Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.1 Detection of IPv4-only hosts or applications

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 17 Jul 2020 14:14:04 +0200

I’m thinking something else that may be very useful if we include in the EAMT entry a field for the source host that is using it, we may want to create also another table (better than using the same table because we don’t need the other fields, so less memory is used) for those hosts that are detected to be dual-stack. This will avoid delaying the AAAA query from the A one (it will happen only if the table is empty).

So, once a dual-stack host is detected, it will never get EAMT entries, and HE is never broken. If this host suddenly becomes IPv4-only (corner case), then nothing from that hosts will be optimized (except if we decide to add an expiry time to the table of “detected-dual-stack hosts” or the CE is rebooted). For example, if you disable IPv6 in the browser, it will still use 464XLAT as we do it today, no optimization, etc.

A dual-stack host may be “wrongly” classified, in corner cases, as IPv4-only if a given app is using only IPv4 and doing only A queries and that will be optimized. However, this will be re-checked when the same host tries to initiate a new connection to a new destination.

The disadvantage is that then we don’t optimize any application from that host, but I think this is a good thing as a conservative approach, it resolves some of the other issues and even keeps allowing troubleshooting with IPv4 and IPv6, using literal IPv4 addresses, etc., etc.

So only IPv4-only hosts will need to wait the Resolution Delay for every new destination, to make sure if the destination is IPv6-enabled to create the EAMT entry. In the case of the hosts that we are trying to optimize (a SmartTV or STB), I don’t think it is a big issue, because usually is running a single “app”, so the delays introduced should not have a user-noticeable impact.

At the end the main goal of the optimization was to resolve the access from *IPv4-only* devices such as old smartTVs/STBs, so I feel that disallowing at all dual-stack hosts to take advantage of the optimization is a very good trade-off.

Thoughs?

El 17/7/20 12:16, "v6ops en nombre de JORDI PALET MARTINEZ" <[email-masked] en nombre de jordi.palet=[email-masked]> escribió:

> 5.2.1 Detection of IPv4-only hosts or applications
> It needs to be remarked that, if the detection of the IPv4-only
> device or application is done incorrectly (either not detecting it
> or by a false detection), no harm is caused.

I'm not sure that "no harm is caused" is always the case.
There may be harm due to cases such as a client no longer
able to fall back to the IPv4 address it would have used
in a Happy Eyeballs setup.  (ie, connectivity is discussed extensively
here, but application-level breakage due to some of the issues
mentioned above may not be possible to recover from).

[Jordi] Maybe is a matter of an alternative wording: “the goal is that no harm is caused”.

Regarding HE, I think this is well explained in the updated 5.2..12. section.

One possible alternative if we want to keep HE working *at all means*, even if it is worse than the optimization (which is very possible, because we are talking about IPv6-only access, so most probably if IPv6 is broken, IPv4 is broken as well), will be to add one more field in the EAMT entry: The IPv4 source address from the hosts in that network. Then we can ensure that the EAMT entries are “per client” and applied only to each client and only to IPv4-only clients. So dual-stack clients will NOT use the optimization (in normal conditions they should prefer IPv6!). This small change in the approach makes the optimization implementation a bit more complex, but being done by the CPE, still is preferable to the NAT64 unnecessary overload. I think that this may also *resolve* many of the other issues that I’m still reading from the list and even some security issues.

=========

> 5.2.1  Detection of IPv4-only hosts or applications

Will Android doing synchronous A/AAAA lookups break this
detection?  and does this impact other things like STBs built on
Android?  Android does one of the A or AAAA lookups, waits for it
to return, then does the other.  From the perspective of the CPE resolver,
could look like an IPv4-only host and just always introduce the 50ms delay?

Some more details may be needed here on the timing heuristics needed
to detect various scenarios like this.

[Jordi] When a synchronous lookup is performed, then it is clear that the hosts is IPv6 enabled (actually dual-stack), so the EAMT entry is not created. If the EAMT entry already exists, then it will be used only if the host decides to prefer IPv4 instead of IPv6, which doesn’t look like a normal behavior. To ensure it, we may need to double-check if the 50 ms. delay is still good for Android or it is too small. I don’t think it is a big issue to increase it. We could improve it, to avoid the delay, if we create an additional table for the “already known” to be dual-stack hosts. This may be also related to the new field in the EAMT that I mention above.

**********************************************
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 [email-masked] 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.