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

From: Fernando Gont <[email-masked]>
Date: Fri, 3 Jan 2020 18:40:11 -0500

Folks,

I've read the document, and have the following comments:

It would seem to me is that this document has resulted from an
operators' concern that deployment of 464xlat might result in
unnecessary heavyweight use of the stateful PLAT, leading to scalability
problems or unnecessary money spendings. In that sense, I would like the
issue to be documented (even if somehow we don't agree on a workaround).

So I support the adoption of this document (or some version of it) --
i.e., there's value in documenting the issue itself.

That said, I think that further work is required on the document. PLease
find my review below:

**** Some meta comments ****

* Meta: I'd put more stress on why this "optimization" is important. You
delve into many other (rather unnecessary) details, but don't elaborate
much regarding why this "optimization" is important.

* Meta: It'd be important to note that, according to the Abstract of
RFC6877, 464XLAT assumes IPv4 services over an IPv6-only node. In that
sense, the behavior you describe is kind of "expected", and what you
describe would seem to me more of a mechanism to *opt out of 464xlat*
than an optimization to 464XLAT itself.

* It would seem to me that the cases where this issue is more of a
concern is essentially smartboxes (smart TVs) consuming media from large
CDNs. If so, this should be spelled out, since this essentially sets the
context for what options/approaches can be considered acceptable.

*** Some specific comments: ****

* Abstract: I'm curious if the term "NAT46" can be confusing, for
multiple reasons (for instance, it's not specified in RFC7915). Just use
"SIIT", and the context (i.e., describe what's on each side of the SIIT
device, and what's the intent).

* Introduction:
It seems to me the intro contains too many unnecessary details. e.g.,
just talk about the CLAT as an abstract concept. Where/how
(specifically) it is implemented is mostly irrelevant in the context of
this document.

* Section 4:
Is the option where packets might get to the Cache with *private space*
worth mentioning/describing/discussing?

* Section 4.3:
   One more advantage of this solution is that the EAMT pairs doesn't
   need to match the "real" IPv4/IPv6 addresses available in the A/AAAA
   records, as shown in the next example.

Please elaborate.

* Section 5:
   If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is chosen, it can
   be complemented to resolve this issue, by means of making sure that
   IPv6-only destinations have one A resource record (even an invalid
   one), despite they aren't actually connected to IPv4.

Not sure what you mean.

* Section 5:
   In fact, it may become an incentive for the IPv6 deployment in
   Internet services and provides the option to use an IPv4 address
   (maybe anycast) for the "non-valid" A resource record, that points to
   a "universal" web page (maybe hosted by IETF?) that displays a
   warning such as "Sorry, you don't IPv6 support in your operator, so
   this service is not available for you".

Please *no*, for so many different reasons. -- including "the average
user doesn't care about IPv6, and may not even be aware of what it is".

* Section 6:
   Should we recommend having A records for IPv6-only services in
   Internet?  The A record may point to a "reserved" or "special" IPv4
   address.  A web page IPv4-only hosted by IETF(?) showing "sorry this
   web page/service is only available from IPv6 enabled operators"?.

Please no. This assumes (?) hosts prefer IPv6, but they don't need to.
In which case they would get to such page and have a not so great
WTH(!?) moment.

* Section 6:
   NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right
   solution for optimizing the access to dual-stack services, whether
   they are located inside or outside the ISP.

It would seem to me that, actually, Approach #3, when the ISP has no
control on the CDN, or approach #1 (when it does), are the way to go.
Approach #2 seems rather complex, with the consequent opportunities to
screw up.

* Section 6:
   SIIT already has a SHOULD for EAM support.  Should 464XLAT be updated
   by this document so the CLAT has a MUST for EAM support?.

464xlat employs existing technologies. So I'm not sure you can do a MUST
in 464xlat, when it relies on SIIT, and for SIIT the requirement is a
SHOULD.

Besides, the 464xlat spec does not even employ RFC2119 language.

* Section 7:

Any solution where you spoof DNS records would play bad with DNSsec.
This should at least be discussed.

Thanks!

Cheers,
Fernando

On 11/12/19 14:24, Ron Bonica 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
> 

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Alejandro D'Egidio <[email-masked]>
Date: Sat, 4 Jan 2020 00:33:34 -0300 (ART)

Hello Fernando,

First at all, thanks for your support to the work and the document and for taking your time to read all the document.

I will try to answer your comments below.

Regards,
Alejandro

----- Mensaje original -----
> De: "Fernando Gont" <[email-masked]>
> Para: "Ron Bonica" <rbonica=[email-masked]>, "[email-masked] list" <[email-masked]>
> Enviados: Viernes, 3 de Enero 2020 20:40:11
> Asunto: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

> issue to be documented (even if somehow we don't agree on a workaround).
Yes, from one point of view it is correct what you said and in addition to that we have an unnecessary second translation (NAT64) when customer traffic was translated to IPv6 (NAT46) and the destination (content) is available in IPv6 also, so we could avoid both a bottleneck and a performance impairment. That's why we consider this as an optimization.

> much regarding why this "optimization" is important.
Yes, it is true, maybe the introduction could be simpler and more oriented to show the concrete problem and why we believe this is important.

I don't know if the info is wrong, maybe a specific initial summary that indicates it is missing. We can consider it.

> than an optimization to 464XLAT itself.
Yes, 464XLAT asumes both IPv4 services and IPv4-only devices also.
Yes, this is the expected behavior of 464XLAT (and MAP-T also) but from a practical and performance point of view, maybe, it is not the most optimal path for the end-to-end traffic flow. As you said if we avoid the NAT64, technically speaking, the traffic will not be going through a 464XLAT/MAP-T scenario.
We are not saying that 464XLAT is wrong at all, we are trying to expose a real problem for IPv6 only network deployments and trying to present some approaches to solve it (or minimize it).

> context for what options/approaches can be considered acceptable.
Ok, yes, we can put more effort to explain that.
 
> device, and what's the intent).
We can review it if it is confusing.
The idea on this point was to talk about the NAT46 of CPE (CLAT).
Yes, RFC7915 talks about SIIT independently if it is NAT46 or not.
Regarding "(IP/ICMP Translation Algorithm) as described by [RFC7915]" it refers just to SIIT.
As we know, CLAT is a combination of NAT46 + SIIT because it's an stateless translation from IPv4 to IPv6.
 
> (specifically) it is implemented is mostly irrelevant in the context of
Yes, I don't know, it could be, as I put above maybe in the introduction we talk about many specific things and we could talk more about the problem itself.

> worth mentioning/describing/discussing?
I'm sorry I didn't understand it very well.
What *private space* are you talking about? IPv4 or IPv6?
If you are talking about IPv6, CDNs normally have IPv6 GUA.
If you are talking about customers with private IPv4 reaching public IPv4 destination CDNs, yes we could explain it because it is the main scenario we actually some content providers offers to ISPs to deliver content from public IPv4 of CDN to customers with private IPv4 avoiding a CGN platform. That was the first reason to create this document.

>   one), despite they aren't actually connected to IPv4.
It's an idea, we offer different ideas (approaches) to try optimize the traffic flow.
Here, the idea is that if the destination is IPv6-only, when we have an IPv4-only device, in a normal case you could never reach the destination but if you have this optimization your Proxy DNS could detect that it doesn't have an A record but it has an AAAA record, so you could be connected to the IPv6 destination. Without this, your IPv4-only device would not be able to get the IPv6-only content.

> user doesn't care about IPv6, and may not even be aware of what it is".
Ok, it could be, but remember it is another proposal like the other approaches and the idea is to get these kind of inputs.

> Approach #2 seems rather complex, with the consequent opportunities to
Approach #1 is not easy to be implemented because content providers doesn't want to be envolved on this process despite agreeing it can be an improvement , so the don't want to do any change in configuration of their devices / interfaces. It applies more in case where CDN is controlled by ISP (own CDN), but we want to define a general solution, we need to consider the normal case of public / external CDNs.
Approach #3, as you say, it is when ISP doesn't have control of the CDN. This is could not be a very scalable solution because it's not dynamic and any change needs to be propagated to all CPEs. On the other hand it's a very easy method to make a fast deploy where there are not often changes. I think this is a way where that allow to the operator to deploy the solution quickly without depending on complex mechanisms and where content provider doesn't change DNS records, this is the case of Netflix CDN where A and AAAA records always have the same IPs associated for the same FQDN (for CDN).
Approach #2, yes, clearly it is more complex but it will depends on how much complexity we want to give to the process and we need to define very well which cases we want to consider.

> in 464xlat, when it relies on SIIT, and for SIIT the requirement is a
Yes, what you say is valid, these are questions to see exactly what the community thinks.

---

From: Fernando Frediani <[email-masked]>
Date: Sun, 5 Jan 2020 13:29:39 -0300

> Yes, from one point of view it is correct what you said and in addition to that we have an unnecessary second translation (NAT64) when customer traffic was translated to IPv6 (NAT46) and the destin…

This is the biggest thing of this proposal, eliminate any unnecessary 
double translation where it's not needed and 'convert' any traffic that 
would originally happen in IPv4 (due to legacy devices behind the CPE) 
into IPv6 to external world. This has as result a even smaller need of 
IPv4 addresses in the PLAT to communicate to these destinations which 
have IPv6 support. 464XLAT is already great in saving IPv4 addresses and 
with this proposal it helps to reduce even more the dependency of IPv4 
regardless the devices the user has at home.

This is also an advantage over CGNAT + IPv6 scenarios where this IPv4 
traffic originated from these legacy devices can't bypass the CGNAT 
device. So in this case it translates into even higher savings as it 
means even less traffic passing through the PLAT device.

Regards
Fernando

---

From: Erik Nygren <[email-masked]>
Date: Thu, 9 Jan 2020 15:06:19 -0500

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

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.

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

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

        Erik

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Jan 2020 23:38:25 +0100

Hi Erik,

El 9/1/20 21:07, "v6ops en nombre de Erik Nygren" <[email-masked] en nombre de [email-masked]> 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

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 

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=[email-masked]..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

_______________________________________________ v6ops mailing list [email-masked] 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.

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Jan 2020 11:22:13 -0800

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

Is it fair to assume that Alejandro, your co-author, has tested a prototype in his network?

---

From: Alejandro D'Egidio <[email-masked]>
Date: Wed, 22 Jan 2020 19:32:08 -0300 (ART)

Hello Fred,
I hope you are well.
I'm sorry for the delay, I was on vacations.

I'm working with our cablemodem vendor in a prototype but as this is a very new feature and we are both working in many other projects.
Despite that, I've receive test version.
For the moment I'm not able to have the traffic "optimized" but if I send a A query from PC the proxy DNS on CPE sends both A and AAAA query.

Regards,
Alejandro

---

From: Fred Baker <[email-masked]>
Date: Tue, 28 Jan 2020 09:35:31 -0800

Thanks. I'm asking what I hope is the obvious "so what" question. Do we have a prototype (it sounds like the answer is "almost"), and do we find the recommendation to make a valuable improvement in the real world?

> On Jan 22, 2020, at 2:32 PM, Alejandro D'Egidio <[email-masked]> wrote:
> 
> Hello Fred,
> I hope you are well.