Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarifications for preferred_address #3588

Merged
merged 1 commit into from
Apr 28, 2020
Merged

Clarifications for preferred_address #3588

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2327,6 +2327,11 @@ begins sending non-probing packets to the client exclusively from its preferred
IP address. It SHOULD drop packets for this connection received on the old IP
address, but MAY continue to process delayed packets.

The addresses that a server provides in the preferred_address transport
parameter are only valid for the connection in which they are provided. A
client MUST NOT use these for other connections, including connections that are
resumed from the current connection.


### Interaction of Client Migration and Preferred Address

Expand Down Expand Up @@ -2355,6 +2360,12 @@ address before path validation is complete.
A client that migrates to a new address SHOULD use a preferred address from the
same address family for the server.

The connection ID provided in the preferred_address transport parameter is not
specific to the addresses that are provided. This connection ID is provided to
ensure that the client has a connection ID available for migration, but the
client MAY use this connection ID on any path.


## Use of IPv6 Flow-Label and Migration {#ipv6-flow-label}

Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label
Expand Down