Internet DRAFT - draft-ietf-idr-mpbgp-extension-4map6
draft-ietf-idr-mpbgp-extension-4map6
Network Working Group C. Xie
Internet-Draft G. Dong
Intended status: Standards Track China Telecom
Expires: 29 August 2024 X. Li
CERNET Center/Tsinghua University
G. Han
Indirection Network Inc.
Z. Guo
Alibaba Cloud
26 February 2024
MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement
draft-ietf-idr-mpbgp-extension-4map6-01
Abstract
This document defines MP-BGP extension and the procedures for IPv4
service delivery in multi-domain IPv6-only underlay networks. It
defines a new TLV in the BGP Tunnel Encapsulation attribute to be
used in conjunction with the specific AFI/SAFI for IPv4 and IPv6.
The behaviors of each type of network (IPv4 and IPv6) are also
illustrated. In addition, this document provides the deployment and
operation considerations when the extension is deployed.
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 29 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xie, et al. Expires 29 August 2024 [Page 1]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
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. Reference Topology . . . . . . . . . . . . . . . . . . . . . 3
3. MP-BGP Protocol Extension . . . . . . . . . . . . . . . . . . 5
3.1. NLRI Encoding for Mapping Rule Advertisement . . . . . . 5
3.2. 4map6 Tunnel TLV . . . . . . . . . . . . . . . . . . . . 6
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Advertisement of Mapping Rule Update by Egress PE . . . . 8
4.2. Receiving Mapping Rule Update by Ingress PE . . . . . . . 8
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Deployment and Operation Considerations . . . . . . . . . . . 10
7.1. Scalability Consideration . . . . . . . . . . . . . . . . 10
7.2. Route Distribution Control . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 14
Appendix B. IPv6-only DCN for AI-infra fabric . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The document [I-D.ietf-v6ops-framework-md-ipv6only-underlay] proposes
a framework for deploying IPv6-only as the underlay in multi-domain
networks, in which IPv4 packets will be stateless translated or
encapsulated into IPv6 ones for transmission across IPv6-only
underlay domains. To achieve this goal, this framework introduces a
specific data structure called IPv4/IPv6 address mapping rule to
support stateless IPv4-IPv6 packet conversion at the edge of the
network. For brevity, in the rest of the document, we will refer to
the IPv4/IPv6 address mapping rule as mapping rule. For an incoming
IPv4 packet, the mapping rules are used by the ingress PE to generate
corresponding IPv6 source and destination addresses from the IPv4
source and destination address of the original IPv4 packet, and vice
Xie, et al. Expires 29 August 2024 [Page 2]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
versa. Since the mapping rule for the destination IPv4 address can
identify the right PE egress by providing the IPv6 mapping prefix, it
gives the direction of IPv4 service data transmission throughout the
IPv6-only network. It is obvious that the exchange of the mapping
rule corresponding to the destination IPv4 address in a packet should
precede to the process of IPv4 data transmission in IPv6-only
network, 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 an ingress PE processes the incoming IPv4 packets, the mapping
rule for the source address can be obtained locally, but for the
mapping rule of the destination address, since it is not generated
locally by the ingress PE, it needs corresponding methods to be
obtained remotely. This document defines MP-BGP extension in which
BGP update message contains the mapping rule for IPv4 service
delivery. The extensions include a new TLV for 4map6 tunnel type in
BGP Encapsulation attribute corresponding to specific AFI/SAFI
combination and related procedures in IPv6-only networks.
It should be noted that the approach in this document focuses on
controlled environment, for instance, one network of single network
operator or small network of cooperating network operators. One
effect of using this approach is that the IPv4 address prefix in it
will be given one IPv6 mapping prefix and advertised in a IPv6
mapping route.
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. Reference Topology
In the context of this document, multi-domain underlay network refers
to a network system composed of multiple autonomous systems (i.e.,
AS) interconnected, each AS can serve different scenarios. Multi-
domain network can be operated by one or more network operators.
Consider the following scenarios, the network shown in figure 1 is a
typical multi-domain IPv6-only underlay network, it is used as a
basic scenario to illustrate the extension of the MP-BGP and its
related procedures in this document. The whole network comprises of
AS1, AS2 and AS3, it provides IPv4 services communications between
IPv4 network N1 and IPv4 network N2, which have IPv4 address block
IPv4 A1 and A2 respectively. It is consistent with section 6 of
Xie, et al. Expires 29 August 2024 [Page 3]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
draft [I-D.ietf-v6ops-framework-md-ipv6only-underlay].
IPv4 A1 +-------+ +-+ +------+ IPv4 A2
+----------+ / AS1 \ /AS2\ / AS3 \ +----------+
| IPv4 | |+--++ +---+ | |+--+ | | +--+ +--+ | | IPv4 |
|network N1|---||PE1|--| P1|-|--||P2|-|--|-|P3|-|PE2|-|---|network N2|
+----------+ |+---+ +---+ | |+--+ | | +--+ +--+ | +----------+
\ / \ / \ /
+-------+ +-+ +------+
Figure 1:Topology of Typical Multi-domain IPv6-only Network
PE and P routers are network devices which constitute the IPv6-only
underlay. The definition of PE and P is consistent with that in
draft [I-D.ietf-v6ops-framework-md-ipv6only-underlay]. It should be
noted that in multi-domain network, some ASBRs are not at the edge of
the network. In this case, they run as P routers. On each PE router
that the IPv4 address prefix is reachable through, there is a locally
configured IPv6 virtual interface (VIF) address. The VIF address, as
an ordinary global IPv6 /128 address, must also be injected into the
IPv6 IGP so that it is reachable across the multi-domain transit
core.
The extension of MP-BGP for mapping rule processing and transmission
across domains in this document will involve PE routers, which setup
BGP sessions to directly exchange 4map6 routing without affecting the
RIB and FIB of intermediate P devices. Each PE router maintains a
Mapping rule Database (i. e., MD) as depicted in figure 2. The entry
in the Mapping rule Database consists of an IPv4 address prefix, IPv4
address prefix length, IPv6 mapping prefix of the PE, IPv6 mapping
prefix length, address origin type and forwarding Type of the PE. It
should be noted that the database here is just an example, and
developers can design the structure of database according to the
actual situation.
+---------+---------------+--------+-------------+-------+----------+
| IPv4 | IPv4 | IPv6 |IPv6 |Address|Forwarding|
| Address | Address | Mapping|Mapping |Origin |Type |
| Prefix | Prefix Length | Prefix |Prefix Length|Type | |
+---------+---------------+--------+-------------+-------+----------+
Figure 2:Entry structure of Mapping Rule Database
The IPv4 packet sent from IPv4 network N1 will traverse the IPv6-only
network and reach the destination network, i.e., IPv4 network N2.
Its source address and destination address are within IPv4 address
block A1 and A2 respectively. Its ingress in the IPv6-only network
Xie, et al. Expires 29 August 2024 [Page 4]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
is PE1 and the egress is PE2. Before the data packet is transmitted,
the mapping rules corresponding to IPv4 address block A2 should be
transmitted from PE2 to PE1.
This mechanism is also in line with the requirements of emerging
scenarios such as DCN for AI infra fabric, as described in
Appendix A.
3. MP-BGP Protocol Extension
3.1. NLRI Encoding for Mapping Rule Advertisement
This document specifies a way in which BGP protocol can be used by a
given PE to tell other PE, "If you need to send IPv4 packet whose
destination address is within a given IPv4 address block, please send
them to me, here's the information you need to properly transform the
IPv4 packets into IPv6 ones". Multiprotocol BGP (MP-BGP) [RFC4760]
specifies that the set of usable next-hop address families is
determined by the Address Family Identifier (AFI) and the Subsequent
Address Family Identifier (SAFI). [RFC8950] specifies the extensions
to allow advertisement of IPv4 NLRI or VPN IPv4 NLRI with a next-hop
address that belongs to the IPv6 protocol. This document specifies
the extensions necessary to support the transmission of mapping rule
from any egress PE to any ingress PE within and across domains.
Since it is based on IPv6-only routing paradigm, it leverages the
combination of AFI and SAFI, with the value of 2 and xxx
respectively, which identifies NLRI used for IPv4 forwarding in IPv6
network. In addition, to support the transmission of additional
information of the mapping rule, it defines a new TLV for 4map6
tunnel type in the BGP Tunnel Encapsulation attribute. With this new
TLV, Address Origin Type and Forwarding Type can be obtained from BGP
update by the ingress PE to properly transform the IPv4 packets. The
route carried in the BGP update whose MP_REACH_NLRI attribute
contains the AFI/SAFI combinations and 4map6 TLV specified above is
called as IPv6 mapping route.
The use and meaning of the fields of MP_REACH_NLRI in this case are
as follows:
– AFI = 2 (IPv6)
– SAFI = xxx (4map6)
– Length of Next Hop
Xie, et al. Expires 29 August 2024 [Page 5]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
– Network Address of Next Hop = When a BGP speaker advertises
the 4map6 NLRI via BGP, it uses its own address as the BGP
next hop in the MP_REACH_NLRI.
– NLRI = Synthetic IPv6 address prefix, which is composed of
a IPv6 mapping prefix, the original IPv4 address prefix, and
their length. Following section 5 of [RFC4760], the
corresponding NLRI field for IPv4/IPv6 address mapping is
encoded as shown in figure 3:
+---------------------------------------------+
| NLRI Length (1 octet) |
+---------------------------------------------+
| IPv6 mapping prefix length (1 octet) |
+---------------------------------------------+
| IPv6 mapping prefix (0 ... 16 octets) |
+---------------------------------------------+
| IPv4 address prefix length (1 octet) |
+---------------------------------------------+
| IPv4 address prefix (0 ... 4 octets) |
+---------------------------------------------+
Figure 3:Format of NLRI Field
3.2. 4map6 Tunnel TLV
[RFC9012]defines a BGP path attribute known as the "Tunnel
Encapsulation attribute", which can be used with BGP UPDATEs of
various Subsequent Address Family Identifiers (SAFIs) to provide
information needed to create tunnels and their corresponding
encapsulation headers. It provides encodings for a number of tunnel
types, along with procedures for choosing between alternate tunnels
and routing packets into tunnels. BGP path attribute is composed of
a set of Type-Length-Value (TLV) encodings. Each TLV contains
information corresponding to a particular tunnel type. Since IPv4
forwarding in [I-D.ietf-v6ops-framework-md-ipv6only-underlay] adopts
stateless IPv4/IPv6 address mapping to generate IPv6 addresses, and
supports both encapsulation and translation, a new tunnel type named
4map6 is defined in this document. Following the format of Tunnel
Encapsulation TLV defined in section 2 of [RFC9012], the TLV for
4map6 tunnel is shown as follows,
Xie, et al. Expires 29 August 2024 [Page 6]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value (Address Origin Type, Forwarding Type) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4:Format of the 4map6 tunnel TLV
The code of "Tunnel Type" for 4map6 tunnel needs to be applied from
the IANA registry "BGP Tunnel Encapsulation Attribute Tunnel Types"
[IANA-BGP-TUNNEL-ENCAP].
This Value field contains two sub-fields: "Address Origin Type" and
"Forwarding Type", both of which are 1 octet in length, they are
arranged in sequential order in the field of Value. The use and
meaning of these sub-fields are as follows:
a) Address Origin Type
The sub-field can assume the following value:
Value Meaning
0 The IPv4 address prefix originates from the local configuration
of the egress PE.
1 The IPv4 address prefix is obtained by egress PE from external
IPv4 networks.
b) Forwarding Type
This sub-field identifies the IPv4/IPv6 forwarding capability of the
egress PE, it can assume the following values:
Value Meaning
0 Translation and encapsulation
1 Encapsulation
2 Translation
Xie, et al. Expires 29 August 2024 [Page 7]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
In addition, ATTR_ SET attribute(type code 128), defined in [RFC
6368], can be used to transfer the routing information of the IPv4
network in multi-domain IPv6-only network.
4. Operation
4.1. Advertisement of Mapping Rule Update by Egress PE
When a PE router learns an IPv4 route from the locally attached IPv4
access networks, the control plane of the PE should process it as
follows:
1. Install and maintain local IPv4 route in the IPv4 routing
database.
2. Generate BGP update advertisement based on the IPv4 route
advertisement and the capability of the egress PE as follows:
a) Set the values of AFI and SAFI in MP_REACH_NLRI to 2 and xxx
respectively.
b) Following the NLRI coding method in section 3.1, generate a
new NLRI using IPv6 mapping prefix length, IPv6 mapping prefix of
the egress PE, IPv4 address prefix length and IPv4 address
prefix.
c) Generate 4map6 tunnel TLV based on Forwarding Type of the
egress PE and Address Origin Type of the IPv4 address prefix.
d) The Origin ASN, Length of AS_ Path, AS_Path in the original
IPv4 route advertisement are copied to the corresponding fields
of ATTR_ SET attribute respectively.
3. Send the BGP update advertisement generated to its IPv6 peer
routers.
4.2. Receiving Mapping Rule Update by Ingress PE
When a PE router receives BGP update advertisement from other PE
routers and uses that information to populate the local Mapping Rule
Database, the following procedures are used to update the Mapping
rule Database and send IPv4 routing information to its IPv4 peers.
1. Validate the received BGP update advertisement as 4map6 routing
by AFI = 2 (IPv6) and SAFI = xxx (4map6).
Xie, et al. Expires 29 August 2024 [Page 8]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
2. Extract the IPv6 Mapping Prefix which is encoded in the NLRI
field and compare it with the ingress PE's IPv6 Mapping Prefix, and
if they match, proceed to the next step. Otherwise, this update will
be announced to its other BGP Peers.
3. Extract the IPv4 address prefix which is encoded in the NLRI
field and lookup in Mapping rule Database, if an entry which matches
the IPv4 address prefix is found, then,
1) Update the entry found in the Mapping rule Database with
the IPv6 mapping prefix, Address Origin Type and Forwarding
Type extracted from BGP advertisement, then place that as an
associated entry next to the IPv4 network index.
2) Redistribute the new IPv4 route to the local IPv4 routing
table. Set the destination network prefix as the extracted
IPv4 address prefix, set the Next Hop as Null, and set the
OUTPUT Interface as the 4map6 VIF on the local PE router.
else then
1) Install and maintain a new entry in the Mapping rule
Database with the extracted IPv4 address prefix and its
corresponding IPv6 mapping prefix, Forwarding Type, Address
Origin Type.
2) Redistribute the new IPv4 route to the local IPv4 routing
table. Set the destination network prefix as the extracted
IPv4 address prefix, set the Next Hop as Null, and set the
OUTPUT Interface as the 4map6 VIF on the local PE router.
As mentioned in [I-D.draft-ietf-v6ops-framework-md-ipv6only-
underlay], multi-domain IPv6-only network supports both translation
and encapsulation technologies for IPv4 data delivery at the
forwarding layer. Take the encapsulation as an example, the
reachability to the egress endpoint of tunnel may change over time,
directly impacting the feasibility of the IPv4 service delivery. A
tunnel that is not feasible at some moment may become feasible at
later time when its egress endpoint address is reachable. The router
may start using the newly feasible tunnel instead of an existing one.
This may happen for translation-based data-path as well. How this
decision is made is outside the scope of this document.
Xie, et al. Expires 29 August 2024 [Page 9]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
5. Error Handling
When a BGP speaker encounters an error while parsing the
4map6-related attributes, the speaker must treat the update as a
withdrawal of existing IPv6 mapping routes, or discard the update if
no such routes exist. A log entry should be raised for local
analysis.
6. IANA Considerations
With this document IANA is requested to allocate the following codes,
1)A new SAFI value (xxx) for the BGP 4map6 in "Subsequent Address
Family Identifiers (SAFI) Parameters" registry.
2)A code for 4map6 in "BGP Tunnel Encapsulation Attribute Tunnel
Types".
All the codes above use this document as the reference.
7. Deployment and Operation Considerations
7.1. Scalability Consideration
When operators use the new extension in actual IPv6 networks, it is
necessary to consider its impact on BGP scalability. If there is not
specific policy consideration during deployment, for the same IPv4
address block, different operators may use different prefixes to map
it, so multiple synthesized IPv6 prefixes will be generated, which
can have a significant impact on the scale of RIB and even FIB.
Therefore, it is recommended that only one IPv6 mapping prefix should
be configured for each IPv4 address block in principle, and this is
also true in multi-operator scenario. In essence, the scalability
issue is related to the strategy of IPv6 mapping prefix allocation.
In section 6.3 of [I-D.ietf-v6ops-framework-md-ipv6only-underlay] ,
two configuration mapping prefix methods are proposed, WKP (i. e.,
Well-Known Prefix) and NSP (i. e., Network Specific Prefix), which
can be combined to assist in solving the scale concern. For
different types of PE, it is recommended to use the following IPv6
mapping prefix configuration policy:
Xie, et al. Expires 29 August 2024 [Page 10]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
1) PE for access (Type 1), this kind of PE is configured with IPv4
address blocks, which are owned by the operator. Generally, it does
not have direct interconnection with external IPv4 Internet. It is
recommended to assigns NSP as the IPv6 mapping prefix to these
address blocks and sets the sub-field of Address Origin Type in the
4map6 tunnel TLV to 0. Since the NSP is part of the operator's IPv6
address block, it is usually not necessary to advertise a dedicated
IPv6 route for each IPv6 mapping prefix, so that no additional
entries are added to the FIB of the P devices.
2) Interworking PE (Type 2), this kind of PE interworks directly with
the external IPv4 Internet. For the address block in the IPv4 route
announcement received from the IPv4 Internet, it is proposed to use
WKP to configure the IPv6 mapping prefix, and set the sub-field of
Address Origin Type in the 4map6 tunnel TLV to 1. With this
configuration, in a IPv6 network with multiple interworking PE,
regardless of which PE maps and advertisements the IPv6 mapped route,
the NLRI for the received external IPv4 address block is the same, so
there will be no significant impact on the scale of IPv6 network
routing.
In addition, implementation of 4map6 related settings and policies at
the network edge can also be useful to ensure scalability. For
example, setting a policy on interworking PE to prohibit self-owned
IPv4 address blocks from backtracking to IPv6 routing. Interworking
PEs may receive BGP advertisement of self-owned IPv4 address blocks
from IPv4 Internet. If a new IPv6 mapping route is generated using
the mapping prefix of Interworking PEs and advertised in the IPv6
network, it will increase the load of RIB of routers and may form a
routing loop. Therefore, it is necessary to configure policies on
the PE to restrict the backtracking of IPv4 address blocks to be
advertised in the IPv6 network. The strategy is also effective in
multi-operator scenario. Moreover, Restricting the advertisement of
BGP messages with Address Origin Type value of 1 to other operators
can also help avoid situations that multiple operators assign
different mapping prefixes to the same IPv4 address block.
Nevertheless, in some cases, such as when high reliability is
required, some IPv4 address blocks need to be configured with
multiple IPv6 mapping prefixes.
Xie, et al. Expires 29 August 2024 [Page 11]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
7.2. Route Distribution Control
With the approach in this document, IPv6 mapping routes should only
be used within the closed multi-domain IPv6 network. To prevent IPv6
mapping routes from leaving the IPv6-only network and entering the
IPv6 Internet, it is recommended to mark them when generating IPv6
mapping routes at the egress PE and set policies on the receiving PE
to prevent leakage into the IPv6 Internet. For operators, the range
of IPv6 mapping routes distribution can be controlled based on the
new 4map6 SAFI, to be specific, BGP message with SAFI xxx is
restricted from being advertised on the IPv6 Internet. In addition,
as the IPv6 prefix of NLRI generated through mapping is longer than
that of regular IPv6 routes, the sum of the lengths of IP mapping
prefix and IPv4 address prefix is generally greater than 64. But in
BGP routing between operators, there is a convention that the prefix
of NLRI is required to be less than a certain length, such as 48
bits. If a route has a long prefix without 4map6 attribute, the
receiving BGP router can filter it out. Furthermore, since the NLRI
of the mapping route is synthesized based on legal IPv4 addresses and
does not overlap with NLRIs of other native IPv6 routes, even if it
is leaked to the IPv6 Internet, no traffic hijacking effect will
occur.
8. Security Considerations
In the early stage of deployment, it can be expected that 4map6
extension is mainly used in small multi-domain IPv6 network with a
few operator interconnections. At this stage, BGP collaboration was
established on the basis of mutual trust between operators. In case
of accidents or malfunctions, both parties can resolve them through
collaborative means. Under this premise, when one egress PE of the
other operator sends a 4map6 BGP announcement with Address Origin
Type value of 0, the Ingress PE can trust the information in it,
extract the items of the IPv4 address prefix, IPv6 mapping prefix,
address origin type and forwarding type, then store them in the local
Mapping rule Database. However, in the distant future, if the scope
of 4map6 usage is further expanded, a dedicated authentication
mechanism will be needed to verify the authenticity of 4map6
information in BGP advertisements, preventing malicious network
operators from using their own address prefix to map other operators'
IPv4 address blocks, thereby turning into network hijacking behavior,
as stated in section 8.2 of
[I-D.ietf-v6ops-framework-md-ipv6only-underlay], " 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." In this case,
similar techniques as RPKI origin validation or IRR filtering are
needed to help prevent this. Applying such technologies to the
proposed mapping mechanism would mean that BGP prefix policy would
Xie, et al. Expires 29 August 2024 [Page 12]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
need to be able to be applied to the embedded IPv4 networks, this
security enhancement can be defined in other documents.
9. Acknowledgement
The authors would like to thank Jeffrey Haas, Susan Hares, Robert
Raszuk, Changwang Lin, Yingzhen Qu, Nan Geng, Gyan Mishra, Jingrong
Xie, Acee Lindem, Tom Petch, Richard Huang, Cheng Li, Jie Dong,
Eduard Metz, Shunwan Zhang, Linjian Song, Weiqiang Cheng, Paolo
Volpato, Sheng Jiang, Giuseppe Fioccola, Shuping Peng, Di Ma, Ran
Pang, Tianran Zhou, Linda Dunbar for their review and comments.
10. References
10.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>.
[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>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T.
Yamagata, "Internal BGP as the Provider/Customer Edge
Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 6368, DOI 10.17487/RFC6368, September 2011,
<https://www.rfc-editor.org/info/rfc6368>.
[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>.
[RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K.
Patel, "Advertising IPv4 Network Layer Reachability
Information (NLRI) with an IPv6 Next Hop", RFC 8950,
DOI 10.17487/RFC8950, November 2020,
<https://www.rfc-editor.org/info/rfc8950>.
Xie, et al. Expires 29 August 2024 [Page 13]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
10.2. Informative References
[I-D.ietf-v6ops-framework-md-ipv6only-underlay]
Xie, C., Ma, C., Li, X., Mishra, G. S., Boucadair, M., and
T. Graf, "Framework of Multi-domain IPv6-only Underlay
Network and IPv4-as-a-Service", Work in Progress,
Internet-Draft, draft-ietf-v6ops-framework-md-ipv6only-
underlay-04, 4 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
framework-md-ipv6only-underlay-04>.
[IANA-BGP-TUNNEL-ENCAP]
IANA, "Border Gateway Protocol (BGP) Tunnel
Encapsulation", <https://www.iana.org/assignments/bgp-
tunnel-encapsulation/>.
Appendix A. Contributors
The following people have contributed to this document:
Congxiao Bao
CERNET Center/Tsinghua University
Email: congxiao@cernet.edu.cn
Linjian Song
Alibaba Cloud
Email: linjian.slj@alibaba-inc.com
Chenhao Ma
China Telecom
Email: Machh@chinatelecom.cn
Appendix B. IPv6-only DCN for AI-infra fabric
There is enormous "East-West" traffic inside the data center network,
which are the flows between DC devices and applications. Upgrading
the DCN network firstly to dual-stack, then IPv6-only is nontrivial.
One example is building AI-infra fabric on IPv6 only fabric which
reduce data plane encapsulation overhead, simplify forwarding chip's
feature and improve data plane performance.
Xie, et al. Expires 29 August 2024 [Page 14]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
When DCN plans to transits from dual stack to IPv6-only, it is
impossible to be done overnight. Considerations and plans should be
made supporting legacy IPv4 servers and applications when the DCN is
IPv6-only. The IPv6-only framework proposed in this memo provide
availability for IPv4 service when the underlay Networks upgraded to
IPv6-only.
As shown in Figure 6, Host 1 and Host 2 are legacy servers with only
IPv4 capability. Traffic between Host 1 and Host 2 are carried by
IPv6 network in the DCN. The access switch(ASW) have the function of
ADPT which learns IPv4/IPv6 mapping rules and delivers the IPv4
service in IPv6-only network.
Internet
^
|
^ +----------------+------------------+
| | Data Center Network |
| +----+-------------------------+----+
| | |
| +----+-------------------------+----+
| | |
IPv6-only | PSW/R1 |AS2
| +----+--------------------------+---+
| | |
| | |
v +----+---+ +----+---+
------- | | | |
^ |ASW/PE1 |AS1 |ASW/PE2 |AS1
| +----+---+ +----+---+\
dualstack | | \
| +-+-+ +-+-+ +---+
v | H1|IPv4 IPv4| H2| | H3| IPv6
+---+ +---+ +---+
Figure 6:IPv6-only DCN for AI infra fabric
Authors' Addresses
Chongfeng Xie
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: xiechf@chinatelecom.cn
Xie, et al. Expires 29 August 2024 [Page 15]
Internet-Draft MP-BGP Extension for 4map6 Advertisement February 2024
Guozhen Dong
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: donggz@chinatelecom.cn
Xing Li
CERNET Center/Tsinghua University
Shuangqing Road No.30, Haidian District
Beijing
100084
China
Email: xing@cernet.edu.cn
Guoliang Han
Indirection Network Inc.
Email: guoliang.han@indirectionnet.com
Zhongfeng Guo
Alibaba Cloud
Wangjing Qiyang Rd, Chaoyang District
Beijing
100102
China
Email: guozhongfeng.gzf@alibaba-inc.com
Xie, et al. Expires 29 August 2024 [Page 16]
