It seems this should mimic what we would do for TCP, and may well be purview of the Happy WG (https://datatracker.ietf.org/group/happy/about/).
I would lean heavily towards your solution (2), but using SVCB and HTTPS resource records (rather than solely AAAA), as those have more robust semantics. Somewhat related to your question, see also Erik's recent post about draft-nygren-dnsop-ipv6only-indicator sent to several working groups, https://mailarchive.ietf.org/arch/msg/v6ops/VaaERK1-riWFauEqbuoZzPZx_x4. -d > On Jul 6, 2026, at 6:23 AM, Stefano Duo > <[email protected]> wrote: > > Hi all, > > I'm trying to solve the following common scenario: a client has a QUIC > connection to a server's IPv6 address and has to migrate the connection to an > IPv4-only network. > > Currently, our implementation will attempt to connect to the server's IPv6 > address via the IPv4-only network and will (expectedly) fail. > > I can think of two main solutions, the client could instead migrate to the > IPv4: > • Provided in the preferred_address extension, during the initial TLS > handshake > • Returned by the A query, that was sent alongside the AAAA query that > contained the IPv6 address currently being used by the client > > From past discussions in the archive, I understand that preferred_address's > main intent is to support a one-time only, server-initiated migration for > anycast deployments that do not support connection ID-based routing. It's not > clear to me whether #1 would be an abuse of preferred_address. > > As per #2, there are no technical guarantees that the A result will lead us > to a machine that has the necessary state to migrate successfully. It is also > explicitly not covered by section 9 of RFC 9000. > > Has this scenario been discussed before? Is there any guidance on how to > handle this correctly? > > Thank you, > Stefano
