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

[Robert Raszuk <[e-mail]>]

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.

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 ...


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
>>>>
>>>