Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service
draft-ietf-v6ops-framework-md-ipv6only-underlay-14
| Document | Type | Active Internet-Draft (v6ops WG) | |
|---|---|---|---|
| Authors | Chongfeng Xie , Chenhao Ma , Xing Li , Gyan Mishra , Thomas Graf | ||
| Last updated | 2025-10-08 | ||
| Replaces | draft-xie-v6ops-framework-md-ipv6only-underlay | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Mahesh Jethanandani | ||
| Send notices to | (None) |
draft-ietf-v6ops-framework-md-ipv6only-underlay-14
v6ops Working Group C. Xie
Internet-Draft C. Ma
Intended status: Informational China Telecom
Expires: 12 April 2026 X. Li
CERNET Center/Tsinghua University
G. Mishra
Verizon Inc
T. Graf
Swisscom
9 October 2025
Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-
a-Service
draft-ietf-v6ops-framework-md-ipv6only-underlay-14
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 12 April 2026.
Xie, et al. Expires 12 April 2026 [Page 1]
Internet-Draft Multi-domain IPv6-only Underlay October 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . 10
6. Framework Introduction . . . . . . . . . . . . . . . . . . . 11
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Mapping Rule Processing at the Control Layer . . . . . . 12
6.3. Packet Processing at the Forwarding Layer . . . . . . . . 13
7. IPv6 Mapping Prefix Allocation . . . . . . . . . . . . . . . 15
8. Applicability of SRv6 for Multi-domain IPv6-only Network . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Authenticity and Integrity of Packets . . . . . . . . . . 16
9.2. BGP-4 and Multiprotocol Extensions for BGP-4 . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Xie, et al. Expires 12 April 2026 [Page 2]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
1. Introduction
IPv6 capabilities have been widely deployed over the past decade,
with IPv6 traffic growing at a faster rate than IPv4. 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, to date various
transition technologies like 464XLAT [RFC6877], MAP-T [RFC7599],
MAP-E [RFC6333] and DS-Lite [RFC6333] have been developed and
deployed[RFC9313]. These 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. [I-D.ietf-v6ops-6mops] illustrates a deployment scenario
called "an IPv6-Mostly network", when IPv6-only and IPv4-enabled
endpoints coexist on the same network (network segment, VLAN, SSID
etc). It allows IPv6-capable devices to remain IPv6-only while the
network is seamlessly supplying IPv4 access to those that require it.
Xie, et al. Expires 12 April 2026 [Page 3]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
However, the current IPv6-only ecosystem remains incomplete,
particularly in backbone networks. For large-scale network
operators, a comprehensive multi-domain IPv6-only framework is needed
to integrate multiple related technologies to ensure seamless IPv4
and IPv6 data transmission. A key objective is enabling efficient
cross-domain IPv4 service delivery across IPv6-only network,
utilizing tunneling or translation to forward data between edge
devices. With such a framework, 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 a large-scale
IPv6-only network from network operators' 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. When transmitting IPv4 service data, this
framework enables end-to-end tunneling across multiple network
providers, and therefore is different from existing SRv6/MPLS VPN
solutions which are for a single NP. In addition, networks
implemented under this framework can integrate with other IPv6-only
access methods.
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.
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.
Xie, et al. Expires 12 April 2026 [Page 4]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
* 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.
* MD: Mapping rule Database.
* NP: Network Provider.
* 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]).
* ADPT: Adapter in PE, a function entity that implements the two-way
IPv4 and IPv6 packet conversion for IPv4 service delivery over
IPv6-only network.
* Conversion point: A function that converts between IPv4 and IPv6
realms, such as the translation (XLAT) function defined in
[RFC6144]
* RAN: Radio Access Network.
* WKP: Well-Known Prefix.
Xie, et al. Expires 12 April 2026 [Page 5]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
3. Scenarios
For the purpose of the framework described in this document, an
IPv6-only network is defined as a cluster of inter-connected ASes
where the underlay network is IPv6, with no IPv4 present. An
IPv6-only network may interconnect with external networks, including
IPv4-only networks.
As a general network infrastructure, an IPv6-only network should
support the following scenarios,
Scenario 1: IPv6 user accessing an IPv4 server, i.e., an
IPv6-only user accesses to an IPv4-based service hosted in a data
center or other places.
Scenario 2: IPv4 user accessing an IPv4 server, i.e., an
IPv4-only user accesses to an IPv4-based service hosted in a data
center or other places.
Scenario 3: IPv6 user accessing an IPv6 server, i.e., an
IPv6-only user accesses to an IPv6-based service hosted in a data
center or other places.
Scenario 4: IPv4 user accessing an IPv6 server, i.e., an
IPv4-only user accesses to an IPv6-based service hosted in a data
center or other places.
Scenario 5: DC-to-DC, i.e., an IPv6-only network provides
communications between servers hosted in different data centers,
regardless of whether they are IPv4, IPv6 or IPv4/IPv6 dual-
stack.
Scenario 6: Transit for neighbor networks, i.e., an IPv6-only
network interconnects multiple isolated IPv4-only networks,
enabling IPv4 packet transmission over the IPv6 infrastructure.
Scenario 7: Mobile transport network, mobile operators can
utilize IPv6-only to connect the RAN and 5G core network,
delivering the specific connectivity services required for 5G
application operations.
It should be noted the scenarios listed above represent only a subset
of those supported by IPv6-only networks, which are at least as
capable as current dual-stack networks.
Xie, et al. Expires 12 April 2026 [Page 6]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
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 is called "Multi-domain
Underlay Network" in this document. 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 operators 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 from the perspective of
operators, Figure 1 shows a multi-domain network, namely N1, which
consists of three interconnected ASes, i.e., AS1, AS2, and AS3.
Among them, AS1 and AS2 are operated by operator NP-1, AS3 is
operated by operator NP-2. Routers located outside the backbone but
directly connected to it are referred to as Customer Edge (CE)
routers. AS1 of NP-1 provides connectivity services to mobile, home
broadband, and enterprise customers, represented by CE1, CE2, and
CE3, respectively. [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 should support at least two connectivity modes for data
centers: the first is the mode between data center and individual
users, for instance, the user of CE1 accesses the service hosted in
DC1, the second is the mode between data centers, for instance,
communications between service instances hosted in DC1 and DC2
respectively.
Regarding external interconnection, NP-3 is a neighboring operator of
NP-2. AS4 of NP-3 is an IPv4-only network and does not support IPv6.
AS4 and AS3 are interconnected via BGP.
Xie, et al. Expires 12 April 2026 [Page 7]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
+-------+ +-------+
| DC1 | | DC2 |
+-------+ +-------+
| |
+----+ /-------|-----------------\ /------|-------\
|UE/ |\ | | | | | |
|CE2 | \ | | | | | |
+----+ \| PE2 +-+ | | PE4 |
|\ / \ / \ | | / \ | +---+
+----+ | \ | AS1 | | AS2 | | | | AS3 | | / \
|UE/ |---+- PE1 P1--P2 P3--+---+--P4 PE3--+----BR1 AS4 |
|CE1 | | / | | | | | | | | | \ NP-3/
+----+ |/ \ / \ / | | \ / | +---+
| +-+ +-+ | | +-+ |
+----+ /| | | |
|UE/ | / | NP-1 | | NP-2 |
|CE3 |/ | | | |
+----+ | | | |
\-------------------------/ \--------------/
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, PE3 and PE4, support IPv4 on interfaces facing IPv4 client
networks and IPv6 on interfaces facing the core, requiring them to
handle both address families. Network N1 transports packets that
originate and terminate outside the network. These packets enter the
IPv6 network at a PE router, traverse the network, and exit through
another PE router to continue their path.
In addition, the IPv6-only deployment in network N1 must ensure the
continued operation of remaining IPv4 services without degrading user
experience. As some Internet services may remain IPv4-based even in
an IPv6-dominated environment. Therefore, an IPv6-only network
should support access to IPv4-only services, as well as native IPv6
services. [RFC6992] describes a routing scenario where IPv4 packets
are transported over an IPv6 network, based on [RFC7915] and
[RFC6052], along with a separate OSPFv3 routing table for
IPv4-embedded IPv6 routes in the IPv6 network. Since it is based on
the OSPF protocol, it supports IPv4aaS within a single AS.
For a multi-domain network operator, deploying IPv6-only without a
unified framework may lead to independent adoption of IPv6 transition
approaches across different ASes. This can result in multiple
IPv6-only islands interconnected by IPv4 links between domains. With
Xie, et al. Expires 12 April 2026 [Page 8]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
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 device will also
have one or more associated IPv4 address blocks which are extracted
from local IPv4 routing table or address pool. The mapping
relationship between an IPv4 address block and its corresponding IPv6
prefix is referred to as a mapping rule, which will have at least the
following data structure.
IPv4 address block: Pref6(PE)
It should be noted that the mapping rule contains not only the data
structure above, but also other necessary information to support IPv4
service delivery over IPv6-only network, the detailed structure
definition of the mapping rule is out of the scope of this document.
The mapping rule of destination address will determine the direction
of IPv4 service data transmission in a multi-domain IPv6-only
network. When the mapping rule corresponding to the destination
address of a given IPv4 packet is available, the ingress PE can
generate corresponding IPv6 source and destination addresses from its
IPv4 source and destination address as below,
* The IPv6 source address is derived by appending the IPv4 source
address to its local IPv6 mapping prefix, i.e., Pref6(ingress PE).
* The IPv6 destination address is derived by appending the IPv4
destination address to the Pref6(egress PE) in the mapping rule.
Since mapping rule adopts prefix-level mapping, there is no need to
maintain user-related status or translation tables for packet
transformation at the PE devices.
Xie, et al. Expires 12 April 2026 [Page 9]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
[RFC6052] illustrates the algorithmic translation of an IPv4 address
to a corresponding IPv6 address, and vice versa, using only
statically configured information. With this approach, IPv4-embedded
IPv6 addresses are composed by concatenating the prefix, the 32 bits
of the IPv4 address, and the suffix (if needed) to obtain a 128-bit
address. The prefixes can only have one of the following lengths:
32, 40, 48,56, 64, or 96.
For IPv4 service delivery across a multi-domain IPv6-only network, it
is proposed that IPv4 address is located at the last 32 bits of the
IPv6 address, most significant bits first. The bits between IPv6
mapping prefix and IPv4 address can be set to zero and are reserved
for future extensions. Examples of such representations are
presented in Table 1.
+-------------------+------------+--------------------------+
|IPv6 mapping prefix|IPv4 address|IPv4-embedded IPv6 address|
+-------------------+------------+--------------------------+
|2001:db8::/32 |192.0.2.33 |2001:db8::192.0.2.33 |
|2001:db8:100::/40 |192.0.2.33 |2001:db8:100::192.0.2.33 |
|2001:db8:122::/48 |192.0.2.33 |2001:db8:122::192.0.2.33 |
+-------------------+------------+--------------------------+
Table 1. Text Representation of IPv4-Embedded IPv6 Address
Prior to IPv4/IPv6 packets conversion, the mapping rule for the
destination address needs to be obtained remotely in advance. To
meet this requirement, specific mechanism of mapping rule exchange
needs to be designed, the exchange can be within or across domains.
Using the mapping rule exchange mechanism, an egress PE can inform
other PEs that an IPv4 packet with a destination address within the
IPv4 address block of a mapping rule should be forwarded to the
egress PE identified by the corresponding IPv6 mapping prefix.
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) from a client-facing interface,
it queries its mapping rule database(i.e., MD) 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 NP-1, while the
egress PE3 is in NP-2. 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
Xie, et al. Expires 12 April 2026 [Page 10]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
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---| IPv4 |
|CE | | IPv6 | | IPv6 | | IPv6 | \ NW /
+----+ \ / \ / \ / +--+
+--+ +--+ +--+
Figure 2. End-to-end IPv4 Service Delivery from Ingress to Egress
It should be noted that P3 and P4 are Ps from the perspective of the
framework defined by this document, but they are PEs from the NPs'
perspective for they are at the edge of the NPs' networks.
It can be seen that such a multi-NP tunneling requires only two-end
NPs to support this solution for it to work, it has no specific
requirements for NPs in the middle of the path, as long as it
supports IPv6.
6. Framework Introduction
6.1. Overview
This section describes the framework of multi-domain IPv6-only
underlay network from NP' perspective. As shown in Figure 3, the
whole framework comprises PE devices at the edge, core P devices and
customer-side IPv4 routers. In this framework, the PE devices are
responsible for implementing stateless IPv4/IPv6 packet conversion,
and they are required to support the following functions,
1. RP(Rule Processing):
* Manage the mapping relationships between IPv4 address blocks and
their corresponding IPv6 prefixes.
* Exchange of mapping rules and associated routing information
between PEs at the routing layer.
Xie, et al. Expires 12 April 2026 [Page 11]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
2. PT(Packet Transformation):
* Generate IPv4-embedded IPv6 packets using either translation or
encapsulation for IPv4 data delivery.
The combination of the two functions above forms an adaptation (ADPT)
within PE for transmitting IPv4 service data in IPv6-only network.
There is no specific requirements to the P devices.
+-------------------------------------------+
| PE1 /---------\ | +-------+
+-------+ | | ADPT | | | PE2 |
| | | +-------+ | +-----| | | | +---+ |
| +---+-+IPv4 | | | +--+---------------|----+-+ RP| |
| | | |routing+-----+--+ | | | | +---+ |
| | | |engine | | | | | | +---+---+
| | | +-------+ | | RP | | +-------+ | |
| | | | | | | | | IPv6 | | +---+---+
| R1 | | | | | +--+---+routing+---+----+ |
|(IPv4 | | | | | | | |engine | | | |
|Router)| | | | +-----+ | +---+---+ | | P1 |
| | | | | | | | |(IPv6) |
| | | +----------+ | +-----+ | +---+------+| | |
| | | |IPv4 | | | | | |IPv6 || | |
| +---+-+packet +--+--+ PT +--+---+packet ++----+ |
| | | |forwarding| | | | | |forwarding|| +-------+
+-------+ | +----------+ | +-----+ | +----------+|
| \_________/ |
+-------------------------------------------+
RP: Rule Processing
PT: Packet Transformation
Figure 3. Multi-domain IPv6-only Underlay Network Framework
6.2. Mapping Rule Processing at the Control Layer
In this framework, IPv4/IPv6 address mapping rules are processed at
the control layer, which includes two processes,
1. Mapping Rule Generation
In Figure 3, IPv4 routing engine of PE1 receives an IPv4 BGP
route advertisement sent by IPv4 router R1 and generates an IPv4
route entry. The RP function of PE1 extracts IPv4 address blocks
from its IPv4 BGP routing instance and generates device-specific
mapping rules by combining them with its IPv6 mapping prefix.
Xie, et al. Expires 12 April 2026 [Page 12]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
Each PE stores all mapping rule entries in its local MD database,
whether locally generated or received from other PEs. The RP
function also supports management operations such as insertion,
modification, and deletion of mapping rules.
If certain IPv4 address blocks are not explicitly announced by
any egress PEs to the ingress PE, the ingress PE 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)
2. Mapping Rule Transport
For IPv4 service delivery, IPv4/IPv6 address mapping rules need
to be exchanged between PEs at the routing layer. This process
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 IPv4 destination
address.
When a mapping rule is generated locally, PE1 converts it into a
data structure compatible with the IPv6 routing system and
forwards it to the IPv6 routing engine. In the opposite
direction, when PE1 receives a routing update from the IPv6
routing engine, it extracts the embedded mapping rule and store
it locally for further processing. It can seen that, based on
the address mapping rule received, the PE who has sent the
mapping rule (i.e., Egress PE) is visible to the ingress PE. To
enable mapping rule transmission at the routing layer, extensions
to MP-BGP or other control protocols would be required, a typical
approach is [I-D.ietf-idr-mpbgp-extension-4map6].
6.3. Packet Processing at the Forwarding Layer
In this framework, Forwarding Layer provides data forwarding
capability 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
Xie, et al. Expires 12 April 2026 [Page 13]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
Translation refers to the packet conversion from one protocol
format to the other. When the PT function receives an IPv4
packet from the IPv4 packet forwarding module, it queries the
local MD database which store all the address mapping rule, if a
mapping rule exists for the IPv4 destination address, it will
generate corresponding IPv6 source and destination addresses from
the IPv4 addresses, following the procedure described in
Section 5.1. This process should comply with [RFC7915].
Upon receiving the IPv6 packet, the egress PE firstly checks
whether its destination IPv6 prefix matches its own IPv6 mapping
prefix. If not, it discards or forwards it as a regular IPv6
packet. Otherwise, it the egress PE extracts the original IPv4
source and destination addresses from the IPv4-embedded IPv6
addresses and reconstructs the IPv4 packet, this process should
comply with [RFC7915]. The IPv4 packet is then forwarded based
on the IPv4 routing table maintained at the egress PE.
2. Encapsulation
The address mapping process for encapsulation follows the same
procedure as translation: When the PT function receive an IPv4
packet from the IPv4 forwarding module, it queries the local MD
database which store all the address mapping rule, if a mapping
rule exists for the IPv4 destination address, it will generate
corresponding IPv6 source and destination addresses from the IPv4
addresses, following the procedure described in Section 5.1.
This process should comply with [RFC7915].
Upon receiving the IPv6 packet, the egress PE firstly checks
whether its destination IPv6 prefix matches its own IPv6 mapping
prefix. If not, it discards or forwards it as a regular IPv6
packet. Otherwise, the egress PE decapsulation it by removing
outer IPv6 header and restores the IPv4 packet. The IPv4 packet
is then forwarded based on the IPv4 routing table maintained at
the egress PE.
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.
Xie, et al. Expires 12 April 2026 [Page 14]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
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:
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 as
regular IPv6 packets without requiring a specific FIB entry for
the mapping prefix.
Xie, et al. Expires 12 April 2026 [Page 15]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
Cons:
If the operator has not implemented specific address prefix
planning and policy configuration, interworking between operators
may result in the same IPv4 address block receiving multiple NSP
prefixes from different operators. This can generate multiple
IPv6 mapping routes, potentially increasing the size of IPv6
routing tables (including FIB and RIB).
As specified in Section 5.1, each PE must be assigned at least one
IPv6 mapping prefix. This prefix serves as the fundamental
information for forwarding IPv4-embedded IPv6 packets to the correct
egress PE. Operators should carefully determine the IPv6 mapping
prefix length during implementation. The length of all the IPv6
mapping prefixes is recommended to be the same, to avoid unnecessary
processing cost and complexity induced by the prefix length
diversity.
8. Applicability of SRv6 for Multi-domain IPv6-only Network
SRv6 [RFC8986] enables network operators to specify a packet
processing program by encoding a sequence of Segment IDs (SIDs) in
the IPv6 packet header. It can also use specific SIDs (e.g., DT4 or
DX4) to transport IPv4 packets across an IPv6-only network from one
PE device to another. However, SRv6 is a generally single-NP
solution and not suitable for a multi-NP scenario, for the current
specification assumes SRv6 deployment within a trusted domain, this
may limit the joint deployment of IPv6-only by multiple operators.
In addition, if Traffic Engineering (TE) is needed in the case of
Single-NP deployment, SRv6 can be used. With SRv6, IPv6-only network
can optimize network performance by controlling traffic paths to
avoid congestion and balance load.
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
recovers the received IPv6 packets into IPv4 packets, they are routed
based on the destination IPv4 address and enter the Internet. Since
Xie, et al. Expires 12 April 2026 [Page 16]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
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, Mohamed
Boucadair, 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, Daryll Swer, Tim Wicinski, 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
Linjian Song
Alibaba Cloud
China
Xie, et al. Expires 12 April 2026 [Page 17]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
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>.
[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>.
13.2. Informative References
Xie, et al. Expires 12 April 2026 [Page 18]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
[I-D.ietf-idr-mpbgp-extension-4map6]
Xie, C., Dong, G., Li, X., Han, G., and Z. Guo, "MP-BGP
Extension and the Procedures for IPv4/IPv6 Mapping
Advertisement", Work in Progress, Internet-Draft, draft-
ietf-idr-mpbgp-extension-4map6-04, 14 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
mpbgp-extension-4map6-04>.
[I-D.ietf-spring-srv6-security]
Buraglio, N., Mizrahi, T., tongtian124, Contreras, L. M.,
and F. Gont, "Segment Routing IPv6 Security
Considerations", Work in Progress, Internet-Draft, draft-
ietf-spring-srv6-security-07, 18 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-security-07>.
[I-D.ietf-v6ops-6mops]
Buraglio, N., Caletka, O., and J. Linkova, "IPv6-Mostly
Networks: Deployment and Operations Considerations", Work
in Progress, Internet-Draft, draft-ietf-v6ops-6mops-02, 26
August 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-v6ops-6mops-02>.
[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>.
Xie, et al. Expires 12 April 2026 [Page 19]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
[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>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[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>.
Authors' Addresses
Chongfeng Xie
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: xiechf@chinatelecom.cn
Xie, et al. Expires 12 April 2026 [Page 20]
Internet-Draft Multi-domain IPv6-only Underlay October 2025
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
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 12 April 2026 [Page 21]