Re: QUIC connection migration to an IPv4-only network when connected to a server's IPv6 address

[Christian Huitema]

I would use "preferred address" to pass the IP addresses and port 
specific to the selected server. Otherwise, either pass these addresses 
via the application, or negotiate one of the extensions that pass the 
server addresses after connection establishment. In both cases, the 
server needs to cooperate.

I implemented that in picoquic by having each server in a pool listen to 
both the "shared" socket (e.g., port 443) and a server specific socket 
(random port number). That's only exposed via the preferred address 
extension so far, but it could be used in conjunction with multipath as 
well.

-- Christian Huitema

On 7/9/2026 8:34 AM, Ian Swett wrote:
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 <lu...@lucaspardue.com> 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=
40google....@dmarc.ietf.org> 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