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

Hi Chongfeng,

Ad 1 -

> The mapping rule can be transmitted within and across domains

Introduction of a new address-family always has a significant operational
burden. If you intend to make it work interdomain all involved domains now
must be upgraded to support new AFI/SAFI.

That is a real obstacle if sites would like to also connect to the Internet
as now you need a gateway to translate new SAFI into 1/1.

Ad 2 -

As we have discussed offline what you put as encapsulation src or dst is a
local matter.  Nothing prevents local configuration to place fully mapped
address as src and/or dst in the outer encapsulation today.

In all cases routing in the core to egress PE would be done based on IPv6
prefix of the egress node.

You keep repeating "legacy encapsulation mode" ... that pejorative
statement has no basis here as you are not proposing any new encapsulation.
All you are proposing in the draft is to carry IPv4 mapped IPv6 addresses
in new BGP SAFI.

So what is your definition of "legacy encapsulation mode " ? And what is
the "modern" version of it ?

That alone is highly questionable as such mapping's algorithm is well known
and each node can do the mapping by itself. All it needs to know is the
AFI/SAFI 1/1 and tunnel endpoint. There is no magic to it. This really
proves no justification to invent new SAFI for it.

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

As we also discussed, tunnel endpoint does not and in many case is not the
same as BGP next hop.

Ad 3 -

Addressed in #2.

It is however interesting that you are bringing a security aspect for a
closed domain(s) service. Are you afraid that your own customers will be
attacking the subject infrastructure ?

If this is about Internet sourced attacks your infra there are well known
techniques to prevent that irrespective of the subject draft.

Many thx,
R.

On Mon, Jan 23, 2023 at 1:39 AM Chongfeng Xie <xiechf@chinatelecom.cn>
wrote:

>
>
>
>
> 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 <xiechf@chinatelecom.cn>
> *Date:* 2023-01-17 19:33
> *To:* internet-drafts <internet-drafts@ietf.org>
> *CC:* donggz <donggz@chinatelecom.cn>; xing <xing@cernet.edu.cn>;
> idr-chairs <idr-chairs@ietf.org>
> *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 <internet-drafts@ietf.org>
> *Date:* 2023-01-17 19:17
> *To:* Chongfeng Xie <xiechf@chinatelecom.cn>; Guozhen
> <donggz@chinatelecom.cn>; Guozhen Dong <donggz@chinatelecom.cn>; Xing Li
> <xing@cernet.edu.cn>
> *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
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>