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

[Chongfeng Xie <[e-mail]>]

Hi Robert,

Thank you for your new comments, see my comments inline please...
 
发件人： Chongfeng Xie
发送时间： 2023-01-25 07:47
收件人： xiechf
主题： 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.[Chongfeng]: Let's make a preliminary quantitative analysis, suppose the size of IPv4 BGP table of Internet is R, and that of IPv6 is S, the values of R and S are about 1M and 200k respectively now. Just from the perspective of IPv6 BGP routing, introduction of new address-family will have new cost, but from the perspective of the network as a whole, this is equal to move IPv4 reachability information into IPv6 domains by mapping, there will be no native IPv4 reachability information table in multi-domain networks anymore. Furthermore, the forwarding of IPv4 services in P routers will be based on IPv6 FIB, the size of which is much smaller than R+S. Therefore, on the whole, the cost can be negligible or even less than before. Of course, this is only a very rough analysis, which needs further discussion.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.[Chongfeng]: I agree with you that it is local configuration to place mapped address as source in the outer encapsulation.  But it is not true for destination address, the creation of outer IPv6 destination address needs to get the IPv6 mapping prefix of remote end-point in advance, which needs the coordination of different nodes.
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 ?
[Chongfeng]: This is just used to describe the existing and mature encapsulation approaches, there is no discrimination or negative view of them. :-)
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.[Chongfeng]: Can you show which draft or RFC specifies the technology or procedure to get the mapping prefix of remote-end? 
> 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. [Chongfeng]: I didn't deny this. What I mean is that it needs to use specific and explicit IPv6 addresses for tunnel encapsulation.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.[Chongfeng]:  The multi-domain networks mentioned in my draft is open, it is not a closed system, it can consist of multiple ASes and be operated by different operators. DDOS attack is always a threaten to carriers. Since the mapping rule mechanism in this draft generates the outer IPv6 addresses by appending the IPv4 address to the IPv6 mapping prefix automatically, the possibility of attacking to a pre-configured tunnel address from outside can be avoided. However, this is not within the scope of this draft yet.
Many thx,R.
Thank you again for your comments. I'd like to have more discussion with you.
Best regardsChongfeng 

On Mon, Jan 23, 2023 at 1:39 AM Chongfeng Xie <[e-mail]>
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 <[e-mail]>
> *Date:* 2023-01-17 19:33
> *To:* internet-drafts <[e-mail]>
> *CC:* donggz <[e-mail]>; xing <[e-mail]>;
> idr-chairs <[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 <[e-mail]>
> *Date:* 2023-01-17 19:17
> *To:* Chongfeng Xie <[e-mail]>; Guozhen
> <[e-mail]>; Guozhen Dong <[e-mail]>; Xing Li
> <[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
>
>
>


[e-mail]