Re: [Idr] Please discuss the use cases for draft-xie-idr-mpbgp-extention-4map6

[Robert Raszuk <[e-mail]>]

Dear Chongfeng,

When you need to transport IPv4 packet over IPv6 core and you want to do it
via translation just swapping the address is not enough. You need to deal
with *all* other IPv4 and IPv6 header elements and describe how they are
going to be mapped when you are "translating" IPv4 header to IPv6 header on
ingress and the reverse operation on egress.

Typically customers do not want transit to touch their header bits so
translation transparency becomes often the requirement.

In your draft you are just describing how to signal the address
translation in BGP. But in which document there is clear description how to
map all other fields of IPv4 header and how to assure their transparent
reappearance on the other side of the transit ?

Kind regards,
Robert


On Sat, Mar 16, 2024 at 1:40 AM Chongfeng Xie <[e-mail]>
wrote:

> Hi Robert,
>
> I understand that VPN4 is about encapsulation.  As mentioned before, the
> new extension in my draft focuses on the case of IPv4 delivery over
> multi-domain IPv6-only underlay network, it can support not only IPv4/IPv6
> encapsualtion, but also IPv4/IPv6 translation simultaneously. Translation
> is important transition mechanism, it has been widely developed.  From the
> perspective of an operator, it is better for a unified control plane to
> support all possible functions at the data plane. Further more, address
> mapping mechanism from IPv4 to IPv6 has several advantages for network
> operation, which have been discussed before.
>
> Thank you very much.
>
> Chongfeng
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Date:* 2024-03-11 00:23
> *To:* Chongfeng Xie <[e-mail]>
> *CC:* ketant.ietf <[e-mail]>; idr <[e-mail]>
> *Subject:* Re: [Idr] Please discuss the use cases for
> draft-xie-idr-mpbgp-extention-4map6
> Hi Chongfeng,
>
> > It adopts address mapping rule which is the 1:1 mapping between IPv4
> address and IPv6 address
>
> Let's assume that you are talking about prefixes not actual addresses as
> this is what draft says.
>
> But I have a fundamental question as an alternative to this proposal:
>
> Why not to use VPNv4 with IPv6 next hops as is without changing anything
> in the protocols or shipping implementations ?
>
> At min please kindly document pros and cons of using VPN signalling to
> accomplish the very same outcome.  For transport as you know VPNs can run
> over lot's of data plane options: IPv6, SRv6 etc ...
>
> Note that if you would not propose a new SAFI I could see some benefits to
> what you are after ... but you do hence we better very well understand the
> reason for this extra dev and ops cost.
>
> Many thx,
> Robert
>
>
> On Sun, Mar 10, 2024 at 9:40 AM Chongfeng Xie <[e-mail]>
> wrote:
>
>>
>> Hi Ketant,
>>
>> Sorry for my negligence of your mail accidentally. Actually your question
>> has been discussed early last year.  I try to answer it again as below，
>>
>> As mentioned The use case of 4map6 proposal in this draft is to support
>> IPv4aaS in the multi-domain IPv6-only networks.  It adopts address mapping
>> rule which is the 1:1 mapping between IPv4 address and IPv6 address, and
>> IPv4 address become part of IPv6 address. With this design，PE devices can
>> map the source and destination addresses of IPv4 packets to the source
>> addresses of outer IPv6 packets, respectively.  It mainly meets the
>> following requirements:
>>
>> 1）Compatibility with both encapsulation and translation, as we all know,
>> IPv4 service delivery over IPv6 network has two transition approaches:
>> Encapsulation and translation,  both of them have been used in current
>> networks. 4map6 proposal can meet their needs simultaneously. Especially in
>> translation, it can support both doulbe translation and single translation.
>>
>> 2）Security，the outer IPv6 address is dynamically generated based on
>> mapping, and does not require a statically configured address as the tunnel
>> endpoint address in advance.  This will be helpful to avoid the static IPv6
>> address from becoming the target of the DDOS attack.
>>
>> 3）Load balancing，the 4map6 proposal assigns a corresponding IPv6 address
>> to each host's IPv4 address in the IPv6 network, and the IPv6 address newly
>> generated can more accurately identify the host. This allows for IPv6
>> address based load balancing and management of the host in the IPv6 network
>> based on the IPv6 address.
>>
>>  I hope this explanation can address your concerns. Welcome to continue
>> the discussion.
>>
>> Best regards
>> Chongfeng
>>
>>
>> ------------------------------
>> [e-mail]
>>
>>
>> *From:* Ketan Talaulikar <[e-mail]>
>> *Date:* 2024-02-12 22:57
>> *To:* Chongfeng Xie <[e-mail]>;
>> draft-xie-idr-mpbgp-extension-4map6
>> <[e-mail]>
>> *CC:* jhaas <[e-mail]>; Susan Hares <[e-mail]>; idr
>> <[e-mail]>
>> *Subject:* Re: [Idr] Please discuss the use cases for
>> draft-xie-idr-mpbgp-extention-4map6
>> Hi Chongfeng/Authors,
>>
>> Thanks for your updates to the document.
>>
>> I am still struggling to find the answer to the question on why it is
>> necessary to perform mapping from IPv4 to IPv6 and then back to IPv4 when
>> providing IPv4 connectivity service over an IPv6 core? Why is it not
>> sufficient to simply encapsulate the IPv4 payload into any encapsulation
>> (e.g., IPv4-in-IPv6, SRv6, MPLS, GRE, etc.) using RFC8950 encoding for the
>> IPv4 unicast/VPN SAFI. These solutions are documented
>> in draft-mishra-idr-v4-islands-v6-core-4pe
>>
>> Perhaps I am missing something and it would help me understand the need
>> for such mapping by service provider PE routers.
>>
>> Thanks,
>> Ketan
>>
>>
>> On Thu, Feb 8, 2024 at 5:14 AM Chongfeng Xie <[e-mail]>
>> wrote:
>>
>>>
>>>
>>> Hi Jeff,
>>>
>>> We have submitted a new version of draft-xie-idr-mpbgp-extention-4map6.
>>> Based on your suggestions, the contents of new attribute is placed in a new
>>> TLV in the tunnel encapsulation attribute of RFC9012, and the format of the
>>> NLRI is revised as well. In addition, the section of operation has been
>>> changed accordingly.
>>>
>>>
>>>         Name:     draft-xie-idr-mpbgp-extension-4map6
>>>         Revision: 09
>>>         Title:    MP-BGP Extension and the Procedures for IPv4/IPv6
>>> Mapping Advertisement
>>>         Date:     2024-02-09
>>>         Group:    idr
>>>         Pages:    16
>>>         URL:
>>> https://www.ietf.org/archive/id/draft-xie-idr-mpbgp-extension-4map6-09.txt
>>>         Status:
>>> https://datatracker.ietf.org/doc/draft-xie-idr-mpbgp-extension-4map6/
>>>         HTMLized:
>>> https://datatracker.ietf.org/doc/html/draft-xie-idr-mpbgp-extension-4map6
>>>         Diff:
>>> https://author-tools.ietf.org/iddiff?url2=draft-xie-idr-mpbgp-extension-4map6-09
>>>
>>> We express sincere thanks to you for reviewing the draft as WG chair and
>>> providing a couple of important suggestions.  We also thank idr WG for the
>>> comments and suggestions received so far.
>>>
>>> If you have any new comments or suggestions, please feel free to let me
>>> know. Thanks!
>>>
>>> Best regards
>>> Chongfeng
>>>
>>>
>>> *From:* 【外部账号】Jeffrey Haas <[e-mail]>
>>> *Date:* 2024-02-05 00:02
>>> *To:* Chongfeng Xie <[e-mail]>
>>> *CC:* Sue Hares <[e-mail]>; idr <[e-mail]>;
>>> draft-xie-idr-mpbgp-extension-4map6
>>> <[e-mail]>
>>> *Subject:* Re: [Idr] Please discuss the use cases for
>>> draft-xie-idr-mpbgp-extention-4map6
>>> Chongfeng,
>>>
>>>
>>> On Jan 29, 2024, at 10:38 AM, Chongfeng Xie <[e-mail]>
>>> wrote:
>>> Based on your comment and suggestions, we have made the following
>>> revisions and submitted a new version,
>>>
>>>
>>>
>>> [...]
>>>
>>> If you have any further comments, please feel free to let me know.
>>>
>>>
>>> Your changes significantly address my operational concerns.  Thank you.
>>>
>>> -- Jeff
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>