[v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns

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

Hi Erik,

 

I think it will be good to respond in different threads to simplify the discussion and try to find appropriate text for each of the issues that you mention.

This one is on your general concerns, below in-line.

If any of the general concerns is further discussed in the rest of your email, I will try to tackle it also in the follow-up emails, so we can concentrate in every possible issue in the specific email to avoid multiple parallel threads on the same issue.

Tks a lot!

 

El 15/7/20 7:54, "v6ops en nombre de Erik Nygren" <[e-mail] en nombre de [e-mail]> escribió:

 

On Thu, Jul 9, 2020 at 11:58 PM Jen Linkova <[e-mail]> wrote:

OK, I"ve read the document and before I finish the write up I'd like
to discuss a number of comments I have.
My apologies for not raising them during the WGLC - I was not paying
attention, got busy with work...


Prodded by Jen's response here I also re-read draft-ietf-v6ops-464xlat-optimization-02.
(My apologies also for not raising these during WGLC -- similar excuses to Jen...  ;-)

While this continues to close corner-cases, I'm still concerned
that there is significant possibility for breakage in a way that
will result in content that is now dual-stacked getting switched
to be IPv4-only.

It would be good to add some examples as to why
some of the invalidation logic needs to actually work
(and the risk of corner cases where it doesn't).
To that end, it may make sense to also have some more
use of normative rfc2119 language for clearly spelling out behaviors
where there are sharp edges.


[Jordi] Often when an informational document goes to the IESG they complain about the use of normative language. One open question is, if we advance RFC6877 to standards then, we could consider that this optimization should be also in the standards track. Anyway, at the time being I will keep it as informational, but I will add normative language to make everything very clear and more examples as needed in every section.


Some example cases of breakage or significant risk of breakage:
* A site is IPv4-only (breaks for or denies all IPv6 users) but shares an A record with a dual-stack site.  If this isn't detected properly, it will break users who get sent over IPv6 to the IPv4-only site.

 

[Jordi] My goal has been to ensure that the optimization doesn’t break any case, and especially when the site only offers A records. Unless I’m missing something, I think this is perfectly resolved in 5.2.2, because the EAMT entry will be only created if the site is only IPv4-only.


* some CDNs use TLS SNI for demuxing IPv4 traffic but the IPv6 address for demuxing IPv6 traffic (both to determine which cert to serve).  This means that the IPv4:IPv6 associations are one to many and using the wrong one will result in cert errors.

 

[Jordi] This was discussed in a previous version (I recall it was after the presentation in Prague) and resolved by incorporating the FQDN in the EAMT entry and a section 5.2.4, which forces the forwarding path via a stateful NAT44.


* Some CDNs may use cluster A for IPv4 and cluster B for IPv6 for one customer/tenant, but then cluster A for IPv4 and cluster C for a different customer/tenant.  An stale or invalid association will result in going to the wrong cluster which may not be able to serve the request properly.


[Jordi] Same as the previous one. Because the EAMT entry is created by every CE, the association between a given IPv4 and IPv6 FQDN/addresses is done the same way as if the same CE is actually dual-stack instead of IPv6-only. If I got it correctly, in a CDN, any change in terms of what cluster is serving what, depends on DNS TTLs and maybe routing, right? If that’s the case, routing is transparent because the entries are created in each CE, and to the CDN they appear as a dual-stack eyeball. Similarly, we rely in the CDN provided TTLs.

 

** if the user changes DNSs, unexpected consequences may happen, but there is no difference vs the case when there is no optimization. Any change in the DNSs done by users, may break thinks (for example, CDN contents are server from another cluster). Nevertheless, usually users change DNS in end-hosts (Windows, Linux, MacOS, etc.), it is not so common to change those in the CE. Is even less common to change them in the smartTV or STB, because in many cases they don’t allow it. This is described in 5.2.10. If needed I can improve that section.


While the recent revisions help some, there are still a bunch of cases
where things could still break.  I fear that when they do break it's
not something that content providers or CDNs or their customers will
debug and the result will be for content to get switched back
to IPv4-only (which is not what we want happening, but will
appear to "fix" issues here).


[Jordi] Fully agree here, we need to make sure that we don’t break anything.


I think there may also be some significant security issues not called out
that are independent of the DNS spoofing issue.


[Jordi] I will move this to independent threads.


Another area not discussed is clients caching DNS lookups well past
their TTL.  This is fairly common in some clients (eg, some Java versions)
which could result in entries getting expired from the EAMT but then used
with a new association that should be invalid but wasn't detected as such
as the first client is caching well past the expiry..


[Jordi] I’m confused here.

 

You mean a client ignoring DNS TTLs ? This could actually be a problem without the optimization. If the CDN is changing the IPv4 or IPv6 addresses, but the client is still using them, the content will be unreachable or something different served, right? So, the optimization is not the problem here it is a broken client already …

 

Note that if the EAMT expired and the client tries to use it again, the EAMT entry will be re-created with the new (correct) information from the CDN DNSs, so we may be potentially solving the broken client problem. If the EAMT, for whatever reason is not recreated, the optimization will not be used, so the client will be still doing the “correct” thing according to its expected behavior (non-optimized NAT46+NAT64) – whether it is a broken behavior or not.

 

 



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