v6ops Working Group C. Xie
Internet-Draft C. Ma
Intended status: Informational China Telecom
Expires: 7 October 2025 X. Li
CERNET Center/Tsinghua University
G. Mishra
Verizon Inc
T. Graf
Swisscom
5 April 2025
Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-
a-Service
draft-ietf-v6ops-framework-md-ipv6only-underlay-10
Abstract
For the IPv6 transition, IPv6-only is considered as the final stage,
where only IPv6 protocol is used for transport while maintaining
global reachability for both IPv6 and IPv4 services. This document
illustrates a framework of multi-domain IPv6-only underlay network
from an operator's perspective. In particular, it proposes stateless
address mapping as the base for enabling IPv4 service data
transmission in an multi-domain IPv6-only environment(i.e.,IPv4-as-
a-Service). It describes the methodology of stateless IPv4/IPv6
mapping, illustrates the behaviors of network devices, analyzes the
options of IPv6 mapping prefix allocation, examines the utilization
of SRv6, and discusses the security considerations.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 October 2025.
Xie, et al. Expires 7 October 2025 [Page 1]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IPv6-only Deployment in Multi-domain Network . . . . . . . . 7
5. IPv4/IPv6 Address Mapping for IPv4aaS . . . . . . . . . . . . 9
5.1. IPv4/IPv6 Address Mapping . . . . . . . . . . . . . . . . 9
5.2. End-to-End IPv4 Service Delivery . . . . . . . . . . . . 11
6. Framework Introduction . . . . . . . . . . . . . . . . . . . 11
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Rule Processing Layer . . . . . . . . . . . . . . . . . . 13
6.3. Rule Transport Layer . . . . . . . . . . . . . . . . . . 14
6.4. Data Forwarding Layer . . . . . . . . . . . . . . . . . . 14
7. IPv6 Mapping Prefix Allocation . . . . . . . . . . . . . . . 15
8. SRv6 for Multi-domain IPv6-only Network . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Authenticity and Integrity of Packets . . . . . . . . . . 17
9.2. BGP-4 and Multiprotocol Extensions for BGP-4 . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
IPv6 capabilities have been widely deployed over the past decade,
with IPv6 traffic growing at a faster rate than IPv4. [RFC9386]
provides an overview of IPv6 deployment status and the progress of
the transition to IPv6 among network operators and enterprises.
Xie, et al. Expires 7 October 2025 [Page 2]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
As of 2022, most IPv6 deployments rely on dual-stack[RFC4213].
However, dual-stack has long-term drawbacks, including duplicated
network resources and states, as well as increased operational
complexity from maintaining both protocol stacks. For instance, when
broadband users experience access service failure, operators must
determine whether the failure stems from IPv4 or IPv6, effectively
doubling troubleshooting efforts. Once IPv6 adoption becomes
dominant, transitioning to IPv6-only could reduce resource overhead
and simplify operations.
In 2016, the IAB stated that it “expects the IETF to no longer
mandate IPv4 compatibility in new or updated protocols, with future
IETF work focusing on IPv6 optimizationâ€[IAB-statement]. To ensure
service continuity after IPv4 address exhaustion, operators must
deploy IPv6 while maintaining access to the global IPv4 Internet-
commonly referred to as IPv4-as-a-Service (IPv4aaS)-a logical
approach for IPv6-only networks.
The network infrastructure of large operators typically consists of
at least an access section and a backbone section. The access
section serves customer by delivering access links, assigning
addresses, and enabling two-way data transmission. The backbone
section, also known as the backbone network, is usually a multi-
domain network comprising interconnected autonomous systems (i.e.,
ASes), each with a full-mesh or partial-mesh topology. The backbone
network is sometimes referred to as the underlay network.
Accordingly, IPv6-only deployment involves two key sections:
IPv6-only in the access section and IPv6-only in the backbone
section.
For the IPv6-only deployment in the access section, several IPv6-only
approaches have been developed within the IETF over the past two
decades[RFC9313]. These methods employ different IPv4/IPv6
conversion techniques to deliver IPv4 services. For example:
* 464XLAT [RFC6877] is an IPv6 transition mechanism that enables
IPv4 connectivity in IPv6-only networks. It combines client-side
stateless NAT46 (CLAT) with provider-side stateful NAT64 (PLAT),
allowing legacy IPv4 applications to operate without modification.
464XLAT has been commonly used in mobile networks.
* MAP-T [RFC7599] and MAP-E[RFC7597] are stateless IPv6 transition
technologies. MAP-T performs IPv4-IPv6 translation, while MAP-E
uses encapsulation. Both employ algorithmic address mapping to
enable IPv4 service delivery over IPv6 networks without
maintaining per-flow state, suitable for broadband deployments.
Xie, et al. Expires 7 October 2025 [Page 3]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
* DS-Lite [RFC6333] is also an IPv6 transition technology, enabling
IPv4 communication over an IPv6 network, it combines IPv4-in-IPv6
tunneling with a centralized carrier-grade NAT (CGN), reducing the
need for IPv4 addresses while maintaining compatibility.
These IPv6-only solutions allocate only IPv6 addresses to customer
terminals or networks, addressing IPv4 address exhaustion on the user
side while enabling access to both IPv4 and IPv6 Internet services.
To date, some operators have deployed 464XLAT in mobile networks and
DS-Lite in wireline networks.
However, the current IPv6-only ecosystem remains incomplete,
particularly in backbone networks, where IPv6-only solutions are
nearly nonexistent. Existing implementations focus solely on the
access segment, leaving backbone networks operating mainly in dual-
stack mode, which falls short of full IPv6-only deployment
requirements.
For large-scale network operators, a comprehensive multi-domain
IPv6-only framework is needed to guide end-to-end deployment. Such a
framework would integrate multiple technologies, including existing
ones, to ensure seamless IPv4 and IPv6 data transmission. A key
objective is enabling efficient cross-domain IPv6 and IPv4 service
delivery, utilizing tunneling or translation to forward data between
edge devices. IPv4-IPv6 packet conversion relies on stateless
address mapping at the edges, meaning no user-specific state or
translation tables are required for packet processing. In addition,
for any IPv4 traffic flow traversing a multi-domain IPv6-only
network, there should be no IPv4-to-IPv6 conversion point along the
data path.
This document presents a framework for building large-scale IPv6-only
networks from a network operator's perspective. As it is described
at a high level, this framework is not meant to replace existing
IPv6-only technologies but rather to leverage and remain compatible
with them. Networks implemented under this framework can integrate
with other IPv6-only access methods, minimizing unnecessary IPv4/IPv6
conversions.
Unless otherwise stated, the term “IPv6-only network†in this
document refers specifically to “IPv6-only underlay networkâ€. This
document does not propose new IPv6 transition mechanisms or IPv4aaS
solutions.
Xie, et al. Expires 7 October 2025 [Page 4]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14[RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
The following terms are used in this document:
* Multi-domain IPv6-only underlay network: IPv6-only underlay
network which consists of multiple ASes operated by single or
multiple operators.
* AS: Autonomous System.
* UE: User Equipment, e.g., mobile phone.
* CLAT: Customer-side translator (Section 1 of [RFC6877]).
* CE: Customer 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 address: IPv6 address used to represent IPv4
nodes in an IPv6 network. This address includes a 32-bit embedded
IPv4 address and are also referred to as IPv6-mapped addresses
([RFC6052]).
* IPv4-embedded IPv6 packet: An IPv6 packet created through
encapsulation or translation of an IPv4 packet, where the source
and destination IPv4 addresses are statelessly mapped to
corresponding IPv6 addresses.
* PLAT: Provider-side translator (Section 1 of [RFC6877]).
Xie, et al. Expires 7 October 2025 [Page 5]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
* ASBR: Autonomous System Boundary Router, a router that runs
External Border Gateway Protocol(eBGP) and peering with the BGP
routers of external ASes.
* AFBR: Address Family Border Router, a router that supports both
IPv4 and IPv6 address families and serves to provide transit
services for the other in a backbone network (Section 1 of
[RFC5565]).
* ADPT: Adapter in PE, a function entity that implements the two-way
IPv4 and IPv6 packet conversion for IPv4 service delivery over
IPv6-only network.
* Conversion point: A function that converts between IPv4 and IPv6
realms, such as the translation (XLAT) function defined in
[RFC6144]
* GUA: IPv6 Global Unicast Address (Section 3 of [RFC3587]).
* RAN: Radio Access Network.
3. Scenarios
Currently, the global Internet industry has not given a unified
definition of an IPv6-only network. This document defines it as an
IPv6-centric network where data packets are forwarded based on IPv6
capability. An IPv6-only network may interconnect with external
networks, including IPv4-only networks.
As a general network infrastructure, an IPv6-only network should
support the following scenarios,
Scenario 1: IPv6 user accessing an IPv4 server, i.e., an
IPv6-only user accesses to an IPv4-based service hosted in a data
center or other places.
Scenario 2: IPv4 user accessing an IPv4 server, i.e., an
IPv4-only user accesses to an IPv4-based service hosted in a data
center or other places.
Scenario 3: IPv6 user accessing an IPv6 server, i.e., an
IPv6-only user accesses to an IPv6-based service hosted in a data
center or other places.
Scenario 4: IPv4 user accessing an IPv6 server, i.e., an
IPv4-only user accesses to an IPv6-based service hosted in a data
center or other places.
Xie, et al. Expires 7 October 2025 [Page 6]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
Scenario 5: DC-to-DC, i.e., an IPv6-only network provides
communications between servers hosted in different data centers,
regardless of whether they are IPv4, IPv6 or IPv4/IPv6 dual-
stack.
Scenario 6: Transit for neighbor networks, i.e., an IPv6-only
network interconnects multiple isolated IPv4-only networks,
enabling IPv4 packet transmission over the IPv6 infrastructure.
Scenario 7: Mobile transport network, mobile operators can
utilize IPv6-only to connect the RAN and 5G core network,
delivering the specific connectivity services required for 5G
application operations.
It should be noted the scenarios listed above represent only a subset
of those supported by IPv6-only networks, which are at least as
capable as current dual-stack networks.
4. IPv6-only Deployment in Multi-domain Network
This framework is designed to assist large operators in deploying
IPv6-only in a multi-domain network. Large-scale operators typically
manage network infrastructure composed of multiple interconnected
autonomous systems (ASes), that's why it called "Multi-domain
Underlay Network". These ASes often support different functions,
such as metro area networks (MANs), backbone networks, 4G/5G mobile
core networks, DCs, and may be administered by separate departments
or institutions with different routing and security policies. In a
multi-domain network, edge nodes are commonly referred to as Provider
Edge (PE) routers. The ingress PE is the router where a packet
enters the network, while the egress PE is the router where it exits.
Internal nodes are typically called Provider (P) routers.
To facilitate the illustrating the framework, this document first
introduces an example of a multi-domain network from the perspective
of operators. As shown in Figure 1, Network N1 is managed by
operator NP-1 and consists of multiple interconnected Autonomous
Systems (ASes), namely AS1, AS2, and AS3. N1 provides connectivity
to various user types, including mobile, home broadband, and
enterprise customers, represented by CE1, CE2, and CE3, respectively.
Routers located outside the backbone but directly connected to it are
referred to as Customer Edge (CE) routers. [RFC8585] defines IPv4
service continuity requirements for IPv6 CE routers, extending the
basic IPv6 CE specifications to support IPv4 delivery in IPv6-only
access networks. Additionally, service instances in DCs must support
cross-site communication, whether on-premises or in external data
centers. A multi-domain network must facilitate these data center
connections. Network N1 supports at least two connectivity modes for
Xie, et al. Expires 7 October 2025 [Page 7]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
data centers: the first is the mode between data center and
individual users, for instance, the user of CE1 accesses the service
hosted in DC1, the second is the mode between data centers, for
instance, communications between service instances hosted in DC1 and
DC2 respectively.
Regarding external interconnection, NP-2 is a neighboring operator of
NP-1. AS4 of NP-2 and AS3 of NP-1 are interconnected via BGP. AS4
is an IPv4-only network and does not support IPv6.
+-------+ +-------+
| DC1 | | DC2 |
+-------+ +-------+
| |
+----+ /-------|---------------------|--------\ (NP-2)
|UE/ |\ | | | | +---+
|CE2 | \ | | | | / \
+----+ \| PE2 +-+ PE5 | BR1 AS4 |
|\ / \ / \ / \ | / \ /
+----+ | \ | AS1 | | AS2 | | AS3 | | / +---+
|UE/ |---+- PE1 P1--P2 P3--P4 PE3---+-/
|CE1 | | / | | | | | | |
+----+ |/ \ / \ / \ / |
| +-+ +-+ PE4-------+-\ (NP-3)
+----+ /| | \ +---+
|UE/ | / | Multi-domain Network N1 | \ / \
|CE3 |/ | (NP-1) | BR2 AS5 |
+----+ | | \ /
\--------------------------------------/ +---+
Figure 1. An Example of Multi-domain Underlay Network
For network N1, transitioning from dual-stack to IPv6-only involves
gradually disabling some or all IPv4 protocol instances, making IPv6
the primary network-layer protocol. Specifically, core P routers,
such as P1, P2, P3 and P4, run only IPv6, while PE routers, such as
PE1, PE2 and PE3, support IPv4 on interfaces facing IPv4 client
networks and IPv6 on interfaces facing the core, requiring them to
handle both address families. Network N1 transports packets that
originate and terminate outside the network. These packets enter the
IPv6 network at a PE router, traverse the network, and exit through
another PE router to continue their path.
Xie, et al. Expires 7 October 2025 [Page 8]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
In addition, the IPv6-only deployment in network N1 must ensure the
continued operation of remaining IPv4 services without degrading user
experience. As some Internet services may remain IPv4-based even in
an IPv6-dominated environment. Therefore, an IPv6-only network
should support access to IPv4-only services, as well as native IPv6
services.
[RFC6992] describes a routing scenario where IPv4 packets are
transported over an IPv6 network, based on [RFC7915] and [RFC6052],
along with a separate OSPFv3 routing table for IPv4-embedded IPv6
routes in the IPv6 network. Since it is based on the OSPF protocol,
it supports IPv4aaS within a single AS.
For a multi-domain network operator, deploying IPv6-only without a
unified framework may lead to independent adoption of IPv6 transition
approaches across different ASes. This can result in multiple
IPv6-only islands interconnected by IPv4 links between domains. With
independent deployment in different domains, the network may contain
multiple IPv4-IPv6 packet conversion points with varying
functionalities. In such cases, IPv6 packets converted from IPv4
packets may need to revert to IPv4 at the egress of one AS, then back
to IPv6 in the next domain. The number of conversion gateways
increases with the number of ASes. Excessive IPv4-IPv6 conversion
gateways introduce network complexity and higher capital expenditures
(CAPEX). Thus, a unified framework is required to define network
edge behavior for IPv4 service delivery and eliminate unnecessary
IPv4/IPv6 conversion gateways within the multi-domain network.
5. IPv4/IPv6 Address Mapping for IPv4aaS
5.1. IPv4/IPv6 Address Mapping
To support IPv4aaS in a multi-domain IPv6-only network, the framework
proposes each PE device to be allocated and identified by at least
one IPv6 mapping prefix, denoted by Pref6(PE). Each devices will
also have one or more associated IPv4 address blocks which are
extracted from local IPv4 routing table or address pool. The mapping
relationship between an IPv4 address block and its corresponding IPv6
prefix is referred to as a mapping rule, which will have at least the
following data structure.
IPv4 address block: Pref6(PE)
It should be noted that the mapping rule contains not only the data
structure above, but also other necessary information to support IPv4
service delivery over IPv6-only network, the detailed structure
definition of the mapping rule is out of the scope of this document.
Xie, et al. Expires 7 October 2025 [Page 9]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
The mapping rule of destination address will determine the direction
of IPv4 service data transmission in a multi-domain IPv6-only
network. When the mapping rule corresponding to the destination
address of a given IPv4 packet is available, the ingress PE can
generate corresponding IPv6 source and destination addresses from its
IPv4 source and destination address as below,
-The IPv6 source address is derived by appending the IPv4 source
address to its local IPv6 mapping prefix, i.e., Pref6(ingress
PE).
-The IPv6 destination address is derived by appending the IPv4
destination address to the Pref6(egress PE) in the mapping rule.
Since mapping rule adopts prefix-level mapping, there is no need to
maintain user-related status or translation tables for packet
transformation at the PE devices.
[RFC6052] illustrates the algorithmic translation of an IPv4 address
to a corresponding IPv6 address, and vice versa, using only
statically configured information. With this approach, IPv4-embedded
IPv6 addresses are composed by concatenating the prefix, the 32 bits
of the IPv4 address, and the suffix (if needed) to obtain a 128-bit
address. The prefixes can only have one of the following lengths:
32, 40, 48,56, 64, or 96.
For IPv4 service delivery across a multi-domain IPv6-only network, it
is proposed that IPv4 address is located at the last 32 bits of the
IPv6 address, most significant bits first. The bits between IPv6
mapping prefix and IPv4 address can be set to zero and are reserved
for future extensions. Examples of such representations are
presented in Table 1.
+-------------------+------------+--------------------------+
|IPv6 mapping prefix|IPv4 address|IPv4-embedded IPv6 address|
+-------------------+------------+--------------------------+
|2001:db8::/32 |192.0.2.33 |2001:db8::192.0.2.33 |
|2001:db8:100::/40 |192.0.2.33 |2001:db8:100::192.0.2.33 |
|2001:db8:122::/48 |192.0.2.33 |2001:db8:122::192.0.2.33 |
+-------------------+------------+--------------------------+
Table 1. Text Representation of IPv4-Embedded IPv6 Address
Prior to IPv4/IPv6 packets conversion, the mapping rule for the
destination address needs to be obtained remotely in advance. To
meet this requirement, specific mechanism of mapping rule exchange
needs to be designed, the exchange can be within or across domains.
Using the mapping rule exchange mechanism, an egress PE can inform
other PEs that an IPv4 packet with a destination address within the
Xie, et al. Expires 7 October 2025 [Page 10]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
IPv4 address block of a mapping rule should be forwarded to the
egress PE identified by the corresponding IPv6 mapping prefix.
However, this has been beyond the scope of this document, and it will
be addressed in other documents.
5.2. End-to-End IPv4 Service Delivery
To enable IPv4 service data forwarding in a multi-domain IPv6-only
network, IPv4 packets must be converted to IPv6 packets-either at the
UE/CE or at the edge PE of the network. Consider the network case of
section 4, when one ingress PE, e.g., PE1, receives an IPv4 packet
(destined for a remote IPv4 network, e.g., AS4) from a client-facing
interface, it queries its mapping rule database (detailed later) in
PE1 to find the rule that best matches the packet's destination IPv4
address. The IPv6 mapping prefix in the rule identifies the
corresponding egress PE. In this case, the ingress and egress PEs
belong to different autonomous systems (ASes), the ingress PE1
resides in AS 1, while the egress PE3 is in AS 3. The ingress PE
converts the IPv4 destination address into an IPv6 address using
PE3's IPv6 mapping prefix and forwards the IPv6 packet to PE3. Upon
receiving the IPv6 packet, PE3 extracts the original IPv4 source and
destination addresses from the IPv4-embedded IPv6 addresses and
reconstructs the IPv4 packet. The packet is then forwarded based on
the IPv4 routing table maintained at the egress PE. In this case,
there are only two IPv4-IPv6 conversion actions, which occur in PE1
and PE3 respectively, the IPv6 data path for this process is between
PE1 and PE3, as shown in Figure 2.
IPv6 Data Path
|<---------------------------------->|
| |
| +--+ +--+ +--+ |
| / \ / \ / \ | +--+
+----+ | | AS1 | | AS2 | | AS3 | | / \
|UE/ |-----PE1 P1---P2 P3---P4 PE3---| AS4 |
|CE | | IPv6 | | IPv6 | | IPv6 | \IPv4/
+----+ \ / \ / \ / +--+
+--+ +--+ +--+
Figure 2. End-to-end IPv4 Service Delivery from Ingress to Egress
6. Framework Introduction
Xie, et al. Expires 7 October 2025 [Page 11]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
6.1. Overview
To meet the above requirements, it is necessary to define a framework
to describe the behavior of devices from the perspective of
operators. In this framework, the PE is the key device, enabling
stateless IPv4/IPv6 packet transformation to deliver IPv4 services in
a multi-domain IPv6-only network. There is no specific requirements
to the P devices. ADPT is the functional entity in the PE device
that facilitates IPv4-to-IPv6 packet conversion. This section
describes the ADPT components and interfaces from a network
operations perspective. As illustrated in Figure 3, ADPT consists of
the following components,
-RP: Rule Processing Layer
-RT: Rule Transport Layer
-DF: Data Forwarding Layer
Besides, there are interfaces of I1 I2, I3, I4, I5, I6, I7, and I8 in
this framework. The functions of these components and interfaces
will be introduced in the following sections.
Xie, et al. Expires 7 October 2025 [Page 12]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
+-----------------------------------------------+
| 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. Rule Processing Layer
The Rule Processing Layer (RP) manages the mapping relationships
between IPv4 address blocks and their corresponding IPv6 prefixes.
Each PE contains a Mapping Rule Database (MD) that stores all mapping
rule entries received from other PEs, as shown in Figure 3. The Rule
Processing Layer manages the MD via Interface I7, supporting
operations such as rule insertion, modification, and deletion.
Interface I1 facilitates mapping rule exchange between PEs via their
respective ADPTs. Interface I2 enables mapping rule transmission
through the Rule Transport Layer (detailed in Section 6.3). PE1
extracts IPv4 address blocks from its IPv4 BGP routing instance using
Interface I3, then generates device-specific mapping rules by
combining them with its IPv6 mapping prefix. Once prepared, these
rules are forwarded to the Rule Transport Layer via Interface I2.
Conversely, PE1 receives mapping rules from other PEs through
Interface I2 and stores them locally in its MD.
Xie, et al. Expires 7 October 2025 [Page 13]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
If certain IPv4 address blocks are not explicitly announced by any
egress PEs to the ingress PE, the MD will lack corresponding mapping
rules. To address this, the framework introduces a default egress
PE, which advertises a default IPv6 mapping rule containing a default
mapping prefix to all other PEs. The format of the default IPv4
address mapping rule is as follows:
0.0.0.0/0: Pref6(PE)
6.3. Rule Transport Layer
The Rule Transport Layer (RT) handles the exchange of mapping rules
and associated routing information between PEs at the routing layer.
Mapping rule exchange must occur before IPv4 data transmission
begins; otherwise, IPv4 traffic packets will be dropped due to the
lack of a corresponding IPv6 mapping prefix for the destination
address.
Upon receiving a mapping rule transmission request from the Rule
Processing Layer via Interface I2, the Rule Transport Layer (RT)
converts the mapping rule into a data structure that is suitable for
the transmission in the IPv6 routing system. The RT then forwards
this formatted rule to the IPv6 routing engine through Interface I4.
In the opposite direction, when the RT receives a routing update from
the IPv6 routing engine via Interface I4, it extracts the embedded
mapping rule and relays it to the Rule Processing Layer for further
processing.
To enable mapping rule transmission at the routing layer, extensions
to MP-BGP4 or other control protocols would be required. However,
this has been out of the scope of the draft and will be discussed in
other documents.
6.4. Data Forwarding Layer
In this framework, Data Forwarding Layer, i.e., DF, provides data
forwarding function to IPv6 packets, including native IPv6 packets
and IPv4-embedded IPv6 packets. IPv4-embedded IPv6 packets can be
generated using either translation or encapsulation for IPv4 data
delivery.
1. Translation
Translation refers to the packet conversion from one protocol
format to the other. When the Data Forwarding Layer receives an
IPv4 packet via interface I5 from the IPv4 packet forwarding
module, it queries the Mapping Rule Database(MD) through
interface I8. If a mapping rule exists for the IPv4 destination
Xie, et al. Expires 7 October 2025 [Page 14]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
address, the layer generates corresponding IPv6 source and
destination addresses from the IPv4 addresses, following the
procedure described in Section 5.1.
2. Encapsulation
Encapsulation refers to the process of adding an IPv6 header to
the original IPv4 packet for transmission across the multi-domain
IPv6-only network. The address mapping process for encapsulation
follows the same procedure as translation: When receiving an IPv4
packet via interface I5 from the IPv4 forwarding module, the Data
Forwarding Layer queries the Mapping Rule Database through
interface I8. If a matching rule exists for the IPv4 destination
address, the layer generates corresponding IPv6 source and
destination addresses from the IPv4 addresses according to the
procedure described in Section 5.1.
For IPv4-embedded IPv6 packets, the Pref6 portion of the destination
address identifies the network egress, regardless of whether
translation or encapsulation was used. Therefore, packet forwarding
can be performed by P devices based solely on the Pref6 part of the
destination address.
Although this document illustrates the framework of multi-domain
IPv6-only network operated by a single operator, this multi-domain
model can naturally be extended to IPv6-only network which is
operated by multiple operators.
7. IPv6 Mapping Prefix Allocation
With this framework, a specific IPv6 address range, i.e., IPv6
mapping prefix, is used to represent an IPv4 address block by
stateless mapping as illustrated in section 5.1, there are two
options to allocate IPv6 mapping prefixes:
1) Well-Known Prefix (WKP)
A specific WKP can be allocated from the global IPv6 address prefix,
e.g., 64:ff9b::/96, or an IPv6 address prefix specifically assigned
for this purpose.
Pros:
Xie, et al. Expires 7 October 2025 [Page 15]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
This can offer two key advantages for IPv6 mapping prefix
allocation. First, operators are not required to dedicate IPv6
address prefixes from their own resources for mapping IPv4
addresses. Second, they can easily control the range of IPv6
mapping routes, such as applying routing restrictions at network
boundaries to prevent leakage into external networks.
Cons:
When the PE device converts an IPv4 address to an IPv6 address
using a Well-Known Prefix, the IPv4 portion of the IPv4-embedded
IPv6 address is used for routing the packet. Consequently,
multiple specific routes with prefix lengths greater than 96 may
be inserted into the FIB of P routers in an IPv6-only network.
However, most networks do not support such fine-grained routes
with prefix lengths exceeding 96.
2) Network Specific Prefix (NSP)
NSP refers to a dedicated IPv6 prefix (or prefixes) assigned from
operator's available IPv6 address pool to each PE for IPv4 addresses
mapping. The assigned IPv6 mapping prefix differs per PE.
Pros:
In a multi-domain network, the length of the IPv6 mapping prefix
can be adjusted to meet IPv6 routing requirements. The IPv6
mapping prefix is part of a larger and routable IPv6 address
block assigned to the PE, so this approach is unlikely introduce
new routing entries or impact the global IPv6 routing system.
For IPv4-embedded IPv6 packet, the P devices can forward them in
legacy manner without requiring a specific FIB entry for the
mapping prefix.
Cons:
If the operator has not implemented specific address prefix
planning and policy configuration, interworking between operators
may result in the same IPv4 address block receiving multiple NSP
prefixes from different operators. This can generate multiple
IPv6 mapping routes, potentially increasing the size of IPv6
routing tables (including FIB and RIB).
As specified in Section 5.1, each PE must be assigned at least one
IPv6 mapping prefix. This prefix serves as the fundamental
information for forwarding IPv4-embedded IPv6 packets to the correct
egress PE. Operators should carefully determine the IPv6 mapping
prefix length during implementation. The length of all the IPv6
Xie, et al. Expires 7 October 2025 [Page 16]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
mapping prefixes is recommended to be the same, to avoid unnecessary
processing cost and complexity induced by the prefix length
diversity.
8. SRv6 for Multi-domain IPv6-only Network
As mentioned before, the purpose of this framework is to guide
operators IPv6-only deployment in multi-domain networks. It proposes
to integrate multiple technologies, including SRv6[RFC8986], to
ensure seamless IPv4 and IPv6 data transmission.
SRv6 enables a network operator to specify a packet processing
program by encoding a sequence of instructions in the IPv6 packet
header. SRv6 can also utilize specific SID, i.e., DT4 or DX4, to
transport IPv4 packets across IPv6-only networks from one PE to
another, making it a candidate technology for building multi-domain
IPv6-only network. However, there will be issues with SRv6 which may
influence its actual utilization for this purpose. Firstly, due to
security concerns, as mentioned in 'draft-ietf-spring-srv6-security',
the current document assumes that SRv6 is deployed within a trusted
domain, where one operator's SID cannot be manipulated by another
operator's network devices,this may limit the joint deployment of
IPv6-only by multiple operators. Another issue is that SRv6 uses SRH
to carry SIDs, extension headers are often restricted by many
operators due to various considerations, [RFC9098] mentions that
"packets employing IPv6 extension headers are often dropped by
network firewalls, either because of the challenges represented by
extension headers or because the use of IPv6 extension headers has
not been explicitly allowed." In addition, the actual deployment of
SRv6 globally is not yet widespread, and many operators are just
starting to deploy IPv6. These issues may become constraints for
operators to use SRv6 to build multi-domain IPv6-only networks. Of
course, if these issues are relieved, SRv6 can also be a good option
for building IPv6-only network.
9. Security Considerations
Besides regular security checks on configured mapping rules, the
following two aspects need to be considered as well.
9.1. Authenticity and Integrity of Packets
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
Xie, et al. Expires 7 October 2025 [Page 17]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
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.
9.2. BGP-4 and Multiprotocol Extensions for BGP-4
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.
10. IANA Considerations
There are no other special IANA considerations.
11. 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, Nick Buraglio, David 'equinox' Lamparter, Tianran Zhou and
Huaimo Chen for their review and comments.
12. Contributors
Guoliang Han
Indirection Network Inc.
China
Email: guoliang.han@indirectionnet.com
Ruoyu Zhao
Beijing TC Group
China
Email: api_zhao@126.com
Xie, et al. Expires 7 October 2025 [Page 18]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
Linjian Song
Alibaba Cloud
China
Email: linjian.slj@alibaba-inc.com
13. References
13.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>.
Xie, et al. Expires 7 October 2025 [Page 19]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
[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>.
13.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>.
Xie, et al. Expires 7 October 2025 [Page 20]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>.
[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>.
Authors' Addresses
Chongfeng Xie
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: xiechf@chinatelecom.cn
Chenhao Ma
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: machh@chinatelecom.cn
Xing Li
CERNET Center/Tsinghua University
Shuangqing Road No.30, Haidian District
Beijing
100084
China
Xie, et al. Expires 7 October 2025 [Page 21]
Internet-Draft Multi-domain IPv6-only Underlay April 2025
Email: xing@cernet.edu.cn
Gyan Mishra
Verizon Inc
Email: gyan.s.mishra@verizon.com
Thomas Graf
Swisscom
Binzring 17
CH- CH-8045 Zurich
Switzerland
Email: thomas.graf@swisscom.com
Xie, et al. Expires 7 October 2025 [Page 22]