Re: [Idr] MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement

[Chongfeng Xie <[e-mail]>]

Hi Ketan,

Thank you for your question, please see my feedback inline:

From: Ketan Talaulikar
Date: 2024-03-19 07:22
To: Chongfeng Xie
CC: Robert Raszuk; Acee Lindem; idr
Subject: Re: [Idr] MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement
Hi Chongfeng,

You've responded (and I am trimming to focus on that point):



[Chongfeng]:  Double-translation is a popular way for transition to IPv6-only, it has been even widely supported by terminal OS, such as IOS and Android. Double translation have deployed in the mobile networks of multiple operators.  In this case, double-translation is more suitable than encapsulation.  From the perspective of network operation, the extension to BGP should cover both cases, not only encapsulation, but also translation.

The wide deployment that you refer to seems to be on end hosts and not routers which is what is the current proposal. Is that correct? Also, can you clarify if these "wide deployments" translate from IPv4 Addr A --> IPv6 Addr B --> IPv4 Addr A? Or are they more like IPv4 Addr A --> IPv6 Addr B --> IPv4 Addr C (more like NAT)?

[Chongfeng]: This is related to the integration of IPv6-only access with IPv6-only transit, UE/CPE supports only translation, if the transit core support translation at the data layer, the IPv6-only data path can span from UE/CPE to egress PE router for end-to-end IPv4 service delivery. You can find the illustration in section 7of draft-ietf-v6ops-framework-md-ipv6only-underlay-04. In IPv6-only access, there is no IPv4 address allocated to UE/CPE, and the address change in the transit core should follow IPv4 Addr A--> IPv6 Addr B--> IPv4 Addr A, if I under your question correctly. 


Thanks,
Ketan

Best regards
Chongfeng