| Internet-Draft | Unified Transition Overlay (UTO): A Gate | December 2025 |
| Montero | Expires 3 July 2026 | [Page] |
Unified Transition Overlay (UTO) is a gateway-based IPv4/IPv6 translation proxy that enables cross-version connectivity without requiring encapsulation, new protocol headers, or modifications to end-host stacks. UTO operates exclusively at transition gateways, which translate packet headers between IPv4 and IPv6 and update transport-layer checksums to preserve end-to-end correctness. By confining translation logic to gateways, UTO allows the underlying network to remain purely IPv4 or purely IPv6, facilitating incremental deployment within existing routing and forwarding infrastructures. UTO also supports incremental checksum update to reduce processing overhead for TCP and UDP traffic.¶
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 3 July 2026.¶
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The coexistence of IPv4 [RFC0791] and IPv6 [RFC8200] continues to introduce operational challenges, particularly in environments where edge networks remain single-stack due to legacy constraints, device limitations, or administrative policy. While IPv6 deployment has grown, many enterprise and service-provider environments still rely on IPv4-only cores or provide IPv6-only access networks with limited IPv4 reachability. As a result, hosts and services frequently need to communicate across IP versions.¶
Existing transition mechanisms such as NAT64 [RFC6146] and 464XLAT [RFC6877] rely on specific address synthesis or client-side translation components. UTO proposes a simplified model in which a dedicated gateway device performs IP header translation (IPv4↔IPv6) and updates transport-layer checksums (TCP/UDP) to preserve correctness end-to-end. UTO does not introduce new overlay headers or encapsulation formats, and it requires no changes to host protocol stacks.¶
The IPv4/IPv6 transition remains complicated by heterogeneous deployments and uneven adoption. A common scenario is an access or edge domain that is IPv6-only while upstream services or cores remain IPv4-only, or the reverse. In such cases, cross-version reachability is necessary for legacy applications and services.¶
UTO aims to reduce the operational machinery at the network edge by avoiding encapsulation and additional headers. The gateway translates between address families and preserves transport-layer integrity by updating TCP/UDP checksums when IP addresses change.¶
The goals of UTO are:¶
This document uses the following terms:¶
A device that performs IPv4/IPv6 translation at an administrative boundary and updates transport-layer checksums.¶
A domain that forwards only native IPv4 or only native IPv6 packets.¶
Traffic destined to an IP version not supported by the originating host stack (IPv4-to-IPv6 or IPv6-to-IPv4).¶
UTO is deployed at the boundary of an administrative domain in which hosts may be single-stack. UTO-Gateways (UGWs) provide translation services to allow endpoints to communicate across IP versions. The underlying network remains single-stack and performs ordinary forwarding.¶
The UGW performs IP header translation (IPv4↔IPv6) and updates transport-layer checksums for TCP and UDP packets to ensure end-to-end correctness.¶
The following figure illustrates a conceptual flow:¶
IPv4 Host UGW (v4->v6) IPv6 Network IPv6 Host
|------------------>|--------------------->|--------------------->|
| IPv4 pkt | IPv6 pkt | IPv6 pkt |
Endpoint discovery of a UTO-Gateway is deployment-specific and may use standard mechanisms such as DNS to locate the gateway or service. In a typical deployment, the endpoint obtains a synthetic address in its native address family (for example, a synthetic IPv4 address for an IPv4-only host). This synthetic address is used to steer traffic toward the UTO-Gateway.¶
The UTO-Gateway maintains the mapping between the synthetic address and the real opposite-family destination address and performs translation accordingly. Traffic steering toward the UGW can be achieved via routing policy, anycast gateway addressing, or administrative configuration.¶
When an IPv4-only host needs to reach an IPv6-only destination, the UGW performs translation as follows:¶
When an IPv6-only host needs to reach an IPv4-only destination, the UGW performs translation as follows:¶
TCP [RFC0793] and UDP [RFC0768] checksums include a pseudo-header that covers source and destination IP addresses. When translating between IPv4 and IPv6, the checksum becomes invalid unless updated.¶
The UGW MUST update TCP and UDP checksums before forwarding translated packets. The UGW SHOULD use incremental checksum adjustment [RFC1624] to reduce processing overhead.¶
For UDP, IPv6 does not permit a checksum value of zero. If an IPv4 UDP packet has a zero checksum and is translated to IPv6, the UGW MUST compute and set a valid checksum.¶
UTO does not change the fundamental security properties of IPv4 or IPv6. However, the UTO-Gateway is a critical enforcement point and MUST be protected and monitored as infrastructure-critical equipment.¶
UTO-Gateways MUST validate translated addresses against authorized prefixes and policy. Administrators SHOULD restrict which hosts are permitted to initiate opposite-version traffic, and SHOULD apply ingress filtering to reduce spoofing.¶
This document makes no requests of IANA.¶
The author would like to thank members of the operational community for feedback on gateway-based transition behavior and transport-layer correctness considerations.¶