rfc9221.original.xml   rfc9221.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-rfc2629 version 1.5.17 --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc toc="yes"?> -ietf-quic-datagram-10" category="std" obsoletes="" updates="" submissionType="I
<?rfc sortrefs="yes"?> ETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"
<?rfc symrefs="yes"?> consensus="true" number="9221">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-quic-datagram-10" category="std" obsoletes="" updates="" submissionType="I
ETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.11.1 --> <!-- xml2rfc v2v3 conversion 3.11.1 -->
<front> <front>
<title abbrev="QUIC Datagrams">An Unreliable Datagram Extension to QUIC</tit le> <title abbrev="QUIC Datagrams">An Unreliable Datagram Extension to QUIC</tit le>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-datagram-10"/> <seriesInfo name="RFC" value="9221"/>
<author initials="T." surname="Pauly" fullname="Tommy Pauly"> <author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<postal> <postal>
<street>One Apple Park Way</street> <street>One Apple Park Way</street>
<city>Cupertino, California 95014</city> <city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<author initials="E." surname="Kinnear" fullname="Eric Kinnear"> <author initials="E." surname="Kinnear" fullname="Eric Kinnear">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<postal> <postal>
<street>One Apple Park Way</street> <street>One Apple Park Way</street>
<city>Cupertino, California 95014</city> <city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>ekinnear@apple.com</email> <email>ekinnear@apple.com</email>
</address> </address>
</author> </author>
<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, California 94043</city> <city>Mountain View</city>
<region>CA</region>
<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>
<date year="2022" month="February" day="04"/> <date year="2022" month="March"/>
<workgroup>QUIC</workgroup> <workgroup>QUIC</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>quic</keyword>
<keyword>datagram</keyword>
<abstract> <abstract>
<t>This document defines an extension to the QUIC transport protocol to ad d support <t>This document defines an extension to the QUIC transport protocol to ad d support
for sending and receiving unreliable datagrams over a QUIC connection.</t> for sending and receiving unreliable datagrams over a QUIC connection.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<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/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/quicwg/datagram"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The QUIC Transport Protocol <xref target="RFC9000" format="default"/> p rovides a secure, multiplexed <t>The QUIC transport protocol <xref target="RFC9000" format="default"/> p rovides a secure, multiplexed
connection for transmitting reliable streams of application data. QUIC uses connection for transmitting reliable streams of application data. QUIC uses
various frame types to transmit data within packets, and each frame type various frame types to transmit data within packets, and each frame type
defines whether the data it contains will be retransmitted. Streams of reliable defines whether the data it contains will be retransmitted. Streams of reliable
application data are sent using STREAM frames.</t> application data are sent using STREAM frames.</t>
<t>Some applications, particularly those that need to transmit real-time d ata, <t>Some applications, particularly those that need to transmit real-time d ata,
prefer to transmit data unreliably. In the past, these applications have built prefer to transmit data unreliably. In the past, these applications have built
directly upon UDP <xref target="RFC0768" format="default"/> as a transport and h ave often added security directly upon UDP <xref target="RFC0768" format="default"/> as a transport and h ave often added security
with DTLS <xref target="RFC6347" format="default"/>. Extending QUIC to support t ransmitting unreliable with DTLS <xref target="RFC6347" format="default"/>. Extending QUIC to support t ransmitting unreliable
application data provides another option for secure datagrams with the added application data provides another option for secure datagrams with the added
benefit of sharing the cryptographic and authentication context used for benefit of sharing the cryptographic and authentication context used for
reliable streams.</t> reliable streams.</t>
<t>This document defines two new DATAGRAM QUIC frame types which carry app lication <t>This document defines two new DATAGRAM QUIC frame types that carry appl ication
data without requiring retransmissions.</t> data without requiring retransmissions.</t>
<section anchor="specification-of-requirements" numbered="true" toc="defau lt"> <section anchor="specification-of-requirements" numbered="true" toc="defau lt">
<name>Specification of Requirements</name> <name>Specification of Requirements</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " <t>
SHOULD", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
document are to be interpreted as described in BCP 14 <xref target="RFC2119" for NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
mat="default"/> <xref target="RFC8174" format="default"/> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</section> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section> </section>
<section anchor="motivation" numbered="true" toc="default"> <section anchor="motivation" numbered="true" toc="default">
<name>Motivation</name> <name>Motivation</name>
<t>Transmitting unreliable data over QUIC provides benefits over existing solutions:</t> <t>Transmitting unreliable data over QUIC provides benefits over existing solutions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Applications that want to use both a reliable stream and an unreliab le flow to <li>Applications that want to use both a reliable stream and an unreliab le flow to
the same peer can benefit by sharing a single handshake and authentication the same peer can benefit by sharing a single handshake and authentication
context between a reliable QUIC stream and a flow of unreliable QUIC context between a reliable QUIC stream and a flow of unreliable QUIC
datagrams. This can reduce the latency required for handshakes compared to datagrams. This can reduce the latency required for handshakes compared to
opening both a TLS connection and a DTLS connection.</li> opening both a TLS connection and a DTLS connection.</li>
<li>QUIC uses a more nuanced loss recovery mechanism than the DTLS hands hake. This <li>QUIC uses a more nuanced loss recovery mechanism than the DTLS hands hake. This
can allow loss recovery to occur more quickly for QUIC data.</li> can allow loss recovery to occur more quickly for QUIC data.</li>
<li>QUIC datagrams are subject to QUIC congestion control. Providing a s ingle <li>QUIC datagrams are subject to QUIC congestion control. Providing a s ingle
congestion control for both reliable and unreliable data can be more effective congestion control for both reliable and unreliable data can be more effective
and efficient.</li> and efficient.</li>
</ul> </ul>
<t>These features can be useful for optimizing audio/video streaming appli cations, <t>These features can be useful for optimizing audio/video streaming appli cations,
gaming applications, and other real-time network applications.</t> gaming applications, and other real-time network applications.</t>
<t>Unreliable QUIC datagrams can also be used to implement an IP packet tu nnel over <t>Unreliable QUIC datagrams can also be used to implement an IP packet tu nnel over
QUIC, such as for a Virtual Private Network (VPN). Internet-layer tunneling QUIC, such as for a Virtual Private Network (VPN). Internet-layer tunnelin g
protocols generally require a reliable and authenticated handshake followed by protocols generally require a reliable and authenticated handshake followed by
unreliable secure transmission of IP packets. This can, for example, require a unreliable secure transmission of IP packets. This can, for example, require a
TLS connection for the control data and DTLS for tunneling IP packets. A single TLS connection for the control data and DTLS for tunneling IP packets. A single
QUIC connection could support both parts with the use of unreliable datagrams QUIC connection could support both parts with the use of unreliable datagrams
in addition to reliable streams.</t> in addition to reliable streams.</t>
</section> </section>
<section anchor="transport-parameter" numbered="true" toc="default"> <section anchor="transport-parameter" numbered="true" toc="default">
<name>Transport Parameter</name> <name>Transport Parameter</name>
<t>Support for receiving the DATAGRAM frame types is advertised by means o f a QUIC <t>Support for receiving the DATAGRAM frame types is advertised by means o f a QUIC
Transport Parameter (name=max_datagram_frame_size, value=0x20). The transport parameter (name=max_datagram_frame_size, value=0x20). The
max_datagram_frame_size transport parameter is an integer value (represented as max_datagram_frame_size transport parameter is an integer value (represented as
a variable-length integer) that represents the maximum size of a DATAGRAM frame a variable-length integer) that represents the maximum size of a DATAGRAM frame
(including the frame type, length, and payload) the endpoint is willing to (including the frame type, length, and payload) the endpoint is willing to
receive, in bytes.</t> receive, in bytes.</t>
<t>The default for this parameter is 0, which indicates that the endpoint does not <t>The default for this parameter is 0, which indicates that the endpoint does not
support DATAGRAM frames. A value greater than 0 indicates that the endpoint support DATAGRAM frames. A value greater than 0 indicates that the endpoint
supports the DATAGRAM frame types and is willing to receive such frames on this supports the DATAGRAM frame types and is willing to receive such frames on this
connection.</t> connection.</t>
<t>An endpoint MUST NOT send DATAGRAM frames until it has received the <t>An endpoint <bcp14>MUST NOT</bcp14> send DATAGRAM frames until it has r eceived the
max_datagram_frame_size transport parameter with a non-zero value during the max_datagram_frame_size transport parameter with a non-zero value during the
handshake (or during a previous handshake if 0-RTT is used). An endpoint MUST handshake (or during a previous handshake if 0-RTT is used). An endpoint <bcp14>
NOT send DATAGRAM frames that are larger than the max_datagram_frame_size value MUST
NOT</bcp14> send DATAGRAM frames that are larger than the max_datagram_frame_siz
e value
it has received from its peer. An endpoint that receives a DATAGRAM frame when it has received from its peer. An endpoint that receives a DATAGRAM frame when
it has not indicated support via the transport parameter MUST terminate the it has not indicated support via the transport parameter <bcp14>MUST</bcp14> ter minate the
connection with an error of type PROTOCOL_VIOLATION. Similarly, an endpoint that connection with an error of type PROTOCOL_VIOLATION. Similarly, an endpoint that
receives a DATAGRAM frame that is larger than the value it sent in its receives a DATAGRAM frame that is larger than the value it sent in its
max_datagram_frame_size transport parameter MUST terminate the connection with max_datagram_frame_size transport parameter <bcp14>MUST</bcp14> terminate the co nnection with
an error of type PROTOCOL_VIOLATION.</t> an error of type PROTOCOL_VIOLATION.</t>
<t>For most uses of DATAGRAM frames, it is RECOMMENDED to send a value of 65535 in <t>For most uses of DATAGRAM frames, it is <bcp14>RECOMMENDED</bcp14> to s end a value of 65535 in
the max_datagram_frame_size transport parameter to indicate that this endpoint the max_datagram_frame_size transport parameter to indicate that this endpoint
will accept any DATAGRAM frame that fits inside a QUIC packet.</t> will accept any DATAGRAM frame that fits inside a QUIC packet.</t>
<t>The max_datagram_frame_size transport parameter is a unidirectional lim it and <t>The max_datagram_frame_size transport parameter is a unidirectional lim it and
indication of support of DATAGRAM frames. Application protocols that use indication of support of DATAGRAM frames. Application protocols that use
DATAGRAM frames MAY choose to only negotiate and use them in a single direction. DATAGRAM frames <bcp14>MAY</bcp14> choose to only negotiate and use them in a si
</t> ngle direction.</t>
<t>When clients use 0-RTT, they MAY store the value of the server's <t>When clients use 0-RTT, they <bcp14>MAY</bcp14> store the value of the
server's
max_datagram_frame_size transport parameter. Doing so allows the client to send max_datagram_frame_size transport parameter. Doing so allows the client to send
DATAGRAM frames in 0-RTT packets. When servers decide to accept 0-RTT data, DATAGRAM frames in 0-RTT packets. When servers decide to accept 0-RTT data,
they MUST send a max_datagram_frame_size transport parameter greater than or they <bcp14>MUST</bcp14> send a max_datagram_frame_size transport parameter grea ter than or
equal to the value they sent to the client in the connection where they sent equal to the value they sent to the client in the connection where they sent
them the NewSessionTicket message. If a client stores the value of the them the NewSessionTicket message. If a client stores the value of the
max_datagram_frame_size transport parameter with their 0-RTT state, they MUST max_datagram_frame_size transport parameter with their 0-RTT state, they <bcp14> MUST</bcp14>
validate that the new value of the max_datagram_frame_size transport parameter validate that the new value of the max_datagram_frame_size transport parameter
sent by the server in the handshake is greater than or equal to the stored sent by the server in the handshake is greater than or equal to the stored
value; if not, the client MUST terminate the connection with error value; if not, the client <bcp14>MUST</bcp14> terminate the connection with erro r
PROTOCOL_VIOLATION.</t> PROTOCOL_VIOLATION.</t>
<t>Application protocols that use datagrams MUST define how they react to the <t>Application protocols that use datagrams <bcp14>MUST</bcp14> define how they react to the
absence of the max_datagram_frame_size transport parameter. If datagram support absence of the max_datagram_frame_size transport parameter. If datagram support
is integral to the application, the application protocol can fail the handshake is integral to the application, the application protocol can fail the handshake
if the max_datagram_frame_size transport parameter is not present.</t> if the max_datagram_frame_size transport parameter is not present.</t>
</section> </section>
<section anchor="datagram-frame-types" numbered="true" toc="default"> <section anchor="datagram-frame-types" numbered="true" toc="default">
<name>Datagram Frame Types</name> <name>Datagram Frame Types</name>
<t>DATAGRAM frames are used to transmit application data in an unreliable manner. <t>DATAGRAM frames are used to transmit application data in an unreliable manner.
The Type field in the DATAGRAM frame takes the form 0b0011000X (or the values The Type field in the DATAGRAM frame takes the form 0b0011000X (or the values
0x30 and 0x31). The least significant bit of the Type field in the DATAGRAM 0x30 and 0x31). The least significant bit of the Type field in the DATAGRAM
frame is the LEN bit (0x01), which indicates whether there is a Length field frame is the LEN bit (0x01), which indicates whether there is a Length field
present: if this bit is set to 0, the Length field is absent and the Datagram present: if this bit is set to 0, the Length field is absent and the Datagram
Data field extends to the end of the packet; if this bit is set to 1, the Data field extends to the end of the packet; if this bit is set to 1, the
Length field is present.</t> Length field is present.</t>
<t>DATAGRAM frames are structured as follows:</t> <t>DATAGRAM frames are structured as follows:</t>
<figure anchor="datagram-format"> <figure anchor="datagram-format">
<name>DATAGRAM Frame Format</name> <name>DATAGRAM Frame Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<artwork name="" type="" align="left">
DATAGRAM Frame { DATAGRAM Frame {
Type (i) = 0x30..0x31, Type (i) = 0x30..0x31,
[Length (i)], [Length (i)],
Datagram Data (..), Datagram Data (..),
} }
]]></artwork> </artwork>
</figure> </figure>
<t>DATAGRAM frames contain the following fields:</t> <t>DATAGRAM frames contain the following fields:</t>
<dl> <dl>
<dt> <dt>
Length: </dt> Length: </dt>
<dd> <dd>
<t>A variable-length integer specifying the length of the Datagram Dat a field in <t>A variable-length integer specifying the length of the Datagram Dat a field in
bytes. This field is present only when the LEN bit is set to 1. When the LEN bit bytes. This field is present only when the LEN bit is set to 1. When the LEN bit
is set to 0, the Datagram Data field extends to the end of the QUIC packet. Note is set to 0, the Datagram Data field extends to the end of the QUIC packet. Note
that empty (i.e., zero-length) datagrams are allowed.</t> that empty (i.e., zero-length) datagrams are allowed.</t>
skipping to change at line 204 skipping to change at line 205
Datagram Data: </dt> Datagram Data: </dt>
<dd> <dd>
<t>The bytes of the datagram to be delivered.</t> <t>The bytes of the datagram to be delivered.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="behavior-and-usage" numbered="true" toc="default"> <section anchor="behavior-and-usage" numbered="true" toc="default">
<name>Behavior and Usage</name> <name>Behavior and Usage</name>
<t>When an application sends a datagram over a QUIC connection, QUIC will generate <t>When an application sends a datagram over a QUIC connection, QUIC will generate
a new DATAGRAM frame and send it in the first available packet. This frame a new DATAGRAM frame and send it in the first available packet. This frame
SHOULD be sent as soon as possible (as determined by factors like congestion <bcp14>SHOULD</bcp14> be sent as soon as possible (as determined by factors like
control, described below) and MAY be coalesced with other frames.</t> congestion
<t>When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD deliver control, described below) and <bcp14>MAY</bcp14> be coalesced with other frames.
the data </t>
<t>When a QUIC endpoint receives a valid DATAGRAM frame, it <bcp14>SHOULD<
/bcp14> deliver the data
to the application immediately, as long as it is able to process the frame and to the application immediately, as long as it is able to process the frame and
can store the contents in memory.</t> can store the contents in memory.</t>
<t>Like STREAM frames, DATAGRAM frames contain application data and MUST b e <t>Like STREAM frames, DATAGRAM frames contain application data and <bcp14 >MUST</bcp14> be
protected with either 0-RTT or 1-RTT keys.</t> protected with either 0-RTT or 1-RTT keys.</t>
<t>Note that while the max_datagram_frame_size transport parameter places a limit <t>Note that while the max_datagram_frame_size transport parameter places a limit
on the maximum size of DATAGRAM frames, that limit can be further reduced by the on the maximum size of DATAGRAM frames, that limit can be further reduced by the
max_udp_payload_size transport parameter and the Maximum Transmission Unit max_udp_payload_size transport parameter and the Maximum Transmission Unit
(MTU) of the path between endpoints. DATAGRAM frames cannot be fragmented; (MTU) of the path between endpoints. DATAGRAM frames cannot be fragmented;
therefore, application protocols need to handle cases where the maximum therefore, application protocols need to handle cases where the maximum
datagram size is limited by other factors.</t> datagram size is limited by other factors.</t>
<section anchor="multiplexing-datagrams" numbered="true" toc="default"> <section anchor="multiplexing-datagrams" numbered="true" toc="default">
<name>Multiplexing Datagrams</name> <name>Multiplexing Datagrams</name>
<t>DATAGRAM frames belong to a QUIC connection as a whole, and are not a ssociated <t>DATAGRAM frames belong to a QUIC connection as a whole and are not as sociated
with any stream ID at the QUIC layer. However, it is expected that applications with any stream ID at the QUIC layer. However, it is expected that applications
will want to differentiate between specific DATAGRAM frames by using will want to differentiate between specific DATAGRAM frames by using
identifiers, such as for logical flows of datagrams or to distinguish between identifiers, such as for logical flows of datagrams or to distinguish between
different kinds of datagrams.</t> different kinds of datagrams.</t>
<t>Identifiers used to multiplex different kinds of datagrams, or flows <t>Defining the identifiers used to multiplex different kinds of datagra
of ms or flows of datagrams is the responsibility of the application protocol runni
datagrams, are the responsibility of the application protocol running over QUIC ng over QUIC. The application defines the semantics of the Datagram Data field a
to define. The application defines the semantics of the Datagram Data field and nd
how it is parsed.</t> how it is parsed.</t>
<t>If the application needs to support the coexistence of multiple flows of <t>If the application needs to support the coexistence of multiple flows of
datagrams, one recommended pattern is to use a variable-length integer at the datagrams, one recommended pattern is to use a variable-length integer at the
beginning of the Datagram Data field. This is a simple approach that allows a beginning of the Datagram Data field. This is a simple approach that allows a
large number of flows to be encoded using minimal space.</t> large number of flows to be encoded using minimal space.</t>
<t>QUIC implementations SHOULD present an API to applications to assign relative <t>QUIC implementations <bcp14>SHOULD</bcp14> present an API to applicat ions to assign relative
priorities to DATAGRAM frames with respect to each other and to QUIC streams.</t > priorities to DATAGRAM frames with respect to each other and to QUIC streams.</t >
</section> </section>
<section anchor="acknowledgement-handling" numbered="true" toc="default"> <section anchor="acknowledgement-handling" numbered="true" toc="default">
<name>Acknowledgement Handling</name> <name>Acknowledgement Handling</name>
<t>Although DATAGRAM frames are not retransmitted upon loss detection, t hey are <t>Although DATAGRAM frames are not retransmitted upon loss detection, t hey are
ack-eliciting (<xref target="RFC9002" format="default"/>). Receivers SHOULD supp ort delaying ACK frames ack-eliciting (<xref target="RFC9002" format="default"/>). Receivers <bcp14>SHOU LD</bcp14> support delaying ACK frames
(within the limits specified by max_ack_delay) in response to receiving packets (within the limits specified by max_ack_delay) in response to receiving packets
that only contain DATAGRAM frames, since the sender takes no action if these that only contain DATAGRAM frames, since the sender takes no action if these
packets are temporarily unacknowledged. Receivers will continue to send ACK packets are temporarily unacknowledged. Receivers will continue to send ACK
frames when conditions indicate a packet might be lost, since the packet's frames when conditions indicate a packet might be lost, since the packet's
payload is unknown to the receiver, and when dictated by max_ack_delay or other payload is unknown to the receiver, and when dictated by max_ack_delay or other
protocol components.</t> protocol components.</t>
<t>As with any ack-eliciting frame, when a sender suspects that a packet containing <t>As with any ack-eliciting frame, when a sender suspects that a packet containing
only DATAGRAM frames has been lost, it sends probe packets to elicit a faster only DATAGRAM frames has been lost, it sends probe packets to elicit a faster
acknowledgement as described in <xref section="6.2.4" sectionFormat="of" target= "RFC9002" format="default"/>.</t> acknowledgement as described in <xref section="6.2.4" sectionFormat="of" target= "RFC9002" format="default"/>.</t>
<t>If a sender detects that a packet containing a specific DATAGRAM fram e might <t>If a sender detects that a packet containing a specific DATAGRAM fram e might
have been lost, the implementation MAY notify the application that it believes have been lost, the implementation <bcp14>MAY</bcp14> notify the application tha t it believes
the datagram was lost.</t> the datagram was lost.</t>
<t>Similarly, if a packet containing a DATAGRAM frame is acknowledged, t he <t>Similarly, if a packet containing a DATAGRAM frame is acknowledged, t he
implementation MAY notify the sender application that the datagram was implementation <bcp14>MAY</bcp14> notify the sender application that the datagra m was
successfully transmitted and received. Due to reordering, this can include a successfully transmitted and received. Due to reordering, this can include a
DATAGRAM frame that was thought to be lost, but which at a later point was DATAGRAM frame that was thought to be lost but, at a later point, was
received and acknowledged. It is important to note that acknowledgement of a received and acknowledged. It is important to note that acknowledgement of a
DATAGRAM frame only indicates that the transport-layer handling on the receiver DATAGRAM frame only indicates that the transport-layer handling on the receiver
processed the frame, and does not guarantee that the application on the receiver processed the frame and does not guarantee that the application on the receiver
successfully processed the data. Thus, this signal cannot replace successfully processed the data. Thus, this signal cannot replace
application-layer signals that indicate successful processing.</t> application-layer signals that indicate successful processing.</t>
</section> </section>
<section anchor="flow-control" numbered="true" toc="default"> <section anchor="flow-control" numbered="true" toc="default">
<name>Flow Control</name> <name>Flow Control</name>
<t>DATAGRAM frames do not provide any explicit flow control signaling, a nd do not <t>DATAGRAM frames do not provide any explicit flow control signaling an d do not
contribute to any per-flow or connection-wide data limit.</t> contribute to any per-flow or connection-wide data limit.</t>
<t>The risk associated with not providing flow control for DATAGRAM fram es is that <t>The risk associated with not providing flow control for DATAGRAM fram es is that
a receiver might not be able to commit the necessary resources to process the a receiver might not be able to commit the necessary resources to process the
frames. For example, it might not be able to store the frame contents in memory. frames. For example, it might not be able to store the frame contents in memory.
However, since DATAGRAM frames are inherently unreliable, they MAY be dropped by However, since DATAGRAM frames are inherently unreliable, they <bcp14>MAY</bcp14 > be dropped by
the receiver if the receiver cannot process them.</t> the receiver if the receiver cannot process them.</t>
</section> </section>
<section anchor="congestion-control" numbered="true" toc="default"> <section anchor="congestion-control" numbered="true" toc="default">
<name>Congestion Control</name> <name>Congestion Control</name>
<t>DATAGRAM frames employ the QUIC connection's congestion controller. A s a result, <t>DATAGRAM frames employ the QUIC connection's congestion controller. A s a result,
a connection might be unable to send a DATAGRAM frame generated by the a connection might be unable to send a DATAGRAM frame generated by the
application until the congestion controller allows it <xref target="RFC9002" for mat="default"/>. The sender application until the congestion controller allows it <xref target="RFC9002" for mat="default"/>. The sender
MUST either delay sending the frame until the controller allows it or drop the <bcp14>MUST</bcp14> either delay sending the frame until the controller allows i
frame without sending it (at which point it MAY notify the application). t or drop the
frame without sending it (at which point it <bcp14>MAY</bcp14> notify the applic
ation).
Implementations that use packet pacing (<xref section="7.7" sectionFormat="of" t arget="RFC9002" format="default"/>) can also Implementations that use packet pacing (<xref section="7.7" sectionFormat="of" t arget="RFC9002" format="default"/>) can also
delay the sending of DATAGRAM frames to maintain consistent packet pacing.</t> delay the sending of DATAGRAM frames to maintain consistent packet pacing .</t>
<t>Implementations can optionally support allowing the application to sp ecify a <t>Implementations can optionally support allowing the application to sp ecify a
sending expiration time beyond which a congestion-controlled DATAGRAM frame sending expiration time beyond which a congestion-controlled DATAGRAM frame
ought to be dropped without transmission.</t> ought to be dropped without transmission.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The DATAGRAM frame shares the same security properties as the rest of t he data <t>The DATAGRAM frame shares the same security properties as the rest of t he data
transmitted within a QUIC connection, and the security considerations of transmitted within a QUIC connection, and the security considerations of
<xref target="RFC9000" format="default"/> apply accordingly. All application dat a transmitted with the <xref target="RFC9000" format="default"/> apply accordingly. All application dat a transmitted with the
DATAGRAM frame, like the STREAM frame, MUST be protected either by 0-RTT or DATAGRAM frame, like the STREAM frame, <bcp14>MUST</bcp14> be protected either b y 0-RTT or
1-RTT keys.</t> 1-RTT keys.</t>
<t>Application protocols that allow DATAGRAM frames to be sent in 0-RTT re quire a <t>Application protocols that allow DATAGRAM frames to be sent in 0-RTT re quire a
profile that defines acceptable use of 0-RTT; see <xref section="5.6" sectionFor mat="of" target="RFC9001" format="default"/>.</t> profile that defines acceptable use of 0-RTT; see <xref section="5.6" sectionFor mat="of" target="RFC9001" format="default"/>.</t>
<t>The use of DATAGRAM frames might be detectable by an adversary on path that is <t>The use of DATAGRAM frames might be detectable by an adversary on path that is
capable of dropping packets. Since DATAGRAM frames do not use transport-level capable of dropping packets. Since DATAGRAM frames do not use transport-level
retransmission, connections that use DATAGRAM frames might be distinguished from retransmission, connections that use DATAGRAM frames might be distinguished from
other connections due to their different response to packet loss.</t> other connections due to their different response to packet loss.</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="quic-transport-parameter" numbered="true" toc="default"> <section anchor="quic-transport-parameter" numbered="true" toc="default">
<name>QUIC Transport Parameter</name> <name>QUIC Transport Parameter</name>
<t>This document registers a new value in the QUIC Transport Parameter R egistry <t>This document registers a new value in the "QUIC Transport Parameters " registry
maintained at maintained at
<eref target="https://www.iana.org/assignments/quic/quic.xhtml#quic-transport"/> <eref target="https://www.iana.org/assignments/quic" brackets="angle"/>.</t>
.</t> <dl spacing="compact">
<dl>
<dt> <dt>
Value: </dt> Value: </dt>
<dd> <dd>
<t>0x20</t> 0x20
</dd> </dd>
<dt> <dt>
Parameter Name: </dt> Parameter Name: </dt>
<dd> <dd>
<t>max_datagram_frame_size</t> max_datagram_frame_size
</dd> </dd>
<dt> <dt>
Status: </dt> Status: </dt>
<dd> <dd>
<t>permanent</t> permanent
</dd> </dd>
<dt> <dt>
Specification: </dt> Specification: </dt>
<dd> <dd>
<t>This document</t> RFC 9221
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="quic-frame-types" numbered="true" toc="default"> <section anchor="quic-frame-types" numbered="true" toc="default">
<name>QUIC Frame Types</name> <name>QUIC Frame Types</name>
<t>This document registers two new values in the QUIC Frame Type registr y <t>This document registers two new values in the "QUIC Frame Types" regi stry
maintained at maintained at
<eref target="https://www.iana.org/assignments/quic/quic.xhtml#quic-frame-types" <eref target="https://www.iana.org/assignments/quic" brackets="angle"/>.</t>
/>.</t> <dl spacing="compact">
<dl>
<dt> <dt>
Value: </dt> Value: </dt>
<dd> <dd>
<t>0x30 and 0x31 (if this document is approved)</t> 0x30-0x31
</dd> </dd>
<dt> <dt>
Frame Name: </dt> Frame Name: </dt>
<dd> <dd>
<t>DATAGRAM</t> DATAGRAM
</dd> </dd>
<dt> <dt>
Status: </dt> Status: </dt>
<dd> <dd>
<t>permanent</t> permanent
</dd> </dd>
<dt> <dt>
Specification: </dt> Specification: </dt>
<dd> <dd>
<t>This document</t> RFC 9221
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="acknowledgments" numbered="true" toc="default">
<name>Acknowledgments</name>
<t>The original proposal for this work came from Ian Swett.</t>
<t>This document had reviews and input from many contributors in the IETF
QUIC
Working Group, with substantive input from Nick Banks, Lucas Pardue, Rui Paulo,
Martin Thomson, Victor Vasiliev, and Chris Wood.</t>
</section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC9001"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.9001.xml"/>
<title>Using TLS to Secure QUIC</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author fullname="M. Thomson" initials="M." role="editor" surname="T FC.9000.xml"/>
homson"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization/> FC.2119.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author fullname="S. Turner" initials="S." role="editor" surname="Tu FC.8174.xml"/>
rner"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization/> FC.9002.xml"/>
</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="RFC9000">
<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="RFC9002">
<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="RFC0768"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.0768.xml"/>
<title>User Datagram Protocol</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author fullname="J. Postel" initials="J." surname="Postel"> FC.6347.xml"/>
<organization/>
</author>
<date month="August" year="1980"/>
</front>
<seriesInfo name="STD" value="6"/>
<seriesInfo name="RFC" value="768"/>
<seriesInfo name="DOI" value="10.17487/RFC0768"/>
</reference>
<reference anchor="RFC6347">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<author fullname="N. Modadugu" initials="N." surname="Modadugu">
<organization/>
</author>
<date month="January" year="2012"/>
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport L
ayer Security (DTLS) protocol. The DTLS protocol provides communications privac
y for datagram protocols. The protocol allows client/server applications to com
municate in a way that is designed to prevent eavesdropping, tampering, or messa
ge forgery. The DTLS protocol is based on the Transport Layer Security (TLS) pr
otocol and provides equivalent security guarantees. Datagram semantics of the u
nderlying transport are preserved by the DTLS protocol. This document updates D
TLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6347"/>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
</reference>
</references> </references>
</references> </references>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The original proposal for this work came from <contact fullname="Ian Sw
ett"/>.</t>
<t>This document had reviews and input from many contributors in the IETF
QUIC
Working Group, with substantive input from <contact fullname="Nick Banks"/>, <co
ntact fullname="Lucas Pardue"/>, <contact fullname="Rui Paulo"/>,
<contact fullname="Martin Thomson"/>, <contact fullname="Victor Vasiliev"/>, and
<contact fullname="Chris Wood"/>.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAMak/WEAA81bW3Mbt5J+x6/A2g+RqiiachznRKnURseyE9WRL2vJzm6l
Ui5wBiSxGg64cxHNuJzfvl93AzOYIeVdn9qHfbBFzgXoe3/dDZ6cnKjGNYU9
0+elfldWtnBmXlh9YRqzrMxaP//Y2LJ2vtSN1//27vKZMvN5Ze/O+Ev3XK1y
n5VmjYXyyiyaE2ebxcl/tS47ycMjJ6czhc/2TGX4f+mr3Zmum1xtl7KWurNl
i7taLyvfbs70A7r6AN+b3QbrPvjNV7euXOpf6DZdXxtX4Drt8jPtN/XVkq6b
Klvh+qppNvXZo0f0GF1yd3YaH3tEFx7NK7+t7SNa4BG9uHTNqp2HJbfLR5F0
uleA6LpJlpVnpvLO1Pnu6Uf3SWC6atbFA6XcpjrTTdXWzePZ7IfZY3Vrd1tf
5Wf6smxsVdrm5IKWUKpuTJl/MIUvIYCdrdXGnenfG59NdO2rprKLGp92a/rw
h1KmbVa+IhGe4J/WrqzP9M1UvzFtseMroqIbv17vkqsQCAxgs4HiL8tsytdq
rG7B7+vShltvTHWrfzPySuYa6O9Zu7FV40o/0c9M4Ra+Kp3RP3w3O30iT/m2
bEjR70rX2FxfNyRF7Rf6fG0rlxl+yooimw0R9LOhzaaZXw/ZeD7V/3BlaU2V
MPIcawwu///gxN4KSffxcjHV17DH0vzpEmYuzJ3LhzeYnV+8X4Loq6tnA3ZO
n85m2HyzggFag4vM1nbA1Uui2rhSv3d2O+TsyezJt1/PWV4H8tiTfl7SVeZP
lb5amwY+Rub39sWzH2az0zOlTk5OtJmDZpPBnm9WrtaIFO3alo3O7cKV2MqU
2qZhBvxIdMFbZb2BoetN5WH1vqDbJs913W7ougI3urZlTnEBrqIrm1l3R9/a
PphF/wNTd7bSRhbPPHSUNdhzKmSuXZ4XVqmH5IaVz1u+SUQHcm46ct5Ecj59
+hfhdfb5MxEJDRJDoClrKzvR67ZoHGzgo81Vv6Emspm5tWsaorajlbTLlC40
GQ/Ezy8QC1Ohoq0RB+5M5Xxb6wXYshwga5ZcWJOf11tYBnS/MdmtbRAoSEDW
ZKvkLRV1sF1ZiL1i2fPLWAQEk/HgpisKPbegsiPa5rDhntZIvxoTjWBsSUMN
6CZGr2/ePj9/KRTUEPy1ByXJSyBzY+CIWYuYXexAj69B6so0urSwzpRJ7F6c
NG4tFE/UBmGQWBjLoTOF3RSqZRY3pm4m9Kke7q5X5s7qeeuKRuUO1tSAhnYD
Zt5dvIG2/xXann3/9G/QtiE99xZKwuWX/QKmTEYKatkM4ImKVKEvbq6uwxpP
v33y/efPU0mvbL1i8D5a9tA8emPeF3BvdaVnFfpNZ2NihokDMB0kAKZPzW0J
/TekwXoFk8JWdDOrdpvG4w0El4w5o8wCJcaNyTLgsmSLOW2kxvY7vc/Xm62H
Irf64vzm/Je3sATmOzXjLfZc6cxU1S5VjepM2rekemTWSjwnSKqm8EEbP3yo
rzc2c4tILbh7y89bIqUWj0bO1ZR0a/3g5bvrmwcT+atfvebPb5+DsLfPL+jz
9a/nV1fdh/jE9a+v313hvgqf+jefvX758vmrC3kZV/Xo0svz/3gg3vjg9Zub
y9evzq8eIDFA9I5xlEiMHAf2ALdzhApg3BSdYXXQdVa5Ob7gnb8/e6NPn4Q4
9Pj09AdYpnz52+n3Tz5/VnDsUjbzJWxZvkKZLFzkKFrEwL0zs3GNKShM1DAG
vy01jMmSPJFGENhNiIaH7VJskeMra7SzymBiIfbaj67mN2tftOxxlCM4LXcu
yM6+NRAB2IeF6TnsGr42sjGxyzKlYVH4LV4iyAgN12RTG4tdMzwWTX2+60wd
YRp/8N4KS+HirT1g60p31j63zdaSb/ekMK8pPUIDLC4hi9Gt7r1wqtk3iKrK
Is1YJpcAZpntgmmLX/WU4XG/RmTkEIjF/MaWxEOQDUWWJL8IKRfDq5Tm+hSC
+2sPEytbU2ZYtfB1TemT1LTTa5tha1evSRsSMnm1jh7hgYRj2H7A9HAF6M5n
iD6yC+HgW5gf8cQkcELrCOoDFKeLdv6fIDlWHMTCEtg7Bp7KF1PKwLCvVIui
qNGDvCHLqNMGyWZst2IgQqpdLEhed7QgZ8wFAomDQXBMo4SxANxCWK3jaxDn
opWtKPau3Z9MV5ujKCAn8MFC+Gqa6tTywEXxVY7kfYJDTYBgdTt4EvS8GxpZ
IkdRS+0DfZw43RpIRGJLqS/fBGCgmxYWUrB/KloFFUWLCIwwQBwZYMeqaU0B
kVMQsPpVoOXo/ZtXx9O+ZinMjrIvrwauVMRstV7C9yoYSWfcqQuNXM7miTsu
PFkWLs13KtFZSGtp4CeX61hKPGzCTNiPhnif9PurkccwIqPUF+xGsAtIY7Pn
u5GxwT7n0fpGmJJgddHhVDFBAjZJCqbQNgwUnfqUYwThmoCID6TXhykcNZQ/
oQbgqbAhUdyDYfbfmHHTZAshmfyOKp+apQzHx6KMPiVsHdhEH1G98tPafPwQ
Cf7Aa36o3Z+Q8Z0pWvvT7OPj2THpwap7nkzhfbe243KAMt4S33gpfVRZZD8C
kZwAldEEf0keJ4UtlxBneP5Yckf3eM2MY3u3btea92TOhqJQR67MijaPgurl
M9GyvvjkxuwKb/JjfgiobeOxLRFM8Jhf9kpEjhehwPmusQKELMEfFLdNMDO8
M+B4NgmoxwELZlx+MSODjXKPy4B4KtrUkAu2RZHXEjbSMJaHKGdfWjSuVd9v
IcT5gMdgVlaihOytfUAvg2xzXvbUR2zF1dqYdPhA4woqOVamjuvnRNNX2Q57
loGMypM/beWDNPI24lrVB5Yj6CHcIARt77ia6u+7hZ6dvL25IdYpfMKSx9yo
e7lhMVMiQwmzjHoIlniQGSZUjdlfVH6tCTkRhhnuH8ycH6z3DJpBXlwOFtNZ
QB+P7pxhig6JkVWFD0hNFO5JcElcEyGDlqqifLdgM9Fv3r6+ef3s9dWH95ev
r84J06I8RCbkIm7Cz6e0q/tpZ9Yg9bHsRJlgiotJuBck81XWsc+WHrGl/jds
KfXCE6ipG4FReHSk/wlRCQ4S1M+FnWVQJnzgraffffftd2BEfckyDjFCmTwo
NHo0dutcmot1k2V2Q3l+d1C+DMhR2QOcxHaIZLQQrr42YsOBnZTLkCWgQuGo
+IY3qUBpyNDR/PaFNk1rAN1DByYXglZjJ0MRpbOV5+6Al9qmtEsUKiQWxnjc
N7BrLnAi0u+IBKO/wUt0VjhOFPQ0e3wojmj5uiE82BsfWQXVFbZCxvzmq6xv
qi+8lD0CliXgyubROPZYBOEShDq0wSTL/lQHZqQ/6oiJtuVh6YUIE2Tywe6+
RqWDBILqHqDJFLEzJ7Lg9etAfcKLK/c8i8rI/nnFOqFnXtnttWXwduMYiILn
2ixRWlxSkg4LshLqPS18fWLAS64KMqqpxxk1TbEcS7s8cSjLTYqB2r9iQ8WC
me8Sc4mCSVJMPZazHsiZGc8V0/AjJSRE8kkq6v85oEk0Uwej2JfdLakkeBtp
3+gV1dckNBCeRdUrMwe/2T8jKFZ1fLZr6rpaAF3VCyOpeybjC31zmIqehQGS
GEhaua+mi5RDiTPgSIbb3UjsBcfRG0JHas9nKe3HeqvrQu717CgkDToXawPF
VVMOvrQyIrQt8mg04xDO/QCGqr5a69l8Njs9nc1m/86wpvOUWs0+fjvjWIgP
pwLGgWgNUlftliU3yMhOpQHYfHFrJVs72ffq+St+7Wj2cXZ6vI9ek25yZSVD
XAlS58VVkOuZZtXg/lxSZm3ZqGai4/QVXmReS/GaC2lBIYo+hKd4jpDX0Wwo
9AXWJIb+eM+Op7yjGu/Y6/+QnlGMtRl1AnIpljmwnyn1119/9c+LtXxSWoR7
5I71T6SP2XRKWpngxu9hW9z7g753lsaMHU2nxxP1mVf9dKYfdvPUBU9cNM9v
f3ow2vAF33zweZ/y0NUP9kM0U2Jilol4oQUfzrieOFhn6Zr7q7tYMYW7QdJD
8qM1KSmHpDAfC7jvTQ7MK9FPyH3JXbVnL4c2vt8gUtSjX/nGKg5+dr1pdlDF
1E4nmsqIwPvxqEllpDNBppFuy4IjP2N2415diJOGbg63R07gtx/qv9uVQf1R
sWG/owwYsAm1cJLIUTMjpl/s8DRrIhcYBkrjBayZYdNdnJn2Y3Tgury9cBWi
g7mjkTnFpSgf0RpXy6HbPQ9jHeoWe2o5Qpke2ZzeOuIutaQmaSsskC48MEvh
bm3SplOh3TJJmtpzC8EeM3EEwub0vClwG/c4qUlvrJsgiaiE6a7ISOoLTu0j
1hmiB0aCMjo9qf2Uo916bXNCllzMgA1PhWMdgD5LCm8hD2WAMEkTgRAwJaUe
SXIvuWT0Dbyz9tUOLFyRVAaTscleURnddn/ARoKiHD233HKDFURJWceiEswD
AzvlD7d2R3Ijkw+99pUr7FenyE1hMhYwg33luxJ30GzZq414R6kPQvt00Vah
20m98DzgJgZ4bb75ENou9xMS88HLsPVN2hakobY6ennz7rhPBJBMbOVHg0Fg
2hM4UrJvmMDKLNfcffpRcUZD5IUJHYIgdTelJPgBqWamlnxY2VQ+qgc9xBbV
uyQS4T4YuLiMDLRexjkyhdz+0M1ecCfnkS7NXlyQgeV25akPyk1X6v578uDa
Z2TcuQrF/S6ONC4vdIDDvBh3eKf6VwQ+eEysc+3Hjdic9D2SDrXUonGUk7vF
AmIopUSLGqjDqG5P/hAEj4wVihy8g3Be1cPWdOGX2KngkQuH2mTQX8mOPGxq
Xd1pXHVU6FtH8TR9DbK+7DfrcFw3xNdfenlCm0ZSVHLZBNUj1W0gFDd3hUOK
CeZ4EMhWbcnTnW6eRkFJMLiguEEUiKNVLjaAJBuX1V9KxhSVCMmL+uBINWei
y32CyJjrwVSaQxhP8SLkj9I5yLsvLY+EED9LGojD+WhawDhShnv3NnOD5am5
XbogjXtZCgmKgWbNYw5io/J02EGsUopuo7itpMt2Pbfc5hGiJS2DI09EykkF
5C63hnXVyIE0BmUP6EYoYVYZckiEMQho528u2f0GE01PTgbITY18PiSDSI2M
7xon5zbGts9+SPYSxmB8akPCAkc7nw4eQ4g4z25Lvy1svpQZz68UgMh/1HlB
Q/Plam+bGAEG5zrkuAMP8yiHZ13NtaPnFQDBCTJm5niMe9QdgHn8+TMqjLeS
d6tOMtFwkGUN48XzZ/8I26ujcECFISSFvzpGgzCLQAbAdh/43WPKmMGFbN+G
piVDe0TwGyPJmCz3sg80G8atBHwo63MtVVIPRTL9Qk6FqLCoeC9Aoa9gpnQY
pDS9oPOUYw52tLMrW9t1/MCvilrlhpMvZa5T9108E0dxa7dcccqB+JuUWrn/
Ta1CNuS+dEl0dCemAuSpJLjzXli+Mc0BYVKoYnNSfe3swWNJ0ISaA7XuUsFQ
4QE+bQV0BSHWLVtq7HxHboIWyAZZK2Pzo/b0nHKAcCu93ZyKAj+PLLN7yPY0
XEftCqLNyNTHhyI+fboOOe/p9PH0CR8AiUYqga4jXUz8fsrpycMZSpSl5MBQ
zwWpYhglGMbCzVAw7QVY6XaTyguHnFqrQbWwZahZU/2ZNNPd4h5CR/RRNExM
VSrcL5MWhLJH4ZgqhTRMUHfR0lA3DR79ITxyjos2uKqvsC6onEjxnfGMj4Zu
NIo91KEm1iVqNSE6i3jnbRO6DayvgvtngvmJrm54wgBn4KiXnO0ceXITEEnZ
QeCxRdGYcEwX2/CBYVqHScMEfBUCrw6QODqmCvWBTLaiJxGhcbSnly1QLdJf
0odMdTFecKCF4epyYPBm1dZB5JR+TBFRbWUZvqenyQL18lxgr4tQ/U5xHzAo
eecFnf14JnXcPiDNfWik8XEgDijAi+LPfFQmDtxlXzYREQnPOvmug9Klz423
N7Y6kTM2VQJuT7a0OtdDnEnCHKNy9W2CbyWo9fRwQEuJIFS514UXWSjTyT2E
6VAdxOqPQI6LvWOSkKmoT1r7tsokyyf1oYpTjxfp6QTXHF66Lx/FEg8VkR0o
l6RxKNW7csXglbNYbD0m8w7qTFR+s5HzFqmlhbTYfw9mlHC0Fmt41h/Budcm
kE0Lv+vLil6N39QHzvAUPP2s+cxIDbA5gSqSsqbLmcjMUV4y8hj5b2yGdBVm
6loygQ4V+j4BEUBCQyniETAuUVNxER5Kbsmy8WRyr7nBNvtr01QaGugtpDvw
GJeipquJITCcQGi+kGGOp+pyhFm7Hn/IIfgToFzMmt9Pvx/kzOPuOJESxmKu
CKh8bwDu6bcZAsEyKnmoWmiG+1EeHhFGm8jhVT4rFKGjiT3KveTpYyMSwTqS
g+jiqnCfTk7N7c4zHuKckWj3pNPAuDuk0rQTPSIqIj10xO2763DGl+ydBqpV
qH05AI1MkE4exkqNv8d34Uj8+wPy1DpWi03aPlRplg3A+UDvLzZDupWzAVVU
nn361B9ZJ3ESxMuQoGlCuoOn0fh43GQab84WOu6pcXOPNk9bWZPYnNJ9cyo4
CdwwtqbUoDX1hdmUHDU8YHCxH9kNTfujXlhiIR0uk/zogGemHDHCQSx+7Ues
YhMA+d30ae8Kpwwfb/qzW2M6ulgksJJXB5fkPHTKilMC8WSaUJfSkRmz4eeo
l0C2llQ0dIbiUDAPSZUn3D34QPgv1PA49CSxjcTx7ye7b5iEAyhKqs50mVxA
ncxT+45IWpsFT6cikn3k8vzV+Z5/IFuMf1bRn2Mbnh6v7JJiSEVJoB/MhtLx
vkVQmtFb1U7FYES4sFG//3EUf8O13W6nzpRGfhLGJTofEZefhNF/04/0o62H
/DuuTtYIquo9kcDdfjrpplS/7Sv6NQ/duKebCjCPiNfW/Ay8fm2o7MLV9NB6
mCMkQugFNhhA3ieoeNBeRoEDWfXvh+f/70TEXJ7wybGxkJJRpD6KU7iOcCpW
qGMD7H6slFDYCbIbQv7Tkku6I8lvAHzllo5QMYVfX5uiP5/HJ1wzooKPYV3C
ha+3tmn2ftiwMlTw3Dm7DWflyg2yBL+0JrzaIVgafwQtXD6/eSFtvcFvGicS
Wut2Tr/7ozZRutorl93qv5vyFoj+qs2QJmBy8MWJfts6/jGfn6iX9NuZEuz7
dU3u/95RE1m/N7WjAlPyw7MVcLH+zft8qv4blOpVNgI6AAA=
</rfc> </rfc>
 End of changes. 60 change blocks. 
360 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/