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

# 8.1.3.  Address Validation for Future Connections
#
# A server MAY provide clients with an address validation token during
# one connection that can be used on a subsequent connection.  Address
# validation is especially important with 0-RTT because a server
# potentially sends a significant amount of data to a client in
# response to 0-RTT data.
# 
# The server uses the NEW_TOKEN frame (Section 19.7) to provide the
# client with an address validation token that can be used to validate
# future connections.  In a future connection, the client includes this
# token in Initial packets to provide address validation.  The client
# MUST include the token in all Initial packets it sends, unless a
# Retry replaces the token with a newer one.  The client MUST NOT use
# the token provided in a Retry for future connections.  Servers MAY
# discard any Initial packet that does not carry the expected token.
# 
# Unlike the token that is created for a Retry packet, which is used
# immediately, the token sent in the NEW_TOKEN frame can be used after
# some period of time has passed.  Thus, a token SHOULD have an
# expiration time, which could be either an explicit expiration time or
# an issued timestamp that can be used to dynamically calculate the
# expiration time.  A server can store the expiration time or include
# it in an encrypted form in the token.
# 
# A token issued with NEW_TOKEN MUST NOT include information that would
# allow values to be linked by an observer to the connection on which
# it was issued.  For example, it cannot include the previous
# connection ID or addressing information, unless the values are
# encrypted.  A server MUST ensure that every NEW_TOKEN frame it sends
# is unique across all clients, with the exception of those sent to
# repair losses of previously sent NEW_TOKEN frames.  Information that
# allows the server to distinguish between tokens from Retry and
# NEW_TOKEN MAY be accessible to entities other than the server.
# 
# It is unlikely that the client port number is the same on two
# different connections; validating the port is therefore unlikely to
# be successful.
# 
# A token received in a NEW_TOKEN frame is applicable to any server
# that the connection is considered authoritative for (e.g., server
# names included in the certificate).  When connecting to a server for
# which the client retains an applicable and unused token, it SHOULD
# include that token in the Token field of its Initial packet.
# Including a token might allow the server to validate the client
# address without an additional round trip.  A client MUST NOT include
# a token that is not applicable to the server that it is connecting
# to, unless the client has the knowledge that the server that issued
# the token and the server the client is connecting to are jointly
# managing the tokens.  A client MAY use a token from any previous
# connection to that server.
# 
# A token allows a server to correlate activity between the connection
# where the token was issued and any connection where it is used.
# Clients that want to break continuity of identity with a server can
# discard tokens provided using the NEW_TOKEN frame.  In comparison, a
# token obtained in a Retry packet MUST be used immediately during the
# connection attempt and cannot be used in subsequent connection
# attempts.
# 
# A client SHOULD NOT reuse a token from a NEW_TOKEN frame for
# different connection attempts.  Reusing a token allows connections to
# be linked by entities on the network path; see Section 9.5.
# 
# Clients might receive multiple tokens on a single connection.  Aside
# from preventing linkability, any token can be used in any connection
# attempt.  Servers can send additional tokens to either enable address
# validation for multiple connection attempts or replace older tokens
# that might become invalid.  For a client, this ambiguity means that
# sending the most recent unused token is most likely to be effective.
# Though saving and using older tokens have no negative consequences,
# clients can regard older tokens as being less likely to be useful to
# the server for address validation.
# 
# When a server receives an Initial packet with an address validation
# token, it MUST attempt to validate the token, unless it has already
# completed address validation.  If the token is invalid, then the
# server SHOULD proceed as if the client did not have a validated
# address, including potentially sending a Retry packet.  Tokens
# provided with NEW_TOKEN frames and Retry packets can be distinguished
# by servers (see Section 8.1.1), and the latter can be validated more
# strictly.  If the validation succeeds, the server SHOULD then allow
# the handshake to proceed.
# 
#    |  Note: The rationale for treating the client as unvalidated
#    |  rather than discarding the packet is that the client might have
#    |  received the token in a previous connection using the NEW_TOKEN
#    |  frame, and if the server has lost state, it might be unable to
#    |  validate the token at all, leading to connection failure if the
#    |  packet is discarded.
# 
# In a stateless design, a server can use encrypted and authenticated
# tokens to pass information to clients that the server can later
# recover and use to validate a client address.  Tokens are not
# integrated into the cryptographic handshake, and so they are not
# authenticated.  For instance, a client might be able to reuse a
# token.  To avoid attacks that exploit this property, a server can
# limit its use of tokens to only the information needed to validate
# client addresses.
# 
# Clients MAY use tokens obtained on one connection for any connection
# attempt using the same version.  When selecting a token to use,
# clients do not need to consider other properties of the connection
# that is being attempted, including the choice of possible application
# protocols, session tickets, or other connection properties.

[[spec]]
level = "MAY"
quote = '''
A server MAY provide clients with an address validation token during
one connection that can be used on a subsequent connection.
'''

[[spec]]
level = "MUST"
quote = '''
The client
MUST include the token in all Initial packets it sends, unless a
Retry replaces the token with a newer one.
'''

[[spec]]
level = "MUST"
quote = '''
The client MUST NOT use
the token provided in a Retry for future connections.
'''

[[spec]]
level = "MAY"
quote = '''
Servers MAY
discard any Initial packet that does not carry the expected token.
'''

[[spec]]
level = "SHOULD"
quote = '''
Thus, a token SHOULD have an
expiration time, which could be either an explicit expiration time or
an issued timestamp that can be used to dynamically calculate the
expiration time.
'''

[[spec]]
level = "MUST"
quote = '''
A token issued with NEW_TOKEN MUST NOT include information that would
allow values to be linked by an observer to the connection on which
it was issued.
'''

[[spec]]
level = "MUST"
quote = '''
A server MUST ensure that every NEW_TOKEN frame it sends
is unique across all clients, with the exception of those sent to
repair losses of previously sent NEW_TOKEN frames.
'''

[[spec]]
level = "MAY"
quote = '''
Information that
allows the server to distinguish between tokens from Retry and
NEW_TOKEN MAY be accessible to entities other than the server.
'''

[[spec]]
level = "SHOULD"
quote = '''
When connecting to a server for
which the client retains an applicable and unused token, it SHOULD
include that token in the Token field of its Initial packet.
'''

[[spec]]
level = "MUST"
quote = '''
A client MUST NOT include
a token that is not applicable to the server that it is connecting
to, unless the client has the knowledge that the server that issued
the token and the server the client is connecting to are jointly
managing the tokens.
'''

[[spec]]
level = "MAY"
quote = '''
A client MAY use a token from any previous
connection to that server.
'''

[[spec]]
level = "MUST"
quote = '''
In comparison, a
token obtained in a Retry packet MUST be used immediately during the
connection attempt and cannot be used in subsequent connection
attempts.
'''

[[spec]]
level = "SHOULD"
quote = '''
A client SHOULD NOT reuse a token from a NEW_TOKEN frame for
different connection attempts.
'''

[[spec]]
level = "MUST"
quote = '''
When a server receives an Initial packet with an address validation
token, it MUST attempt to validate the token, unless it has already
completed address validation.
'''

[[spec]]
level = "SHOULD"
quote = '''
If the token is invalid, then the
server SHOULD proceed as if the client did not have a validated
address, including potentially sending a Retry packet.
'''

[[spec]]
level = "SHOULD"
quote = '''
If the validation succeeds, the server SHOULD then allow
the handshake to proceed.
'''

[[spec]]
level = "MAY"
quote = '''
Clients MAY use tokens obtained on one connection for any connection
attempt using the same version.
'''