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

[Ketan Talaulikar <[e-mail]>]

Hi Robert,

Let me share some pointers and my analysis that you can cross-check/review.
Having another pair of eyes/perspective would be helpful in clearing my
understanding as well.

Those aspects/details that you are looking for are coming from
https://datatracker.ietf.org/doc/draft-ietf-v6ops-framework-md-ipv6only-underlay/
which is an informational document in v6ops WG (therefore copying them).
Disclaimer: I am not an expert on these IPv6 mapping/transition techniques.

I believe the crux of the matter is this piece:
https://www.ietf.org/archive/id/draft-ietf-v6ops-framework-md-ipv6only-underlay-04.html#section-6.2
which seeks to put this "translation" function in a PE router. Which by
itself is OK.

But I have some basic concerns on this proposal and I will refer to text
from the v6ops WG draft as well:

1) Why is back/forth translation required when there are encapsulation
methods available that preserve the end to end sanctity of the end user
packets?

From
https://www.ietf.org/archive/id/draft-ietf-v6ops-framework-md-ipv6only-underlay-04.html#name-overview

Take the latter case as an example, when IPv4 packets that need to traverse
lPv6-only network, the ingress PE, i.e., PE1, will *convert IPv4 packets
into lPv6 packets by translation* or encapsulation and send them into IPv6
network. After intra-domain and cross-domain transmission, the IPv6 packets
reach the egress PE, i.e., PE2, *then be restored to IPv4 packets*.

I can understand the use of translation when an IPv4-only client is talking
to an IPv6 server. I am having a tough time understanding why IETF would
bless the translation back/forth simply to carry the traffic over an
IPv6-only underlay (as the draft says)?

2) Now, if we were to remove this requirement for back/forth translation
then every (PE) router would be providing this mapping services for
IPv4-only hosts behind it. In that case, what we need is:

(a) The PE router needs to know/learn which IPv4 destinations are in fact
IPv6-only and therefore need to be mapped to IPv6. Assuming those IPv4
prefixes are learnt via AFI 1 SAFI 1, we need an indication in BGP that
these routes need translation - perhaps a community or something more
well-known?

(b) The PE router needs to know/learn what IPv6 prefix is available for
such a mapping function. Not sure if this requires BGP protocol extensions
since there are many mapping techniques already deployed that don't seem to
need one. Refer
https://www.ietf.org/archive/id/draft-ietf-v6ops-framework-md-ipv6only-underlay-04.html#name-introduction

(c) The PE router needs to advertise the IPv6 mapped prefixes corresponding
to IPv4 prefixes that are hosted behind it. I assume that AFI 2 SAFI 1 can
be used for such advertisements. These prefixes can be determined as part
of (a) and could be "imported" from AFI 1 SAFI 1 after mapping on the PE
router locally.

It is likely that I am missing something here ... as I've been saying since
the adoption poll for this document in IDR. But I have not seen a clear and
crisp answer to justify this BGP extension.

Are you (or anyone) able to help cross-check/correct my understanding?

Thanks,
Ketan


On Sat, Mar 16, 2024 at 2:43 PM Robert Raszuk <[e-mail]> wrote:

> 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
>>>
>> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>