]> Independent Researcher

Santiago Chile nicolas.montero@usach.cl

Internet Network Working Group IPv6 IPv4 transition encapsulation translation 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.

Introduction The transition from IPv4 to IPv6 has progressed far slower than originally expected. Although IPv6 was standardized in (now ) 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 , 464XLAT , DS-Lite, MAP-T , 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 () 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 .

Motivation 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:

• Preserve the sender's original packet across the transit network.
• Enable bidirectional communication between IPv4-only and IPv6-only hosts.
• Keep the transit forwarding plane purely IPv4 or purely IPv6.
• Avoid stateful per-flow translation and DNS rewriting in the IPv4-to-IPv6 direction.
• Support incremental deployment at administrative boundaries without global coordination.

Terminology 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 when, and only when, they appear in all capitals, as shown here.

UTO-Gateway (UGW):

A device that, at the ingress, encapsulates the native packet and prepends the UTO header, and, at the egress, removes the UTO header and performs the single stateless header translation that produces the deliverable native packet.

Destination Native Address (DNA):

The destination host's address in its own address family, carried in the UTO header. The egress UGW writes the DNA into the destination field of the delivered packet.

Source Native Address (SNA):

A representation of the source host in the destination's address family, carried in the UTO header, chosen so that the destination host can address replies back toward the source. See for how the SNA is derived and for the constraints in the IPv6-to-IPv4 direction.

Transit Network:

The forwarding plane over which the encapsulated packet travels between UGWs. It is IPv4-only or IPv6-only and is unaware of UTO.

Native Packet:

The sender's original IPv4 or IPv6 packet before encapsulation.

UTO Header:

A variable-length transition header (minimum 8 bytes plus the encoded DNA and SNA) inserted between the outer transit header and the native packet.

Endpoint:

A host that supports only one IP version.

Architecture Overview 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 () converts the preserved native packet into the destination's address family, using the DNA and SNA as the new destination and source. 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.

UTO Header Format 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.

Field Definitions

Vers (4 bits):

UTO protocol version. This document defines Vers = 1 (0b0001). A UGW that receives an unsupported version MUST drop the packet.

DAF (4 bits):

Destination Address Family / encoding of the DNA: 0b0001 = IPv4 (4 bytes); 0b0010 = IPv6, full (16 bytes); 0b0011 = IPv6, label-compressed (10 bytes, see ). Other values are reserved; a UGW that receives a reserved value MUST drop the packet.

SAF (4 bits):

Source Address Family / encoding of the SNA, using the same code points as DAF.

Flags (4 bits):

Control flags. Bit 0 (DF): when set, the egress UGW MUST set the Don't Fragment behavior on the delivered packet where applicable. The remaining bits are reserved, MUST be set to zero on transmission, and MUST be ignored on receipt.

HLen (8 bits):

Total length of the UTO header in bytes, including the fixed 8-byte part and both encoded addresses. HLen MUST equal 8 + len(DNA) + len(SNA). A UGW MUST drop the packet if HLen is inconsistent with the DAF and SAF encodings.

Reserved:

The 8-bit and 16-bit reserved fields MUST be set to zero on transmission and ignored on receipt, except that they are included in the Checksum computation.

Checksum (16 bits):

The 16-bit one's-complement checksum of the entire UTO header (fixed part plus DNA plus SNA), computed per with the Checksum field set to zero. This protects against the reconstruction errors that arise from corrupted or misconfigured headers. See .

DNA / SNA:

The destination and source native addresses, encoded as indicated by DAF and SAF.

Encoding of an IPv4 Address 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.

Encoding of an IPv6 Address 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. 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 .

Header Checksum 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.

Protocol Operation 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.

IPv4-to-IPv6 Flow

1. The IPv4 host sends an ordinary IPv4 packet toward a destination that policy maps to an IPv6-only host.
2. The ingress UGW determines the destination IPv6 address (DNA) and a source representation in IPv6 (SNA), per .
3. The ingress UGW prepends a UTO header (DAF = IPv6, SAF = IPv6) and encapsulates the intact IPv4 packet inside an outer IPv6 header addressed UGW-to-UGW.
4. The IPv6 transit network forwards the packet natively, unaware of UTO.
5. The egress UGW removes the outer and UTO headers and performs a single stateless IPv4-to-IPv6 header translation (), writing DNA as destination and SNA as source, and delivers a native IPv6 packet to the IPv6-only host.

Because the IPv6 source (SNA) is an IPv4-embedded IPv6 address () routed toward the UGWs, replies from the IPv6 host are forwarded to a UGW and reverse-translated to IPv4 with no per-flow state.

IPv6-to-IPv4 Flow

1. The IPv6 host sends an ordinary IPv6 packet toward a destination that policy maps to an IPv4-only host.
2. The ingress UGW determines the destination IPv4 address (DNA) and an IPv4 source representation (SNA), per . Selecting a 32-bit SNA for an arbitrary 128-bit source is the point at which state or a constrained address range is required ().
3. The ingress UGW prepends a UTO header (DAF = IPv4, SAF = IPv4) and encapsulates the intact IPv6 packet inside an outer IPv4 header addressed UGW-to-UGW.
4. The IPv4 transit network forwards the packet natively.
5. The egress UGW removes the outer and UTO headers, performs a single stateless IPv6-to-IPv4 header translation, and delivers a native IPv4 packet to the IPv4-only host.

UGW Behavior A UGW MUST:

• Maintain policy identifying opposite-version destinations.
• Apply UTO only to cross-family traffic; same-family traffic MUST NOT be altered.
• Verify the UTO header checksum and the HLen/DAF/SAF consistency before acting on a packet, and drop the packet on any failure.
• Perform exactly one stateless header translation, at the egress, per .
• Adjust the Hop Limit / TTL of the translated packet as normal forwarding requires, and otherwise not modify inner upper-layer payload.
• Enforce which prefixes may originate cross-version traffic.

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.

ICMP and Path MTU Handling 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 ( for IPv4 transit, 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 using the DNA and SNA so that the originating host receives a coherent error.

Address Resolution and Mapping 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 (). 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 (); this is stateless and reversible. For IPv6-to-IPv4, see : 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.

Deployment Scenarios

Enterprise with Legacy IPv4 Core 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.

ISP with IPv6-Only Access Network 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 .

IoT IPv6 Devices Reaching IPv4 Infrastructure IPv6-only IoT devices can reach IPv4 management or monitoring systems over an IPv4 backhaul. UGWs sit at aggregation points or border concentrators.

Advantages and Limitations

Advantages

• The sender's original packet is preserved across the transit network; only one transform occurs, at the egress.
• The IPv4-to-IPv6 direction is stateless and needs neither NAT64 state nor DNS64.
• The transit network forwards only pure IPv4 or pure IPv6 packets and is unaware of UTO.
• Works with existing hardware forwarding pipelines and outer-header middleboxes.
• Deployable incrementally at administrative boundaries.
• The header carries an integrity checksum, making header validation well defined.

Limitations

• Cross-family delivery requires translating the packet at the egress; UTO does not and cannot avoid translation altogether.
• IPv6-to-IPv4 source representation. A 128-bit source cannot be represented losslessly in a 32-bit SNA. Bidirectional IPv6-to-IPv4 communication therefore requires either stateful source mapping at the UGW (state in exactly one place) or a constrained, 1:1-mapped IPv6 source range. This is the same fundamental limit that constrains NAT64 and is not removed by UTO.
• UTO does not provide name resolution; deployments still rely on DNS or configured mapping to learn destination addresses.
• The OPTIONAL label-compressed IPv6 encoding requires consistent Label-to-context bindings across UGWs, which this document does not distribute.
• Encapsulation increases packet size, requiring PMTUD or fragmentation on the transit path.
• UTO requires UGWs at transition points and is not a replacement for dual-stack.

Security Considerations UTO is a tunneling-plus-translation mechanism and inherits the security posture of both. The following apply:

• A UGW MUST verify the UTO header checksum before decapsulation or translation and MUST drop packets that fail.
• DNA and SNA values MUST be checked against authorized prefixes; a UGW MUST drop packets whose DNA or SNA falls outside its configured cross-version policy, to prevent the overlay from being used as an open relay.
• Operators SHOULD apply ingress anti-spoofing (BCP 38, ) on UGW interfaces.
• The UTO checksum protects against corruption but not against an active attacker; where confidentiality or authenticity is required, UTO traffic SHOULD be carried inside IPsec () or an equivalent secure tunnel.
• Because addresses are carried in the overlay rather than in a state table, a misconfigured or spoofed SNA can misdirect replies; SNA validation against authorized source ranges is therefore REQUIRED, not optional.
• Monitoring systems SHOULD be able to observe both the outer header and the encapsulated native packet.

IANA Considerations 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.

Backward Compatibility 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.

Examples

IPv4-to-IPv6 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.

IPv6-to-IPv4 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.

Normative References Informative References

Acknowledgments 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.