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

[Ketan Talaulikar <[e-mail]>]

Hi Robert,

Please check inline for short responses while we wait for authors and
experts from v6ops to help clarify.


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

> HI Ketan,
>
> 100% agree with all what you have said.
>
> It is just to me the goal of the draft is pretty clear - authors attempt
> to specify dynamic signalling for IPv4-to-ipv6-to-IPv4 connectivity - two
> times translation.
>
> I also agree to wait for them to clarify it. But I expect they will simply
> restate that some operators may prefer double translation and some may
> prefer encapsulation :)  Clearly v6ops seems not to be dismissing any of
> them.
>

KT> Yes, this clarification from the authors as well as v6ops would help.


>
> In fact they neatly illustrated this as well:
>
>      IPv4 A1        +-------+       +-+       +------+        IPv4 A2
>   +----------+    /    AS1    \    /AS2\    /    AS3   \    +----------+
>   |  IPv4    |   |+--++  +---+ |  |+--+ |  | +--+ +--+  |   |  IPv4    |
>   |network N1|---||PE1|--| P1|-|--||P2|-|--|-|P3|-|PE2|-|---|network N2|
>   +----------+   |+---+  +---+ |  |+--+ |  |  +--+ +--+ |   +----------+
>                   \           /    \   /    \          /
>                     +-------+       +-+       +------+
>   Figure 1:Topology of Typical Multi-domain IPv6-only Network
>
>
> Back to your case if we hook v6 service node (say web page) anywhere within IPv6 only AS1 or AS2 or AS3 I am not sure who should trigger any BGP advertisement ...
>
>
KT> OK. You got me here! Like I said, I don't know the existing deployment
practices of the IPv4/IPv6 translation mechanisms to answer that question.
But, I would assume that those mapped routes would be getting advertised
into BGP for such a service to be reachable?

Thanks,
Ketan


>
> Best regards,
>
> Robert
>
>
>
> On Sat, Mar 16, 2024 at 4:09 PM Ketan Talaulikar <[e-mail]>
> wrote:
>
>> 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
>>>>>
>>>>