There's not much harm in trying the A address as you suggest in #2, though it will take at least a round trip, so you might want to start another connection for any new requests.
In an ideal world, that would typically work. In reality, I think a deployment would need QUIC-LB or some equivalent to ensure packets made it back to the correct server. On Mon, Jul 6, 2026 at 10:49 PM Lucas Pardue <[email protected]> wrote: > 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 <stefanoduo= > [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 > > > >
