tfpauly / draft-happy-eyeballs-v3 Goto Github PK

This is an open question I do not have an answer for yet - I guess the arguments can be made for both approaches..

So if an IPv6-mostly network provides DNS64, then a dual-stack host talking to an IPv4-only destination would have a choice between:

• a synthesized IPv6 address which will be routed via NAT64
• a native IPv4 path

(we have a similar discussion in https://datatracker.ietf.org/doc/draft-link-v6ops-claton/: shall CLAT be enabled if both PLAT and IPv4 are available?)

Similarly to #6, need a discussion on using A/AAAA without waiting for HTTPS when the HTTPS record could have forced upgrade to https://. Clients need to be aware of the potential tradeoffs of that functionality potentially getting skipped.

Should the first SYN retransmission and next connection attempt happen at the same time?
i.e. If we attempt to connect to address A, should retransmitting to address A happen at the same time as attempting to connect to address B (the next address in the list)?

If we have packet loss in the network, that would probably exacerbate the problem. Maybe we should use packet pacing or some kind of delay between them?

This was dismissed on #18 but today I just found it in RFC6052. (I didn't notice this until now since i was only reading RFC7050 and RFC6146)

[3.1](https://datatracker.ietf.org/doc/html/rfc6052#section-3.1).  Restrictions on the Use of the Well-Known Prefix

   The Well-Known Prefix MUST NOT be used to represent non-global IPv4
   addresses, such as those defined in [[RFC1918](https://datatracker.ietf.org/doc/html/rfc1918)] or listed in Section 3
   of [RFC5735].  Address translators MUST NOT translate packets in
   which an address is composed of the Well-Known Prefix and a non-
   global IPv4 address; they MUST drop these packets.

If you think this part is not necessary because it is already documented here I understand, but I think it is very informational if it is in this document. (As I did not know this was a MUST NOT until today)

https://twitter.com/flano_yuki/status/1717731672815485016 made me think about the sorted ordering in Section 5 again and realized we should probably have a TCP IPv4 endpoint towards the beginning as well, just in case QUIC and IPv6 are both broken, however unlikely it may be. This is so that just in case both the protocol and address family are in fact impaired, the client doesn't have to wait a long time before it gets a good/working endpoint.

We should add text about the sorting algorithm incorporating SVCB/HTTPS RR.

One option (that an existing implementation has already been using) is to prefer addresses received in hints or resolved via service names on SVCB/HTTPS records over direct A and AAAA responses, and sort the SVCB/HTTPS derived addresses based on their priority.

Is this some we will publish as rfc? or is this something that we will record somewhere in the wg wiki?

rt

The Acknowledgements section is currently copy-pasted from HEv2

Something that I think deserves a bit more discussion in the draft...

When HTTPS with IPv6 hints is received before A/AAAA, the draft specifies to start connection attempts based on those hints. Absolutely the correct thing to do.

But I don't see any real discussion of what to do when A/AAAA is subsequently received with different addresses before connection succeeds, especially for the case where the hint addresses are not present. Because A/AAAA addresses are generally better than hint addresses (because it's easier for the server to provide optimized or load-balanced addresses), I believe the best behavior would be to remove hint-only addresses from the connection list, similar to other removals discussed in Section 7 ("DNS Answer Changes During Happy Eyeballs Connection Setup"). Removing the addresses in this case would also be most consistent with the RFC9460#7.3 "SHOULD" to ignore hints if A/AAAA are locally available.

Our implementation currently does:

• Have the 50ms default "Resolution Delay” timer apply to waiting for both AAAA and HTTPS/SVCB

The draft says:

For example, if the first address in the sorted list is a QUIC IPv6 address, then the first TCP IPv6 address should be moved up in the list to be second in the list, then the first QUIC IPv4 address should be moved up to be third in the list,

1. Why is TCP IPv6 preferred over QUIC IPv4? Does this also mean that the dial delay to misconfigured IPv6 servers with a fixed delay is 500ms now?

2. What happens when there's only a QUIC IPv4 and TCP IPv6 address. I assume the preference is QUIC IPv4 over TCP IPv6, as the draft says. I understand, this ia a highly unusual situation.

The client SHOULD also sort the addresses in protocol order, such that QUIC is prioritized over TCP, as it connects faster and generally results in a better experience once connected.

(copying from an email I sent to the authors)

With PREF64 being available, some networks might only provide PREF64 and do not use DNS64, as the latter has a number of disadvantages, such as breaking DNSSEC and not working if the host has custom DNS
servers configured.

So do you think it's worth adding some text saying that some Ipv6-only
or, more likely, IPv6-mostly networks might only deploy PREF64 w/o DNS64?

See https://www.ietf.org/archive/id/draft-link-v6ops-6mops-00.html#name-dns-vs-dns64

"prioirity" → "priority"

"Servicemode" → "ServiceMode"

"The priority in a SVCB RR is always greater than 0" → "The priority in a ServiceMode SVCB RR is always greater than 0"

Should synthesis be done to all address spaces?

If client applications or users wish to connect to IPv4 address
literals, the Happy Eyeballs engine will need to perform NAT64
address synthesis for them.

I wonder if this has been discussed for RFC7050 but should this algorithm
be applied to 127.0.0.0/8 and RFC1918 address space? Maybe we should
discuss if these address spaces should NOT be translated.

For the loopback address range (127.0.0.0/8), it should not be translated
as the client in question should have a route to the loopback network
resulting in the synthesis not being needed.

For addresses within the RFC1918 space, the translated address could be
misrouted to an unintended host, diverging from the user's original
intention. Nonetheless, it is worth noting that nothing stops the inclusion
of RFC1918 addresses in DNS records. As a result, translated IPv6 addresses
originating from RFC1918 space can still be acquired via DNS64. Given this,
it may be counterintuitive to impose restrictions on such addresses in the
Happy Eyeballs algorithm.

8.1. IPv4 Address Literals
Such translation also applies to any IPv4 address hints received in SVCB RRs.
The mention of SVCB RRs makes this section a lot more meaningful as IP address literals may not have been so common but with SVCB RRS they will be common even in a client/server scenario.

The other case that is common is when you’re using encrypted DNS (DoT/DoH/etc) and asking for both address families. That’s common to then get v4 answers that need to be translated.

From reply from Tommy.
https://mailarchive.ietf.org/arch/msg/v6ops/2csKJzBti4Mmb5vdWXp4-kzPd1k/

So maybe

- Such translation also applies to any IPv4 address hints received in SVCB RRs.
+ Such translation also applies to any IPv4 address hints received in SVCB RRs or when using encrypted DNS (DoT/DoH/etc).

Section 4:

If the client did request SVCB RRs:

• If the client receives any positive response back (containing a valid AAAA, A, or SVCB ServiceMode RR), it starts the Resolution Delay timer, which is run until both the AAAA and SVCB ServiceMode responses are received, or a SVCB response is received that also includes at least one address in the ipv6hint parameter. Once both records are received, or the timer expires, the client proceeds with the process of sorting addresses and staggered connection attempts.

"Once both records are received" seems to be referring to receiving both AAAA and SVCB ServiceMode RR's, but this is in tension with the previous sentence which allows proceeding without receiving the AAAA response yet if a SVCB has been received that contains at least one IPv6 address hint.

Suggested replacement text:

If the client did request SVCB RRs:

• If the client receives any positive response back (containing a valid AAAA, A, or SVCB ServiceMode RR), it starts the Resolution Delay timer, which is run until both the AAAA and SVCB ServiceMode responses are received, or a SVCB response is received that also includes at least one address in the ipv6hint parameter. Once at least one IPv6 address has been received, or the timer expires, the client proceeds with the process of sorting addresses and staggered connection attempts.

We should have one line recording the impact on current deployment. why does it matter??

From discussion

the device queries the network for the NAT64 prefix using
"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"
[RFC7050] and then
Regarding the use of RFC7050 for obtaining the NAT64 prefix, RA Option 38 (as specified in RFC8781) could also serve this purpose. However, given that this section is geared towards platforms not supporting 464XLAT, I assume doing rfc7050 is simpler than getting an RA message for an application so the omission of RFC8781 seems justified.

I think it would be fine to mention to RFC8781. Perhaps you could file an issue on GitHub for that?
https://mailarchive.ietf.org/arch/msg/v6ops/2csKJzBti4Mmb5vdWXp4-kzPd1k/

   When an IPv4 address is passed into the library instead of a
   hostname, the device queries the network for the NAT64 prefix using
   "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"
- [RFC7050] 
+ [RFC7050] or PREF64 Router Advertisement option [RFC8781],
   and then synthesizes an appropriate IPv6 address (or
   several) using the encoding described in "IPv6 Addressing of IPv4/
   IPv6 Translators" [RFC6052].  The synthesized addresses are then
   inserted into the list of addresses as if they were results from DNS
   queries; connection attempts follow the algorithm described above
   (see Section 6).

In the context of this draft "AAAA response" seems it could be interpreted as just the DNS response to the AAAA query. But for most of the usage/discussion, I think we want AAAA records received in response to the AAAA query or AAAA records received in the Additional section of the response to the HTTPS query, whichever is received first.

Maybe we should rephrase all those references to "received AAAA records" or something like that. Maybe we even need an explicit mention that those records could come in the response to the HTTPS query and that clients should use those if received first instead of waiting for a response to the AAAA query.

See: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-update/

In section 8.1 I think instead of "When an IPv4 address is passed into the library instead of a
hostname, the device queries the network for the NAT64 prefix using
"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"
[RFC7050], or uses PREF64s received from Router Advertisements
[RFC8781]."

the text should say:

"When an IPv4 address is passed into the library instead of a
hostname, the device SHOULD use PREF64s received from Router
Advertisements [RFC8781], or, the network does not provide PREF64, the
host SHOULD queries the network for the NAT64 prefix using "Discovery
of the IPv6 Prefix Used for IPv6 Address Synthesis" [RFC7050]"

The reason is that PREF64 shall be preferred over RFC7050.

Current doc just talks about TCP — we should add QUIC considerations in specifically

Explain what v3 is focused on, and intro SVCB and how it impacts happy eyeballs.

ECH use can make the client be SVCB-reliant instead of SVCB-optional. At the very least, the algorithm will be impacted by being SVCB-reliant.

My initial proposal here is:

• Request HTTPS records for any case where the port is 443 or 80, or the URL has a scheme of http:// or https://
• Request the HTTPS record in parallel with A and AAAA

SVCB contains ALPN information, which can change what protocols can be attempted (learning that H3/QUIC is supported, for example). We should consider how much of this to discuss in happy eyeballs.