Subject: [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 12:15:16 +0200

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

---

From: Erik Nygren <[email-masked]>
Date: Sat, 18 Jul 2020 11:10:09 -0400

On Fri, Jul 17, 2020 at 6:16 AM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

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

Will *all* A lookups invalidate EAMT entries?  If they don't, IPv4-only
hosts can break dual-stack hosts.

Also on "only if the host decides to prefer IPv4 instead of IPv6, which
doesn’t look like a normal behavior"
a reminder that this is a normal behavior for many clients.  For example, a
large portion of deployed
AppleTVs will always do A and AAAA lookups but will randomly pick between
IPv4 and IPv6 to use.
(ie, they are based on an older iOS that doesn't give a bias towards IPv6
so ~half of their traffic is IPv4.)

An important principle here may be that whatever we do here needs to work
for all clients,
not just a subset of clients following an assumption of what "well behaved"
is.
While I started out overly optimistic, I'm starting to fear that this may
not be tractable
without a level of complexity and risk which may not be worth the effort.
(I have a bunch of ideas for additional hacks that might help, but they just
make things more fragile in different ways.)

      Erik

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 19 Jul 2020 22:57:59 +0200

With the new detection and the per-host entries, we never optimize dual-stack hosts, neither re-use entries from other hosts, so one less issue …

El 18/7/20 17:11, "v6ops en nombre de Erik Nygren" <[email-masked] en nombre de [email-masked]> escribió:

Will *all* A lookups invalidate EAMT entries?  If they don't, IPv4-only hosts can break dual-stack hosts.

Also on "only if the host decides to prefer IPv4 instead of IPv6, which doesn’t look like a normal behavior"

a reminder that this is a normal behavior for many clients.  For example, a large portion of deployed

AppleTVs will always do A and AAAA lookups but will randomly pick between IPv4 and IPv6 to use.

(ie, they are based on an older iOS that doesn't give a bias towards IPv6 so ~half of their traffic is IPv4.)

An important principle here may be that whatever we do here needs to work for all clients,

not just a subset of clients following an assumption of what "well behaved" is.

While I started out overly optimistic, I'm starting to fear that this may not be tractable 

      Erik

 

 

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops