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

Internet-Draft	Multi-domain IPv6-only Underlay	October 2024
Xie, et al.	Expires 21 April 2025	[Page]

Abstract

For the IPv6 transition, dual-stack deployments require both IPv4 and IPv6 forwarding capabilities to be deployed in parallel. IPv6-only is considered as the ultimate stage where only IPv6 bearer capabilities are used while ensuring global reachability for both IPv6 and IPv4 services(usually known as IPv4aaS). This document proposes a general framework for deploying IPv6-only in one multi-domain underlay network. It lists the requirements of service traffic, illustrates major components and interfaces, IPv6 mapping prefix allocation, typical procedures for service delivery from the perspective of network operation. The document also discusses related security considerations.¶

1. Introduction

IPv6 capabilities have been widely deployed during the past decade with IPv6 traffic growing faster than IPv4. [RFC9386] 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[RFC4213]. 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 encounter 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" [IAB-statement]. 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.¶

The network of large operators generally includes at least access section and backbone section. The access section serves customers by providing access links, assigning addresses, and providing data transmission. The backbone section, i.e., backbone network, is generally a multi-domain network that includes multiple autonomous systems interconnected, each of which has a full-mesh or partial-mesh topology. The backbone network is also referred to as an underlay network. Correspondingly, the deployment of IPv6-only includes at least IPv6-only for the access section and IPv6-only for the backbone section.¶

Several IPv6-only approaches have been designed within IETF during the past twenty years[RFC9313]. For IPv4 service delivery, these approaches use different IPv4/IPv6 conversion methods. For instance, 464XLAT[RFC6877] uses both stateless and stateful NAT64 translation, MAP-E[RFC7597]and MAP-T[RFC7599] use stateless IPv4-IPv6 address translation for encapsulation and translation respectively. DS-Lite[RFC6333] utilizes AFTR-based 4over6 tunneling approach. These existing IPv6-only approaches can assign only IPv6 addresses to customer terminals or networks, thus solving the problem of IP address shortage on the user side, and supporting users to access IPv4 and IPv6 Internet normally. Up to now, several operators have deployed 464XLAT on their mobile networks, some have deployed DS-Lite in their wireline networks. However, the current IPv6-only technology system is incomplete, and the IPv6-only solution for the backbone network is nearly blank. Existing solutions only implement IPv6-only for the access section, and the backbone network is still dual-stack, which cannot meet the comprehensive IPv6-only deployment requirements. From the perspective of large-scale network operators, it is necessary to design an IPv6-only framework with multi-domain network as the main body, which can guide the deployment of IPv6-only as a whole, this framework can combine multiple technologies, including existing ones, to form a comprehensive solution, meet end-to-end IPv4 and IPv6 data transmission concurrently. One of the objectives of such a framework is to support end-to-end IPv6 and IPv4 service across domains delivery in an efficiently way, therefore it uses tunneling or translation to transfer data from one edge device to the other, the conversion between IPv4 and IPv6 packets is based on stateless address mapping at the edge devices. The term "stateless" here refers to no need to maintain user-related status or translation tables for packet transformation at the edge devices.¶

It should be noted that the multi-domain framework proposed in this document is not intended to replace existing IPv6-only technologies, but to utilize or be compatible with them. The network specified by this framework can be integrated with other existing IPv6-only access approaches, thereby reducing unnecessary IPv4/IPv6 conversions. 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.¶

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.¶

4. IPv6-only Deployment in Multi-domain Network

For large-scale operators, their networks 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. [RFC8585] 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 respectively.¶

Regarding the external interconnection, 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).¶

                     +---+          +---+
                    /     \        /     \
                   |  DC1  |      |  DC2  |
                    \     /        \     /
                     +---+          +---+
              ---------|--------------|---------
             |         |      N1      |         |
             |         | (Operator 1) |         |     (Operator2)
             |        PE3            PE4        |       +---+
             |      /    \         /     \      |      /     \
   +----+    |     |  AS1 |       |       |     |     |       |
   |UE/ |---------PE1     R1-----R2      PE5---------BR1 AS4  |
   |CPE1|    |     |      |       |       |     |     |       |
   +----+    |      \    /        |       |     |      \     /
             |        R5          |  AS3  |     |       +---+
             |        |           |       |     |
   +----+    |        |           |       |     |     (Operator3)
   |UE/ |-   |        R6          |       |     |       +---+
   |CPE2| \  |      /    \        |       |     |      /     \
   +----+  \ |     |  AS2 |       |       |     |     |       |
             -----PE2     R3-----R4      PE6---------BR2 AS5  |
   +----+  / |     |      |       |       |     |     |       |
   |UE/ | /  |      \    /         \     /      |      \     /
   |CPE3|-   |       +--+           +---+       |       +---+
   +----+    |                                  |
              ----------------------------------

   Figure 1. Multi-domain Underlay Network

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. [RFC5565] 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 [RFC5565] 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.¶

[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 one multi-domain network, when IPv6-only scheme is deployed without any collaboration, different ASes adopt the IPv6 transition approach independently, the result maye be that multiple IPv6-only islands are connected by IPv4 links between domains. With independent 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 behaviors of the network edge for IPv4 service delivery and eliminate unnecessary IPv4/IPv6 conversion gateways within the multi-domain network.¶

5. General Requirements

Native IPv6 traffic can be transported over an IPv6-only network following legacy procedures.¶

From the perspective of network operation, 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¶

User status refers to the address/port mapping relationship between different protocols formed during the conversion from IPv4 to IPv6, which is usually caused by a single IPv4 address being used by multiple IPv6 users. Maintaining user state will consume a significant amount of storage and computing power. Border gateway which communicate with external networks does not need to store user related state?it only needs to perform stateless translation or encapsulation/decapsulation when necessary. The user status is usually maintained at the terminal or the network edge on the user side.¶

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 compromises¶

The technologies proposed must not introduce additional security compromise.¶

The requirements above can be considered as guidances for multi-domain IPv6-only network framework design and subsequent production operation.¶

6. Framework

6.1. Overview

The framework in this document is deliberately described at a high level, it is not intended to be prescriptive, implementations and technical solutions may vary freely. In addition, this document describes the behaviors of network devices and IPv4 and IPv6 address space handling from the perspective of operators, it does not define any new protocols.¶

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 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 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 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 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 documents. 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.¶

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 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, which will be illustrated later, 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 2, 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.¶

                           IPv6 Data Path
                |<---------------------------------->|
                |                                    |
                |   +--+         +--+         +--+   |
                |  /    \       /    \       /    \  |     +--+
     +----+     | | AS1  |     |  AS2 |     | AS3  | |    /    \
     |UE/ |-----PE1      R1---R2      R3---R4      PE3---| AS4  |
     |CPE |       | IPv6 |     | IPv6 |     | IPv6 |      \IPv4/
     +----+        \    /       \    /       \    /        +--+
                    +--+         +--+         +--+

    Figure 2. 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.¶

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.¶

6.2. ADPT Description

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 3.¶

             +-----------------------------------------------+
             | 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

6.2.1. Rule Processing Layer

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 receives from other PEs, as shown in Figure 3. 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)¶

6.2.2. Rule Transport Layer

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 transmission from Rule Processing Layer through interface I2 is 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.¶

6.2.3. Data Forwarding Layer

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 it finds the mapping rule for the IPv4 destination address, 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 refers to the process in which PE adds a new IPv6 header 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 it finds the mapping rule for the IPv4 destination address, 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.¶

6.3. IPv6 Mapping Prefix Allocation

With this framework, a specific IPv6 range is used to represent IPv4 address space by stateless 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.¶

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, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3587]: Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, August 2003, <https://www.rfc-editor.org/info/rfc3587>.
[RFC4026]: Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <https://www.rfc-editor.org/info/rfc4026>.
[RFC4760]: Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC5565]: Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, <https://www.rfc-editor.org/info/rfc5565>.
[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, <https://www.rfc-editor.org/info/rfc6052>.
[RFC6877]: Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <https://www.rfc-editor.org/info/rfc6877>.
[RFC7915]: Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, <https://www.rfc-editor.org/info/rfc7915>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11.2. Informative References

[IAB-statement]: "IAB statement", <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>.
[RFC4213]: Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, <https://www.rfc-editor.org/info/rfc4213>.
[RFC6144]: Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, <https://www.rfc-editor.org/info/rfc6144>.
[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, <https://www.rfc-editor.org/info/rfc6333>.
[RFC6992]: Cheng, D., Boucadair, M., and A. Retana, "Routing for IPv4-Embedded IPv6 Packets", RFC 6992, DOI 10.17487/RFC6992, July 2013, <https://www.rfc-editor.org/info/rfc6992>.
[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, <https://www.rfc-editor.org/info/rfc7597>.
[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, <https://www.rfc-editor.org/info/rfc7599>.
[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, <https://www.rfc-editor.org/info/rfc8585>.
[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, <https://www.rfc-editor.org/info/rfc9313>.
[RFC9386]: Fioccola, G., Volpato, P., Palet Martinez, J., Mishra, G., and C. Xie, "IPv6 Deployment Status", RFC 9386, DOI 10.17487/RFC9386, April 2023, <https://www.rfc-editor.org/info/rfc9386>.

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

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

1.1. Requirements Language

2. Terminology

3. Scenarios

4. IPv6-only Deployment in Multi-domain Network

5. General Requirements

6. Framework

6.1. Overview

6.2. ADPT Description

6.2.1. Rule Processing Layer

6.2.2. Rule Transport Layer

6.2.3. Data Forwarding Layer

6.3. IPv6 Mapping Prefix Allocation

7. Security Considerations

7.1. Authenticity and Integrity of Packets

7.2. BGP-4 and Multiprotocol Extensions for BGP-4

8. IANA Considerations

9. Acknowledgements

10. Contributors

11. References

11.1. Normative References

11.2. Informative References

Authors' Addresses