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
