Re: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Chongfeng, WG:

Thank you Chongfeng firstly for providing the background information.
I think it may be useful to understand the background before we understand how and why the IDR-4map6 draft (draft-xie-idr-mpbgp-extention-4map6-00) is so defined.
FYI: I have read the draft <draft-ietf-v6ops-framework-md-ipv6only-underlay> as the background in https://datatracker.ietf.org/doc/draft-ietf-v6ops-framework-md-ipv6only-underlay/ .


I will use an example with topology to show my understanding on the overall solution (mainly process from data plane view), and based on that understanding I will give my comments on the IDR-4map6 draft:

Topology:  Host1----CE1----PE1--------PE2----CE2----Host2

Case1: Using IPv6-Mapping-Translation (IPv6-Map-T for short)
Packet from Host1---->Host2:
host1->CE1:  (IPv4 S=Host1<192.168.1.x>, D=Host2<192.168.2.y>)(Upper-layer Header like TCP or UDP)(Payload);
CE1->PE1:  (IPv4 S=Host1<192.168.1.x>, D=Host2<192.168.2.y>)(Upper-layer Header like TCP or UDP) (Payload);
PE1->PE2:  (IPv6 S=PE1<2001:db8:1:1:1:1:192.168.1.x>, D=PE2<2001:db8:2:2:2:2:192.168.2.y>)(Upper-layer Header like TCP or UDP) (Payload);
PE2->CE2:  (IPv4 S=Host1<192.168.1.x>, D=Host2<192.168.2.y>)(Upper-layer Header like TCP or UDP) (Payload);
CE2->host2:  (IPv4 S=Host1<192.168.1.x>, D=Host2<192.168.2.y>)(Upper-layer Header like TCP or UDP) (Payload);

Packet from Host1<----Host2:
CE2<-host2:  (IPv4 S=Host2<192.168.2.y>, D=Host1<192.168.1.x>)(Upper-layer Header like TCP or UDP) (Payload);
PE2<-CE2:  (IPv4 S=Host2<192.168.2.y>, D=Host1<192.168.1.x>)(Upper-layer Header like TCP or UDP) (Payload);
PE1<-PE2:  (IPv6 S=PE2<2001:db8:2:2:2:2:192.168.2.y>, D=PE2<2001:db8:1:1:1:1:192.168.1.x>)(Upper-layer Header like TCP or UDP) (Payload);
CE1<-PE1:  (IPv4 S=Host2<192.168.2.y>, D=Host1<192.168.1.x>)(Upper-layer Header like TCP or UDP) (Payload);
host1<-CE1:  (IPv4 S=Host2<192.168.2.y>, D=Host1<192.168.1.x>)(Upper-layer Header like TCP or UDP) (Payload);


Case2: Using IPv6-Mapping-Encapsulation (IPv6-Map-E for short)
Packet from Host1---->Host2:
PE1->PE2:  (IPv6 S=PE1<2001:db8:1:1:1:1:192.168.1.x>, D=PE2<2001:db8:2:2:2:2:192.168.2.y>) (IPv4 S=Host1<192.168.1.x>, D=Host2<192.168.2.y>) (Upper-layer Header like TCP or UDP) (Payload);

Packet from Host1<----Host2:
PE1<-PE1:  (IPv6 S=PE2<2001:db8:2:2:2:2:192.168.2.y>, D=PE1<2001:db8:1:1:1:1:192.168.1.x>) (IPv4 S=Host2<192.168.2.y>, D=Host2<192.168.1.x>) (Upper-layer Header like TCP or UDP) (Payload);


Note that, I will mainly use the IPv6-Map-T (Case-1 above) for the following illustration of my understanding.
For Packet from Host1---->Host2:
On Ingress PE (PE1):
PE1 need to first lookup the IPv4 Dest address <192.168.2.y> and match the mapping rule [2], and then translate the DA from <192.168.2.y> to <2001:db8:2:2:2:2:192.168.2.y>;
PE1 need then to lookup the IPv4 Src address <192.168.1.x> and match the mapping rule [1], and then translate the SA from <192.168.1.x> to <2001:db8:1:1:1:1:192.168.1.x>;
I will assume that will be an IPv4 DST-SRC lookup procedure, and an IPv4-FIB-Entry (192.168.2.y/24) and IPv4-FIB-Entry (192.168.1.x/24) should be built (on PE1).

On Egress PE (PE2):
PE2 need to first lookup the IPv6 Dest address <2001:db8:2:2:2:2:192.168.2.y> and match the mapping rule [2], and then translate the DA to <192.168.2.y> from <2001:db8:2:2:2:2:192.168.2.y>;
PE2 need then to lookup the IPv6 Src address <2001:db8:1:1:1:1:192.168.1.x> and match the mapping rule [1], and then translate the SA to <192.168.1.x> from <2001:db8:1:1:1:1:192.168.1.x>;
I will assume that will be an IPv6 DST-SRC lookup procedure, and an IPv6-FIB-Entry (2001:db8:2:2:2:2:192.168.2.y/120) and IPv6-FIB-Entry (2001:db8:1:1:1:1:192.168.1.x/120) should be built (on PE2).

For Packet from Host1<----Host2:
An IPv4-FIB-Entry (192.168.2.y/24) and IPv4-FIB-Entry (192.168.1.x/24) should be built (on PE2).
An IPv6-FIB-Entry (2001:db8:2:2:2:2:192.168.2.y/120) and IPv6-FIB-Entry (2001:db8:1:1:1:1:192.168.1.x/120) should be built (on PE1).


The above behavior is relying on the use of BGP to advertise the relationship of IPv6-address-block and IPv4-address-block, and that is the meaning of the “mapping rule”:
PE1---->PE2: mapping rule 1 advertised from PE1: (IPv6-address-block<2001:db8:1:1:1:1:192.168.1.x/120>, IPv4-address-block<192.168.1.x/24>) [1];
PE1<----PE2: mapping rule 1 advertised from PE2: (IPv6-address-block<2001:db8:2:2:2:2:192.168.2.y/120>, IPv4-address-block<192.168.2.y/24>) [2];

PE1 will build both IPv4 and IPv6 FIB Entry for the 4map6 packet processing to be done, from the BGP message (advertised by PE2) and the Local configuration (which will advertise to PE2).
PE2 will build both IPv6 and IPv4 FIB Entry for the 4map6 packet processing to be done, from the BGP message (advertised by PE1) and the Local configuration (which will advertise to PE1 ).


From the above understanding, I will have the following comments to this draft:
(1) Build the relationship of “Mapping-rule database” and “FIB”, and the relationship of “Mapping-rule” and the “FIB Entry”.
The “Mapping-rule” and “Mapping-rule database” are concepts defined in <draft-ietf-v6ops-framework-md-ipv6only-underlay>.
The “FIB” and “FIB Entry” are concepts that is more related to RIB, routing, and IGP/BGP protocol, and the existing implementations, etc.

(2) Use of existing BGP SAFI like RFC5549 for the advertisement of “mapping-rule” may be a reasonable choice, because the “mapping-rule” can be a FIB/RIB Entry, and current BGP SAFI is suitable for build a FIB/RIB Entry.
A FIB/RIB Entry has a key for Longest-Prefix-Match, and a set of attributes to indicate the behavior and parameters.
The “legacy tunnels” ,“IPv6-Map-T”  and “IPv6-Map-E” can all be supported by the “attributes” of a FIB/RIB Entry.
Please Note that, 1 mapping rule between IPv4-address-block and IPv6-address-block, will lead to 2 FIB entries ---- 1 FIB entries with the key being IPv4-address-block and 1 with the key being IPv6-address-block!!!

(3) For the allocation and management of IPv6-address-block ( see above PE1 & PE2), I would suggest that SRv6 Network Programming (RFC8986) is considered.
With this consideration, the aforementioned IPv6-Map-T and IPv6-Map-E will become SRv6-Map-T and SRv6-Map-E.

(4) VPN/VRF is considered between CE1----PE1 and PE2----CE2.
Note RFC5549 also support VPN, and there are more existing SAFI like EVPN (route type 5) can support VPN as well.
Note also that, this draft currently doesn’t support VPN yet, and will become more complex if VPN will be supported.

(5) Summarizing all above points, I currently think out the following protocol extension for IDR-4map6 for your consideration && WG discussion:

(5.1) Using SAFI 1/128/70 to carry the the “key” prefix, and an IPv4/IPv6 address specific Extended Community newly defined to carry the “attribute” prefix, and an attribute like “Color” or “Tag” for local routing-policy to populate the RIB/FIB Entry of SRv6-Map-T/E.

(5.2) Example-1: PE1 advertises the following routes (which constitute to a single mapping rule):
Route-1: SAFI-1 NLRI=192.168.1.x/24, IPv6-Addr-Specific-Ext-Community=2001:db8:1:1:1:1:192.168.1.x/120, Color=20230128
Route-2: SAFI-1 NLRI=2001:db8:1:1:1:1:192.168.1.x/120, IPv4-Addr-Specific-Ext-Community=192.168.1.x/24, Color=20230128

(5.3) Example-2: PE2 advertises the following routes (which constitute to a single mapping rule):
Route-3: SAFI-1 NLRI=192.168.2.y/24, IPv6-Addr-Specific-Ext-Community=2001:db8:2:2:2:2:192.168.2.y/120, Color=20230128
Route-4: SAFI-1 NLRI=2001:db8:2:2:2:2:192.168.2.y/120, IPv4-Addr-Specific-Ext-Community=192.168.2.y/24, Color=20230128

(5.4) Example-3: PE1 and PE2 using the following local-route policy to import the route:
{ if-match Color 20230128, then mark the FIB Entry for SRv6-Map-T or SRv6-Map-E};

(5.5) In such a way, the extension to BGP protocol  and implementation will be minimal, and the compatibility will be maximal IMO.


Thanks,
Jingrong

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: Idr [mailto:[e-mail]] On Behalf Of Chongfeng Xie
Sent: Monday, January 23, 2023 8:39 AM
To: idr-chairs <[e-mail]>; idr <[e-mail]>
Cc: donggz <[e-mail]>; xing <[e-mail]>
Subject: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt





Hello, folks,

Since the drafts was submitted several days ago, we have received Robert and Gyan's comments, which are very valuable. Thanks.

Here I'd like to provide some background information about this draft:
1）Firstly, its use case is to support IPv4aaS in the multi-domain IPv6-only networks.  The framework has been defined in [draft-ietf-v6ops-framework-md-ipv6only-underlay],it adopted a specific data structure called address mapping rule, which is the mapping relationship between IPv4 address block and IPv6 mapping prefix of the PE devices. In order to forward IPv4 service data, mapping rule is used by the ingress PE to generate corresponding IPv6 source and destination addresses from its IPv4 source and destination address, and vice versa. The mapping rule can be transmitted within and across domains, therefore, it gives the direction of IPv4 service data transmission in multi-domain IPv6-only networks. Moreover, since this is prefix-level mapping, there is no need to maintain user-related status or translation tables at the PE devices.

2）Secondly, the encapsulation approach supported by the mapping rule is different from legacy tunnels in terms of the outer address creation.
In the legacy encapsulation mode, the mapping of original IPv4 address and IPv6 address is N:1, i.e., IPv4 packets with different combination of source and destination address share the same IPv6 tunnel. The outer IPv6 addresses are unrelated to the inner IPv4 addresses, so it is difficult for the network to distinguish the host.

The approach in my draft uses rule-based address mapping, the IPv6 source addresses automatically generated comprises the original IPv4 source addresses of the packet, the IPv6 destination addresses comprises the original IPv4 destination addresses too. Thus, for all the IPv4 packets which have the same IPv6 data path in IPv6-only network, when the inner IPv4 addresses are different, the outer IPv6 addresses will be different correspondingly, which is equivalent to establishing specific tunnels for different IPv4 packets, so the network can easily identify hosts based on the outer source and destination IPv6 addresses.

RFC9012 does not have this feature, it still relies on explicit IPv6 address of the router, e.g., BGP next-hop, as the tunnel point.

3) In addition，the mapping rule-based mechanism expects to make some security enhancement over traditional tunnel. In the legacy encapsulation mode, endpoint IP address on PE device can easily become a target of DDOS attack from the Internet. But in the new approach, there is no specific physical end-point address on each PE, the tunnel endpoint address is generated dynamically by using IPv6 mapping prefix to splice IPv4 addresses. This will be helpful to avoid the static IPv6 address from becoming the target of the DDOS attack.

Based on the considerations above, in order to exchange the mapping rule across domains, this draft proposes to make necessary extensions to MP-BGP in a feasible and effective way. Of course, this draft is only at the primitive stage, and there are many aspects to be modified and improved. I hope to receive more comments and suggestions.

Best regards
Chongfeng


From: Chongfeng Xie<mailto:[e-mail]>
Date: 2023-01-17 19:33
To: internet-drafts<mailto:[e-mail]>
CC: donggz<mailto:[e-mail]>; xing<mailto:[e-mail]>; idr-chairs<mailto:[e-mail]>
Subject: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt

Hello, everyone,
We have just submitted a new draft, which is about MP-BGP extension for multi-domain IPv6-only neworking. Since this is its first submission, there must be many defects in it, we look forward to receiving more comments, suggestions and even criticism.

Best regards
Chongfeng


From: internet-drafts<mailto:[e-mail]>
Date: 2023-01-17 19:17
To: Chongfeng Xie<mailto:[e-mail]>; Guozhen<mailto:[e-mail]>; Guozhen Dong<mailto:[e-mail]>; Xing Li<mailto:[e-mail]>
Subject: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt

A new version of I-D, draft-xie-idr-mpbgp-extention-4map6-00.txt
has been successfully submitted by Chongfeng Xie and posted to the
IETF repository.

Name: draft-xie-idr-mpbgp-extention-4map6
Revision: 00
Title: MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement
Document date: 2023-01-15
Group: Individual Submission
Pages: 13
URL:            https://www.ietf.org/archive/id/draft-xie-idr-mpbgp-extention-4map6-00.txt
Status:         https://datatracker.ietf.org/doc/draft-xie-idr-mpbgp-extention-4map6/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xie-idr-mpbgp-extention-4map6


Abstract:
   This document defines NLRI with specific AFI/SAFI combination, a new
   BGP path attribute known as the "4map6" and a set of related
   procedures, which can be used for transferring IPv4/IPv6 address
   mapping rule to support IPv4 service delivery in multi-domain
   IPv6-only underlay networks.




The IETF Secretariat