Hi On Tue, Jul 7, 2026, at 03:25, Dan Wing wrote: > 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? You might also be interested in Marco and Marten's draft https://datatracker.ietf.org/doc/draft-munizaga-quic-alternative-server-address/
> > > > Thank you, > > Stefano > >
