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.

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

A new IP #4725

Merged
merged 3 commits into from
Jan 13, 2021
Merged
Changes from 1 commit
Commits
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
6 changes: 3 additions & 3 deletions draft-ietf-quic-transport.md
Original file line number Diff line number Diff line change
Expand Up @@ -2644,12 +2644,12 @@ those paths to be linked by entities other than the peer.

A client might wish to reduce linkability by switching to a new connection ID,
source UDP port, or IP address (see {{?RFC4941}}) when sending traffic after a
period of inactivity. Changing the UDP port from which it sends packets at the
period of inactivity. Changing the address from which it sends packets at the
same time might cause the packet to appear as a connection migration. This
martinthomson marked this conversation as resolved.
Show resolved Hide resolved
ensures that the mechanisms that support migration are exercised even for
clients that do not experience NAT rebindings or genuine migrations. Changing
port number can cause a peer to reset its congestion control state (see
{{migration-cc}}), so the port SHOULD only be changed infrequently.
address can cause a peer to reset its congestion control state (see
{{migration-cc}}), so addresses SHOULD only be changed infrequently.

An endpoint that exhausts available connection IDs cannot probe new paths or
initiate migration, nor can it respond to probes or attempts by its peer to
Expand Down