v6ops Working Group C. Xie Internet-Draft C. Ma Intended status: Informational China Telecom Expires: 31 May 2026 X. Li CERNET Center/Tsinghua University G. Mishra Verizon Inc T. Graf Swisscom 27 November 2025 Framework for Multi-domain IPv6-only Underlay Network and IPv4-as- a-Service draft-ietf-v6ops-framework-md-ipv6only-underlay-15 Abstract 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. This document introduces a framework for a multi-domain IPv6-only underlay network from the perspective of network operators. In particular, it proposes stateless address mapping as the basis for enabling IPv4 service data transmission in a multi-domain IPv6-only environment (i.e., IPv4-as-a-Service). It describes the methodology of stateless IPv4/IPv6 mapping, illustrates the behaviors of network devices, analyzes the options of IPv6 mapping prefix allocation, and discusses the security considerations. This framework is not intended to replace existing IPv6-only technologies, but rather to leverage or remain compatible with them. 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 31 May 2026. Xie, et al. Expires 31 May 2026 [Page 1] Internet-Draft Multi-domain IPv6-only Underlay November 2025 Copyright Notice Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IPv6-only Deployment in Multi-domain Network . . . . . . . . 5 4. IPv4/IPv6 Address Mapping for IPv4-as-a-Service . . . . . . . 7 4.1. IPv4/IPv6 Address Mapping . . . . . . . . . . . . . . . . 7 4.2. End-to-End IPv4 Service Delivery . . . . . . . . . . . . 9 5. Framework Introduction . . . . . . . . . . . . . . . . . . . 10 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Address Mapping Rule Processing . . . . . . . . . . . . . 10 5.3. Packet Conversion and Transmission . . . . . . . . . . . 11 6. IPv6 Mapping Prefix Allocation . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.1. Authenticity and Integrity of Packets . . . . . . . . . . 14 7.2. BGP-4 and Multiprotocol Extensions for BGP-4 . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction IPv6 capabilities have been widely deployed over the past decade, with IPv6 traffic growing at a faster rate than IPv4. As of 2022, most IPv6 deployments rely on dual-stack [RFC4213]. However, dual- stack has long-term drawbacks, including duplicated network resources and states, as well as increased operational complexity from maintaining both protocol stacks. For instance, when broadband users experience access service failure, Network Providers (NPs) must Xie, et al. Expires 31 May 2026 [Page 2] Internet-Draft Multi-domain IPv6-only Underlay November 2025 determine whether the failure stems from IPv4 or IPv6, effectively doubling the troubleshooting effort. Once IPv6 adoption becomes dominant, transitioning to IPv6-only can reduce resource overhead and simplify operations. 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 after IPv4 address exhaustion, NPs must deploy IPv6 while maintaining access to the global IPv4 Internet-commonly referred to as IPv4-as-a-Service, which is a logical approach for IPv6-only networks. The network infrastructure of large NPs typically consists of at least an access section and a backbone section. The access section serves customer by delivering access links, assigning addresses, and enabling two-way data transmission. The backbone section, also known as the backbone network, is typically a multi-domain network comprising interconnected autonomous systems (ASes), each with a full-mesh or partial-mesh topology. The backbone network is sometimes referred to as the underlay network. Accordingly, IPv6-only deployment involves two key sections: IPv6-only in the access section and IPv6-only in the backbone section. For the IPv6-only deployment in the access section, to date 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 allocate only IPv6 addresses to customer terminals or networks, addressing IPv4 address exhaustion on the user side while enabling access to both IPv4 and IPv6 Internet services. [I-D.ietf-v6ops-6mops] describes a deployment scenario termed as "an IPv6-Mostly network", where IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc.). It allows IPv6-capable devices to remain IPv6-only while the network is seamlessly supplying IPv4 access to those that require it. However, the current IPv6-only ecosystem remains incomplete, particularly in backbone networks. For large-scale network NPs, a comprehensive multi-domain IPv6-only framework is needed to integrate multiple related technologies to ensure seamless IPv4 and IPv6 data transmission. A key objective is to enable efficient IPv4 service delivery across a multi-domain IPv6-only network, utilizing tunneling or translation to forward data between edge PE devices. 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. In addition, there should be no IPv4-to-IPv6 conversion gateway along the data path. Xie, et al. Expires 31 May 2026 [Page 3] Internet-Draft Multi-domain IPv6-only Underlay November 2025 Unless otherwise stated, the term “IPv6-only network” in this document refers specifically to “IPv6-only underlay network”. This document presents a framework for building a large-scale IPv6-only network from the perspective of network operators. As it is described at a high level, this framework is not meant to replace existing IPv6-only technologies but rather to leverage and remain compatible with them, nor does it propose any new IPv6 transition mechanisms or IPv4-as-a-Service solutions. When transmitting IPv4 service data, this framework enables end-to-end tunneling or translation across multiple network providers, and therefore is different from existing SRv6/MPLS VPN solutions which are for a single NP. It also differs from "IPinIP" tunneling in that this approach includes a control plane, whereas "IPinIP" does not. 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. 2. Terminology The following terms are used in this document: * AS: Autonomous System. * CE: Customer Equipment. * DC: Data Center. * IPv4-embedded IPv6 address: IPv6 address used to represent IPv4 nodes in an IPv6 network. This address includes a 32-bit embedded IPv4 address and is also referred to as IPv6-mapped addresses ([RFC6052]). * IPv4-embedded IPv6 packet: An IPv6 packet created through encapsulation or translation of an IPv4 packet, where the source and destination IPv4 addresses are statelessly mapped to corresponding IPv6 addresses. * Multi-domain IPv6-only underlay network: IPv6-only underlay network which consists of multiple ASes operated by single or multiple network providers. * MR-DB: Mapping Rule DataBase. Xie, et al. Expires 31 May 2026 [Page 4] Internet-Draft Multi-domain IPv6-only Underlay November 2025 * NP: Network Provider. * NSP: Network-Specific Prefix. * P: Provider Router. * PE: Provider Edge (Section 5.2 of [RFC4026]). * UE: User Equipment, e.g., mobile phone. * WKP: Well-Known Prefix. 3. IPv6-only Deployment in Multi-domain Network This framework is designed to assist large NPs in deploying IPv6-only in a multi-domain network. Large-scale NPs usually manage network infrastructure comprising multiple interconnected Autonomous Systems (ASes). This is referred to as a "Multi-domain Underlay Network" in this document. These ASes often support different functions, such as metro area networks (MANs), backbone networks, 4G/5G mobile core networks, Data Centers (DCs), and may be administered by separate departments or NPs 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 should support access to IPv4-only services, as well as native 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 NPs, Figure 1 shows a multi-domain network, namely NP-1, which consists of three interconnected ASes, i.e., AS1, AS2, and AS3. Among them, AS1 and AS2 are operated by NP-1, AS3 is operated by NP- 2. Routers located outside the backbone but directly connected to it are referred to as Customer Edge (CE) routers. AS1 of NP-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 Xie, et al. Expires 31 May 2026 [Page 5] Internet-Draft Multi-domain IPv6-only Underlay November 2025 external data centers. A multi-domain network must facilitate these data center connections. Network NP-1 should 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, NP-3 is a neighbor of NP-2. AS4 of NP-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 | | / | | | | | | | | | \ NP-3/ +----+ |/ \ / \ / | | \ / | +---+ | +-+ +-+ | | +-+ | +----+ /| | | | |UE/ | / | NP-1 | | NP-2 | |CE3 |/ | | | | +----+ | | | | \-------------------------/ \--------------/ Figure 1. An Example of Multi-domain Underlay Network Xie, et al. Expires 31 May 2026 [Page 6] Internet-Draft Multi-domain IPv6-only Underlay November 2025 For network NP-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. In such cases, IPv6 packets converted from IPv4 packets may need to revert to IPv4 at the egress of one AS, then back to IPv6 in the next AS. The number of conversion gateways increases with the number of ASes. An excessive number of IPv4-IPv6 conversion gateways introduces network complexity and increases capital expenditures (CAPEX). 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 unifed 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. Network NP-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. 4. IPv4/IPv6 Address Mapping for IPv4-as-a-Service 4.1. IPv4/IPv6 Address Mapping To support IPv4-as-a-Service in a multi-domain IPv6-only network, the framework proposes each PE device to be allocated and identified by at least one IPv6 mapping prefix, denoted by Pref6(PE). 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 between an IPv4 address block and its corresponding IPv6 prefix is called an address mapping rule, which can be represented at a minimum by the following data structure. IPv4 address block: Pref6(PE) Note that the address mapping rule contains not only the data structure described above, but also other necessary information to support IPv4 service delivery over the IPv6-only network. The detailed structure definition of the address mapping rule is out of the scope of this document. Xie, et al. Expires 31 May 2026 [Page 7] Internet-Draft Multi-domain IPv6-only Underlay November 2025 The address mapping rule of destination address will determine the direction of IPv4 service data transmission in a multi-domain IPv6-only network. 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 its IPv4 source and destination address as below, * The IPv6 source address is derived by appending the IPv4 source address to its local IPv6 mapping prefix, i.e., Pref6(ingress PE). * The IPv6 destination address is derived by appending the IPv4 destination address to the Pref6(egress PE) in its address mapping rule. Since the address mapping rule adopts prefix-level mapping, there is no need to maintain user-related status or translation tables for packet transformation at the PE devices. [RFC6052] illustrates the algorithmic translation of an IPv4 address to a corresponding IPv6 address, and vice versa, using only statically configured information. With this approach, IPv4-embedded IPv6 addresses are composed by concatenating the prefix, the 32 bits of the IPv4 address, and the suffix (if needed) to obtain a 128-bit address. The prefixes can only have one of the following lengths: 32, 40, 48, 56, 64, or 96. For IPv4 service delivery across a multi-domain IPv6-only network, it is proposed that IPv4 address is located at the last 32 bits of the IPv6 address, most significant bits first. The bits between IPv6 mapping prefix and IPv4 address can be set to zero and are reserved for future extensions. Examples of such representations are presented in Table 1. +-------------------+------------+--------------------------+ |IPv6 mapping prefix|IPv4 address|IPv4-embedded IPv6 address| +-------------------+------------+--------------------------+ |2001:db8::/32 |192.0.2.33 |2001:db8::192.0.2.33 | |2001:db8:100::/40 |192.0.2.33 |2001:db8:100::192.0.2.33 | |2001:db8:122::/48 |192.0.2.33 |2001:db8:122::192.0.2.33 | +-------------------+------------+--------------------------+ Table 1. Text Representation of IPv4-Embedded IPv6 Address Xie, et al. Expires 31 May 2026 [Page 8] Internet-Draft Multi-domain IPv6-only Underlay November 2025 Prior to IPv4/IPv6 packets conversion, an ingress PE needs to obtain the address mapping rule for the destination address within or across domains. To meet this requirement, specific mechanism of address mapping rule exchange needs to be designed, so an egress PE can inform other PEs that a IPv4 packet with a destination address being within a specific IPv4 address block should be forwarded to itself directly. 4.2. End-to-End IPv4 Service Delivery To enable IPv4 service data forwarding in a multi-domain IPv6-only network, IPv4 packets must be converted to IPv6 packets-either at the UE/CE or at the edge PE of the network. Consider the network case of Section 3, when an ingress PE, e.g., PE1, receives an IPv4 packet (destined for a remote IPv4 network, e.g., NP-3) from a client-facing interface, it queries its mapping rule database (i.e., MR-DB) to find the rule that best 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 NP-1, while the egress PE (PE3) is in AS2 of NP-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 NP-3 based on the IPv4 routing table maintained at PE3. In this case, the IPv6 data path is between PE1 and PE3, there are only two IPv4-IPv6 conversion actions, which occur in PE1 and PE3 respectively, as shown in Figure 2. IPv6 Data Path |----------------------------------->| | | | +--+ +--+ +--+ | | / \ / \ / \ | +--+ +----+ | | AS1 | | AS2 | | AS3 | | / \ |UE/ |-----PE1 P1---P2 P3---P4 PE3---| IPv4 | |CE | | IPv6 | | IPv6 | | IPv6 | \ NW / +----+ \ / \ / \ / +--+ +--+ +--+ +--+ 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 network edges of network providers. Xie, et al. Expires 31 May 2026 [Page 9] Internet-Draft Multi-domain IPv6-only Underlay November 2025 It can be seen that such a multi-NP tunneling requires only two-end NPs to support this solution for it to work, it has no specific requirements for NPs in the middle of the path, as long as it supports IPv6. 5. Framework Introduction 5.1. Overview 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 should support the following functions: 1. Address Mapping Rule Processing * Generate and manage the address mapping rules * Exchange the address mapping rules across IPv6-only network 2. Packet Transformation * Generate IPv4-embedded IPv6 packets using either translation or encapsulation There are no specific requirements to the P devices. 5.2. Address Mapping Rule Processing Within PE devices, IPv4/IPv6 address mapping rules are processed at the control layer, which includes two processes, 1. Address Mapping Rule Generation and Management 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 BGP route advertisement from an IPv4 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 supports rule management operations, such as insertion, modification, and deletion of address mapping rules. Xie, et al. Expires 31 May 2026 [Page 10] Internet-Draft Multi-domain IPv6-only Underlay November 2025 If the address mapping rule of a certain IPv4 address block has not been received by the ingress PE, the IPv4 service data destined to that IPv4 address block will not be forwarded to the right egress PE. To mitigate this issue, the framework introduces a default egress PE, which advertises an default address mapping rule to all other PEs. The format of the default address mapping rule is as follows: 0.0.0.0/0: Pref6(PE) With the availability of a default egress PE, the ingress PE can deliver the IPv4 packets to the default egress PE when it does not obtain the address mapping rule for that IPv4 address block. 2. Address Mapping Rule Exchange The address mapping rules generated at one PE device need to be sent to other PE devices, this process can be implemented through the routing layer. When an address mapping rule is generated locally, the PE device will convert it into a data structure and forwards it to the IPv6 routing engine for transmission. In the opposite direction, upon receiving a routing announcement with an address mapping rule from a neighboring IPv6 router, the PE device extracts and stores it in its MR-DB. To enable address mapping rule transmission at the routing layer, extensions to MP-BGP or other protocols would be required, a typical approach is illustrated in [I-D.ietf-idr-mpbgp-extension-4map6]. It should be noted that address mapping rule exchange can be implemented by non-routing mechanisms as well, however, this is outside the scope of this document. Based on the address mapping rule received, the egress PE can be visible to the ingress PE. 5.3. Packet Conversion and Transmission In this framework, the forwarding layer of PE devices provides data forwarding capability to IPv4-embedded IPv6 packets. IPv4-embedded IPv6 packets can be generated using either translation or encapsulation for IPv4 data delivery. 1. Translation Translation refers to the packet conversion from one protocol format to the other. When the ingress PE receives an IPv4 packet from its neighbouring IPv4 network, it queries the local MR-DB Xie, et al. Expires 31 May 2026 [Page 11] Internet-Draft Multi-domain IPv6-only Underlay November 2025 which stores all the address mapping rules, if an address mapping rule for the IPv4 destination address is found, it will generate corresponding IPv6 source and destination addresses from the IPv4 addresses, following the procedure described in Section 4.1. This process should comply with [RFC7915]. Upon receiving the IPv6 packet, the egress PE checks whether the destination IPv6 prefix matches its own IPv6 mapping prefix. If not, it discards it or forwards it as a regular IPv6 packet. Otherwise, the egress PE extracts the original IPv4 source and destination addresses from the IPv4-embedded IPv6 addresses and reconstructs the original IPv4 packet, this process should comply with [RFC7915]. The IPv4 packet is then forwarded based on the IPv4 routing information maintained at the egress PE. 2. Encapsulation The address mapping process for encapsulation follows the same procedure as translation: When the ingress PE receives an IPv4 packet from its neighbouring IPv4 network, it queries the local MR-DB which stores all the address mapping rules, if an address mapping rule for the IPv4 destination address is found, the ingress PE will generate corresponding IPv6 source and destination addresses from the IPv4 addresses, following the procedure described in Section 4.1. Upon receiving the IPv6 packet, the egress PE checks whether its destination IPv6 prefix matches its own IPv6 mapping prefix. If not, it discards it or forwards it as a regular IPv6 packet. Otherwise, the egress PE decapsulates it by removing outer IPv6 header and restores the original IPv4 packet. The IPv4 packet is then forwarded based on the IPv4 routing information maintained at the egress PE. For IPv4-embedded IPv6 packets, regardless of whether translation or encapsulation is used, 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. In summary, both translation and encapsulation rely on the same control-plane mechanisms (the MR-DB and address mapping rules) and impose identical requirements on the IPv6-only core network (forwarding based on the Pref6 part of the destination address). Although this document illustrates the framework for a multi-domain IPv6-only network operated by multiple NPs, this framework is also applicable to IPv6-only network operated by single NP. Xie, et al. Expires 31 May 2026 [Page 12] Internet-Draft Multi-domain IPv6-only Underlay November 2025 6. IPv6 Mapping Prefix Allocation As shown in Section 4.1, for any IPv4 address blocks, IPv6 mapping prefixes are needed to generate their corresponding address mapping rules, there are two options to allocate IPv6 mapping prefixes: 1) Well-Known Prefix (WKP) A specific WKP can be allocated from the global IPv6 address prefix, e.g., 64:ff9b::/96, or an IPv6 address prefix specifically assigned for this purpose. Pros: This can offer two key advantages. First, NPs are not required to dedicate IPv6 address prefixes from their own resources for mapping IPv4 addresses. Second, they can easily control the range of IPv6 mapping routes, such as applying routing restrictions at network boundaries to prevent leakage into external networks. Cons: When the PE device converts an IPv4 address to an IPv6 address using a Well-Known Prefix, the IPv4 portion of the IPv4-embedded IPv6 address is used for routing the packet. Consequently, multiple specific routes with prefix longer than /96 may be inserted into the FIB of P routers in an IPv6-only network. However, most operators do not install any specific routes with prefix longer than /96 in their networks. 2) Network Specific Prefix (NSP) NSP refers to a dedicated IPv6 prefix (or a set of prefixes) assigned from NP's available IPv6 address pool for IPv4 addresses mapping, in this case, one or more distinct IPv6 mapping prefix are assigned to each PE router. Pros: This approach will unlikely introduce new routing entries or impact the global IPv6 routing system. The IPv6 mapping prefix is part of a larger and routable IPv6 address block assigned to the PE device, so it will be easily aggregrated into the larger IPv6 prefix. For any IPv4-embedded IPv6 packets, the P devices can forward them as regular IPv6 packets without requiring a specific FIB entry for each IPv6 mapping prefix. Xie, et al. Expires 31 May 2026 [Page 13] Internet-Draft Multi-domain IPv6-only Underlay November 2025 Cons: None identified so far. As specified in Section 4.1, each PE must be assigned at least one IPv6 mapping prefix. This prefix serves as the fundamental information for forwarding IPv4-embedded IPv6 packets to the correct egress PE. Operators should carefully determine the IPv6 mapping prefix length during implementation. It is recommended that all IPv6 mapping prefixes have the same length to avoid unnecessary processing cost and complexity introduced by prefix length diversity. 7. Security Considerations Besides regular security checks on configured address mapping rules, the following two aspects need to be considered. 7.1. Authenticity and Integrity of Packets In this framework, as the receiver of IPv4-embedded IPv6 packets, each egress PE assume 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 will transform them into IPv4 packets and forward them into the IPv4 Internet. If IPv6 packets cannot guarantee their authenticity or integrity, then there may be a spoofing attack. A malicious ingress PEs could send IPv6 packets converted from IPv4 packets to attack an egress PE. Since the PEs in this framework are stateless, even when receiving massive traffic flows, they won't increase mapping session counts within the device like stateful NAT equipment would, thus avoiding significant consequences. 7.2. BGP-4 and Multiprotocol Extensions for BGP-4 The framework allows BGP protocol as one approach to propagate mapping information over an IPv6-only network. However, BGP has inherent vulnerability, such as route hijacking, where malicious alterations to routing announcements can redirect service traffic from its intended path or even steer it toward unauthorized destinations. Xie, et al. Expires 31 May 2026 [Page 14] Internet-Draft Multi-domain IPv6-only Underlay November 2025 When the capability to advertise address mapping rules via BGP is introduced, attackers may alter the IPv6 mapping prefix within these rules, leading to improper delivery of IPv4 service traffic over 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, [I-D.ietf-sidrops-moa-profile] proposes an approach by leveraging RPKI [RFC6480] architecture to verify the authenticity of the address mapping rule associated with an IPv4 address block. 8. IANA Considerations There are no other special IANA considerations. 9. 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. 10. Contributors Guoliang Han Indirection Network Inc. China Email: guoliang.han@indirectionnet.com Ruoyu Zhao Beijing TC Group China Email: api_zhao@126.com Linjian Song Alibaba Cloud China Email: linjian.slj@alibaba-inc.com Xie, et al. Expires 31 May 2026 [Page 15] Internet-Draft Multi-domain IPv6-only Underlay November 2025 11. References 11.1. 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, . [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, August 2003, . [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, . [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, . [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, . [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, . 11.2. Informative References Xie, et al. Expires 31 May 2026 [Page 16] Internet-Draft Multi-domain IPv6-only Underlay November 2025 [I-D.ietf-idr-mpbgp-extension-4map6] Xie, C., Dong, G., Li, X., Han, G., and Z. Guo, "MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement", Work in Progress, Internet-Draft, draft- ietf-idr-mpbgp-extension-4map6-04, 14 May 2025, . [I-D.ietf-sidrops-moa-profile] Xie, C., Dong, G., Li, X., Huston, G., and D. Ma, "A Profile for Mapping Origin Authorizations (MOAs)", Work in Progress, Internet-Draft, draft-ietf-sidrops-moa-profile- 02, 19 July 2025, . [I-D.ietf-v6ops-6mops] Buraglio, N., Caletka, O., and J. Linkova, "IPv6-Mostly Networks: Deployment and Operations Considerations", Work in Progress, Internet-Draft, draft-ietf-v6ops-6mops-04, 20 October 2025, . [IAB-statement] "IAB statement", . [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, . [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, . [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, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6992] Cheng, D., Boucadair, M., and A. Retana, "Routing for IPv4-Embedded IPv6 Packets", RFC 6992, DOI 10.17487/RFC6992, July 2013, . Xie, et al. Expires 31 May 2026 [Page 17] Internet-Draft Multi-domain IPv6-only Underlay November 2025 [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. M.-H., and M. Kawashima, "Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May 2019, . [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 Xie, et al. Expires 31 May 2026 [Page 18] Internet-Draft Multi-domain IPv6-only Underlay November 2025 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 31 May 2026 [Page 19]