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

[Martin Hunek <[e-mail]>]

Hi Jordi,

Thanks for responding with this new version and sorry for added complexity. :-)

This 03 version solves an issue I had been pointing out. I think it made it potentially more reliable by introducing automated way for detection colliding EAMT entries. In my opinion it minimizes possibilities how it could have caused problems not just to CDN/cache providers - it has been focused on, but also to other services on the Internet. So I would like to voice my support for this draft in this version.

I'm just not entirely sure about that "universal web page" from section 5. One issue with that was already mentioned by Fred - the DNSSEC incompatibility. I would have one more, that it would be quite easy to filter out responses with this universal page (and also that it would work only for web, by the way). I can imagine that network operator or service operator, which is not doing IPv6 properly, would not like their customers ever to see such web page. So naturally they would make sure that it would never get displayed.

This "universal web page" is a cool looking concept, but I'm not sure it is worth the effort.

Best Regards,
Martin

Dne pondělí 8. července 2019 23:43:09 CEST, JORDI PALET MARTINEZ napsal(a):
> 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.
>