



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,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC0768]  Postel, J., "User Datagram Protocol", RFC 768, August
              1980, <https://www.rfc-editor.org/info/rfc768>.

   [RFC0793]  Postel, J., "Transmission Control Protocol", RFC 793,
              September 1981, <https://www.rfc-editor.org/info/rfc793>.

   [RFC1624]  Braden, R., "Computation of the Internet Checksum via
              Incremental Update", RFC 1624, May 1994,
              <https://www.rfc-editor.org/info/rfc1624>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

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,
              <https://www.rfc-editor.org/info/rfc6146>.

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateless and Stateful Translation",
              RFC 6877, April 2013,
              <https://www.rfc-editor.org/info/rfc6877>.

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]
