Unified Transition Overlay (UTO): A Stateless Cross-Version Transition Mechanism for IPv4/IPv6
draft-montero-uto-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Nicolás Montero Torrealba | ||
| Last updated | 2026-06-14 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-montero-uto-03
Network Working Group N. Montero
Internet-Draft Independent Researcher
Intended status: Informational 14 June 2026
Expires: 16 December 2026
Unified Transition Overlay (UTO): A Stateless Cross-Version Transition
Mechanism for IPv4/IPv6
draft-montero-uto-03
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Montero Expires 16 December 2026 [Page 1]
Internet-Draft Unified Transition Overlay June 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5
5. UTO Header Format . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Field Definitions . . . . . . . . . . . . . . . . . . . . 6
5.2. Encoding of an IPv4 Address . . . . . . . . . . . . . . . 7
5.3. Encoding of an IPv6 Address . . . . . . . . . . . . . . . 7
5.4. Header Checksum . . . . . . . . . . . . . . . . . . . . . 7
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8
6.1. IPv4-to-IPv6 Flow . . . . . . . . . . . . . . . . . . . . 8
6.2. IPv6-to-IPv4 Flow . . . . . . . . . . . . . . . . . . . . 8
6.3. UGW Behavior . . . . . . . . . . . . . . . . . . . . . . 9
6.4. ICMP and Path MTU Handling . . . . . . . . . . . . . . . 9
6.5. Address Resolution and Mapping . . . . . . . . . . . . . 10
7. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 10
7.1. Enterprise with Legacy IPv4 Core . . . . . . . . . . . . 10
7.2. ISP with IPv6-Only Access Network . . . . . . . . . . . . 10
7.3. IoT IPv6 Devices Reaching IPv4 Infrastructure . . . . . . 11
8. Advantages and Limitations . . . . . . . . . . . . . . . . . 11
8.1. Advantages . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Backward Compatibility . . . . . . . . . . . . . . . . . . . 13
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. IPv4-to-IPv6 . . . . . . . . . . . . . . . . . . . . . . 13
12.2. IPv6-to-IPv4 . . . . . . . . . . . . . . . . . . . . . . 13
13. Normative References . . . . . . . . . . . . . . . . . . . . 13
14. Informative References . . . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Montero Expires 16 December 2026 [Page 2]
Internet-Draft Unified Transition Overlay June 2026
1. Introduction
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.
2. 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
Montero Expires 16 December 2026 [Page 3]
Internet-Draft Unified Transition Overlay June 2026
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.
3. 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 [RFC2119]
[RFC8174] 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 Section 6.5 for how the SNA is derived and
Section 8.2 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.
Montero Expires 16 December 2026 [Page 4]
Internet-Draft Unified Transition Overlay June 2026
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.
4. 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
([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.
5. 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.
Montero Expires 16 December 2026 [Page 5]
Internet-Draft Unified Transition Overlay June 2026
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
5.1. 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 Section 5.3). 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
[RFC1071] with the Checksum field set to zero. This protects
against the reconstruction errors that arise from corrupted or
misconfigured headers. See Section 5.4.
Montero Expires 16 December 2026 [Page 6]
Internet-Draft Unified Transition Overlay June 2026
DNA / SNA: The destination and source native addresses, encoded as
indicated by DAF and SAF.
5.2. 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.
5.3. 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.
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.
5.4. 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
Montero Expires 16 December 2026 [Page 7]
Internet-Draft Unified Transition Overlay June 2026
integrity mechanisms where applicable.
6. 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.
6.1. 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 Section 6.5.
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 ([RFC7915]),
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
([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.
6.2. 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 Section 6.5. Selecting
a 32-bit SNA for an arbitrary 128-bit source is the point at
which state or a constrained address range is required
(Section 8.2).
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.
Montero Expires 16 December 2026 [Page 8]
Internet-Draft Unified Transition Overlay June 2026
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.
6.3. 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 [RFC7915].
* 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.
6.4. 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 ([RFC1191] for IPv4 transit, [RFC8201] for IPv6
transit) or fragment the outer packet where the transit version
permits.
Montero Expires 16 December 2026 [Page 9]
Internet-Draft Unified Transition Overlay June 2026
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.
6.5. 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 ([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.
7. Deployment Scenarios
7.1. 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.
7.2. 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 Section 8.2.
Montero Expires 16 December 2026 [Page 10]
Internet-Draft Unified Transition Overlay June 2026
7.3. 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.
8. Advantages and Limitations
8.1. 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.
8.2. 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.
Montero Expires 16 December 2026 [Page 11]
Internet-Draft Unified Transition Overlay June 2026
* UTO requires UGWs at transition points and is not a replacement
for dual-stack.
9. 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, [RFC2827])
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 ([RFC4301])
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.
10. 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.
Montero Expires 16 December 2026 [Page 12]
Internet-Draft Unified Transition Overlay June 2026
11. 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.
12. Examples
12.1. 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.
12.2. 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.
13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981, <https://www.rfc-editor.org/rfc/rfc791>.
Montero Expires 16 December 2026 [Page 13]
Internet-Draft Unified Transition Overlay June 2026
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the
Internet Checksum", RFC 1071, September 1988,
<https://www.rfc-editor.org/rfc/rfc1071>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010, <https://www.rfc-editor.org/rfc/rfc6052>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915, June 2016,
<https://www.rfc-editor.org/rfc/rfc7915>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990, <https://www.rfc-editor.org/rfc/rfc1191>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, "Path
MTU Discovery for IP version 6", STD 87, RFC 8201, July
2017, <https://www.rfc-editor.org/rfc/rfc8201>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000,
<https://www.rfc-editor.org/rfc/rfc2827>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005,
<https://www.rfc-editor.org/rfc/rfc4301>.
14. Informative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998,
<https://www.rfc-editor.org/rfc/rfc2460>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998,
<https://www.rfc-editor.org/rfc/rfc2473>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000, <https://www.rfc-editor.org/rfc/rfc2784>.
Montero Expires 16 December 2026 [Page 14]
Internet-Draft Unified Transition Overlay June 2026
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011,
<https://www.rfc-editor.org/rfc/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011, <https://www.rfc-editor.org/rfc/rfc6147>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, April 2013,
<https://www.rfc-editor.org/rfc/rfc6877>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, July 2015,
<https://www.rfc-editor.org/rfc/rfc7599>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, October 2022,
<https://www.rfc-editor.org/rfc/rfc9300>.
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.
Author's Address
Nicolas Montero Torrealba
Independent Researcher
Santiago
Chile
Email: nicolas.montero@usach.cl
Montero Expires 16 December 2026 [Page 15]