[IPv6]Re: Happy Eyeballs, synthesized AAAA and IPv6-only/dual-stack nodes.

[Ondřej Caletka <[e-mail]>]

Hello Philipp!

On 17/11/2025 11:37, Philipp Tiesel wrote:
> For the sake of simplicity and reducing state explosion, I would really love to remove CLAT from any Happy Eyeballs discussion and, thus, change the perspective:
Good idea! Or at last this CLAT discussion could be postponed after we 
know what to do without considering CLAT.
> Assuming we treat it as Native IPv6, we may end up with more IPv4 than necessary and load the NAT64.
>
> Assuming we treat it as Native IPv4, we make sure native IPv6 is preferred. We may get some extra latency in CLAT, but that may be acceptable.
This is my preferred variant, treat synthesised IPv6 addresses the same 
way like native IPv4 addresses.
> Assuming we treat it as its own class, we can sort it between IPv6 and IPv4 and, thus, prefer NAT64 over “believed to be native IPv4”.
> This would also move the traffic away from CLAT and CGNAT towards IPv6 and know NAT64.
> -> I tend to prefer this.
I fail to see what advantage this would bring. I am still not convinced 
that talking to IPv4 hosts over NAT64 is better or worse than talking to 
them via (optional) NAT44. So what exactly would this extra category help?
> Finally, we should think about how we may end up with NAT64 AAAAs:
The Happy Eyeballs algorithm _has to know_ the NAT64 prefix anyway for 
treating the IPv4 literals or dual-stack servers with broken IPv6 
connnectivity.
> - Got them from DNS64 (perhaps with some heuristics how to identify non-well-known prefixes)
Of course with RFC 7050 heuristics - no implementation should ever just 
assume the WKP or treat the WKP better than any other NAT64 prefix. 
Using RFC 7050 is probably still necessary because due to the fact that 
support for PREF64 RA option requires firmware update of all routers, 
this will take decennia to get universal support.
> - Synthesized them ourselves based on PREF64
Again, this has to happen in order to support IPv4 literals or 
dual-stack servers with broken IPv6 connectivity.
> Both is much easier to classify than any try to detect/undo CLAT.
I don't get this. This was never about detecting and undoing CLAT, it 
was always about detecting and undoing DNS64, because the consensus is 
that DNS64 should not be necessary, so IPv6-only networks with NAT64 
should work well with just PREF64 signalled in the RA. In this 
situation, the Happy Eyeballs can never rely on DNS64 to be present, so 
the algorithm needs to work well without it. So in case it turns out 
DNS64 is actually present, I believe that undoing it is the best thing 
to do.


--
Best regards,

Ondřej Caletka

>
> I would really try to avoid more complexity than this…
>
> AVE!
>      Philipp
>   
>
>> On 14. Nov 2025, at 18:51, Jen Linkova <[e-mail]> wrote:
>>
>> During the IETF124 week, both HAPPY and 6MAN discussed how HE should
>> behave on an IPv6-only host, or when a synthesized AAAA is available
>> but the host has both IPv6 and IPv4 addresses.
>>
>> There is https://github.com/ietf-wg-happy/draft-happy-eyeballs-v3/pull/94
>> but I'm not sure I agree with what's proposed here, and I'd like to
>> continue the discussion on the list.
>>
>> As I've mentioned already, it might be useful to define the desired
>> behaviour first:
>>
>> 1. define how an HE implementation behaves in different scenarios when
>> the NAT64 is present. More specifically - does it prefer IPv4 or IPv6
>> to IPv4-only destinations.
>> 2. if that behaviour is not consistent with what RFC6724 (-bis)
>> defines, craft some modifications to RFC6724(-bis).
>>
>> So, to address #1, I've tried to summarize the options available in
>> the following scenario: the host discovers the NAT64 prefix (so the
>> network provides the NAT64 service) and a synthesised AAAA was
>> received.
>>
>> (There is an assumption that the implementation can differentiate
>> between CLAT and non-CLAT IPv4 addresses. IMHO it's a fair assumption
>> if the CLAT is using 192.0.0.0/28 - as it SHOULD as per
>> https://www.ietf.org/archive/id/draft-ietf-v6ops-claton-12.html.
>> If a CLAT implementation decides to use smth else...well, I'd call it
>> a corner case, don't do it unless you have a very good reason - so we
>> can ignore it for the purpose of this discussion)
>>
>> The table attached describes 3 things:
>> 1. The protocol the host should be using (ideally).
>> 2. How to process the received AAAA RRs
>> 3. How to process the received A RRs or IPv4 literals.
>>
>> Most cases are straightforward (at least I think so - I might be wrong
>> indeed) - feedback welcome.
>>
>> The scenario I'd like to discuss: the host has both IPv6 and non-CLAT
>> IPv4 addresses and the received AAAA is synthesized. Example: a
>> dual-stack host on a network with DNS64. The host has two options:
>>
>> 1. Prefer native IPv4 and fall back to IPv6 (via NAT64).
>> 2. Prefer IPv6 via NAT64 and fall back to native IPv4.
>>
>> IMHO Option 1 is better for the following reason: it would solve some
>> of VPN cases - I believe that's what
>> https://github.com/ietf-wg-happy/draft-happy-eyeballs-v3/pull/94 is
>> trying to solve by 'look at the routing table first before
>> synthesiing'.
>>
>> Does it make sense?
>>
>> P.S. I'm only considering the case of synthesized AAAA: if the host
>> also gets a "native" (non-synthesized) AAAA record, that AAAA it will
>> be preferred over synthesized one, if the network is using the
>> well-known prefix ( as Section 5.3 of the draft requires the addresses
>> to be sorted as per RFC6724 Section 6).
>> ....which gives yet another reason why the well-known prefix is a
>> better default choice than a network-specific one...but it's for
>> another v6ops discussion..;)
>>
>> --
>> Cheers, Jen Linkova
>> <HE AddSelect.png>--------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
>> --------------------------------------------------------------------