Independent Researcher

Santiago Chile nicolas.montero@usach.cl

IPv4 IPv6 Transition Gateway Translation 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.

The coexistence of IPv4 and IPv6 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 and 464XLAT 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:

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

This document uses the following terms:

UTO-Gateway (UGW)

A device that performs IPv4/IPv6 translation at an administrative boundary and updates transport-layer checksums.

Underlying Network

A domain that forwards only native IPv4 or only native IPv6 packets.

Opposite-Version Traffic

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:

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:

1. Receive an IPv4 packet destined for opposite-version traffic.
2. Translate the IPv4 header to an IPv6 header, mapping addresses as configured.
3. Update transport-layer checksums for TCP/UDP based on address changes.
4. Forward the resulting native IPv6 packet into the IPv6 underlying network.
5. Do not modify same-version traffic.

When an IPv6-only host needs to reach an IPv4-only destination, the UGW performs translation as follows:

1. Receive an IPv6 packet destined for opposite-version traffic.
2. Translate the IPv6 header to an IPv4 header, mapping addresses as configured.
3. Update transport-layer checksums for TCP/UDP based on address changes.
4. Forward the resulting native IPv4 packet into the IPv4 underlying network.
5. Do not modify same-version traffic.

TCP and UDP 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 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.