]> China Telecom

Beiqijia Town, Changping District Beijing 102209 China xiechf@chinatelecom.cn

China Telecom

Beiqijia Town, Changping District Beijing 102209 China donggz@chinatelecom.cn

CERNET Center/Tsinghua University

Shuangqing Road No.30, Haidian District Beijing 100084 China xing@cernet.edu.cn

Indirection Network Inc.

guoliang.han@indirectionnet.com

Alibaba Cloud

Wangjing Qiyang Rd, Chaoyang District Beijing 100102 China guozhongfeng.gzf@alibaba-inc.com

Network Working Group RFC This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new BGP path attribute known as the "4map6" to be used in conjunction with the existing AFI/SAFI for IPv4 and IPv6. This attribute with associate an IPv4/IPv6 address mapping rule that will allow IPv4 traffic to cross IPv6-only domains. The behavior of each type of network (IPv4 and IPv6) also illustrated.

The document 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 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 new BGP Path Attribute known as the "4map6" corresponding to the NLRI and a set of related procedures. It should be noted that the approach in this document focuses on is 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.

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 when, and only when, they appear in all capitals, as shown here.

In the context of this document, multi-domain underlay networks refer to a network system composed of multiple autonomous systems (i.e., AS) interconnected, each AS can serve different scenarios. Multi-domain networks can be operated by one or more network operators. Consider the following scenarios, the network shown in figure 1 is typical multi-domain IPv6-only underlay networks, 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 draft [I-D.ietf-v6ops-framework-md-ipv6only-underlay].

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 networks, 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 and P routers. Each PE router maintains a Mapping rule Database (MD) as depicted in figure 2. The entry in the MD database consists of an IPv4 address prefix, IPv4 address prefix length, IPv6 mapping prefix of the PE and IPv6 mapping prefix length. 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.

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 is PE1 and the egress is PE2. Before the data packet is transmitted, the address mapping rules corresponding to IPv4 address block A2 should be transmitted from PE2 to PE1. During the mapping rule announcement and transmission process, it may pass through the intermediate P routers, such as P3, P2 and P1, and finally reaches PE1. When any P router receives a mapping rule announcem, it processes the IPv6 mapping route in the same way to that of native IPv6 routing. This mechanism is also in line with the requirements of emerging scenarios such as DCN for AI infra fabric, as described in Appendix A.

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 1 respectively, which identifies Network Layer Reachability Information (NLRI) used for unicast forwarding in IPv6 network. In addition, in order to identify that this BGP update message is used for the transmission of the mapping rule, it needs to contain a newly defined BGP path attribute type -- the 4map6 attribute. With this attribute, the IPv6 mapping prefix and IPv4 address block can be identified from NLRI,other information can also be obtained 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 BGP path attribute 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 = 1 (Unicast) – Length of Next Hop – 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 = Composite IPv6 address prefix, which is composed of a IPv6 mapping prefix, the original IPv4 address prefix, and the remaining bits are zero. The NLRI field is encoded as shown in figure 3:

As a new BGP path attribute defined in this document, 4map6 attribute is optional and transitive, it requires IANA to assign a new BGP path attribute value. The attribute is composed of a set of fields as below,

The use and meaning of these fields are as follows: a) Length of IPv6 Mapping Prefix This is a 1-octet field whose value indicates the length of IPv6 mapping prefix. b) Forwarding Type This field identifies the IPv4/IPv6 forwarding capability of the egress PE, the data octet can assume the following values: Value Meaning 0 Translation and encapsulation 1 Encapsulation 2 Translation c) Address Origin Type The data octet can assume the following value: Value Meaning 0 The IPv4 address prefix is locally configured in the egress PE. 1 The IPv4 address prefix is obtained by egress PE from external IPv4 networks. The field entries of "Forwarding Type" and "Address Origin Type" need IANA Considerations registries. 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 networks.

When a PE router learns IPv4 routing information from the locally attached IPv4 access networks, the control plane of the PE should process the information as follows: 1. Install and maintain local IPv4 routing information in the IPv4 routing database. 2. Install and maintain new entries in the MD database. Each entry should consist of the IPv4 address prefix and the local IPv6 mapping prefix. 3. Advertise the content of each entry in the local MD database in the form of BGP update advertisement to IPv6 peer routers. The process to generate IPv6 route advertisement with 4map6 attribute based on IPv4 route advertisement messages is as follows: a) Set the values of AFI and SAFI in MP_REACH_NLRI to 2 and 1 respectively; b) The IPv6 mapping prefix of the egress PE splices IPv4 address blocks in IPv4 routing advertisements to form a composite IPv6 address prefix with the length value denoted by L1. The composite IPv6 address prefix is copied to address prefix field of the NLRI structure in the MP_ REACH_NLRI, and the length field of the NLRI is set to L1, the structure of the composite IPv6 address prefix in NLRI is shown in figure 5. L2 is used to denote the length of the IPv6 mapping prefix of PE2, i.e. Pref6-2. When the value of L2 is available, the field of Length of IPv6 Mapping Prefix in the 4map6 attribute is set to L2. c) The value of Origin ASN in the original IPv4 route advertisement, the values of Length of AS_ Path, AS_Path are copied to the corresponding fields of ATTR_ SET attribute respectively.

When a P router receives BGP update advertisement from neighboring P or PE routers, it processes the BGP update advertisement in the same way to that of native IPv6 routing, then advertise the IPv6 mapping route in the form of BGP update advertisement to IPv6 peer routers. It should be noted that this process does not change or affect the IPv6 FIB table of the P router.

When a PE router receives BGP update advertisement from neighboring P or PE routers and uses that information to populate the local MD database and the BGP routing database, the following procedures are used to update the MD database and send IPv4 routing information to its IPv4 peers. 1. Validate route in the received BGP update advertisement as IPv6 mapping route by finding the 4map6 attribute. 2. Extract the IPv6 Mapping Prefix which is encoded in positions 0 to L2-1 of the NLRI field and compare the obtained IPv6 Mapping Prefix with its own 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 positions L2 to L1-1 of the NLRI field and lookup in the MD database, if an entry which matches the IPv4 address prefix is found, then, 1) Update the entry found in the MD database with the 4map6 attributes of BGP advertisement by extracting the IPv6 mapping prefix and 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 MD database with the extracted IPv4 prefix and its corresponding IPv6 mapping prefix. 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 networks support both translation and encapsulation technologies for IPv4 data delivery at the data 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.

When a BGP speaker encounters an error while parsing the 4map6 path attribute, the speaker must treat the update as a withdrawal of existing routes to the included 4map6 SAFI NLRIs, or discard the update if no such routes exist. A log entry should be raised for local analysis.

With this document IANA is requested to allocate the following codes, 1)A code for 4map6 path attribute in the BGP “BGP Path Attributes” registry 2)Value for the field entries of "Forwarding Type" and "Address Origin Type" in 4map6 path attribute. 3)Value xx for 4map6 in the BGP "Capability Codes" registry All the codes above use this document as the reference.

When using the 4map6 attribute 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 scenarios. The scalability issue is related to IPv6 mapping prefix allocation. In section 6.3 of , two configuration mapping prefix methods are proposed, WKP and NSP, 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 strategy: 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 Address Origin Type in the 4map6 attribute 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 prefix, so that no additional entries are added to the FIB of the P device. 2) Interworking PE (Type 2), this kind of PE interworks with the external IPv4 Internet. For the address block it receives from the IPv4 Internet in the IPv4 route announcement, it is proposed to use WKP to configure the IPv6 mapping prefix, and set the Address Origin Type in the 4map6 attribute 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 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 P devices 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 scenarios. Moreover, Restricting the advertisement of BGP messages with Address Origin Type 1 to other operators can also help avoid situations where 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.

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 also be controlled based on the prefix length of NLRI. 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.

In the early stages of 4map6 deployment, it can be expected that 4map6 attribute is mainly used in small multi-domain IPv6 networks 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 the Egress PE of the other operator sends a 4map6 BGP network announcement with Address Origin Type 0, the Ingress PE can trust the information in it, extract the item of the IPv4 address block, and store it in the local MD. 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 , " 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 need to be able to be applied to the embedded IPv4 networks, this security enhancement can be defined in other documents.

Contributors The following people have contributed to this document: CERNET Center/Tsinghua University

congxiao@cernet.edu.cn

Alibaba Cloud

linjian.slj@alibaba-inc.com

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 exmaple 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. 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.