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

[Fernando Gont <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> 


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