Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service

IPv6 capabilities have been widely deployed during the past decade with IPv6 traffic growing faster than IPv4. provides an overview of IPv6 deployment status and how the transition to IPv6 is progressing among network operators and enterprises. As of 2022, most IPv6 deployments rely on dual-stack. Dual-stack does have a few disadvantages in the long run, like the duplication of the network resources and states and increased complexity for network operation to maintain both protocol stacks. For example, when broadband users accounter malfunctions in accessing services, network operators need to troubleshoot whether it is an IPv4 protocol failure or an IPv6 protocol failure, which increases the workload by at least twice. For those reasons, and when IPv6 usage has been dominant, it makes more sense to consider IPv6-only to reduce network resources and operational complexity. In 2016, the IAB announced that it "expects that the IETF will stop requiring IPv4 compatibility in new or extended protocols. Future IETF protocol work will then optimize for and depend on IPv6" . To guarantee the normal operation of the service after IPv4 address depletion, operators need to provide IPv6 services and preserve access to the global IPv4 Internet as a Service(i.e. IPv4aaS) is a natural consideration for IPv6-only network. Several IPv4 service continuity mechanisms have been designed within IETF during the past twenty years. For IPv4 service delivery, these approaches use different IPv4/IPv6 conversion methods. For instance, 464XLAT uses both stateless and stateful NAT64 translation, MAP-Eand MAP-T use stateless IPv4-IPv6 address translation for encapsulation and translation respectively. DS-Lite utilizes AFTR-based 4over6 tunneling approach. This document specifies the requirements for multi-domain IPv6-only underlay network and proposes a general framework for network operators. In such a multi-domain IPv6-only underlay network, the conversion between IPv4 and IPv6 packets is implementated through stateless address mapping at the edge devices, so that the remaining IPv4 services can still be accessed by users. The term "stateless" here refers to no need to maintain user-ralated status or translation tables for packet transformation at the edge devices. In addition, the network specified by this framework can be integrated with other existing IPv6-only access schemes, thereby reducing unnecessary IPv4/IPv6 conversions. The objective of such a framework is to help operators implement the transition to IPv6-only and support cross domain, end-to-end IPv6 and IPv4 service delivery in an efficienty way. In this document, the term of “IPv6-only network” stands for “IPv6-only underlay network”, unless there is a specific statement. This document does not introduce any new IPv6 transition mechanisms nor IPv4aaS.

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 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. UE: User Equipment, e.g., mobile phone. CLAT: Customer-side translator (Section 1 of ). CPE: Customer Premise Equipment. DC: Data Center. IXP: Internet Exchange Point. WKP: Well-Known Prefix. NSP: Network-Specific Prefix. P: Provider Router. PE: Provider Edge (Section 5.2 of ). IPv4-embedded IPv6 addresses: IPv6 addresses used to represent IPv4 nodes in an IPv6 network, 32 bits in the IPv6 addresses contain IPv4 addresses, also known as IPv6 mapping address(). IPv4-embedded IPv6 packet: IPv6 packet which is generated from IPv4 packet by statelessly mapping of the source and destination IPv4 addresses to IPv6 addresses. PLAT: Provider-side translator (Section 1 of ). ASBR: Autonomous System Boundary Router, which runs External Border Gateway Protocol(eBGP) and peering with the BGP routers of external ASes. AFBR: Address Family Border Router, which supports both IPv4 and IPv6 address families and serves to provide transit services for the other in a backbone network (Section 1 of ). ADPT: Adapter in PE, a function entity which implements the two-way IPv4 and IPv6 packet conversion for IPv4 service delivery over IPv6-only network. Conversion point: A function which provides conversion between IPv4 and IPv6 realms. This is, for example, the translation(XLAT) function in GUA: IPv6 Global Unicast Address (Section 3 of ).

Up to present the global Internet industry has not given a unified definition of IPv6-only network so far. This document defines such a notion as a IPv6-centric network in which data packets are forwarded upon IPv6 capability, IPv6-only network may interconnect with external networks, including IPv4-only networks. Generally, IPv6-only network should support the following scenarios, Scenario 1: IPv6 user to IPv4 server, i.e., IPv6-only user accesses IPv4 services hosted in data centers. Scenario 2: IPv4 user to IPv4 server, i.e., IPv4-only user accesses IPv4 services hosted in data centers. Scenario 3: IPv6 user to IPv6 server, i.e., IPv6-only user accesses IPv6 services hosted in data centers. Scenario 4: DC-to-DC, i.e., IPv6-only network provides communications between servers hosted in data centers, despite they are IPv4, IPv6 or IPv4/IPv6 dual-stack. Scenario 5: Transit for neighbor networks, i.e., IPv6-only network serves as an interconnection between several segregated IPv4-only networks, IPv4 packets are transported over the IPv6-only network between IPv4 networks. Scenario 6: IPv6-only eBGP Edge peering in IXP[I-D.ietf-bess-ipv6-only-pe-design], this serves to eliminate IPv4 provisioning at the edge of IXP that is facing IPv4 address depletion at large peering points. Scenario 7: 5G Transport service, SD-WAN, network slicing, etc. It should be noted that the scenarios above are only a subset of the scenarios that IPv6-only network will work for in the future.

For large-scale operators, their network usually comprise multiple inter-connected autonomous systems (ASes). Different ASes may serve different scenarios, such as Metro Area Network(MAN), backbone network, 4G or 5G mobile core network, data center and are often managed by different departments or institutions, using different routing and security policies. Using Figure 1 as an example, Network N1, belonging to and operated by operator 1, is composed of multiple inter-connected ASes(i. e. ,AS1, AS2 and AS3). N1 provides access to multiple types of users, including mobile, home broadband and enterprise customers, denoted by CPE1, CPE2 and CPE3 respectively. Routers that are outside the backbone but directly attached to it are known as “Customer Edge” (CE) routers. specifies the IPv4 service continuity requirements for IPv6 Customer Edge (CE) routers. Specifically, it extends the basic requirements for IPv6 CE routers to allow for delivering IPv4 in IPv6-only access networks. In addition, the service instances in data centers must be able to communicate across different sites, both on-premises and in data centers. Multi-domain network needs to provide connections for data center. Network N1 supports at least two connection modes of data centers, the first is the mode between data center and individual users, for instance, the user of CPE1 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 seperately. Multi-domain network discussed in this document is open, it is interworking with external networks. Operator 2 is one of the neighbor operators of operator 1, AS4 of operator 2 and AS3 of operator 1 are interconnected through BGP protocol. AS4 is an IPv4-only network, which means that it does not run IPv6 protocol. The edge nodes of the Network N1 are often known as “Provider Edge” (PE) routers. The term “ingress” (or “ingress PE”) refers to the router at which a packet enters the network, and the term “egress” (or “egress PE”) refers to the router at which it leaves the network. Interior nodes are often known as “P routers” (Provider Routers).

For one multi-domain IPv6-only network, transition to IPv6-only from dual-stack means some or all the IPv4 protocol instances of dual-stack network will be disabled gradually, thereby IPv6 will become the main network-layer protocol. To be specific, the P routers in the core only support IPv6, but the PEs support IPv4 on interfaces facing IPv4 client networks and IPv6 on interfaces facing the core, in this case, the PEs need to support both address families. Network N1 provides transport services for packets that originate outside the network and whose destinations are outside the network. These packets enter the IPv6 network at one of its PE routers. They are routed through the network to another PE router, at which they leave the IPv6-only network and continue their way. When IPv4 capability is disabled, the first question is how to make remaining IPv4 services running normally and users’ experience does not deteriorate. The deployment of IPv6-only should not be based on the premise of the extinction of all IPv4-only services, it is very possible that some portion of the Internet service will consistently be IPv4-based. In other words, IPv6-only network should not only carry native IPv6 services, but also allow users to reach IPv4-only services. describes the IPv4-over-IPv6 scenario, where the network core is IPv6-only and the interconnected IPv4 networks are called IPv4 client networks. The P Routers in the core only support IPv6, but the ASBRs support IPv4 on interfaces facing IPv4 client networks and IPv6 on interfaces facing the core. The routing solution defined in is to run IBGP among AFBRs to exchange IPv4 routing information in the core, and the IPv4 packets are forwarded from one IPv4 client network to the other through a softwire using tunneling technologies, such as MPLS, LSP, GRE, VXLAN, L2TPv3, etc. describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on and , 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 one multi-domain network, when IPv6-only scheme is deployed without any collaboration, different ASes adopt the IPv6 transition approach independently, the result is that multiple IPv6-only islands are connected by IPv4 links between domains. With indepent deployment in different domains, there will be multiple IPv4-IPv6 packet conversion gateways with different functions in the network. Under this circumstance, IPv6 packets converted from IPv4 packets need to be transformed back to IPv4 packets at the egress of one AS, and then back to IPv6 in the next domain, and the number of conversion gateways will increase along with the increasing of the number of ASes. Excessive IPv4-IPv6 conversion gateways lead to complexity of network and CAPEX increasing. Therefore, an overall framework is required to specify the behaviours of the network edge for IPv4 service delivery and eliminate unnecessary IPv4/IPv6 conversion gateways within the multi-domain network.

Native IPv6 traffic can be transported over an IPv6-only network following legacy procedures. In order to support IPv4 service continuity, the following requirements should be met by multi-domain IPv6-only network. Requirement 1: Beneficial to wider IPv6 adoption It should largely reduce IPv4 public address consumption and accelerate the deployment of IPv6, rather than prolonging the lifecycle of IPv4 by introducing multiple layers of NAT44. Requirement 2: No service degradation There should be no perceived degradation of customer experience when accessing the remaining IPv4 services. Requirement 3: Optimized end-to-end For any given IPv4 traffic flow, there should be no IPv4-IPv6 conversion point in the middle of the IPv6 data path when traversing multi-domain IPv6-only network, in other words, IPv4 packet should not appear in the middle of the IPv6 data path, the quantity of the conversion points should not exceed two. In addition, IPv6-only network should support the following two directions of IPv6 data path. -From UE to egress, the packets of IPv4 service can be translated (or encapsulated) into IPv6 packets within the UE or CPE, and there should be no IPv6/IPv4 conversion before they reach the egress of the network. -From ingress to egress, since the core of the network is IPv6-based, all IPv4 packets that reach the edge of the network will be transformed into IPv6 packets by the ingress and forwarded to the egress of the network. The end-to-end requirement should also be valid for DC-to-DC communications. Requirement 4: Support of double translation and encapsulation The data-plane has two approaches for traversing the IPv6 provider network: 4-6-4 translation and 4over6 encapsulation, at least one mode should be supported by the IPv6-only network, the core nodes do not distinguish between translation-based IPv6 packet and encapsulation-based IPv6 packet. At the egress, the PE can recover IPv4 packet by reading the next-header field of the packet. Moreover, translation mode and encapsulation mode should share the same IPv4-IPv6 address mapping algorithm. Note that the double translation can reduce to single translation, while the encapsulation cannot. At the ingress an IPv6 forwarding function is needed to forward IPv4 service data to the right egress network node (via encapsulation / translation) or right interface towards an external network. Requirement 5: User stateless at the border gateway Maintaining user status will consume great volume of storage and computation power, so it is generally stored or managed at the edge of network and close to the user side. It is unsuitable to store user-related status at the inter-connection points with external networks. The border ASBR that is interworking with external networks should be unaware of the user-related status, it only needs to perform stateless translation or encapsulation/decapsulation when necessary. Requirement 6: High scalability It should achieve high scalability, simplicity and availability, especially for large-scale operators. When PE processes IPv4-features at the edge of the network, the quantity of the IPv4-related status should not increase linearly or exponentially along with the quantity of the user or traffic. Considering this, it is better to adopt stateless mapping approach to avoid excessive status storage at the edge. It would also avoid overloading of the IPv6 routing table. Requirement 7: Incremental deployment It can be deployed in an incremental fashion and the overall transition process should be stable and operational. Requirement 8: No security compromise The technologies proposed must not introduce additional security compromise.

The framework described in this document is deliberately at a high level. It is not intended to be prescriptive, implementations and technical solutions may vary freely. To support the forwarding of IPv4 service data, multi-domain IPv6-only network needs to transform IPv4 packets into IPv6 ones in the UE/CPE or at the edge of the network. Take the latter case as an example, when IPv4 packets reach the edge of the lPv6-only network, the ingress PE, i.e., PE1, will convert them into lPv6 packets by translation or encapsulation and send them into IPv6 network. After intra-domain and cross-domain transmission, the IPv6 packets reach the egress PE, i.e., PE2, then be restored to IPv4 packets. In this process, the forwarding of IPv4 service data will follow the topology of IPv6 network. In the new framework proposed in this document, each PE device will be allocated and identified by at least one IPv6 mapping prefix, denoted by Pref6(PE), it 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 IPv4 address block and IPv6 mapping prefix is called 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 of the mapping rule is out of the scope of this document. The mapping rule of destination address will give the direction of IPv4 service data transmission in 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 is prefix-level mapping, there is no need to maintain user-ralated status or translation tables for packet transformation at the PE devices. 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 the IPv6-only deployment scenario in this document, 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 SHOULD be set to zero and are reserved for future extensions. Examples of such representations are presented in Table 1.

Prior to IPv4/IPv6 packets tranformation, the mapping rules need 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. However, this has been beyond the scope of this document, and it will be addressed in other document. Using the mechanism of mapping rule exchange, an egress PE can tell other PEs that IPv4 packet whose IPv4 destination address is within the scope IPv4 address block of the mapping rule, can be forwarded to the egress PE identified by the corresponding IPv6 mapping prefix of the mapping rule. 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.

In this framework, PE device is the key part and provides the statelessly IPv4/IPv6 packet transformation for IPv4 service delivery in a multi-domain IPv6-only network environment, there is no specific requirements to the P devices. This section illustrates the components and interfaces of ADPT in PE devices. ADPT is the entity in PE which accommodates the conversion of IPv4 packets into IPv6 ones for IPv4 service delivery over IPv6-only network. ADPT comprises the following components, as shown in figure 2.

The Rule Processing Layer, i.e., RP, deals with the management of mapping relationship between IPv4 address blocks and their IPv6 mapping prefixes. In each PE, there is a Mapping rule Database, i.e., MD, to store all the mapping rule entries it receive from other PEs, as shown in figure 2. Rule Processing Layer provides management functions to Mapping rule Database through interface I7, for example, insertion, modification, or deletion mapping rules. The interface with the ADPT of other PE is I1, which is used for the exchanging of mapping rule with each other. Interface I2, which is illustrated in section 6.2.2, is I2, is used for the transmission of mapping rule through Rule Transport Layer. PE1 can extract the IPv4 address blocks from its IPv4 BGP routing instance through interface I3, and generate the mapping rules of the device in combination with its own IPv6 mapping prefix. When the mapping rules are ready, they will be sent to Rule Transport Layer through interface I2. Correspondingly, PE1 will receive the mapping rules of other PEs through interface I2 and stores them in the local Mapping rule Database. For some IPv4 address blocks which are not announced explicitly by any egress PEs to the ingress PE, there will be no corresponding mapping rule in the Mapping rule Database. To solve this problem, the default egress PE is defined in this framework, which announces the default IPv6 mapping rule with the default mapping prefix to other PEs. The format of the mapping rule for default IPv4 address is as follows, 0.0.0.0/0: Pref6(PE)

Rule Transport Layer, i.e., RT, is in charge of the exchanging of mapping rule with other PEs and its related routing information at the routing layer. The exchanging of the mapping rule should precede to the process of IPv4 data transmission, otherwise, the data originated from IPv4 network will be dropped due to the absence of the IPv6 mapping prefix corresponding to its destination address. When the request of the mapping rule from Rule Processing Layer through interface I2 is being received, Rule Transport Layer will convert the mapping rule into data structure that is suitable for the transmission in the IPv6 routing system and send it to the IPv6 routing engine through interface I4. In opposite direction, when receiving the routing update from IPv6 routing engine through interface I4, Rule Transport Layer will extract mapping rule from the routing information and send it to the Rule Processing Layer. To support the transmission of mapping rules at the routing layer, MP-BGP4 protocol or other control protocols needs to be extended. However, this has been out of the scope of the draft and will be discussed in other documents.

Data Forwarding Layer, i.e., DF, provides data forwarding function to IPv6 packets, including native IPv6 packets and IPv4-embedded IPv6 packets. Multi-domain IPv6-only network needs to support both translation and encapsulation technologies for IPv4 data delivery: 1. Translation Translation refers to the conversion of IPv4 packet into IPv6 packet, then transmits it in the multi-domain IPv6-only network. When receiving an IPv4 packet through interface I5 from IPv4 packet forwarding module, the data forwarding layer will look up the Mapping rule Database through the interface I8, if the mapping rule corresponding to the IPv4 destination address is found, then it generates corresponding IPv6 source and destination addresses from its IPv4 source and destination address following the procedure illustrated in section 6.1. 2. Encapsulation Encapsulation is the process in which PE adds a new IPv6 header is to the original IPv4 packet received, then transmits it in the multi-domain IPv6-only network. Address mapping in encapsulation mode is same to that in translation mode, when receiving IPv4 packet through interface I5 from IPv4 packet forwarding module, the data forwarding layer will look up the Mapping rule Database through the interface I8, if the mapping rule corresponding to the IPv4 destination address is found, then it generates corresponding IPv6 source and destination addresses from its IPv4 source and destination address following the procedure illustrated in section 6.1. For an IPv4-embedded IPv6 packet, whether it is based on translation or encapsulation, the Pref6 part of the destination address can identify the egress in the network, so the forwarding of the IPv6 packet can be implemented based on the Pref6 part of the destination address.

With this framework, a specific IPv6 range is used to represent IPv4 address space by statelss mapping as with section 6.1, there are two options to allocate IPv6 mapping prefixes: 1) 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: Operators do not need to allocate IPv6 address prefixes specially used for mapping IPv4 addresses from their own IPv6 address resources. Secondly, operators can easily control the range of IPv6 mapping routes, such as implementing routing restrictions at the boundaries to prevent them from leaking into other networks. Cons: If the PE device converts the IPv4 address into IPv6 address with WKP, the IPv4 part of the IPv4-embedded IPv6 address is used for the routing of the IPv4-embedded IPv6 packet. For this reason, many fine routes with prefix length greater than 96 will be introduced into the FIB of P routers in IPv6-only network. In most networks, fine routes with long prefix length greater than 96 is not supported. 2) NSP Operator allocates a specific IPv6 prefix or prefixes from their existing IPv6 address resources to each PE for IPv4 addresses mapping. The IPv6 mapping prefix varies for different PEs. Pros: Within the multi-domain network, the length of IPv6 mapping prefix can be easily tailored to meet the requirements of IPv6 network for routing length, and the routing of the packets can be based on the IPv6 mapping prefix part of the IPv6 address. The IPv6 mapping prefix is inside a bigger IPv6 address block allocated to the PE, which is routable, so IPv6 devices can forward IPv6 packets in legacy manner without setting up a specific entry for IPv6 mapping prefix in FIB. In addition, because the IPv6 mapping prefix has been included in operator's existing IPv6 address space, it will not introduce any new routing items and affect the global IPv6 routing system. Cons: If the operator does not have a specific address prefix planning and policy configuration, in the case of operator-interworking, the same IPv4 address block will receive NSP prefixes from different operators, forming different IPv6 mapping routes. This may lead to increase the scale of the routing table in the IPv6 network, including FIB and RIB. As mentioned in section 6.1, each PE will be identified by at least one IPv6 mapping prefix, which is used as the basic routing information to forward IPv4-embedded IPv6 packet to the right egress PE. For operators, the selection of the length of IPv6 mapping prefix should be given specific consideration. The length of all the IPv6 mapping prefixes should be the same, to avoid unnecessary processing cost and complexity induced by the prefix length diversity.

This section gives a brief overview of the procedures of the IPv4 service delivery over IPv6-only network. When the ingress PE receives an IPv4 packet from a client-facing interface destined to a remote IPv4 network, it looks up in its mapping rule database to find the mapping rule which best matches the packet’s destination IPv4 address. The IPv6 mapping prefix in the mapping rule will help to find another PE, i.e., the egress PE. Since this happens in multi-domain IPv6-only network, the ingress and egress may belong to different ASes, as shown in figure 3, the ingress PE1 is in AS 1 and egress is PE3 in AS 3. The ingress PE must convert the IPv4 destination address into IPv6 destination address using the IPv6 mapping prefix of PE3 and forward the IPv6 packet to PE3. When PE3 receives the IPv6 packet, it derives the IPv4 source and destination addresses from the IPv4-embedded IPv6 addresses respectively and restore the original IPv4 packet. Afterwards, the IPv4 packet will be further forwarded according to the IPv4 routing table maintained on the egress. The IPv6 data path in this process is shown as below.

| | | | ---- ---- ---- | | / \ / \ / \ | ---- +----+ | | AS1 | | AS2 | | AS3 | | / \ |UE/ |-----PE1 R1---R2 R3---R4 PE3----| AS4 | |CPE1| | | | | | | \(IPv4)/ +----+ \ / \ / \ / ---- ---- ---- ---- Figure 3. End-to-end IPv4 Service Delivery from Ingress to Egress ]]> In this case, there are only two IPv4-IPv6 conversion actions, which occur in PE1 and PE3 respectively.

One typical case is that IPv4 packets may have been transformed into IPv6 packet in UE/CPE, as done by CLAT of 464XLAT, before they reach the edge of the network. In this case, the PLAT of 464XLAT and ADPT will converge in ingress PE. As shown in figure 4, when IPv6 packet reaches the ingress PE, the ingress PE, i.e. PE1, does not need to implement the conversion between IPv4 and IPv6 packets. For the source IPv6 address, because the address adopted by UE is generally GUA, and the source address of the IPv4-embedded IPv6 packet is IPv4-embedded address in the core of this framework, it is necessary to convert the source address from GUA to IPv4-embedded IPv6 address. In addition, because the quantity of IPv4-embedded IPv6 address is limited, it is necessary to take IPv6 address multiplexing here, one IPv4-embedded IPv6 address is shared among multiple IPv6-only clients with GUA addresses. For the destination address, with 464XLAT, UE synthesizes the destination IPv4 address into IPv6 address by appending IPv4 address to the IPv6 prefix provided by DNS64 server. When the IPv6 packet reaches the edge the multi-domain IPv6 network, i.e. PE1, the destination IPv6 address is converted into IPv4-embedded IPv6 address too. This process is implemented by looking for the mapping rule corresponding to the original destination IPv4 address in mapping rule database, and then substituting the NAT64 prefix with the IPv6 mapping prefix of the egress PE.

| | | | ---- ---- ---- | | / \ / \ / \ | ---- +----+ | AS1 | | AS2 | | AS3 | | / \ |UE/ |-----PE1 R1---R2 R3---R4 PE3----| AS4 | |CPE1| | | | | | | \(IPv4)/ +----+ \ / \ / \ / ---- ---- ---- ---- Figure 4. Integration with IPv6-only Access Mechanisms]]> In this case, the functions of stateful NAT64 and stateless IPv4/IPv6 conversion converge in PE1, so the client-facing interface and the core-facing interface are both IPv6. Along the IPv6 data path, there are only one stateless IPv4-IPv6 conversion action, which occurs in PE3. Compared with the case of independent deployment mentioned in section 5, the quantity of IPv4-IPv6 conversion points is reduced from three to one in the new framework. Besides 464XLAT, other IPv6-only technologies, such as DS-Lite, Lightweight 4over6, MAP-T/MAP-T, can also be integrated with the PE of the multi-domain 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, Tianran Zhou and Huaimo Chen for their review and comments.

Contributors Indirection Network Inc.

China guoliang.han@indirectionnet.com

Beijing TC Group

China api_zhao@126.com

Alibaba Cloud

China linjian.slj@alibaba-inc.com