| Internet-Draft | Unified Transition Overlay | December 2025 |
| Montero | Expires 15 June 2026 | [Page] |
This document specifies Unified Transition Overlay (UTO), a minimal encapsulation mechanism designed to enable bidirectional communication between IPv4-only and IPv6-only hosts without requiring NAT64, DNS64, heavy protocol translation, or global changes to Internet routing. UTO introduces a compact 12-byte header that carries a Remote Native Address (RNA) and allows a packet to traverse a network whose forwarding plane uses the opposite IP version. The underlying network remains purely IPv4 or purely IPv6, ensuring compatibility with existing hardware and reducing operational complexity.¶
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 15 June 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 transition from IPv4 to IPv6 has progressed far slower than originally expected. Although IPv6 was standardized in 1998 and provides an address space sufficient for global-scale expansion, IPv4 continues to dominate a significant portion of Internet traffic and infrastructure.¶
Existing coexistence mechanisms such as NAT64, 464XLAT, DS-Lite, MAP-T, MAP-E, and tunneling technologies allow partial interoperability between the two protocol families. However, these solutions introduce operational challenges including stateful translation, DNS rewriting, multi-stage encapsulation, complex customer-premises equipment requirements, and decreased visibility for operators and middleboxes.¶
Unified Transition Overlay (UTO) defines a minimal and efficient encapsulation mechanism allowing IPv4-only hosts to communicate with IPv6-only hosts, and vice versa, without altering the forwarding behavior of the underlying network. UTO preserves the original IP packet by wrapping it in a compact micro-header that carries the Remote Native Address (RNA) of the intended destination host.¶
UTO operates exclusively at transition gateways and does not require updates to backbone routers, end-host stacks, or the semantics of the IPv4/IPv6 version field. The mechanism is suitable for incremental deployment and does not disrupt existing routing architectures.¶
The continued coexistence of IPv4 and IPv6 has created operational 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 due to legacy applications, security policies, or hardware constraints.¶
The industry has generally adopted translation-based models for cross-version communication. While functional, these models rely on complex transformation of packet headers, manipulation of DNS records, and maintenance of large state tables. Such approaches can reduce transparency, complicate troubleshooting, and introduce latency.¶
UTO addresses these issues by avoiding deep translation entirely. Instead, the original IP packet remains intact, and only a concise transition overlay header is added. The underlying network sees only IPv4 or IPv6 traffic, while the UTO-Gateway performs minimal processing at the boundaries between domains.¶
The goals of UTO include:¶
UTO enables cross-version communication by inserting a compact overlay header that carries the Remote Native Address (RNA) of the destination host. The underlying network transports the encapsulated packet using its native forwarding plane (IPv4 or IPv6), while the UTO-Gateway (UGW) at the remote boundary restores the original packet and delivers it to the destination.¶
IPv4 Host ----> UGW(v4v6) ----> IPv6 Network ----> UGW(v6v4) ----> IPv6 Host IPv6 Host ----> UGW(v6v4) ----> IPv4 Network ----> UGW(v4v6) ----> IPv4 Host
In all cases, the underlying forwarding devices (routers, middleboxes, fabric switches, and hardware ASIC pipelines) see only pure IPv4 or pure IPv6 packets. UTO does not modify the meaning of any field in either IP header, does not introduce mixed-version headers, and does not require new behaviors from the routing subsystem.¶
Encapsulation occurs only at the edges of transition domains, where UGWs have explicit configuration defining which prefixes or hosts reside in opposite-version networks. Traffic between same-version hosts (IPv4-IPv4 or IPv6-IPv6) remains native and is unaffected by UTO.¶
The UTO header precedes the native packet and has a fixed size of 12 bytes. It contains the Remote Native Address (RNA) of the destination host, encoded according to the address family and compressed when necessary. The general layout is:¶
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 |Flags|HLen| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Native Address (part 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Native Address (part 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UTO header is inserted immediately after the outer IP header (IPv4 or IPv6), depending on the direction of encapsulation. When decapsulating, the receiving UGW removes the UTO header, restores the native packet, and forwards it according to its normal routing table.¶
Vers (4 bits): Indicates the version of the UTO protocol. This specification defines Vers=1 (0001).¶
Flags (4 bits): Identify the address family encoded in RNA. 0001 - RNA contains an IPv4 address. 0010 - RNA contains an IPv6 address (compressed).¶
HLen (8 bits): Total length of the UTO header in bytes. For this version, HLen MUST be set to 12.¶
Reserved (16 bits): Reserved for future use. MUST be set to zero on transmission and ignored on receipt.¶
Remote Native Address (RNA): Carries the destination host's native IPv4 or IPv6 address. When the address is IPv6, the RNA block contains a compressed representation sufficient to reconstruct the full 128-bit address at the receiving UGW.¶
When the Flags field indicates an IPv4 address (0001), the RNA field carries the 32-bit IPv4 address left-aligned within the 64-bit RNA space. The remaining bits MUST be set to zero.¶
Example:¶
IPv4 address: 192.0.2.44 RNA encoding: 0xC000022C 00000000
When the Flags field indicates IPv6 (0010), the RNA carries a compressed representation of the full 128-bit IPv6 address. Compression is deterministic and reversible.¶
UTO uses a two-component encoding scheme:¶
Each UGW maintains an internal Prefix Table:¶
Label (16 bits) IPv6 Prefix (48 bits)
During encapsulation, the UGW:¶
During decapsulation, the receiving UGW:¶
Compression reduces RNA size while preserving uniqueness and allowing fast O(1) reconstruction.¶
This section describes the behavior of UTO-Gateways (UGWs) during encapsulation and decapsulation, and defines the forwarding logic for IPv4-to-IPv6 and IPv6-to-IPv4 transitions. UTO operates strictly at administrative boundaries and does not modify packets traveling within a single address family.¶
Cross-version traffic is identified by UGW policy, typically based on destination prefixes, routing tables, interface roles, or explicitly configured host mappings.¶
When an IPv4-only host sends a packet toward an IPv6-only host, the following steps occur:¶
When an IPv6-only host sends a packet toward an IPv4-only host:¶
UGWs MUST implement the following logic:¶
UGWs MAY implement rate limiting or filtering on cross-version flows, depending on administrative policy.¶
UGWs MUST NOT modify the inner native IP header except when decrementing the Hop Limit or TTL, as required by normal forwarding semantics.¶
Performance Considerations: UTO is designed for efficient forwarding in both software and hardware implementations. Encapsulation and decapsulation are stateless operations requiring only header insertion/removal and optional prefix-table lookup. This avoids the per-flow state, checksum rewrites, and multi-field translations required by stateful transition mechanisms such as NAT64. Implementations MAY leverage hardware offload where available.¶
UTO is designed for deployment in environments where one IP version dominates the core, while hosts or services using the opposite version exist at the edges. This section outlines representative deployment patterns.¶
Many organizations operate IPv4-centric networks due to legacy equipment or applications. Cloud services, IoT systems, and external APIs may be IPv6-only. UTO allows such enterprises to:¶
UGWs are deployed at the enterprise perimeter, typically at WAN routers or firewalls.¶
ISPs deploying IPv6-only access (e.g., mobile or FTTH networks) may still need to support IPv4-only services hosted externally. UTO enables:¶
UGWs are deployed at the ISP's edge to minimize translation complexity.¶
IoT deployments commonly use IPv6 due to address abundance and neighbor-discovery efficiency. However, control servers or legacy monitoring systems may operate only in IPv4. UTO allows IPv6-only IoT devices to:¶
UGWs in this scenario are placed at aggregation points or border concentrators.¶
UTO offers the following benefits:¶
UTO introduces certain limitations:¶
UTO increases packet size by 12 bytes in addition to the outer IP header. UGWs MUST implement Path MTU Discovery (PMTUD) on the encapsulation path, or alternatively support IP-layer fragmentation when required. Operators SHOULD provision appropriate MTU values on boundary interfaces to avoid encapsulation-induced loss.¶
UTO does not alter IPv4 or IPv6 security properties. However, several operational considerations apply:¶
Since UTO encapsulates entire packets, its security posture is similar to other tunneling protocols. Operators SHOULD ensure that monitoring systems can observe both outer headers and encapsulated flows when necessary.¶
This document requests that IANA allocate:¶
These values are required for correct identification of UTO packets when conveyed over native IPv4 or IPv6 networks.¶
UTO is compatible with existing IPv4 and IPv6 networks because:¶
No modifications to TCP, UDP, ICMP, IPv4, or IPv6 behavior are required. UTO can coexist with other transition technologies, including NAT64, DS-Lite, MAP-E, MAP-T, and traditional tunnels.¶
The following example illustrates a full cross-version transition:¶
Source IPv4 host: 10.1.1.10¶
Destination IPv6: 2001:db8:20::44¶
Steps:¶
Example:¶
Source IPv6 host: 2001:db8:10::50¶
Destination IPv4: 192.0.2.99¶
Steps:¶
The author would like to thank the members of the operational and research communities whose discussions on transition technologies motivated the development of this document. Their practical feedback on coexistence mechanisms, routing architectures, and deployment challenges helped shape the UTO design goals.¶
Special appreciation is extended to engineers who contributed insights on encapsulation performance, IPv6 prefix management, and hardware forwarding behavior. Their operational experience provided valuable context for identifying the limitations of translation-based models.¶