Hello Marten,
Indeed this TP does not addresses the case of a dynamic set of
addresses. A frame updating this set would work. It probably requires a
bit more work in the Security Considerations section as it becomes a
dynamic mechanism. The case of an address being used and then removed
using the frame needs also to be discussed. The TP should be reworked to
negotiate the use of this frame. I would be interested to update the
document in this direction to get a sense of the complexity of using
such a frame.
It could still be employed when using Multipath QUIC, so it would make
sense to have it in a separate document I believe. I have not closely
followed the discussions on the MPQUIC extension, and feedback from this
side would also be valuable.
Le 17/10/22 à 17:52, Marten Seemann a écrit :
Thank you for the draft. I was wondering if this should be a QUIC frame
instead of a transport parameter.
A frame would make this more interesting for the more general case where
the set of addresses of a node is not static. Take for example a QUIC
connection between two mobile devices (where interfaces / path can come up
/ go down), or for servers located behind NATs / firewalls (which might
need some time to discover their public addresses).
On Mon 17. Oct 2022 at 16:30, 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
