| Internet-Draft | Multi-domain IPv6-only Underlay | April 2025 |
| Xie, et al. | Expires 7 October 2025 | [Page] |
For the IPv6 transition, IPv6-only is considered as the final stage, where only IPv6 protocol is used for transport while maintaining global reachability for both IPv6 and IPv4 services. This document illustrates a framework of multi-domain IPv6-only underlay network from an operator's perspective. In particular, it proposes stateless address mapping as the base for enabling IPv4 service data transmission in an 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, examines the utilization of SRv6, and discusses the security considerations.¶
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 7 October 2025.¶
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.¶
IPv6 capabilities have been widely deployed over the past decade, with IPv6 traffic growing at a faster rate than IPv4. [RFC9386] provides an overview of IPv6 deployment status and the progress of the transition to IPv6 among network operators and enterprises.¶
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, operators must determine whether the failure stems from IPv4 or IPv6, effectively doubling troubleshooting efforts. Once IPv6 adoption becomes dominant, transitioning to IPv6-only could 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, operators must deploy IPv6 while maintaining access to the global IPv4 Internet-commonly referred to as IPv4-as-a-Service (IPv4aaS)-a logical approach for IPv6-only networks.¶
The network infrastructure of large operators 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 usually a multi-domain network comprising interconnected autonomous systems (i.e., 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, several IPv6-only approaches have been developed within the IETF over the past two decades[RFC9313]. These methods employ different IPv4/IPv6 conversion techniques to deliver IPv4 services. For example:¶
464XLAT [RFC6877] is an IPv6 transition mechanism that enables IPv4 connectivity in IPv6-only networks. It combines client-side stateless NAT46 (CLAT) with provider-side stateful NAT64 (PLAT), allowing legacy IPv4 applications to operate without modification. 464XLAT has been commonly used in mobile networks.¶
MAP-T [RFC7599] and MAP-E[RFC7597] are stateless IPv6 transition technologies. MAP-T performs IPv4-IPv6 translation, while MAP-E uses encapsulation. Both employ algorithmic address mapping to enable IPv4 service delivery over IPv6 networks without maintaining per-flow state, suitable for broadband deployments.¶
DS-Lite [RFC6333] is also an IPv6 transition technology, enabling IPv4 communication over an IPv6 network, it combines IPv4-in-IPv6 tunneling with a centralized carrier-grade NAT (CGN), reducing the need for IPv4 addresses while maintaining compatibility.¶
These IPv6-only 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. To date, some operators have deployed 464XLAT in mobile networks and DS-Lite in wireline networks.¶
However, the current IPv6-only ecosystem remains incomplete, particularly in backbone networks, where IPv6-only solutions are nearly nonexistent. Existing implementations focus solely on the access segment, leaving backbone networks operating mainly in dual-stack mode, which falls short of full IPv6-only deployment requirements.¶
For large-scale network operators, a comprehensive multi-domain IPv6-only framework is needed to guide end-to-end deployment. Such a framework would integrate multiple technologies, including existing ones, to ensure seamless IPv4 and IPv6 data transmission. A key objective is enabling efficient cross-domain IPv6 and IPv4 service delivery, utilizing tunneling or translation to forward data between edge devices. 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, for any IPv4 traffic flow traversing a multi-domain IPv6-only network, there should be no IPv4-to-IPv6 conversion point along the data path.¶
This document presents a framework for building large-scale IPv6-only networks from a network operator's perspective. 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. Networks implemented under this framework can integrate with other IPv6-only access methods, minimizing unnecessary IPv4/IPv6 conversions.¶
Unless otherwise stated, the term “IPv6-only network” in this document refers specifically to “IPv6-only underlay network”. This document does not propose new IPv6 transition mechanisms or IPv4aaS solutions.¶
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.¶
The following terms are used in this document:¶
Multi-domain IPv6-only underlay network: IPv6-only underlay network which consists of multiple ASes operated by single or multiple operators.¶
AS: Autonomous System.¶
UE: User Equipment, e.g., mobile phone.¶
CE: Customer Equipment.¶
DC: Data Center.¶
IXP: Internet Exchange Point.¶
WKP: Well-Known Prefix.¶
NSP: Network-Specific Prefix.¶
P: Provider Router.¶
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 are 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.¶
ASBR: Autonomous System Boundary Router, a router that runs External Border Gateway Protocol(eBGP) and peering with the BGP routers of external ASes.¶
AFBR: Address Family Border Router, a router that supports both IPv4 and IPv6 address families and serves to provide transit services for the other in a backbone network (Section 1 of [RFC5565]).¶
ADPT: Adapter in PE, a function entity that implements the two-way IPv4 and IPv6 packet conversion for IPv4 service delivery over IPv6-only network.¶
Conversion point: A function that converts between IPv4 and IPv6 realms, such as the translation (XLAT) function defined in [RFC6144]¶
RAN: Radio Access Network.¶
Currently, the global Internet industry has not given a unified definition of an IPv6-only network. This document defines it as an IPv6-centric network where data packets are forwarded based on IPv6 capability. An IPv6-only network may interconnect with external networks, including IPv4-only networks.¶
As a general network infrastructure, an IPv6-only network should support the following scenarios,¶
Scenario 1: IPv6 user accessing an IPv4 server, i.e., an IPv6-only user accesses to an IPv4-based service hosted in a data center or other places.¶
Scenario 2: IPv4 user accessing an IPv4 server, i.e., an IPv4-only user accesses to an IPv4-based service hosted in a data center or other places.¶
Scenario 3: IPv6 user accessing an IPv6 server, i.e., an IPv6-only user accesses to an IPv6-based service hosted in a data center or other places.¶
Scenario 4: IPv4 user accessing an IPv6 server, i.e., an IPv4-only user accesses to an IPv6-based service hosted in a data center or other places.¶
Scenario 5: DC-to-DC, i.e., an IPv6-only network provides communications between servers hosted in different data centers, regardless of whether they are IPv4, IPv6 or IPv4/IPv6 dual-stack.¶
Scenario 6: Transit for neighbor networks, i.e., an IPv6-only network interconnects multiple isolated IPv4-only networks, enabling IPv4 packet transmission over the IPv6 infrastructure.¶
Scenario 7: Mobile transport network, mobile operators can utilize IPv6-only to connect the RAN and 5G core network, delivering the specific connectivity services required for 5G application operations.¶
It should be noted the scenarios listed above represent only a subset of those supported by IPv6-only networks, which are at least as capable as current dual-stack networks.¶
This framework is designed to assist large operators in deploying IPv6-only in a multi-domain network. Large-scale operators typically manage network infrastructure composed of multiple interconnected autonomous systems (ASes), that's why it called "Multi-domain Underlay Network". These ASes often support different functions, such as metro area networks (MANs), backbone networks, 4G/5G mobile core networks, DCs, and may be administered by separate departments or institutions with different routing and security policies. In a multi-domain network, 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.¶
To facilitate the illustrating the framework, this document first introduces an example of a multi-domain network from the perspective of operators. As shown in Figure 1, Network N1 is managed by operator NP-1 and consists of multiple interconnected Autonomous Systems (ASes), namely AS1, AS2, and AS3. N1 provides connectivity to various user types, including mobile, home broadband, and enterprise customers, represented by CE1, CE2, and CE3, respectively. Routers located outside the backbone but directly connected to it are referred to as Customer Edge (CE) routers. [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 must support cross-site communication, whether on-premises or in external data centers. A multi-domain network must facilitate these data center connections. Network N1 supports at least two connectivity modes for data centers: the first is the mode between data center and individual users, for instance, the user of CE1 accesses the service hosted in DC1, the second is the mode between data centers, for instance, communications between service instances hosted in DC1 and DC2 respectively.¶
Regarding external interconnection, NP-2 is a neighboring operator of NP-1. AS4 of NP-2 and AS3 of NP-1 are interconnected via BGP. AS4 is an IPv4-only network and does not support IPv6.¶
+-------+ +-------+
| DC1 | | DC2 |
+-------+ +-------+
| |
+----+ /-------|---------------------|--------\ (NP-2)
|UE/ |\ | | | | +---+
|CE2 | \ | | | | / \
+----+ \| PE2 +-+ PE5 | BR1 AS4 |
|\ / \ / \ / \ | / \ /
+----+ | \ | AS1 | | AS2 | | AS3 | | / +---+
|UE/ |---+- PE1 P1--P2 P3--P4 PE3---+-/
|CE1 | | / | | | | | | |
+----+ |/ \ / \ / \ / |
| +-+ +-+ PE4-------+-\ (NP-3)
+----+ /| | \ +---+
|UE/ | / | Multi-domain Network N1 | \ / \
|CE3 |/ | (NP-1) | BR2 AS5 |
+----+ | | \ /
\--------------------------------------/ +---+
Figure 1. An Example of Multi-domain Underlay Network¶
For network N1, transitioning from dual-stack to IPv6-only involves gradually disabling some or all IPv4 protocol instances, making IPv6 the primary network-layer protocol. Specifically, core P routers, such as P1, P2, P3 and P4, run only IPv6, while PE routers, such as PE1, PE2 and PE3, support IPv4 on interfaces facing IPv4 client networks and IPv6 on interfaces facing the core, requiring them to handle both address families. Network N1 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.¶
In addition, the IPv6-only deployment in network N1 must ensure the continued operation of remaining IPv4 services without degrading user experience. As some Internet services may remain IPv4-based even in an IPv6-dominated environment. Therefore, 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 IPv4aaS within a single AS.¶
For a multi-domain network operator, 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. With independent deployment in different domains, the network may contain multiple IPv4-IPv6 packet conversion points 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 domain. The number of conversion gateways increases with the number of ASes. Excessive IPv4-IPv6 conversion gateways introduce network complexity and higher 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.¶
To support IPv4aaS 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 devices 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 referred to as a mapping rule, which will have at least the following data structure.¶
IPv4 address block: Pref6(PE)¶
It should be noted that the mapping rule contains not only the data structure above, but also other necessary information to support IPv4 service delivery over IPv6-only network, the detailed structure definition of the mapping rule is out of the scope of this document.¶
The mapping rule of destination address will determine the direction of IPv4 service data transmission in a multi-domain IPv6-only network. When the 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 the mapping rule.¶
Since 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¶
Prior to IPv4/IPv6 packets conversion, the mapping rule for the destination address needs to be obtained remotely in advance. To meet this requirement, specific mechanism of mapping rule exchange needs to be designed, the exchange can be within or across domains. Using the mapping rule exchange mechanism, an egress PE can inform other PEs that an IPv4 packet with a destination address within the IPv4 address block of a mapping rule should be forwarded to the egress PE identified by the corresponding IPv6 mapping prefix. However, this has been beyond the scope of this document, and it will be addressed in other documents.¶
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 4, when one ingress PE, e.g., PE1, receives an IPv4 packet (destined for a remote IPv4 network, e.g., AS4) from a client-facing interface, it queries its mapping rule database (detailed later) in PE1 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 belong to different autonomous systems (ASes), the ingress PE1 resides in AS 1, while the egress PE3 is in AS 3. 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 based on the IPv4 routing table maintained at the egress PE. In this case, there are only two IPv4-IPv6 conversion actions, which occur in PE1 and PE3 respectively, the IPv6 data path for this process is between PE1 and PE3, as shown in Figure 2.¶
IPv6 Data Path
|<---------------------------------->|
| |
| +--+ +--+ +--+ |
| / \ / \ / \ | +--+
+----+ | | AS1 | | AS2 | | AS3 | | / \
|UE/ |-----PE1 P1---P2 P3---P4 PE3---| AS4 |
|CE | | IPv6 | | IPv6 | | IPv6 | \IPv4/
+----+ \ / \ / \ / +--+
+--+ +--+ +--+
Figure 2. End-to-end IPv4 Service Delivery from Ingress to Egress¶
To meet the above requirements, it is necessary to define a framework to describe the behavior of devices from the perspective of operators. In this framework, the PE is the key device, enabling stateless IPv4/IPv6 packet transformation to deliver IPv4 services in a multi-domain IPv6-only network. There is no specific requirements to the P devices. ADPT is the functional entity in the PE device that facilitates IPv4-to-IPv6 packet conversion. This section describes the ADPT components and interfaces from a network operations perspective. As illustrated in Figure 3, ADPT consists of the following components,¶
-RP: Rule Processing Layer¶
-RT: Rule Transport Layer¶
-DF: Data Forwarding Layer¶
Besides, there are interfaces of I1 I2, I3, I4, I5, I6, I7, and I8 in this framework. The functions of these components and interfaces will be introduced in the following sections.¶
+-----------------------------------------------+
| PE1 /------------\ | +-------+
| | ADPT | | |PE2 |
+-------+ | +-------+ | +-----+ | | | +---+ |
| | | |IPv4 | I3 | | | | I1 | | | | |
| +---+-+routing+------+------+ RP +-+------+--------+----+-+ RP| |
| | | |engine | | +---+ | | | | | | |
| | | +-------+ | | +--+--+ | | | +---+ |
| | | | | +I7 +I2 | | +---+---+
| | | | | | +--+--+ | +-------+ | |
| | | | |+--+ | | |I4 | IPv6 | | +---+---+
| R1 | | | ||MD| | RT +-+---+routing+---+----+ |
|(IPv4 | | | |+--+ | | | |engine | | | |
|Router)| | | | | +-----+ | +---+---+ | | R2 |
| | | | | +I8 | | | |(IPv6 |
| | | +----------+ | | +-----+ | +---+------+| |Router)|
| | | |IPv4 |I5 | +---+ | |I6 |IPv6 || | |
| +---+-+packet +---+------+ DF +-+---+packet ++----+ |
| | | |forwarding| | | | | |forwarding|| | |
+-------+ | +----------+ | +-----+ | +----------+| +-------+
| \____________/ |
+-----------------------------------------------+
RP: Rule Processing Layer
RT: Rule Transport Layer
DF: Data Forwarding Layer
MD: Mapping rule Database
Figure 3. Components and Interfaces of ADPT¶
The Rule Processing Layer (RP) manages the mapping relationships between IPv4 address blocks and their corresponding IPv6 prefixes.¶
Each PE contains a Mapping Rule Database (MD) that stores all mapping rule entries received from other PEs, as shown in Figure 3. The Rule Processing Layer manages the MD via Interface I7, supporting operations such as rule insertion, modification, and deletion. Interface I1 facilitates mapping rule exchange between PEs via their respective ADPTs. Interface I2 enables mapping rule transmission through the Rule Transport Layer (detailed in Section 6.3). PE1 extracts IPv4 address blocks from its IPv4 BGP routing instance using Interface I3, then generates device-specific mapping rules by combining them with its IPv6 mapping prefix. Once prepared, these rules are forwarded to the Rule Transport Layer via Interface I2. Conversely, PE1 receives mapping rules from other PEs through Interface I2 and stores them locally in its MD.¶
If certain IPv4 address blocks are not explicitly announced by any egress PEs to the ingress PE, the MD will lack corresponding mapping rules. To address this, the framework introduces a default egress PE, which advertises a default IPv6 mapping rule containing a default mapping prefix to all other PEs. The format of the default IPv4 address mapping rule is as follows:¶
0.0.0.0/0: Pref6(PE)¶
The Rule Transport Layer (RT) handles the exchange of mapping rules and associated routing information between PEs at the routing layer. Mapping rule exchange must occur before IPv4 data transmission begins; otherwise, IPv4 traffic packets will be dropped due to the lack of a corresponding IPv6 mapping prefix for the destination address.¶
Upon receiving a mapping rule transmission request from the Rule Processing Layer via Interface I2, the Rule Transport Layer (RT) converts the mapping rule into a data structure that is suitable for the transmission in the IPv6 routing system. The RT then forwards this formatted rule to the IPv6 routing engine through Interface I4. In the opposite direction, when the RT receives a routing update from the IPv6 routing engine via Interface I4, it extracts the embedded mapping rule and relays it to the Rule Processing Layer for further processing.¶
To enable mapping rule transmission at the routing layer, extensions to MP-BGP4 or other control protocols would be required. However, this has been out of the scope of the draft and will be discussed in other documents.¶
In this framework, Data Forwarding Layer, i.e., DF, provides data forwarding function to IPv6 packets, including native IPv6 packets and 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 Data Forwarding Layer receives an IPv4 packet via interface I5 from the IPv4 packet forwarding module, it queries the Mapping Rule Database(MD) through interface I8. If a mapping rule exists for the IPv4 destination address, the layer generates corresponding IPv6 source and destination addresses from the IPv4 addresses, following the procedure described in Section 5.1.¶
2. Encapsulation¶
Encapsulation refers to the process of adding an IPv6 header to the original IPv4 packet for transmission across the multi-domain IPv6-only network. The address mapping process for encapsulation follows the same procedure as translation: When receiving an IPv4 packet via interface I5 from the IPv4 forwarding module, the Data Forwarding Layer queries the Mapping Rule Database through interface I8. If a matching rule exists for the IPv4 destination address, the layer generates corresponding IPv6 source and destination addresses from the IPv4 addresses according to the procedure described in Section 5.1.¶
For IPv4-embedded IPv6 packets, the Pref6 portion of the destination address identifies the network egress, regardless of whether translation or encapsulation was used. Therefore, packet forwarding can be performed by P devices based solely on the Pref6 part of the destination address.¶
Although this document illustrates the framework of multi-domain IPv6-only network operated by a single operator, this multi-domain model can naturally be extended to IPv6-only network which is operated by multiple operators.¶
With this framework, a specific IPv6 address range, i.e., IPv6 mapping prefix, is used to represent an IPv4 address block by stateless mapping as illustrated in section 5.1, 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 for IPv6 mapping prefix allocation. First, operators 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 lengths greater than 96 may be inserted into the FIB of P routers in an IPv6-only network. However, most networks do not support such fine-grained routes with prefix lengths exceeding 96.¶
2) Network Specific Prefix (NSP)¶
NSP refers to a dedicated IPv6 prefix (or prefixes) assigned from operator's available IPv6 address pool to each PE for IPv4 addresses mapping. The assigned IPv6 mapping prefix differs per PE.¶
Pros:¶
In a multi-domain network, the length of the IPv6 mapping prefix can be adjusted to meet IPv6 routing requirements. The IPv6 mapping prefix is part of a larger and routable IPv6 address block assigned to the PE, so this approach is unlikely introduce new routing entries or impact the global IPv6 routing system. For IPv4-embedded IPv6 packet, the P devices can forward them in legacy manner without requiring a specific FIB entry for the mapping prefix.¶
Cons:¶
If the operator has not implemented specific address prefix planning and policy configuration, interworking between operators may result in the same IPv4 address block receiving multiple NSP prefixes from different operators. This can generate multiple IPv6 mapping routes, potentially increasing the size of IPv6 routing tables (including FIB and RIB).¶
As specified in Section 5.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. The length of all the IPv6 mapping prefixes is recommended to be the same, to avoid unnecessary processing cost and complexity induced by the prefix length diversity.¶
As mentioned before, the purpose of this framework is to guide operators IPv6-only deployment in multi-domain networks. It proposes to integrate multiple technologies, including SRv6[RFC8986], to ensure seamless IPv4 and IPv6 data transmission.¶
SRv6 enables a network operator to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. SRv6 can also utilize specific SID, i.e., DT4 or DX4, to transport IPv4 packets across IPv6-only networks from one PE to another, making it a candidate technology for building multi-domain IPv6-only network. However, there will be issues with SRv6 which may influence its actual utilization for this purpose. Firstly, due to security concerns, as mentioned in 'draft-ietf-spring-srv6-security', the current document assumes that SRv6 is deployed within a trusted domain, where one operator's SID cannot be manipulated by another operator's network devices,this may limit the joint deployment of IPv6-only by multiple operators. Another issue is that SRv6 uses SRH to carry SIDs, extension headers are often restricted by many operators due to various considerations, [RFC9098] mentions that "packets employing IPv6 extension headers are often dropped by network firewalls, either because of the challenges represented by extension headers or because the use of IPv6 extension headers has not been explicitly allowed." In addition, the actual deployment of SRv6 globally is not yet widespread, and many operators are just starting to deploy IPv6. These issues may become constraints for operators to use SRv6 to build multi-domain IPv6-only networks. Of course, if these issues are relieved, SRv6 can also be a good option for building IPv6-only network.¶
Besides regular security checks on configured mapping rules, the following two aspects need to be considered as well.¶
In this framework, for each egress PE, they assume that all ingress PEs are legal and authorized to convert the received IPv4 packets into IPv6 packets and send them into IPv6-only network. If IPv6 packets cannot guarantee its authenticity or integrity, then there may be a spoofing attack. Some faked ingress PEs can send IPv6 data converted from IPv4 to attack the egress PE. After the egress PE recovers the received IPv6 packets into IPv4 packets, they are routed based on the destination IPv4 address and enter the Internet. They use global IPv4 address, not private address, therefore, these attacks cannot cause payload packets to be delivered to an address other than the one appearing in the destination address field of the IP packet. Since the PE in this framework is stateless, the effect of the attack is limited.¶
The framework allows BGP to propagate mapping rule information over an IPv6-only underlay network, BGP is vulnerable to traffic diversion attacks. The ability to advertise a mapping rule adds a new means by which an attacker could cause traffic to be diverted from its normal path. Such an attack differs from pre-existing vulnerabilities in that traffic could be forwarded to a distant target across an intervening network infrastructure (e.g., an IPv6 core), allowing an attack to potentially succeed more easily since less infrastructure would have to be subverted. The security issues already exist in BGP-4 and MP-BGP for IPv6, the same security mechanisms are applicable.¶
There are no other special IANA considerations.¶
The authors would like to thank Brian E. Carpenter, 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, Nick Buraglio, David 'equinox' Lamparter, Tianran Zhou and Huaimo Chen for their review and comments.¶