Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.3 > 4. TTL

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

> 5.2.3
> 4. TTL
>    "In normal conditions the TTL for both A
>       and AAAA records, of a given FQDN, should be the same, so this
>       ensures a proper behavior if there is any DNS mismatch."

Actually if the resolver is a forwarding resolver talking
to the ISP's recursive resolver then it is likely the TTLs
returned will have degraded some and will be different.
For example, if a CDN is using a 60s TTL then it is likely
that the A RRset could have 12s remaining while the AAAA RRset
has 48s remaining.

Using the minimum of the two TTLs is likely better than assuming they will match.

[Jordi] Yep, you’re right. In an optimal situation they should match, but using the minimum of the could resolve some inconsistences even if this just means that the EAMT expires and then a new one needs to be created.

It may make sense to keep track of EAMT records somewhat past their
TTL to handle clients caching things longer as well as race conditions.
For example, add a "stale" state which can convert to "invalid" but won't
get used for new connections and which entries stay in for some amount
of time past expiry.

[Jordi] Yes, again you’re right. It can help to avoid extreme cases even for broken clients.

Nit: Is this really an "expiry time" rather than a "TTL"?
While mentioned later, it would be good to emphasize
that invalidating or expiring EAMT entries MUST NOT
break existing connections.  (ie, that the 5.2.4 behavior
is absolutely required.)  Implementations getting this wrong
would be really bad in-terms of breaking dual-stack content
while IPv4-only content would keep working (ie, due to
the lack of associations).   Hurting reliability for dualstack
content relative to IPv4-only content would be bad.

[Jordi] I will reword expire time/TTLs to make it clear. On the other point, I’ve provided earlier today a tentative text for 5.2.4 using normative language in response to one of the Eduard inputs. Let me know if you think that’s sufficient.

Also not covered here is clients caching A/IPv4 lookups for extended time.
For example, the  EAMT entry may have expired but client may have A record
cached and then another mismatching EAMT entry might get created for a
different FQDN.

[Jordi] This is one of the points in a previous email. Is not that a broken client? Is not that a situation, that without the optimization already will mean the client may be getting a different response from the CDN or nothing at all?

Also, if we add the client source address as a field in the EAMT, this is also resolved, I think.

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