rfc9368.original.xml   rfc9368.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 3.1. 3) --> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 3.1. 3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-quic-version-negotiation-14" category="std" consensus="true" submissionTyp e="IETF" updates="8999" tocInclude="true" sortRefs="true" symRefs="true" version ="3"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="9368" docName="draft-ietf-quic-version-negotiation-14" category="std" consensus="true" submissionType="IETF" obsoletes="" updates="8999" xml:lang="en" tocInclude="tru e" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.15.3 --> <!-- xml2rfc v2v3 conversion 3.15.3 -->
<front> <front>
<title abbrev="QUIC Compatible VN">Compatible Version Negotiation for QUIC</ <title abbrev="QUIC-Compatible VN">Compatible Version Negotiation for QUIC</
title> title>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-version-negotiation <seriesInfo name="RFC" value="9368"/>
-14"/>
<author initials="D." surname="Schinazi" fullname="David Schinazi"> <author initials="D." surname="Schinazi" fullname="David Schinazi">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<postal> <postal>
<street>1600 Amphitheatre Parkway</street> <street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>94043</code> <code>94043</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>dschinazi.ietf@gmail.com</email> <email>dschinazi.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization>Mozilla</organization> <organization>Mozilla</organization>
<address> <address>
<email>ekr@rtfm.com</email> <email>ekr@rtfm.com</email>
</address> </address>
</author> </author>
<date year="2022" month="December" day="19"/> <date year="2023" month="May"/>
<area>Transport</area> <area>Transport</area>
<workgroup>QUIC</workgroup> <workgroup>QUIC</workgroup>
<keyword>quic</keyword> <keyword>quic</keyword>
<keyword>version</keyword> <keyword>version</keyword>
<keyword>negotiation</keyword> <keyword>negotiation</keyword>
<keyword>compatible</keyword> <keyword>compatible</keyword>
<keyword>incompatible</keyword> <keyword>incompatible</keyword>
<keyword>not quite tls</keyword> <keyword>not quite tls</keyword>
<keyword>tls-ng</keyword> <keyword>tls-ng</keyword>
<abstract> <abstract>
<t>QUIC does not provide a complete version negotiation mechanism but inst ead only <t>QUIC does not provide a complete version negotiation mechanism but inst ead only
provides a way for the server to indicate that the version the client chose is provides a way for the server to indicate that the version the client chose is
unacceptable. This document describes a version negotiation mechanism that unacceptable. This document describes a version negotiation mechanism that
allows a client and server to select a mutually supported version. Optionally, 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 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 first flight format, the negotiation can take place without incurring an extra
round trip. This document updates RFC 8999.</t> round trip. This document updates RFC 8999.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
quicwg.github.io/version-negotiation/draft-ietf-quic-version-negotiation.html"/>
.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-quic-version-negotiation/"/>.
</t>
<t>
Discussion of this document takes place on the
QUIC Working Group mailing list (<eref target="mailto:quic@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/quic/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/quic/"/
>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/quicwg/version-negotiation"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The version-invariant properties of QUIC <xref target="QUIC-INVARIANTS" /> define a <t>The version-invariant properties of QUIC <xref target="RFC8999"/> defin e a
Version Negotiation packet but do not specify how an endpoint reacts when it Version Negotiation packet but do not specify how an endpoint reacts when it
receives one. QUIC version 1 <xref target="QUIC"/> allows the server to use a receives one. QUIC version 1 <xref target="RFC9000"/> allows the server to use a
Version Negotiation packet to indicate that the version the client chose is Version Negotiation packet to indicate that the version the client chose is
unacceptable, but doesn't allow the client to safely make use of that 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. information to create a new connection with a mutually supported version.
This document updates <xref target="QUIC-INVARIANTS"/> by defining version This document updates <xref target="RFC8999"/> by defining version
negotiation mechanisms that leverage the Version Negotiation packet.</t> negotiation mechanisms that leverage the Version Negotiation packet.</t>
<t>With proper safety mechanisms in place, the Version Negotiation packet can be <t>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 part of a mechanism to allow two QUIC implementations to negotiate between two
totally disjoint versions of QUIC. This document specifies version negotiation totally disjoint versions of QUIC. This document specifies version negotiation
using Version Negotiation packets, which adds an extra round trip to connection using Version Negotiation packets, which adds an extra round trip to connection
establishment if needed.</t> establishment if needed.</t>
<t>It is beneficial to avoid additional round trips whenever possible, esp ecially <t>It is beneficial to avoid additional round trips whenever possible, esp ecially
given that most incremental versions are broadly similar to the previous given that most incremental versions are broadly similar to the previous
version. This specification also defines a simple version negotiation mechanism version. This specification also defines a simple version negotiation mechanism
which leverages similarities between versions and can negotiate between which leverages similarities between versions and can negotiate between
"compatible" versions without additional round trips.</t> "compatible" versions without additional round trips.</t>
<section anchor="conventions"> <section anchor="conventions">
<name>Conventions</name> <name>Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="definitions"> <section anchor="definitions">
<name>Definitions</name> <name>Definitions</name>
<t>The document uses the following terms:</t> <t>The document uses the following terms:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>In the context of a given QUIC connection, the "first flight" of p ackets <li>In the context of a given QUIC connection, the "first flight" of p ackets
refers to the set of packets the client creates and sends to initiate the refers to the set of packets the client creates and sends to initiate the
connection before it has heard back from the server.</li> connection before it has heard back from the server.</li>
<li>In the context of a given QUIC connection, the "client's chosen ve rsion" is <li>In the context of a given QUIC connection, the "client's Chosen Ve rsion" is
the QUIC version of the connection's first flight.</li> the QUIC version of the connection's first flight.</li>
<li>The "original version" is the QUIC version of the very first packe t the client <li>The "Original Version" is the QUIC version of the very first packe t the client
sends to the server. If version negotiation spans multiple connections (see sends to the server. If version negotiation spans multiple connections (see
<xref target="connections"/>), the original version is equal to the client's cho sen version <xref target="connections"/>), the Original Version is equal to the client's Cho sen Version
of the first QUIC connection.</li> of the first QUIC connection.</li>
<li>The "negotiated version" is the QUIC version in use on the connect ion once the <li>The "Negotiated Version" is the QUIC version in use on the connect ion once the
version negotiation process completes.</li> version negotiation process completes.</li>
<li>The "Maximum Segment Lifetime" (MSL) represents the time a QUIC pa cket can <li>The "Maximum Segment Lifetime" (MSL) represents the time a QUIC pa cket can
exist in the network. Implementations can make this configurable, and a exist in the network. Implementations can make this configurable, and a
<bcp14>RECOMMENDED</bcp14> value is one minute. Note that the term "segment" her e originated <bcp14>RECOMMENDED</bcp14> value is one minute. Note that the term "segment" her e originated
in <xref section="3.4.1" sectionFormat="of" target="TCP"/>.</li> in <xref section="3.4.1" sectionFormat="of" target="RFC9293"/>.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="version-negotiation-mechanism"> <section anchor="version-negotiation-mechanism">
<name>Version Negotiation Mechanism</name> <name>Version Negotiation Mechanism</name>
<t>This document specifies two means of performing version negotiation: on <t>This document specifies two means of performing version negotiation:
e 1) "incompatible", which requires a round trip and is applicable to all versions
"incompatible" which requires a round trip and is applicable to all versions, ,
and one "compatible" that allows saving the round trip but only applies when the and 2) "compatible", which allows saving the round trip but only applies when th
e
versions are compatible (see <xref target="compat"/>).</t> versions are compatible (see <xref target="compat"/>).</t>
<t>The client initiates a QUIC connection by choosing an original version and <t>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 sending a first flight of QUIC packets with a long header to the server
<xref target="QUIC-INVARIANTS"/>. The client's first flight includes Version Inf <xref target="RFC8999"/>. The client's first flight includes Version Information
ormation (see (see
<xref target="vers-info"/>) which will be used to optionally enable compatible v <xref target="vers-info"/>), which will be used to optionally enable compatible
ersion version
negotiation (see <xref target="compat-vn"/>), and to prevent version downgrade a negotiation (see <xref target="compat-vn"/>) and to prevent version downgrade at
ttacks (see tacks (see
<xref target="downgrade"/>).</t> <xref target="downgrade"/>).</t>
<t>Upon receiving this first flight, the server verifies whether it knows how to <t>Upon receiving this first flight, the server verifies whether it knows how to
parse first flights from the original version. If it does not, then it starts parse first flights from the Chosen Version (which is also the Original Version
incompatible version negotiation, see <xref target="incompat-vn"/>, which causes in this case). If it does not, then it starts
the client incompatible version negotiation (see <xref target="incompat-vn"/>), which cause
s the client
to initiate a new connection with a different version. For instance, if the to initiate a new connection with a different version. For instance, if the
client initiates a connection with version A and the server starts incompatible client initiates a
version negotiation and the client then initiates a new connection with version connection with version A that the server can't parse, the server
B, we say that the first connection's client chosen version is A, the second starts incompatible version negotiation; then, when the client
connection's client chosen version is B, and the original version for the entire 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.</t> sequence is A.</t>
<t>If the server can parse the first flight, it can either establish the c <t>If the server can parse the first flight, it can establish the connecti
onnection on
using the client's chosen version, or it <bcp14>MAY</bcp14> select any other com using the client's Chosen Version, or it <bcp14>MAY</bcp14> select any other com
patible patible
version, as described in <xref target="compat-vn"/>.</t> version, as described in <xref target="compat-vn"/>.</t>
<t>Note that it is possible for a server to have the ability to parse the first <t>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 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 implements enough of the version's specification to parse first flight packets
but not enough to fully establish a connection using that version.</t> but not enough to fully establish a connection using that version.</t>
<section anchor="incompat-vn"> <section anchor="incompat-vn">
<name>Incompatible Version Negotiation</name> <name>Incompatible Version Negotiation</name>
<t>The server starts incompatible version negotiation by sending a Versi on <t>The server starts incompatible version negotiation by sending a Versi on
Negotiation packet. This packet <bcp14>SHALL</bcp14> include each entry from the server's set Negotiation packet. This packet <bcp14>SHALL</bcp14> include each entry from the server's set
of Offered Versions (see <xref target="server-fleet"/>) in a Supported Version f ield. The of Offered Versions (see <xref target="server-fleet"/>) in a Supported Version f ield. The
server <bcp14>MAY</bcp14> add reserved versions (as defined in <xref section="6. 3" sectionFormat="of" target="QUIC"/>) in server <bcp14>MAY</bcp14> add reserved versions (as defined in <xref section="6. 3" sectionFormat="of" target="RFC9000"/>) in
Supported Version fields.</t> Supported Version fields.</t>
<t>Clients will ignore a Version Negotiation packet if it contains the o <t>Clients will ignore a Version Negotiation packet if it contains the O
riginal riginal
version attempted by the client; see <xref target="downgrade"/>. The client also Version attempted by the client, as required by <xref target="downgrade"/>. The
ignores a client also ignores a
Version Negotiation packet that contains incorrect connection ID fields; see Version Negotiation packet that contains incorrect connection ID fields, as requ
<xref section="6" sectionFormat="of" target="QUIC-INVARIANTS"/>.</t> ired by
<xref section="6" sectionFormat="of" target="RFC8999"/>.</t>
<t>Upon receiving the Version Negotiation packet, the client <bcp14>SHAL L</bcp14> search for a <t>Upon receiving the Version Negotiation packet, the client <bcp14>SHAL L</bcp14> search for a
version it supports in the list provided by the server. If it doesn't find one, version it supports in the list provided by the server. If it doesn't find one,
it <bcp14>SHALL</bcp14> abort the connection attempt. Otherwise, it <bcp14>SHALL </bcp14> select a mutually it <bcp14>SHALL</bcp14> abort the connection attempt. Otherwise, it <bcp14>SHALL </bcp14> select a mutually
supported version and send a new first flight with that version - this version supported version and send a new first flight with that version -- this version
is now the negotiated version.</t> is now the Negotiated Version.</t>
<t>The new first flight will allow the endpoints to establish a connecti on using <t>The new first flight will allow the endpoints to establish a connecti on using
the negotiated version. The handshake of the negotiated version will exchange the Negotiated Version. The handshake of the Negotiated Version will exchange
version information (see <xref target="vers-info"/>) required to ensure that ver Version Information (see <xref target="vers-info"/>) that is required to ensure
sion that version
negotiation was genuine, i.e. that no attacker injected packets in order to negotiation was genuine, i.e., that no attacker injected packets in order to
influence the version negotiation process, see <xref target="downgrade"/>.</t> influence the version negotiation process (see <xref target="downgrade"/>).</t>
<t>Only servers can start incompatible version negotiation: clients <bcp <t>Only servers can start incompatible version negotiation. Clients <bcp
14>MUST NOT</bcp14> send 14>MUST NOT</bcp14> send
Version Negotiation packets and servers <bcp14>MUST</bcp14> ignore all received Version Version Negotiation packets and servers <bcp14>MUST</bcp14> ignore all received Version
Negotiation packets.</t> Negotiation packets.</t>
</section> </section>
<section anchor="compat"> <section anchor="compat">
<name>Compatible Versions</name> <name>Compatible Versions</name>
<t>If A and B are two distinct versions of QUIC, A is said to be "compat ible" with <t>If A and B are two distinct versions of QUIC, A is said to be "compat ible" with
B if it is possible to take a first flight of packets from version A and convert 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 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 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 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 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 such as QUIC version 1 0-RTT packets, could be ignored during conversion and
retransmitted later.</t> retransmitted later.</t>
<t>Version compatibility is not symmetric: it is possible for version A <t>Version compatibility is not symmetric. It is possible for version A
to be to be
compatible with version B and for B not to be compatible with A. This could compatible with version B and for version B not to be compatible with version A.
happen for example if version B is a strict superset of version A: if version A This could
includes the concept of streams and STREAM frames, and version B includes the happen, for example, if version B is a strict superset of version A, i.e., if ve
rsion 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 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 TUBE frames, then A would be compatible with B, but B would not be compatible
with A.</t> with A.</t>
<t>Note that version compatibility does not mean that every single possi ble <t>Note that version compatibility does not mean that every single possi ble
instance of a first flight will succeed in conversion to the other version. A 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 first flight using version A is said to be "compatible" with version B if two
conditions are met: first that version A is compatible with version B, and conditions are met: (1) version A is compatible with version B and
second that the conversion of this first flight to version B is well-defined. (2) the conversion of this first flight to version B is well defined.
For example, if version B is equal to A in all aspects except it introduced a For example, if version B is equal to version A in all aspects except it introdu
new frame in its first flight that version A cannot parse or even ignore, then B ced a
could still be compatible with A as conversions would succeed for connections new frame in its first flight that version A cannot parse or even ignore, then v
ersion B
could still be compatible with version A, as conversions would succeed for conne
ctions
where that frame is not used. In this example, first flights using version B 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.</t> that carry this new frame would not be compatible with version A.</t>
<t>When a new version of QUIC is defined, it is assumed to not be compat ible with <t>When a new version of QUIC is defined, it is assumed to not be compat ible with
any other version unless otherwise specified. Similarly, no other version is any other version unless otherwise specified. Similarly, no other version is
compatible with the new version unless otherwise specified. Implementations <bcp 14>MUST compatible with the new version unless otherwise specified. Implementations <bcp 14>MUST
NOT</bcp14> assume compatibility between versions unless explicitly specified.</ t> NOT</bcp14> assume compatibility between versions unless explicitly specified.</ t>
<t>Note that both endpoints might disagree on whether two versions are c ompatible <t>Note that both endpoints might disagree on whether two versions are c ompatible
or not. For example, two versions could have been defined concurrently and then 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 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.</ endpoint might be aware of the compatibility document, while the other may not.<
t> /t>
</section> </section>
<section anchor="compat-vn"> <section anchor="compat-vn">
<name>Compatible Version Negotiation</name> <name>Compatible Version Negotiation</name>
<t>When the server can parse the client's first flight using the client' <t>When the server can parse the client's first flight using the client'
s chosen s Chosen
version, it can extract the client's Version Information structure (see Version, it can extract the client's Version Information structure (see
<xref target="vers-info"/>). This contains the list of versions that the client knows its <xref target="vers-info"/>). This contains the list of versions that the client knows its
first flight is compatible with.</t> first flight is compatible with.</t>
<t>In order to perform compatible version negotiation, the server <bcp14 >MUST</bcp14> select one <t>In order to perform compatible version negotiation, the server <bcp14 >MUST</bcp14> select one
of these versions that (1) it supports and (2) it knows the client's chosen of these versions that it (1) supports and (2) knows the client's Chosen
version to be compatible with. This selected version is now the negotiated Version is compatible with. This selected version is now the Negotiated
version. After selecting it, the server attempts to convert the client's first 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 flight into that version and replies to the client as if it had received the
converted first flight.</t> converted first flight.</t>
<t>If those formats are identical, as in cases where the negotiated vers <t>If those formats are identical, as in cases where the Negotiated Vers
ion is the ion is the
same as the client's chosen version, then this will be the identity transform. same as the client's Chosen Version, then this will be the identity transformati
on.
If the first flight is correctly formatted, then this conversion process cannot 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 fail by definition of the first flight being compatible; if the server is unable
to convert the first flight, it <bcp14>MUST</bcp14> abort the handshake.</t> to convert the first flight, it <bcp14>MUST</bcp14> abort the handshake.</t>
<t>If a document specifies that a QUIC version is compatible with anothe r, that <t>If a document specifies that a QUIC version is compatible with anothe r, that
document <bcp14>MUST</bcp14> specify the mechanism by which clients are made awa re of the document <bcp14>MUST</bcp14> specify the mechanism by which clients are made awa re of the
negotiated version. An example of such a mechanism is to have the client 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 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 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 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 switching to the Negotiated Version (this can happen when the client's Version
Information structure spans multiple packets; in that case the server might 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 acknowledge the first packet in the client's Chosen Version and later switch to
a different negotiated version). Mutually compatible versions <bcp14>SHOULD</bcp a different Negotiated Version). Mutually compatible versions <bcp14>SHOULD</bcp
14> use the 14> use the
same mechanism.</t> same mechanism.</t>
<t>Note that, after the first flight is converted to the negotiated vers <t>Note that, after the first flight is converted to the Negotiated Vers
ion, the ion, the
handshake completes in the negotiated version. If the negotiated version has handshake completes in the Negotiated Version. If the Negotiated Version has
requirements that apply during the handshake, those requirements apply to the requirements that apply during the handshake, those requirements apply to the
entire handshake, including the converted first flight. In particular, if the entire handshake, including the converted first flight. In particular, if the
negotiated version mandates that endpoints perform validations on handshake Negotiated Version mandates that endpoints perform validations on Handshake
packets, endpoints <bcp14>MUST</bcp14> also perform such validations on the conv erted first packets, endpoints <bcp14>MUST</bcp14> also perform such validations on the conv erted first
flight. For instance, if the negotiated version requires that the 5-tuple remain 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 stable for the entire handshake (as QUIC version 1 does), then both endpoints n
need to validate the 5-tuple of all handshake packets, including the converted eed to validate the 5-tuple of all packets received during the handshake, includ
first flight.</t> ing the converted first flight.</t>
<t>Note also that the client can disable compatible version negotiation by only <t>Note also that the client can disable compatible version negotiation by only
including the Chosen Version in the Available Versions field of the Version including the Chosen Version in the Available Versions field of the Version
Information; see <xref target="vers-info"/>.</t> Information (see <xref target="vers-info"/>).</t>
<t>If the server does not find a compatible version (including the clien <t>If the server does not find a compatible version (including the clien
t's chosen t's Chosen
version), it will perform incompatible version negotiation instead, see Version), it will perform incompatible version negotiation instead (see
<xref target="incompat-vn"/>.</t> <xref target="incompat-vn"/>).</t>
<t>Note that it is possible to have incompatible version negotiation fol lowed by <t>Note that it is possible to have incompatible version negotiation fol lowed by
compatible version negotiation. For instance, if version A is compatible with B compatible version negotiation. For instance, if version A is compatible with ve
and C is compatible with D, the following scenario could occur:</t> rsion B
and version C is compatible with version D, the following scenario could occur:<
/t>
<figure anchor="fig-dual-example"> <figure anchor="fig-dual-example">
<name>Combined Negotiation Example</name> <name>Combined Negotiation Example</name>
<artwork><![CDATA[ <artwork><![CDATA[
Client Server Client Server
Chosen = A, Available Versions = (A, B) -------------> Chosen = A, Available Versions = (A, B) ------------->
<------------------------ Version Negotiation = (D, C) <------------------------ Version Negotiation = (D, C)
Chosen = C, Available Versions = (C, D) -------------> Chosen = C, Available Versions = (C, D) ------------->
<------------- Chosen = D, Available Versions = (D, C) <------------- Chosen = D, Available Versions = (D, C)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>In this example, the client selected C from the server's Version Nego tiation <t>In this example, the client selected C from the server's Version Nego tiation
packet, but the server preferred D and then selected it from the client's offer. </t> packet, but the server preferred D and then selected it from the client's offer. </t>
</section> </section>
<section anchor="connections"> <section anchor="connections">
<name>Connections and Version Negotiation</name> <name>Connections and Version Negotiation</name>
<t>QUIC connections are shared state between a client and a server <t>QUIC connections are shared state between a client and a server
<xref target="QUIC-INVARIANTS"/>. The compatible version negotiation mechanism d efined in <xref target="RFC8999"/>. The compatible version negotiation mechanism defined i n
this document (see <xref target="compat-vn"/>) is performed as part of a single QUIC this document (see <xref target="compat-vn"/>) is performed as part of a single QUIC
connection; that is, the packets with the client's chosen version are part of connection; that is, the packets with the client's Chosen Version are part of
the same connection as the packets with the negotiated version.</t> the same connection as the packets with the Negotiated Version.</t>
<t>In comparison, the incompatible version negotiation mechanism, which leverages <t>In comparison, the incompatible version negotiation mechanism, which leverages
QUIC Version Negotiation packets (see <xref target="incompat-vn"/>) conceptually QUIC Version Negotiation packets (see <xref target="incompat-vn"/>), conceptuall
operates y operates
across two QUIC connections: the connection attempt prior to receiving the 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 Negotiation packet is distinct from the connection with the incompatible
version that follows.</t> version that follows.</t>
<t>Note that this separation across two connections is conceptual: it ap <t>Note that this separation across two connections is conceptual, i.e.,
plies to it applies to
normative requirements on QUIC connections, but does not require implementations normative requirements on QUIC connections, but it does not require implementati
ons
to internally use two distinct connection objects.</t> to internally use two distinct connection objects.</t>
</section> </section>
<section anchor="client-choice-of-original-version"> <section anchor="client-choice-of-original-version">
<name>Client Choice of Original Version</name> <name>Client Choice of Original Version</name>
<t>When the client picks its original version, it will try to avoid inco mpatible <t>When the client picks its Original Version, it <bcp14>SHOULD</bcp14> try to avoid incompatible
version negotiation to save a round trip. Therefore, the client <bcp14>SHOULD</b cp14> pick an version negotiation to save a round trip. Therefore, the client <bcp14>SHOULD</b cp14> pick an
original version to maximize the combined probability that both:</t> Original Version to maximize the combined probability that both:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The server knows how to parse first flights from the original vers <li>the server knows how to parse first flights from the Original Vers
ion.</li> ion and</li>
<li>The original version is compatible with the client's preferred ver <li>the Original Version is compatible with the client's preferred ver
sion.</li> sion.</li>
</ul> </ul>
<t>Without additional information, this could mean selecting the oldest version <t>Without additional information, this could mean selecting the oldest version
that the client supports, while advertising newer compatible versions in the that the client supports while advertising newer compatible versions in the
client's first flight.</t> client's first flight.</t>
</section> </section>
</section> </section>
<section anchor="vers-info"> <section anchor="vers-info">
<name>Version Information</name> <name>Version Information</name>
<t>During the handshake, endpoints will exchange Version Information, whic h <t>During the handshake, endpoints will exchange Version Information, whic h
consists of a chosen version and a list of available versions. Any version of consists of a Chosen Version and a list of Available Versions. Any version of
QUIC that supports this mechanism <bcp14>MUST</bcp14> provide a mechanism to exc hange Version QUIC that supports this mechanism <bcp14>MUST</bcp14> provide a mechanism to exc hange Version
Information in both directions during the handshake, such that this data is Information in both directions during the handshake, such that this data is
authenticated.</t> authenticated.</t>
<t>In QUIC version 1, the Version Information is transmitted using a new <t>In QUIC version 1, the Version Information is transmitted using a new
"version_information" transport parameter; see <xref section="7.4" sectionFormat version_information transport parameter (see <xref section="7.4" sectionFormat="
="of" target="QUIC"/>. The of" target="RFC9000"/>). The
contents of Version Information are shown below (using the notation from the contents of Version Information are shown below (using the notation from <xref t
"Notational Conventions" section of <xref target="QUIC"/>):</t> arget="RFC9000" section="1.3" sectionFormat="of"/>):</t>
<figure anchor="fig-vi-format"> <figure anchor="fig-vi-format">
<name>Version Information Format</name> <name>Version Information Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
Version Information { Version Information {
Chosen Version (32), Chosen Version (32),
Available Versions (32) ..., Available Versions (32) ...,
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The content of each field is described below:</t> <t>The content of each field is described below:</t>
<dl> <dl>
<dt>Chosen Version:</dt> <dt>Chosen Version:</dt>
<dd> <dd>
<t>The version that the sender has chosen to use for this connection. In most <t>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 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 header that carries this data; however, future versions or extensions can choose
to set different values in the long header Version field.</t> to set different values in the long header Version field.</t>
</dd> </dd>
</dl> </dl>
<t>The contents of the Available Versions field depends on whether it is s ent by <t>The contents of the Available Versions field depend on whether it is se nt by
the client or by the server.</t> the client or by the server.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Client-Sent Available Versions:</dt> <dt>Client-Sent Available Versions:</dt>
<dd> <dd>
<t>When sent by a client, the Available Versions field lists all the v ersions <t>When sent by a client, the Available Versions field lists all the v ersions
that this first flight is compatible with, ordered by descending preference. that this first flight is compatible with, ordered by descending preference.
Note that the version in the Chosen Version field <bcp14>MUST</bcp14> be include d in this list Note that the version in the Chosen Version field <bcp14>MUST</bcp14> be include d in this list
to allow the client to communicate the chosen version's preference. Note that to allow the client to communicate the Chosen Version's preference. Note that
this preference is only advisory, servers <bcp14>MAY</bcp14> choose to use their this preference is only advisory; servers <bcp14>MAY</bcp14> choose to use their
own preference own preference
instead.</t> instead.</t>
</dd> </dd>
<dt>Server-Sent Available Versions:</dt> <dt>Server-Sent Available Versions:</dt>
<dd> <dd>
<t>When sent by a server, the Available Versions field lists all the <t>When sent by a server, the Available Versions field lists all the
Fully-Deployed Versions of this server deployment, see <xref target="server-flee t"/>. The Fully Deployed Versions of this server deployment (see <xref target="server-flee t"/>). The
ordering of the versions in this field does not carry any semantics. Note 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 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 list, because the server operator could be in the process of removing support
for this version. For the same reason, the Available Versions field <bcp14>MAY</ bcp14> be empty.</t> for this version. For the same reason, the Available Versions field <bcp14>MAY</ bcp14> be empty.</t>
</dd> </dd>
</dl> </dl>
<t>Clients and servers <bcp14>MAY</bcp14> both include versions following the pattern 0x?a?a?a?a <t>Clients and servers <bcp14>MAY</bcp14> both include versions following the pattern 0x?a?a?a?a
in their Available Versions list. Those versions are reserved to exercise in their Available Versions list. Those versions are reserved to exercise
version negotiation (see the Versions section of <xref target="QUIC"/>), and wil l never be version negotiation (see <xref target="RFC9000" section="15" sectionFormat="of"/ >) and will never be
selected when choosing a version to use.</t> selected when choosing a version to use.</t>
</section> </section>
<section anchor="downgrade"> <section anchor="downgrade">
<name>Version Downgrade Prevention</name> <name>Version Downgrade Prevention</name>
<t>A version downgrade is an attack where a malicious entity manages to ma ke the <t>A version downgrade is an attack where a malicious entity manages to ma ke the
QUIC endpoints negotiate a QUIC version different from the one they would have 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 negotiated in the absence of the attack. The mechanism described in this
document is designed to prevent downgrade attacks.</t> document is designed to prevent downgrade attacks.</t>
<t>Clients <bcp14>MUST</bcp14> ignore any received Version Negotiation pac kets that contain the <t>Clients <bcp14>MUST</bcp14> ignore any received Version Negotiation pac kets that contain the
original version. A client that makes a connection attempt based on information Original Version. A client that makes a connection attempt based on information
received from a Version Negotiation packet <bcp14>MUST</bcp14> ignore any Versio n Negotiation received from a Version Negotiation packet <bcp14>MUST</bcp14> ignore any Versio n Negotiation
packets it receives in response to that connection attempt.</t> packets it receives in response to that connection attempt.</t>
<t>Both endpoints <bcp14>MUST</bcp14> parse their peer's Version Informati on during the handshake. <t>Both endpoints <bcp14>MUST</bcp14> parse their peer's Version Informati on during the handshake.
If that leads to a parsing failure (for example, if it is too short or if 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 <bcp14>MUST</bcp14> clos e the its length is not divisible by four), then the endpoint <bcp14>MUST</bcp14> clos e the
connection; if the connection was using QUIC version 1, that connection closure connection; if the connection was using QUIC version 1, that connection closure
<bcp14>MUST</bcp14> use a transport error of type TRANSPORT_PARAMETER_ERROR. If an endpoint <bcp14>MUST</bcp14> 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, receives a Chosen Version equal to zero, or any Available Version equal to zero,
it <bcp14>MUST</bcp14> treat it as a parsing failure. If a server receives a Ver sion it <bcp14>MUST</bcp14> treat it as a parsing failure. If a server receives Versi on
Information where the Chosen Version is not included in Available Versions, it Information where the Chosen Version is not included in Available Versions, it
<bcp14>MUST</bcp14> treat it as a parsing failure.</t> <bcp14>MUST</bcp14> treat it as a parsing failure.</t>
<t>Every QUIC version that supports version negotiation <bcp14>MUST</bcp14 > define a method for <t>Every QUIC version that supports version negotiation <bcp14>MUST</bcp14 > define a method for
closing the connection with a version negotiation error. For QUIC version 1, 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 errors are signaled using a transport error of type
VERSION_NEGOTIATION_ERROR; see <xref target="iana-error"/>.</t> VERSION_NEGOTIATION_ERROR (see <xref target="iana-error"/>).</t>
<t>When a server receives a client's first flight, the server will first e stablish <t>When a server receives a client's first flight, the server will first e stablish
which QUIC version is in use for this connection in order to properly parse the which QUIC version is in use for this connection in order to properly parse the
first flight. For example, the server determines that QUIC version 1 is in use first flight. This may involve examining data that is not part of the handshake
by observing that the Version field of the first Long Header packet it receives transcript, such as parts of the packet header. When the server then processes t
is set to 0x00000001. When the server then processes the client's Version he client's Version
Information, the server <bcp14>MUST</bcp14> validate that the client's Chosen Ve rsion matches Information, the server <bcp14>MUST</bcp14> validate that the client's Chosen Ve rsion matches
the version in use for the connection. If the two differ, the server <bcp14>MUST </bcp14> close the version in use for the connection. If the two differ, the server <bcp14>MUST </bcp14> close
the connection with a version negotiation error. For example, if a server the connection with a version negotiation error.</t>
<t>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 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 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 parameters) and the client's Chosen Version is not set to 0x00000001, the server
will close the connection with a version negotiation error.</t> <bcp14>MUST</bcp14> close the connection with a version negotiation error.</t>
<t>If a client receives a Version Information where the server's Chosen Ve <t>Servers <bcp14>MAY</bcp14> complete the handshake even if the Version Informa
rsion was tion is missing. Clients <bcp14>MUST NOT</bcp14> complete the handshake if they
are reacting to a Version Negotiation packet and the Version Information is mis
sing, but <bcp14>MAY</bcp14> do so otherwise.</t>
<t>If a client receives Version Information where the server's Chosen Vers
ion was
not sent by the client as part of its Available Versions, the client <bcp14>MUST </bcp14> close not sent by the client as part of its Available Versions, the client <bcp14>MUST </bcp14> close
the connection with a version negotiation error.</t> the connection with a version negotiation error. If a client has reacted to a Ve
<t>If the Version Information was missing, the endpoints <bcp14>MAY</bcp14 rsion Negotiation packet and the server's Version Information was missing, the c
> complete the lient <bcp14>MUST</bcp14> close the connection with a version negotiation error.
handshake. However, if a client has reacted to a Version Negotiation packet and </t>
the Version Information was missing, the client <bcp14>MUST</bcp14> close the co
nnection with a
version negotiation error.</t>
<t>If the client received and acted on a Version Negotiation packet, the c lient <t>If the client received and acted on a Version Negotiation packet, the c lient
<bcp14>MUST</bcp14> validate the server's Available Versions field. The Availabl e Versions <bcp14>MUST</bcp14> validate the server's Available Versions field. The Availabl e Versions
field is validated by confirming that the client would have attempted the same 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 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 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 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 Negotiated Version. If the client would have selected a different version, the
client <bcp14>MUST</bcp14> close the connection with a version negotiation error . In client <bcp14>MUST</bcp14> close the connection with a version negotiation error . In
particular, if the client reacted to a Version Negotiation packet and the particular, if the client reacted to a Version Negotiation packet and the
server's Available Versions field is empty, the client <bcp14>MUST</bcp14> close the connection server's Available Versions field is empty, the client <bcp14>MUST</bcp14> close the connection
with a version negotiation error. These connection closures prevent an attacker with a version negotiation error. These connection closures prevent an attacker
from being able to use forged Version Negotiation packets to force a version from being able to use forged Version Negotiation packets to force a version
downgrade.</t> downgrade.</t>
<t>As an example, let's assume a client supports hypothetical QUIC version s 10, 12, <t>As an example, let's assume a client supports hypothetical QUIC version s 10, 12,
and 14 with a preference for higher versions. The client initiates a connection and 14 with a preference for higher versions. The client initiates a connection
attempt with version 12. Let's explore two independent example scenarios:</t> attempt with version 12. Let's explore two independent example scenarios:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>In the first scenario, the server supports versions 10, 13, and 14 b <li>In the first scenario, the server supports versions 10, 13, and 14,
ut only 13 but only 13
and 14 are Fully-Deployed (see <xref target="server-fleet"/>). The server sends and 14 are Fully Deployed (see <xref target="server-fleet"/>). The server sends
a Version a Version
Negotiation packet with versions 10, 13, and 14. This triggers an incompatible Negotiation packet with versions 10, 13, and 14. This triggers an incompatible
version negotiation and the client initiates a new connection with version 14. 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 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 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 Negotiation packet with versions 13 and 14; therefore, the handshake succeeds
using negotiated version 14.</li> using Negotiated Version 14.</li>
<li>In the second scenario, the server supports versions 10, 13, and 14 <li>In the second scenario, the server supports versions 10, 13, and 14,
and they and they
are all Fully-Deployed. However, the attacker forges a Version Negotiation are all Fully Deployed. However, the attacker forges a Version Negotiation
packet with versions 10 and 13. This triggers an incompatible version packet with versions 10 and 13. This triggers an incompatible version
negotiation and the client initiates a new connection with version 10. Then 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 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 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 Version Negotiation packet with versions 10, 13, and 14; therefore, the client
aborts the handshake with a version negotiation error.</li> aborts the handshake with a version negotiation error.</li>
</ul> </ul>
<t>This validation of Available Versions is not sufficient to prevent down grade. <t>This validation of Available Versions is not sufficient to prevent down grade.
Downgrade prevention also depends on the client ignoring Version Negotiation Downgrade prevention also depends on the client ignoring Version Negotiation
packets that contain the original version; see <xref target="incompat-vn"/>.</t> packets that contain the Original Version (see <xref target="incompat-vn"/>).</t
<t>After the process of version negotiation in this document completes, th >
e version <t>After the process of version negotiation described in this document com
pletes, the version
in use for the connection is the version that the server sent in the Chosen 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 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 versions were used in the Version field of long headers at any point in the
lifetime of the connection. In particular, since during compatible version lifetime of the connection. In particular, since the client can be made aware of
negotiation the client is made aware of the negotiated version by the QUIC long the Negotiated Version by the QUIC long
header version (see <xref target="compat-vn"/>), clients <bcp14>MUST</bcp14> val header version during compatible version negotiation (see <xref target="compat-
idate that the server's vn"/>), clients <bcp14>MUST</bcp14> validate that the server's
Chosen Version is equal to the negotiated version; if they do not match, the Chosen Version is equal to the Negotiated Version; if they do not match, the
client <bcp14>MUST</bcp14> close the connection with a version negotiation error . This prevents client <bcp14>MUST</bcp14> close the connection with a version negotiation error . This prevents
an attacker's ability to influence version negotiation by forging the Version an attacker's ability to influence version negotiation by forging the long heade
long header field.</t> r Version
field.</t>
</section> </section>
<section anchor="server-fleet"> <section anchor="server-fleet">
<name>Server Deployments of QUIC</name> <name>Server Deployments of QUIC</name>
<t>While this document mainly discusses a single QUIC server, it is common for <t>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. We deployments of QUIC servers to include a fleet of multiple server instances.
therefore define the following terms:</t> Therefore, we define the following terms:</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Acceptable Versions:</dt> <dt>Acceptable Versions:</dt>
<dd> <dd>
<t>This is the set of versions supported by a given server instance. M ore <t>This is the set of versions supported by a given server instance. M ore
specifically, these are the versions that a given server instance will use if a specifically, these are the versions that a given server instance will use if a
client sends a first flight using them.</t> client sends a first flight using them.</t>
</dd> </dd>
<dt>Offered Versions:</dt> <dt>Offered Versions:</dt>
<dd> <dd>
<t>This is the set of versions that a given server instance will send in a <t>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 Negotiation packet if it receives a first flight from an unknown
version. This set will most often be equal to the Acceptable Versions set, 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). </t> except during short transitions while versions are added or removed (see below). </t>
</dd> </dd>
<dt>Fully-Deployed Versions:</dt> <dt>Fully Deployed Versions:</dt>
<dd> <dd>
<t>This is the set of QUIC versions that is supported and negotiated b y every <t>This is the set of QUIC versions that is supported and negotiated b y every
single QUIC server instance in this deployment. If a deployment only contains a 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, 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). </t> except during short transitions while versions are added or removed (see below). </t>
</dd> </dd>
</dl> </dl>
<t>If a deployment contains multiple server instances, software updates ma y not <t>If a deployment contains multiple server instances, software updates ma y not
happen at exactly the same time on all server instances. Because of this, a 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 client might receive a Version Negotiation packet from a server instance that
has already been updated and the client's resulting connection attempt might has already been updated, and the client's resulting connection attempt might
reach a different server instance which hasn't been updated yet.</t> reach a different server instance which hasn't been updated yet.</t>
<t>However, even when there is only a single server instance, it is still possible <t>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 to receive a stale Version Negotiation packet if the server performs its
software update while the Version Negotiation packet is in flight.</t> software update while the Version Negotiation packet is in flight.</t>
<t>This could cause the version downgrade prevention mechanism described i n <t>This could cause the version downgrade prevention mechanism described i n
<xref target="downgrade"/> to falsely detect a downgrade attack. To avoid that, server <xref target="downgrade"/> to falsely detect a downgrade attack. To avoid that, server
operators <bcp14>SHOULD</bcp14> perform a three-step process when they wish to a dd or remove operators <bcp14>SHOULD</bcp14> perform a three-step process when they wish to a dd or remove
support for a version:</t> support for a version, as described below.</t>
<t>When adding support for a new version:</t> <t>When adding support for a new version:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The first step is to progressively add support for the new version t o all <li>The first step is to progressively add support for the new version t o all
server instances. This step updates the Acceptable Versions but not the server instances. This step updates the Acceptable Versions but not the
Offered Versions nor the Fully-Deployed Versions. Once all server instances 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 have been updated, operators wait for at least one MSL to allow any in-flight
Version Negotiation packets to arrive.</li> Version Negotiation packets to arrive.</li>
<li>Then, the second step is to progressively add the new version to Off ered <li>Then, the second step is to progressively add the new version to Off ered
Versions on all server instances. Once complete, operators wait for at least Versions on all server instances. Once complete, operators wait for at least
another MSL.</li> another MSL.</li>
<li>Finally, the third step is to progressively add the new version to <li>Finally, the third step is to progressively add the new version to
Fully-Deployed Versions on all server instances.</li> Fully Deployed Versions on all server instances.</li>
</ul> </ul>
<t>When removing support for a version:</t> <t>When removing support for a version:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The first step is to progressively remove the version from Fully-Dep loyed <li>The first step is to progressively remove the version from Fully Dep loyed
Versions on all server instances. Once it has been removed on all server 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 instances, operators wait for at least one MSL to allow any in-flight Version
Negotiation packets to arrive.</li> Negotiation packets to arrive.</li>
<li>Then, the second step is to progressively remove the version from Of fered <li>Then, the second step is to progressively remove the version from Of fered
Versions on all server instances. Once complete, operators wait for at least Versions on all server instances. Once complete, operators wait for at least
another MSL.</li> another MSL.</li>
<li>Finally, the third step is to progressively remove support for the v ersion <li>Finally, the third step is to progressively remove support for the v ersion
from all server instances. That step updates the Acceptable Versions.</li> from all server instances. That step updates the Acceptable Versions.</li>
</ul> </ul>
<t>Note that, during the update window, connections are vulnerable to down <t>Note that, during the update window, connections are vulnerable to
grade downgrade attacks for Acceptable Versions that are not Fully
attacks for partially-deployed versions. This is because a client cannot Deployed. This is because a client cannot distinguish such a
distinguish such a downgrade attack from legitimate exchanges with both updated downgrade attack from legitimate exchanges with both updated and
and non-updated server instances.</t> non-updated server instances.</t>
</section> </section>
<section anchor="application-layer-protocol-considerations"> <section anchor="application-layer-protocol-considerations">
<name>Application Layer Protocol Considerations</name> <name>Application-Layer Protocol Considerations</name>
<t>When a client creates a QUIC connection, its goal is to use an applicat <t>When a client creates a QUIC connection, its goal is to use an applicat
ion layer ion-layer
protocol. Therefore, when considering which versions are compatible, clients protocol. Therefore, when considering which versions are compatible, clients
will only consider versions that support one of the intended application layer will only consider versions that support one of the intended application-layer
protocols. If the client's first flight advertises multiple Application Layer protocols. If the client's first flight advertises multiple Application-Layer
Protocol Negotiation (ALPN) <xref target="ALPN"/> tokens and multiple compatible Protocol Negotiation (ALPN) <xref target="RFC7301"/> tokens and multiple compati
versions, it is possible for some application layer protocols to not be able to ble
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 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 responsibility to only select an ALPN token that can run over the compatible
QUIC version that it selects.</t> QUIC version that it selects.</t>
<t>A given ALPN token <bcp14>MUST NOT</bcp14> be used with a new QUIC vers ion different from the <t>A given ALPN token <bcp14>MUST NOT</bcp14> be used with a new QUIC vers ion that is different from the
version for which the ALPN token was originally defined, unless all the version for which the ALPN token was originally defined, unless all the
following requirements are met:</t> following requirements are met:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The new QUIC version supports the transport features required by the <li>The new QUIC version supports the transport features required by the
application protocol.</li> application protocol.</li>
<li>The new QUIC version supports ALPN.</li> <li>The new QUIC version supports ALPN.</li>
<li>The version of QUIC for which the ALPN token was originally defined is <li>The version of QUIC for which the ALPN token was originally defined is
compatible with the new QUIC version.</li> compatible with the new QUIC version.</li>
</ul> </ul>
<t>When incompatible version negotiation is in use, the second connection <t>When incompatible version negotiation is in use, the second connection
which is that is
created in response to the received version negotiation packet <bcp14>MUST</bcp1 created in response to the received Version
4> restart its Negotiation packet <bcp14>MUST</bcp14> restart its application-layer proto
application layer protocol negotiation process without taking into account the col
original version.</t> negotiation process without taking into account the Original Version.</t>
</section> </section>
<section anchor="considerations-for-future-versions"> <section anchor="considerations-for-future-versions">
<name>Considerations for Future Versions</name> <name>Considerations for Future Versions</name>
<t>In order to facilitate the deployment of future versions of QUIC, desig ners of <t>In order to facilitate the deployment of future versions of QUIC, desig ners of
future versions <bcp14>SHOULD</bcp14> attempt to design their new version such t hat commonly future versions <bcp14>SHOULD</bcp14> attempt to design their new version such t hat commonly
deployed versions are compatible with it.</t> deployed versions are compatible with it.</t>
<t>QUIC version 1 defines multiple features which are not documented in th e QUIC <t>QUIC version 1 defines multiple features which are not documented in th e QUIC
invariants. Since, at the time of writing, QUIC version 1 is widely deployed, invariants. Since, at the time of writing, QUIC version 1 is widely deployed,
this section discusses considerations for future versions to help with this section discusses considerations for future versions to help with
compatibility with QUIC version 1.</t> compatibility with QUIC version 1.</t>
<section anchor="interaction-with-retry"> <section anchor="interaction-with-retry">
<name>Interaction with Retry</name> <name>Interaction with Retry</name>
<t>QUIC version 1 features Retry packets, which the server can send to v alidate the <t>QUIC version 1 features Retry packets, which the server can send to v alidate the
client's IP address before parsing the client's first flight. A server that 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. A sends a Retry packet can do so before parsing the client's first flight. Therefo
server that sends a Retry packet therefore might not have processed the client's re, a
server that sends a Retry packet might not have processed the client's
Version Information before doing so.</t> Version Information before doing so.</t>
<t>If a future document wishes to define compatibility between two versi ons that <t>If a future document wishes to define compatibility between two versi ons that
support retry, that document <bcp14>MUST</bcp14> specify how version negotiation support Retry, that document <bcp14>MUST</bcp14> specify how version negotiation
(both (both
compatible and incompatible) interacts with retry during a handshake that compatible and incompatible) interacts with Retry during a handshake that
requires both. For example, that could be accomplished by having the server requires both. For example, that could be accomplished by having the server
first send a Retry packet in the original version thereby validating the first send a Retry packet in the Original Version, thereby validating the
client's IP address before attempting compatible version negotiation. If both client's IP address before attempting compatible version negotiation. If both
versions support authenticating Retry packets, the compatibility definition versions support authenticating Retry packets, the compatibility definition
needs to define how to authenticate the Retry in the negotiated version 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 handshake even though the Retry itself was sent using the client's Chosen
version.</t> Version.</t>
</section> </section>
<section anchor="interaction-with-tls-resumption"> <section anchor="interaction-with-tls-resumption">
<name>Interaction with TLS resumption</name> <name>Interaction with TLS Resumption</name>
<t>QUIC version 1 uses TLS 1.3, which supports session resumption by sen ding <t>QUIC version 1 uses TLS 1.3, which supports session resumption by sen ding
session tickets in one connection that can be used in a later connection; see session tickets in one connection that can be used in a later connection (see
<xref section="2.2" sectionFormat="of" target="TLS"/>. New versions that also us <xref section="2.2" sectionFormat="of" target="RFC8446"/>). New versions that al
e TLS 1.3 <bcp14>SHOULD</bcp14> so use TLS 1.3 <bcp14>SHOULD</bcp14>
mandate that their session tickets are tightly scoped to one version of QUIC; 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 i.e., require that clients not use them across multiple version and that servers
validate this client requirement. This helps mitigate cross-protocol attacks.</t > validate this client requirement. This helps mitigate cross-protocol attacks.</t >
</section> </section>
<section anchor="interaction-with-0-rtt"> <section anchor="interaction-with-0-rtt">
<name>Interaction with 0-RTT</name> <name>Interaction with 0-RTT</name>
<t>QUIC version 1 allows sending data from the client to the server duri ng the <t>QUIC version 1 allows sending data from the client to the server duri ng the
handshake, by using 0-RTT packets. If a future document wishes to define handshake by using 0-RTT packets. If a future document wishes to define
compatibility between two versions that support 0-RTT, that document <bcp14>MUST </bcp14> compatibility between two versions that support 0-RTT, that document <bcp14>MUST </bcp14>
address the scenario where there are 0-RTT packets in the client's first flight. 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 For example, this could be accomplished by defining which transformations are
applied to 0-RTT packets. That document could specify that compatible version applied to 0-RTT packets. That document could specify that compatible version
negotiation causes 0-RTT data to be rejected by the server.</t> negotiation causes 0-RTT data to be rejected by the server.</t>
</section> </section>
</section> </section>
<section anchor="special-handling-for-quic-version-1"> <section anchor="special-handling-for-quic-version-1">
<name>Special Handling for QUIC Version 1</name> <name>Special Handling for QUIC Version 1</name>
<t>Because QUIC version 1 was the only IETF Standards Track version of QUI
C <t>Because QUIC version 1 was the only QUIC version that was published
published before this document, it is handled specially as follows: if a client on the IETF Standards Track before this document, it is handled
is starting a QUIC version 1 connection in response to a received Version specially as follows: if a client is starting a QUIC version 1
Negotiation packet, and the version_information transport parameter is missing connection in response to a received Version Negotiation packet and
from the server's transport parameters, then the client <bcp14>SHALL</bcp14> pro the version_information transport parameter is missing from the
ceed as if the server's transport parameters, then the client <bcp14>SHALL</bcp14> procee
server's transport parameters contained a version_information transport d as if
parameter with a Chosen Version set to 0x00000001 and an Available Version list the server's transport parameters contained a version_information
containing exactly one version set to 0x00000001. This allows version transport parameter with a Chosen Version set to 0x00000001 and an
negotiation to work with servers that only support QUIC version 1. Note that Available Version list containing exactly one version set to
implementations which wish to use version negotiation to negotiate versions 0x00000001. This allows version negotiation to work with servers
other than QUIC version 1 will need to implement the version negotiation that only support QUIC version 1. Note that implementations that
mechanism defined in this document.</t> wish to use version negotiation to negotiate versions other than QUIC
version 1 <bcp14>MUST</bcp14> implement the version negotiation mechanism
defined in this document.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security of this version negotiation mechanism relies on the authen ticity of <t>The security of this version negotiation mechanism relies on the authen ticity of
the Version Information exchanged during the handshake. In QUIC version 1, the Version Information exchanged during the handshake. In QUIC version 1,
transport parameters are authenticated ensuring the security of this mechanism. transport parameters are authenticated, ensuring the security of this mechanism.
Negotiation between compatible versions will have the security of the weakest Negotiation between compatible versions will have the security of the weakest
common version.</t> common version.</t>
<t>The requirement that versions not be assumed compatible mitigates the <t>The requirement that versions not be assumed compatible mitigates the
possibility of cross-protocol attacks, but more analysis is still needed here. possibility of cross-protocol attacks, but more analysis is still needed here.
That analysis is out of scope for this document.</t> That analysis is out of scope for this document.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="quic-transport-parameter"> <section anchor="quic-transport-parameter">
<name>QUIC Transport Parameter</name> <name>QUIC Transport Parameter</name>
<t>IANA has registered the following value in the "QUIC Transport Parame ters" <t>IANA has registered the following value in the "QUIC Transport Parame ters"
registry maintained at <<eref target="https://www.iana.org/assignments/quic"/ >&gt;.</t> registry maintained at <eref brackets="angle" target="https://www.iana.org/assig nments/quic"/&gt;.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>0x11</dd>
<t>0x11</t>
</dd>
<dt>Parameter Name:</dt> <dt>Parameter Name:</dt>
<dd> <dd>version_information</dd>
<t>version_information</t>
</dd>
<dt>Status:</dt> <dt>Status:</dt>
<dd> <dd>permanent</dd>
<t>permanent</t>
</dd>
<dt>Specification:</dt> <dt>Specification:</dt>
<dd> <dd>RFC 9368</dd>
<t>This document</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="iana-error"> <section anchor="iana-error">
<name>QUIC Transport Error Code</name> <name>QUIC Transport Error Code</name>
<t>IANA has registered the following value in the "QUIC Transport Error Codes" <t>IANA has registered the following value in the "QUIC Transport Error Codes"
registry maintained at &lt;<eref target="https://www.iana.org/assignments/quic"/ >&gt;.</t> registry maintained at <eref brackets="angle" target="https://www.iana.or g/assignments/quic"/&gt;.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>0x11</dd>
<t>0x11</t>
</dd>
<dt>Code:</dt> <dt>Code:</dt>
<dd> <dd>VERSION_NEGOTIATION_ERROR</dd>
<t>VERSION_NEGOTIATION_ERROR</t>
</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>Error negotiating version</dd>
<t>Error negotiating version</t>
</dd>
<dt>Status:</dt> <dt>Status:</dt>
<dd> <dd>permanent</dd>
<t>permanent</t>
</dd>
<dt>Specification:</dt> <dt>Specification:</dt>
<dd> <dd>RFC 9368</dd>
<t>This document</t>
</dd>
</dl> </dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC8999" to="QUIC-INVARIANTS"/>
<displayreference target="RFC9000" to ="QUIC"/>
<displayreference target="RFC7301" to="ALPN"/>
<displayreference target="RFC8446" to="TLS"/>
<displayreference target="RFC9293" to="TCP"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="QUIC-INVARIANTS"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<front> C.8999.xml"/>
<title>Version-Independent Properties of QUIC</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<author fullname="M. Thomson" initials="M." surname="Thomson"> C.9000.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
</author> C.2119.xml"/>
<date month="May" year="2021"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<abstract> C.8174.xml"/>
<t>This document defines the properties of the QUIC transport prot <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
ocol that are common to all versions of the protocol.</t> C.7301.xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
</front> C.8446.xml"/>
<seriesInfo name="RFC" value="8999"/>
<seriesInfo name="DOI" value="10.17487/RFC8999"/>
</reference>
<reference anchor="QUIC">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar">
<organization/>
</author>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communic
ation, low-latency connection establishment, and network path migration. QUIC in
cludes security measures that ensure confidentiality, integrity, and availabilit
y in a range of deployment circumstances. Accompanying documents describe the i
ntegration of TLS for key negotiation, loss detection, and an exemplary congesti
on control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="ALPN">
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Neg
otiation Extension</title>
<author fullname="S. Friedl" initials="S." surname="Friedl">
<organization/>
</author>
<author fullname="A. Popov" initials="A." surname="Popov">
<organization/>
</author>
<author fullname="A. Langley" initials="A." surname="Langley">
<organization/>
</author>
<author fullname="E. Stephan" initials="E." surname="Stephan">
<organization/>
</author>
<date month="July" year="2014"/>
<abstract>
<t>This document describes a Transport Layer Security (TLS) extens
ion for application-layer protocol negotiation within the TLS handshake. For ins
tances in which multiple application protocols are supported on the same TCP or
UDP port, this extension allows the application layer to negotiate which protoco
l will be used within the TLS connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7301"/>
<seriesInfo name="DOI" value="10.17487/RFC7301"/>
</reference>
<reference anchor="TLS">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over
the Internet in a way that is designed to prevent eavesdropping, tampering, and
message forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
mplementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="TCP"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<front> C.9293.xml"/>
<title>Transmission Control Protocol (TCP)</title>
<author fullname="W. Eddy" initials="W." role="editor" surname="Eddy
">
<organization/>
</author>
<date month="August" year="2022"/>
<abstract>
<t>This document specifies the Transmission Control Protocol (TCP)
. TCP is an important transport-layer protocol in the Internet protocol stack,
and it has continuously evolved over decades of use and growth of the Internet.
Over this time, a number of changes have been made to TCP as it was specified i
n RFC 793, though these have only been documented in a piecemeal fashion. This
document collects and brings those changes together with the protocol specificat
ion from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6
093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 a
nd 1122, and it should be considered as a replacement for the portions of those
documents dealing with TCP requirements. It also updates RFC 5961 by adding a s
mall clarification in reset handling while in the SYN-RECEIVED state. The TCP h
eader control bits from RFC 793 have also been updated based on RFC 3168.</t>
</abstract>
</front>
<seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="9293"/>
<seriesInfo name="DOI" value="10.17487/RFC9293"/>
</reference>
</references> </references>
</references> </references>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The authors would like to thank Nick Banks, Mike Bishop, Martin Duke, R <t>The authors would like to thank <contact fullname="Nick Banks"/>, <cont
yan act fullname="Mike Bishop"/>, <contact fullname="Martin Duke"/>, <contact fullna
Hamilton, Roberto Peon, Anthony Rossi, and Martin Thomson for their input and me="Ryan
Hamilton"/>, <contact fullname="Roberto Peon"/>, <contact fullname="Anthony Ross
i"/>, and <contact fullname="Martin Thomson"/> for their input and
contributions.</t> contributions.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA809a28byZHf+1dM5A+xDyRtrX1JVpvNhbLsrABb9knaXQRB
sBhymlTH5AwzPZTMNZzfcr/lftnVq18zTUreJMBtEFicRz+qqutdNePxWHWm
W+mT4mWz3pSdma108YNurWnq4kIvm87ARfh70bTFf39//lKVs1mrb0/oR/LS
haqaeV2uYayqLRfd2OhuMf771szHtzzguA4Djo9fKBjlubLb2dpYvN3tNvDu
+avr12pedvBouzspbFepstXlSXHdlrXdNG2n7pY8vaq365luT1QFj5+oeVNb
XdutPSm6dqvVdoPX4dfvvv76a3Wr6y08VBTLttluToojHOEIfvO0Rz827QdT
L4s/4W28vi7NCq7jBv6IW5k07RKvl+38Bq7fdN3Gnjx9io/hJXOrJ+6xp3jh
6axt7qx+igM8xReXprvZzmTIu+XTDFTwsRUuuotm4Mcn/PrENLkXnz4A5JOb
br06Uh/07q5pKwTFuMBn6Q95nv6O3qHfc49l+mnq3oW66XCgThfdytIV+Hdc
L1W57W6almaC/xfwJmDjbFJcAbjq8mdDF5lkzspbU6U3AJAnxZ+aZgnU9ebN
S7pmu1ZrAM7xb549K6brzQ0ARZdwsXhfth/uyh09NTcdkM7bZlt3pamLH4y+
o+utXsKegNan/FhTwcxfv3j24rn8hheQ6L6vYTOwmg5RUTQLmEm3Zl7SU5oJ
o7KyVsL6H5d4dQKASTf7alJcajtv2lUZbfYVDJZeh72WtfmZYI4r/9msVsl0
+kP7x7ZbrGkKpcbjcVHOABrlvFOKzmLVwFoRFZu2AVjqoiTErTTgRbAbY7ZY
6/kNzGnXxWzb4Wo7XVZFU692SkawMASAlM4+gLmwuoWBiq6BpyuDZxQulx3d
czPg3/OV0XVXzG8aqwtj1bYu53O96UogmElxfWMsLHa+XeNDMMu8NTOa6/Aq
cSpVrlZwqHBrPEdZV9GyrF7pOVws1ttuC4/uCrvdIMsAZMrgk+LdBgfGuyNl
FtGCf215ybVfCI6O992CwjCFvQGuJCCWo7Awre2KxcosbzqE2brsRsnr+N68
BBiVH3SxWZVzXdwB/TYE/vm2bZH/wH39EfCqgA/h9K3Z9GEmjK24fP2SeNtE
CGJtqgrWoR4V50DHTbWd0xFW1wE/Y1Pflq0payKTjW47wxROJPTp06/w3/H5
xQ/Ty/PpxfXVtzAHTvH5M2BqYWrYssqJh005/6A7oqSqISq0Gz03i11x09zR
nupq0xiYFnj5vLPF3Q3A2XSq1XMNrBPWUANt0CociI/denARXz979gwWIfhP
qXFr71nWP0WxI9mVtvWvO15A/A6SXbnQQGtrRCuupVkwsZqaqYBmaYo5bL1D
mqn1HdBNXWvCD9HAYZpVefx/+tTDFgBotmNEISk5np49T5YhsdLwVLnUtKX9
IAQS+xGXyURDO+528WDAZomiR/cMRAdgptWmbDsEVBmf8MaB965hUjDIv3DP
NITFJ/xZhFG6Ow1UBE+rrukIdpWxfyMyk7172u6fISZPJP4M11Fbi/Dbvws7
AgI2c0BbVVl/ZItwZAnfHsUKBDqQkrE3NDdwnVrrSlcA1XP4aWErNSBtbsoV
AeG2AVkIQxvmVNG4fHAQZ8WmAa2J6FPTZnD/aglnqWbMrhtLfKVlAK4CSJBz
gXJSVkhsZo36C06LiNuAbmearVWeXRLYBFpzhkG5so2wA2TFlrB0mHsrBpej
NuvmNcR/HCbDCmG7SCgDZKujwHCPwvOOjeZhhvzx0SNQVmsADhES80TQhApU
hWxx9Pb7q+ujEf9bXLyjvy9fAeFcvjrDv6++m7554/9Q8sTVd+++f3MW/gpv
vnz39u2rizN+Ga4WySV19Hb6Z7iD2zx69/76/N3F9M0RnqEuIVJEFCBmBjyp
7nQLyEGuUFrlpGaF75y+fP+//3P8ArklMMqvjo+RW/OP3x3/9gX8QJrh2VC8
y09A906Vm40G7BtE6gpAvjFAKUDdJWAIOHdd3OhWA/z+4y8Imb+eFL+fzTfH
L/4gF3DDyUUHs+QiwWx4ZfAyAzFzKTONh2ZyvQfpdL3TPye/Hdyji0wnZ8Q/
IzoJjNdqlj2LBvkU8ghAy9qeAIBA5rJYAEMGuAHzNj6OxMoCN2AWeRSrC0f4
uLAWhXrqAijbnUmru+h2Iq9IoljRgurKsqQzfGTgQVXEgmamQR4BLXXFDeAX
9Oa2KmYwarFom3UkUye/ZDt7dKgjFKcFPZII92bhhpdh4M0YIrQGBP5R05ql
qQP/whH3jgc/dzKOk/0eXLAMD6Ros8X5Isu77AbsTZDKq84gewsrtcVjqxG0
nz5FFz9/fsKQ6K8Xl6v/vmXWfkDbhAFlE7z+HpgDQIbaaB4kcKhJG6l7kIYr
c0cduY2DjJ9ra731YMPUb8uPZr1dF1d6SQfijQE9wKyBFT9+e/XmCRAu8CjY
k5Ap3gKyoVUF8Q/T6o+GhJOoxyDB2w+AiJ60RwlAShVxRdjAwiy3LetkSPJo
IEWnvbgtV1tU31CXBGW43nagUl40sdKHx7U4srz8I+JuDmEAT4VWG6D1SgD1
fPJicoxY+a/rl+9JC/3q6+efP5M8yWoHb728U/vUDdRt1rpkzQR0KVQRI2Ut
xsQJbkQdxfb2kegdLVCUaUn8RkoHAgVmBaa+AlmNXhlWqbygHCkWAnheozEJ
PKJaWzDEka8BsKKRUQUm2UFja9HfkYYSrSIMSmeETghegcMxYV4qnMsxKevI
I2ZTOzwZjRVraHCeYAsKDzLdT5iGN2QcrxTVetXAo8DvKt2mh19lVOhJcR0f
0mR8QMVqi4axQ/55pOITV/j0CZc5RtUfNi3YugNrHqU4HMcKF9B4ExTsIsJT
BLic1p4Ac3xbE7Mh67QhlU0HjRdo7q5etiU6ALoO4GDdwvwNxsb3G3iYzS9G
uEk3O4qtLPg/ky/gHS63KEQ+1EgvaN91DerzVifv2yBW+igknms677KgqdAc
LEBPbkEExiSfOxmjggHiniOQOJ18Xno5LYw/lor7zK/KLEDoRoCcFK+blvwi
ZY12DfsKVIaA+4O5BU+9A0GgyLtLHWg5DuxecyYmASeaMLcDRzanAAaYsNwF
psdYSURtbPDWsaSaOrTD45V62DunI7/iwWF1viNUvFsN5/bvW43iB6dC82cR
wwcZPhNSWLYjRsOmozZEft6g6sk2sdwOiNlR0RD1gjro/UX1rmho2CFeSBVO
1O3kGMIWgoAxZMs5u4y2XkZuipvyljdWzszKgPmMhzfdrQp8zGlbDpDOxFls
Ix8B7tUgcGoBY239WpQ3nkH/qJvt8iZSkiyjNLXr/HoSnufUUhQB6NiRseBh
XkpARXISHCLKcKBYvT6Pz3ZOiH56FB9rFhv7D1BWhQEREiSEzKEyXg22bkU1
YaNEWHyhS2AlGv3BffUY4aY7BcB8RyyjcjNYx6f5ufFipTWKPjKviivv1nGb
Boa6qkjcKNkfEiXYsAUqUXChChbuYyJDNLmrVEf5zeS5E3s8ldozEapxL+lM
WBZIZlk35MM84K0xxKfRCChNbZMj7jkXiBm93uB8s1108r4RHh2JnVi0sheB
12Dvcd8hEfk1IPLbFs9tRG3nZ7JJmlVF4HHASWV8Rvwd8lqNYnbMdGI1Bnn4
kHtQoARj6Ft3Jleo6YpD3UMoMj1M8C0Cdkk5GynjZilnMFZffxeAT4p3yLTu
jNXEHt26ej5wNfAnentRREly3EmYxMcWwzl4SpyAMSiy7/b4xUXLy4wKBBd8
p84bTLbYIQai9kxDhASqdmVv0EAQxpbx09PE+iOq5csgbE1PbSt6apuo16Rf
YUix1QlIEt3sDk7mUtdbOJqAhgmYHPRo3Yj+hcpS/TfYFAzn9FKDai1ro+gl
XrFMjL3SGYNslDlQSr1DrZzpiS0m4pH3ssgToWZbOD8OUcSBY2ijYIu85TgI
gFj8+NUBbhv8cH32b4Hni6FAKgErTqfs/wJ7qYIzBBsaenVH8Ci6J0tTiaMs
sWuQltWpMLFYNKMRgHQzNB/cXonnp4rcHP2HbYeHE0i3eejLp5NiKj7iEiUy
aZJ+I1MVtlrObLMCoxWFKjkMmIWYFjaCfps1+unx8ZkGXcIA56m2rWNe/jCQ
oGZttigXnW7T26JrE9wiEqFjfypwT24pujXtW9IMjdj3kkCD3fxgeVmLUfxm
rYuq7EpgRug1t/1Iz7Px5fW1h9+82a4qcnsSgVVun9GcaAS2usOcgLXp8Gxh
3BxdV46C3Q5Y1zIcG7W79RreMvOTnLYW8E3EpPrw8SglOOEbpzQqk17/6amo
F7QbdYOuVtaHhRAiOmCYlxjeNnOSIXCd3X5+TSfx81PlTVFBBoar8HmMkJdr
PqxX15evpm+BHMu1tqykRxNGA6g9AxDl7DaoHHegJa7iibotRW3Jtqb9ymyI
mevvT1/5aYXe7hxSh1SHFHsqDyA8k4cc/cWa9m0Wxz4Cjv4VflCTQxAlCczm
cK2cUcd69lBQAZHONStaEcmJ54AtBS+Ipmncl9XeQEj3cKcYHwuKZKHdxc5n
4glrzHbgGZKdZ8+vH2wkThIcbP+R7Rn8uMaEHu/0ajUWpXOiXgfKHQ1I1zs4
py6WUKJtgabHRyIYZpoUlMYQhiINAQkEnzddfyXpVoGZUGIDGSe4DDSMmDcI
eZ0q5hkgJ9jVMjiMyHQCAKxQm8M0HsvImavuyDNIy5BVMmWhB2fCvnHctQNH
6vdIaeBUsf5atu2OXwt730PyPTcCBl9xk6ytRSjkGKk3DEbC00prt2tWXvJD
q2DxutG29Qp9vo3TKL3HErZ7xbG61W6EWk36nrEDLtmJAviQofsuX1QrMLom
e+gd8EGcUIbWH9HhaTrUhPzYMb+YweSR0rkmIgOtoly2mjzkzq2F2sYej6YC
EgFwslvIYz55gWmQ7PwZrtMZbMg1ty06l9CDyny1Vn6pTJoeiGQtAqG0VfAf
r1FskoSjBCzelZ3rumxNQ25in2DBmwOkl3e4AR9oSTmljHt3Y1Y6Ymvrckeb
3Kep9Qz12Ez/UTzCeWdO3p+611sT3C/O7/ORcp3SZ3NeWBBf23mHGnvGH+sl
cmTPkoHWRCpZ4Jds77GfE3hUyumH/Bf9WUGxd879jG83dWVGMCOtWiw4RCoj
z+re4h4fP0lMTSSpx189CU7ZAxDNKysuzk9TR+ZT1tgLyQFT0i/5LeeLirYj
hqqVbAjUnjPEoLxznSRs4PyssbSaIw5J9AyPDKv1N2UVjA9RZXAiZOppPJF8
jZjgw8TC5xus8ppUG3L0ocAvLbu5W73PpuRgm7LIwcsssMMOOj4VxvogAD7O
s6ILEBVYXM/EuUKHNEbOjtVOlt0hnw+jRjLdx+1IWqpFaVYhHajbp6jPNGvW
jhy+EUe3w6FBLosxCtVD4sA9S8QbHBbe4mDQl9lgGAWeemHLoV5T1sSdRvS8
8uPwaZE8M5wySmncuWCAWLmkS1FQJOKKKudZmHpLjbRhsleikY1NfLkSYag0
RhYxPy7xE2aIB1aGw3OGlo/ZRhEqb8CIe9BLsZFPEHHr86sa5ayZLvgVfQCE
fMfo+UkiZAcoWJIGlIUHMeF16c5hZmuPmSKBW4ux44KEA46t8hy7F3KXNX7j
BR6ezZg2SdQpeAp41EpXyzhu4ByY9cHdIYNhscobRIdMHAsa7hJkyFuXqTfk
7LaQjJUtr5SZhMdTrJSMIut8eOgdD9sLbWICKrjAfLQ+hNWHtH2+1092U1ol
Xq+1xO/xaG42mFSX8TKMhJcm7/DjvGTFEZ/4DbY4vcTP82lUrjE50My3oHP6
sFtmyWsYmQJibOl57c7J3dtyZSrRK2mHzkHic/jCO8y70CPt3qaD3xsis2zl
lp0LFuYA7SP3Xs34z3G3RXJvMdUb1ELKOu0FziJf5+Oh9wQN3yciFVJVV2Gi
IRl2vBOdzIjmLwilMLaHzB5UqZ5IJWImsPWVJuQCqGDng9v9YA1lnadzvuSD
6pihEPX0FsstEtchsUkn2jL8xcUhIj1wEHj0ngNywZe5FT/ugSSvXT0hTkyi
3hHSvcEqSb0fSeQiiWkfii86MXTvBJytRtEHdfjRDBkfdDickvfyZe7WGWuC
IVPOWytsJTVzMIlOlPrHP/4hYaniwf9dcfKGEhr5FqPWGcr4tngMN06fFOP4
vz+o34/3/Je1cmAU2MvLJ9F0L/dNBzfO7pmu8KOc7RuFp0PAfDopHi3MclyB
vBk7qU8FW98egXE2I+syXuwrfuboM5kiqZMiOp1ez3+ZCW5mgKBcGAw9ddG5
2VCmInpoz7xdGwY3XRjdn5cGRWvIyPU5dfj6PiMzJNlJrUucjIfqHFVjoPcn
zgtPikRcIP5Axs/hQxQ0wBCGVWm6biZLhw4sMwK280PeuzglqZAt7OcbOers
N324moZQkLEpZkZ6RxwztPnxsiG8c/GstsY6A/VeJhPpor1cb0bZocDS40w2
zxPna2ZVC8sOUNiDttcCAwwlAhEpnDhh1QuUAplisAT4ZRLvPRRyRrS6oFOg
4V7KTR8uwcQmvyFxPptw8I6NbICsJPqEzcQkzRqgbJ4iFS7tDtTTmgXbbU/3
agaJuTZUrpBsk8f7RRWcHQWaKCekkeIax9zixNEZxjF9HI9PF/Azw670dy75
x0nh4BOSk7gxmI+G7t5+olCQm5hx4Ysg7k2VovKbW53kQdJ5bslu6QXuSTXH
RQBPUINcJRhrjQmu5mftfGbMYcGynvmkHedPPHFZscIL43S4TB7NoXQ4N1Iu
dTjnXfVMIPDfMNSPw1qIKNw9cm4DlMEUJwneG1rbqtI2BLr7ap1zOY3Ec1hW
qBgacuPV+i5JoQo2EStvKusDTJNpY7vw06Ogsil1ljVCggafBPpz4wlfojJh
oG3LXDhjD5beJVh68ey2gu6BXeSCZ97G3ljnjSMAB3FBpkWoyUzKnfrrTexi
I8p8ZVrHGPKWGJkqgb9gnBX98lh9y86tjkuN6p7dkNZqJVPbIg6tspuWwg/q
SF7/KSKqI34at4+UD6IH2InTu10mzm8nL0KiEmc9UXFBzajILYNFO5ahzDSm
jjwO/mJgaKLcyqlSRxdyCQg+KvU5wlxG5/1i4Q/CRRTPLNmpom98PH7+1ZMR
XM6oa3irmEwmI/U50dhuzZiHdOpabqrX9NeR5LgJNHCdlHzGho2J0w8JDCde
E5UxT9QJsY9E/LCWVqMvGqs9hM6lWpKNSxYzrr4ADW+sGVPkARU+wWtwrsuk
jIGz7VO7y61ZUp+aeqlc2rWLgbHbT8j0G+SXVM222JIHyLMMirEAOCSwAnyK
csLJC4mR8ShdF9dh4zldqnfqSEuAbN3C9xqUld5QsUgUHGL7C8sb0JKKuCIs
Nk3scpl24yu8PZwDMfYj68o0mNdVR4cXtSLGhTZ7F/BtVTj790QoRhyd4EQ0
JCtJkmQ5gklIE5WmeXhJVOescl4VcTgqUqOMgsr7KXG5KlR1BoCRK3m93tau
Jlf3GLGXbbSm4ANljTvc4moPjKpVt6CstrtRyFCa/lloxlF9R7k0yE7CAEqs
b0AZW5VfgDKe6UtQpl5jyuz4TG9WzS5OHHXxeOePoAfWRBC5lFJmn4RLRF+a
12s9/IWSnQLIIWiM/Vq9LlEyWAat+iJ0Sygc+Ia2FmwEgH4f8wp3Deqnplz8
2GJkPZ6i7S7Hh6dy0QvYC6i0DSnpIlKVZ1fekfnatSRAM6fVpbdT9uIByQFZ
GNgDuwmwaQuaPszxLadkzIkLu/TYJNEN30Mx7BKDPZSjIkCyrDrUoYtnH/+r
5P8pn76VWRQCCLHYxME9lHc+9ZfUA93Ojc1rvmQ0RbzXZgUdx9CIgXPZ8AyD
AmKgk38+1NrEijCgLdXMznxZyXsuOGEVLSQjKjXN1KAYSn3jTEiJqoEOVGK4
vtnaQsJgQI1UFUwa+Af2nJOuEvS7UArcixcFSRAUbI7D7CS/Ar1ksQNZKK6c
WS1JQPST1si+gNjYj1L/ibS9uc+S2SxrndThDOpvorzrJGsSzmE/azJrHcfp
zwSZYTnNNJSKYOU3gLBXl+Is4VmJJUhNkgGr/CoIgAfzwfsb2O8rQjOv8N0d
DDq+QUGsmRu7LfUzmpU6TTM1WHl2WQRwlDY68VHF2lROOZawKjU6KLn0s6Tx
8EmMkFKiwKKX2sSCvmsa1D5bku9modBsXel6ibyAWWBlQOiQcJ1heHbbPvGh
2ZDjzHuYrxqJCMW+HtOvgqVsYtZyh7p6CjMcEVavaHhqgRFp4WAUwqKRsncb
XVxfTi+u3r+7vP7p/fRy+vbV9avLn15dXr67pIhQ1J0jtOMo+7zf634/67ah
IhrE/4Cz9Z5TLi6MSYXkwS7tEAO8DCciojXkzKIQmu+HCBgpsSwaMl70M6gH
rEipV7eYOphgIbXzckyZRnadUjB576ah5DKF2IrCKb3is9xQhEKWdD1SyIoD
ely8oXBAy1Vkt+2hC/XDq8ur83cXP128+tO76/Mp1sMzXTjbzQBfHtM7FIqQ
LLQhnrKWfZIKQhKI7/p8f2kK0Y/+S91yxkaJ8+alFQkoH549pNGpXp5WFOxx
sXphrb1gml+BwsDUDF/ylUxDUydJqXiDxsd3bHw4R2Jggor0O1J+n318xv8d
T4p+3hQxENGGdC+7JHMehvlDUaiv7OXb9E4MjDC/0Vb1NL8AfZ0aiLxX9g6i
0B3OTWxO/SIijxmw99Z7GsuBIeH+Da6hh8rHlNLDjX8qZ7Nl8TfEnJO7ZLJy
JrQ/Rso7OeyTXrHmEMgu87yP+Rh4io6HlxFfBDzJrhEFYMg8izzz9OGe3nJB
ACleL5s5kdUWhS9QFuaYa/T0P0EPPjyb3UKJCZwWWdsoEbRi8rmeZ12cHjEp
vmNHg5CXrBE9I9SQilW4g6oPZlQ/eE0DGOTRup+TBxikiK3YRUkrRsXpgUVr
qs8ZIgLYZzKxKjy8q7wZ6MYjdwL1Z+BeBn2vcVDDo2JBZ755GBBIQipP36iN
WI0TwbjCKFgmW41m85aOtxU9m1tErLk6CEe2jtFgk4F6fu37ITkqNqstJw0e
yMoZAssvP1OePopc6vfS2SHee16rYb5NoLoHHw5az72goGIBtMEfdk7U/eu/
pgTZoWJsvUXmDVBgtGTicM6ja5Ah4m55nxnW4FNzHVajvKkHp7VX4wUs6Ncu
Ez/wG687JkU1sdSyxfGzUXH8FXfqOH7hEBi5vFA034CKE7LwbVJYm29NoJwJ
mNQWHH81Kd7QUjGHvpF6O5CZ5P3E0VzWgUvfSJodsdrjbo1yZ7S3sefskICN
+ZYix9h9Uy6i+trzkeVrqidx6I3b+gRzociRaLzv/mIk/bkDw3qJTp+y7nc5
zRFgr03DAzs04HQw4HWq9h06Mj5d/fi5X+85WyPY0yiBfobjUlabARgQhDNZ
018GOLcGmo+jrKnN7YpqsO/TViKDgzQ4BEKgI6lU+mWEJGjYUW9erkZNSSgS
/sHRgzEHPPQ2z9hgsD10w9M+v4dkPI8o/iUk84zovZZOWl9CMgSrX0A2EcW4
1rAL3H2OfmC4A7Ihd/D20JBv1EVp5LZHVw/QGwknIWuTevcOYeRU8u0Cmy5K
QGLgv5uo4PPcBJ+ndD/00aEYnegY29M5Uu1z5w2i/t747iUCTn26cOQrzwFj
0EfQ5waPYv1F7TX1XDuxxO/RJfy2S0MEadK6sxAyqrKobJzraqlRt5TzLbgE
KTSUukNThVomyVSDOaJgH5wgbuTCPjfxlK6kP9mw3dwgzxgYFchWX2h8sB1T
jHI7LCvYk/aPd3yyv4uLuvvZDk9Jif7QrHdsQA0tziRSO1yO8zzuXLde8gT8
y1TKawnS4ZGxKlK/UCUKzW9C54PcWORSbZe95hwqDvC6wK56JCmhxZkPnEVd
jR8lugO6sbjoLT4iSI7cP3a+Jb9LkqDnQ33GRVXXDdVyqyozoQsd0RY5aFQW
NDk+4ssbXIGNZNuCEvcjmcrCD8WLSGrWoN3k1LcnTgKUBHjjbKW0rC20AaHg
JXcX6q1hUrylYg/XFgibZONg6F1ukwYVvnYnOw67+5C5oLXtSMqpafkSQCyO
6DfUuW9P96+Bil2wovJgtt8iCVb0VshREaxjReO07rfG1ZK3Rv12G+DR9SBV
IoMtfG+kpDhauA4HG8jLJBXgnGTlt0vqTYW+7ablKKnTjykxBLu67Qkw7wFk
anlI5mlEKSilI+6BtUvoFVfDoxHA7qWPPxni3g8XWO/3OkrpxusNFde5WU7K
TMA6aL/074Hpp5MiFyzu78lvZ+8BByED9EGCwrXwlnpb1x2iJHuLqv28x4Ll
FxfVD1nGqYTYJYFgFE4b1wELUR+23iXu18ckaYroIitXLTDcHRc189Krod8T
TG7cOffp6AceuVSrpcSm2JsxOLQUEoBJsSFSMt+OupB7TZ6UBldg1kaJIMU+
YpL0HeoQ4FtB+KRgTe03yj2lzoFRRGqQJHZzbXAPtVFl9aHxyIfkEyFDu5Ai
JE442VjllNF8oDpt9kieC9Basa8Mxj6oO1Q/Sg3czOXccnGaOKZdvoYvbHNl
LVii3mo9Bttg4xVSh48dsERLPeKwm5k/WK4VlbTGk52duMBSVUVJH/JM1EjA
J9yK1wEn5mpMmH4J1GcBi5QKVCWDsAoU+hFwQhJ1A+6fJuboOLA7oPvYt+uG
11Eb3QEnqmXePex4UrxDYs8daRgtNBAQ2h8VAQ13pRHYUEzbUqF48fbqTWif
j2qwqcdMVgdtMw6Ity1+vEag6wNKbJEfAnIGsAKIMKndz7oIBM40ObhF8g9x
gwLYKK30tam9dlJws4QvXCsMujcba8+ShVD7+UkDcn4QmfKRSI448eF0UQ+H
pLT1Jrpxcix5g7obe1H0yynqoLfol1PUPnj8vyQpWWyfzQSnD4vU7CLJAH4I
k0mrhaP0FidiTA1sfDSohrrdrmrdOve25/TK9QPG1ZLpi9sdV478Y2cya4ou
f8/7r6W1ANeGLLfI46VAvi9PGAArvQSta42LdanuUntEKXXC3sjVXTf12In6
zMEDE2/Kba2J2N6UO3jgfdt0zbyhfG9rKt1KRYtLVOi3yR+2rkcvxbLBEgnr
vyRTuwbaNNMKZ8IvItFMSWkJp8/J1IgbVl4S1TJ4Erw5z8FepwLTyz0d3JEV
nkNxKWCFTo1a6v612V4kqd9sxdVq6EhFHcBUeZjGZ/vx9M37iyf4UQn8Azuh
//b5s2NSLT5oKd6LOuX3K3Zstj8BNYUbbKfw24n6Fwktq3YrgX56V0DTiPDN
VJ4ARLpg8oi3RBLRTHBENNxDUZoBF7hH3pnLAQCO6mZmZ4jf4TA/yLjySiTb
qdim0ZC+36JrCC7+FJRO9yQ2+lApgo+JjVhHGBwD0c6fuNqFxlDSKMmlIQeH
Qlq/Lw3HnAQbLCmqcYnSIYoFnC+KuPm+mezuQiYb4dcfovvHxy35x9xdZ7B+
4e75CxT7ulTF8zsBf3/JtssRSkRb7COj5WFzLOI91TABUgf/eW6GON+y1dLT
E51pe89L9hsOrmt0V9LHDblv5Zw+dEcIypSiqUc9dkrwfs31GU40pZ2OFmAd
w1lymQWxob8YVna41p2SPNviJdV/SqwNZz6iHKPHcQLTJqpcKH9iv9xqpwYy
rf91AiIBgzZXv5WCfNbIczNP2/LBp1Zz6qc4DoN3mgp5/efVLLZNI7PTfXlC
3NB3+M0jTBMZpp3dAcyJbHnxIyWeDyap4JqcD9HTBx/2BtCrDXd7S3t/0dbT
yX1n7k5jky3v5L3UXbsbgMhDhG73v4gV2cfUjVbXg/4ToRDw/D0q56hWuY/T
uDzMvWIMk519plzZKedUjBfD3ScakBJfMqyKhi2ywwbnLDtXkBA4WCbpeqlH
JFteJguqGjIgGpe+JQgMjdlAt+KEePED5zvhJe3nGB6iO2Bz1J1kDec7JmGp
ao71PEbdLG4UQZ8ViVjiE64X5u/4IZ3QXE5BLaOIHa3IdzzBcQdpmXRspRQE
ORNcx62TCLkJ3yIRE0ZsKu5dneBmTzCNcQZjuaCg1H4fIEHhOfk4UNotA1BH
wOo72Yuo9hLH6Z2UWIeQhny+SRd1bIkRLxXFcTUnDcBj7m32E7UG0vxNOG7b
H97sQE1ZkMykeN69vfj2cYnrN1fk+1vTV00G7II+xoHPHE+eOybh5bzV9Onf
6P2od79ydzsT2mbXSSzK62ezECospaNTnGifNoX/avIVsuJfwaroA5cvXvwG
a6ouglBxoQWM9aJRIOsXsaSk9ZAPxZm26K+V4iXIJVC1nIMlyl9+qQfqzDcK
m4aPfHk+b0kif9JzlOIjrluAF01uoNI1eZXAk4qYrbEhlctremLhoYTAvEVY
Jj5Mo4+9OhGqV7JYp47NA2S7jwhJXSGVIvd6gKRf4InMWhWVNM92Qo9JY2gJ
JNzHK9UDeaU/rTRJjlcqxxpowa6BjU+ibTksljav7nccS4vde9zP+3sz3M9/
x1MEq2sVWHpLn7VBpqweoK6TvUhzXN8qj3WlQyFu+YgOj0po5L6RrZZW9v2C
V4zB8mcoi+8AjysqpnC1C04QHivlAhY9wrmTBiVkiuE3wPHry3DI8OuM1y06
FHrHRm22Mwcrl0ASBXSdxYk0haUQ/hOZmMUsrTlO4lxgys5HNZtlWG95aQ1C
rMmXD2l9Hz6QI0P+lHwbdlg8T3kFnFCshh16Mi9YHyzrfaeCVBPuPSOt1A4O
48JYlBZ2cLEhCd5ZsL00hEHGO6cuZ6pyuFBYZkb4uyBYzC4zpRPExYTl5IgY
Hscvy/H6fFQeqZ8tfjn+PWU4qjbuf3/Wfc6LYxtbm7cOk6/UOo6j2NkIw/bb
MLjqTD7HfsrEExp/nDbXiSglfpcSMQfeCgyw7x27ZpOVb7rK49xGwkytpvYz
kvvidREeYG9avPP5VfnavGLYkUJlaZJitHE3C/4oR9ANe3uJ+i3GZ9EJglyL
EsKB7+qZjgjmosaSSiRRSvwICtH1TdKGp4jb11rvvZJ+3NG8TuhyUji7xVha
wYx5QczdfNZceVmudpZ9tBzP5O8Jy9daiffHz6AHAHuZohoS6qpSajmfXkwH
lAKCnxB07bHy3mEF7BZ8gysolpgc34r5E5xL8kFGJpqjfSPZI8UjtDtKw3Hs
pyt+/5e/Pr7puo09efr07u5uguVok6ZdPgWImmVNTqunAPz5kz/ghx9wNkx0
ePbxGASNH7+4gH/xeoadKQVipttSfsRGw8UaRYG6ir+L5XMnHMD2ZQRkwPWK
6u1eNpXGz1qFarp/Gnph4H8T+HBo/LW3RlCpMwo5bxyMeEmef0QfIP+XAhl7
6OFXaykk4Fu/sgPz06MyvfIZhqm36xmC99sjioK7divIUCg0RLrRynxwlcn1
h+ICW0Sdwl9w6t7inVNg+c0GfpCCUJxtUUm93JW1+q5cm1WHsYTLBqaBId5r
/DWtYfh6B1cB2Cz/5eXrm2ZtG/9pPIOBjs2WC4xQBrYGDjrHf/4P4oi3BKCF
AAA=
</rfc> </rfc>
 End of changes. 112 change blocks. 
679 lines changed or deleted 308 lines changed or added

This html diff was produced by rfcdiff 1.48.