Network Working Group C. Xie Internet-Draft C. Ma Intended status: Informational China Telecom Expires: 1 April 2027 X. Li CERNET Center/Tsinghua University G. Mishra Verizon Inc. T. Graf Swisscom 28 September 2026 Framework for Multi-domain IPv6-only Network and IPv4-as-a-Service draft-ietf-v6ops-framework-md-ipv6only-underlay-28 Abstract This document presents a framework, from the network operators' perspective, for building and operating IPv6-only underlay networks that span multiple domains (i.e., multiple interconnected Autonomous Systems). To carry residual IPv4 traffic in such an environment, the framework proposes stateless IPv4/IPv6 address mapping as the basis for IPv4-as-a-Service (IPv4aaS), so that IPv4 packets are translated at the network edge and forwarded across the IPv6-only underlay without per-flow state or IPv4/IPv6 conversion gateways on the data path. The document is intended as a network operator problem statement, guidance, and requirements rather than a protocol specification. It covers the scope of applicability and trust boundaries, options for IPv6 mapping prefix allocation, and operational, manageability, and security considerations. 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 April 2027. Xie, et al. Expires 1 April 2027 [Page 1] Internet-Draft Framework for Multi-domain IPv6-only September 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. IPv6-only Deployment in Multi-domain Network . . . . . . . . 7 3.1. Scope of Applicability . . . . . . . . . . . . . . . . . 9 4. IPv4/IPv6 Address Mapping for IPv4-as-a-Service . . . . . . . 10 4.1. IPv4/IPv6 Address Mapping . . . . . . . . . . . . . . . . 11 4.2. End-to-End IPv4 Service Delivery . . . . . . . . . . . . 13 5. Framework Overview . . . . . . . . . . . . . . . . . . . . . 14 5.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Address Mapping Rule Processing . . . . . . . . . . . . . 15 5.2.1. Generation . . . . . . . . . . . . . . . . . . . . . 15 5.2.2. Distribution . . . . . . . . . . . . . . . . . . . . 16 5.3. Packet Conversion and Transmission . . . . . . . . . . . 17 5.4. Conversion Capability Selection . . . . . . . . . . . . . 18 6. IPv6 Mapping Prefix Allocation . . . . . . . . . . . . . . . 18 7. Operational Considerations . . . . . . . . . . . . . . . . . 19 8. Manageability Considerations . . . . . . . . . . . . . . . . 20 8.1. MR-DB Consistency Monitoring . . . . . . . . . . . . . . 20 8.2. Behavior on Mapping Rule Withdrawal . . . . . . . . . . . 21 8.3. OAM Requirements . . . . . . . . . . . . . . . . . . . . 21 8.3.1. ICMP/ICMPv6 Error Handling . . . . . . . . . . . . . 21 8.3.2. Connectivity Verification . . . . . . . . . . . . . . 22 8.3.3. Performance Monitoring . . . . . . . . . . . . . . . 22 8.3.4. Cross-Domain Coordination . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9.1. Authenticity and Integrity of Packets . . . . . . . . . . 22 9.2. Source Address Validation . . . . . . . . . . . . . . . . 23 9.3. Stateless IP/ICMP Translators . . . . . . . . . . . . . . 24 9.4. Address Mapping Rule Distribution . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 Xie, et al. Expires 1 April 2027 [Page 2] Internet-Draft Framework for Multi-domain IPv6-only September 2026 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 13. Normative References . . . . . . . . . . . . . . . . . . . . 25 14. Informative References . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction For the IPv6 transition, IPv6-only is considered the final stage where only IPv6 protocol is used for transport while maintaining global reachability for both IPv6 and IPv4 services. As of this writing, most IPv6 deployments rely on dual-stack [RFC4213]. Dual- stack has long- term drawbacks, including duplicated network resources and states, as well as increased operational complexity from maintaining both protocol stacks. In 2016, the IAB stated that it "expects the IETF to no longer mandate IPv4 compatibility in new or updated protocols, with future IETF work focusing on IPv6 optimization" [IAB-statement]. To ensure service continuity, network operators require that the network maintains access to the global IPv4 Internet when deploying IPv6-only. This practice is commonly referred to as "IPv4-as- a-Service" and is a logical approach for IPv6-only networks [RFC9313]. To avoid confusion when using the term "IPv6-only" in IETF and other documents, [I-D.ietf-v6ops-ipv6-only] provides a definition of "IPv6-only". This document uses the term "IPv6-only network" as defined in Section 2. The network infrastructure of large network operators typically consists of at least an access network and a backbone network. The access network serves customers by delivering access links, assigning addresses, and enabling two-way data transmission. The backbone network is typically a multi-domain network comprising interconnected Autonomous Systems (ASes). The backbone network is sometimes referred to as the underlay network. Accordingly, IPv6-only deployment involves two key parts: IPv6-only in the access network and IPv6-only in the backbone network. For the IPv6-only deployment in the access network, various transition technologies such as 464XLAT [RFC6877], MAP-T [RFC7599], MAP-E [RFC7597], and DS-Lite [RFC6333] have been developed and deployed [RFC9313]. These solutions allow network operators to allocate only IPv6 addresses to customer terminals or networks, while some public IPv4 addresses are shared on the network side to enable users to access IPv4 Internet services. However, the current IPv6-only ecosystem remains incomplete, particularly in backbone networks. For large-scale network operators, a comprehensive multi-domain IPv6-only framework is needed Xie, et al. Expires 1 April 2027 [Page 3] Internet-Draft Framework for Multi-domain IPv6-only September 2026 that integrates multiple related technologies to ensure seamless IPv4 and IPv6 data transmission. The Softwire Mesh Framework addresses the fundamental problem of connecting IPv4 islands across an IPv6-only transit core [RFC5565]. However, as stated in Section 12 of [RFC5565], its procedures do not function as specified when the transit core consists of multiple Autonomous Systems. While access- side IPv6-only solutions have matured, the backbone network side lacks a comparable framework, which is the focus of this document. This document presents an operational and deployment framework for building a multi-AS IPv6-only network and for coordinating the IPv4 and IPv6 address spaces from the perspective of network operators. This multi-AS IPv6-only network may be operated by a single network operator or by multiple cooperating network operators under mutual agreement. For IPv4-as-a- Service, this framework proposes an address-mapping-based mechanism that performs packet translation at the network edge. An alternative realization encapsulates IPv4 in IPv6 using the same address mapping approach. While the primary focus of this document is the translation-based approach, encapsulation aspects are discussed where relevant. With such a framework, IPv4/IPv6 packet conversion relies on stateless address mapping at the edges, meaning no user-specific state or translation tables are required for packet processing, and no IPv4-to-IPv6 conversion gateway is needed along the data path. The document serves as a problem statement, provides guidance, and defines a set of requirements for network operators, rather than as a protocol specification. The remainder of this document is organized as follows. Section 2 defines terminology used throughout this document. Section 3 describes the scope and applicability of multi-domain IPv6-only deployment. Section 4 introduces the IPv4/IPv6 address mapping mechanism for IPv4-as-a-Service. Section 5 presents the overall framework, including address mapping rule processing, packet conversion, and conversion capability selection. Section 6 discusses IPv6 mapping prefix allocation. Sections 7 through 9 address operational, manageability, and security considerations, respectively. Section 10 discusses IANA considerations. Sections 11 and 12 provide acknowledgements and contributors. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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. Xie, et al. Expires 1 April 2027 [Page 4] Internet-Draft Framework for Multi-domain IPv6-only September 2026 2. Terminology The following terms are used in this document: Address mapping rule The mapping relationship between an IPv4 address block and its corresponding IPv6 mapping prefix in an IPv6-only network. AS Autonomous System, this term refers to a set of routers under a single technical administration, using an interior gateway protocol (IGP) and common metrics to determine how to route packets within the AS, and using an inter-AS routing protocol to determine how to route packets to other ASes. BR Border Router, a router located at the edge of an AS. CE Customer Edge, customer devices attached, via some sort of attachment circuit, to one or more Provider Edge (PE) routers. DC Data Center, a physical complex housing physical servers, network switches and routers, network service appliances, and networked storage. The purpose of a data center is to provide application, compute, and/or storage services. Default egress PE A designated PE that advertises a default address mapping rule (0.0.0.0/0) to all other PEs, serving as a fallback for IPv4 traffic whose destination lacks a more specific mapping rule in the ingress PE's MR-DB. Default mapping rule An address mapping rule with the IPv4 address block 0.0.0.0/0, advertised by the default egress PE, ensuring that IPv4 traffic is not dropped due to missing mapping information. Egress PE The PE router where a packet exits the IPv6-only underlay network. The egress PE reconstructs the original IPv4 packet from the received IPv4-embedded IPv6 packet and forwards it toward the IPv4 destination. Conversion Type field An attribute of an address mapping rule that indicates the PE's IPv4/IPv6 conversion capability (e.g., translation-only, encapsulation-only, or both), enabling the ingress PE to select a transformation mechanism supported by both the ingress and egress PEs. IPv4-embedded IPv6 address An IPv6 address formed by a variable- Xie, et al. Expires 1 April 2027 [Page 5] Internet-Draft Framework for Multi-domain IPv6-only September 2026 length prefix, a zero-u-octet (bits 64-71), an embedded 32-bit IPv4 address, and a variable-length zero suffix, as defined in Section 2.2 of [RFC6052]. IPv4-embedded IPv6 packet An IPv6 packet created through translation of an IPv4 packet, where the source and destination IPv4 addresses are statelessly mapped to corresponding IPv6 addresses. IPv6-only network Refers specifically to an "IPv6-only underlay network", where the forwarding plane and transport infrastructure support only IPv6. IPv6 mapping prefix A specific IPv6 prefix allocated to a PE device. It is used to construct an IPv4-embedded IPv6 address by combining with an IPv4 address, as described in Section 4.1 of this document. Ingress PE The PE router where a packet enters the IPv6-only underlay network. The ingress PE converts the IPv4 packet into an IPv4-embedded IPv6 packet for forwarding across the underlay. MR-DB Mapping Rule DataBase, a database which stores the address mapping rules at the PE router. Multi-domain IPv6-only underlay network IPv6-only underlay network which consists of multiple ASes operated by single or multiple network operators. NSP Network-Specific Prefix, as defined in [RFC6052]; it refers to an IPv6 prefix assigned by an organization for use in algorithmic mapping. P Provider Router, a router in the network operator's network that does not attach to CE devices. PE Provider Edge, a device at the edge of the IPv6-only underlay network, providing the functionality required for IPv4-as- a-Service. Pref6(PE) The IPv6 mapping prefix assigned to a specific Provider Edge (PE) device. This prefix uniquely identifies the PE within the IPv6-only underlay network and is used by other PEs to determine the correct egress PE for an IPv4-over-IPv6 flow. UE User Equipment, e.g., mobile phone. Xie, et al. Expires 1 April 2027 [Page 6] Internet-Draft Framework for Multi-domain IPv6-only September 2026 3. IPv6-only Deployment in Multi-domain Network This framework is designed to assist large network operators in deploying IPv6-only networks in a multi-domain environment. Large- scale network operators usually manage network infrastructure comprising multiple interconnected Autonomous Systems (ASes). This is referred to as a "Multi-domain Underlay Network" in this document. The term "underlay" is used here from an operational service-delivery perspective, where the IPv6-only network acts as the underlying infrastructure for delivering IPv4 services across multiple domains. These ASes often support different functions, such as metro area networks, backbone networks, 4G/5G mobile core networks, Data Centers (DCs), and may be administered by separate departments or network operators with different routing and security policies. In a multi- domain network environment, edge nodes are commonly referred to as Provider Edge (PE) routers. The ingress PE is the router where a packet enters the network, while the egress PE is the router where it exits. Internal nodes are typically called Provider (P) routers. As some Internet services may remain IPv4-based even in an IPv6-dominated environment, an IPv6-only network needs to support access to IPv4-only services, as well as IPv6 services. [RFC6992] describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on [RFC7915] and [RFC6052], along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network. Since it is based on the OSPF protocol, it supports IPv4-as-a-Service within a single AS. To facilitate the illustration of the framework from the perspective of network operators, Figure 1 shows a multi-domain network, which consists of three interconnected ASes, i.e., AS1, AS2, and AS3. Among them, AS1 and AS2 are operated by Operator 1, AS3 is operated by Operator 2. Routers located outside the backbone but directly connected to it Xie, et al. Expires 1 April 2027 [Page 7] Internet-Draft Framework for Multi-domain IPv6-only September 2026 are referred to as Customer Edge (CE) routers. AS1 of Operator 1 provides connectivity services to mobile, home broadband, and enterprise customers, represented by CE1, CE2, and CE3, respectively. [RFC8585] defines IPv4 service continuity requirements for IPv6 CE routers, extending the basic IPv6 CE specifications to support IPv4 delivery in IPv6-only access networks. Additionally, service instances in DCs often require cross-site communication, whether on- premises or in external data centers. A multi-domain network needs to facilitate these data center connections. Operator 1 needs to support at least two connectivity modes for data centers: The first is between a data center and individual users, for instance, a user of CE1 accesses a service instance hosted in DC1; the second is between data centers, for instance, communications occur between service instances hosted in DC1 and DC2, respectively. Regarding external interconnection, Operator 3 is a neighboring network of Operator 2. AS4 of Operator 3 is an IPv4-only network and does not support IPv6. The interconnection protocol between AS3 and AS4 is BGP that supports IPv4 route advertisement. +-------+ +-------+ | DC1 | | DC2 | +-------+ +-------+ | | +----+ /-------|-----------------\ /------|-------\ |UE/ |\ | | | | | | |CE2 | \ | | | | | | +----+ \| PE2 +-+ | | PE4 | |\ / \ / \ | | / \ | +---+ +----+ | \ | AS1 | | AS2 | | | | AS3 | | / \ |UE/ |---+- PE1 P1--P2 P3--+---+--P4 PE3--+----BR1 AS4 | |CE1 | | / | | | | | | | | | \ Op-3/ +----+ |/ \ / \ / | | \ / | +---+ | +-+ +-+ | | +-+ | +----+ /| | | | |UE/ | / | Op-1 | | Op-2 | |CE3 |/ | | | | +----+ | | | | \-------------------------/ \--------------/ Figure 1: An Example of a Multi-domain Underlay Network For Operator 1, deploying IPv6-only without a unified framework may lead to independent adoption of IPv6 transition approaches across different ASes. This can result in multiple IPv6-only islands interconnected by IPv4 links between domains. Furthermore, the network may operate multiple IPv4/IPv6 packet conversion gateways with varying functionalities. For a given AS, incoming IPv4 packets Xie, et al. Expires 1 April 2027 [Page 8] Internet-Draft Framework for Multi-domain IPv6-only September 2026 are converted to IPv6 at an ingress, then reverted to IPv4 at an egress. When the IPv4 packets reach the next AS, another round of IPv4 -> IPv6 -> IPv4 packet conversion is carried out. Excessive IPv4/IPv6 conversion gateways introduce network complexity and increase capital expenditures. Thus, a unified framework is required to define network edge behavior for IPv4 service delivery and eliminate unnecessary IPv4/IPv6 conversion gateways within the multi- domain network. For IPv6-only deployment guided by a unified framework, IPv4 protocol instances are gradually disabled and IPv6 will be the primary network-layer protocol. Specifically, core P routers, such as P1, P2, P3, and P4, operate only IPv6 protocol, while PE routers, such as PE1, PE2, PE3, and PE4, support IPv4 protocol on interfaces facing IPv4 client networks and IPv6 on interfaces facing the core, requiring them to handle both address families. Operator 1 transports packets that originate and terminate outside the network. These packets enter the IPv6 network at a PE router, traverse the network, and exit through another PE router to continue their path. 3.1. Scope of Applicability This subsection defines the intended deployment scope, the trust assumptions, and the boundary of the framework. Maximum scope of deployment: This framework targets a multi-domain IPv6-only underlay composed of multiple interconnected IPv6-only ASes, which may be operated by a single network operator or multiple cooperating network operators with mutual agreement. The framework is not intended to cover the Internet, and it MUST NOT affect the operation of the existing IPv4 Internet or IPv6 Internet. Address mapping rules are advertised but are not propagated over the Internet. Trust relationship among participating network operators: Participating network operators are assumed to have a pre- existing trust relationship, including bilateral agreements, coordinated mapping-prefix allocation, common ICMP filtering rules, and trusted ingress PEs. These assumptions are prerequisites for deployment, not properties that the framework itself establishes. Boundary of the framework: The framework boundary is the edge of the participating IPv6-only underlay network. Mapping prefixes are not advertised outside this boundary. Xie, et al. Expires 1 April 2027 [Page 9] Internet-Draft Framework for Multi-domain IPv6-only September 2026 Reachability of mapping prefixes outside the boundary: Mapping prefixes are intended to be reachable only within the participating domain. They are not intended to be reachable from the global IPv4 Internet or from non-participating networks. Border routers at the framework boundary SHOULD filter mapping prefixes to prevent leakage outside the participating domain. Filtering at the boundary: The following filtering requirements apply at the framework boundary: * Ingress and egress filtering of mapping prefixes to prevent leakage outside the participating domain; * Source validation for traffic entering and leaving the underlay; * Consistent ICMP filtering rules across participating network operators; * Prevention of default egress use for non-participating destinations. This framework may be considered a limited-domain mechanism as described in [RFC8799]. The operational, routing, and security analyses in this document are based on the assumption of a limited domain with cooperating parties, not an open capability reaching the global IPv4 Internet. Existing technologies such as 464XLAT [RFC6877], MAP-T [RFC7599], MAP-E [RFC7597], and DS-Lite [RFC6333] are single-administration access technologies where mapping rules are provisioned rather than exchanged, and each has one well-defined edge to the rest of the Internet. This framework addresses multi-domain backbone networks where mapping rules are exchanged across AS boundaries, which is a complementary rather than substitutive scenario. The Softwire Mesh Framework [RFC5565] addresses the fundamental problem of connecting IPv4 islands across an IPv6-only transit core. However, as stated in Section 12 of [RFC5565], its procedures do not work as specified when the transit core consists of multiple ASes. [RFC8950] addresses IPv4 NLRI with IPv6 next-hop in BGP, but does not define mapping-prefix uniqueness, boundary filtering, or default- egress behavior in a multi-AS IPv6-only underlay. This framework targets the multi-AS environment that is not adequately covered by these existing specifications, and provides the operational considerations and requirements for such deployments. 4. IPv4/IPv6 Address Mapping for IPv4-as-a-Service Xie, et al. Expires 1 April 2027 [Page 10] Internet-Draft Framework for Multi-domain IPv6-only September 2026 4.1. IPv4/IPv6 Address Mapping To support IPv4-as-a-Service in a multi-domain IPv6-only network, the framework proposes that each PE device be allocated and identified by at least one IPv6 mapping prefix, denoted by Pref6(PE). In addition, this framework uses an attribute named "Conversion Type field" to indicate the PE's IPv4/IPv6 conversion capability (e.g., translation- only, encapsulation-only, or both). Each PE device will also have one or more associated IPv4 address blocks which are extracted from local IPv4 routing table or address pool. The mapping relationship can be represented at a minimum by the following data structure. IPv4 address block: Pref6(PE) The address mapping rule comprises the aforementioned data structure and a Conversion Type field. The Conversion Type field informs the ingress PE whether the egress PE supports translation-only, encapsulation-only, or both. Based on the value of this field, the ingress PE can select an IPv4/ IPv6 transformation mechanism that is supported by both itself and the egress PE, ensuring interoperation when multiple transformation modes are available in the network. The detailed structure of the address mapping rule, including the definition of the Conversion Type field, is out of the scope of this document and is expected to be defined by the specific protocol(s) used for rule distribution. For an IPv4 packet traversing a multi-domain IPv6-only network, the address mapping rule for the destination address determines the egress PE from which the packet leaves the IPv6-only domain. When the address mapping rule corresponding to the destination address of a given IPv4 packet is available, the ingress PE can generate corresponding IPv6 source and destination addresses from the packet's IPv4 source and destination address as below. The explicit process of converting an IPv4 packet into an IPv6 packet is described in Section 5.3. Xie, et al. Expires 1 April 2027 [Page 11] Internet-Draft Framework for Multi-domain IPv6-only September 2026 * The IPv6 source address is derived from an IPv6 mapping prefix that is assigned to the ingress PE, using the address construction algorithm specified in [RFC6052] Section 2.2. When more than one such mapping prefix is assigned to the ingress PE, the selection of the prefix to use for a given packet is a matter of local policy. Network operators SHOULD define a clear policy for selecting which prefix to use as the source when constructing IPv4-embedded IPv6 packets. The selection may be based on, for example, the egress PE's domain (e.g., intra-provider vs. inter- provider), the destination domain, the type of service, or other administrative boundaries. However, this document does not mandate a single selection algorithm or approach, but expects network operators to develop and refine their strategies based on operational needs. * The IPv6 destination address is derived from an IPv6 mapping prefix that has been advertised via the mapping rule distribution mechanism, using the address construction algorithm specified in [RFC6052] Section 2.2. For example, if the ingress PE's mapping prefix is 2001:db8:1::/96 and the source IPv4 address is 192.0.2.1, the source IPv6 address is 2001:db8:1::192.0.2.1. If the destination IPv4 address is 198.51.100.1 and the egress PE's mapping prefix is 2001:db8:2::/96, the destination IPv6 address is 2001:db8:2::198.51.100.1. At the egress PE, the IPv4 address is extracted from the IPv4-embedded IPv6 address following [RFC6052] Section 2.3. This document does not define any additional validation of the suffix or u-bit beyond what [RFC6052] specifies. Since the address mapping rule adopts prefix-level mapping, there is no need to maintain user-related status or translation tables for packet conversion at the PE devices. This framework proposes to algorithmically translate an IPv4 address to a corresponding IPv6 address, and vice versa, using only statically configured information. The IPv6 address translated from an IPv4 address is called an IPv4-embedded IPv6 address, which has been defined in [RFC6052]. As shown in Section 2.2 of [RFC6052], IPv4-embedded IPv6 addresses are composed of a variable-length prefix, a zero u-octet (bits 64-71), the embedded IPv4 address, and a variable-length suffix. Table 1 shows examples of IPv4-embedded IPv6 addresses constructed according to Section 2.2 of [RFC6052]. It is the same as Table 1 of [RFC6052], except that the first column is referred to as the "IPv6 mapping prefix" rather than the "Network- Specific Prefix". Xie, et al. Expires 1 April 2027 [Page 12] Internet-Draft Framework for Multi-domain IPv6-only September 2026 +=======================+============+==============================+ | IPv6 mapping prefix | IPv4 | IPv4-embedded IPv6 address | | | address | | +=======================+============+==============================+ | 2001:db8::/32 | 192.0.2.33 | 2001:db8:c000:221:: | +-----------------------+------------+------------------------------+ | 2001:db8:100::/40 | 192.0.2.33 | 2001:db8:1c0:2:21:: | +-----------------------+------------+------------------------------+ | 2001:db8:122::/48 | 192.0.2.33 | 2001:db8:122:c000:2:2100:: | +-----------------------+------------+------------------------------+ | 2001:db8:122:300::/56 | 192.0.2.33 | 2001:db8:122:3c0:0:221:: | +-----------------------+------------+------------------------------+ | 2001:db8:122:344::/64 | 192.0.2.33 | 2001:db8:122:344:c0:2:2100:: | +-----------------------+------------+------------------------------+ | 2001:db8:122:344::/96 | 192.0.2.33 | 2001:db8:122:344::192.0.2.33 | +-----------------------+------------+------------------------------+ Table 1: Representation Examples of IPv4-Embedded IPv6 Addresses Prior to IPv4/IPv6 packet conversion, an ingress PE needs to obtain the address mapping rule for the destination address within or across domains. To meet this requirement, a specific mechanism of address mapping rule exchange needs to be designed, so an egress PE can inform other PEs that an IPv4 packet with a destination address being within a specific IPv4 address block can be forwarded to itself directly. [RFC1918] addresses are allowed by this framework, and customers can use [RFC1918] addresses inside their own networks. [RFC1918] prefixes used by different customers can be differentiated by assigning different IPv6 mapping prefixes to different customers at the edge of the IPv6-only underlay network. 4.2. End-to-End IPv4 Service Delivery To enable IPv4 service data forwarding in a multi-domain IPv6-only network, IPv4 packets need to be converted to IPv6 packets at the PEs located at the edge of the network. This framework specifies stateless IPv4/IPv6 address translation, which is used for packet translation at the data layer. Encapsulating IPv4 in IPv6 across a multi-AS core using the same address-mapping approach is an alternative realization. The subsequent text in this document mainly elaborates on the packet translation mode. Consider the network shown in Figure 1, when an ingress PE, e.g., PE1, receives an IPv4 packet (destined for a remote IPv4 network, e.g., Operator 3) from a client-facing interface, it queries its Xie, et al. Expires 1 April 2027 [Page 13] Internet-Draft Framework for Multi-domain IPv6-only September 2026 mapping rule database (i.e., MR-DB) to find the rule that longest- prefix matches the packet's destination IPv4 address. The IPv6 mapping prefix in the rule identifies the corresponding egress PE. In this case, the ingress and egress PEs reside in different autonomous systems (ASes): the ingress PE (PE1) is in AS1 of Operator 1, while the egress PE (PE3) is in AS3 of Operator 2. The ingress PE converts the IPv4 destination address into an IPv6 address using PE3's IPv6 mapping prefix and forwards the IPv6 packet to PE3. Upon receiving the IPv6 packet, PE3 extracts the original IPv4 source and destination addresses from the IPv4-embedded IPv6 addresses and reconstructs the IPv4 packet. The packet is then forwarded to Operator 3 based on the IPv4 routing table maintained at PE3. In this case, only the ingress/egress PEs, i.e. PE1 and PE3, convert packets, intermediate P routers just forward, so the overhead introduced by IPv4/IPv6 packet header transformation is incurred once, not per-AS-hop, as shown in Figure 2. |----------------------------------->| | | | +--+ +--+ +--+ | | / \ / \ / \ | +--+ +----+ | | AS1 | | AS2 | | AS3 | | / \ |UE/ |-----PE1 P1---P2 P3---P4 PE3---| IPv4 | |CE | | IPv6 | | IPv6 | | IPv6 | \Op-3/ +----+ \ / \ / \ / +--+ +--+ +--+ +--+ Figure 2: End-to-end IPv4 Service Delivery from Ingress to Egress It should be noted that P3 and P4 are P routers from the perspective of the framework defined by this document, although they are the edges of providers' networks. 5. Framework Overview 5.1. Outline This section outlines the multi-domain IPv6-only underlay network framework from the perspective of network operators. As shown in Figure 1, the framework consists of edge PE devices, core P devices, and customer-side IPv4 routers. The PE devices are responsible for performing stateless IPv4/IPv6 packet conversion and will support the following functions: 1. Address Mapping Rule Processing * Generate and manage the address mapping rules Xie, et al. Expires 1 April 2027 [Page 14] Internet-Draft Framework for Multi-domain IPv6-only September 2026 * Exchange the address mapping rules across an IPv6-only network 2. Packet Conversion * Generate IPv4-embedded IPv6 packets using translation * Recover IPv4 packets from IPv4-embedded IPv6 packets via translation. 5.2. Address Mapping Rule Processing Within PE devices, processing of IPv4/IPv6 address mapping rules includes two steps, 5.2.1. Generation For IPv4 service delivery, IPv4/IPv6 address mapping rules need to be generated. In the network shown in Figure 1, when PE3 receives an IPv4 route advertisement from an IPv4 border router, e.g., BR1, it extracts IPv4 address blocks and generates address mapping rules by combining them with its own IPv6 mapping prefix. All the address mapping rules, whether locally generated or received from other PEs, are stored in its local MR-DB. PE devices also support rule management operations, such as insertion, modification, and deletion of address mapping rules. A PE originates mapping rules only for IPv4 address blocks for which it serves as the authoritative or aggregating egress point. These blocks include, but are not limited to, its directly connected customer prefixes, locally provisioned address pools, and site aggregates. A PE MUST NOT originate per-prefix mapping rules for transit routes learned from external BGP peers. Traffic destined for all other IPv4 addresses (i.e., the remainder of the global IPv4 space) is covered by a default mapping rule pointing to a configured default egress PE. When multiple mapping rules match the same IPv4 destination address block (e.g., due to multihoming or anycast services), the ingress PE selects the single best rule according to the underlying routing protocol's best-path selection procedure (e.g., BGP's decision process). This ensures deterministic egress PE selection. The detailed selection procedure is outside the scope of this document. Multipath forwarding (i.e., load balancing across multiple egress PEs) is not considered in this framework. Anycast egress is also not supported in this framework. Xie, et al. Expires 1 April 2027 [Page 15] Internet-Draft Framework for Multi-domain IPv6-only September 2026 If the address mapping rule of a certain IPv4 address block has not been received by the ingress PE, the IPv4 service data destined for that IPv4 address block will not be forwarded to the correct egress PE. To mitigate this issue, the framework introduces a default egress PE, which advertises a default address mapping rule to all other PEs. The format of default address mapping rule is as follows: 0.0.0.0/0: Pref6(PE) The default rule associated with the designated default egress PE serves as a fallback mechanism to ensure connectivity when a more specific address mapping rule for a given IPv4 destination is not available in the ingress PE's MR-DB. When such a rule is present, the ingress PE forwards the corresponding IPv4-embedded IPv6 packets to the default egress PE. This ensures that IPv4 traffic is not dropped due to missing mapping information, though it may lead to suboptimal forwarding paths. Operators should carefully consider the placement and capacity of the default egress PE to avoid congestion or single points of failure. The introduction of the default address mapping rule in an IPv6-only network will cause some IPv4 service traffic to be attracted to the default egress PE, which may introduce security implications, such as hijack risk; discussion on this aspect can be found in Section 9.4. Under the rule-origination policy above, an egress PE will generate mapping entries only for locally significant IPv4 prefixes -- i.e., its own customer blocks, address pools, and site aggregates. The default egress PE mechanism covers all non-local traffic, preventing unbounded MR-DB growth. This ensures that MR-DB lookups, synchronization, and rule management impose minimal overhead on PE control and data planes, making the design operationally manageable even in networks with complex external peering. In typical deployments, this yields an MR-DB size on the order of tens to a few hundred entries, substantially smaller than the global routing table. 5.2.2. Distribution Address mapping rules generated on a PE device need to be distributed to PE devices in other domains. During the transmission of these rules, the key information elements, including the Conversion Type field mentioned in Section 4.1, MUST NOT be modified by any intermediate node. The distribution mechanism should be designed with the goal of supporting scalability across multiple independently administered network operators. This process can be implemented through the routing process. When an address mapping rule is generated locally, the PE device converts it into a data structure and forwards it to the routing engine for Xie, et al. Expires 1 April 2027 [Page 16] Internet-Draft Framework for Multi-domain IPv6-only September 2026 transmission. In the opposite direction, upon receiving a routing announcement with an address mapping rule from a neighboring router, the PE device extracts and stores it in its MR-DB. The specific protocol extensions required for address mapping rule transmission are outside the scope of this document. Based on the received mapping rule, the ingress PE can identify the appropriate egress PE (i.e., the Pref6(PE) to use as the destination prefix). 5.2.2.1. Properties of Conforming Rule Distribution Mechanisms Any conforming mapping-rule distribution mechanism MUST provide the following properties: * Field integrity: The key information elements of an address mapping rule, including the Conversion Type field, MUST NOT be modified by any intermediate node during transit. * Scoping and filtering: The distribution mechanism MUST support scoping and filtering of mapping rules at administrative boundaries. Mapping rules SHOULD NOT be propagated outside the participating domain. * Origin authentication: The distribution mechanism MUST support origin authentication. Specifically, any distribution mechanism that conforms to this framework and is used to distribute mapping rules SHOULD be capable of verifying the authentic origin of the mapping rules, thereby ensuring the legitimacy and trustworthiness of their source. * Rule rejection: PE devices SHOULD reject unauthorized mapping rules. Specifically, when a mapping rule attempts to bind an IPv4 address block to a mapping prefix that is not within the authorized scope of that address block, the PE device MUST detect such a violation and explicitly reject the mapping rule. 5.3. Packet Conversion and Transmission In this framework, the PE devices provide forwarding capability to IPv4-embedded IPv6 packets for IPv4 data delivery. IPv4-embedded IPv6 packets are generated using translation, which refers to the packet conversion from one protocol format to the other. When the ingress PE receives an IPv4 packet from its neighboring IPv4 network, it looks for an address mapping rule for the packet's IPv4 destination address; if such a rule is found, it generates the corresponding IPv6 source and destination addresses from the IPv4 addresses, following the procedure described in Section 4.1. This Xie, et al. Expires 1 April 2027 [Page 17] Internet-Draft Framework for Multi-domain IPv6-only September 2026 process complies with [RFC7915]. For IPv4-embedded IPv6 packets, the Pref6 part of the IPv6 destination address identifies the egress point. Therefore, packet forwarding can be performed by P devices solely based on the Pref6 part of the destination address. Upon receiving the IPv6 packet, the egress PE processes the packet according to the following cases: * If the destination address does NOT match one of the PE's own IPv6 mapping prefixes: The packet is not subject to this framework and is forwarded according to the normal IPv6 forwarding rules. * If the destination address DOES match, but the source address is NOT a valid IPv4-embedded IPv6 address (i.e., one whose IPv6 prefix portion is formed from the mapping prefix of an authorized ingress PE, see Section 9.2): The packet MUST be discarded, and implementations SHOULD maintain a counter for such drops for operational visibility and security monitoring. * If BOTH the destination matches AND the source is a valid IPv4-embedded IPv6 address: The egress PE translates the IPv4-embedded IPv6 packet and restores the original IPv4 packet. This process complies with [RFC7915]. The IPv4 packet is then forwarded based on the IPv4 routing information maintained at the egress PE. Source-address validation is described in Section 9.2. 5.4. Conversion Capability Selection When both the ingress PE and the egress PE support translation and encapsulation mechanisms (as indicated by the Conversion Type field in the address mapping rule), the ingress PE can autonomously select an egress PE capability that matches its own to send IPv4 service packets. This selection process requires no additional negotiation with the egress PE. 6. IPv6 Mapping Prefix Allocation As shown in Section 4.1, IPv6 mapping prefixes are used by PEs to generate address mapping rules for the IPv4 address blocks they serve (see Section 5.2.1 ). These prefixes are unique within the multi- domain network, and they are to be allocated from the NSPs. An NSP refers to a dedicated IPv6 prefix (or a set of prefixes) assigned from a network operator's available IPv6 address pool for IPv4 address mapping. For an IPv6-only network, one or more distinct IPv6 Xie, et al. Expires 1 April 2027 [Page 18] Internet-Draft Framework for Multi-domain IPv6-only September 2026 mapping prefixes are assigned to each PE device. Each PE's IPv6 mapping prefix SHOULD be allocated as a sub- prefix of a larger IPv6 prefix that is already advertised in the network and whose next hop reaches that PE (or its site). This allows IPv4-embedded IPv6 packets to be forwarded using existing aggregate routes, avoiding the need for additional FIB entries in the IPv6 core. The IPv6 mapping prefix MUST be one of the lengths permitted by [RFC6052] Section 2.2, i.e., /32, /40, /48, /56, /64, or /96. When the prefix length is less than 96 bits, the bits after the embedded IPv4 address are defined in [RFC6052] Section 2.2 as the suffix. The value of the suffix and the u-bit follows [RFC6052]; in particular, for the well-known prefix case the u-bit is set to 0 and the remaining suffix bits are 0, but the exact value is as specified in [RFC6052]. Guidance on prefix length selection can be found in Section 3.3 of [RFC6052]. From the perspective of network operations, having all IPv6 mapping prefixes share the same length during deployment will likely avoid the unnecessary processing cost and complexity caused by prefix length diversity. The IPv6 mapping prefix Pref6(PE) MUST be selected from the IPv6 address block owned by the egress PE. A mapping rule is only usable while its Pref6(PE) recursively resolves to a valid IPv6 route reaching the correct egress. When that reachability is lost, the mapping rule MUST be withdrawn or deactivated. Traffic MUST NOT continue to be forwarded using a mapping rule whose Pref6(PE) is unreachable. The exact mechanism (withdraw, deactivate, or fall back to another egress) is a local policy decision, but the stale mapping rule MUST NOT be used. A PE MUST NOT forward an IPv4-embedded IPv6 packet using a mapping rule whose Pref6(PE) does not recursively resolve to a valid IPv6 route reaching the originating egress PE. When a PE receives an IPv4-embedded IPv6 packet and its MR-DB does not contain a mapping rule covering the destination IPv4 address, the PE MUST drop the packet and MAY generate an ICMPv6 Destination Unreachable error. 7. Operational Considerations MTU configuration SHOULD be given consideration when deploying IPv6-only in a multi-domain network. When IPv4 packets are translated (as specified in [RFC7915]), the IPv6 header is 20 octets larger than the IPv4 header in the best case; however, the overhead is not fixed. As per [RFC7915] Section 4.1, a Fragment Header (8 octets) is additionally inserted when the incoming IPv4 packet is already a fragment, or when the DF bit is clear and the resulting IPv6 packet would exceed the configured lowest-ipv6-mtu. Moreover, IPv4 options, if present, contribute further overhead (hence [RFC7915] Section 1.4 uses "20+ octets"). Operators provisioning Xie, et al. Expires 1 April 2027 [Page 19] Internet-Draft Framework for Multi-domain IPv6-only September 2026 headroom for MTU SHOULD therefore account for up to 28 octets of translation overhead, plus any IPv4 options that may be present. In a multi-domain network traversing multiple ASes, MTU differences between domains are likely to cause silent packet drops or performance degradation -- a fundamental operational concern for any IPv4-over-IPv6 framework. Therefore, network operators MUST handle MTU and fragmentation issues, for example, by configuring appropriate MSS clamping for TCP connections, ensuring consistent MTU across domains, or following the recommendations in Section 1.4 of [RFC7915] for general MTU/ fragmentation handling, and Sections 4.2 and 5.2 for specific ICMP translation handling. A concrete recommendation is to provision an IPv6-only core MTU of at least 1548 bytes (1500-byte IPv4 payload + 40-byte IPv6 header + 8-byte Fragment Header) to allow a 1500-byte IPv4 packet to traverse without fragmentation in the common translation case. One potential risk specific to multi-domain is Path MTU Discovery reliability. An ICMPv6 Type 2 (Packet Too Big) message from a P router in one IPv6 carrier's AS has to reach the originating IPv4 host across administrative boundaries with independent ICMP-filtering policies. In this case, IPv4 hosts may not receive "Packet Too Big" notifications, and will keep trying to send large packets. These packets will then be repeatedly dropped along the path, ultimately leading to connection interruptions or severe performance degradation -- forming a "PMTUD black hole." This issue has been mentioned in [RFC7915] Section 7. In this framework, ingress PEs MUST implement the complete behavior specified in [RFC7915]. To hand an ICMPv4 message to the IPv4 host, the ingress PE MUST translate ICMPv6 to ICMPv4 per [RFC7915] Sections 5.2 and 5.3 and synthesize an IPv4 source address for it -- a case for which [RFC7915] Section 6 points to [RFC6791]. 8. Manageability Considerations This section outlines manageability considerations for the framework, covering MR-DB monitoring, PE behavior upon rule withdrawal, and OAM considerations. These are presented as considerations rather than mandates, to be adapted by network operators based on their specific deployment requirements. 8.1. MR-DB Consistency Monitoring Each PE maintains a local MR-DB containing address mapping rules. The following capabilities are RECOMMENDED: Xie, et al. Expires 1 April 2027 [Page 20] Internet-Draft Framework for Multi-domain IPv6-only September 2026 * Each mapping rule should be identifiable by a version or timestamp to allow comparison of rule freshness across PEs. * PEs should be able to exchange MR-DB summary information to verify rule set consistency. * PEs should generate notifications upon significant MR-DB changes (addition, modification, or withdrawal of a mapping rule). * PEs should maintain counters for packets forwarded using each mapping rule to enable detection of anomalies (e.g., sustained high volume through a default rule may indicate missing explicit rules). * The MR-DB should be accessible via management interfaces (e.g., NETCONF/YANG) for query and audit purposes. 8.2. Behavior on Mapping Rule Withdrawal When a mapping rule is withdrawn, the following behaviors are RECOMMENDED: * The withdrawn rule should be removed immediately and not used for new packet conversions. * A configurable graceful period (on the order of seconds) may be supported for packets already in the forwarding pipeline to avoid disrupting established sessions. * If no explicit rule exists for a destination, the packet should be forwarded via the default mapping rule if configured; otherwise, it should be dropped and an ICMP/ICMPv6 error generated. * A notification should be generated upon rule withdrawal, including the affected IPv4 prefix and the reason. 8.3. OAM Requirements 8.3.1. ICMP/ICMPv6 Error Handling When a core P router generates an ICMPv6 error message destined to an IPv4-embedded IPv6 address, the message SHOULD be forwarded to the ingress PE identified by the source mapping prefix. Upon receiving such a message, the ingress PE SHOULD translate it to the corresponding ICMP message and forward it toward the original IPv4 source, in compliance with [RFC7915]. Inter-provider SLAs SHOULD permit such ICMPv6 messages to traverse administrative boundaries to avoid PMTUD black holes. Xie, et al. Expires 1 April 2027 [Page 21] Internet-Draft Framework for Multi-domain IPv6-only September 2026 8.3.2. Connectivity Verification Operators should be able to initiate diagnostic probes (e.g., ping, traceroute) from an ingress PE to an IPv4 destination behind a remote egress PE. These tools should support tracing the full path across the IPv6 underlay. Each PE should support a diagnostic mode to verify local translation functions using test packets. 8.3.3. Performance Monitoring The following metrics should be monitored at PE devices: * Conversion latency * Packet drop rate due to MR-DB lookup failures * Throughput per egress PE prefix Operators should establish baselines and alerts for significant deviations. 8.3.4. Cross-Domain Coordination For multi-domain deployments, the following coordination is RECOMMENDED: * Inter-provider SLAs should include provisions for ICMPv6 traversal across administrative boundaries and cooperative troubleshooting. * Out-of-band communication channels should be established for coordinating on inter-domain issues. * PEs should report the reachability and health of their mapping rules to a central management system for unified monitoring. 9. Security Considerations Besides regular security checks on configured address mapping rules, the following aspects need to be considered. 9.1. Authenticity and Integrity of Packets In this framework, as the receiver of IPv4-embedded IPv6 packets, each egress PE assumes that all ingress PEs are legal and authorized to send IPv4-embedded IPv6 packets to it. After the egress PE receives IPv4-embedded IPv6 packets, it converts them into IPv4 packets and forwards them into the IPv4 Internet. If IPv6 packets cannot guarantee their authenticity or integrity, then there may be a Xie, et al. Expires 1 April 2027 [Page 22] Internet-Draft Framework for Multi-domain IPv6-only September 2026 spoofing attack. A malicious ingress PE could send IPv6 packets converted from IPv4 packets to attack an egress PE. Since the PEs in this framework are stateless, even when receiving large-volume traffic flows, they will not increase mapping session counts within the device like a stateful NAT device would. Even if no per-flow state exists, it should be acknowledged that in some extreme cases PEs can possibly be overwhelmed by bandwidth exhaustion, packet-rate/ CPU exhaustion, MR-DB lookup pressure, or queue/buffer exhaustion. To mitigate these issues, measures such as rate limiting, ACLs between PEs, or provision validation can be applied for actual deployment. Source address validation at the egress PE is described in Section 9.2. 9.2. Source Address Validation As stated in Section 5.1 of [RFC6052], an attacker could use an IPv4-embedded IPv6 address as the source address of malicious packets. After translation, the packets will appear as IPv4 packets from the specified source, and the attacker may be hard to track. If left without mitigation, the attack would allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses. To prevent source-address spoofing, an egress PE SHOULD validate the IPv6 source of IPv4-embedded IPv6 packets. In particular, it SHOULD accept such a packet only if: * the IPv6 source is formed from the mapping prefix of an authorized ingress PE; * the embedded IPv4 source is consistent with the mapping rule or policy assigned to that ingress PE; and * the packet arrived from the expected participating network. This validation can be implemented using reverse-path checks (e.g., uRPF) and/or policy checks against the ingress PE's advertised mapping rule, and can be performed statelessly. Packets that fail validation SHOULD be discarded and, where appropriate, logged or counted for operational purposes. Mapping prefixes SHOULD be filtered at the framework boundary to prevent external spoofing. The analysis of these security risks can be found in [RFC6052] Sections 5.1 and 5.3, and in BCP 38 [RFC2827]. Xie, et al. Expires 1 April 2027 [Page 23] Internet-Draft Framework for Multi-domain IPv6-only September 2026 9.3. Stateless IP/ICMP Translators In this framework, the Stateless IP/ICMP Translation Algorithm is used to translate between IPv4 and IPv6 packet headers. As stated in Section 8 of [RFC7915], the use of stateless IP/ICMP translators does not introduce any new security issues beyond the security issues that are already present in the IPv4 and IPv6 protocols and in the routing protocols that are used to make the packets reach the translator. Other security considerations can be found in [RFC6052]. 9.4. Address Mapping Rule Distribution The distribution of address mapping rules over an IPv6-only network may use various protocols, each with their own inherent vulnerabilities. For example, when a routing protocol is used for rule distribution, attackers may alter the IPv6 mapping prefix within these rules, leading to improper delivery of IPv4 service traffic over an IPv6-only network. Such an attack differs from pre-existing vulnerabilities in that traffic could be forwarded to a remote target across an intervening network infrastructure (e.g., an IPv6 core), allowing an attack to potentially succeed more easily since less infrastructure needs to be compromised. To mitigate this risk, the distribution mechanism MUST support origin authentication, and PE devices MUST reject unauthorized mapping rules, as described in Section 5.2.2. This framework proposes a default rule 0.0.0.0/0: Pref6(PE), which sends unknown IPv4 traffic (i.e., IPv4 traffic without definite IPv6 address mapping rule) to a "default egress PE". This approach has obvious implications, such as traffic attraction (posing a DoS concentration risk) and becoming a "catch-all" hijack target if rule distribution is compromised. Where a default address mapping rule is used, it MUST NOT be advertised across an administrative boundary unless the participating network operators have an explicit bilateral agreement covering its use. Operators using a default egress PE should apply monitoring and rate-limiting or ACLs on that PE. Xie, et al. Expires 1 April 2027 [Page 24] Internet-Draft Framework for Multi-domain IPv6-only September 2026 After the default egress PE translates, the recovered IPv4 packet carries no indication that it has already traversed the framework once, and it is forwarded on that PE's IPv4 routing information. If that PE's best IPv4 path for the destination points back toward another participating PE -- entirely possible where the default egress PE's IPv4 view is partial, or where two network operators each treat the other as their default -- the packet is mapped again and the cycle repeats. To prevent these potential routing loops, a default egress PE MUST have a complete IPv4 forwarding view for the traffic it attracts, and MUST NOT resolve traffic received via the framework back onto a path that re-enters the framework. It is worth noting explicitly that TTL and hop limit handling bounds the loop but does not prevent it. 10. IANA Considerations This document has no IANA action. 11. Acknowledgements The authors would like to thank Brian E. Carpenter, Mohamed Boucadair, Bob Harold, Fred Baker, Xipeng Xiao, Giuseppe Fioccola, Vasilenko Eduard, Zhenbin Li, Jen Linkova, Ron Bonica, Shuping Peng, Jingrong Xie, Eduard Metz, Wu Qin, Dhruv Dhody, Nick Buraglio, Linda Dunbar, Weiqiang Cheng, Aijun Wang, Daryll Swer, Tim Wicinski, David 'equinox' Lamparter, Tianran Zhou and Huaimo Chen for their review and comments. The authors would also like to thank the IESG reviewers -- Ketan Talaulikar, Gunter Van de Velde, Eric Vyncke, Gorry Fairhurst, Mike Bishop, Roman Danyliw, and Christopher Inacio -- for their thorough reviews and constructive comments that significantly improved this document. 12. Contributors * Guoliang Han, Indirection Network Inc., China (guoliang.han@indirectionnet.com) * Ruoyu Zhao, Xiong’an Tianchuang, China (ruoyu.zhao@tciot.cn) 13. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Xie, et al. Expires 1 April 2027 [Page 25] Internet-Draft Framework for Multi-domain IPv6-only September 2026 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, . [RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. Huston, "Stateless Source Address Mapping for ICMPv6 Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012, . [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 14. Informative References [I-D.ietf-v6ops-ipv6-only] Palet Martinez, J.P., "IPv6-Only and IPv6-Mostly Terminology Definitions", Work in Progress, Internet- Draft, draft-ietf-v6ops-ipv6-only-02, 11 September 2026, . [IAB-statement] Internet Architecture Board, "IAB statement on IPv6", November 2016, . [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, . Xie, et al. Expires 1 April 2027 [Page 26] Internet-Draft Framework for Multi-domain IPv6-only September 2026 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, . [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, . [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, . [RFC6992] Cheng, D., Boucadair, M., and A. Retana, "Routing for IPv4-Embedded IPv6 Packets", RFC 6992, DOI 10.17487/RFC6992, July 2013, . [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, . [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, DOI 10.17487/RFC7599, July 2015, . [RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima, "Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May 2019, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. Patel, "Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop", RFC 8950, DOI 10.17487/RFC8950, November 2020, . Xie, et al. Expires 1 April 2027 [Page 27] Internet-Draft Framework for Multi-domain IPv6-only September 2026 [RFC9313] Lencse, G., Palet Martinez, J., Howard, L., Patterson, R., and I. Farrer, "Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)", RFC 9313, DOI 10.17487/RFC9313, October 2022, . Authors' Addresses Chongfeng Xie China Telecom Beiqijia Town, Changping District Beijing 102209 China Email: xiechf@chinatelecom.cn Chenhao Ma China Telecom Beiqijia Town, Changping District Beijing 102209 China Email: machh@chinatelecom.cn Xing Li CERNET Center/Tsinghua University Shuangqing Road No.30, Haidian District Beijing 100084 China Email: xing@cernet.edu.cn Gyan Mishra Verizon Inc. Email: gyan.s.mishra@verizon.com Thomas Graf Swisscom Binzring 17 CH-8045 Zurich Switzerland Email: thomas.graf@swisscom.com Xie, et al. Expires 1 April 2027 [Page 28]