rfc9369.original.xml   rfc9369.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-v2-10" category="std" consensus="true" submissionType="IETF" tocInclu de="true" sortRefs="true" symRefs="true" version="3"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="9369" docName="draft-ietf-quic-v2-10" obsoletes="" updates="" category="std" consensus ="true" xml:lang="en" submissionType="IETF" tocInclude="true" sortRefs="true" sy mRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.15.3 --> <!-- xml2rfc v2v3 conversion 3.15.3 -->
<front> <front>
<title abbrev="QUICv2">QUIC Version 2</title> <title abbrev="QUICv2">QUIC Version 2</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-v2-10"/> <seriesInfo name="RFC" value="9369"/>
<author initials="M." surname="Duke" fullname="Martin Duke"> <author initials="M." surname="Duke" fullname="Martin Duke">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<email>martin.h.duke@gmail.com</email> <email>martin.h.duke@gmail.com</email>
</address> </address>
</author> </author>
<date year="2022" month="December" day="15"/> <date year="2023" month="May"/>
<area>Transport</area> <area>Transport</area>
<workgroup>QUIC</workgroup> <workgroup>QUIC</workgroup>
<abstract> <abstract>
<t>This document specifies QUIC version 2, which is identical to QUIC vers ion 1 <t>This document specifies QUIC version 2, which is identical to QUIC vers ion 1
except for some trivial details. Its purpose is to combat various ossification except for some trivial details. Its purpose is to combat various ossification
vectors and exercise the version negotiation framework. It also serves as a vectors and exercise the version negotiation framework. It also serves as a
template for the minimum changes in any future version of QUIC.</t> template for the minimum changes in any future version of QUIC.</t>
<t>Note that "version 2" is an informal name for this proposal that indica <t> Note that "version 2" is an informal name for this proposal that
tes it indicates it is the second version of QUIC to be published as a
is the second standards-track QUIC version. The protocol specified here uses a Standards Track document. The protocol specified here uses a
version number other than 2 in the wire image, in order to minimize ossification version number other than 2 in the wire image, in order to minimize ossification
risk.</t> risks.</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.org/quic-v2/draft-ietf-quic-v2.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-quic-v2/"/>.
</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/quic-v2"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>QUIC version 1<xref target="QUIC"/> has numerous extension points, incl uding the version <t>QUIC version 1 <xref target="RFC9000"/> has numerous extension points, including the version
number that occupies the second through fifth bytes of every long header (see number that occupies the second through fifth bytes of every long header (see
<xref target="QUIC-INVARIANTS"/>). If experimental versions are rare, and QUIC <xref target="RFC8999"/>).
version 1 constitutes the vast majority of QUIC traffic, there is the potential If experimental versions are
for middleboxes to ossify on the version bytes always being 0x00000001.</t> rare, and QUIC version 1 constitutes the vast majority of QUIC
<t>In QUIC version 1, Initial packets are encrypted with the version-speci traffic, there is the potential for middleboxes to ossify on the
fic salt version bytes that are usually 0x00000001.</t>
as described in <xref section="5.2" sectionFormat="of" target="QUIC-TLS"/>. Prot <t>In QUIC version 1, Initial packets are encrypted with the version-speci
ecting Initial packets in this fic salt,
as described in <xref section="5.2" sectionFormat="of" target="RFC9001"/>. Prote
cting Initial packets in this
way allows observers to inspect their contents, which includes the TLS Client way allows observers to inspect their contents, which includes the TLS Client
Hello or Server Hello messages. Again, there is the potential for middleboxes to Hello or Server Hello messages. Again, there is the potential for middleboxes to
ossify on the version 1 key derivation and packet formats.</t> ossify on the version 1 key derivation and packet formats.</t>
<t>Finally, <xref target="QUIC-VN"/> provides two mechanisms
for endpoints to negotiate the QUIC version to use. The "incompatible" version <t>Finally, <xref target="RFC9368"/> describes two mechanisms endpoints ca
n use to negotiate which QUIC version to select. The "incompatible" version
negotiation method can support switching from any QUIC version to any negotiation method can support switching from any QUIC version to any
other version with full generality, at the cost of an additional round-trip at other version with full generality, at the cost of an additional round trip at
the start of the connection. "Compatible" version negotiation eliminates the the start of the connection. "Compatible" version negotiation eliminates the
round-trip penalty but levies some restrictions on how much the two versions can round-trip penalty but levies some restrictions on how much the two versions can
differ semantically.</t> differ semantically.</t>
<t>QUIC version 2 is meant to mitigate ossification concerns and exercise the <t>QUIC version 2 is meant to mitigate ossification concerns and exercise the
version negotiation mechanisms. The changes provide an example of the minimum version negotiation mechanisms. The changes provide an example of the minimum
set of changes necessary to specify a new QUIC version. However, note that the set of changes necessary to specify a new QUIC version. However, note that the
choice of the version number on the wire is randomly chosen instead of "2", and choice of the version number on the wire is randomly chosen instead of "2", and
the two bits that identify each long header packet type are different from the two bits that identify each Long Header packet type are different from
version 1; both of these properties are meant to combat ossification and are not version 1; both of these properties are meant to combat ossification and are not
strictly required of a new QUIC version.</t> strictly required of a new QUIC version.</t>
<t>Any endpoint that supports two versions needs to implement version nego tiation <t>Any endpoint that supports two versions needs to implement version nego tiation
to protect against downgrade attacks.</t> to protect against downgrade attacks.</t>
</section> </section>
<section anchor="conventions"> <section anchor="conventions">
<name>Conventions</name> <name>Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>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="differences-with-quic-version-1"> <section anchor="differences-with-quic-version-1">
<name>Differences with QUIC Version 1</name> <name>Differences with QUIC Version 1</name>
<t>Except for a few differences, QUIC version 2 endpoints <bcp14>MUST</bcp 14> implement the QUIC <t>Except for a few differences, QUIC version 2 endpoints <bcp14>MUST</bcp 14> implement the QUIC
version 1 specification as described in <xref target="QUIC"/>, <xref target="QUI version 1 specification as described in <xref target="RFC9000"/>, <xref target="
C-TLS"/>, and RFC9001"/>, and
<xref target="QUIC-RECOVERY"/>. The remainder of this section lists the differen <xref target="RFC9002"/>. The remainder of this section lists the differences.</
ces.</t> t>
<section anchor="version-field"> <section anchor="version-field">
<name>Version Field</name> <name>Version Field</name>
<t>The Version field of long headers is 0x6b3343cf. This was generated b y taking <t>The Version field of long headers is 0x6b3343cf. This was generated b y taking
the first four bytes of the sha256sum of "QUICv2 version number".</t> the first four bytes of the sha256sum of "QUICv2 version number".</t>
<ul empty="true">
<li>
<t><strong>RFC Editor's Note:</strong> Please remove the sentence b
elow prior to publication
of a final version of this document.</t>
</li>
</ul>
<t>This version number will not change in subsequent versions of this dr
aft,
unless there is a behavior change that breaks compatibility.</t>
</section> </section>
<section anchor="long-header-packet-types"> <section anchor="long-header-packet-types">
<name>Long Header Packet Types</name> <name>Long Header Packet Types</name>
<t>All version 2 long header packet types are different. The Type field values are:</t> <t>All version 2 Long Header packet types are different. The Type field values are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Initial: 0b01</li> <li>Initial: 0b01</li>
<li>0-RTT: 0b10</li> <li>0-RTT: 0b10</li>
<li>Handshake: 0b11</li> <li>Handshake: 0b11</li>
<li>Retry: 0b00</li> <li>Retry: 0b00</li>
</ul> </ul>
</section> </section>
<section anchor="cryptography-changes"> <section anchor="cryptography-changes">
<name>Cryptography changes</name> <name>Cryptography Changes</name>
<t>The values below were chosen randomly.</t>
<section anchor="initial-salt"> <section anchor="initial-salt">
<name>Initial Salt</name> <name>Initial Salt</name>
<t>The salt used to derive Initial keys in <xref section="5.2" section Format="of" target="QUIC-TLS"/> changes to:</t> <t>The salt used to derive Initial keys in <xref section="5.2" section Format="of" target="RFC9001"/> changes to:</t>
<artwork><![CDATA[ <artwork><![CDATA[
initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9 initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9
]]></artwork> ]]></artwork>
<t>This is the first 20 bytes of the sha256sum of "QUICv2 salt".</t> <t>This is the first 20 bytes of the sha256sum of "QUICv2 salt".</t>
</section> </section>
<section anchor="hkdf-labels"> <section anchor="hkdf-labels">
<name>HKDF Labels</name> <name>HMAC-based Key Derivation Function (HKDF) Labels</name>
<ul empty="true"> <t>The labels used in <xref target="RFC9001"/> to derive packet protec
<li> tion keys (Section
<t><strong>RFC Editor's Note:</strong> Please ensure that the str <xref section="5.1" sectionFormat="bare" target="RFC9001"/>), header protection
ings in quotes are not split keys
up in a line break in this section.</t> (Section <xref section="5.4" sectionFormat="bare" target="RFC9001"/>), Retry Int
</li> egrity
</ul> Tag keys (Section <xref section="5.8" sectionFormat="bare" target="RFC9001"/>),
<t>The labels used in <xref target="QUIC-TLS"/> to derive packet prote and key
ction keys (Section updates (Section <xref section="6.1" sectionFormat="bare" target="RFC9001"/>) ch
<xref section="5.1" sectionFormat="bare" target="QUIC-TLS"/>), header protection ange from
keys "quic&nbsp;key" to "quicv2&nbsp;key", from "quic&nbsp;iv" to "quicv2&nbsp;iv", f
(Section <xref section="5.4" sectionFormat="bare" target="QUIC-TLS"/>), Retry In rom "quic&nbsp;hp" to
tegrity "quicv2&nbsp;hp", and from "quic&nbsp;ku" to "quicv2&nbsp;ku" to meet the guidan
Tag keys (Section <xref section="5.8" sectionFormat="bare" target="QUIC-TLS"/>), ce for new
and key versions in Section <xref section="9.6" sectionFormat="bare" target="RFC9001"/>
updates (Section <xref section="6.1" sectionFormat="bare" target="QUIC-TLS"/>) c of that
hange from
"quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to
"quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the guidance for new
versions in Section <xref section="9.6" sectionFormat="bare" target="QUIC-TLS"/>
of that
document.</t> document.</t>
</section> </section>
<section anchor="retry-integrity-tag"> <section anchor="retry-integrity-tag">
<name>Retry Integrity Tag</name> <name>Retry Integrity Tag</name>
<t>The key and nonce used for the Retry Integrity Tag (<xref section=" 5.8" sectionFormat="of" target="QUIC-TLS"/>) <t>The key and nonce used for the Retry Integrity Tag (<xref section=" 5.8" sectionFormat="of" target="RFC9001"/>)
change to:</t> change to:</t>
<artwork><![CDATA[ <artwork><![CDATA[
secret = secret =
0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f 0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f
key = 0x8fb4b01b56ac48e260fbcbcead7ccc92 key = 0x8fb4b01b56ac48e260fbcbcead7ccc92
nonce = 0xd86969bc2d7c6d9990efb04a nonce = 0xd86969bc2d7c6d9990efb04a
]]></artwork> ]]></artwork>
<t>The secret is the sha256sum of "QUICv2 retry secret". The key and n once are <t>The secret is the sha256sum of "QUICv2 retry secret". The key and n once are
derived from this secret with the labels "quicv2 key" and "quicv2 iv", derived from this secret with the labels "quicv2 key" and "quicv2 iv",
respectively.</t> respectively.</t>
skipping to change at line 170 skipping to change at line 145
</section> </section>
<section anchor="version-negotiation-considerations"> <section anchor="version-negotiation-considerations">
<name>Version Negotiation Considerations</name> <name>Version Negotiation Considerations</name>
<t>QUIC version 2 is not intended to deprecate version 1. Endpoints that s upport <t>QUIC version 2 is not intended to deprecate version 1. Endpoints that s upport
version 2 might continue support for version 1 to maximize compatibility with version 2 might continue support for version 1 to maximize compatibility with
other endpoints. In particular, HTTP clients often use Alt-Svc <xref target="RFC 7838"/> to other endpoints. In particular, HTTP clients often use Alt-Svc <xref target="RFC 7838"/> to
discover QUIC support. As this mechanism does not currently distinguish between discover QUIC support. As this mechanism does not currently distinguish between
QUIC versions, HTTP servers <bcp14>SHOULD</bcp14> support multiple versions to r educe the QUIC versions, HTTP servers <bcp14>SHOULD</bcp14> support multiple versions to r educe the
probability of incompatibility and the cost associated with QUIC version probability of incompatibility and the cost associated with QUIC version
negotiation or TCP fallback. For example, an origin advertising support for "h3" negotiation or TCP fallback. For example, an origin advertising support for "h3"
in Alt-Svc should support QUIC version 1 as it was the original QUIC version in Alt-Svc should support QUIC version 1, as it was the original QUIC version
used by HTTP/3, and therefore some clients will only support that version.</t> used by HTTP/3; therefore, some clients will only support that version.</t>
<t>Any QUIC endpoint that supports QUIC version 2 <bcp14>MUST</bcp14> send , process, and validate <t>Any QUIC endpoint that supports QUIC version 2 <bcp14>MUST</bcp14> send , process, and validate
the version_information transport parameter specified in <xref target="QUIC-VN"/ > to prevent the version_information transport parameter specified in <xref target="RFC9368"/ > to prevent
version downgrade attacks.</t> version downgrade attacks.</t>
<t>Note that version 2 meets the <xref target="QUIC-VN"/> definition of a compatible version <t>Note that version 2 meets the definition in <xref target="RFC9368"/> of a compatible version
with version 1, and version 1 is compatible with version 2. Therefore, servers with version 1, and version 1 is compatible with version 2. Therefore, servers
can use compatible negotiation to switch a connection between the two versions. can use compatible negotiation to switch a connection between the two versions.
Endpoints that support both versions <bcp14>SHOULD</bcp14> support compatible ve rsion Endpoints that support both versions <bcp14>SHOULD</bcp14> support compatible ve rsion
negotiation to avoid a round trip.</t> negotiation to avoid a round trip.</t>
<section anchor="compatible-negotiation-requirements"> <section anchor="compatible-negotiation-requirements">
<name>Compatible Negotiation Requirements</name> <name>Compatible Negotiation Requirements</name>
<t>Compatible version negotiation between versions 1 and 2 follow the sa me <t>Compatible version negotiation between versions 1 and 2 follows the s ame
requirements in either direction. This section uses the terms "original requirements in either direction. This section uses the terms "original
version" and "negotiated version" from <xref target="QUIC-VN"/>.</t> version" and "negotiated version" from <xref target="RFC9368"/>.</t>
<t>If the server sends a Retry packet, it <bcp14>MUST</bcp14> use the or iginal version. The <t>If the server sends a Retry packet, it <bcp14>MUST</bcp14> use the or iginal version. The
client ignores Retry packets using other versions. The client <bcp14>MUST NOT</b cp14> use a client ignores Retry packets using other versions. The client <bcp14>MUST NOT</b cp14> use a
different version in the subsequent Initial packet that contains the Retry different version in the subsequent Initial packet that contains the Retry
token. The server <bcp14>MAY</bcp14> encode the QUIC version in its Retry token to validate token. The server <bcp14>MAY</bcp14> encode the QUIC version in its Retry token to validate
that the client did not switch versions, and drop the packet if it switched, that the client did not switch versions, and drop the packet if it switched,
to enforce client compliance.</t> to enforce client compliance.</t>
<t>QUIC version 2 uses the same transport parameters to authenticate the Retry as <t>QUIC version 2 uses the same transport parameters to authenticate the Retry as
QUIC version 1. After switching to a negotiated version after a Retry, the QUIC version 1. After switching to a negotiated version after a Retry, the
server <bcp14>MUST</bcp14> include the relevant transport parameters to validate that the server <bcp14>MUST</bcp14> include the relevant transport parameters to validate that the
server sent the Retry and the connection IDs used in the exchange, as described server sent the Retry and the connection IDs used in the exchange, as described
in <xref section="7.3" sectionFormat="of" target="QUIC"/>.</t> in <xref section="7.3" sectionFormat="of" target="RFC9000"/>.</t>
<t>The server cannot send CRYPTO frames until it has processed the clien t's <t>The server cannot send CRYPTO frames until it has processed the clien t's
transport parameters. The server <bcp14>MUST</bcp14> send all CRYPTO frames usin g transport parameters. The server <bcp14>MUST</bcp14> send all CRYPTO frames usin g
the negotiated version.</t> the negotiated version.</t>
<t>The client learns the negotiated version by observing the first long header <t>The client learns the negotiated version by observing the first long header
Version field that differs from the original version. If the client receives a Version field that differs from the original version. If the client receives a
CRYPTO frame from the server in the original version, that indicates that the CRYPTO frame from the server in the original version, it indicates that the
negotiated version is equal to the original version.</t> negotiated version is equal to the original version.</t>
<t>Before the server is able to process transport parameters from the cl ient, it <t>Before the server is able to process transport parameters from the cl ient, it
might need to respond to Initial packets from the client. For these packets, the might need to respond to Initial packets from the client. For these packets, the
server uses the original version.</t> server uses the original version.</t>
<t>Once the client has learned the negotiated version, it <bcp14>SHOULD< /bcp14> send subsequent <t>Once the client has learned the negotiated version, it <bcp14>SHOULD< /bcp14> send subsequent
Initial packets using that version. The server <bcp14>MUST NOT</bcp14> discard i ts original Initial packets using that version. The server <bcp14>MUST NOT</bcp14> discard i ts original
version Initial receive keys until it successfully processes a Handshake version Initial receive keys until it successfully processes a Handshake
packet with the negotiated version.</t> packet with the negotiated version.</t>
<t>Both endpoints <bcp14>MUST</bcp14> send Handshake and 1-RTT packets u sing the negotiated <t>Both endpoints <bcp14>MUST</bcp14> send Handshake and 1-RTT packets u sing the negotiated
version. An endpoint <bcp14>MUST</bcp14> drop packets using any other version. E ndpoints have version. An endpoint <bcp14>MUST</bcp14> drop packets using any other version. E ndpoints have
no need to generate the keying material that would allow them to decrypt or no need to generate the keying material that would allow them to decrypt or
authenticate such packets.</t> authenticate such packets.</t>
<t>The client <bcp14>MUST NOT</bcp14> send 0-RTT packets using the negot iated version, even after <t>The client <bcp14>MUST NOT</bcp14> send 0-RTT packets using the negot iated version, even after
processing a packet of that version from the server. Servers can accept 0-RTT processing a packet of that version from the server. Servers can accept 0-RTT
and then process 0-RTT packets from the original version.</t> and then process 0-RTT packets from the original version.</t>
</section> </section>
</section> </section>
<section anchor="tls-resumption-and-newtoken-tokens"> <section anchor="tls-resumption-and-newtoken-tokens">
<name>TLS Resumption and NEW_TOKEN Tokens</name> <name>TLS Resumption and NEW_TOKEN Tokens</name>
<t>TLS session tickets and NEW_TOKEN tokens are specific to the QUIC versi <t>TLS session tickets and NEW_TOKEN tokens are specific to the QUIC versi
on of the on of the connection that provided them. Clients <bcp14>MUST NOT</bcp14> use a s
connection that provided them. Clients <bcp14>MUST NOT</bcp14> use a session tic ession ticket or token from a QUIC version 1 connection to initiate a QUIC versi
ket or token on 2 connection, and vice versa. When a connection includes compatible version n
from a QUIC version 1 connection to initiate a QUIC version 2 connection, or vic egotiation, any issued server tokens are considered to originate from the negoti
e ated version, not the original one.</t>
versa.</t>
<t>Servers <bcp14>MUST</bcp14> validate the originating version of any ses sion ticket or token and <t>Servers <bcp14>MUST</bcp14> validate the originating version of any ses sion ticket or token and
not accept one issued from a different version. A rejected ticket results in not accept one issued from a different version. A rejected ticket results in
falling back to a full TLS handshake, without 0-RTT. A rejected token results in falling back to a full TLS handshake, without 0-RTT. A rejected token results in
the client address remaining unverified, which limits the amount of data the the client address remaining unverified, which limits the amount of data the
server can send.</t> server can send.</t>
<t>After compatible version negotiation, any resulting session ticket <t>After compatible version negotiation, any resulting session ticket
maps to the negotiated version rather than original one.</t> maps to the negotiated version rather than the original one.</t>
</section> </section>
<section anchor="ossification-considerations"> <section anchor="ossification-considerations">
<name>Ossification Considerations</name> <name>Ossification Considerations</name>
<t>QUIC version 2 provides protection against some forms of ossification. Devices <t>QUIC version 2 provides protection against some forms of ossification. Devices
that assume that all long headers will encode version 1, or that the version 1 that assume that all long headers will encode version 1, or that the version 1
Initial key derivation formula will remain version-invariant, will not correctly Initial key derivation formula will remain version-invariant, will not correctly
process version 2 packets.</t> process version 2 packets.</t>
<t>However, many middleboxes, such as firewalls, focus on the first packet in a <t>However, many middleboxes, such as firewalls, focus on the first packet in a
connection, which will often remain in the version 1 format due to the connection, which will often remain in the version 1 format due to the
considerations above.</t> considerations above.</t>
<t>Clients interested in combating middlebox ossification can initiate a c <t>Clients interested in combating middlebox ossification can initiate
onnection a connection using version 2 if they are reasonably certain the
using version 2 if they are either reasonably certain the server supports it, or server supports it and if they are willing to suffer a round-trip
are willing to suffer a round-trip penalty if they are incorrect. In penalty if they are incorrect. In
particular, a server that issues a session ticket for version 2 indicates an particular, a server that issues a session ticket for version 2 indicates an
intent to maintain version 2 support while the ticket remains valid, even if intent to maintain version 2 support while the ticket remains valid, even if
support cannot be guaranteed.</t> support cannot be guaranteed.</t>
</section> </section>
<section anchor="applicability"> <section anchor="applicability">
<name>Applicability</name> <name>Applicability</name>
<t>This version of QUIC provides no change from QUIC version 1 relating to <t> QUIC version 2 provides no change from QUIC version 1
the for the capabilities available to applications. Therefore, all Application-Laye
capabilities available to applications. Therefore, all Application Layer r
Protocol Negotiation (ALPN) (<xref target="RFC7301"/>) codepoints specified to o Protocol Negotiation (ALPN) <xref target="RFC7301"/> codepoints specified to ope
perate over rate over
QUIC version 1 can also operate over this version of QUIC. In particular, both QUIC version 1 can also operate over this version of QUIC. In particular, both
the "h3" <xref target="H3"/> and "doq" <xref target="RFC9250"/> ALPNs can operat e over the "h3" <xref target="RFC9114"/> and "doq" <xref target="RFC9250"/> ALPNs can o perate over
QUIC version 2.</t> QUIC version 2.</t>
<t>Unless otherwise stated, all QUIC extensions defined to work with versi on 1 also <t>Unless otherwise stated, all QUIC extensions defined to work with versi on 1 also
work with version 2.</t> work with version 2.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>QUIC version 2 introduces no changes to the security or privacy propert ies of <t>QUIC version 2 introduces no changes to the security or privacy propert ies of
QUIC version 1.</t> QUIC version 1.</t>
<t>The mandatory version negotiation mechanism guards against downgrade at tacks, <t>The mandatory version negotiation mechanism guards against downgrade at tacks,
but downgrades have no security implications, as the version properties are but downgrades have no security implications, as the version properties are
identical.</t> identical.</t>
<t>Support for QUIC version 2 can help an observer to fingerprint both cli ent and <t>Support for QUIC version 2 can help an observer to fingerprint both cli ent and
server devices.</t> server devices.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document requests that IANA add the following entry to the QUIC ve rsion <t>IANA has added the following entries to the "QUIC Versions"
registry maintained at registry maintained at
<<eref target="https://www.iana.org/assignments/quic/quic.xhtml#quic-versions "/>&gt;.</t> <eref target="https://www.iana.org/assignments/quic" brackets="angle"/&gt;.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>0x6b3343cf</dd>
<t>0x6b3343cf</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 9369</dd>
<t>This Document</t>
</dd>
<dt>Change Controller:</dt> <dt>Change Controller:</dt>
<dd> <dd>IETF</dd>
<t>IETF</t>
</dd>
<dt>Contact:</dt> <dt>Contact:</dt>
<dd> <dd>QUIC WG</dd>
<t>QUIC WG</t>
</dd>
</dl> </dl>
<dl spacing="compact"> <dl spacing="compact">
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>0x709a50c4</dd>
<t>0x709a50c4</t>
</dd>
<dt>Status:</dt> <dt>Status:</dt>
<dd> <dd>provisional</dd>
<t>provisional</t>
</dd>
<dt>Specification:</dt> <dt>Specification:</dt>
<dd> <dd>RFC 9369</dd>
<t>This Document</t>
</dd>
<dt>Change Controller:</dt> <dt>Change Controller:</dt>
<dd> <dd>IETF</dd>
<t>IETF</t>
</dd>
<dt>Contact:</dt> <dt>Contact:</dt>
<dd> <dd>QUIC WG</dd>
<t>QUIC WG</t> <dt>Notes:</dt>
</dd> <dd>QUIC v2 draft codepoint</dd>
<dt>Note:</dt>
<dd>
<t>QUIC v2 draft codepoint</t>
</dd>
</dl> </dl>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="H3" to="HTTP/3"/> <displayreference target="RFC9000" to="QUIC"/>
<displayreference target="RFC9001" to="QUIC-TLS"/>
<displayreference target="RFC9368" to="QUIC-VN"/>
<displayreference target="RFC9002" to="QUIC-RECOVERY"/>
<displayreference target="RFC9114" to="HTTP/3"/>
<displayreference target="RFC8999" to="QUIC-INVARIANTS"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="QUIC"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.
<front> xml"/>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9001.
<author fullname="J. Iyengar" initials="J." role="editor" surname="I xml"/>
yengar"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9002.
<organization/> xml"/>
</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="QUIC-TLS">
<front>
<title>Using TLS to Secure QUIC</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<author fullname="S. Turner" initials="S." role="editor" surname="Tu
rner">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document describes how Transport Layer Security (TLS) is u
sed to secure QUIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9001"/>
<seriesInfo name="DOI" value="10.17487/RFC9001"/>
</reference>
<reference anchor="QUIC-VN">
<front>
<title>Compatible Version Negotiation for QUIC</title>
<author fullname="David Schinazi" initials="D." surname="Schinazi">
<organization>Google LLC</organization>
</author>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>Mozilla</organization>
</author>
<date day="6" month="November" year="2022"/>
<abstract>
<t> QUIC does not provide a complete version negotiation mechani
sm but
instead only provides a way for the server to indicate that the
version the client chose is unacceptable. This document describes a
version negotiation mechanism that allows a client and server to
select a mutually supported version. Optionally, if the client's
chosen version and the negotiated version share a compatible first
flight format, the negotiation can take place without incurring an
extra round trip. This document updates RFC 8999.
</t> <reference anchor="RFC9368" target="https://www.rfc-editor.org/info/rfc9368">
</abstract> <front>
</front> <title>Compatible Version Negotiation for QUIC</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-version-negot <author initials="D." surname="Schinazi" fullname="David Schinazi">
iation-13"/> <organization>Google LLC</organization>
</reference> </author>
<reference anchor="RFC2119"> <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<front> <organization>Mozilla</organization>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit </author>
le> <date month="May" year="2023"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"> </front>
<organization/> <seriesInfo name="RFC" value="9368"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC9368"/>
<date month="March" year="1997"/> </reference>
<abstract>
<t>In many standards track documents several words are used to sig <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
nify the requirements in the specification. These words are often capitalized. xml"/>
This document defines these words as they should be interpreted in IETF document <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
s. This document specifies an Internet Best Current Practices for the Internet xml"/>
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="QUIC-RECOVERY">
<front>
<title>QUIC Loss Detection and Congestion Control</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar">
<organization/>
</author>
<author fullname="I. Swett" initials="I." role="editor" surname="Swe
tt">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document describes loss detection and congestion control m
echanisms for QUIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9002"/>
<seriesInfo name="DOI" value="10.17487/RFC9002"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="H3"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9114.
<front> xml"/>
<title>HTTP/3</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8999.
<author fullname="M. Bishop" initials="M." role="editor" surname="Bi xml"/>
shop"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7838.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.
<date month="June" year="2022"/> xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9250.
<t>The QUIC transport protocol has several features that are desir xml"/>
able in a transport for HTTP, such as stream multiplexing, per-stream flow contr
ol, and low-latency connection establishment. This document describes a mapping
of HTTP semantics over QUIC. This document also identifies HTTP/2 features tha
t are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP
/3.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9114"/>
<seriesInfo name="DOI" value="10.17487/RFC9114"/>
</reference>
<reference anchor="QUIC-INVARIANTS">
<front>
<title>Version-Independent Properties of QUIC</title>
<author fullname="M. Thomson" initials="M." surname="Thomson">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the properties of the QUIC transport prot
ocol that are common to all versions of the protocol.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8999"/>
<seriesInfo name="DOI" value="10.17487/RFC8999"/>
</reference>
<reference anchor="RFC7838">
<front>
<title>HTTP Alternative Services</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="P. McManus" initials="P." surname="McManus">
<organization/>
</author>
<author fullname="J. Reschke" initials="J." surname="Reschke">
<organization/>
</author>
<date month="April" year="2016"/>
<abstract>
<t>This document specifies "Alternative Services" for HTTP, which
allow an origin's resources to be authoritatively available at a separate networ
k location, possibly accessed with a different protocol configuration.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7838"/>
<seriesInfo name="DOI" value="10.17487/RFC7838"/>
</reference>
<reference anchor="RFC7301">
<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="RFC9250">
<front>
<title>DNS over Dedicated QUIC Connections</title>
<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization/>
</author>
<author fullname="S. Dickinson" initials="S." surname="Dickinson">
<organization/>
</author>
<author fullname="A. Mankin" initials="A." surname="Mankin">
<organization/>
</author>
<date month="May" year="2022"/>
<abstract>
<t>This document describes the use of QUIC to provide transport co
nfidentiality for DNS. The encryption provided by QUIC has similar properties to
those provided by TLS, while QUIC transport eliminates the head-of-line blockin
g issues inherent with TCP and provides more efficient packet-loss recovery than
UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) s
pecified in RFC 7858, and latency characteristics similar to classic DNS over UD
P. This specification describes the use of DoQ as a general-purpose transport fo
r DNS and includes the use of DoQ for stub to recursive, recursive to authoritat
ive, and zone transfer scenarios.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9250"/>
<seriesInfo name="DOI" value="10.17487/RFC9250"/>
</reference>
</references> </references>
</references> </references>
<section anchor="test-vectors"> <section anchor="test-vectors">
<name>Sample Packet Protection</name> <name>Sample Packet Protection</name>
<t>This section shows examples of packet protection so that implementation s can be <t>This section shows examples of packet protection so that implementation s can be
verified incrementally. Samples of Initial packets from both client and server verified incrementally. Samples of Initial packets from both the client and serv er
plus a Retry packet are defined. These packets use an 8-byte client-chosen plus a Retry packet are defined. These packets use an 8-byte client-chosen
Destination Connection ID of 0x8394c8f03e515708. Some intermediate values are Destination Connection ID of 0x8394c8f03e515708. Some intermediate values are
included. All values are shown in hexadecimal.</t> included. All values are shown in hexadecimal.</t>
<section anchor="keys"> <section anchor="keys">
<name>Keys</name> <name>Keys</name>
<t>The labels generated during the execution of the HKDF-Expand-Label fu nction <t>The labels generated during the execution of the HKDF-Expand-Label fu nction
(that is, HkdfLabel.label) and part of the value given to the HKDF-Expand (that is, HkdfLabel.label) and part of the value given to the HKDF-Expand
function in order to produce its output are:</t> function in order to produce its output are:</t>
<t>client in: 00200f746c73313320636c69656e7420696e00</t> <t>client in: 00200f746c73313320636c69656e7420696e00</t>
<t>server in: 00200f746c7331332073657276657220696e00</t> <t>server in: 00200f746c7331332073657276657220696e00</t>
skipping to change at line 610 skipping to change at line 395
0d0010000e0403050306030203080408 050806002d00020101001c0002400100 0d0010000e0403050306030203080408 050806002d00020101001c0002400100
3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000 3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
75300901100f088394c8f03e51570806 048000ffff 75300901100f088394c8f03e51570806 048000ffff
]]></artwork> ]]></artwork>
<t>The unprotected header indicates a length of 1182 bytes: the 4-byte p acket <t>The unprotected header indicates a length of 1182 bytes: the 4-byte p acket
number, 1162 bytes of frames, and the 16-byte authentication tag. The header number, 1162 bytes of frames, and the 16-byte authentication tag. The header
includes the connection ID and a packet number of 2:</t> includes the connection ID and a packet number of 2:</t>
<artwork><![CDATA[ <artwork><![CDATA[
d36b3343cf088394c8f03e5157080000449e00000002 d36b3343cf088394c8f03e5157080000449e00000002
]]></artwork> ]]></artwork>
<t>Protecting the payload produces output that is sampled for header pro tection. <t>Protecting the payload produces an output that is sampled for header protection.
Because the header uses a 4-byte packet number encoding, the first 16 bytes of Because the header uses a 4-byte packet number encoding, the first 16 bytes of
the protected payload is sampled and then applied to the header as follows:</t> the protected payload is sampled and then applied to the header as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
sample = ffe67b6abcdb4298b485dd04de806071 sample = ffe67b6abcdb4298b485dd04de806071
mask = AES-ECB(hp, sample)[0..4] mask = AES-ECB(hp, sample)[0..4]
= 94a0c95e80 = 94a0c95e80
header[0] ^= mask[0] & 0x0f header[0] ^= mask[0] & 0x0f
= d7 = d7
skipping to change at line 682 skipping to change at line 467
02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739 02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739
88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94 88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94
0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00 0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00
020304 020304
]]></artwork> ]]></artwork>
<t>The header from the server includes a new connection ID and a 2-byte packet <t>The header from the server includes a new connection ID and a 2-byte packet
number encoding for a packet number of 1:</t> number encoding for a packet number of 1:</t>
<artwork><![CDATA[ <artwork><![CDATA[
d16b3343cf0008f067a5502a4262b50040750001 d16b3343cf0008f067a5502a4262b50040750001
]]></artwork> ]]></artwork>
<t>As a result, after protection, the header protection sample is taken starting <t>As a result, after protection, the header protection sample is taken, starting
from the third protected byte:</t> from the third protected byte:</t>
<artwork><![CDATA[ <artwork><![CDATA[
sample = 6f05d8a4398c47089698baeea26b91eb sample = 6f05d8a4398c47089698baeea26b91eb
mask = 4dd92e91ea mask = 4dd92e91ea
header = dc6b3343cf0008f067a5502a4262b5004075d92f header = dc6b3343cf0008f067a5502a4262b5004075d92f
]]></artwork> ]]></artwork>
<t>The final protected packet is then:</t> <t>The final protected packet is then:</t>
<artwork><![CDATA[ <artwork><![CDATA[
dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698 dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698
baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17 baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17
skipping to change at line 712 skipping to change at line 497
connection ID value of 0x8394c8f03e515708, but that value is not connection ID value of 0x8394c8f03e515708, but that value is not
included in the final Retry packet:</t> included in the final Retry packet:</t>
<artwork><![CDATA[ <artwork><![CDATA[
cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436 cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436
65dcc7b6 65dcc7b6
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="chacha20-poly1305-short-header-packet"> <section anchor="chacha20-poly1305-short-header-packet">
<name>ChaCha20-Poly1305 Short Header Packet</name> <name>ChaCha20-Poly1305 Short Header Packet</name>
<t>This example shows some of the steps required to protect a packet wit h <t>This example shows some of the steps required to protect a packet wit h
a short header. This example uses AEAD_CHACHA20_POLY1305.</t> a short header. It uses AEAD_CHACHA20_POLY1305.</t>
<t>In this example, TLS produces an application write secret from which a server <t>In this example, TLS produces an application write secret from which a server
uses HKDF-Expand-Label to produce four values: a key, an IV, a header uses HKDF-Expand-Label to produce four values: a key, an Initialization Vector ( IV), a header
protection key, and the secret that will be used after keys are updated (this protection key, and the secret that will be used after keys are updated (this
last value is not used further in this example).</t> last value is not used further in this example).</t>
<artwork><![CDATA[ <artwork><![CDATA[
secret secret
= 9ac312a7f877468ebe69422748ad00a1 = 9ac312a7f877468ebe69422748ad00a1
5443f18203a07d6060f688f30f21632b 5443f18203a07d6060f688f30f21632b
key = HKDF-Expand-Label(secret, "quicv2 key", "", 32) key = HKDF-Expand-Label(secret, "quicv2 key", "", 32)
= 3bfcddd72bcf02541d7fa0dd1f5f9eee = 3bfcddd72bcf02541d7fa0dd1f5f9eee
a817e09a6963a0e6c7df0f9a1bab90f2 a817e09a6963a0e6c7df0f9a1bab90f2
skipping to change at line 763 skipping to change at line 549
sample = e7b6b932bc27d786f4bc2bb20f2162ba sample = e7b6b932bc27d786f4bc2bb20f2162ba
mask = 97580e32bf mask = 97580e32bf
header = 5558b1c6 header = 5558b1c6
]]></artwork> ]]></artwork>
<t>The protected packet is the smallest possible packet size of 21 bytes .</t> <t>The protected packet is the smallest possible packet size of 21 bytes .</t>
<artwork><![CDATA[ <artwork><![CDATA[
packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section anchor="acknowledgments"> <section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The author would like to thank Christian Huitema, Lucas Pardue, Kyle Ro <t>The author would like to thank <contact fullname="Christian Huitema"/>,
se, <contact fullname="Lucas Pardue"/>, <contact fullname="Kyle Rose"/>,
Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa, and Martin <contact fullname="Anthony Rossi"/>, <contact fullname="Zahed Sarker"/>, <contac
Thomson for their helpful suggestions.</t> t fullname="David Schinazi"/>, <contact fullname="Tatsuhiro Tsujikawa"/>, and <c
</section> ontact fullname="Martin
<section anchor="changelog"> Thomson"/> for their helpful suggestions.</t>
<name>Changelog</name>
<ul empty="true">
<li>
<t><strong>RFC Editor's Note:</strong> Please remove this section pri
or to
publication of a final version of this document.</t>
</li>
</ul>
<section anchor="since-draft-ietf-quic-v2-09">
<name>since draft-ietf-quic-v2-09</name>
<ul spacing="normal">
<li>Added note for provisional IANA registration</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-v2-08">
<name>since draft-ietf-quic-v2-08</name>
<ul spacing="normal">
<li>Updated IANA considerations in accordance with new constants</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-v2-07">
<name>since draft-ietf-quic-v2-07</name>
<ul spacing="normal">
<li>Generated new constants and test vectors</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-v2-06">
<name>since draft-ietf-quic-v2-06</name>
<ul spacing="normal">
<li>Clients <bcp14>MUST NOT</bcp14> use TLS resumption tickets across
versions</li>
<li>Servers <bcp14>SHOULD</bcp14> support multiple versions</li>
<li>Clients <bcp14>SHOULD</bcp14> check path support for QUIC independ
ently by version</li>
<li>Minor editorial changes</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-v2-05">
<name>since draft-ietf-quic-v2-05</name>
<ul spacing="normal">
<li>Servers <bcp14>MUST</bcp14> use the negotiated version in Initials
with CRYPTO frames.</li>
<li>Clarified when clients "learn" the negotiated version as required
in the VN
draft.</li>
<li>Comments from SECDIR review.</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-v2-04">
<name>since draft-ietf-quic-v2-04</name>
<ul spacing="normal">
<li>Clarified 0-RTT handling</li>
<li>Editorial comments from Zahed Sarker.</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-v2-03">
<name>since draft-ietf-quic-v2-03</name>
<ul spacing="normal">
<li>a v2 session ticket is an indication of v2 support</li>
<li>a v1-only extension is theoretically possible</li>
<li>editorial fixes</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-v2-02">
<name>since draft-ietf-quic-v2-02</name>
<ul spacing="normal">
<li>Editorial comments from Lucas Pardue</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-v2-01">
<name>since draft-ietf-quic-v2-01</name>
<ul spacing="normal">
<li>Ban use of NEW_TOKEN tokens across versions</li>
<li>version-info transport parameter required for all v2 endpoints</li
>
<li>Explicitly list known ALPN compatibility</li>
</ul>
</section>
<section anchor="since-draft-ietf-quic-v2-00">
<name>since draft-ietf-quic-v2-00</name>
<ul spacing="normal">
<li>Expanded requirements for compatible version negotiation</li>
<li>Added test vectors</li>
<li>Greased the packet type codepoints</li>
<li>Random version number</li>
<li>Clarified requirement to use QUIC-VN</li>
<li>Banned use of resumption tokens across versions</li>
</ul>
</section>
<section anchor="since-draft-duke-quic-v2-02">
<name>since draft-duke-quic-v2-02</name>
<ul spacing="normal">
<li>Converted to adopted draft</li>
<li>Deleted references to QUIC improvements</li>
<li>Clarified status of QUIC extensions</li>
</ul>
</section>
<section anchor="since-draft-duke-quic-v2-01">
<name>since draft-duke-quic-v2-01</name>
<ul spacing="normal">
<li>Made the final version number TBD.</li>
<li>Added ALPN considerations</li>
</ul>
</section>
<section anchor="since-draft-duke-quic-v2-00">
<name>since draft-duke-quic-v2-00</name>
<ul spacing="normal">
<li>Added provisional versions for interop</li>
<li>Change the v1 Retry Tag secret</li>
<li>Change labels to create full key separation</li>
</ul>
</section>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA6186XIcyZHm/3iKWLTZDtkGVOd9YIaaQZNskSY2ySWhlvXK
tG1xJZBCVWUpMwsghkY9yz7LPtl+HhF5FYpE79hSTQrIjMPDw/3zIzzy7OyM
9XW/Nuf8f/z59XP+i2m7utnyiAkpW3PrHt9GTDdqKzZopltR9We16auzf+xr
dXYbnYUBU6I3V017f867XjN0i1m3l5u6o9H6+x06vn55+RMTrRHn/OSyFdtu
17T9Cbtr2purttnv8JjmOmG3Zrs354zz5WPO3Tgnf0GPenvF/0iv6flG1Gs8
J3L+gwhbNe0VPRetusbz677fdec//EDN6FF9a1ZDsx/owQ+ybe468wMN8AN1
vKr76730Q95d/eAXSq/WWGjXz0Z1TexYvtkPD1m0uu436xPGxL6/blpa2xn+
cl5vu3P+84q/2N8Y+8Dx+GfR9vV2eorBz/kfm+ZqbfibN8/tM+NWvbFNV9cr
jcb/cUUPV6rZMLZt2o3osVaajTh4zj/89LwMgsD/fnb55uPwLGSs3lbzHq/i
czvNM9ckDBP7q6673Vpgm19dXr7/IWaMnZ2dcSG7vhWqZ+zyuu44ZGW/Mdue
dzuj6qo2nROu20G4Tvndda2uOdrWGg1rJda8b5atQmY+KbPrOejiXbMxvG/r
2xottemxzG7FX/cd3+3bXdMZGgsjYOlS9PxWtHWz73gD+asweo8BIVeqb9qO
i63m5pNpVY1u/bUZZ9xChPvaNuZVi50g2aRZuFh3De9Me4ulCPzHerPZkShY
4miMTb2tN/sNV9die4VW2D6xvefVvt+30wxNZde4Yuxt09PkoPVkZMsJLUJs
ud+KtZUGPwPe7NoGKyVOUbd6q2lhNFXPaPEgojOqweK6HksUre7OaFduFmxd
8Us0xFB9o5r1uEOaXxvQue9ogWxkyH4jTcsbjE00gLSIFkZT3dVoXm/ElTml
R02rqUnj+FD/p1myvq27m5WTlU2t9dow9h1/ve3bRu+VbcGWe//5M/3+5Qu/
BrtBhmlpO82n3mxtg11Tb/uOplbrvSY0mG0k83RbPjVK7XckgjMG9dcY7uqa
V3XVX3N5T1zE1hj0v+frBqNdG0ELetIZwz5//nerL6/f/nLx4fXF28uPz6AS
RVmWX748hXig46edaWsSeeyOJwJ8BIda/HNqJY6GGBkbQlC3HYB333vKbkXX
Q5n/3rR1fz/ICSReVGDiKTVpnYzT7kF2oDRizUg2HENl88lYDbB8xwjbhWi7
NYr1nbjvuDTEsOBT4P6E2JnX2wPlO8X21DQH30GETO+WY7aqvd/1EJc7QOR8
hjMvSYpDQnuGXdOmU20t0Rby8fnzR2M3mqeraFgeIdCXLyv+HtJIb0HU4aRW
2uqOgW5QvwZM80ZaRWztagGgmLcnSuqWmEqc6UZ8sdLhOYzJ+PN1jffslcFQ
kFn+0Y7E3e8b03WQZ+DKxZWot19jOn/IdHac6SG/MffgA2DLgQrJgVsZd2Db
gfU/1Vus7P4UPPpvliu/vH32+uzFamY/PItn+ATNgA7f1nZxd0Q7AU/dbTor
E2arnYYQj4ZuDuwW24y3UHmHCSfgVrPZYXi5NieTLs1AcWNgvjRXAIJuvyP7
zTsIAkwqtq5qm43FvMMZ8Iw5CBkeWuGp9us1vzJb04o1ZB5aYrcRmwhNgIRg
EqF1TROD6VDYrQae1Tu0Y1aXe5g+aug6bbdOwFb85PnDZSyw3awBUVvhVY/N
ht4ZzAX9k/uer80twYa1PC1sflvb8Tva5evmjm/2ymkA8X9UevCG6bqqsNoO
JtrZtvX96gDgIhKrjcF7B5p9fUUbNAdNWpMy7fahwWLHFjVJgNvOwRB5MSF2
mk8CVssMPPMmi3XGsnHoAD6SIgAJQZnTaugeHt8dGJJXzR0h5infjraMiFPX
Ta3GSQ5Nydx6dIDHrW4263tMDhtOlq/rgbzU+SQ6scDJBhbLmsTZmj7rM4Aq
I7AFc7z2ykWOosUrtxPkipB0TvD7r1xCIj2NnbWHQPCe9pu6jRvj3YnFttBu
UCOsmjmpAP2tgaa2xlJ+hFeMXUAxBq10q/Aa1C3lZ2uMdshGW2W9qCO7zdBg
51CTCwIrqIxu7rZXraCt7nvwgbDlO/682d4StzA2eWfGQhL8Gkxy8vOfP16C
yfb/+dt39ucPL0H4h5cv6OePry7evBl/YL7Fx1fv/vzmxfTT1PP5u59/fvn2
heuMp3zxiJ38fPGr21N+8u795et3by/enAwIPzmNxFssT0JAgObtrjVkb0TH
Fgblx+fv/8//DhMCTRjjKAxhjP0vRZgn+OXu2mzdbM0WO+R+xXbfM7HbGdFa
Fw0QpMSuht2G0YDR6qDZW+sLgXvf/5U487dz/m9S7cLkD/4BLXjxcODZ4qHl
2cMnDzo7Jh55dGSakZuL5wecXtJ78evi94Hvs4ckJS+8nkDzHTgvgkFEBy8n
V1zwCuKtpx6nB979zPpYdk2SPNifmR80uA1etx64Dc4NPPU/OY/B4cJgLmnp
v7z88OszF8pE5FGQoLcUIW0JFayaQ8Q674Ks6653Rn22CtKW78Yl/1SbtXYK
Mzyq6BGNNQOcjkAs+JTJOE5iVdHEeHCHZTjDRpIrAaSCAlaLZFXddsTHfTv5
ndaaXYsozTpEEIR9Lug+AM8TkPgH/v33WCd/CcPYtP/ScYojzr//nvP3ayM6
u+rm1nhnl7whQLE0cJyAF3VjXfTdXq4Hx/wPDrAq8kHmUcpCJVc+rjvA8rsa
2gMU9JaD9gsxfwcknKFWN41GUfEp22/XMC+TbyVA3rW4Jdr8OBYdZWvETccH
j6QmF8Ft0Rti/yuH9+8d3l8C7wFvF+v1TAq/Yhe6pWFwskID+A2+Feu9a3QO
BBgc0nMeSETJ3/Pg7MPlJf0WBvjtFQQRO3dj7BN6/8H0lAVB68BS+5z85Qa4
vLu+H0yskys/kducO+KGN4KDUbTL/W50iT+SX217kodNfpum3bTupRlbAd67
Rxzu0dL3DZb4z3/+E7G/7fybHfgZRQbaaBNrU+VBIDIti7CMi1CazERZqZWs
Sqkjo0vb2wmHd5OdfEfB75Bumu3EL/LVn178xN8IMKP7HUKOIJCi6sHl4GSG
t1d23f/YN73fYxLNbgfBwYD7nYV7qP7WONkaDY9HhZXj7drS4Lg7ApDn28Rt
L0/eBBOXLd+feJ6zOffDJfc/n/sJf7IRwLMTCVpPvjw9HWV1OSgbBl1safJ7
B7XySKG2uaLIkl2KqyWti2GL3zssmVUMw/Y7bf3oI6Nlv3flg95bF82m3Gjo
E2K3/Q2iQr+fugjDNahvF+/x6+L19Y5es+E1fnUkz5rc7Jcz7NGEXHFjnExd
7WstCD3J5sGhYyOgQSwerrZcZb9rtU4jEMLMwJUU4GCfOPZp8teI9C1FA04u
h5zTkT78yTe28ykbEHZQfJAI94o/YxxKrxKto6RIdFaEwlQiqSr8XKpIRUFU
lmWRiDxLRapjFYdlEVVxUak8CbMoTFNTVoxIJfQoKpkALWWaCZUUgIygkkoq
iHeulCoj5tZCTXWRlVkpVYRXmcYkgalkkIgBWGzKhkgcMlzHgKS1fHANTxyg
L7kGzjOnuV4EBsWnkcdMhlf9ucw5Z3UmZAyRICUcMJQFaDa5DG9nwRi87g5R
Siu84/0w9iNwIv8WDoqHcTi6lM+bsgcr/nIK42cRA5sG2tRX171Ne9TbvRmD
chKQycUiqRafXFZuYU/t0n1oPvpsKwgU8A3BkNqvBaI7yvRyZRMnhOcgmaSQ
X6z7s4+3Cirw78DqvIgLi5AIfjvVUFLFrtlTtOIXnWP6GKbCuzCODWrfkiWG
j46+lAXa19017GJ/Z8x2wbrOUzMkgLyjPCx7s1/3NQW4o6pi6QjK9sqFzUBW
KfzSIT5TvsM9EjYz6BMQousaVYsx1TUnY5ETAasvn7/nFUIJCauw4j9R/sVF
2gQ6aFBfke3RtxRhdpQqme/TyXV8AgM88hMRyB5uyNBkmZUjB7nurYNJlLqh
YfUX1FmMgNfpUvSnw7pag+mMy2cM22ldOBseDfNZQVuGrXbwr8SuB4Jt/X34
MPqUzBjlEdz08HVqMhRslhL4bTxxoKTAcCBEoic2CPnaWW56MsS/vHV2GMpC
Ye2oCseC3ynFPlMYY7zrPx8Qjo51gZzvK/iUBxuZaoVglh21qxq3pe7mfRZt
IwtIjvmng+QySqGRFs16zYWKMi82sWaJGVJbg048yDqt2HGkcFmOURsO1OXI
Kg9oELdNjdDbJd/o+GXnXPApwbZAvQ8uCUJWDZj3/MHwiyUOaxmpCy1PIygF
5Xkd2kMSWDsblSTB1BawNJ75hN/lPLizRxiWQabdAM0HHRlExWP6mBQdt/HE
mYaZXFBe3PuvLk9Mkk0RizO8zgk8JYW0cr/3x0mjVs6PXJhTOV5fbSEI3WII
cjcJFhZJ0iGN57oNeQc7iWBTXmtgrT+WmQVgy1S6kwuyFJQtmtwH1jc3xp8K
+VX+fPErJfobfSRhjGkoDeeot11JTmbqPSRxHdm61s4Nd8I8wTjtgW6bnUut
Owrriljpmhp9SjkuQxChxuFIYtc1eWUP86njvpPQHMMTaw3oANYdOPp0uFuJ
6A7On2CwKotBY3qbOvOHUsOFbedlwiaY2MBHm/xwRxB2rtasza3NLH6FuoGP
UzJ1Erx+Tu5oqUZoeP1iClrolfnkfL3TRU6FLSLDfBUPDqIV9pkMAJ/svkHg
+fMPv76/fOdORDEJuLemjaKTOQ/yRs82/V86dmx9SxEb7ITNwB1M0A25kofc
9kR6cUAw2HpZPrIxsIDuqGg4HXSh6SwtwJapHct0p1nd4CYe02aPCZ4IoJCp
7bkwm69jGsAv2e/L4XCnh6e549YfWRJgDsrtzsqP0sbYj87KzycGaQTCLmWs
bPLlmPyNBLuFEa4x519STtq5Uui0tT8entMddHZekM+tuyYL1RiV9cgK3m2d
uzYwmOTM7rSXsod8sRA8GDcSqgkF2SGhDmkXXs4DwSScJTdWtNqi3aEJGVfv
994F1KNidHtFXKbzrftRQ8hsjNki5hFvDD2OSvqPZLwPcql2eeM4FghCykg9
WN98TDau9GI7OXJ2PIvBy750hLewRPM45FrcQjKbUSSGNKedEWygAeDSIdYa
6hTurDsrBpu+ccGOPUYGY9kCkDs6UvPULFV93BfLgODRJU+iQX6iA2nm98Iu
cjA6PhwfVexAbVf+iNge7HGhbBbcTs88CG9HrVpS9XUAoaCRDqM/GMSxu/FM
6e3Lv/x2+e5PL9/yS7KrlCVEo8507hy19qfwi5bWArts13j+7rFhYc9cGo7N
7IVdtD8btOvYrPzpeHfgbByQwG0SGdMyd+B7GKHM56Dz+dodPYvDUGFqd0pD
3tbKnWsK8GfguSVkZhRHZtpagdniSGa/QqY9KyBb5jev2VLaudsPqQDBHzhT
0BOo9t9BHbHGDQfsQ3RJDiijUI/mp3DPuQX2KJt263rQzFOr283eC8tyREvW
bMAZ2AmtW5Ild3hBs+y3oMqGQUNVA51e+yBGbOCZWyEGh8QcYe0ZPXSFYjjr
oTz09ufu+KlloaPJRqgLZrKN2HWDYB2xS0CAsUJoFHcw2or6u/nh6SOJkbGm
YZYEHc43beBKEaPNKs+PZFf8hSH56Zz/idB9v/E+FLkXi/MaG/F673YWzjXt
lE2eCtBmSfV5GQcRsV8LN5bbqbEMpt5S7Zkg+zmdjzQtxSrr+wGB5ise0W48
Tt/QVswKTE4dLsIMwoMxd1gSHlWN2nfDcbrzbAY3Gixjc+1yUuNCfZu+8STX
h9UqLhznem/8XtMws+2CH9Hc0qYOQGEPaE3XO7fTHZZbCzAQf1DQYGvbRkCY
aGQOwmcJMotX967myMV7rRFds4Unc8+VaSmKWURmQ0Ki7k+tWWmNXbH33Lu9
rcgQ/Eitx3wuSgnZvVpxGHk2T4OJYSrnrxGCdA/BcZ55i2Zendgym+1z5R4g
vp8JDVoOMTn2au2QbsSdjQ3YLAp6a1ZXbIzhnZ8uKV8NVw5TGG217mK3o0M+
n9r6/J2Y//7l4EBvKDcb1Q8WfpaUP4R4xDFunwcpETs3sK2fuKUyW+9w+ln7
MZ4d8iCklxfTS/5G3MNAvx/KEudZhScXb96/fUqJbZtojIPwC50ZQIG9TzLl
iaj8bef8EUpBskPTRCacKjnnjVxa8oATD5KglEixOE3pOoRQr+IvX1wiQTf/
OPFJ0DJKAzwmep2/8HViImzSn91JqPW17qi0p+sJVR1zXNJtqHfsXIrKLZGq
Upc5ptAuiz18EVlZQLy3twcEj6WlfUHmXABG2O+GQRo6ogIUqvt52UxTHUbQ
zn/bUClq3yBo/WbRkhVfyq18rZjllFFN1vjYeaJE5kgXlRkMsmaj3jm4LQt8
2Fh1TM7GLBl76KMIqgVZ72waVw7639Bx+RVVppAbbVNsg/WGq+FbaWeRLP9f
X7y9eMD7ZaU0JblMN6TvbAe4Ag7cbT6M1A0NXVXWoX/HWnNVd/RygBaqmOnZ
v/31b0+GOvW7u7sV7JJwVe8ArautTam5qnf6Z/WJqtS/m5ccdk//gBX8QifV
5+x8VukAtkFY9x09BWOxyxRssY/zag56Z1f5wq8ShsOBCngBSVuvTUtt7MUA
Rs+E6umBXdpf/sg+n0O3hcLSn51Y90X1J18W5ORBKdJAJQtyCMSIeARs/58J
sinl8cFt5GoaJiz6GsVU90zeoj0v+uiK8HzpwvvJ0fn8HV0tOPNl6gNGD3lN
qkzqhoMF6wI9PITuGm+dhoobb7dJjqV1r4d8unIJVVua6CmyYx6N6w9E3BtC
tlvvD5OhrrbCQZXF+yn+d8HElhdnVBnghztzJQ/shaGDn9FFnJJaRFPwqYjL
RBVVEJs0TPOgAMnkDFr3Y2O09Semug3mc26gwFaEjC98dVdNSv0JIKLqjUUA
Smn/iY7a5xUAUwGP3rdDgGk+AW2GcwJ6QHULZy8/7cCWM1u+gFhg63yaJ95R
OOWvbnRlX67s2E99HfBUvWpJ5Ff1rUunHgzMhiEXhfY7B9UuQbHvd/ve16wM
iebtOedBEAVBlSeZyuM4jOMoyOJMZWWWZiZP8FuZGSpUGXNUR/vkcZbmUZ7R
v1Of6ZjUdgrxv0WnME/RNM6zmDpJdC5n3epb2ytQB1Mte5V5NutzvfMzfbNP
kdMdF7uVvq5ldoYMpdwQECzLXvwp+MB0e5flybwo5pSrWj91F2I45ohMIWOl
C51GQRllYSILkKEDIcJK2mac5yoysVBhGVd5IaMiMHmkiyrN07DKhHxwxN1Z
C7SbauH9Rs7q7z3d7sVvS/I9cQ8E8smy2Sk/GQWEyjTxN46GlYWJUaXOjCwr
nYuqiGWViiwrpApzkZvIr6wAqzMBBcqN0kFRhlUeVGVV5VUiqySXzFcCPKTl
KOWnB2UeRFOYDTQVMhQBCIjCqEiiMhBRaYIyD2WKuZNUM1bfHl/4I5PZmhE7
17h+WklsojgNsVGiDLMsMGVQwtpd7/5Lc9jCk+V6klSWqQlTzKKzKgF/ZVgq
qWQQlYkU5aNi4XX1oVi4F/9lsRgx4IFYBFEWaxnmRZTHIXY4LQpsfaLLWEIP
49KLRZArWUApAB8y1SJNRSF1graiUnGuwq+LxVHKHxGLSEuofJGFOgU7dRCG
VVgaAS1MdSTyr4vFI5MdEQutw1gB/5KyVEGUlBrAE2Rp9HWxeGSOI2JhdJXp
IFVFTJIehDKJMxMCzPK0jFXs0cIevjr1HSz15+86a77PvEX1c35ZpE/9weX2
wL4jyqVG+60XL0Nm6X7duAp8d+nMNmSLg8PJI52feJxy6xCYrb1a9f7ixYvX
b/84HOrYqJcS1iwMs8i5AH4qL70BkD4JKjIj+GN0EMPcywp6mGZVGJU8LqE4
RSLiosySPDIqCaQsMjijOjZFVrAgqQC4SV4FmYhkViZFouwFpyRE0BjGkGM3
uBouPtmZ7I9kngqWhZnOAxjINDIwlNiRqrKtbMtAkMEq8BekQuKCEJYmLPxb
sjopaMAYCmPQsKn9Gwbjnzgm64reUeJGgPWI80BGqlSCKIdVkAIKlpaV0VLk
aaxNmIcVxLpKwRxlQp7qJDZlCajOE50nmD+SNDYGi8HBgAV6XFqCRyn+Zv51
gScFx6OC1hChoeUJWofEFEsWRohhqWFY0bY6+IOumBGrsL/k9Iv/uQCLqbd9
wkB5EJT2EV4d+m9BxqeeE+DN5dAXQ84yKHxttlfu0kYYFpErMD23ApkMAmVl
1ZUnQ7kgaVMZqhPEsRoGquc6zQ4gbB5HXHmt8GeEiztkiwNXdxNk8HyHCy4V
j7xE63iIlo5wgMQyKY0XjMgxYXYRzp2LO13cDVG59/O8Y8md4rt6wAfFoyv2
o1FiqEnwr939ziW/BsptUhRTn85SimE2MtBmPx7ixIyM8UDEZn1crmI2N+Uv
LXB0g71ygdAzXlUmyyV8IqUlTHwhkyLVMO7akJjmMBwb0d2g4cXLj2cvn//4
5Hp36md9+tdgtUr+5iwQDHgiAgXzWsABdNP+Nfgb/1/POA1AP/53Km6uhuY6
H1qFxWoVhVPTcD6qHzPyjW3Hx7d27DXK95Ren/PRJW0Hpjw2Mp8PfYxxbM45
ic5aGeCogDKYHC6H4mUWpLDMspJhlCtdUTk3oAmGuiwFOrOyKkWsdZJEqYCZ
D8oyUlDUsDCgqtKSw7InAI8yT/IgjSo4hyoKgFURUCpX8MkigFWkkgoQFAGe
8iAvUpmXSYYpIpMWXKSlUGmkjchywBhaxjJN0ySNaOkhzERUxImJK5hbkRc6
xnoDHRYVIC8jS8HRKMoI/mDsk9wIAbRRMeyHItcDEKRkGUZRhRdVCOOaqbhE
rFAKmFZgkgYCKDAiCctMhKGSRiSBqGRmqjRK4dvDoGC6LItSUykTywxhbQZI
NomMc7St8hwuElzRWAuRIxAI4SnGqSwwfYG4pariGKsQJg1kWMD9SeIYwU4Q
FUYrlSisr5A8E6WsVBRlSiQyAWgajK2wY9g6EYkYIAL6TCriSqZhFBeJjCqt
C8QQOWxhlnITxJbV0oShAOE5/sBLiZMsiuJSa5ZVOYjDALBL8I1gLFUp0SeO
8zzWieRJpqNYwUVLDVzRQmUxzKWKYNkQqCDAYVJV2Lwsq1SCnohnYAFDjd0X
ESydrnihElFCMKsw1HkFOdBKyjJQmYT/AiedwZgaUIX1m8TIoEJgh71OskBB
Tssw4DpScZpio8B7iRgkgiQIIVIIe5QjqGJC5apKjM4xfoTwqxIF3OVMgIth
IOKEyzjDDiAUDEVWYSVZKmDDYIdzxCkIHxjsMhgLsaWIDJ6ElHGRBhgA8RnE
PObwGVKpUjAR1KkQ/iv2RMmkymGgE5OyRFch5EPAL4DgwgJHCpubKA35MtA3
HuYGAYOGJw8nA8qJmSC2SRkS2ZVMWKWrIsVb2kIITprnEo4JKA4DSJdIuYoj
GRloTYnl5AJus5RBIYsEWgLxlgybgsAyVRD3NFICMXepC5kXwsDXzoucZ/BO
wRDwWGArNTZKhwK6hfmiEqxgYaJDBHkhHI+qCBNsY6FyKHEcQblVWfIqtkqm
shIMKrF/AaIh7IOUKfSpKlkJEQHLEw0/S5hCiAIAJXPsuEgEGfcwSIEqSsRh
Cm8qgU+EXQGPlIEQQy2ZkBAESDYgJFcF9DdUwBydBMAC6EDIA4wNRy7GTFKT
xxPmVQZvJI5SKfAIfEAgolUBmhAeYqux88CCCNIF7mjNIXiSSATiwSHEWhNg
D1wtaAZiWQ1OJkWUpQbgaiQi8wp4SvgHdoRQ7wLyAP6qFH5hZgBy0Aqonswk
on0jDLAIWA101UUCCYcmJGAFlDaHXkFXQuAp11mJkNLAcw0QLGkjZUI+I/4F
4oowZSoBcABiAooGNUAnB3BAhaECOSEBSRREMA4BeRBck5L0A8lFkUJ3hFIs
J/0ISuw61EQUWQnXVQH4IV8CbqLgEIYISIlOZYF9zRPadQgmlhsXJgsZUA0h
Kd6B9boCJ2MVSgmcg5rHeWU4GA0tL+EhArgwv4AiAjBgUgyAPQxYGGjgSR4g
cpEJohUDvUoTAGkhhRZJxBEugR/QEbBWywCKIzV0tSKpQzQpWYyVp0WI/xDZ
BwSW4BWIjGLAeRimPI+LADALN9lAcBOBJiaVYE0RGATsBuEDjJw2lGmqADCQ
PsQQ0FppVAz2QCalxpyFTmOSEZUJrQDAuaINC2EjWaEJ50shc6wLeqjjsEDg
RxsOvMtDDv6aTJD1MYhByioOYd8gCKWJsa06ZHFCoAfFLCrEJZHKywJGtAzA
g7LI44BDm0UZRVA+GKMiSHWQRxKaCREHqlchQxwThamKNNiXQWiBXnERQ7ik
BH6kAqFoleSasi8F8E1lFciAQQUGpALSrlmqIabA30jCBSjDEhsSJDEBXBVn
AiGMQbiMqTRidGCbISlRiFkN5LNSmYnBB0QlOqhgXGJYhlxQngK7gfg3VOAw
hznBoxDWrgoprwXlCUP8JKEBaVWUTAM1EpgwEKYqsjmCoCIOYb8Qi1UxjyF3
0HWTQzcrpRHB5cBKCcMJ0ZJpDJuVwNbEQLUcQgA9T2A3gfdJAvQtRMWlkHEa
FZEAZpcUnlOWDYPDMmBZITAK2AmUhokPyNLkkFfwLwAcF1h6FPCyzMGpEBuQ
kN+CeDEnNc4ihUWWmWQiLCS5D3gsM2B5UWIxeQR3AnEljPYUkfuvSPjYelFH
6QLvZdA8us5bX1HXmfmHTBClXzz/0xBTL6sKT/2lloPwegihozHStME01muf
pJkNpkGDMjmsWZxLEeoQIoqFAnIK7Keu8rhkBTaAxBYPqjTLtEqTOJClIIQL
MRanSNoGLIai2UUgq7EJCYJPhOfAWeBJUAgAPPAgTBCsigyPYOkLeHbAfNiY
FBIhCVDgK2golwtkmYtjJ6/ZO90P6yl9XOau2x+LzKIjYeEY5vi7zA+it3Bw
xMPREUfQTyaE3MoIcJZBZ4m9OcX3oSP0guhw/v2pLwmeQrHTeRg0P65xARBd
bRJUEmS/aEHFr+Na++u61bNogdZzGD1lCMp1IWBO4YYhSgD7gbvGQJZhao10
wZNNPQIBseWhEbNIRj2+TPSaRenurvCRCMYGfwP3HhmWD+MKAZ/qyArYfAk5
uZuyKKOYgLDIoywmZ6sM0ziFGYMoplVewVVOMA66A3bCnMGjqGwOrYAvA39a
wVyHAbBMVDGgT/FKpLCBERwkoBMsYhLlKTY1x/SgTkZMwSyiFxwRAdMV6ULp
FHJcgINVFCrDtSgRkkj4zxVBBLAUnmJswGdomhIFS6QBNEehiQwQb4IMV3vv
T/jsyd7BQZqN8V35rXRXued4MYTWy3Seq+4+ng70l+Lr8bKgujbqZvmFnOWZ
3FKj3BHV0dO4U/u5FFdFaVu5623jMdxQaOQEZ77K4Tyj+paw5AlEnM6PMqOK
LMkUuVkmRkQY6ZJixjhjWQrXBJHwLEt6LfBfFJy9b9b3QK2Uf7ymU/7FxXG/
AcN3UdxG2Dqz4d5yb3bd9HGP+Vc3ho2yd+gE9cXoTq1sAmk2rs26XLy8ePHb
81cX+C8Kfnv/7s2vRJX79FI/a31qCwnHlI/Yzoto+B32brwTaWHCVXcN1UnM
zvXwVHJ2YGi/PeAORc/R78bc22tqr3+hGief9FreQZ6SZn5iV9hLBWXSX0l1
kGfroOmg1V0L1vyJ/XjTmr5tNRcNf41139rKrnrJgKer+d3U4WRGqBjBdA7l
z5OsgFuXlUkEp7sQsD4i9EcQaZLAKSlgQQTivgxmEFFDUSEaisjcfeNk6utn
DtM5SAwM0VrDZYCkRmlCwa4IAB9VivjIGE+EKCgOLAWdSYrAUNiNyIoSDwL+
YRV962ji0bMIQd46vFeZa0H+qk2hwnx/6yziK4cP08I0nKg8C3QkAcKI6qMM
YAo/IUUMiIhZDOd+EeL7MFBJFSJMLxBtomMGzE11KAuDhd3sfx8N9rb1kgYK
N3Py+kys4WQlWQYPtChNUiKuzfRwqgqfWVcSMaOGgw0LITIAR6UDOLjgc1HM
7NTocDm9nvS53t4261sHTLODNeG+iDRdmbKlVGLLzGYHwPxqjYK/gOY7jScl
UEmMSpUeo6PGbU0Ao5oAMT9p+fseChJ8CkJXGkA3Ho54JhlBHZy5xFanWc0a
MWO/rGqfOvmkecyncoSkhCmyd0lsGax+6u75dYw+w+Gq+nZCLzLQHg7d6P96
eLjjSvylsbcCiK2u2nxJyzQfVa1W5s74L6B4dd9t+eGfZ9OS+RNfrvHUXx4/
aHioFlFRVRDkkh05U4AjREeUaMDGDPua6qbMp94ed4bjc1XvgFD2BZ4jGkH8
j4BEqijXeYEoBT9JRBMEL9H8SH9K9c6G8HfYh09FdnQhe0cVsnJtVvwdfZmC
/FVyCW7q3c4aHDbAtr/aRvbkK/n+pVv4KK2jW1hS5gQsk9XkFsKuFjJU2bSi
rzh8vMOmrA2VH/uVDO/t8ug4JFzus3s7TfF72fodv1A32+ZubfSVv2JKdLlP
qnoZXNc33jcS2xv4AC1dKIdxe7WH2dyIU/5mr6Bc70Wr99CaP92D3A/wdk7Z
xRbDbO/pt64+5f9TXGOlH0V7QydJL6AY+I0uAor/xNtL0Xd7uOYNv+z2f69v
xJ1wNtJ9uBV0NZvOFYoTj+rWVhFW+zXv9ldXhCP20i6zbsr2yqybq/+XT/vM
qsKGj/qg9+yzPr/zoz5wkwAb5MY+/KZvUNLXby406av9vpuvQhhK61yNoq87
dN8S+vZ4BY33Z+8X2M4HxeW1vV/TtO6rGxZ7fWBH3zOl7f7m+DmN/8exaGvR
1fkvJKS+uO6RsTIa6+htGPLN2unezngrR7XNVNbfofdwheWxTxTMJvJNnWO+
E1h/d1iaSt+z2tE3I+znEuRYVItRfq639OEBKzwUEozfGvrmSlM2o3Vxi/nY
9cOxfsB/JWxxcXNllyJ8iSF9bm38zMCJvb938rVxxczF9rHCL2+ZJdcO2mzc
5W/r7358+fzF6w/ocFubu8eEOGELotwNLbqkQxcD8OrlxK7FJHP1f2yOmOYQ
VA16cBdg+Jivnmnl7Vjq7zqFZ/brC9OHbR2qNvCW3IcjR1hF+2lzq/rTo1sb
sW8scI6Dj4wT0jg/+u8VYAkPb589EP7pMkzVHP20w7jdNglDRZqzr8YR2Z8o
5KlJyOljbZxwf2sL65dfMHmE9IC5sYT9ysriQwI08bevRI3wtwAOYAzdRDF6
5hC5701ONxLoM2D2G14HX0xbyOKMGv8ZVu4/PODYTSXcnuNzwDnO8kM20MfA
DyTBfgiydffPuNCN/YqvbY2XL8zafmWxNeNnAIfPcdcbQn3/UYf5AjpbcT3e
HZnuKjxCjZWnn4W/E780Ut5XvPzxxWpkv9/1ZfX8N2cIJtM1t1jjlyZo723t
cLOjFQ1fnYMUhD49QV9S8vHn2MDXBdNXQSEBZBHp1h/Fk50hybYy838BL0rY
RFBfAAA=
</rfc> </rfc>
 End of changes. 57 change blocks. 
750 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.48.