Network Working Group N. Montero Internet-Draft Independent Researcher Intended status: Informational 30 December 2025 Expires: 3 July 2026 Unified Transition Overlay (UTO): A Gateway-Based IPv4/IPv6 Translation Proxy draft-montero-uto-02 Abstract 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. 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 3 July 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Montero Expires 3 July 2026 [Page 1] Internet-Draft Unified Transition Overlay (UTO): A Gate December 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 5. Gateway Discovery and Addressing . . . . . . . . . . . . . . 4 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 4 6.1. IPv4-to-IPv6 Flow . . . . . . . . . . . . . . . . . . . . 4 6.2. IPv6-to-IPv4 Flow . . . . . . . . . . . . . . . . . . . . 5 7. Transport-Layer Integrity and Checksum Handling . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 11. Informative References . . . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The coexistence of IPv4 [RFC0791] and IPv6 [RFC8200] 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 [RFC6146] and 464XLAT [RFC6877] 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. Montero Expires 3 July 2026 [Page 2] Internet-Draft Unified Transition Overlay (UTO): A Gate December 2025 2. Motivation 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. 3. Terminology 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). 4. Architecture Overview 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. Montero Expires 3 July 2026 [Page 3] Internet-Draft Unified Transition Overlay (UTO): A Gate December 2025 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: IPv4 Host UGW (v4->v6) IPv6 Network IPv6 Host |------------------>|--------------------->|--------------------->| | IPv4 pkt | IPv6 pkt | IPv6 pkt | Figure 1 5. Gateway Discovery and Addressing 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. 6. Protocol Operation 6.1. IPv4-to-IPv6 Flow 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. Montero Expires 3 July 2026 [Page 4] Internet-Draft Unified Transition Overlay (UTO): A Gate December 2025 6.2. IPv6-to-IPv4 Flow 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. 7. Transport-Layer Integrity and Checksum Handling TCP [RFC0793] and UDP [RFC0768] 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 [RFC1624] 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. 8. Security Considerations 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. 9. IANA Considerations This document makes no requests of IANA. 10. Normative References Montero Expires 3 July 2026 [Page 5] Internet-Draft Unified Transition Overlay (UTO): A Gate December 2025 [RFC0791] Postel, J., "Internet Protocol", RFC 791, September 1981, . [RFC0768] Postel, J., "User Datagram Protocol", RFC 768, August 1980, . [RFC0793] Postel, J., "Transmission Control Protocol", RFC 793, September 1981, . [RFC1624] Braden, R., "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 8200, July 2017, . 11. Informative References [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, . [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateless and Stateful Translation", RFC 6877, April 2013, . Appendix A. Acknowledgments The author would like to thank members of the operational community for feedback on gateway-based transition behavior and transport-layer correctness considerations. Author's Address Nicolas Montero Torrealba Independent Researcher Santiago Chile Email: nicolas.montero@usach.cl Montero Expires 3 July 2026 [Page 6]