doc: Add RFC documents

1 files changed, 813 insertions, 0 deletions

diff --git a/doc/rfc/rfc9368.txt b/doc/rfc/rfc9368.txt
new file mode 100644
index 0000000..8ab47ba
--- /dev/null
+++ b/doc/rfc/rfc9368.txt
@@ -0,0 +1,813 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       D. Schinazi
+Request for Comments: 9368                                    Google LLC
+Updates: 8999                                                E. Rescorla
+Category: Standards Track                                        Mozilla
+ISSN: 2070-1721                                                 May 2023
+
+
+                Compatible Version Negotiation for QUIC
+
+Abstract
+
+   QUIC does not provide a complete version negotiation mechanism but
+   instead only provides a way for the server to indicate that the
+   version the client chose is unacceptable.  This document describes a
+   version negotiation mechanism that allows a client and server to
+   select a mutually supported version.  Optionally, if the client's
+   chosen version and the negotiated version share a compatible first
+   flight format, the negotiation can take place without incurring an
+   extra round trip.  This document updates RFC 8999.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9368.
+
+Copyright Notice
+
+   Copyright (c) 2023 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Conventions
+     1.2.  Definitions
+   2.  Version Negotiation Mechanism
+     2.1.  Incompatible Version Negotiation
+     2.2.  Compatible Versions
+     2.3.  Compatible Version Negotiation
+     2.4.  Connections and Version Negotiation
+     2.5.  Client Choice of Original Version
+   3.  Version Information
+   4.  Version Downgrade Prevention
+   5.  Server Deployments of QUIC
+   6.  Application-Layer Protocol Considerations
+   7.  Considerations for Future Versions
+     7.1.  Interaction with Retry
+     7.2.  Interaction with TLS Resumption
+     7.3.  Interaction with 0-RTT
+   8.  Special Handling for QUIC Version 1
+   9.  Security Considerations
+   10. IANA Considerations
+     10.1.  QUIC Transport Parameter
+     10.2.  QUIC Transport Error Code
+   11. References
+     11.1.  Normative References
+     11.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   The version-invariant properties of QUIC [QUIC-INVARIANTS] define a
+   Version Negotiation packet but do not specify how an endpoint reacts
+   when it receives one.  QUIC version 1 [QUIC] allows the server to use
+   a Version Negotiation packet to indicate that the version the client
+   chose is unacceptable, but it doesn't allow the client to safely make
+   use of that information to create a new connection with a mutually
+   supported version.  This document updates [QUIC-INVARIANTS] by
+   defining version negotiation mechanisms that leverage the Version
+   Negotiation packet.
+
+   With proper safety mechanisms in place, the Version Negotiation
+   packet can be part of a mechanism to allow two QUIC implementations
+   to negotiate between two totally disjoint versions of QUIC.  This
+   document specifies version negotiation using Version Negotiation
+   packets, which adds an extra round trip to connection establishment
+   if needed.
+
+   It is beneficial to avoid additional round trips whenever possible,
+   especially given that most incremental versions are broadly similar
+   to the previous version.  This specification also defines a simple
+   version negotiation mechanism which leverages similarities between
+   versions and can negotiate between "compatible" versions without
+   additional round trips.
+
+1.1.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+1.2.  Definitions
+
+   The document uses the following terms:
+
+   *  In the context of a given QUIC connection, the "first flight" of
+      packets refers to the set of packets the client creates and sends
+      to initiate the connection before it has heard back from the
+      server.
+
+   *  In the context of a given QUIC connection, the "client's Chosen
+      Version" is the QUIC version of the connection's first flight.
+
+   *  The "Original Version" is the QUIC version of the very first
+      packet the client sends to the server.  If version negotiation
+      spans multiple connections (see Section 2.4), the Original Version
+      is equal to the client's Chosen Version of the first QUIC
+      connection.
+
+   *  The "Negotiated Version" is the QUIC version in use on the
+      connection once the version negotiation process completes.
+
+   *  The "Maximum Segment Lifetime" (MSL) represents the time a QUIC
+      packet can exist in the network.  Implementations can make this
+      configurable, and a RECOMMENDED value is one minute.  Note that
+      the term "segment" here originated in Section 3.4.1 of [TCP].
+
+2.  Version Negotiation Mechanism
+
+   This document specifies two means of performing version negotiation:
+   1) "incompatible", which requires a round trip and is applicable to
+   all versions, and 2) "compatible", which allows saving the round trip
+   but only applies when the versions are compatible (see Section 2.2).
+
+   The client initiates a QUIC connection by choosing an Original
+   Version and sending a first flight of QUIC packets with a long header
+   to the server [QUIC-INVARIANTS].  The client's first flight includes
+   Version Information (see Section 3), which will be used to optionally
+   enable compatible version negotiation (see Section 2.3) and to
+   prevent version downgrade attacks (see Section 4).
+
+   Upon receiving this first flight, the server verifies whether it
+   knows how to parse first flights from the Chosen Version (which is
+   also the Original Version in this case).  If it does not, then it
+   starts incompatible version negotiation (see Section 2.1), which
+   causes the client to initiate a new connection with a different
+   version.  For instance, if the client initiates a connection with
+   version A that the server can't parse, the server starts incompatible
+   version negotiation; then, when the client initiates a new connection
+   with version B, we say that the first connection's client Chosen
+   Version is A, the second connection's client Chosen Version is B, and
+   the Original Version for the entire sequence is A.
+
+   If the server can parse the first flight, it can establish the
+   connection using the client's Chosen Version, or it MAY select any
+   other compatible version, as described in Section 2.3.
+
+   Note that it is possible for a server to have the ability to parse
+   the first flight of a given version without fully supporting it, in
+   the sense that it implements enough of the version's specification to
+   parse first flight packets but not enough to fully establish a
+   connection using that version.
+
+2.1.  Incompatible Version Negotiation
+
+   The server starts incompatible version negotiation by sending a
+   Version Negotiation packet.  This packet SHALL include each entry
+   from the server's set of Offered Versions (see Section 5) in a
+   Supported Version field.  The server MAY add reserved versions (as
+   defined in Section 6.3 of [QUIC]) in Supported Version fields.
+
+   Clients will ignore a Version Negotiation packet if it contains the
+   Original Version attempted by the client, as required by Section 4.
+   The client also ignores a Version Negotiation packet that contains
+   incorrect connection ID fields, as required by Section 6 of
+   [QUIC-INVARIANTS].
+
+   Upon receiving the Version Negotiation packet, the client SHALL
+   search for a version it supports in the list provided by the server.
+   If it doesn't find one, it SHALL abort the connection attempt.
+   Otherwise, it SHALL select a mutually supported version and send a
+   new first flight with that version -- this version is now the
+   Negotiated Version.
+
+   The new first flight will allow the endpoints to establish a
+   connection using the Negotiated Version.  The handshake of the
+   Negotiated Version will exchange Version Information (see Section 3)
+   that is required to ensure that version negotiation was genuine,
+   i.e., that no attacker injected packets in order to influence the
+   version negotiation process (see Section 4).
+
+   Only servers can start incompatible version negotiation.  Clients
+   MUST NOT send Version Negotiation packets and servers MUST ignore all
+   received Version Negotiation packets.
+
+2.2.  Compatible Versions
+
+   If A and B are two distinct versions of QUIC, A is said to be
+   "compatible" with B if it is possible to take a first flight of
+   packets from version A and convert it into a first flight of packets
+   from version B.  As an example, if versions A and B are absolutely
+   equal in their wire image and behavior during the handshake but
+   differ after the handshake, then A is compatible with B and B is
+   compatible with A.  Note that the conversion of the first flight can
+   be lossy; some data, such as QUIC version 1 0-RTT packets, could be
+   ignored during conversion and retransmitted later.
+
+   Version compatibility is not symmetric.  It is possible for version A
+   to be compatible with version B and for version B not to be
+   compatible with version A.  This could happen, for example, if
+   version B is a strict superset of version A, i.e., if version A
+   includes the concept of streams and STREAM frames and version B
+   includes the concept of streams and the hypothetical concept of tubes
+   along with STREAM and TUBE frames, then A would be compatible with B,
+   but B would not be compatible with A.
+
+   Note that version compatibility does not mean that every single
+   possible instance of a first flight will succeed in conversion to the
+   other version.  A first flight using version A is said to be
+   "compatible" with version B if two conditions are met: (1) version A
+   is compatible with version B and (2) the conversion of this first
+   flight to version B is well defined.  For example, if version B is
+   equal to version A in all aspects except it introduced a new frame in
+   its first flight that version A cannot parse or even ignore, then
+   version B could still be compatible with version A, as conversions
+   would succeed for connections where that frame is not used.  In this
+   example, first flights using version B that carry this new frame
+   would not be compatible with version A.
+
+   When a new version of QUIC is defined, it is assumed to not be
+   compatible with any other version unless otherwise specified.
+   Similarly, no other version is compatible with the new version unless
+   otherwise specified.  Implementations MUST NOT assume compatibility
+   between versions unless explicitly specified.
+
+   Note that both endpoints might disagree on whether two versions are
+   compatible or not.  For example, two versions could have been defined
+   concurrently and then specified as compatible in a third document
+   much later -- in that scenario, one endpoint might be aware of the
+   compatibility document, while the other may not.
+
+2.3.  Compatible Version Negotiation
+
+   When the server can parse the client's first flight using the
+   client's Chosen Version, it can extract the client's Version
+   Information structure (see Section 3).  This contains the list of
+   versions that the client knows its first flight is compatible with.
+
+   In order to perform compatible version negotiation, the server MUST
+   select one of these versions that it (1) supports and (2) knows the
+   client's Chosen Version is compatible with.  This selected version is
+   now the Negotiated Version.  After selecting it, the server attempts
+   to convert the client's first flight into that version and replies to
+   the client as if it had received the converted first flight.
+
+   If those formats are identical, as in cases where the Negotiated
+   Version is the same as the client's Chosen Version, then this will be
+   the identity transformation.  If the first flight is correctly
+   formatted, then this conversion process cannot fail by definition of
+   the first flight being compatible; if the server is unable to convert
+   the first flight, it MUST abort the handshake.
+
+   If a document specifies that a QUIC version is compatible with
+   another, that document MUST specify the mechanism by which clients
+   are made aware of the Negotiated Version.  An example of such a
+   mechanism is to have the client determine the server's Negotiated
+   Version by examining the QUIC long header Version field.  Note that,
+   in this example mechanism, it is possible for the server to initially
+   send packets with the client's Chosen Version before switching to the
+   Negotiated Version (this can happen when the client's Version
+   Information structure spans multiple packets; in that case, the
+   server might acknowledge the first packet in the client's Chosen
+   Version and later switch to a different Negotiated Version).
+   Mutually compatible versions SHOULD use the same mechanism.
+
+   Note that, after the first flight is converted to the Negotiated
+   Version, the handshake completes in the Negotiated Version.  If the
+   Negotiated Version has requirements that apply during the handshake,
+   those requirements apply to the entire handshake, including the
+   converted first flight.  In particular, if the Negotiated Version
+   mandates that endpoints perform validations on Handshake packets,
+   endpoints MUST also perform such validations on the converted first
+   flight.  For instance, if the Negotiated Version requires that the
+   5-tuple remain stable for the entire handshake (as QUIC version 1
+   does), then both endpoints need to validate the 5-tuple of all
+   packets received during the handshake, including the converted first
+   flight.
+
+   Note also that the client can disable compatible version negotiation
+   by only including the Chosen Version in the Available Versions field
+   of the Version Information (see Section 3).
+
+   If the server does not find a compatible version (including the
+   client's Chosen Version), it will perform incompatible version
+   negotiation instead (see Section 2.1).
+
+   Note that it is possible to have incompatible version negotiation
+   followed by compatible version negotiation.  For instance, if version
+   A is compatible with version B and version C is compatible with
+   version D, the following scenario could occur:
+
+   Client                                          Server
+
+   Chosen = A, Available Versions = (A, B) ------------->
+   <------------------------ Version Negotiation = (D, C)
+
+   Chosen = C, Available Versions = (C, D) ------------->
+   <------------- Chosen = D, Available Versions = (D, C)
+
+                   Figure 1: Combined Negotiation Example
+
+   In this example, the client selected C from the server's Version
+   Negotiation packet, but the server preferred D and then selected it
+   from the client's offer.
+
+2.4.  Connections and Version Negotiation
+
+   QUIC connections are shared state between a client and a server
+   [QUIC-INVARIANTS].  The compatible version negotiation mechanism
+   defined in this document (see Section 2.3) is performed as part of a
+   single QUIC connection; that is, the packets with the client's Chosen
+   Version are part of the same connection as the packets with the
+   Negotiated Version.
+
+   In comparison, the incompatible version negotiation mechanism, which
+   leverages QUIC Version Negotiation packets (see Section 2.1),
+   conceptually operates across two QUIC connections, i.e., the
+   connection attempt prior to receiving the Version Negotiation packet
+   is distinct from the connection with the incompatible version that
+   follows.
+
+   Note that this separation across two connections is conceptual, i.e.,
+   it applies to normative requirements on QUIC connections, but it does
+   not require implementations to internally use two distinct connection
+   objects.
+
+2.5.  Client Choice of Original Version
+
+   When the client picks its Original Version, it SHOULD try to avoid
+   incompatible version negotiation to save a round trip.  Therefore,
+   the client SHOULD pick an Original Version to maximize the combined
+   probability that both:
+
+   *  the server knows how to parse first flights from the Original
+      Version and
+
+   *  the Original Version is compatible with the client's preferred
+      version.
+
+   Without additional information, this could mean selecting the oldest
+   version that the client supports while advertising newer compatible
+   versions in the client's first flight.
+
+3.  Version Information
+
+   During the handshake, endpoints will exchange Version Information,
+   which consists of a Chosen Version and a list of Available Versions.
+   Any version of QUIC that supports this mechanism MUST provide a
+   mechanism to exchange Version Information in both directions during
+   the handshake, such that this data is authenticated.
+
+   In QUIC version 1, the Version Information is transmitted using a new
+   version_information transport parameter (see Section 7.4 of [QUIC]).
+   The contents of Version Information are shown below (using the
+   notation from Section 1.3 of [QUIC]):
+
+   Version Information {
+     Chosen Version (32),
+     Available Versions (32) ...,
+   }
+
+                    Figure 2: Version Information Format
+
+   The content of each field is described below:
+
+   Chosen Version:  The version that the sender has chosen to use for
+      this connection.  In most cases, this field will be equal to the
+      value of the Version field in the long header that carries this
+      data; however, future versions or extensions can choose to set
+      different values in the long header Version field.
+
+   The contents of the Available Versions field depend on whether it is
+   sent by the client or by the server.
+
+   Client-Sent Available Versions:  When sent by a client, the Available
+      Versions field lists all the versions that this first flight is
+      compatible with, ordered by descending preference.  Note that the
+      version in the Chosen Version field MUST be included in this list
+      to allow the client to communicate the Chosen Version's
+      preference.  Note that this preference is only advisory; servers
+      MAY choose to use their own preference instead.
+   Server-Sent Available Versions:  When sent by a server, the Available
+      Versions field lists all the Fully Deployed Versions of this
+      server deployment (see Section 5).  The ordering of the versions
+      in this field does not carry any semantics.  Note that the version
+      in the Chosen Version field is not necessarily included in this
+      list, because the server operator could be in the process of
+      removing support for this version.  For the same reason, the
+      Available Versions field MAY be empty.
+
+   Clients and servers MAY both include versions following the pattern
+   0x?a?a?a?a in their Available Versions list.  Those versions are
+   reserved to exercise version negotiation (see Section 15 of [QUIC])
+   and will never be selected when choosing a version to use.
+
+4.  Version Downgrade Prevention
+
+   A version downgrade is an attack where a malicious entity manages to
+   make the QUIC endpoints negotiate a QUIC version different from the
+   one they would have negotiated in the absence of the attack.  The
+   mechanism described in this document is designed to prevent downgrade
+   attacks.
+
+   Clients MUST ignore any received Version Negotiation packets that
+   contain the Original Version.  A client that makes a connection
+   attempt based on information received from a Version Negotiation
+   packet MUST ignore any Version Negotiation packets it receives in
+   response to that connection attempt.
+
+   Both endpoints MUST parse their peer's Version Information during the
+   handshake.  If that leads to a parsing failure (for example, if it is
+   too short or if its length is not divisible by four), then the
+   endpoint MUST close the connection; if the connection was using QUIC
+   version 1, that connection closure MUST use a transport error of type
+   TRANSPORT_PARAMETER_ERROR.  If an endpoint receives a Chosen Version
+   equal to zero, or any Available Version equal to zero, it MUST treat
+   it as a parsing failure.  If a server receives Version Information
+   where the Chosen Version is not included in Available Versions, it
+   MUST treat it as a parsing failure.
+
+   Every QUIC version that supports version negotiation MUST define a
+   method for closing the connection with a version negotiation error.
+   For QUIC version 1, version negotiation errors are signaled using a
+   transport error of type VERSION_NEGOTIATION_ERROR (see Section 10.2).
+
+   When a server receives a client's first flight, the server will first
+   establish which QUIC version is in use for this connection in order
+   to properly parse the first flight.  This may involve examining data
+   that is not part of the handshake transcript, such as parts of the
+   packet header.  When the server then processes the client's Version
+   Information, the server MUST validate that the client's Chosen
+   Version matches the version in use for the connection.  If the two
+   differ, the server MUST close the connection with a version
+   negotiation error.
+
+   In the specific case of QUIC version 1, the server determines that
+   version 1 is in use by observing that the Version field of the first
+   Long Header packet it receives is set to 0x00000001.  Subsequently,
+   if the server receives the client's Version Information over QUIC
+   version 1 (as indicated by the Version field of the Long Header
+   packets that carried the transport parameters) and the client's
+   Chosen Version is not set to 0x00000001, the server MUST close the
+   connection with a version negotiation error.
+
+   Servers MAY complete the handshake even if the Version Information is
+   missing.  Clients MUST NOT complete the handshake if they are
+   reacting to a Version Negotiation packet and the Version Information
+   is missing, but MAY do so otherwise.
+
+   If a client receives Version Information where the server's Chosen
+   Version was not sent by the client as part of its Available Versions,
+   the client MUST close the connection with a version negotiation
+   error.  If a client has reacted to a Version Negotiation packet and
+   the server's Version Information was missing, the client MUST close
+   the connection with a version negotiation error.
+
+   If the client received and acted on a Version Negotiation packet, the
+   client MUST validate the server's Available Versions field.  The
+   Available Versions field is validated by confirming that the client
+   would have attempted the same version with knowledge of the versions
+   the server supports.  That is, the client would have selected the
+   same version if it received a Version Negotiation packet that listed
+   the versions in the server's Available Versions field, plus the
+   Negotiated Version.  If the client would have selected a different
+   version, the client MUST close the connection with a version
+   negotiation error.  In particular, if the client reacted to a Version
+   Negotiation packet and the server's Available Versions field is
+   empty, the client MUST close the connection with a version
+   negotiation error.  These connection closures prevent an attacker
+   from being able to use forged Version Negotiation packets to force a
+   version downgrade.
+
+   As an example, let's assume a client supports hypothetical QUIC
+   versions 10, 12, and 14 with a preference for higher versions.  The
+   client initiates a connection attempt with version 12.  Let's explore
+   two independent example scenarios:
+
+   *  In the first scenario, the server supports versions 10, 13, and
+      14, but only 13 and 14 are Fully Deployed (see Section 5).  The
+      server sends a Version Negotiation packet with versions 10, 13,
+      and 14.  This triggers an incompatible version negotiation, and
+      the client initiates a new connection with version 14.  Then, the
+      server's Available Versions field contains 13 and 14.  In that
+      scenario, the client would have also picked 14 if it had received
+      a Version Negotiation packet with versions 13 and 14; therefore,
+      the handshake succeeds using Negotiated Version 14.
+
+   *  In the second scenario, the server supports versions 10, 13, and
+      14, and they are all Fully Deployed.  However, the attacker forges
+      a Version Negotiation packet with versions 10 and 13.  This
+      triggers an incompatible version negotiation, and the client
+      initiates a new connection with version 10.  Then, the server's
+      Available Versions field contains 10, 13, and 14.  In that
+      scenario, the client would have picked 14 instead of 10 if it had
+      received a Version Negotiation packet with versions 10, 13, and
+      14; therefore, the client aborts the handshake with a version
+      negotiation error.
+
+   This validation of Available Versions is not sufficient to prevent
+   downgrade.  Downgrade prevention also depends on the client ignoring
+   Version Negotiation packets that contain the Original Version (see
+   Section 2.1).
+
+   After the process of version negotiation described in this document
+   completes, the version in use for the connection is the version that
+   the server sent in the Chosen Version field of its Version
+   Information.  That remains true even if other versions were used in
+   the Version field of long headers at any point in the lifetime of the
+   connection.  In particular, since the client can be made aware of the
+   Negotiated Version by the QUIC long header version during compatible
+   version negotiation (see Section 2.3), clients MUST validate that the
+   server's Chosen Version is equal to the Negotiated Version; if they
+   do not match, the client MUST close the connection with a version
+   negotiation error.  This prevents an attacker's ability to influence
+   version negotiation by forging the long header Version field.
+
+5.  Server Deployments of QUIC
+
+   While this document mainly discusses a single QUIC server, it is
+   common for deployments of QUIC servers to include a fleet of multiple
+   server instances.  Therefore, we define the following terms:
+
+   Acceptable Versions:  This is the set of versions supported by a
+      given server instance.  More specifically, these are the versions
+      that a given server instance will use if a client sends a first
+      flight using them.
+   Offered Versions:  This is the set of versions that a given server
+      instance will send in a Version Negotiation packet if it receives
+      a first flight from an unknown version.  This set will most often
+      be equal to the Acceptable Versions set, except during short
+      transitions while versions are added or removed (see below).
+   Fully Deployed Versions:  This is the set of QUIC versions that is
+      supported and negotiated by every single QUIC server instance in
+      this deployment.  If a deployment only contains a single server
+      instance, then this set is equal to the Offered Versions set,
+      except during short transitions while versions are added or
+      removed (see below).
+
+   If a deployment contains multiple server instances, software updates
+   may not happen at exactly the same time on all server instances.
+   Because of this, a client might receive a Version Negotiation packet
+   from a server instance that has already been updated, and the
+   client's resulting connection attempt might reach a different server
+   instance which hasn't been updated yet.
+
+   However, even when there is only a single server instance, it is
+   still possible to receive a stale Version Negotiation packet if the
+   server performs its software update while the Version Negotiation
+   packet is in flight.
+
+   This could cause the version downgrade prevention mechanism described
+   in Section 4 to falsely detect a downgrade attack.  To avoid that,
+   server operators SHOULD perform a three-step process when they wish
+   to add or remove support for a version, as described below.
+
+   When adding support for a new version:
+
+   *  The first step is to progressively add support for the new version
+      to all server instances.  This step updates the Acceptable
+      Versions but not the Offered Versions nor the Fully Deployed
+      Versions.  Once all server instances have been updated, operators
+      wait for at least one MSL to allow any in-flight Version
+      Negotiation packets to arrive.
+
+   *  Then, the second step is to progressively add the new version to
+      Offered Versions on all server instances.  Once complete,
+      operators wait for at least another MSL.
+
+   *  Finally, the third step is to progressively add the new version to
+      Fully Deployed Versions on all server instances.
+
+   When removing support for a version:
+
+   *  The first step is to progressively remove the version from Fully
+      Deployed Versions on all server instances.  Once it has been
+      removed on all server instances, operators wait for at least one
+      MSL to allow any in-flight Version Negotiation packets to arrive.
+
+   *  Then, the second step is to progressively remove the version from
+      Offered Versions on all server instances.  Once complete,
+      operators wait for at least another MSL.
+
+   *  Finally, the third step is to progressively remove support for the
+      version from all server instances.  That step updates the
+      Acceptable Versions.
+
+   Note that, during the update window, connections are vulnerable to
+   downgrade attacks for Acceptable Versions that are not Fully
+   Deployed.  This is because a client cannot distinguish such a
+   downgrade attack from legitimate exchanges with both updated and non-
+   updated server instances.
+
+6.  Application-Layer Protocol Considerations
+
+   When a client creates a QUIC connection, its goal is to use an
+   application-layer protocol.  Therefore, when considering which
+   versions are compatible, clients will only consider versions that
+   support one of the intended application-layer protocols.  If the
+   client's first flight advertises multiple Application-Layer Protocol
+   Negotiation (ALPN) [ALPN] tokens and multiple compatible versions, it
+   is possible for some application-layer protocols to not be able to
+   run over some of the offered compatible versions.  It is the server's
+   responsibility to only select an ALPN token that can run over the
+   compatible QUIC version that it selects.
+
+   A given ALPN token MUST NOT be used with a new QUIC version that is
+   different from the version for which the ALPN token was originally
+   defined, unless all the following requirements are met:
+
+   *  The new QUIC version supports the transport features required by
+      the application protocol.
+
+   *  The new QUIC version supports ALPN.
+
+   *  The version of QUIC for which the ALPN token was originally
+      defined is compatible with the new QUIC version.
+
+   When incompatible version negotiation is in use, the second
+   connection that is created in response to the received Version
+   Negotiation packet MUST restart its application-layer protocol
+   negotiation process without taking into account the Original Version.
+
+7.  Considerations for Future Versions
+
+   In order to facilitate the deployment of future versions of QUIC,
+   designers of future versions SHOULD attempt to design their new
+   version such that commonly deployed versions are compatible with it.
+
+   QUIC version 1 defines multiple features which are not documented in
+   the QUIC invariants.  Since, at the time of writing, QUIC version 1
+   is widely deployed, this section discusses considerations for future
+   versions to help with compatibility with QUIC version 1.
+
+7.1.  Interaction with Retry
+
+   QUIC version 1 features Retry packets, which the server can send to
+   validate the client's IP address before parsing the client's first
+   flight.  A server that sends a Retry packet can do so before parsing
+   the client's first flight.  Therefore, a server that sends a Retry
+   packet might not have processed the client's Version Information
+   before doing so.
+
+   If a future document wishes to define compatibility between two
+   versions that support Retry, that document MUST specify how version
+   negotiation (both compatible and incompatible) interacts with Retry
+   during a handshake that requires both.  For example, that could be
+   accomplished by having the server first send a Retry packet in the
+   Original Version, thereby validating the client's IP address before
+   attempting compatible version negotiation.  If both versions support
+   authenticating Retry packets, the compatibility definition needs to
+   define how to authenticate the Retry in the Negotiated Version
+   handshake even though the Retry itself was sent using the client's
+   Chosen Version.
+
+7.2.  Interaction with TLS Resumption
+
+   QUIC version 1 uses TLS 1.3, which supports session resumption by
+   sending session tickets in one connection that can be used in a later
+   connection (see Section 2.2 of [TLS]).  New versions that also use
+   TLS 1.3 SHOULD mandate that their session tickets are tightly scoped
+   to one version of QUIC, i.e., require that clients not use them
+   across multiple version and that servers validate this client
+   requirement.  This helps mitigate cross-protocol attacks.
+
+7.3.  Interaction with 0-RTT
+
+   QUIC version 1 allows sending data from the client to the server
+   during the handshake by using 0-RTT packets.  If a future document
+   wishes to define compatibility between two versions that support
+   0-RTT, that document MUST address the scenario where there are 0-RTT
+   packets in the client's first flight.  For example, this could be
+   accomplished by defining which transformations are applied to 0-RTT
+   packets.  That document could specify that compatible version
+   negotiation causes 0-RTT data to be rejected by the server.
+
+8.  Special Handling for QUIC Version 1
+
+   Because QUIC version 1 was the only QUIC version that was published
+   on the IETF Standards Track before this document, it is handled
+   specially as follows: if a client is starting a QUIC version 1
+   connection in response to a received Version Negotiation packet and
+   the version_information transport parameter is missing from the
+   server's transport parameters, then the client SHALL proceed as if
+   the server's transport parameters contained a version_information
+   transport parameter with a Chosen Version set to 0x00000001 and an
+   Available Version list containing exactly one version set to
+   0x00000001.  This allows version negotiation to work with servers
+   that only support QUIC version 1.  Note that implementations that
+   wish to use version negotiation to negotiate versions other than QUIC
+   version 1 MUST implement the version negotiation mechanism defined in
+   this document.
+
+9.  Security Considerations
+
+   The security of this version negotiation mechanism relies on the
+   authenticity of the Version Information exchanged during the
+   handshake.  In QUIC version 1, transport parameters are
+   authenticated, ensuring the security of this mechanism.  Negotiation
+   between compatible versions will have the security of the weakest
+   common version.
+
+   The requirement that versions not be assumed compatible mitigates the
+   possibility of cross-protocol attacks, but more analysis is still
+   needed here.  That analysis is out of scope for this document.
+
+10.  IANA Considerations
+
+10.1.  QUIC Transport Parameter
+
+   IANA has registered the following value in the "QUIC Transport
+   Parameters" registry maintained at <https://www.iana.org/assignments/
+   quic>.
+
+   Value:  0x11
+   Parameter Name:  version_information
+   Status:  permanent
+   Specification:  RFC 9368
+
+10.2.  QUIC Transport Error Code
+
+   IANA has registered the following value in the "QUIC Transport Error
+   Codes" registry maintained at <https://www.iana.org/assignments/
+   quic>.
+
+   Value:  0x11
+   Code:  VERSION_NEGOTIATION_ERROR
+   Description:  Error negotiating version
+   Status:  permanent
+   Specification:  RFC 9368
+
+11.  References
+
+11.1.  Normative References
+
+   [ALPN]     Friedl, S., Popov, A., Langley, A., and E. Stephan,
+              "Transport Layer Security (TLS) Application-Layer Protocol
+              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
+              July 2014, <https://www.rfc-editor.org/info/rfc7301>.
+
+   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
+              Multiplexed and Secure Transport", RFC 9000,
+              DOI 10.17487/RFC9000, May 2021,
+              <https://www.rfc-editor.org/info/rfc9000>.
+
+   [QUIC-INVARIANTS]
+              Thomson, M., "Version-Independent Properties of QUIC",
+              RFC 8999, DOI 10.17487/RFC8999, May 2021,
+              <https://www.rfc-editor.org/info/rfc8999>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [TLS]      Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+11.2.  Informative References
+
+   [TCP]      Eddy, W., Ed., "Transmission Control Protocol (TCP)",
+              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
+              <https://www.rfc-editor.org/info/rfc9293>.
+
+Acknowledgments
+
+   The authors would like to thank Nick Banks, Mike Bishop, Martin Duke,
+   Ryan Hamilton, Roberto Peon, Anthony Rossi, and Martin Thomson for
+   their input and contributions.
+
+Authors' Addresses
+
+   David Schinazi
+   Google LLC
+   1600 Amphitheatre Parkway
+   Mountain View, CA 94043
+   United States of America
+   Email: dschinazi.ietf@gmail.com
+
+
+   Eric Rescorla
+   Mozilla
+   Email: ekr@rtfm.com