Network Working Group N. Montero Internet-Draft Independent Researcher Intended status: Informational 28 December 2025 Expires: 1 July 2026 Unified Transition Overlay (UTO): A Gateway-Based IPv4/IPv6 Translation Proxy draft-montero-uto-01 Abstract This document specifies Unified Transition Overlay (UTO), a gateway- based IPv4/IPv6 translation proxy that enables communication between IPv4-only and IPv6-only hosts without packet encapsulation, new protocol headers, or changes to end-host network stacks. UTO operates exclusively at transition gateways that translate packets between IPv4 and IPv6 and update transport-layer checksums to preserve TCP and UDP correctness. Incremental checksum update is supported to reduce processing overhead. The underlying network remains purely IPv4 or purely IPv6, allowing UTO to be incrementally deployed using existing routing and forwarding infrastructure. 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 1 July 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Montero Expires 1 July 2026 [Page 1] Internet-Draft UTO 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 5. Gateway Discovery and Addressing . . . . . . . . . . . . . . 3 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 4 6.1. IPv4-to-IPv6 Flow . . . . . . . . . . . . . . . . . . . . 4 6.2. IPv6-to-IPv4 Flow . . . . . . . . . . . . . . . . . . . . 4 7. Transport-Layer Integrity and Checksum Handling . . . . . . . 4 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 11. Informative References . . . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction IPv4 and IPv6 continue to coexist at global scale. IPv4 is specified in [RFC0791], and IPv6 is specified in [RFC8200]. Many environments remain single-stack at the edge (IPv4-only or IPv6-only), creating interoperability pressure between address families. Existing coexistence mechanisms often rely on translation and/or auxiliary behaviors such as DNS synthesis, including NAT64 ([RFC6146]) and 464XLAT ([RFC6877]). Operational complexity and transport correctness (checksums) remain central engineering concerns. UTO defines a simplified gateway-based translation proxy model: a transition gateway rewrites the IP header between IPv4 and IPv6 and updates transport-layer checksums to preserve end-to-end transport correctness. 2. Motivation The continued coexistence of IPv4 and IPv6 has created operational environments in which many hosts are limited to a single IP version. IPv4-only enterprise networks and IPv6-only service deployments frequently require cross-version connectivity. Montero Expires 1 July 2026 [Page 2] Internet-Draft UTO December 2025 UTO is motivated by reducing the amount of machinery required at the edge: no overlay header is introduced and no encapsulation is required. Instead, a gateway performs address-family translation and preserves transport integrity by explicitly updating TCP and UDP checksums. Goals of UTO include: * Enable communication between IPv4-only and IPv6-only hosts. * Avoid packet encapsulation and additional overlay headers. * Preserve TCP/UDP correctness via checksum update. * Allow incremental deployment using existing routing and forwarding. 3. Terminology UTO-Gateway (UGW) A device that performs IPv4/IPv6 translation at administrative boundaries and updates transport-layer checksums as required. Underlying Network A forwarding domain that uses a single IP version (IPv4-only or IPv6-only). Opposite-Version Traffic Traffic whose destination resides in the opposite IP address family relative to the source host. 4. Architecture Overview UTO is deployed at domain boundaries using UTO-Gateways (UGWs). The underlying network forwards only native IPv4 or native IPv6 packets. The UGW translates packets between IPv4 and IPv6 and updates TCP/UDP checksums before forwarding. IPv4 Host ----> UGW (v4->v6 translation) ----> IPv6 Network ----> IPv6 Host IPv6 Host ----> UGW (v6->v4 translation) ----> IPv4 Network ----> IPv4 Host Figure 1: UTO High-Level Architecture 5. Gateway Discovery and Addressing UTO assumes that an endpoint discovers the appropriate gateway using standard mechanisms such as DNS resolution. DNS is used to locate the gateway (or gateway service) and does not require rewriting DNS records for destination addressing. Montero Expires 1 July 2026 [Page 3] Internet-Draft UTO December 2025 Steering traffic to the UGW is deployment-specific and may be achieved through routing policy, anycast gateway addressing, or explicit administrative configuration. 6. Protocol Operation This section describes gateway behavior for IPv4-to-IPv6 and IPv6-to- IPv4 transitions. Native same-version traffic MUST NOT be modified by UTO. 6.1. IPv4-to-IPv6 Flow 1. An IPv4-only host sends a native IPv4 packet. 2. The UGW identifies opposite-version traffic by policy. 3. The UGW translates the IPv4 header to an IPv6 header for the destination domain. 4. The UGW updates TCP/UDP checksums as required by the address change. 5. The IPv6 domain forwards the translated IPv6 packet to the IPv6 destination. 6.2. IPv6-to-IPv4 Flow 1. An IPv6-only host sends a native IPv6 packet. 2. The UGW identifies opposite-version traffic by policy. 3. The UGW translates the IPv6 header to an IPv4 header for the destination domain. 4. The UGW updates TCP/UDP checksums as required by the address change. 5. The IPv4 domain forwards the translated IPv4 packet to the IPv4 destination. 7. Transport-Layer Integrity and Checksum Handling TCP ([RFC0793]) and UDP ([RFC0768]) include a pseudo-header that incorporates source and destination IP addresses. When a UGW translates between IPv4 and IPv6, the transport checksum becomes invalid unless updated. A UGW MUST update transport-layer checksums for TCP and UDP prior to forwarding translated packets. Implementations SHOULD use incremental checksum adjustment where applicable, as described in [RFC1624], to reduce processing overhead. For UDP, IPv6 requires a non-zero UDP checksum. When translating an IPv4 UDP packet with a zero checksum into IPv6, the UGW MUST compute and set a valid UDP checksum before forwarding. Montero Expires 1 July 2026 [Page 4] Internet-Draft UTO December 2025 8. Security Considerations UTO does not alter IPv4 or IPv6 security properties, but the UGW becomes a critical policy enforcement point. * UGWs MUST validate translated addresses against authorized prefixes or policy. * Administrators SHOULD restrict which hosts can initiate cross- version traffic. * Administrators SHOULD apply ingress filtering on UGW interfaces to reduce spoofing. * UGWs SHOULD be monitored and protected as critical infrastructure components. 9. IANA Considerations This document makes no request of IANA. 10. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981, . [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981, . [RFC1624] Rijsinghani, 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", STD 86, 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, . Montero Expires 1 July 2026 [Page 5] Internet-Draft UTO December 2025 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless 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 Email: nicolas.montero@usach.cl Montero Expires 1 July 2026 [Page 6]