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

[Ketan Talaulikar <[e-mail]>]

Hi Robert,

Please check inline below for some clarifications.


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

> Hi Ketan,
>
>
>> 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 do not see anywhere in the draft you are pointing to how to maintain TOS
> bits, how to deal with TTL transparency, how to encode Flow label or how to
> carry protocol when doing the IPv4 to IPv6 translation (and reverse).
>
> The subject draft also neglects all the important points just focusing on
> address mapping.
>

KT> Fully agree


>
> Hence I also asked why not encapsulate ? **
>

KT> Yes, that is the solution for carrying IPv4 packets over an IPv6-only
underlay - that is a solved problem.


>
> What you are describing below is a different service - how IPv4 users can
> reach IPv6 only service - while very interesting and important question -
> IMHO a bit outside of the topic :).
>

KT> Well, I thought that is what the authors are claiming to solve/address.
The mixing of encapsulation and translation is what may be causing this
confusion. If doing encapsulation there is no need for mapping. If doing
translation then mapping is needed. The v6ops document seems to obfuscate
these two entirely different mechanisms.


>
> ** Of course there are people stating that encapsulation is evil as it
> adds per packet overhead. So be it - but if we are proposing an alternative
> to it - namely translation  - I am looking for a single spec based on which
> an implementer can actually deliver a required functionality.
>

KT> This is comparing "twice translation" vs "encapsulation" - if the goal
is indeed simply about carrying IPv4 traffic over IPv6-only transit
network. I would wait for the authors to clarify that goal first. Then I
would wait for the authors to say why "encapsulation is evil" in this
scenario - we've always tried to carry end user traffic encapsulated (be it
MPLS, VXLAN, for various flavors of IP-in-IP) over a transit network.

Thanks,
Ketan


>
> Cheers,
> Robert
>
>
>
>> 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
>>>
>>