Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service
draft-ietf-v6ops-framework-md-ipv6only-underlay-04
| Document | Type | Active Internet-Draft (v6ops WG) | |
|---|---|---|---|
| Authors | Chongfeng Xie , Chenhao Ma , Xing Li , Gyan Mishra , Mohamed Boucadair , Thomas Graf | ||
| Last updated | 2024-02-04 | ||
| 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 | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-v6ops-framework-md-ipv6only-underlay-04
v6ops Working Group C. Xie
Internet-Draft C. Ma
Intended status: Informational China Telecom
Expires: 7 August 2024 X. Li
CERNET Center/Tsinghua University
G. Mishra
Verizon Inc
M. Boucadair
Orange
T. Graf
Swisscom
4 February 2024
Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-
a-Service
draft-ietf-v6ops-framework-md-ipv6only-underlay-04
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.
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 August 2024.
Xie, et al. Expires 7 August 2024 [Page 1]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
Copyright Notice
Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Focus on IPv6-only Network . . . . . . . . . . . . . . . . . 5
4. Motivation for Considering Multi-domain Factor in IPv6-only
Network Deployment . . . . . . . . . . . . . . . . . . . 6
5. Requirements from Service Traffic . . . . . . . . . . . . . . 9
6. Description of the Framework . . . . . . . . . . . . . . . . 11
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. ADPT Description . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Rule Processing Layer . . . . . . . . . . . . . . . . 13
6.2.2. Rule Transport Layer . . . . . . . . . . . . . . . . 14
6.2.3. Data Forwarding Layer . . . . . . . . . . . . . . . . 15
6.3. IPv6 Mapping Prefix Allocation . . . . . . . . . . . . . 16
6.4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Integration with IPv6-only Access Mechanisms . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Authenticity and Integrity of Packets . . . . . . . . . . 19
8.2. BGP-4 and Multiprotocol Extensions for BGP-4 . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 transition deployment status and how the transition
to IPv6 is progressing among network operators and enterprises.
Xie, et al. Expires 7 August 2024 [Page 2]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
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 experience abnormal access to
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 furthermore
when IPv6 usage is 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(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]. These technologies 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] adopts AFTR-based 4over6 tunneling technology.
This document specifies the requirements for multi-domain IPv6-only
underlay network and proposes a general framework for network
operators. The objective of such a framework is to help large-scale
operators implement the transition to IPv6-only and support cross-
domain, end-to-end IPv4 service delivery over IPv6-only network. In
this document, the term of “IPv6-only network” stands for “IPv6-only
underlay network”, unless there is a specific statement. This
document does not introduce any new IPv6 transition mechanisms nor
IPv4aaS.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14[RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Xie, et al. Expires 7 August 2024 [Page 3]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
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 the same
operator.
* 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) routing protocol and peering with
the BGP router of external AS.
* 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 underlay network.
Xie, et al. Expires 7 August 2024 [Page 4]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
* 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. Focus on IPv6-only Network
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 Internet Exchange Point
(IXP)[I-D.ietf-bess-ipv6-only-pe-design], this serves to eliminate
IPv4 provisioning at the Edge of IXP that are 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 underlay network will support in the future.
Xie, et al. Expires 7 August 2024 [Page 5]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
4. Motivation for Considering Multi-domain Factor in IPv6-only Network
Deployment
Generally, the whole network of large-scale operators comprise
multiple autonomous systems (ASes). Different ASes may serve
different scenarios, such as metro network, backbone network, 4G or
5G mobile core, data center network and are often managed by
different departments or institutions, using different routing and
security policies.
A typical model of multi-domain network is shown in figure 1.
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 UE1, UE2 and UE3 respectively in
figure 1. 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 these multiple sites, both on-premises and
in data centers. Multi-domain network needs to provide connections
for data center. Network 1 supports at least two connection modes of
data centers, the first is the communication mode between data center
and individual users, for instance, the user of CPE1 accesses the
service hosted in DC1, the second is the connection mode between data
centers, for instance, communications between service instances
hosted in DC1 and DC2 separately.
Network N1 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. 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).
Xie, et al. Expires 7 August 2024 [Page 6]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
----- -----
/ \ / \
| DC1 | | DC2 |
\ / \ /
----- -----
---------|--------------|---------
| | (Operator1) | |
| +---+ N1 +---+ |
| |PE3| |PE4| | (Operator2)
| +---+ +---+ | +--+
| / \ / \ | / \
+----+ | +---+ +--+ +--+ +---+ | +---+ +
|UE/ |---|PE1| AS1 |R1|-|R2| |PE5|---|BR1| AS4 |
|CPE1| | +---+ +--+ +--+ +---+ | +---+ +
+----+ | \ / | | | \ /
| +--+ | | | +--+
| |R5| | | |
| +--+ | AS3 | |
| | | | |
| +--+ | | |
+----+ | |R6| | | | (Operator3)
|UE/ | | +--+ | | | +--+
|CPE2|\| / \ | | | / \
+----+ \ +---+ +--+ +--+ +---+ | +---+ +
|-|PE2| AS2 |R3|-|R4| |PE6|---|BR2| AS5 |
+----+ / +---+ +--+ +--+ +---+ | +---+ +
|UE/ |/| \ / \ / | \ /
|CPE3| | ---- ----- | +--+
+----+ | |
----------------------------------
Figure 1. Multi-domain IPv6 Underlay Network Model
For Network N1, 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, after which they leave the network and
continue their way.
Xie, et al. Expires 7 August 2024 [Page 7]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
When IPv4 capabilities are 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 only supports IPv4aaS within a single AS.
For one multi-domain network, when introducing the IPv6-only scheme
without collaboration between ASes, different ASes adopt the IPv6
transition approach independently, the result is that multiple
IPv6-only islands are connected by IPv4 links between domains. As
shown in figure 2, there will be more 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, there is an urgent need for
multi-domain IPv6-only solution to eliminate unnecessary conversion
functions and improve data forwarding efficiency.
Xie, et al. Expires 7 August 2024 [Page 8]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
+---+ +---+ +------+
|UE/|--|PGW| | IPv4 |
|CPE| +---+ |Server|
+---+ | +------+
| |
----------- -----------
/Mobile Core\ / \
| Network | | IPv4 |
| (IPv6-only) | | Internet |
\ / \ /
----------- -----------
| |
+-----+ +--------+
|PLAT/| |IPv4 BGP|
|NAT64| | Router |
+-----+ +--------+
| IPv4 link |IPv4 link
| ----------- |
+---------+ / Backbone \ +---------+
|Stateless|----| Network |----|Stateless|
| NAT64 | \(IPv6-only)/ | NAT64 |
+---------+ ----------- +---------+
XLAT-1 XLAT-2
Figure 2: IPv6-only Independent Deployment in Multi-domain Network
5. Requirements from Service Traffic
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: IPv4-as-a-Service
It should provide IPv4 service delivery and there should be no
perceived degradation of customer experience when accessing the
remaining IPv4 services.
Requirement 3: optimized end-to-end
Xie, et al. Expires 7 August 2024 [Page 9]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
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 types 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,
so all IPv4 packets which reach the edge of the network should 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 need 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 point. The border ASBR
that is interworking with external networks should be unaware of the
user-related information, it only needs to perform stateless
translation or encapsulation/decapsulation when necessary.
Requirement 6: high scalability
Xie, et al. Expires 7 August 2024 [Page 10]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
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 should deploy 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. Description of the Framework
6.1. Overview
Multi-domain IPv6-only network should support the forwarding of IPv4
service data, after transforming IPv4 packets into IPv6 ones in the
UE/CPE or at the edge of the network. Take the latter case as an
example, when IPv4 packets that need to traverse lPv6-only network,
the ingress PE, i.e., PE1, will convert IPv4 packets into lPv6
packets by translation or encapsulation and send them into IPv6
network. After intra-domain and cross-domain transmission, the IPv6
packets reach the egress PE, i.e., PE2, then be restored to IPv4
packets.
As can be seen from the above, the routing of IPv4 service data in
the form of IPv6 packet will follow topology of IPv6 network. With
this framework, each PE will be allocated and identified by at least
one IPv6 mapping prefix, denoted by Pref6(PE), it will also have one
or more associated IPv4 address blocks which are extracted from local
IPv4 routing table or address pool. The mapping relationship between
IPv4 address block and IPv6 mapping prefix is called mapping rule in
this context. The mapping rule announced by a given PE will have at
least the following data structure,
IPv4 address block: Pref6(PE)
Since this is prefix-level mapping, there is no need to maintain
user-related status or translation tables at the PE devices.
Xie, et al. Expires 7 August 2024 [Page 11]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
Mapping rules are used by the ingress to generate corresponding IPv6
source and destination addresses from its IPv4 source and destination
address when its egress is the given PE, and vice versa.
-The IPv6 source address is derived by appending the IPv4 source
address to the Pref6(ingress PE).
-The IPv6 destination address is derived by appending the IPv4
destination address to the Pref6(egress PE) in the mapping rule,
which needs to be obtained remotely in advance.
[RFC6052] illustrates the algorithmic translation of an IPv4 address
to a corresponding IPv6 address, and vice versa, using only
statically configured information. With this approach, IPv4-embedded
IPv6 addresses are composed by concatenating the prefix, the 32 bits
of the IPv4 address, and the suffix (if needed) to obtain a 128-bit
address. The prefixes can only have one of the following lengths:
32, 40, 48,56, 64, or 96.
For the deployment scenario in this document, it proposed that IPv4
address is located at the last 32 bits of the IPv6 address, most
significant bits first. The bits between IPv6 mapping prefix and
IPv4 address SHOULD be set to zero and are reserved for future
extensions. Examples of such representations are presented in
Table 1.
+-------------------+------------+--------------------------+
|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
Using the mechanism of mapping rule exchange in IPv6-only network, an
egress PE can tell other PEs that IPv4 packet whose IPv4 destination
address is within the scope IPv4 address block of the mapping rule,
can be forwarded in the IPv6-only network through the egress PE
identified by the corresponding IPv6 mapping prefix of the mapping
rule. This mapping rule can be transmitted across domains.
Therefore, it gives the direction of IPv4 service data transmission
in multi-domain IPv6-only network.
It should be noted that the mapping rule contains not only the data
structure above, but also other necessary information to support IPv4
service delivery over IPv6-only network, the detailed structure of
the mapping rule is out of the scope of this document.
Xie, et al. Expires 7 August 2024 [Page 12]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
Although this document illustrates the framework of multi-domain
IPv6-only network operated by a single operator, this multi-domain
model can naturally be extended to IPv6-only network which is
operated by multiple operators.
6.2. ADPT Description
This section illustrates the framework of multi-domain IPv6 network
from the perspective of ADPT in PE devices. ADPT is the entity in PE
which accommodates the conversion of IPv4 packets into IPv6 ones for
IPv4 service delivery over IPv6-only network. ADPT comprises the
following components, as shown in figure 3.
+----- + +--------------------------------------------+
| | | PE1 /------------\ | +-------+
| | | | ADPT | | |PE2 |
| | |+-------+ | +-----+ | | | +---+ |
| | ||IPv4 | I3 | | | | I1 | | | | |
| +-++routing+--+--+------+ RP +-+-----+--------+-|-+RP | |
| | ||engine | | +---+ | | | | | | |
| | |+-------+ | | +--+--+ | | | +---+ |
| | | | | +I7 +I2 | | |_______|
| | | | | | +--+--+ | +-------+ |
| | | | |+-++ | | |I4|IPv6 | | +------+
|R1 | | | ||MD| | RT +-+-++routing+---+--+ |
|IPv4 | | | |+-++ | | | |engine | | | |
|Router| | | | | +-----+ | +---+---+ | |R2 |
| | | | | +I8 | | | |IPv6 |
| | |+----------+ | | +-----+ | +---+------+| |Router|
| | ||IPv4 |I5| +---+ | |I6|IPv6 || | |
| +-++packet +-++------+ DF +-+-++packet ++--+ |
| | ||forwarding| | | | | |forwarding|| | |
| | |+----------+ | +-----+ | +----------+| +------+
| | | |______________| |
+------+ +--------------------------------------------+
RP: Rule Processing Layer
RT: Rule Transport Layer
DF: Data Forwarding Layer
MD: Mapping rule Database
Figure 3. Framework of Multi-domain IPv6-only Network
6.2.1. Rule Processing Layer
The Rule Processing Layer, i.e., RP, deals with the management of
mapping relationship between IPv4 address block and IPv6 mapping
prefix of PEs, as shown in figure 3.
Xie, et al. Expires 7 August 2024 [Page 13]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
In each PE, there is a Mapping rule Database, i.e., MD, to store all
the mapping rule records it receive from other PEs. Rule Processing
Layer provides management functions to Mapping rule Database through
interface I7, for example, insertion, modification, or deletion
mapping rules. The interface with the ADPT of other PE is I1, which
is used for the exchanging of mapping rule with each other. The
interface with Rule Transport Layer, which will be illustrated in
section 6.2.2, is I2, which is used for the transmission of mapping
rule through Rule Transport Layer. PE1 can extract the IPv4 address
blocks from its IPv4 BGP routing instance through interface I3, and
generate the mapping rules of the device in combination with its own
IPv6 mapping prefix. When the mapping rules are ready, they will be
sent to Rule Transport Layer through interface I2. Correspondingly,
PE1 will receive the mapping rules of other PEs through interface I2
and stores them in the local Mapping rule Database.
For some IPv4 address blocks which are not announced explicitly by
any egress PEs to the ingress PE, there will be no corresponding
mapping rule in the Mapping rule Database. To solve this problem,
the default egress PE is defined in this framework, which announces
the default IPv6 mapping rule with the default mapping prefix to
other PEs. The format of the mapping rule for default IPv4 address
is as follows,
0.0.0.0/0: Pref6(PE)
6.2.2. Rule Transport Layer
Rule Transport Layer, i.e., RT, is in charge of the exchanging of
mapping rule with other PEs and its related routing information at
the routing layer. The exchanging of the mapping rule should precede
to the process of IPv4 data transmission, otherwise, the data
originated from IPv4 network will be dropped due to the absence of
the IPv6 mapping prefix corresponding to its destination address.
When the request of the mapping rule from Rule Processing Layer
through interface I2 is being received, Rule Transport Layer will
convert the mapping rule into data structure that is suitable for the
transmission in the IPv6 routing system and send it to the IPv6
routing engine through interface I4. In opposite direction, when
receiving the routing information from IPv6 routing engine through
interface I4, Rule Transport Layer will extract mapping rule from the
routing information and send it to the Rule Processing Layer.
Xie, et al. Expires 7 August 2024 [Page 14]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
To support the transmission of mapping rules at the routing layer,
MP-BGP4 protocol or other control protocols needs to be extended.
However, this has been out of the scope of the draft and will be
discussed in other documents. In addition, Rule Transport Layer is
responsible for announcing the IPv6 route corresponding to each IPv6
mapping prefix throughout the multi-domain IPv6-only network.
6.2.3. Data Forwarding Layer
Data Forwarding Layer, i.e., DF, provides data forwarding function to
IPv6 packets, including native IPv6 packets and IPv4-embedded IPv6
packets. Multi-domain IPv6-only network needs to support both
translation and encapsulation technologies for IPv4 data delivery:
1. Translation
Translation refers to the conversion of IPv4 packets into IPv6
packets or reverse conversion. When receiving an IPv4 packet through
interface I5 from IPv4 packet forwarding module, the data forwarding
layer will look up the Mapping rule Database through the interface
I8, if the mapping rule corresponding to the IPv4 destination address
is found, the destination address of IPv6 header required for
translation is generated by appending the IPv4 address to the Pref6
in the mapping rule. Otherwise, the default IPv6 mapping prefix is
used to create the destination IPv6 address.
2. Encapsulation
Encapsulation is the process in which PE adds a new IPv6 header is to
the original IPv4 packet received, then transmits it in multi-domain
IPv6-only networks. Address mapping in encapsulation mode is same to
that in translation mode, when receiving IPv4 packet through
interface I5 from IPv4 packet forwarding module, the data forwarding
layer will look up the Mapping rule Database through the interface
I8, if the mapping rule corresponding to the IPv4 destination address
is found, the destination address of the IPv6 header required for
encapsulation is generated by appending the IPv4 address to the Pref6
in the mapping rule. If the mapping prefix corresponding to the
destination IPv4 address is not found, the default IPv6 mapping
prefix is used.
For an IPv4-embedded IPv6 packet, whether it is based on translation
or encapsulation, the Pref6 part of the destination address can
identify the egress in the network, so the forwarding of the IPv6
packet can be implemented based on the Pref6 information of the
destination address.
Xie, et al. Expires 7 August 2024 [Page 15]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
6.3. IPv6 Mapping Prefix Allocation
In order to support rule-based IPv4/IPv6 address mapping, a specific
IPv6 address range will be planned to represent IPv4 address space by
stateless mapping as with section 6.1. With this framework, there
are two options to allocate IPv6 mapping prefix:
1) WKP:
A specific WKP can be allocated from the global IPv6 address prefix,
e.g., 64:ff9b:: /96, or an IPv6 address prefix specifically assigned
for this purpose.
Pros:
Service providers do not need to allocate IPv6 address prefixes
specially used for mapping IPv4 addresses from their own IPv6 address
resources. Another benefit of using WKP is that operators can easily
control the range of IPv6 mapping routes, such as implementing
routing restrictions at the boundaries to prevent them form leaking
into other networks.
Cons:
After the IPv4 address is converted into IPv6 address with WKP, the
IPv4 part of the IPv4-embedded IPv6 address is used for the routing
of the IPv4-embedded IPv6 packet. In this way, many fine routes with
prefix length greater than 96 will be introduced into the FIB of P
routers in IPv6 network. In most networks, fine routing with long
prefix length greater than 96 is not supported.
2) NSP:
Operator allocates a specific prefix from their existing IPv6 address
resources to each PE for IPv4 addresses mapping. The IPv6 mapping
prefix varies for different PEs.
Pros:
Xie, et al. Expires 7 August 2024 [Page 16]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
Within the multi-domain network, the length of IPv6 mapping prefix
can be easily tailored to meet the requirements of IPv6 network for
routing length, and the routing of the packets can be based on the
information of IPv6 mapping prefix part of the IPv6 address. The
IPv6 mapping prefix is a part of the IPv6 address block where the PE
is located, which is routable, so IPv6 devices can forward IPv6
packets in legacy manner without setting up a specific entry for IPv6
mapping prefix in FIB. Outside the multi-domain network, because the
IPv6 mapping prefix has been included in operator's IPv6 address
prefix, it will not introduce any new routing items and affect the
global IPv6 routing system.
Cons:
If the operator does not have a specific address prefix planning and
policy configuration, in the case of operator-interworking, the same
IPv4 address block will receive NSP prefixes from different
operators, forming different IPv6 mapping routes. This may lead to
an increase scale of the routing table in the IPv6 network, including
FIB and RIB.
As mentioned earlier, each PE will be identified by at least one IPv6
mapping prefix, which is used as the basic routing information to
forward IPv4-embedded IPv6 packet to the right egress PE. For a
given operator, the selection of the length of IPv6 mapping prefix
should be given specific consideration. The length of all the IPv6
mapping prefixes should be the same, to avoid unnecessary processing
cost and complexity induced by the prefix length diversity.
6.4. Procedure
This section gives a brief overview of the procedures of the IPv4
service delivery over IPv6-only underlay network. The requisite of
IPv4 data delivery is that PEs have successfully exchanged the
mapping rules with each other. The end-to-end IPv4 data delivery
from ingress PE to egress PE can be illustrated as follows.
When an ingress PE receives an IPv4 packet from a client-facing
interface destined to a remote IPv4 network, it looks up in its
mapping rule database to find the mapping rule which best matches the
packet’s destination IP address. The IPv6 mapping prefix in the
mapping rule will help to find another PE, the egress PE. Since this
happens in multi-domain IPv6-only network, the ingress and egress may
belong to different ASes, as shown in figure 4, the ingress PE1 is in
AS 1 and egress is PE3 in AS 3. The ingress PE must convert the IPv4
destination address into IPv6 destination address using the IPv6
mapping prefix of PE3 and forward the IPv6 packet to PE3. When PE3
receives the IPv6 packet, it derives the IPv4 source and destination
Xie, et al. Expires 7 August 2024 [Page 17]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
addresses from the IPv4-embedded IPv6 addresses respectively and
restore the original IPv4 packet. Afterwards, the IPv4 packet will
be further forwarded according to the IPv4 routing table maintained
on the egress. The IPv6 data-path can be shown as below.
IPv6 Data Path
|<------------------------>|
| | (Operator2)
| ---- ----- | ----
| / \ / \ | / \
+----+ +---+ +--+ +--+ +---+ | |
|UE/ |---|PE1| AS1 |R1|-|R2| AS3 |PE3|---| AS4 |
|CPE1| +---+ +--+ +--+ +---+ | |
+----+ \ / \ / \ /
---- ----- ----
Figure 4. IPv6 Data Path from Ingress PE to Egress PE
In this case, there are only two IPv4-IPv6 conversion actions, which
occur in PE1 and PE3 respectively.
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, both the client-facing interface and the core-facing interface
are IPv6. When IPv6 packet reaches the ingress PE, the ingress PE
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.
Xie, et al. Expires 7 August 2024 [Page 18]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
IPv6 Data Path
|<--------------------------------->|
| | (Operator2)
| ---- ----- | ----
| / \ / \ | / \
+----+ +---+ +--+ +--+ +---+ | |
|UE/ |---|PE1| AS1 |R1|-|R2| AS3 |PE3|---| AS4 |
|CPE1| +---+ +--+ +--+ +---+ | |
+----+ \ / \ / \ /
---- ----- ----
Figure 5. IPv6 Data Path from UE/CPE to Egress PE
In this case, there are only one stateless IPv4-IPv6 conversion
action, which occurs in PE3. Compared with the case of independent
deployment model mentioned in section 5, with the new framework the
quantity of IPv4-IPv6 conversion points has been reduced from three
to one. Besides 464XLAT, other IPv6-only technologies, such as DS-
Lite, Lightweight 4over6, MAP-T/MAP-T, can also be integrated into
the multi-domain IPv6-only framework.
8. Security Considerations
Besides regular security checks on configured mapping rules, the
following two aspects need to be considered as well.
8.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. 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.
Xie, et al. Expires 7 August 2024 [Page 19]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
8.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.
9. IANA Considerations
There are no other special IANA considerations.
10. Acknowledgment
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, Guoliang Han, Weiqiang
Cheng, Aijun Wang, Tianran Zhou and Huaimo Chen for their review and
comments.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
August 2003, <https://www.rfc-editor.org/info/rfc3587>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>.
Xie, et al. Expires 7 August 2024 [Page 20]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009,
<https://www.rfc-editor.org/info/rfc5565>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/info/rfc7915>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
[IAB-statement]
"IAB statement",
<https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213,
DOI 10.17487/RFC4213, October 2005,
<https://www.rfc-editor.org/info/rfc4213>.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
April 2011, <https://www.rfc-editor.org/info/rfc6144>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<https://www.rfc-editor.org/info/rfc6333>.
Xie, et al. Expires 7 August 2024 [Page 21]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
[RFC6992] Cheng, D., Boucadair, M., and A. Retana, "Routing for
IPv4-Embedded IPv6 Packets", RFC 6992,
DOI 10.17487/RFC6992, July 2013,
<https://www.rfc-editor.org/info/rfc6992>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<https://www.rfc-editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <https://www.rfc-editor.org/info/rfc7599>.
[RFC8585] Palet Martinez, J., Liu, H. M.-H., and M. Kawashima,
"Requirements for IPv6 Customer Edge Routers to Support
IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May
2019, <https://www.rfc-editor.org/info/rfc8585>.
[RFC9313] Lencse, G., Palet Martinez, J., Howard, L., Patterson, R.,
and I. Farrer, "Pros and Cons of IPv6 Transition
Technologies for IPv4-as-a-Service (IPv4aaS)", RFC 9313,
DOI 10.17487/RFC9313, October 2022,
<https://www.rfc-editor.org/info/rfc9313>.
[RFC9386] Fioccola, G., Volpato, P., Palet Martinez, J., Mishra, G.,
and C. Xie, "IPv6 Deployment Status", RFC 9386,
DOI 10.17487/RFC9386, April 2023,
<https://www.rfc-editor.org/info/rfc9386>.
Authors' Addresses
Chongfeng Xie
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: xiechf@chinatelecom.cn
Xie, et al. Expires 7 August 2024 [Page 22]
Internet-Draft Multi-domain IPv6-only Underlay February 2024
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
Mohamed Boucadair
Orange
France
Email: mohamed.boucadair@orange.com
Thomas Graf
Swisscom
Binzring 17
CH- CH-8045 Zurich
Switzerland
Email: thomas.graf@swisscom.com
Xie, et al. Expires 7 August 2024 [Page 23]