target = "https://www.rfc-editor.org/rfc/rfc9000#section-9.5"

# 9.5.  Privacy Implications of Connection Migration
#
# Using a stable connection ID on multiple network paths would allow a
# passive observer to correlate activity between those paths.  An
# endpoint that moves between networks might not wish to have their
# activity correlated by any entity other than their peer, so different
# connection IDs are used when sending from different local addresses,
# as discussed in Section 5.1.  For this to be effective, endpoints
# need to ensure that connection IDs they provide cannot be linked by
# any other entity.
# 
# At any time, endpoints MAY change the Destination Connection ID they
# transmit with to a value that has not been used on another path.
# 
# An endpoint MUST NOT reuse a connection ID when sending from more
# than one local address -- for example, when initiating connection
# migration as described in Section 9.2 or when probing a new network
# path as described in Section 9.1.
# 
# Similarly, an endpoint MUST NOT reuse a connection ID when sending to
# more than one destination address.  Due to network changes outside
# the control of its peer, an endpoint might receive packets from a new
# source address with the same Destination Connection ID field value,
# in which case it MAY continue to use the current connection ID with
# the new remote address while still sending from the same local
# address.
# 
# These requirements regarding connection ID reuse apply only to the
# sending of packets, as unintentional changes in path without a change
# in connection ID are possible.  For example, after a period of
# network inactivity, NAT rebinding might cause packets to be sent on a
# new path when the client resumes sending.  An endpoint responds to
# such an event as described in Section 9.3.
# 
# Using different connection IDs for packets sent in both directions on
# each new network path eliminates the use of the connection ID for
# linking packets from the same connection across different network
# paths.  Header protection ensures that packet numbers cannot be used
# to correlate activity.  This does not prevent other properties of
# packets, such as timing and size, from being used to correlate
# activity.
# 
# An endpoint SHOULD NOT initiate migration with a peer that has
# requested a zero-length connection ID, because traffic over the new
# path might be trivially linkable to traffic over the old one.  If the
# server is able to associate packets with a zero-length connection ID
# to the right connection, it means that the server is using other
# information to demultiplex packets.  For example, a server might
# provide a unique address to every client -- for instance, using HTTP
# alternative services [ALTSVC].  Information that might allow correct
# routing of packets across multiple network paths will also allow
# activity on 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 [RFC8981]) when
# sending traffic after a period of inactivity.  Changing the address
# from which it sends packets at the same time might cause the server
# to detect a connection migration.  This ensures that the mechanisms
# that support migration are exercised even for clients that do not
# experience NAT rebindings or genuine migrations.  Changing address
# can cause a peer to reset its congestion control state (see
# Section 9.4), 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 migrate.  To ensure that migration is possible and
# packets sent on different paths cannot be correlated, endpoints
# SHOULD provide new connection IDs before peers migrate; see
# Section 5.1.1.  If a peer might have exhausted available connection
# IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in
# all packets sent on a new network path.

[[spec]]
level = "MAY"
quote = '''
At any time, endpoints MAY change the Destination Connection ID they
transmit with to a value that has not been used on another path.
'''

[[spec]]
level = "MUST"
quote = '''
An endpoint MUST NOT reuse a connection ID when sending from more
than one local address -- for example, when initiating connection
migration as described in Section 9.2 or when probing a new network
path as described in Section 9.1.
'''

[[spec]]
level = "MUST"
quote = '''
Similarly, an endpoint MUST NOT reuse a connection ID when sending to
more than one destination address.
'''

[[spec]]
level = "MAY"
quote = '''
Due to network changes outside
the control of its peer, an endpoint might receive packets from a new
source address with the same Destination Connection ID field value,
in which case it MAY continue to use the current connection ID with
the new remote address while still sending from the same local
address.
'''

[[spec]]
level = "SHOULD"
quote = '''
An endpoint SHOULD NOT initiate migration with a peer that has
requested a zero-length connection ID, because traffic over the new
path might be trivially linkable to traffic over the old one.
'''

[[spec]]
level = "SHOULD"
quote = '''
Changing address
can cause a peer to reset its congestion control state (see
Section 9.4), so addresses SHOULD only be changed infrequently.
'''

[[spec]]
level = "SHOULD"
quote = '''
To ensure that migration is possible and
packets sent on different paths cannot be correlated, endpoints
SHOULD provide new connection IDs before peers migrate; see
Section 5.1.1.
'''