Unified Transition Overlay (UTO): A Gateway-Based IPv4/IPv6 Translation Proxy

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 1 July 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

IPv4 and IPv6 continue to coexist at global scale. IPv4 is specified in [RFC0791], and IPv6 is specified in [RFC8200]. Many environments remain single-stack at the edge (IPv4-only or IPv6-only), creating interoperability pressure between address families.¶

Existing coexistence mechanisms often rely on translation and/or auxiliary behaviors such as DNS synthesis, including NAT64 ([RFC6146]) and 464XLAT ([RFC6877]). Operational complexity and transport correctness (checksums) remain central engineering concerns.¶

UTO defines a simplified gateway-based translation proxy model: a transition gateway rewrites the IP header between IPv4 and IPv6 and updates transport-layer checksums to preserve end-to-end transport correctness.¶

2. Motivation

The continued coexistence of IPv4 and IPv6 has created operational environments in which many hosts are limited to a single IP version. IPv4-only enterprise networks and IPv6-only service deployments frequently require cross-version connectivity.¶

UTO is motivated by reducing the amount of machinery required at the edge: no overlay header is introduced and no encapsulation is required. Instead, a gateway performs address-family translation and preserves transport integrity by explicitly updating TCP and UDP checksums.¶

Goals of UTO include:¶

• Enable communication between IPv4-only and IPv6-only hosts.¶
• Avoid packet encapsulation and additional overlay headers.¶
• Preserve TCP/UDP correctness via checksum update.¶
• Allow incremental deployment using existing routing and forwarding.¶

3. Terminology

UTO-Gateway (UGW)

A device that performs IPv4/IPv6 translation at administrative boundaries and updates transport-layer checksums as required.¶

Underlying Network

A forwarding domain that uses a single IP version (IPv4-only or IPv6-only).¶

Opposite-Version Traffic

Traffic whose destination resides in the opposite IP address family relative to the source host.¶

4. Architecture Overview

UTO is deployed at domain boundaries using UTO-Gateways (UGWs). The underlying network forwards only native IPv4 or native IPv6 packets. The UGW translates packets between IPv4 and IPv6 and updates TCP/UDP checksums before forwarding.¶

IPv4 Host ----> UGW (v4->v6 translation) ----> IPv6 Network ----> IPv6 Host
IPv6 Host ----> UGW (v6->v4 translation) ----> IPv4 Network ----> IPv4 Host

5. Gateway Discovery and Addressing

UTO assumes that an endpoint discovers the appropriate gateway using standard mechanisms such as DNS resolution. DNS is used to locate the gateway (or gateway service) and does not require rewriting DNS records for destination addressing.¶

Steering traffic to the UGW is deployment-specific and may be achieved through routing policy, anycast gateway addressing, or explicit administrative configuration.¶

6. Protocol Operation

This section describes gateway behavior for IPv4-to-IPv6 and IPv6-to-IPv4 transitions. Native same-version traffic MUST NOT be modified by UTO.¶

7. Transport-Layer Integrity and Checksum Handling

TCP ([RFC0793]) and UDP ([RFC0768]) include a pseudo-header that incorporates source and destination IP addresses. When a UGW translates between IPv4 and IPv6, the transport checksum becomes invalid unless updated.¶

A UGW MUST update transport-layer checksums for TCP and UDP prior to forwarding translated packets. Implementations SHOULD use incremental checksum adjustment where applicable, as described in [RFC1624], to reduce processing overhead.¶

For UDP, IPv6 requires a non-zero UDP checksum. When translating an IPv4 UDP packet with a zero checksum into IPv6, the UGW MUST compute and set a valid UDP checksum before forwarding.¶

8. Security Considerations

UTO does not alter IPv4 or IPv6 security properties, but the UGW becomes a critical policy enforcement point.¶

• UGWs MUST validate translated addresses against authorized prefixes or policy.¶
• Administrators SHOULD restrict which hosts can initiate cross-version traffic.¶
• Administrators SHOULD apply ingress filtering on UGW interfaces to reduce spoofing.¶
• UGWs SHOULD be monitored and protected as critical infrastructure components.¶

9. IANA Considerations

This document makes no request of IANA.¶

Appendix A. Acknowledgments

The author would like to thank members of the operational community for feedback on gateway-based transition behavior and transport-layer correctness considerations.¶

Author's Address