v6ops Working Group C. Xie
Internet-Draft C. Ma
Intended status: Informational China Telecom
Expires: December 23, 2022 X. Li
CERNET Center/Tsinghua University
G. Mishra
Verizon Inc
M. Boucadair
Orange
June 21, 2022
Framework of Multi-domain IPv6-only Network
draft-xie-v6ops-framework-multi-domain-ipv6only-00
Abstract
For the IPv6 transition, dual-stack deployments require both IPv4 and
IPv6 transfer capabilities are deployed in parallel. IPv6-only is
considered as the ultimate stage where only IPv6 transfer
capabilities are used while ensuring global reachability for both
IPv6 and IPv4(IPv4aaS). This document specifies requirements and
propose a general framework when deploying IPv6-only in multi-domain
network.
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 December 23, 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xie, et al. Expires December 23, 2022 [Page 1]
Internet-Draft Multi-domain IPv6-only Framework June 2022
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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. The concept of IPv6-only network . . . . . . . . . . . . . . 4
5. The reason to consider multi-domain factor when implementing
IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Requirements from service traffic . . . . . . . . . . . . . . 9
8. Description of the framework . . . . . . . . . . . . . . . . 11
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. ADPT description . . . . . . . . . . . . . . . . . . . . 12
8.2.1. Rule management layer . . . . . . . . . . . . . . . . 12
8.2.2. Routing processing layer . . . . . . . . . . . . . . 13
8.2.3. Data forwarding layer . . . . . . . . . . . . . . . . 14
8.3. Mapping prefix allocation . . . . . . . . . . . . . . . . 14
9. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
IPv6 capabilities have been widely deployed during the past 10 years
and IPv6 traffic is growing faster than IPv4. Document
[I-D.ietf-v6ops-ipv6-deployment] provides an overview of IPv6
transition deployment status and how the transition to IPv6 is
progressing among network operators and enterprises.
Up to now, most IPv6 deployments rely on dual-stack
approach[RFC4213]. However, dual-stack does have a few disadvantages
in the long run, like the duplication of the network resources and
states, as well as other limitations for network operation. For this
Xie, et al. Expires December 23, 2022 [Page 2]
Internet-Draft Multi-domain IPv6-only Framework June 2022
reason, when IPv6 usage increases to a certain limit, it would be
better to consider IPv6-only. It is generally supposed that running
an IPv6-only network would reduce operational expenditures and
optimize operations as compared to an IPv4/IPv6 dual-stack
environment. 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]. In order to extend the service in
the case of IPv4 address depletion, operators need to provide IPv6
services and keep the ability for users to access the global IPv4
Internet. Therefore, "IPv4 as a Service", i. e., IPv4aaS is a
natural consideration for IPv6-only scheme.
Several IPv4 service continuity mechanisms have been designed within
IETF during the past twenty
years[I-D.ietf-v6ops-transition-comparison]. When these schemes
support the hosting of IPv4 service, different types of IPv4 and IPv6
conversion technologies are required, e. g., 464XLAT[RFC6877] uses
stateful NAT64 translation technology, MAP-E[RFC7597]and MAP-T
[RFC7599] use stateless NAT64 translation. DS-Lite[RFC6333] adopts
AFTR-based 4over6 tunneling technology, while the backbone network
adopts GRE tunneling or stateless translation technology, etc. This
document specifies the requirements for multi-domain IPv6-only
network and propose a general framework from the perspective of
operators. The objective of this framework is to help large-scale
operators implement the transition to IPv6-only and suppports cross-
domain, end-to-end IPv4 service delivery over IPv6-only network. It
does not introduce any new IPv6 transition mechanisms.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] .
3. Terminology
The following terms are defined in this draft:
o Multi-domain IPv6-only network: An IPv6-only network which
consists of multiple ASes belonging to and operated by the same
operator.
o Inter-domain IPv6-only network: An IPv6-only network which
consists of multiple ASes belonging to and operated by different
operators.
o UE: User Equipment, e.g., mobile phone.
Xie, et al. Expires December 23, 2022 [Page 3]
Internet-Draft Multi-domain IPv6-only Framework June 2022
o CPE: Customer Premise Edge device.
o IXP: Internet Exchange Point.
o WKP: Well-Known Prefix.
o NSP: Network-Specific Prefix.
o PE : Provider Edge device.
o IPv4-embedded IPv6 packet: IPv6 packet which is generated from
IPv4 packet by algorithmically mapping of the source and
destination IPv4 addresses to IPv6 addresses.
o Border gateway: A PE router which run eBGP routing protocol and
peering with the BGP router of external AS.
o Conversion point: A function which provides conversion between
IPv4 and IPv6 realms.
4. The concept of IPv6-only network
The definition of IPv6-only network is proposed against the
definition IPv4/IPv6 dual-stack network. Frankly speaking, the
global industry has not given a unified definition of IPv6-only
network so far. We believe that IPv6-only network is a IPv6-centric
network in which the data packets are routed and forwarded based on
IPv6 protocol, and supports seamlessly interconnection with various
external networks, including IPv4-only.
5. The reason to consider multi-domain factor when implementing
IPv6-only
Intuitively speaking, transition to IPv6-only from dual-stack means
some or all the IPv4 protocol instances of dual-stack network will be
closed gradually, thereby IPv6 will become the main network-layer
protocol.
When IPv4 is closed at the network layer, 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 in short time, it is very possible that some portion of the
Internet service will consistently be IPv4-based. In other words,
IPv6-only network should carry not only IPv6-capable services, but
also IPv4-only services.
Xie, et al. Expires December 23, 2022 [Page 4]
Internet-Draft Multi-domain IPv6-only Framework June 2022
[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 (Provider Routers) in the core
only support IPv6, but the AFBRs support IPv4 on interfaces facing
IPv4 client networks and IPv6 on interfaces facing the core. The
routing solution defined in [RFC5565] for this scenario 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 technology, such as
MPLS, LSP, GRE, 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.
Generally, the networks of large-scale operators comprise multiple
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. 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 1, 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 solutions to eliminate unnecessary conversion
functions and improve data forwarding efficiency.
Xie, et al. Expires December 23, 2022 [Page 5]
Internet-Draft Multi-domain IPv6-only Framework June 2022
+---+ +---+ +------+
|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 1: IPv6-only Independent Deployment in Multi-domain Network
6. Scenarios
This section describes scenarios where IPv4 packets are transported
over a multi-domain IPv6-only network. A typical model of multi-
domain IPv6 network is depicted in figure 2. Network 1, belonging to
and operated by operator 1, runs IPv6 and is composed of multiple
inter-connected ASes, i.e., AS1, AS2 and AS3. In addition, network 1
provides access to multiple types of users, including mobile, home
broadband and enterprise customers, denoted by UE1, UE2 and UE3 in
figure 2. Routers that are outside the backbone but directly
attached to it are known as "Customer Edge" (CE) routers.
Network 1 is open, it is interworking with the external networks.
Operator 2 is one of the neighbor operators of Operator 1, AS4 of
operator 2 and AS3 of operator 1 are interconnected through BGP
protocol. AS4 is an IPv4-only network, which means that it does not
run IPv6 protocol.In addition, cloud services are hosted in data
centers and connected across multiple data centers, the edge, and
public and private clouds. The cloud data center must be able to
communicate across these multiple sites, both on-premises and in the
cloud. IPv6-only network needs to provide connections for cloud data
center. Network 1 supports two connections modes of cloud data
centers, the first one is between cloud data center and individual
Xie, et al. Expires December 23, 2022 [Page 6]
Internet-Draft Multi-domain IPv6-only Framework June 2022
users, for instance, the user of CPE1 accesses the service hosted in
DC1, the second one is the connection between cloud data centers, for
instance, communications between VMs hosted in DC1 and DC2
separately.
The edge nodes of the Network 1 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
backbone. Interior nodes are often known as "P routers". 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.Network 1 provides transportation 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 "edge
routers". They are routed through the network to another edge
router, after which they leave the network and continue on their way.
Xie, et al. Expires December 23, 2022 [Page 7]
Internet-Draft Multi-domain IPv6-only Framework June 2022
----- -----
/ \ / \
| DC1 | | DC2 |
\ / \ /
----- -----
---------|--------------|---------
| | (Operator1) | |
| +---+ Network +---+ |
| |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 2. Multi-domain IPv6 Network Model
In order to illustrate the requirements of IPv6-only network, the
following scenarios should be considered,
Scenario 1: IPv6 user to IPv4 server, i.e., IPv6-only user accesses
IPv4 services hosted in cloud data centers.
Scenario 2: IPv4 user to IPv4 server, i.e., IPv4-only user accesses
IPv4 services hosted in cloud data centers.
Scenario 3: IPv6 user to IPv6 server, i.e., IPv6-only user accesses
IPv6 services hosted in cloud data centers.
Scenario 4: DC-to-DC, i.e., IPv6-only provide communications between
VMs hosted in cloud data centers, despite they are IPv4, IPv6 or
IPv4/IPv6 dual-stack.
Xie, et al. Expires December 23, 2022 [Page 8]
Internet-Draft Multi-domain IPv6-only Framework June 2022
Scenario 5: Transit for neighbor networks, i.e., IPv6-only network
serves as an interconnection between several segregated IPv4-only
network, 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 multi-domain IPv6-only network will support in the
future.
7. Requirements from service traffic
The native-IPv6 traffic can be transported by IPv6-only network
naturally, therefore there are no additional requirements.
In order to support IPv4 service delivery, 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
IPv6 transition mechanisms should provide IPv4 service delivery and
there should be no perceived degradation of customer experience when
accessing the remaining IPv4 services.
Requirement 3: end-to-end
For any given IPv4 traffic flow, there should be no IPv4-IPv6
conversion point in the middle of the IPv6 data path when traversing
multi-domain IPv6 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
into IPv6 packets within UE or CPE, and there should be no IPv4-IPv6
conversion before they reach the egress of the network.
Xie, et al. Expires December 23, 2022 [Page 9]
Internet-Draft Multi-domain IPv6-only Framework June 2022
-From the ingress to egress, since the core of the network is
IPv6-based, so all IPv4 packets which reaches 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 also be valid for cloud-to-cloud
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, they both should
be supported by 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.
Requirement 5: controller independent
In order to forward an IPv4 packet to the right egress point, IPv4
reachability information must be exchanged in advance between the
IPv4 networks over in IPv6-only network. In general, BGP4+ is used
to distribute external IPv4 routing information among PEs. It does
not rely on the deployment of any centralized controller. Note that
with this routing solution, the IPv4 and IPv6 header conversion
performed in both directions by the PE is stateless.
Requirement 6: 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.
Requirement 7: high scalability
It should achieve high scalability, simplicity and high 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 algorithm-based mapping approach to avoid
Xie, et al. Expires December 23, 2022 [Page 10]
Internet-Draft Multi-domain IPv6-only Framework June 2022
excessive status storage at the edge. It would also avoid
overloading of the IPv6 routing table.
Requirement 8: SRv6 applicable
SRv6 can be supported by inserting SRH in translated IPv6 packet, so
the network programming can be realized for IPv4 traffic flow.
Requirement 9: incremental deployment
It should deploy in an incremental fashion and the overall transition
process should be stable and operational.
Requirement 10: no security compromise
The technologies proposed must not introduce additional security
compromise.
8. Description of the framework
8.1. Overview
Multi-domain IPv6-only network should support the transmission 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 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 packet reaches
the egress PE, i.e., PE2, it can be restored to an IPv4 packet.
During this process, a specific kind of IPv4-IPv6 prefix mapping
struct, namely mapping rule, is adopted to generate corresponding
IPv6 source and destination addresses from its IPv4 source and
destination address, 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.
Since this is prefix-level mapping, there is no need to maintain
user-related status at the PE devices. In addition, there is no need
to concern oneself with translation tables, as the IPv4 and IPv6
counterparts are algorithmically related.
Furthermore, this multi-domain model can naturally be extended to
inter-domain IPv6-only networks operated by different operators.
Xie, et al. Expires December 23, 2022 [Page 11]
Internet-Draft Multi-domain IPv6-only Framework June 2022
8.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 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+--+--+------+ RM +-+-----+--------+-|-+RM | |
| | ||engine | | +---+ | | | | | | |
| | |+-------+ | | +--+--+ | | | +---+ |
| | | | | +I7 +I2 | | |_______|
| | | | | | +--+--+ | +-------+ |
| | | | |+-++ | | |I4|IPv6 | | +------+
|R1 | | | ||MD| | RP +-+-++routing+---+--+ |
|IPv4 | | | |+-++ | | | |engine | | | |
|Router| | | | | +-----+ | +---+---+ | |R2 |
| | | | | +I8 | | | |IPv6 |
| | |+----------+ | | +-----+ | +---+------+| |Router|
| | ||IPv4 |I5| +---+ | |I6|IPv6 || | |
| +-++packet +-++------+ DF +-+-++packet ++--+ |
| | ||forwarding| | | | | |forwarding|| | |
| | |+----------+ | +-----+ | +----------+| +------+
| | | |______________| |
+------+ +--------------------------------------------+
Figure 3. Framework of Multi-domain IPv6-only Network
8.2.1. Rule management layer
The routing of IPv4 data in the form of IPv6 packet will follow
topology of IPv6 network. With this framework, each PE will be
identified by at least one IPv6 mapping prefix, denoted by Pref6(PE),
it will also have one or more associated IPv4 prefixes which are
extracted from local IPv4 routing table or address pool. The mapping
relationship between IPv4 address prefix and IPv6 mapping prefix is
called mapping rule. The mapping rule is used to convert the IPv4
destination address of a given IPv4 packet into IPv6 address by
stateless mapping when its egress is the given PE. The rule
management layer i.e., RM, deals with the management of mapping
relationship between IPv4 address prefix and IPv6 address prefix of
PEs, as shown in figure 3. The mapping rule announced by a given PE
will have at least the following data structure.
Xie, et al. Expires December 23, 2022 [Page 12]
Internet-Draft Multi-domain IPv6-only Framework June 2022
IPv4 address prefix: Pref6(PE)
In each PE, there is a mapping rule database, i.e., MD, to store all
the mapping rule records it receives from other PEs. Rule management
layer provides management services to mapping rule database through
interface I7.
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 routing processing layer is I2, which is used for
the transmission of mapping rule through routing processing layer.
PE1 can extract the IPv4 address prefixes from its IPv4 BGP routing
instance through interface I3, and generate the mapping rules of the
device in combination with its own pref6. When the mapping rules are
ready, they will be sent to Routing processing 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 prefixes which are not announced explicitly by
any egress PEs to the ingress PE, there will be no corresponding
mapping rule in the rule database. To solve this problem, the
default egress PE is defined in the network, 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)
8.2.2. Routing processing layer
Routing processing layer, i.e., RP, 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 receiving the sending request of mapping rule from rule
management layer through interface I2, Routing processing 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, Routing processing layer will extract mapping rule from
the routing information and send it to the Rule management layer.
Xie, et al. Expires December 23, 2022 [Page 13]
Internet-Draft Multi-domain IPv6-only Framework June 2022
To support the transmission of mapping rules at the routing layer,
BGP4+ protocol needs to be extended. However, this has been out of
the scope of the draft and will be discussed in other drafts. In
addition, Routing process layer is responsible for announcing the
IPv6 route corresponding to each IPv6 mapping prefix throughout the
multi-domain IPv6-only network.
8.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 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. Encapsultion
Encapsulation means that PE encapsulates IPv4 packets in IPv6 packets
without changing the original IPv4 packets, and then transmits them
in multi-domain IPv6-only network. Same to the translation method,
the source address and destination address of the IPv6 header
required for encapsulation are generated according to the
corresponding mapping rule found in the mapping rule database. If
the mapping prefix corresponding to the destination IPv4 address is
not found, the default IPv6 mapping prefix is used.
For a IPv4-embedded IPv6 packet, the pref6 part of the destination
address can identify the egress in the network, so the routing of the
IPv6 datagram can be implemented based on the pref6 information of
the address.
8.3. 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 [RFC7915]. With this framework, there are
two options to allocate IPv6 mapping prefix:
Xie, et al. Expires December 23, 2022 [Page 14]
Internet-Draft Multi-domain IPv6-only Framework June 2022
1) WKP: A specific WKP can be allocated from the global IPv6 address
prefix, e.g., 64:ff9b:: /96.
Pros: Service providers do not need to allocate IPv6 address prefixes
specially used for mapping IPv4 addresses from their own IPv6 address
resources.
Cons: After the IPv4 address is converted into IPv6 address with WKP,
the IPv4 part of the IPv6 address is used for the routing of the
origin of the data packet. In this way, many fine routes with prefix
length greater than 96 will be introduced into the global 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 for IPv4 addresses mapping.
Pros: The specific prefix allocated by operators can be considered as
an overall prefix, and each PE can obtain IPv6 mapping prefixes
allocated from the overall prefix. Within the multi-domain network,
the length of address 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 prefix part of
IPv6 address. Outside the multi-domain network, because the IPv6
mapping prefix has been included in the original IPv6 address prefix,
it will not introduce any new routing items and affect the global
IPv6 routing system.
Cons: Not found yet.
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. Firstly, the length of the
IPv6 mapping prefix should be smaller than the maximum length of the
routing prefix that the IPv6-only network specifies, so the PE can
successfully announce to its peers via BGP protocol. Secondly, the
length of all the IPv6 mapping prefixes should be the same, to avoid
unnecessary processing cost and complexity induced by the length
diversity.
9. Procedure
This section gives a brief overview of the procedures of the IPv4
service delivery over IPv6-only network. The end-to-end IPv4 data
delivery by IPv6-only network includes the following two cases.
Xie, et al. Expires December 23, 2022 [Page 15]
Internet-Draft Multi-domain IPv6-only Framework June 2022
1. IPv4 delivery from ingress PE to egress PE
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
is a 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 PE3 is 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 it to the egress PE. The egress PE
then derives the IPv4 source and destination addresses from the
IPv4-embedded IPv6 addresses respectively and restore the original
IPv4 packet [RFC6052]. 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
2. IPv4 delivery from UE/CPE to egress PE
Another 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, when receiving an IPv6 packet from a client facing
interface, the ingress PE looks up the packet's destination IPv6
address and forward the packet to the egress PE, i.e., PE3. The
egress PE then restore the original IPv4 packet, and forwards it
further by looking up its IPv4 destination address. The IPv6 data-
path can be shown in figure 5. Different from 464XLAT PLAT which
needs to maintain session state to perform the stateful translation
between IPv6 and IPv4 addresses, the egress PE in this framework to
the external IPv4 network is user stateless.
Xie, et al. Expires December 23, 2022 [Page 16]
Internet-Draft Multi-domain IPv6-only Framework June 2022
IPv6 Data Path
|<--------------------------------->|
| | (Operator2)
| ---- ----- | ----
| / \ / \ | / \
+----+ +---+ +--+ +--+ +---+ | |
|UE/ |---|PE1| AS1 |R1|-|R2| AS3 |PE3|---| AS4 |
|CPE1| +---+ +--+ +--+ +---+ | |
+----+ \ / \ / \ /
---- ----- ----
Figure 5. IPv6 Data Path from UE/CPE to Egress PE
10. Security Considerations
TBD.
11. IANA Considerations
There are no other special IANA considerations.
12. Acknowledgement
This is under development by a large group of people. Those who have
posted to the list during the discussion.
13. References
13.1. Normative References
[I-D.ietf-bess-ipv6-only-pe-design]
Mishra, G., Mishra, M., Tantsura, J., Madhavi, S., Yang,
Q., Simpson, A., and S. Chen, "IPv6-Only PE Design for
IPv4-NLRI with IPv6-NH", draft-ietf-bess-ipv6-only-pe-
design-02 (work in progress), March 2022.
[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>.
[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>.
Xie, et al. Expires December 23, 2022 [Page 17]
Internet-Draft Multi-domain IPv6-only Framework June 2022
[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>.
13.2. Informative References
[I-D.ietf-v6ops-ipv6-deployment]
Fioccola, G., Volpato, P., Elkins, N., Martinez, J. P.,
Mishra, G. S., and C. Xie, "IPv6 Deployment Status",
draft-ietf-v6ops-ipv6-deployment-06 (work in progress),
June 2022.
[I-D.ietf-v6ops-transition-comparison]
Lencse, G., Martinez, J. P., Howard, L., Patterson, R.,
and I. Farrer, "Pros and Cons of IPv6 Transition
Technologies for IPv4aaS", draft-ietf-v6ops-transition-
comparison-04 (work in progress), May 2022.
[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>.
[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 December 23, 2022 [Page 18]
Internet-Draft Multi-domain IPv6-only Framework June 2022
[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>.
Authors' Addresses
Chongfeng Xie
China Telecom
Beiqijia Town, Changping District
Beijing, Beijing 102209
China
Email: xiechf@chinatelecom.cn
Chenhao Ma
China Telecom
Beiqijia Town, Changping District
Beijing, Beijing 102209
China
Email: machh@chinatelecom.cn
Xing Li
CERNET Center/Tsinghua University
Shuangqing Road No.30, Haidian District
Beijing, Beijing 100084
China
Email: xing@cernet.edu.cn
Gyan Mishra
Verizon Inc
Email: gyan.s.mishra@verizon.com
Xie, et al. Expires December 23, 2022 [Page 19]
Internet-Draft Multi-domain IPv6-only Framework June 2022
Mohamed Boucadair
Orange
France
Email: mohamed.boucadair@orange.com
Xie, et al. Expires December 23, 2022 [Page 20]