| Internet-Draft | Unified Transition Overlay | June 2026 |
| Montero | Expires 16 December 2026 | [Page] |
This document specifies Unified Transition Overlay (UTO), a stateless encapsulation-plus-translation mechanism that enables bidirectional communication between IPv4-only and IPv6-only hosts across a transit network whose forwarding plane uses the opposite IP version. UTO carries the native source and destination addresses of the communicating hosts in a compact, variable-length overlay header. The original packet is tunneled between UTO-Gateways (UGWs) across the transit network and is converted to the destination's address family by a single stateless header translation performed only at the egress UGW. UTO requires no DNS64, no stateful per-flow translation in the common IPv4-to-IPv6 direction, and no changes to backbone routers or end-host stacks. The transit network forwards only pure IPv4 or pure IPv6 packets.¶
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 16 December 2026.¶
Copyright (c) 2026 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.¶
The transition from IPv4 to IPv6 has progressed far slower than originally expected. Although IPv6 was standardized in [RFC2460] (now [RFC8200]) and provides an address space sufficient for global-scale expansion, IPv4 continues to carry a significant portion of Internet traffic and to underpin a large installed base of infrastructure.¶
Existing coexistence mechanisms such as stateful NAT64 [RFC6146], 464XLAT [RFC6877], DS-Lite, MAP-T [RFC7599], MAP-E, and various tunneling technologies provide interoperability between the two protocol families. Each makes a different trade-off among per-flow state, DNS rewriting, multi-stage encapsulation, customer-premises-equipment complexity, and operator visibility.¶
Unified Transition Overlay (UTO) targets a specific niche in that design space: it preserves the sender's original packet across an opposite-version transit network by tunneling it between gateways, and it performs exactly one stateless, algorithmic header translation ([RFC7915]) at the egress gateway so that the final host receives a packet in its own address family. The native source and destination addresses needed to perform that translation without per-flow state are carried explicitly in the UTO header rather than being derived from a state table or from DNS rewriting.¶
UTO is honest about its scope. Unlike the -00 revision of this draft, this document does NOT claim to avoid translation entirely; cross-family delivery inherently requires translating the packet to the destination's address family at some point. What UTO avoids is (a) stateful per-flow translation in the IPv4-to-IPv6 direction, (b) DNS64-style record synthesis, and (c) translation anywhere other than the egress gateway. The genuine and unavoidable limits of stateless operation, in particular the IPv6-to-IPv4 source-representation problem, are stated explicitly in Section 8.2.¶
The continued coexistence of IPv4 and IPv6 has produced environments in which many hosts are limited to a single IP version. IPv4 depletion has pushed cloud providers and IoT systems toward IPv6-only deployments, while numerous enterprise networks still rely heavily on IPv4 because of legacy applications, security policy, or hardware constraints.¶
Translation-based models such as NAT64 are functional but rely on per-flow state and, when paired with DNS64, on rewriting DNS responses. Such designs can reduce transparency, complicate troubleshooting, and add latency. UTO reduces these costs for the common direction (IPv4 host reaching an IPv6-only service) to a single stateless transform at the edge, while being explicit that the reverse direction may still require state, exactly as every other transition technology does.¶
The goals of UTO are:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
UTO operates only at the boundaries of transition domains. At the ingress UGW the native packet is left intact and is encapsulated, together with a UTO header carrying the DNA and SNA, inside an outer header of the transit network's address family. The outer header addresses the egress UGW, not the final host; the transit network therefore forwards an ordinary packet of its own version and is unaware of UTO. At the egress UGW the outer header and the UTO header are removed and a single stateless header translation ([RFC7915]) converts the preserved native packet into the destination's address family, using the DNA and SNA as the new destination and source.¶
IPv4 Host --> UGW --[ IPv6 transit ]--> UGW --> IPv6 Host
(encap + UTO) (decap + translate)
IPv6 Host --> UGW --[ IPv4 transit ]--> UGW --> IPv4 Host
(encap + UTO) (decap + translate)
Figure 1: UTO Architecture
¶
Same-version traffic (IPv4-to-IPv4 or IPv6-to-IPv6) is never touched by UTO and is forwarded natively. Backbone routers, fabric switches, hardware ASIC pipelines, and middleboxes that operate on the outer header see only pure IPv4 or pure IPv6 packets.¶
The UTO header is variable in length. A fixed 8-byte part is followed by the encoded DNA and then the encoded SNA. The HLen field carries the total header length so that intermediate code and the egress UGW can locate the native packet without parsing the address encodings.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | DAF | SAF | Flags | HLen | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Native Address (DNA), variable ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Native Address (SNA), variable ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: UTO Header Layout
¶
When DAF or SAF indicates IPv4 (0b0001), the corresponding address is carried as the 32-bit IPv4 address in network byte order, occupying exactly 4 bytes. No padding is used.¶
Example: 192.0.2.44 is encoded as the 4 bytes 0xC0 0x00 0x02 0x2C.¶
An IPv6 address MAY be carried in full (16 bytes, code 0b0010) or, as an OPTIONAL size optimization, label-compressed (10 bytes, code 0b0011). Implementations MUST support the full 16-byte encoding; the label-compressed encoding is OPTIONAL.¶
The label-compressed encoding splits a 128-bit IPv6 address into a 64-bit prefix context (network prefix plus subnet) and a 64-bit Interface Identifier (IID). The prefix context is replaced by a 16-bit Label, and the IID is carried verbatim. The 10-byte field is therefore [Label (16 bits) | IID (64 bits)], and the reconstructed address is the 64-bit context bound to that Label concatenated with the 64-bit IID.¶
Label (16 bits) -> Prefix Context (64 bits)
Figure 3: Prefix Context Table (label-compressed mode)
¶
The label-compressed encoding requires that the ingress UGW (assigning the Label) and the egress UGW (resolving it) share an identical Label-to-context binding. This document does not define a control protocol for distributing those bindings; deployments using the OPTIONAL compressed mode MUST establish consistent bindings by configuration or by an out-of-band mechanism, and a UGW that cannot resolve a Label MUST drop the packet. Deployments that cannot guarantee consistent bindings MUST use the full 16-byte encoding. This constraint is listed in Section 8.2.¶
On transmission the sender sets the Checksum field to zero, computes the one's-complement sum of the entire UTO header as a sequence of 16-bit words, and stores the one's complement of that sum in the Checksum field. On receipt a UGW MUST verify the checksum and MUST drop the packet if verification fails. The checksum covers only the UTO header, not the outer or inner IP headers, which carry their own integrity mechanisms where applicable.¶
UTO operates strictly at administrative boundaries. Cross-version traffic is identified by UGW policy, typically by destination prefix, interface role, or explicitly configured host mapping. Same-family traffic MUST NOT be encapsulated or translated.¶
Because the IPv6 source (SNA) is an IPv4-embedded IPv6 address ([RFC6052]) routed toward the UGWs, replies from the IPv6 host are forwarded to a UGW and reverse-translated to IPv4 with no per-flow state.¶
A UGW MUST:¶
A UGW MAY apply rate limiting or filtering to cross-version flows.¶
Encapsulation and the single egress translation are designed to be amenable to hardware offload; in the IPv4-to-IPv6 direction they require no per-flow state.¶
UTO adds an outer IP header plus the UTO header, increasing packet size on the transit path. UGWs MUST implement Path MTU Discovery for the UGW-to-UGW tunnel ([RFC1191] for IPv4 transit, [RFC8201] for IPv6 transit) or fragment the outer packet where the transit version permits.¶
ICMP errors generated within the transit network refer to the outer header and the UGW addresses; the ingress UGW MUST consume such errors and, where appropriate, signal a reduced effective MTU toward the source rather than forwarding the transit ICMP error to an end host of a different family. ICMP errors that refer to the translated packet (for example, generated at or beyond the egress) MUST be translated back to the source's address family per [RFC7915] using the DNA and SNA so that the originating host receives a coherent error.¶
UTO does not define name resolution and does not synthesize DNS records. The ingress UGW learns the opposite-family destination by ordinary means: an A or AAAA record returned by unmodified DNS, a configured host or prefix mapping, or an algorithmic translation prefix ([RFC6052]). UTO therefore does not remove a deployment's dependence on the host being able to learn a usable destination address; it removes only the need to rewrite DNS responses and to keep per-flow translation state in the IPv4-to-IPv6 direction.¶
The SNA is derived as follows. For IPv4-to-IPv6, the IPv4 source is mapped to an IPv4-embedded IPv6 address using a configured translation prefix ([RFC6052]); this is stateless and reversible. For IPv6-to-IPv4, see Section 8.2: representing an arbitrary 128-bit source in 32 bits is not injective, so the SNA MUST be drawn either from a stateful source map at the UGW or from a constrained, 1:1-mapped IPv6 source range.¶
An IPv4-centric enterprise can reach IPv6-only cloud services, IoT systems, and external APIs without deploying NAT64 or DNS64. UGWs are placed at WAN routers or firewalls. The IPv4-to-IPv6 direction is fully stateless.¶
An ISP running IPv6-only access (mobile or FTTH) can reach IPv4-only external services. UGWs at the ISP edge keep the access network native IPv6 and reduce CGNAT pressure. The IPv6-to-IPv4 direction is subject to the source-mapping constraint of Section 8.2.¶
IPv6-only IoT devices can reach IPv4 management or monitoring systems over an IPv4 backhaul. UGWs sit at aggregation points or border concentrators.¶
UTO is a tunneling-plus-translation mechanism and inherits the security posture of both. The following apply:¶
IANA is requested to assign one value from the "Assigned Internet Protocol Numbers" registry to identify UTO encapsulation. Because that registry is shared between the IPv4 Protocol field and the IPv6 Next Header field, a single assignment suffices to identify UTO over both IPv4 and IPv6 transit networks; no separate IPv6 Next Header value is required.¶
This document makes no other IANA requests. The UTO Vers, DAF, SAF, and Flags code points are managed within this specification and do not require an IANA registry at this time.¶
End hosts are unchanged. Transit routers forward only native IPv4 or IPv6 outer headers, and outer-header middleboxes operate normally. No changes to TCP, UDP, ICMP, IPv4, or IPv6 are required of hosts. UTO can coexist with NAT64, DS-Lite, MAP-E, MAP-T, and traditional tunnels, since it is confined to traffic that UGW policy selects for cross-version handling.¶
Source IPv4 host 10.1.1.10 sends to an IPv6-only service whose AAAA record is 2001:db8:20::44. The ingress UGW sets DNA = 2001:db8:20::44 (DAF = IPv6) and SNA = the IPv4-embedded IPv6 form of 10.1.1.10 under the configured translation prefix (SAF = IPv6), encapsulates the intact IPv4 packet in an outer IPv6 header addressed UGW-to-UGW, and forwards it. The egress UGW translates to IPv6 and delivers a native IPv6 packet: source = embedded(10.1.1.10), destination = 2001:db8:20::44. Replies are routed back to a UGW by the translation prefix and reverse-translated with no state.¶
Source IPv6 host 2001:db8:10::50 sends to IPv4-only host 192.0.2.99. The ingress UGW sets DNA = 192.0.2.99 (DAF = IPv4) and selects an IPv4 SNA for the source from a stateful map or a 1:1-mapped range (SAF = IPv4), encapsulates the intact IPv6 packet in an outer IPv4 header addressed UGW-to-UGW, and forwards it. The egress UGW translates to IPv4 and delivers source = chosen-SNA, destination = 192.0.2.99. Replies to the SNA are returned to the mapping UGW.¶
The author thanks the operational and research communities whose discussions on transition technologies, encapsulation performance, IPv6 prefix management, and hardware forwarding behavior shaped the design goals of UTO and the explicit statement of its limits.¶
The author appreciates the academic feedback and technical discussions received within the Universidad de Santiago de Chile (USACH) environment during the development of this work.¶