Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

Hi Erik,

El 9/1/20 21:07, "v6ops en nombre de Erik Nygren" <v6ops-bounces@ietf.org en nombre de erik+ietf@nygren.org> escribió:

While I'm very supportive of 464xlat as a transition technology, and while I was very optimistic about this approach 

at first (and may even have suggested some of the proposals included in the draft), on subsequent

reflections I continue to have significant concerns about the fragility of this approach.

CPEs have already state with IPv4, and what we are suggesting is just more of the same (as you said, thanks in part to your suggestions!).

Implementing this in a way that works well with a generic CDN  (ie, one not managed

by the operator) will require a significant amount of state and complexity in CPE devices.

It only will take one or two bad CPE implementations to result in CDNs being forced to switch

content to IPv4-only to address user complaints, which would undo what this 

is trying to achieve.

I’m for not breaking anything, of course, it could not be smart to get an RFC from something that we know that breaks things.

In particular, the fundamental issue is that the RR sets returned for A and AAAA records

from many CDNs are not 1:1 and also change frequently during the lifetime of connections.

No doubt, that I will review as many times as needed, all the possible “flows” and interactions to make sure that the text in the document is working and not breaking anything.

As such, I continue to have serious reservations about trying to move this forwards

as anything other than Experimental.  If we do move forward, the DNS-based approach

You’re right that a single CPE implementation will be bad. But, how that is different from any other RFC?

needs to be comfortable moving lots more state into the CPE than I recall seeing

in the last version of this that I read.   In particular, if DNS sees changes to {A,AAAA} 

pairings, it is critical to only apply those to future connections and not break existing 

connections, meaning that CPEs need to keep these rewrite rules associated

with stateful connection tracking.

This is what we have now in the document. I can extend the text to make sure it is clear enough and helps implementors in understanding all your points.

With the use-case for this being IPv4-only devices, a question may be whether

it is better to focus on trying to get those devices to implement native IPv6 support

I will agree on that, but when you ask for vendors of those devices if they will upgrade them to support IPv6, the response is “buy a new SmarTV”. Not everyone can buy a new SmartTV every few years … and what about devices that are still in use and the manufacturer is no longer there?

while handling them via a CLAT in the CPE for the time-being.  Alternately, lw4o6

addresses the "offload stateful NAT off of the CPE" in a much less fragile way.

The point here is that only 464XLAT is supported in mobile, and as a consequence, in many cases, and especially in operators that want to have a single mechanism for all their access networks, other transition mechanisms aren’t a solution.

        Erik

On Wed, Dec 11, 2019 at 2:25 PM Ron Bonica <rbonica=40juniper.net@dmarc.ietf..org> wrote:

Folks,

Each week between now and IETF 107, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-palet-v6ops-464xlat-opt-cdn-caches.

When reviewing this draft, please indicate whether you think that V6OPS should adopt it a s a work item.

                                                      Fred and Ron

Juniper Business Use Only

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.