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

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 service(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. 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 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" [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.¶

Several IPv4 service continuity mechanisms 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.¶

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

2. Terminology

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

• 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 [RFC4026]).¶

• 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([RFC6052]).¶

• 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 [RFC6877]).¶

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

• 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 [RFC6144]¶

• GUA: IPv6 Global Unicast Address (Section 3 of [RFC3587]).¶

3. Scenarios

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

4. IPv6-only Deployment in Multi-domain Network

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

                     +---+          +---+
                    /     \        /     \
                   |  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 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.¶

5. General Requirements

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

6. Framework

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

             +-----------------------------------------------+
             | 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 2. Components and Interfaces of ADPT

                           IPv6 Data Path
                |<----------------------------------->|
                |                                     |
                |   ----         ----          ----   |
                |  /    \       /     \       /    \  |      ----
     +----+     | | 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

7. Integration with IPv6-only Access Mechanisms

One typical case is that IPv4 packets may have been transformed into IPv6 packet in UE/CPE, as done by CLAT of 464XLAT[RFC6877], 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.¶

                           IPv6 Data Path
        |<------------------------------------------->|
        |                                             |
        |           ----         ----          ----   |
        |          /    \       /     \       /    \  |      ----
     +----+       | 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.¶

8. Security Considerations

Besides regular security checks on configured mapping rules, the following two aspects need to be considered as well.¶

9. IANA Considerations

There are no other special IANA considerations.¶

10. Acknowledgements

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

11. Contributors

12. References