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: 1. Provided in the preferred_address extension, during the initial TLS handshake 2. 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
