Looking at the spec and the Chrome code more closely, it appears that my recollection was wrong - Chrome only looks at the preferred address right after the handshake. Please ignore my previous concerns, I was wrong and the sentence I had pasted from draft-piraux-quic-additional-addresses is fine.
David On Tue, Oct 18, 2022 at 5:13 PM Martin Thomson <[email protected]> wrote: > On Tue, Oct 18, 2022, at 18:39, Maxime Piraux wrote: > > To me, when reading RFC9000, addresses provided in preferred_address are > > expected to be used shortly after the handshake. So a client that > > prefers one address family over the other can use its "best server > > preferred address" and migrate across address families indeed. > > So I guess the question can be framed differently: > > Why would a client choose to defer use of this transport parameter? And > how would the client decide that when the transport parameter should be > used? > > To your other points, the expectation is that a preferred address is acted > upon immediately after the connection is complete. If the following is > unclear, we can improve it if and when we revise RFC 9000, but I don't see > this as implying unlimited license to use the address: > > > QUIC allows servers to accept connections on one IP address and attempt > to transfer these connections to a more preferred address shortly after the > handshake. > -- https://quicwg.org/base-drafts/rfc9000.html#section-9.6-1 > >
