Hi Maxime, There's a bit more history in the GitHub issue and PR that led to the addition of dual stacked preferred addresses: https://github.com/quicwg/base-drafts/issues/2122 https://github.com/quicwg/base-drafts/pull/2296 Chrome uses the best address family available when performing a connection migration. I agree with you that this isn't explicitly mentioned in the spec, but it's not disallowed either. I would suggest removing that text from your draft since it doesn't change what you're trying to accomplish. If you want to file an errata on RFC 9000, that might be a good candidate for "hold for document update".
David On Tue, Oct 18, 2022 at 12:39 AM Maxime Piraux <[email protected]> wrote: > Hello David, > > 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. > > I do understand that in most deployments the advertised addresses are > expected to last as long as the connection, so using these later in the > connection is very likely to work. > > However, it is not completely clear to me that a client could use one of > these addresses after it "has acted on a preferred_address transport > parameter" as written in RFC9000. For instance, if it happens to lose > its address family in the middle of the connection. On this particular > case, an errata could be the outcome of our discussion here if what we > discuss was the intended scope. > > Le 17/10/22 à 22:05, David Schinazi a écrit : > > Hi Maxime, > > > > Could you clarify what you meant by this sentence please? > > <<Also, a dual-stack server cannot advertise its other address so that a > > client losing the address family used to establish the connection can > > migrate to the other address family.>> > > > > We intentionally included one IPv4 address and one IPv6 address > > in preferred_address to allow migration across address families. > > > > David > > > > On Mon, Oct 17, 2022 at 8:30 AM Maxime Piraux < > [email protected]> > > wrote: > > > >> Hello QUIC wg, > >> > >> We have submitted a document proposing a new QUIC Transport Parameter > for > >> servers to announce additional addresses that can be used in a QUIC > >> connection. > >> > >> The proposed mechanism addresses scenarios in which dual-stack and > >> multihomed servers would like to advertise several server addresses so > that > >> clients can use them to cope with the loss of an address family and a > >> provider failure. When Multipath QUIC is used over the connection, this > >> extension can also be used to advertise addresses towards which > additional > >> paths can be established. > >> > >> The transport parameter is complementary to the use of Preferred Address > >> and this point is also discussed in the document. We hope the document > will > >> spark interesting discussions and welcome any feedback. > >> > >> Maxime Piraux > >> -------- Message transféré -------- > >> Sujet : New Version Notification for > >> draft-piraux-quic-additional-addresses-00.txt > >> Date : Fri, 14 Oct 2022 04:55:31 -0700 > >> De : [email protected] > >> Pour : Maxime Piraux <[email protected]> > >> <[email protected]>, Olivier Bonaventure > >> <[email protected]> <[email protected]>, > >> Olivier Bonaventure <[email protected]> > >> <[email protected]> > >> > >> > >> A new version of I-D, draft-piraux-quic-additional-addresses-00.txt > >> has been successfully submitted by Maxime Piraux and posted to the > >> IETF repository. > >> > >> Name: draft-piraux-quic-additional-addresses > >> Revision: 00 > >> Title: Additional addresses for QUIC > >> Document date: 2022-10-14 > >> Group: Individual Submission > >> Pages: 7 > >> URL: > >> > https://www.ietf.org/archive/id/draft-piraux-quic-additional-addresses-00.txt > >> Status: > >> > https://datatracker.ietf.org/doc/draft-piraux-quic-additional-addresses/ > >> Html: > >> > https://www.ietf.org/archive/id/draft-piraux-quic-additional-addresses-00.html > >> Htmlized: > >> > https://datatracker.ietf.org/doc/html/draft-piraux-quic-additional-addresses > >> > >> > >> Abstract: > >> This document specifies a QUIC Transport Parameter enabling a QUIC > >> server to advertise additional addresses that can be used for a QUIC > >> connection. > >> > >> > >> > >> The IETF Secretariat > >> > >> > >> >
