Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches

[Fred Baker <[e-mail]>]

I’m reading through this draft, and feel some comments are in order on the issues marked “TBD”. In this case, I’m writing as an individual.

In the general problem and proposed solutions, I agree that the problem statement makes sense (it is comparable to the problem statement in SIIT-DC), and section 4.2 (also comparable to SIIT-DC) seems to present the solution with the least impact on the network and its surrounding devices.

A few thoughts:
>   The information in the EAMT MUST be kept timely-synchronized with the
>   AAAA records TTL's.  In order to achieve that, each EAMT entry MUST
>   update with each A query, the TTL of the relevant AAAA record.
>   Update of RFC7757 ? TBD.

I don’t view this as changing 6145/7915’s algorithm. I need to understand how this changes 7757 to agree that it updates it.

>   SIIT already has a SHOULD for EAM support.  TBD. 464XLAT may be
>   updated by this document so the CLAT has a MUST for EAM support.

THe fact that you want it for this use case doesn’t mean that it is required by all use cases. I’d want to hear that argument before agreeing to “MUST”.

And in any event, what is the argument for 2119 language in an informational document? This is beginning to sound more like a Proposed Standard...

>   TBD.  Should we recommend having A "null" records for IPv6-only
>   services in Internet?  A web page IPv4-only hosted by IETF(?) showing
>   "sorry this web page/service is only available from IPv6 enabled
>   operators"?

I’m very concerned about requiring something that is not going to be DNSSEC-compatible, which it seems such a “null” record has to be. I’m also concerned about something that forces a change to DNS implementations, as a change to the interpretation of an A resource record seems likely to do. An A resource record advertises an IPv4 address that one can expect to work under some set of conditions, and a “null” record seems to advertise an address whose set of conditions for validity would be null. So this is something I would be concerned to find, and would expect to require dnsop support for before I was willing to accept it.

>   TBD.  Other risks to consider ? If a CE is misconfigured, even a
>   small percentage of broken CEs may bring the content providers to
>   switch back to IPv4-only.  So possible failure cases need to be
>   carefully considered for every possible solution approach.
> 
>   TBD.  Should a way to manually exclude EAMT entries be considered?
>   May be a manual config in the CPE and by means of operator config.
>   This is way-out to ensure nothing is broken by surprise and is not
>   solvable.

I’m not an operator. I would expect any operator reading this to say “heavens no, no manual or specific configurations. Make this just fall out of normal operations.” 

Operators, please feel free to agree or disagree, and say why.

>   This document does not have any new specific security considerations.

The question about “broken CEs” seems to point to a security consideration. In what way might they be misconfigured, and what would the effect be?