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

Chongfeng Xie <xiechf@chinatelecom.cn> Mon, 23 January 2023 00:39 UTC

Return-Path: <xiechf@chinatelecom.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91E8C151701; Sun, 22 Jan 2023 16:39:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.885
X-Spam-Level:
X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLTGSetF9Q6F; Sun, 22 Jan 2023 16:39:19 -0800 (PST)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1D148C1516FF; Sun, 22 Jan 2023 16:39:15 -0800 (PST)
HMM_SOURCE_IP: 172.18.0.188:54336.1768477402
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-122.97.174.106 (unknown [172.18.0.188]) by chinatelecom.cn (HERMES) with SMTP id 9EDB02800AF; Mon, 23 Jan 2023 08:39:10 +0800 (CST)
X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn
Received: from ([122.97.174.106]) by app0023 with ESMTP id 7fd82870e62b4fc5b4c6f25821c67fb1 for idr-chairs@ietf.org; Mon, 23 Jan 2023 08:39:13 CST
X-Transaction-ID: 7fd82870e62b4fc5b4c6f25821c67fb1
X-Real-From: xiechf@chinatelecom.cn
X-Receive-IP: 122.97.174.106
X-MEDUSA-Status: 0
Sender: xiechf@chinatelecom.cn
Date: Mon, 23 Jan 2023 08:39:10 +0800
From: Chongfeng Xie <xiechf@chinatelecom.cn>
To: idr-chairs <idr-chairs@ietf.org>, idr <idr@ietf.org>
Cc: donggz <donggz@chinatelecom.cn>, xing <xing@cernet.edu.cn>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.23.121[cn]
Mime-Version: 1.0
Message-ID: <202301230839078513104@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart717645181802_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6E5FMikGdCb4tPoRE_5nOa2Wkxs>
Subject: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jan 2023 00:39:23 -0000




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
Date: 2023-01-17 19:33
To: internet-drafts
CC: donggz; xing; idr-chairs
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
Date: 2023-01-17 19:17
To: Chongfeng Xie; Guozhen; Guozhen Dong; Xing Li
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