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

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Fred, all,

 

I just submitted a new version for this document.

 

https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?include_text=1

 

I’ve updated the issues from your inputs, as well as the issue that Martin raised. It has required a much complex approach than the one initially drafted when responding to him, but I think it resolves the problem.

 

Hopefully we can get inputs, specially from CDN/Cache providers, but also from hosting providers if they are using this reverse-proxy often …

 

Regards,

Jordi

@jordipalet

 

 

 

El 28/6/19 17:10, "v6ops en nombre de JORDI PALET MARTINEZ" <[e-mail] en nombre de jordi.palet=[e-mail]> escribió:

 

Hi Fred,

 

Thanks for your inputs.

 

Responses, below, in-line.

 

Regards,

Jordi

@jordipalet

 

 

 

El 28/6/19 15:55, "v6ops en nombre de Fred Baker" <[e-mail] en nombre de [e-mail]> escribió:

 

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.

 

Sometimes I use the TBD, not necessarily because that need to be completed, but to make sure that I double think on that for the next version.

 

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.

 

Section 6 of RFC7915 has a SHOULD for EAM. I think this is right, but I see that RFC6877 (464XLAT), should get it as a MUST.

 

Similarly, my question about RFC7757, is if it is useful that each entry in the EAMT also needs to have a TTL, or this is exclusive for our optimization case (this ID) ?

 

  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”.
 
I think it makes sense that 464XLAT is *always* optimized, so that’s why I think it requires to be updated by this document..
 
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...
 
Actually we have got this request already many times when having the IESG review. I’ve used RFC7084 “special” language in the recent RFC8585, and I was asked to just use the RFC2119 one.
 
However, I also believe that this document, if we agree that 464XLAT must be always optimized, then this ID is an opportunity for killing two birds with a stone:
1)  Updating RFC6877 to include the optimization always.
2)  It doesn’t make senses (we talked already some time ago about this), that MAP-E/T, DS-Lite and lw4o6 are standards, and 464XLAT which is the mechanism that have “more” users in the world (even compared to all the others together), is just informational. So this ID may be a proposed standard covering both aspects.
 
  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 

 

“null” maybe not the best wording here, so may not break DNSSEC. I mean using an IPv4 address that is not actually configured in the server that the has the AAAA. I think it makes sense that this address is a public one defined by the IETF, which we may use for a special page (or not use at all, but still a special one).

 

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 

 

Clearly, I confused using the “null” wording. Is a real address (so no change at all in DNS implementations), but this address is not actually configured in the interface of the server (because it is IPv6-only).

 

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

 

I think again is a matter of wording. Many CEs have lots of options that usually operators don’t use. But if they need to use they can configure them remotely, or because they get from the vendor a default “factory” config. However, in some cases, those configs are also managed by “expert” users (and today a gamer, just an example, is most of the time an expert user).

 

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?

 

Again, I need to change the wording here. The CE is not actually broken. The complete paragraph “TBD.  Other risks to consider ? …” was more a way to remind muself to work on that. The point is that if we have this optimization, we need to make sure to double-check with CDNs that it doesn’t create a trouble for them, because in those cases they see the “CE as broken for IPv6” and they prefer to disable IPv6 for the entire ISP that has the “broken CEs”.

 

Is that clearer now?

 

I will definitively improve the wording for the next version, so those points don’t create confusion.

 

 

_______________________________________________ v6ops mailing list [e-mail] 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.

_______________________________________________ v6ops mailing list [e-mail] 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.