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

# 8.2.  Path Validation
#
# Path validation is used by both peers during connection migration
# (see Section 9) to verify reachability after a change of address.  In
# path validation, endpoints test reachability between a specific local
# address and a specific peer address, where an address is the 2-tuple
# of IP address and port.
# 
# Path validation tests that packets sent on a path to a peer are
# received by that peer.  Path validation is used to ensure that
# packets received from a migrating peer do not carry a spoofed source
# address.
# 
# Path validation does not validate that a peer can send in the return
# direction.  Acknowledgments cannot be used for return path validation
# because they contain insufficient entropy and might be spoofed.
# Endpoints independently determine reachability on each direction of a
# path, and therefore return reachability can only be established by
# the peer.
# 
# Path validation can be used at any time by either endpoint.  For
# instance, an endpoint might check that a peer is still in possession
# of its address after a period of quiescence.
# 
# Path validation is not designed as a NAT traversal mechanism.  Though
# the mechanism described here might be effective for the creation of
# NAT bindings that support NAT traversal, the expectation is that one
# endpoint is able to receive packets without first having sent a
# packet on that path.  Effective NAT traversal needs additional
# synchronization mechanisms that are not provided here.
# 
# An endpoint MAY include other frames with the PATH_CHALLENGE and
# PATH_RESPONSE frames used for path validation.  In particular, an
# endpoint can include PADDING frames with a PATH_CHALLENGE frame for
# Path Maximum Transmission Unit Discovery (PMTUD); see Section 14.2.1.
# An endpoint can also include its own PATH_CHALLENGE frame when
# sending a PATH_RESPONSE frame.
# 
# An endpoint uses a new connection ID for probes sent from a new local
# address; see Section 9.5.  When probing a new path, an endpoint can
# ensure that its peer has an unused connection ID available for
# responses.  Sending NEW_CONNECTION_ID and PATH_CHALLENGE frames in
# the same packet, if the peer's active_connection_id_limit permits,
# ensures that an unused connection ID will be available to the peer
# when sending a response.
# 
# An endpoint can choose to simultaneously probe multiple paths.  The
# number of simultaneous paths used for probes is limited by the number
# of extra connection IDs its peer has previously supplied, since each
# new local address used for a probe requires a previously unused
# connection ID.

[[spec]]
level = "MAY"
quote = '''
An endpoint MAY include other frames with the PATH_CHALLENGE and
PATH_RESPONSE frames used for path validation.
'''