rfc9298.original.xml   rfc9298.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" ?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.11 (Ruby 3.1. <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.16 (Ruby 2.6.
2) --> 8) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-masque-connect-udp-15" category="std" consensus="true" submissionType="IET -ietf-masque-connect-udp-latest" category="std" consensus="true" submissionType=
F" tocInclude="true" sortRefs="true" symRefs="true" version="3"> "IETF" number="9298" tocInclude="true" sortRefs="true" symRefs="true" version="3
<!-- xml2rfc v2v3 conversion 3.12.10 --> ">
<!-- xml2rfc v2v3 conversion 3.13.1 -->
<link href="https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp-lat
est" rel="prev"/>
<front> <front>
<title>Proxying UDP in HTTP</title> <title>Proxying UDP in HTTP</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-masque-connect-udp-15"/> <seriesInfo name="RFC" value="9298"/>
<author initials="D." surname="Schinazi" fullname="David Schinazi"> <author initials="D." surname="Schinazi" fullname="David Schinazi">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<postal> <postal>
<street>1600 Amphitheatre Parkway</street> <street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>94043</code> <code>94043</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>dschinazi.ietf@gmail.com</email> <email>dschinazi.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date year="2022" month="June" day="17"/> <date year="2022" month="August"/>
<area>Transport</area> <area>Transport</area>
<workgroup>MASQUE</workgroup> <workgroup>MASQUE</workgroup>
<keyword>quic</keyword> <keyword>quic</keyword>
<keyword>http</keyword> <keyword>http</keyword>
<keyword>datagram</keyword> <keyword>datagram</keyword>
<keyword>udp</keyword> <keyword>udp</keyword>
<keyword>proxy</keyword> <keyword>proxy</keyword>
<keyword>tunnels</keyword> <keyword>tunnels</keyword>
<keyword>quic in quic</keyword> <keyword>quic in quic</keyword>
<keyword>turtles all the way down</keyword> <keyword>turtles all the way down</keyword>
skipping to change at line 57 skipping to change at line 58
<note removeInRFC="true"> <note removeInRFC="true">
<name>About This Document</name> <name>About This Document</name>
<t> <t>
The latest revision of this draft can be found at <eref target="https:// ietf-wg-masque.github.io/draft-ietf-masque-connect-udp/draft-ietf-masque-connect -udp.html"/>. The latest revision of this draft can be found at <eref target="https:// ietf-wg-masque.github.io/draft-ietf-masque-connect-udp/draft-ietf-masque-connect -udp.html"/>.
Status information for this document may be found at <eref target="https ://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/"/>. Status information for this document may be found at <eref target="https ://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/"/>.
</t> </t>
<t> <t>
Discussion of this document takes place on the Discussion of this document takes place on the
MASQUE Working Group mailing list (<eref target="mailto:masque@ietf.org" />), MASQUE Working Group mailing list (<eref target="mailto:masque@ietf.org" />),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro wse/masque/"/>. which is archived at <eref target="https://mailarchive.ietf.org/arch/bro wse/masque/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/masque/ "/>.
</t> </t>
<t>Source for this draft and an issue tracker can be found at <t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/ietf-wg-masque/draft-ietf-masque-connec t-udp"/>.</t> <eref target="https://github.com/ietf-wg-masque/draft-ietf-masque-connec t-udp"/>.</t>
</note> </note>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>While HTTP provides the CONNECT method (see <xref section="9.3.6" secti <t>While HTTP provides the CONNECT method (see <xref section="9.3.6" secti
onFormat="of" target="HTTP"/>) onFormat="of" target="RFC9110"/>)
for creating a TCP <xref target="TCP"/> tunnel to a proxy, prior to this for creating a TCP <xref target="RFC0793"/> tunnel to a proxy, it lacked a metho
specification it lacked a method for doing so for UDP <xref target="UDP"/> traff d for
ic.</t> doing so for UDP <xref target="RFC0768"/> traffic prior to this specification.</
<t>This document describes a protocol for tunnelling UDP to a server actin t>
g as a <t>This document describes a protocol for tunneling UDP to a server acting
as a
UDP-specific proxy over HTTP. UDP tunnels are commonly used to create an UDP-specific proxy over HTTP. UDP tunnels are commonly used to create an
end-to-end virtual connection, which can then be secured using QUIC end-to-end virtual connection, which can then be secured using QUIC
<xref target="QUIC"/> or another protocol running over UDP. Unlike CONNECT, the <xref target="RFC9000"/> or another protocol running over UDP. Unlike the HTTP C
UDP ONNECT
proxy itself is identified with an absolute URL containing the traffic's method, the UDP proxy itself is identified with an absolute URL containing the
destination. Clients generate those URLs using a URI Template traffic's destination. Clients generate those URLs using a URI Template
<xref target="TEMPLATE"/>, as described in <xref target="client-config"/>.</t> <xref target="RFC6570"/>, as described in <xref target="client-config"/>.</t>
<t>This protocol supports all existing versions of HTTP by using HTTP Data grams <t>This protocol supports all existing versions of HTTP by using HTTP Data grams
<xref target="HTTP-DGRAM"/>. When using HTTP/2 <xref target="H2"/> or HTTP/3 <xref target="RFC9297"/>. When using HTTP/2 <xref target="RFC9113"/> or HTTP/3
<xref target="H3"/>, it uses HTTP Extended CONNECT as described in <xref target= <xref target="RFC9114"/>, it uses HTTP Extended CONNECT as described in <xref ta
"EXT-CONNECT2"/> rget="RFC8441"/>
and <xref target="EXT-CONNECT3"/>. When using HTTP/1.x <xref target="H1"/>, it u and <xref target="RFC9220"/>. When using HTTP/1.x <xref target="RFC9112"/>, it u
ses HTTP Upgrade ses HTTP Upgrade
as defined in <xref section="7.8" sectionFormat="of" target="HTTP"/>.</t> as defined in <xref section="7.8" sectionFormat="of" target="RFC9110"/>.</t>
<section anchor="conventions"> <section anchor="conventions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<t>In this document, we use the term "UDP proxy" to refer to the HTTP se rver that <t>In this document, we use the term "UDP proxy" to refer to the HTTP se rver that
acts upon the client's UDP tunnelling request to open a UDP socket to a target acts upon the client's UDP tunneling request to open a UDP socket to a target
server, and generates the response to this request. If there are HTTP server and that generates the response to this request. If there are HTTP
intermediaries (as defined in <xref section="3.7" sectionFormat="of" target="HTT intermediaries (as defined in <xref section="3.7" sectionFormat="of" target="RFC
P"/>) between the client and 9110"/>) between the client and
the UDP proxy, those are referred to as "intermediaries" in this document.</t> the UDP proxy, those are referred to as "intermediaries" in this document.</t>
<t>Note that, when the HTTP version in use does not support multiplexing streams <t>Note that, when the HTTP version in use does not support multiplexing streams
(such as HTTP/1.1), any reference to "stream" in this document represents the (such as HTTP/1.1), any reference to "stream" in this document represents the
entire connection.</t> entire connection.</t>
</section> </section>
</section> </section>
<section anchor="client-config"> <section anchor="client-config">
<name>Client Configuration</name> <name>Client Configuration</name>
<t>HTTP clients are configured to use a UDP proxy with a URI Template <t>HTTP clients are configured to use a UDP proxy with a URI Template
<xref target="TEMPLATE"/> that has the variables "target_host" and "target_port" . <xref target="RFC6570"/> that has the variables "target_host" and "target_port".
Examples are shown below:</t> Examples are shown below:</t>
<figure anchor="fig-template-examples"> <figure anchor="fig-template-examples">
<name>URI Template Examples</name> <name>URI Template Examples</name>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
https://example.org/.well-known/masque/udp/{target_host}/{target_port}/ https://example.org/.well-known/masque/udp/{target_host}/{target_port}/
https://proxy.example.org:4443/masque?h={target_host}&p={target_port} https://proxy.example.org:4443/masque?h={target_host}&p={target_port}
https://proxy.example.org:4443/masque{?target_host,target_port} https://proxy.example.org:4443/masque{?target_host,target_port}
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The following requirements apply to the URI Template:</t> <t>The following requirements apply to the URI Template:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The URI Template <bcp14>MUST</bcp14> be a level 3 template or lower. </li> <li>The URI Template <bcp14>MUST</bcp14> be a level 3 template or lower. </li>
<li>The URI Template <bcp14>MUST</bcp14> be in absolute form, and <bcp14 <li>The URI Template <bcp14>MUST</bcp14> be in absolute form and <bcp14>
>MUST</bcp14> include non-empty scheme, MUST</bcp14> include non-empty scheme,
authority and path components.</li> authority, and path components.</li>
<li>The path component of the URI Template <bcp14>MUST</bcp14> start wit <li>The path component of the URI Template <bcp14>MUST</bcp14> start wit
h a slash "/".</li> h a slash ("/").</li>
<li>All template variables <bcp14>MUST</bcp14> be within the path or que ry components of the URI.</li> <li>All template variables <bcp14>MUST</bcp14> be within the path or que ry components of the URI.</li>
<li>The URI template <bcp14>MUST</bcp14> contain the two variables "targ et_host" and <li>The URI Template <bcp14>MUST</bcp14> contain the two variables "targ et_host" and
"target_port" and <bcp14>MAY</bcp14> contain other variables.</li> "target_port" and <bcp14>MAY</bcp14> contain other variables.</li>
<li>The URI Template <bcp14>MUST NOT</bcp14> contain any non-ASCII unico de characters and <bcp14>MUST</bcp14> <li>The URI Template <bcp14>MUST NOT</bcp14> contain any non-ASCII Unico de characters and <bcp14>MUST</bcp14>
only contain ASCII characters in the range 0x21-0x7E inclusive (note that only contain ASCII characters in the range 0x21-0x7E inclusive (note that
percent-encoding is allowed; see <xref section="2.1" sectionFormat="of" target=" URI"/>).</li> percent-encoding is allowed; see <xref section="2.1" sectionFormat="of" target=" RFC3986"/>).</li>
<li>The URI Template <bcp14>MUST NOT</bcp14> use Reserved Expansion ("+" operator), Fragment <li>The URI Template <bcp14>MUST NOT</bcp14> use Reserved Expansion ("+" operator), Fragment
Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment
Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with
Semicolon-Prefix.</li> Semicolon-Prefix.</li>
</ul> </ul>
<t>Clients <bcp14>SHOULD</bcp14> validate the requirements above; however, clients <bcp14>MAY</bcp14> use a <t>Clients <bcp14>SHOULD</bcp14> validate the requirements above; however, clients <bcp14>MAY</bcp14> use a
general-purpose URI Template implementation that lacks this specific validation. general-purpose URI Template implementation that lacks this specific validation.
If a client detects that any of the requirements above are not met by a URI If a client detects that any of the requirements above are not met by a URI
Template, the client <bcp14>MUST</bcp14> reject its configuration and abort the request without Template, the client <bcp14>MUST</bcp14> reject its configuration and abort the request without
sending it to the UDP proxy.</t> sending it to the UDP proxy.</t>
<t>Since the original HTTP CONNECT method allowed conveying the target hos <t>The original HTTP CONNECT method allowed for the conveyance of the targ
t and et host
port but not the scheme, proxy authority, path, nor query, there exist clients and port, but not the scheme, proxy authority, path, or query. Thus, clients
with proxy configuration interfaces that only allow the user to configure the with proxy configuration interfaces that only allow the user to configure the
proxy host and the proxy port. Client implementations of this specification that proxy host and the proxy port exist. Client implementations of this
are constrained by such limitations <bcp14>MAY</bcp14> attempt to access UDP pro specification that are constrained by such limitations <bcp14>MAY</bcp14> attemp
xying t to access UDP
capabilities using the default template, which is defined as: proxying capabilities using the default template, which is defined as
"https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/udp/{target_host}/{target_po "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/udp/{target_host}/{target_po
rt}/" rt}/",
where $PROXY_HOST and $PROXY_PORT are the configured host and port of the UDP where $PROXY_HOST and $PROXY_PORT are the configured host and port of the UDP
proxy respectively. UDP proxy deployments <bcp14>SHOULD</bcp14> offer service at this location proxy, respectively. UDP proxy deployments <bcp14>SHOULD</bcp14> offer service a t this location
if they need to interoperate with such clients.</t> if they need to interoperate with such clients.</t>
</section> </section>
<section anchor="tunnelling-udp-over-http"> <section anchor="tunneling-udp-over-http">
<name>Tunnelling UDP over HTTP</name> <name>Tunneling UDP over HTTP</name>
<t>To allow negotiation of a tunnel for UDP over HTTP, this document defin es the <t>To allow negotiation of a tunnel for UDP over HTTP, this document defin es the
"connect-udp" HTTP Upgrade Token. The resulting UDP tunnels use the Capsule "connect-udp" HTTP upgrade token. The resulting UDP tunnels use the Capsule
Protocol (see <xref section="3.2" sectionFormat="of" target="HTTP-DGRAM"/>) with Protocol (see <xref section="3.2" sectionFormat="of" target="RFC9297"/>) with HT
HTTP Datagrams in the format TP Datagrams in the format
defined in <xref target="format"/>.</t> defined in <xref target="format"/>.</t>
<t>To initiate a UDP tunnel associated with a single HTTP stream, a client issues a <t>To initiate a UDP tunnel associated with a single HTTP stream, a client issues a
request containing the "connect-udp" upgrade token. The target of the tunnel is request containing the "connect-udp" upgrade token. The target of the tunnel is
indicated by the client to the UDP proxy via the "target_host" and "target_port" indicated by the client to the UDP proxy via the "target_host" and "target_port"
variables of the URI Template, see <xref target="client-config"/>. If the reques variables of the URI Template; see <xref target="client-config"/>.</t>
t is <t>"target_host" supports using DNS names, IPv6 literals and IPv4 literals
successful, the UDP proxy commits to converting received HTTP Datagrams into UDP . Note
packets and vice versa until the tunnel is closed.</t> that IPv6 scoped addressing zone identifiers are not supported. Using the terms
IPv6address, IPv4address, reg-name, and port from <xref target="RFC3986"/>, the
"target_host" and
"target_port" variables <bcp14>MUST</bcp14> adhere to the format in <xref target
="target-format"/>, using
notation from <xref target="RFC2234"/>. Additionally:</t>
<ul spacing="normal">
<li>both the "target_host" and "target_port" variables <bcp14>MUST NOT</
bcp14> be empty.</li>
<li>if "target_host" contains an IPv6 literal, the colons (":") <bcp14>M
UST</bcp14> be
percent-encoded. For example, if the target host is "2001:db8::42", it will be
encoded in the URI as "2001%3Adb8%3A%3A42".</li>
<li>"target_port" <bcp14>MUST</bcp14> represent an integer between 1 and
65535 inclusive.</li>
</ul>
<figure anchor="target-format">
<name>URI Template Variable Format</name>
<artwork type="ascii-art"><![CDATA[
target_host = IPv6address / IPv4address / reg-name
target_port = port
]]></artwork>
</figure>
<t>When sending its UDP proxying request, the client <bcp14>SHALL</bcp14> perform URI Template <t>When sending its UDP proxying request, the client <bcp14>SHALL</bcp14> perform URI Template
expansion to determine the path and query of its request. target_host supports expansion to determine the path and query of its request.</t>
using DNS names, IPv6 literals and IPv4 literals. Note that IPv6 scoped <t>If the request is successful, the UDP proxy commits to converting recei
addressing zone identifiers are not supported. Also note that this URI Template ved HTTP
expansion requires using percent-encoding, so for example if the target_host is Datagrams into UDP packets, and vice versa, until the tunnel is closed.</t>
"2001:db8::42", it will be encoded in the URI as "2001%3Adb8%3A%3A42".</t> <t>By virtue of the definition of the Capsule Protocol (see <xref section=
<t>By virtue of the definition of the Capsule Protocol (see <xref section= "3.2" sectionFormat="of" target="RFC9297"/>), UDP proxying requests do not carry
"3.2" sectionFormat="of" target="HTTP-DGRAM"/>), UDP proxying requests do not ca any message content.
rry any message content.
Similarly, successful UDP proxying responses also do not carry any message Similarly, successful UDP proxying responses also do not carry any message
content.</t> content.</t>
<section anchor="handling"> <section anchor="handling">
<name>UDP Proxy Handling</name> <name>UDP Proxy Handling</name>
<t>Upon receiving a UDP proxying request:</t> <t>Upon receiving a UDP proxying request:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>if the recipient is configured to use another HTTP proxy, it will act as an <li>if the recipient is configured to use another HTTP proxy, it will act as an
intermediary: it forwards the request to another HTTP server. Note that such intermediary by forwarding the request to another HTTP server. Note that such
intermediaries may need to reencode the request if they forward it using a intermediaries may need to re-encode the request if they forward it using a
version of HTTP that is different from the one used to receive it, as the version of HTTP that is different from the one used to receive it, as the
request encoding differs by version (see below).</li> request encoding differs by version (see below).</li>
<li>otherwise, the recipient will act as a UDP proxy: it extracts the <li>otherwise, the recipient will act as a UDP proxy. It extracts the
"target_host" and "target_port" variables from the URI it has reconstructed "target_host" and "target_port" variables from the URI it has reconstructed
from the request headers, and establishes a tunnel by directly opening a UDP from the request headers, decodes their percent-encoding, and establishes a
socket to the requested target.</li> tunnel by directly opening a UDP socket to the requested target.</li>
</ul> </ul>
<t>Unlike TCP, UDP is connection-less. The UDP proxy that opens the UDP socket has <t>Unlike TCP, UDP is connectionless. The UDP proxy that opens the UDP s ocket has
no way of knowing whether the destination is reachable. Therefore, it needs to no way of knowing whether the destination is reachable. Therefore, it needs to
respond to the request without waiting for a packet from the target. However, if respond to the request without waiting for a packet from the target. However, if
the target_host is a DNS name, the UDP proxy <bcp14>MUST</bcp14> perform DNS res the "target_host" is a DNS name, the UDP proxy <bcp14>MUST</bcp14> perform DNS r
olution before esolution
replying to the HTTP request. If errors occur during this process, the UDP proxy before replying to the HTTP request. If errors occur during this process, the
<bcp14>MUST</bcp14> reject the request and <bcp14>SHOULD</bcp14> send details us UDP proxy <bcp14>MUST</bcp14> reject the request and <bcp14>SHOULD</bcp14> send
ing an appropriate details using an appropriate
"Proxy-Status" header field <xref target="PROXY-STATUS"/> (for example, if DNS Proxy-Status header field <xref target="RFC9209"/>. For example, if DNS
resolution returns an error, the proxy can use the dns_error Proxy Error Type resolution returns an error, the proxy can use the dns_error Proxy Error Type
from <xref section="2.3.2" sectionFormat="of" target="PROXY-STATUS"/>).</t> from <xref section="2.3.2" sectionFormat="of" target="RFC9209"/>.</t>
<t>UDP proxies can use connected UDP sockets if their operating system s upports <t>UDP proxies can use connected UDP sockets if their operating system s upports
them, as that allows the UDP proxy to rely on the kernel to only send it UDP them, as that allows the UDP proxy to rely on the kernel to only send it UDP
packets that match the correct 5-tuple. If the UDP proxy uses a non-connected packets that match the correct 5-tuple. If the UDP proxy uses a non-connected
socket, it <bcp14>MUST</bcp14> validate the IP source address and UDP source por t on received socket, it <bcp14>MUST</bcp14> validate the IP source address and UDP source por t on received
packets to ensure they match the client's request. Packets that do not match packets to ensure they match the client's request. Packets that do not match
<bcp14>MUST</bcp14> be discarded by the UDP proxy.</t> <bcp14>MUST</bcp14> be discarded by the UDP proxy.</t>
<t>The lifetime of the socket is tied to the request stream. The UDP pro xy <bcp14>MUST</bcp14> <t>The lifetime of the socket is tied to the request stream. The UDP pro xy <bcp14>MUST</bcp14>
keep the socket open while the request stream is open. If a UDP proxy is keep the socket open while the request stream is open. If a UDP proxy is
notified by its operating system that its socket is no longer usable (for notified by its operating system that its socket is no longer usable, it <bcp14>
example, this can happen when an ICMP "Destination Unreachable" message is MUST</bcp14>
received, see <xref section="3.1" sectionFormat="of" target="ICMP6"/>), it <bcp1 close the request stream. For example, this can happen when an ICMP Destination
4>MUST</bcp14> close the request Unreachable message is received; see <xref section="3.1" sectionFormat="of" targ
stream. UDP proxies <bcp14>MAY</bcp14> choose to close sockets due to a period o et="RFC4443"/>. UDP
f inactivity, proxies <bcp14>MAY</bcp14> choose to close sockets due to a period of inactivity
but they <bcp14>MUST</bcp14> close the request stream when closing the socket. U , but they <bcp14>MUST</bcp14>
DP proxies that close the request stream when closing the socket. UDP proxies that close sockets
close sockets after a period of inactivity <bcp14>SHOULD NOT</bcp14> use a perio after a period of inactivity <bcp14>SHOULD NOT</bcp14> use a period lower than t
d lower than wo minutes; see
two minutes, see <xref section="4.3" sectionFormat="of" target="BEHAVE"/>.</t> <xref section="4.3" sectionFormat="of" target="RFC4787"/>.</t>
<t>A successful response (as defined in <xref target="resp1"/> and <xref <t>A successful response (as defined in Sections <xref format="counter"
target="resp23"/>) indicates that target="resp1"/> and <xref format="counter" target="resp23"/>)
the UDP proxy has opened a socket to the requested target and is willing to indicates that the UDP proxy has opened a socket to the requested target and is
proxy UDP payloads. Any response other than a successful response indicates that willing to proxy UDP payloads. Any response other than a successful response
the request has failed, and the client <bcp14>MUST</bcp14> therefore abort the r indicates that the request has failed; thus, the client <bcp14>MUST</bcp14> abor
equest.</t> t the request.</t>
<t>UDP proxies <bcp14>MUST NOT</bcp14> introduce fragmentation at the IP layer when forwarding <t>UDP proxies <bcp14>MUST NOT</bcp14> introduce fragmentation at the IP layer when forwarding
HTTP Datagrams onto a UDP socket; overly large datagrams are silently dropped. HTTP Datagrams onto a UDP socket; overly large datagrams are silently dropped.
In IPv4, the Don't Fragment (DF) bit <bcp14>MUST</bcp14> be set if possible, to prevent In IPv4, the Don't Fragment (DF) bit <bcp14>MUST</bcp14> be set, if possible, to prevent
fragmentation on the path. Future extensions <bcp14>MAY</bcp14> remove these req uirements.</t> fragmentation on the path. Future extensions <bcp14>MAY</bcp14> remove these req uirements.</t>
<t>Implementers of UDP proxies will benefit from reading the guidance in <t>Implementers of UDP proxies will benefit from reading the guidance in
<xref target="UDP-USAGE"/>.</t> <xref target="RFC8085"/>.</t>
</section> </section>
<section anchor="req1"> <section anchor="req1">
<name>HTTP/1.1 Request</name> <name>HTTP/1.1 Request</name>
<t>When using HTTP/1.1 <xref target="H1"/>, a UDP proxying request will meet the following <t>When using HTTP/1.1 <xref target="RFC9112"/>, a UDP proxying request will meet the following
requirements:</t> requirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the method <bcp14>SHALL</bcp14> be "GET".</li> <li>the method <bcp14>SHALL</bcp14> be "GET".</li>
<li>the request <bcp14>SHALL</bcp14> include a single "Host" header fi eld containing the origin <li>the request <bcp14>SHALL</bcp14> include a single Host header fiel d containing the origin
of the UDP proxy.</li> of the UDP proxy.</li>
<li>the request <bcp14>SHALL</bcp14> include a "Connection" header fie <li>the request <bcp14>SHALL</bcp14> include a Connection header field
ld with value "Upgrade" with value "Upgrade"
(note that this requirement is case-insensitive as per <xref section="7.6.1" sec (note that this requirement is case-insensitive as per <xref section="7.6.1" sec
tionFormat="of" target="HTTP"/>).</li> tionFormat="of" target="RFC9110"/>).</li>
<li>the request <bcp14>SHALL</bcp14> include an "Upgrade" header field <li>the request <bcp14>SHALL</bcp14> include an Upgrade header field w
with value "connect-udp".</li> ith value "connect-udp".</li>
</ul> </ul>
<t>A UDP proxying request that does not conform to these restrictions is malformed. <t>A UDP proxying request that does not conform to these restrictions is malformed.
The recipient of such a malformed request <bcp14>MUST</bcp14> respond with an er ror, and <bcp14>SHOULD</bcp14> The recipient of such a malformed request <bcp14>MUST</bcp14> respond with an er ror and <bcp14>SHOULD</bcp14>
use the 400 (Bad Request) status code.</t> use the 400 (Bad Request) status code.</t>
<t>For example, if the client is configured with URI Template <t>For example, if the client is configured with URI Template
"https://example.org/.well-known/masque/udp/{target_host}/{target_port}/" and "https://example.org/.well-known/masque/udp/{target_host}/{target_port}/" and
wishes to open a UDP proxying tunnel to target 192.0.2.6:443, it could send the wishes to open a UDP proxying tunnel to target 192.0.2.6:443, it could send the
following request:</t> following request:</t>
<figure anchor="fig-req-h1"> <figure anchor="fig-req-h1">
<name>Example HTTP/1.1 Request</name> <name>Example HTTP/1.1 Request</name>
<sourcecode type="http-message"><![CDATA[ <artwork><![CDATA[
GET https://example.org/.well-known/masque/udp/192.0.2.6/443/ HTTP/1.1 GET https://example.org/.well-known/masque/udp/192.0.2.6/443/ HTTP/1.1
Host: example.org Host: example.org
Connection: Upgrade Connection: Upgrade
Upgrade: connect-udp Upgrade: connect-udp
Capsule-Protocol: ?1 Capsule-Protocol: ?1
]]></sourcecode> ]]></artwork>
</figure> </figure>
<t>In HTTP/1.1, this protocol uses the GET method to mimic the design of the <t>In HTTP/1.1, this protocol uses the GET method to mimic the design of the
WebSocket Protocol <xref target="WEBSOCKET"/>.</t> WebSocket Protocol <xref target="RFC6455"/>.</t>
</section> </section>
<section anchor="resp1"> <section anchor="resp1">
<name>HTTP/1.1 Response</name> <name>HTTP/1.1 Response</name>
<t>The UDP proxy <bcp14>SHALL</bcp14> indicate a successful response by replying with the <t>The UDP proxy <bcp14>SHALL</bcp14> indicate a successful response by replying with the
following requirements:</t> following requirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the HTTP status code on the response <bcp14>SHALL</bcp14> be 101 ( Switching Protocols).</li> <li>the HTTP status code on the response <bcp14>SHALL</bcp14> be 101 ( Switching Protocols).</li>
<li>the reponse <bcp14>SHALL</bcp14> include a "Connection" header fie <li>the response <bcp14>SHALL</bcp14> include a Connection header fiel
ld with value "Upgrade" d with value "Upgrade"
(note that this requirement is case-insensitive as per <xref section="7.6.1" sec (note that this requirement is case-insensitive as per <xref section="7.6.1" sec
tionFormat="of" target="HTTP"/>).</li> tionFormat="of" target="RFC9110"/>).</li>
<li>the response <bcp14>SHALL</bcp14> include a single "Upgrade" heade <li>the response <bcp14>SHALL</bcp14> include a single Upgrade header
r field with value field with value
"connect-udp".</li> "connect-udp".</li>
<li>the response <bcp14>SHALL</bcp14> meet the requirements of HTTP re sponses that start the <li>the response <bcp14>SHALL</bcp14> meet the requirements of HTTP re sponses that start the
Capsule Protocol; see <xref section="3.2" sectionFormat="of" target="HTTP-DGRAM" />.</li> Capsule Protocol; see <xref section="3.2" sectionFormat="of" target="RFC9297"/>. </li>
</ul> </ul>
<t>If any of these requirements are not met, the client <bcp14>MUST</bcp 14> treat this proxying <t>If any of these requirements are not met, the client <bcp14>MUST</bcp 14> treat this proxying
attempt as failed and abort the connection.</t> attempt as failed and abort the connection.</t>
<t>For example, the UDP proxy could respond with:</t> <t>For example, the UDP proxy could respond with:</t>
<figure anchor="fig-resp-h1"> <figure anchor="fig-resp-h1">
<name>Example HTTP/1.1 Response</name> <name>Example HTTP/1.1 Response</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Connection: Upgrade Connection: Upgrade
Upgrade: connect-udp Upgrade: connect-udp
Capsule-Protocol: ?1 Capsule-Protocol: ?1
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="req23"> <section anchor="req23">
<name>HTTP/2 and HTTP/3 Requests</name> <name>HTTP/2 and HTTP/3 Requests</name>
<t>When using HTTP/2 <xref target="H2"/> or HTTP/3 <xref target="H3"/>, <t>When using HTTP/2 <xref target="RFC9113"/> or HTTP/3 <xref target="RF
UDP proxying requests use Extended C9114"/>, UDP proxying requests use HTTP
CONNECT. This requires that servers send an HTTP Setting as specified in Extended CONNECT. This requires that servers send an HTTP Setting as specified
<xref target="EXT-CONNECT2"/> and <xref target="EXT-CONNECT3"/>, and that reques in <xref target="RFC8441"/> and <xref target="RFC9220"/> and that requests use H
ts use HTTP pseudo-header TTP
fields with the following requirements:</t> pseudo-header fields with the following requirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The ":method" pseudo-header field <bcp14>SHALL</bcp14> be "CONNECT <li>The :method pseudo-header field <bcp14>SHALL</bcp14> be "CONNECT".
".</li> </li>
<li>The ":protocol" pseudo-header field <bcp14>SHALL</bcp14> be "conne <li>The :protocol pseudo-header field <bcp14>SHALL</bcp14> be "connect
ct-udp".</li> -udp".</li>
<li>The ":authority" pseudo-header field <bcp14>SHALL</bcp14> contain <li>The :authority pseudo-header field <bcp14>SHALL</bcp14> contain th
the authority of the UDP e authority of the UDP
proxy.</li> proxy.</li>
<li>The ":path" and ":scheme" pseudo-header fields <bcp14>SHALL NOT</b cp14> be empty. Their <li>The :path and :scheme pseudo-header fields <bcp14>SHALL NOT</bcp14 > be empty. Their
values <bcp14>SHALL</bcp14> contain the scheme and path from the URI Template af ter the URI values <bcp14>SHALL</bcp14> contain the scheme and path from the URI Template af ter the URI
template expansion process has been completed.</li> Template expansion process has been completed.</li>
</ul> </ul>
<t>A UDP proxying request that does not conform to these restrictions is <t>A UDP proxying request that does not conform to these restrictions is
malformed (see <xref section="8.1.1" sectionFormat="of" target="H2"/> and <xref section="4.1.2" sectionFormat="of" target="H3"/>).</t> malformed (see <xref section="8.1.1" sectionFormat="of" target="RFC9113"/> and < xref section="4.1.2" sectionFormat="of" target="RFC9114"/>).</t>
<t>For example, if the client is configured with URI Template <t>For example, if the client is configured with URI Template
"https://example.org/.well-known/masque/udp/{target_host}/{target_port}/" and "https://example.org/.well-known/masque/udp/{target_host}/{target_port}/" and
wishes to open a UDP proxying tunnel to target 192.0.2.6:443, it could send the wishes to open a UDP proxying tunnel to target 192.0.2.6:443, it could send the
following request:</t> following request:</t>
<figure anchor="fig-req-h2"> <figure anchor="fig-req-h2">
<name>Example HTTP/2 Request</name> <name>Example HTTP/2 Request</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HEADERS HEADERS
:method = CONNECT :method = CONNECT
:protocol = connect-udp :protocol = connect-udp
skipping to change at line 312 skipping to change at line 329
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="resp23"> <section anchor="resp23">
<name>HTTP/2 and HTTP/3 Responses</name> <name>HTTP/2 and HTTP/3 Responses</name>
<t>The UDP proxy <bcp14>SHALL</bcp14> indicate a successful response by replying with the <t>The UDP proxy <bcp14>SHALL</bcp14> indicate a successful response by replying with the
following requirements:</t> following requirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the HTTP status code on the response <bcp14>SHALL</bcp14> be in th e 2xx (Successful) range.</li> <li>the HTTP status code on the response <bcp14>SHALL</bcp14> be in th e 2xx (Successful) range.</li>
<li>the response <bcp14>SHALL</bcp14> meet the requirements of HTTP re sponses that start the <li>the response <bcp14>SHALL</bcp14> meet the requirements of HTTP re sponses that start the
Capsule Protocol; see <xref section="3.2" sectionFormat="of" target="HTTP-DGRAM" />.</li> Capsule Protocol; see <xref section="3.2" sectionFormat="of" target="RFC9297"/>. </li>
</ul> </ul>
<t>If any of these requirements are not met, the client <bcp14>MUST</bcp 14> treat this proxying <t>If any of these requirements are not met, the client <bcp14>MUST</bcp 14> treat this proxying
attempt as failed and abort the request.</t> attempt as failed and abort the request.</t>
<t>For example, the UDP proxy could respond with:</t> <t>For example, the UDP proxy could respond with:</t>
<figure anchor="fig-resp-h2"> <figure anchor="fig-resp-h2">
<name>Example HTTP/2 Response</name> <name>Example HTTP/2 Response</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HEADERS HEADERS
:status = 200 :status = 200
capsule-protocol = ?1 capsule-protocol = ?1
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="note-about-draft-versions">
<name>Note About Draft Versions</name>
<t>[[RFC editor: please remove this section before publication.]]</t>
<t>In order to allow implementations to support multiple draft versions
of this
specification during its development, we introduce the "connect-udp-version"
header field. When sent by the client, it contains a list of draft numbers
supported by the client (e.g., "connect-udp-version: 0, 2"). When sent by the
UDP proxy, it contains a single draft number selected by the UDP proxy from the
list provided by the client (e.g., "connect-udp-version: 2"). Sending this
header field is <bcp14>RECOMMENDED</bcp14> but not required. The "connect-udp-ve
rsion" header
field is a
<eref target="https://www.rfc-editor.org/rfc/rfc8941#section-3.1">List Structure
d Field</eref>.
Each list member <bcp14>MUST</bcp14> be an Integer.</t>
</section>
</section> </section>
<section anchor="context-id"> <section anchor="context-id">
<name>Context Identifiers</name> <name>Context Identifiers</name>
<t>The mechanism for proxying UDP in HTTP defined in this document allows future <t>The mechanism for proxying UDP in HTTP defined in this document allows future
extensions to exchange HTTP Datagrams that carry different semantics from UDP extensions to exchange HTTP Datagrams that carry different semantics from UDP
payloads. Some of these extensions can augment UDP payloads with additional payloads. Some of these extensions can augment UDP payloads with additional
data, while others can exchange data that is completely separate from UDP data, while others can exchange data that is completely separate from UDP
payloads. In order to accomplish this, all HTTP Datagrams associated with UDP payloads. In order to accomplish this, all HTTP Datagrams associated with UDP
Proxying request streams start with a context ID, see <xref target="format"/>.</ t> Proxying request streams start with a Context ID field; see <xref target="format "/>.</t>
<t>Context IDs are 62-bit integers (0 to 2<sup>62</sup>-1). Context IDs ar e encoded <t>Context IDs are 62-bit integers (0 to 2<sup>62</sup>-1). Context IDs ar e encoded
as variable-length integers, see <xref section="16" sectionFormat="of" target="Q as variable-length integers; see <xref section="16" sectionFormat="of" target="R
UIC"/>. The context ID value of FC9000"/>. The Context ID value of
0 is reserved for UDP payloads, while non-zero values are dynamically allocated: 0 is reserved for UDP payloads, while non-zero values are dynamically allocated.
non-zero even-numbered context IDs are client-allocated, and odd-numbered Non-zero even-numbered Context IDs are client-allocated, and odd-numbered
context IDs are proxy-allocated. The context ID namespace is tied to a given Context IDs are proxy-allocated. The Context ID namespace is tied to a given
HTTP request: it is possible for a context ID with the same numeric value to be HTTP request; it is possible for a Context ID with the same numeric value to be
simultaneously allocated in distinct requests, potentially with different simultaneously allocated in distinct requests, potentially with different
semantics. Context IDs <bcp14>MUST NOT</bcp14> be re-allocated within a given HT TP namespace semantics. Context IDs <bcp14>MUST NOT</bcp14> be re-allocated within a given HT TP namespace
but <bcp14>MAY</bcp14> be allocated in any order. The context ID allocation rest but <bcp14>MAY</bcp14> be allocated in any order. The Context ID allocation rest
rictions to the rictions to the
use of even-numbered and odd-numbered context IDs exist in order to avoid the use of even-numbered and odd-numbered Context IDs exist in order to avoid the
need for synchronisation between endpoints. However, once a context ID has been need for synchronization between endpoints. However, once a Context ID has been
allocated, those restrictions do not apply to the use of the context ID: it can allocated, those restrictions do not apply to the use of the Context ID; it can
be used by any client or UDP proxy, independent of which endpoint initially be used by any client or UDP proxy, independent of which endpoint initially
allocated it.</t> allocated it.</t>
<t>Registration is the action by which an endpoint informs its peer of the <t>Registration is the action by which an endpoint informs its peer of the
semantics and format of a given context ID. This document does not define how semantics and format of a given Context ID. This document does not define how
registration occurs. Future extensions <bcp14>MAY</bcp14> use HTTP header fields or capsules to registration occurs. Future extensions <bcp14>MAY</bcp14> use HTTP header fields or capsules to
register contexts. Depending on the method being used, it is possible for register Context IDs. Depending on the method being used, it is possible for
datagrams to be received with Context IDs which have not yet been registered, datagrams to be received with Context IDs that have not yet been registered. For
for instance due to reordering of the packet containing the datagram and the instance, this can be due to reordering of the packet containing the datagram
packet containing the registration message during transmission.</t> and the packet containing the registration message during transmission.</t>
</section> </section>
<section anchor="format"> <section anchor="format">
<name>HTTP Datagram Payload Format</name> <name>HTTP Datagram Payload Format</name>
<t>When HTTP Datagrams (see <xref section="2" sectionFormat="of" target="H <t>When HTTP Datagrams (see <xref section="2" sectionFormat="of" target="R
TTP-DGRAM"/>) are associated with UDP FC9297"/>) are associated with UDP
proxying request streams, the HTTP Datagram Payload field has the format defined Proxying request streams, the HTTP Datagram Payload field has the format defined
in <xref target="dgram-format"/>. Note that when HTTP Datagrams are encoded usin in <xref target="dgram-format"/>, using notation from <xref section="1.3" sectio
g QUIC nFormat="of" target="RFC9000"/>. Note that when
DATAGRAM frames <xref target="DGRAM"/>, the Context ID field defined below direc HTTP Datagrams are encoded using QUIC DATAGRAM frames <xref target="RFC9221"/>,
tly the Context ID field defined below directly follows the Quarter Stream ID field,
follows the Quarter Stream ID field which is at the start of the QUIC DATAGRAM which is at the start of the QUIC DATAGRAM frame payload; see <xref section="2.1
frame payload (see <xref section="2.1" sectionFormat="of" target="HTTP-DGRAM"/>) " sectionFormat="of" target="RFC9297"/>.</t>
.</t>
<figure anchor="dgram-format"> <figure anchor="dgram-format">
<name>UDP Proxying HTTP Datagram Format</name> <name>UDP Proxying HTTP Datagram Format</name>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
UDP Proxying HTTP Datagram Payload { UDP Proxying HTTP Datagram Payload {
Context ID (i), Context ID (i),
Payload (..), UDP Proxying Payload (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<dl spacing="compact"> <dl spacing="compact">
<dt>Context ID:</dt> <dt>Context ID:</dt>
<dd> <dd>
<t>A variable-length integer (see <xref section="16" sectionFormat="of <t>A variable-length integer (see <xref section="16" sectionFormat="of
" target="QUIC"/>) that contains the value " target="RFC9000"/>) that contains the value
of the Context ID. If an HTTP/3 Datagram which carries an unknown Context ID is of the Context ID. If an HTTP/3 Datagram that carries an unknown Context ID is
received, the receiver <bcp14>SHALL</bcp14> either drop that datagram silently o r buffer it received, the receiver <bcp14>SHALL</bcp14> either drop that datagram silently o r buffer it
temporarily (on the order of a round trip) while awaiting the registration of temporarily (on the order of a round trip) while awaiting the registration of
the corresponding Context ID.</t> the corresponding Context ID.</t>
</dd> </dd>
<dt>Payload:</dt> <dt>UDP Proxying Payload:</dt>
<dd> <dd>
<t>The payload of the datagram, whose semantics depend on value of the <t>The payload of the datagram, whose semantics depend on the value of
previous the
field. Note that this field can be empty.</t> previous field. Note that this field can be empty.</t>
</dd> </dd>
</dl> </dl>
<t>UDP packets are encoded using HTTP Datagrams with the Context ID set to <t>UDP packets are encoded using HTTP Datagrams with the Context ID field
zero. set to
When the Context ID is set to zero, the Payload field contains the zero. When the Context ID field is set to zero, the UDP Proxying Payload field
unmodified payload of a UDP packet (referred to as "data octets" in <xref target contains the unmodified payload of a UDP packet (referred to as data octets in
="UDP"/>).</t> <xref target="RFC0768"/>).</t>
<t>By virtue of the definition of the UDP header <xref target="UDP"/>, it <t>By virtue of the definition of the UDP header <xref target="RFC0768"/>,
is not possible to it is not possible to
encode UDP payloads longer than 65527 bytes. Therefore, endpoints <bcp14>MUST NO T</bcp14> send encode UDP payloads longer than 65527 bytes. Therefore, endpoints <bcp14>MUST NO T</bcp14> send
HTTP Datagrams with a Payload field longer than 65527 using Context ID zero. An HTTP Datagrams with a UDP Proxying Payload field longer than 65527 using Context
endpoint that receives an HTTP Datagram using Context ID zero whose Payload ID zero. An endpoint that receives an HTTP Datagram using Context ID zero whose
field is longer than 65527 <bcp14>MUST</bcp14> abort the corresponding stream. I UDP Proxying Payload field is longer than 65527 <bcp14>MUST</bcp14> abort the co
f a UDP proxy rresponding
knows it can only send out UDP packets of a certain length due to its underlying stream. If a UDP proxy knows it can only send out UDP packets of a certain
link MTU, it has no choice but to discard incoming HTTP Datagrams using Context length due to its underlying link MTU, it has no choice but to discard incoming
ID zero whose Payload field is longer than that limit. If the discarded HTTP HTTP Datagrams using Context ID zero whose UDP Proxying Payload field is longer
Datagram was transported by a DATAGRAM capsule, the receiver <bcp14>SHOULD</bcp1 than that limit. If the discarded HTTP Datagram was transported by a DATAGRAM
4> discard that capsule, the receiver <bcp14>SHOULD</bcp14> discard that capsule without bufferi
capsule without buffering the capsule contents.</t> ng the capsule
contents.</t>
<t>If a UDP proxy receives an HTTP Datagram before it has received the <t>If a UDP proxy receives an HTTP Datagram before it has received the
corresponding request, it <bcp14>SHALL</bcp14> either drop that HTTP Datagram si lently or corresponding request, it <bcp14>SHALL</bcp14> either drop that HTTP Datagram si lently or
buffer it temporarily (on the order of a round trip) while awaiting the buffer it temporarily (on the order of a round trip) while awaiting the
corresponding request.</t> corresponding request.</t>
<t>Note that buffering datagrams (either because the request was not yet r eceived, <t>Note that buffering datagrams (either because the request was not yet r eceived
or because the Context ID is not yet known) consumes resources. Receivers that or because the Context ID is not yet known) consumes resources. Receivers that
buffer datagrams <bcp14>SHOULD</bcp14> apply buffering limits in order to reduce the risk of buffer datagrams <bcp14>SHOULD</bcp14> apply buffering limits in order to reduce the risk of
resource exhaustion occuring. For example, receivers can limit the total number resource exhaustion occurring. For example, receivers can limit the total number
of buffered datagrams, or the cumulative size of buffered datagrams, on a of buffered datagrams or the cumulative size of buffered datagrams on a
per-stream, per-context, or per-connection basis.</t> per-stream, per-context, or per-connection basis.</t>
<t>A client <bcp14>MAY</bcp14> optimistically start sending UDP packets in HTTP Datagrams before <t>A client <bcp14>MAY</bcp14> optimistically start sending UDP packets in HTTP Datagrams before
receiving the response to its UDP proxying request. However, implementers should receiving the response to its UDP proxying request. However, implementers should
note that such proxied packets may not be processed by the UDP proxy if it note that such proxied packets may not be processed by the UDP proxy if it
responds to the request with a failure, or if the proxied packets are received responds to the request with a failure or if the proxied packets are received by
by the UDP proxy before the request and the UDP proxy chooses to not buffer them the UDP proxy before the request and the UDP proxy chooses to not buffer them.</
.</t> t>
</section> </section>
<section anchor="performance"> <section anchor="performance">
<name>Performance Considerations</name> <name>Performance Considerations</name>
<t>Bursty traffic can often lead to temporally correlated packet losses, w <t>Bursty traffic can often lead to temporally correlated packet losses; i
hich in n turn,
turn can lead to suboptimal responses from congestion controllers in protocols this can lead to suboptimal responses from congestion controllers in protocols
running over UDP. To avoid this, UDP proxies <bcp14>SHOULD</bcp14> strive to avo id increasing running over UDP. To avoid this, UDP proxies <bcp14>SHOULD</bcp14> strive to avo id increasing
burstiness of UDP traffic: they <bcp14>SHOULD NOT</bcp14> queue packets in order to increase burstiness of UDP traffic; they <bcp14>SHOULD NOT</bcp14> queue packets in order to increase
batching.</t> batching.</t>
<t>When the protocol running over UDP that is being proxied uses congestio n control <t>When the protocol running over UDP that is being proxied uses congestio n control
(e.g., <xref target="QUIC"/>), the proxied traffic will incur at least two neste d congestion (e.g., <xref target="RFC9000"/>), the proxied traffic will incur at least two ne sted congestion
controllers. The underlying HTTP connection <bcp14>MUST NOT</bcp14> disable cong estion control controllers. The underlying HTTP connection <bcp14>MUST NOT</bcp14> disable cong estion control
unless it has an out-of-band way of knowing with absolute certainty that the unless it has an out-of-band way of knowing with absolute certainty that the
inner traffic is congestion-controlled.</t> inner traffic is congestion-controlled.</t>
<t>If a client or UDP proxy with a connection containing a UDP proxying re quest <t>If a client or UDP proxy with a connection containing a UDP Proxying re quest
stream disables congestion control, it <bcp14>MUST NOT</bcp14> signal Explicit C ongestion stream disables congestion control, it <bcp14>MUST NOT</bcp14> signal Explicit C ongestion
Notification (ECN) <xref target="ECN"/> support on that connection. That is, it <bcp14>MUST</bcp14> Notification (ECN) <xref target="RFC3168"/> support on that connection. That is, it <bcp14>MUST</bcp14>
mark all IP headers with the Not-ECT codepoint. It <bcp14>MAY</bcp14> continue t o report ECN mark all IP headers with the Not-ECT codepoint. It <bcp14>MAY</bcp14> continue t o report ECN
feedback via QUIC ACK_ECN frames or the TCP "ECE" bit, as the peer may not have feedback via QUIC ACK_ECN frames or the TCP ECE bit, as the peer may not have
disabled congestion control.</t> disabled congestion control.</t>
<t>When the protocol running over UDP that is being proxied uses loss reco very <t>When the protocol running over UDP that is being proxied uses loss reco very
(e.g., <xref target="QUIC"/>), and the underlying HTTP connection runs over TCP, the proxied (e.g., <xref target="RFC9000"/>), and the underlying HTTP connection runs over T CP, the proxied
traffic will incur at least two nested loss recovery mechanisms. This can reduce traffic will incur at least two nested loss recovery mechanisms. This can reduce
performance as both can sometimes independently retransmit the same data. To performance as both can sometimes independently retransmit the same data. To
avoid this, UDP proxying <bcp14>SHOULD</bcp14> be performed over HTTP/3 to allow leveraging the avoid this, UDP proxying <bcp14>SHOULD</bcp14> be performed over HTTP/3 to allow leveraging the
QUIC DATAGRAM frame.</t> QUIC DATAGRAM frame.</t>
<section anchor="mtu-considerations"> <section anchor="mtu-considerations">
<name>MTU Considerations</name> <name>MTU Considerations</name>
<t>When using HTTP/3 with the QUIC Datagram extension <xref target="DGRA <t>When using HTTP/3 with the QUIC Datagram extension <xref target="RFC9
M"/>, UDP payloads are 221"/>, UDP payloads
transmitted in QUIC DATAGRAM frames. Since those cannot be fragmented, they can are transmitted in QUIC DATAGRAM frames. Since those cannot be fragmented, they
only carry payloads up to a given length determined by the QUIC connection can only carry payloads up to a given length determined by the QUIC connection
configuration and the path MTU. If a UDP proxy is using QUIC DATAGRAM frames and configuration and the Path MTU (PMTU). If a UDP proxy is using QUIC DATAGRAM
it receives a UDP payload from the target that will not fit inside a QUIC frames and it receives a UDP payload from the target that will not fit inside a
DATAGRAM frame, the UDP proxy <bcp14>SHOULD NOT</bcp14> send the UDP payload in QUIC DATAGRAM frame, the UDP proxy <bcp14>SHOULD NOT</bcp14> send the UDP payloa
a DATAGRAM d in a DATAGRAM
capsule, as that defeats the end-to-end unreliability characteristic that capsule, as that defeats the end-to-end unreliability characteristic that
methods such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) methods such as Datagram Packetization Layer PMTU Discovery (DPLPMTUD) depend on
depend on <xref target="DPLPMTUD"/>. In this scenario, the UDP proxy <bcp14>SHOU <xref target="RFC8899"/>. In this scenario, the UDP proxy <bcp14>SHOULD</bcp14>
LD</bcp14> drop the drop the UDP
UDP payload and send an ICMP "Packet Too Big" message to the target, see payload and send an ICMP Packet Too Big message to the target; see <xref section
<xref section="3.2" sectionFormat="of" target="ICMP6"/>.</t> ="3.2" sectionFormat="of" target="RFC4443"/>.</t>
</section> </section>
<section anchor="tunneling-of-ecn-marks"> <section anchor="tunneling-of-ecn-marks">
<name>Tunneling of ECN Marks</name> <name>Tunneling of ECN Marks</name>
<t>UDP proxying does not create an IP-in-IP tunnel, so the guidance in <t>UDP proxying does not create an IP-in-IP tunnel, so the guidance in
<xref target="ECN-TUNNEL"/> about transferring ECN marks between inner and outer IP <xref target="RFC6040"/> about transferring ECN marks between inner and outer IP
headers does not apply. There is no inner IP header in UDP proxying tunnels.</t> headers does not apply. There is no inner IP header in UDP proxying tunnels.</t>
<t>Note that UDP proxying clients do not have the ability in this specif ication to <t>In this specification, note that UDP proxying clients do not have the ability to
control the ECN codepoints on UDP packets the UDP proxy sends to the target, nor control the ECN codepoints on UDP packets the UDP proxy sends to the target, nor
can UDP proxies communicate the markings of each UDP packet from target to UDP can UDP proxies communicate the markings of each UDP packet from target to UDP
proxy.</t> proxy.</t>
<t>A UDP proxy <bcp14>MUST</bcp14> ignore ECN bits in the IP header of U DP packets received from <t>A UDP proxy <bcp14>MUST</bcp14> ignore ECN bits in the IP header of U DP packets received from
the target, and <bcp14>MUST</bcp14> set the ECN bits to Not-ECT on UDP packets i the target, and it <bcp14>MUST</bcp14> set the ECN bits to Not-ECT on UDP packet
t sends to the s it sends to
target. These do not relate to the ECN markings of packets sent between client the target. These do not relate to the ECN markings of packets sent between
and UDP proxy in any way.</t> client and UDP proxy in any way.</t>
</section> </section>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>There are significant risks in allowing arbitrary clients to establish a tunnel <t>There are significant risks in allowing arbitrary clients to establish a tunnel
to arbitrary targets, as that could allow bad actors to send traffic and have it to arbitrary targets, as that could allow bad actors to send traffic and have it
attributed to the UDP proxy. HTTP servers that support UDP proxying ought to attributed to the UDP proxy. HTTP servers that support UDP proxying ought to
restrict its use to authenticated users.</t> restrict its use to authenticated users.</t>
<t>There exist software and network deployments that perform access contro l checks <t>There exist software and network deployments that perform access contro l checks
based on the source IP address of incoming requests. For example, some software based on the source IP address of incoming requests. For example, some software
allows unauthenticated configuration changes if they originated from 127.0.0.1. allows unauthenticated configuration changes if they originated from 127.0.0.1.
Such software could be running on the same host as the UDP proxy, or in the same Such software could be running on the same host as the UDP proxy or in the same
broadcast domain. Proxied UDP traffic would then be received with a source IP broadcast domain. Proxied UDP traffic would then be received with a source IP
address belonging to the UDP proxy. If this source address is used for access address belonging to the UDP proxy. If this source address is used for access
control, UDP proxying clients could use the UDP proxy to escalate their access control, UDP proxying clients could use the UDP proxy to escalate their access
privileges beyond those they might otherwise have. This could lead to privileges beyond those they might otherwise have. This could lead to
unauthorized access by UDP proxying clients unless the UDP proxy disallows UDP unauthorized access by UDP proxying clients unless the UDP proxy disallows UDP
proxying requests to vulnerable targets, such as the UDP proxy's own addresses proxying requests to vulnerable targets, such as the UDP proxy's own addresses
and localhost, link-local, multicast, and broadcast addresses. UDP proxies can and localhost, link-local, multicast, and broadcast addresses. UDP proxies can
use the destination_ip_prohibited Proxy Error Type from <xref section="2.3.5" se use the destination_ip_prohibited Proxy Error Type from <xref section="2.3.5" se
ctionFormat="of" target="PROXY-STATUS"/> when rejecting such requests.</t> ctionFormat="of" target="RFC9209"/> when rejecting such requests.</t>
<t>UDP proxies share many similarities to TCP CONNECT proxies when conside <t>UDP proxies share many similarities with TCP CONNECT proxies when consi
ring them dering
as infrastructure for abuse to enable denial of service attacks. Both can them as infrastructure for abuse to enable denial-of-service (DoS) attacks. Both
obfuscate the attacker's source address from the attack target. In the case of a can obfuscate the attacker's source address from the attack target. In the case
stateless volumetric attack (e.g., a TCP SYN flood or a UDP flood), both types of a stateless volumetric attack (e.g., a TCP SYN flood or a UDP flood), both
of proxies pass the traffic to the target host. With stateful volumetric attacks types of proxies pass the traffic to the target host. With stateful volumetric
(e.g., HTTP flooding) being sent over a TCP CONNECT proxy, the proxy will only attacks (e.g., HTTP flooding) being sent over a TCP CONNECT proxy, the proxy
send data if the target has indicated its willingness to accept data by will only send data if the target has indicated its willingness to accept data
responding with a TCP SYN-ACK. Once the path to the target is flooded, the TCP by responding with a TCP SYN-ACK. Once the path to the target is flooded, the
CONNECT proxy will no longer receive replies from the target and will stop TCP CONNECT proxy will no longer receive replies from the target and will stop
sending data. Since UDP does not establish shared state between the UDP proxy sending data. Since UDP does not establish shared state between the UDP proxy
and the target, the UDP proxy could continue sending data to the target in such and the target, the UDP proxy could continue sending data to the target in such
a situation. While a UDP proxy could potentially limit the number of UDP packets a situation. While a UDP proxy could potentially limit the number of UDP packets
it is willing to forward until it has observed a response from the target, that it is willing to forward until it has observed a response from the target, that
provides limited protection against denial of service attacks when attacks provides limited protection against DoS attacks when attacks target open UDP
target open UDP ports where the protocol running over UDP would respond, and ports where the protocol running over UDP would respond and that would be
that would be interpreted as willingness to accept UDP by the UDP proxy. Such interpreted as willingness to accept UDP by the UDP proxy. Such a packet limit
a packet limit could also cause issues for valid traffic.</t> could also cause issues for valid traffic.</t>
<t>The security considerations described in <xref section="4" sectionForma <t>The security considerations described in <xref section="4" sectionForma
t="of" target="HTTP-DGRAM"/> also apply t="of" target="RFC9297"/> also apply
here. Since it is possible to tunnel IP packets over UDP, the guidance in here. Since it is possible to tunnel IP packets over UDP, the guidance in
<xref target="TUNNEL-SECURITY"/> can apply.</t> <xref target="RFC6169"/> can apply.</t>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="iana-upgrade"> <section anchor="iana-upgrade">
<name>HTTP Upgrade Token</name> <name>HTTP Upgrade Token</name>
<t>This document will request IANA to register "connect-udp" in the "HTT <t>IANA has registered "connect-udp" in the "HTTP Upgrade Tokens" regist
P Upgrade ry
Tokens" registry maintained at maintained at &lt;<eref target="https://www.iana.org/assignments/http-upgrade-to
&lt;<eref target="https://www.iana.org/assignments/http-upgrade-tokens"/>&gt;.</ kens"/>&gt;.</t>
t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>
<t>connect-udp</t> <t>connect-udp</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>Proxying of UDP Payloads</t> <t>Proxying of UDP Payloads</t>
</dd> </dd>
<dt>Expected Version Tokens:</dt> <dt>Expected Version Tokens:</dt>
<dd> <dd>
<t>None</t> <t>None</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>This document</t> <t>RFC 9298</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-uri"> <section anchor="iana-uri">
<name>Well-Known URI</name> <name>Well-Known URI</name>
<t>This document will request IANA to register "masque" in the "Well-Kno <t>IANA has registered "masque" in the "Well-Known URIs" registry mainta
wn ined at
URIs" registry maintained at
&lt;<eref target="https://www.iana.org/assignments/well-known-uris"/>&gt;.</t> &lt;<eref target="https://www.iana.org/assignments/well-known-uris"/>&gt;.</t>
<dl spacing="compact"> <dl spacing="compact">
<dt>URI Suffix:</dt> <dt>URI Suffix:</dt>
<dd> <dd>
<t>masque</t> <t>masque</t>
</dd> </dd>
<dt>Change Controller:</dt> <dt>Change Controller:</dt>
<dd> <dd>
<t>IETF</t> <t>IETF</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>This document</t> <t>RFC 9298</t>
</dd> </dd>
<dt>Status:</dt> <dt>Status:</dt>
<dd> <dd>
<t>permanent (if this document is approved)</t> <t>permanent</t>
</dd> </dd>
<dt>Related Information:</dt> <dt>Related Information:</dt>
<dd> <dd>
<t>Includes all resources identified with the path prefix <t>Includes all resources identified with the path prefix
"/.well-known/masque/udp/"</t> "/.well-known/masque/udp/"</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="H1" to="HTTP/1.1"/> <displayreference target="RFC9112" to="HTTP/1.1"/>
<displayreference target="H2" to="HTTP/2"/> <displayreference target="RFC9113" to="HTTP/2"/>
<displayreference target="H3" to="HTTP/3"/> <displayreference target="RFC9114" to="HTTP/3"/>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC0793" to="TCP"/>
<displayreference target="RFC0768" to="UDP"/>
<displayreference target="RFC9000" to="QUIC"/>
<displayreference target="RFC6570" to="TEMPLATE"/>
<displayreference target="RFC9297" to="HTTP-DGRAM"/>
<displayreference target="RFC8441" to="EXT-CONNECT2"/>
<displayreference target="RFC9220" to="EXT-CONNECT3"/>
<displayreference target="RFC9209" to="PROXY-STATUS"/>
<displayreference target="RFC9221" to="QUIC-DGRAM"/>
<displayreference target="RFC3168" to="ECN"/>
<displayreference target="RFC3986" to="URI"/>
<displayreference target="RFC4443" to="ICMP6"/>
<displayreference target="RFC4787" to="BEHAVE"/>
<displayreference target="RFC8085" to="UDP-USAGE"/>
<displayreference target="RFC6455" to="WEBSOCKET"/>
<displayreference target="RFC8899" to="DPLPMTUD"/>
<displayreference target="RFC6040" to="ECN-TUNNEL"/>
<displayreference target="RFC6169" to="TUNNEL-SECURITY"/>
<displayreference target="RFC2234" to="ABNF"/>
<displayreference target="I-D.schwartz-httpbis-helium" to="HELIUM"/>
<displayreference target="I-D.pardue-httpbis-http-network-tunnelling" to="
HiNT"/>
<displayreference target="I-D.schinazi-masque" to="MASQUE-ORIGINAL"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="H1">
<front>
<title>HTTP/1.1</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham">
<organization/>
</author>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document specifies the HTTP/1.1 message syntax, message parsing, connectio
n management, and related security concerns. </t>
<t>This document obsoletes portions of RFC 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="99"/>
<seriesInfo name="RFC" value="9112"/>
<seriesInfo name="DOI" value="10.17487/RFC9112"/>
</reference>
<reference anchor="H2">
<front>
<title>HTTP/2</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<author fullname="C. Benfield" initials="C." role="editor" surname="
Benfield">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>This specification describes an optimized expression of the sem
antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2
(HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced
latency by introducing field compression and allowing multiple concurrent excha
nges on the same connection.</t>
<t>This document obsoletes RFCs 7540 and 8740.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9113"/>
<seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference>
<reference anchor="H3">
<front>
<title>HTTP/3</title>
<author fullname="M. Bishop" initials="M." role="editor" surname="Bi
shop">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The QUIC transport protocol has several features that are desir
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="HTTP">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham">
<organization/>
</author>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes. </t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="TCP">
<front>
<title>Transmission Control Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization/>
</author>
<date month="September" year="1981"/>
</front>
<seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="793"/>
<seriesInfo name="DOI" value="10.17487/RFC0793"/>
</reference>
<reference anchor="UDP">
<front>
<title>User Datagram Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<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="QUIC">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar">
<organization/>
</author>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communic
ation, low-latency connection establishment, and network path migration. QUIC in
cludes security measures that ensure confidentiality, integrity, and availabilit
y in a range of deployment circumstances. Accompanying documents describe the i
ntegration of TLS for key negotiation, loss detection, and an exemplary congesti
on control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="TEMPLATE">
<front>
<title>URI Template</title>
<author fullname="J. Gregorio" initials="J." surname="Gregorio">
<organization/>
</author>
<author fullname="R. Fielding" initials="R." surname="Fielding">
<organization/>
</author>
<author fullname="M. Hadley" initials="M." surname="Hadley">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="D. Orchard" initials="D." surname="Orchard">
<organization/>
</author>
<date month="March" year="2012"/>
<abstract>
<t>A URI Template is a compact sequence of characters for describi
ng a range of Uniform Resource Identifiers through variable expansion. This spec
ification defines the URI Template syntax and the process for expanding a URI Te
mplate into a URI reference, along with guidelines for the use of URI Templates
on the Internet. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6570"/>
<seriesInfo name="DOI" value="10.17487/RFC6570"/>
</reference>
<reference anchor="HTTP-DGRAM">
<front>
<title>HTTP Datagrams and the Capsule Protocol</title>
<author fullname="David Schinazi">
<organization>Google LLC</organization>
</author>
<author fullname="Lucas Pardue">
<organization>Cloudflare</organization>
</author>
<date day="17" month="June" year="2022"/>
<abstract>
<t> This document describes HTTP Datagrams, a convention for con
veying
multiplexed, potentially unreliable datagrams inside an HTTP
connection.
In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9112.
DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or xml"/>
undesirable, they can be sent using the Capsule Protocol, a more <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9113.
general convention for conveying data in HTTP connections. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9114.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9110.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0768.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6570.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2234.
xml"/>
<!-- [I-D.ietf-masque-h3-datagram] in EDIT state as of 07/07/22; companion docum
ent RFC 9297 -->
HTTP Datagrams and the Capsule Protocol are intended for use by HTTP <reference anchor="RFC9297" target="https://www.rfc-editor.org/info/rfc9297">
extensions, not applications. <front>
<title>HTTP Datagrams and the Capsule Protocol</title>
<author fullname="David Schinazi">
<organization>Google LLC</organization>
</author>
<author fullname="Lucas Pardue">
<organization>Cloudflare</organization>
</author>
<date month="August" year="2022"/>
</front>
<seriesInfo name="RFC" value="9297"/>
<seriesInfo name="DOI" value="10.17487/RFC9297"/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8441.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9220.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9209.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9221.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.
xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-masque-h3-datagram
-11"/>
</reference>
<reference anchor="EXT-CONNECT2">
<front>
<title>Bootstrapping WebSockets with HTTP/2</title>
<author fullname="P. McManus" initials="P." surname="McManus">
<organization/>
</author>
<date month="September" year="2018"/>
<abstract>
<t>This document defines a mechanism for running the WebSocket Pro
tocol (RFC 6455) over a single stream of an HTTP/2 connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8441"/>
<seriesInfo name="DOI" value="10.17487/RFC8441"/>
</reference>
<reference anchor="EXT-CONNECT3">
<front>
<title>Bootstrapping WebSockets with HTTP/3</title>
<author fullname="R. Hamilton" initials="R." surname="Hamilton">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The mechanism for running the WebSocket Protocol over a single
stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-ver
sion-specific details need to be specified. This document describes how the mech
anism is adapted for HTTP/3.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9220"/>
<seriesInfo name="DOI" value="10.17487/RFC9220"/>
</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="PROXY-STATUS">
<front>
<title>The Proxy-Status HTTP Response Header Field</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="P. Sikora" initials="P." surname="Sikora">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>This document defines the Proxy-Status HTTP response field to c
onvey the details of an intermediary's response handling, including generated er
rors.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9209"/>
<seriesInfo name="DOI" value="10.17487/RFC9209"/>
</reference>
<reference anchor="DGRAM">
<front>
<title>An Unreliable Datagram Extension to QUIC</title>
<author fullname="T. Pauly" initials="T." surname="Pauly">
<organization/>
</author>
<author fullname="E. Kinnear" initials="E." surname="Kinnear">
<organization/>
</author>
<author fullname="D. Schinazi" initials="D." surname="Schinazi">
<organization/>
</author>
<date month="March" year="2022"/>
<abstract>
<t>This document defines an extension to the QUIC transport protoc
ol to add support for sending and receiving unreliable datagrams over a QUIC con
nection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9221"/>
<seriesInfo name="DOI" value="10.17487/RFC9221"/>
</reference>
<reference anchor="ECN">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP<
/title>
<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishn
an">
<organization/>
</author>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author fullname="D. Black" initials="D." surname="Black">
<organization/>
</author>
<date month="September" year="2001"/>
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congesti
on Notification) to TCP and IP, including ECN's use of two bits in the IP header
. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="URI">
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.
<title>Uniform Resource Identifier (URI): Generic Syntax</title> xml"/>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4787.
"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.
</author> xml"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6455.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8899.
<author fullname="L. Masinter" initials="L." surname="Masinter"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6040.
</author> xml"/>
<date month="January" year="2005"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6169.
<abstract> xml"/>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-s
aracters that identifies an abstract or physical resource. This specification d chwartz-httpbis-helium-00.xml"/>
efines the generic URI syntax and a process for resolving URI references that mi <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-p
ght be in relative form, along with guidelines and security considerations for t ardue-httpbis-http-network-tunnelling-00.xml"/>
he use of URIs on the Internet. The URI syntax defines a grammar that is a supe <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-s
rset of all valid URIs, allowing an implementation to parse the common component chinazi-masque-00.xml"/>
s of a URI reference without knowing the scheme-specific requirements of every p
ossible identifier. This specification does not define a generative grammar for
URIs; that task is performed by the individual specifications of each URI schem
e. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="ICMP6">
<front>
<title>Internet Control Message Protocol (ICMPv6) for the Internet P
rotocol Version 6 (IPv6) Specification</title>
<author fullname="A. Conta" initials="A." surname="Conta">
<organization/>
</author>
<author fullname="S. Deering" initials="S." surname="Deering">
<organization/>
</author>
<author fullname="M. Gupta" initials="M." role="editor" surname="Gup
ta">
<organization/>
</author>
<date month="March" year="2006"/>
<abstract>
<t>This document describes the format of a set of control messages
used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Con
trol Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="STD" value="89"/>
<seriesInfo name="RFC" value="4443"/>
<seriesInfo name="DOI" value="10.17487/RFC4443"/>
</reference>
<reference anchor="BEHAVE">
<front>
<title>Network Address Translation (NAT) Behavioral Requirements for
Unicast UDP</title>
<author fullname="F. Audet" initials="F." role="editor" surname="Aud
et">
<organization/>
</author>
<author fullname="C. Jennings" initials="C." surname="Jennings">
<organization/>
</author>
<date month="January" year="2007"/>
<abstract>
<t>This document defines basic terminology for describing differen
t types of Network Address Translation (NAT) behavior when handling Unicast UDP
and also defines a set of requirements that would allow many applications, such
as multimedia communications or online gaming, to work consistently. Developing
NATs that meet this set of requirements will greatly increase the likelihood th
at these applications will function properly. This document specifies an Intern
et Best Current Practices for the Internet Community, and requests discussion an
d suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="127"/>
<seriesInfo name="RFC" value="4787"/>
<seriesInfo name="DOI" value="10.17487/RFC4787"/>
</reference>
<reference anchor="UDP-USAGE">
<front>
<title>UDP Usage Guidelines</title>
<author fullname="L. Eggert" initials="L." surname="Eggert">
<organization/>
</author>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization/>
</author>
<author fullname="G. Shepherd" initials="G." surname="Shepherd">
<organization/>
</author>
<date month="March" year="2017"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-pas
sing transport that has no inherent congestion control mechanisms. This documen
t provides guidelines on the use of UDP for the designers of applications, tunne
ls, and other protocols that use UDP. Congestion control guidelines are a prima
ry focus, but the document also provides guidance on other topics, including mes
sage sizes, reliability, checksums, middlebox traversal, the use of Explicit Con
gestion Notification (ECN), Differentiated Services Code Points (DSCPs), and por
ts.</t>
<t>Because congestion control is critical to the stable operation
of the Internet, applications and other protocols that choose to use UDP as an I
nternet transport must employ mechanisms to prevent congestion collapse and to e
stablish some degree of fairness with concurrent traffic. They may also need to
implement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protoco
ls (e.g., protocols layered directly on IP or via IP-based tunnels), especially
when these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multic
ast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="WEBSOCKET">
<front>
<title>The WebSocket Protocol</title>
<author fullname="I. Fette" initials="I." surname="Fette">
<organization/>
</author>
<author fullname="A. Melnikov" initials="A." surname="Melnikov">
<organization/>
</author>
<date month="December" year="2011"/>
<abstract>
<t>The WebSocket Protocol enables two-way communication between a
client running untrusted code in a controlled environment to a remote host that
has opted-in to communications from that code. The security model used for this
is the origin-based security model commonly used by web browsers. The protocol
consists of an opening handshake followed by basic message framing, layered ove
r TCP. The goal of this technology is to provide a mechanism for browser-based
applications that need two-way communication with servers that does not rely on
opening multiple HTTP connections (e.g., using XMLHttpRequest or &lt;iframe&gt;s
and long polling). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6455"/>
<seriesInfo name="DOI" value="10.17487/RFC6455"/>
</reference>
<reference anchor="DPLPMTUD">
<front>
<title>Packetization Layer Path MTU Discovery for Datagram Transport
s</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization/>
</author>
<author fullname="T. Jones" initials="T." surname="Jones">
<organization/>
</author>
<author fullname="M. Tüxen" initials="M." surname="Tüxen">
<organization/>
</author>
<author fullname="I. Rüngeler" initials="I." surname="Rüngeler">
<organization/>
</author>
<author fullname="T. Völker" initials="T." surname="Völker">
<organization/>
</author>
<date month="September" year="2020"/>
<abstract>
<t>This document specifies Datagram Packetization Layer Path MTU D
iscovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for
datagram Packetization Layers (PLs). It allows a PL, or a datagram application t
hat uses a PL, to discover whether a network path can support the current size o
f datagram. This can be used to detect and reduce the message size when a sende
r encounters a packet black hole. It can also probe a network path to discover w
hether the maximum packet size can be increased. This provides functionality fo
r datagram transports that is equivalent to the PLPMTUD specification for TCP, s
pecified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines
to refer to this method for use with UDP datagrams and updates SCTP.</t>
<t>The document provides implementation notes for incorporating Da
tagram PMTUD into IETF datagram transports or applications that use datagram tra
nsports.</t>
<t>This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 80
85, and RFC 8261.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8899"/>
<seriesInfo name="DOI" value="10.17487/RFC8899"/>
</reference>
<reference anchor="ECN-TUNNEL">
<front>
<title>Tunnelling of Explicit Congestion Notification</title>
<author fullname="B. Briscoe" initials="B." surname="Briscoe">
<organization/>
</author>
<date month="November" year="2010"/>
<abstract>
<t>This document redefines how the explicit congestion notificatio
n (ECN) field of the IP header should be constructed on entry to and exit from a
ny IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP
tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulat
ion, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously
unused combinations of inner and outer headers. The new rules ensure the ECN fi
eld is correctly propagated across a tunnel whether it is used to signal one or
two severity levels of congestion; whereas before, only one severity level was s
upported. Tunnel endpoints can be updated in any order without affecting pre-ex
isting uses of the ECN field, thus ensuring backward compatibility. Nonetheless
, operators wanting to support two severity levels (e.g., for pre-congestion not
ification -- PCN) can require compliance with this new specification. A thoroug
h analysis of the reasoning for these changes and the implications is included.
In the unlikely event that the new rules do not meet a specific need, RFC 4774
gives guidance on designing alternate ECN semantics, and this document extends t
hat to include tunnelling issues. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6040"/>
<seriesInfo name="DOI" value="10.17487/RFC6040"/>
</reference>
<reference anchor="TUNNEL-SECURITY">
<front>
<title>Security Concerns with IP Tunneling</title>
<author fullname="S. Krishnan" initials="S." surname="Krishnan">
<organization/>
</author>
<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization/>
</author>
<author fullname="J. Hoagland" initials="J." surname="Hoagland">
<organization/>
</author>
<date month="April" year="2011"/>
<abstract>
<t>A number of security concerns with IP tunnels are documented in
this memo. The intended audience of this document includes network administrat
ors and future protocol developers. The primary intent of this document is to r
aise the awareness level regarding the security issues with IP tunnels as deploy
ed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="6169"/>
<seriesInfo name="DOI" value="10.17487/RFC6169"/>
</reference>
</references> </references>
</references> </references>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This document is a product of the MASQUE Working Group, and the author <t>This document is a product of the MASQUE Working Group, and
thanks the author thanks all MASQUE enthusiasts for their
all MASQUE enthusiasts for their contibutions. This proposal was inspired contributions. This proposal was inspired directly or indirectly
directly or indirectly by prior work from many people, in particular by prior work from many people, in particular <xref target="I-D.schwartz-h
<eref target="https://www.ietf.org/archive/id/draft-schwartz-httpbis-helium-00.t ttpbis-helium"/>
xt">HELIUM</eref> by <contact fullname="Ben Schwartz"/>, <xref target="I-D.pardue-httpbis-ht
by Ben Schwartz, tp-network-tunnelling"/>
<eref target="https://www.ietf.org/archive/id/draft-pardue-httpbis-http-network- by <contact fullname="Lucas Pardue"/>, and the original MASQUE Protocol <x
tunnelling-00.txt">HiNT</eref> ref target="I-D.schinazi-masque"/> by the author of this document.</t>
by Lucas Pardue, and the original
<eref target="https://www.ietf.org/archive/id/draft-schinazi-masque-00.txt">MASQ <t>The author would like to thank <contact fullname="Eric
UE Protocol</eref> Rescorla"/> for suggesting the use of an HTTP method to proxy
by the author of this document.</t> UDP. The author is indebted to <contact fullname="Mark
<t>The author would like to thank Eric Rescorla for suggesting the use of Nottingham"/> and <contact fullname="Lucas Pardue"/> for the
an HTTP many improvements they contributed to this document. The
method to proxy UDP. The author is indebted to Mark Nottingham and Lucas Pardue extensibility design in this document came out of the HTTP
for the many improvements they contributed to this document. The extensibility Datagrams Design Team, whose members were <contact
design in this document came out of the HTTP Datagrams Design Team, whose fullname="Alan Frindell"/>, <contact fullname="Alex
members were Alan Frindell, Alex Chernyakhovsky, Ben Schwartz, Eric Rescorla, Chernyakhovsky"/>, <contact fullname="Ben Schwartz"/>, <contact
Lucas Pardue, Marcus Ihlar, Martin Thomson, Mike Bishop, Tommy Pauly, Victor fullname="Eric Rescorla"/>, <contact fullname="Lucas Pardue"/>,
Vasiliev, and the author of this document.</t> <contact fullname="Marcus Ihlar"/>, <contact fullname="Martin
Thomson"/>, <contact fullname="Mike Bishop"/>, <contact
fullname="Tommy Pauly"/>, <contact fullname="Victor Vasiliev"/>,
and the author of this document.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+V92XIbOZboO74CTd87JfclaW3lhd3uGllSlRXtRW3RVVNR
01GRZEIkrpOZnESmJJbC/S33W+bL5mxAAknKVX27HyZioheLyQRwcHD2BRyN
RqqxTWEm+rKu7ja2XOiPZ5falvr1dHqp8mpeZiv4Nq+z62ZkTXM9WmXuP1oz
mldlaebNqM3Xo4Ov1c1EHynXzlbWOVuVzWYNoy7Op9+qedaYRVVvJto1ucpq
k030tM5Kt67qRt0uJvrtydVfPp6rsl3NTD1ROQyYKJjfmdK1bqKbujXqxpQt
PNZ6UVfteqIHPGoAT3ixwQ9V/Qk38B2+gM9XmS3gOQP8rwj8uKoX+E1Wz5fw
zbJp1m7y5Am+iI/sjRn7157ggyezurp15glP8QSHLmyzbGcwmJBxuxB8PPki
hnBgAdtyTbRqOsGYJx7b6stTffnb8bJZFQP1yWxuqzpHdI30f7R2Tn/gwvQH
YDhb1NmKPsAo+neNBEB/NS3MV7gwGMkhTNK0NdCL01lR6GZp9G220Xl1W9KX
DFBYbFQuVNY2y6omSOB/GuaCEz0b6ytAd5n9YukhE9lZdmPz9As4iIn+rqoW
hdFv3pzSM9fUxgAiD57u7+uT1XoJiDMZPNSXWf0J4KG35rYBkntbtWWTAfzf
W3NLz2uzAPqc6NMTfq3KYeUXx/vHR/IZBiCxfixtYwCaBo9NV9ewkqntPKO3
DJNW7gRWopp/XeDT8bxaqbKqV1kD5IT7fn0woUEvJ/rDt6cvDg4O6WNu3brI
YCXktCcH4wN89bD36tGOV3H466Pei8c7XjxSSo1GI53NAGXZvFFqurQOTmve
rkzZ6Ny4eW1nsL1ldaubikkgFgBD7ewKeQO/pZfgxEkynL5/9+78dKpXBo43
R2oARuEJkAenp2GOMRwCnI1bm7m9BgQWxWYI80SAqNxc2xJpCidoqnmFpJU1
ftaMJ9LzwiLYAMocpEhj4H0mVX1d1Qg2CI3Vqi1hkQbO2MEkIAoWyzCBM/WN
qWXueQMzy5p3m7HgamXzvDBKPdIXQAdV3s5xKn3/yEYfPyv1w9IWjAocD3Rr
HCGnh5c9Z4y+v78yPM2L8dH4KRLT73DkSz66/c+fHyvcAe0KsZcR/u7vfwf/
4Ev7z14cff7sNwv7F6CH8I+t6HAQoSrgmBazDcic+Scg4syDg6vkFS7hKo80
XAf+4XWePsd1QMLALOOH6SU6KJyFASu89iAABdeAZtoRjFHw3ciDKLRW4TtM
JTSSJQ/IZ6PxLKuy2OjWwRaiQy+VKfNRU43gH31j66bNCi0yEPY91LdLO1/q
OZw6nEipZ0B8Zt7WMEvrEJi/fLw4VbBr/JfOYH8fzgBkDcxdwZC6210NAOEQ
ghMgBDDLwn4K5zykQ0fS4/3YxpniWgPWgCLKBnYKq96CgEIaBD6siha28PHD
GwQYBRNOjlMIzr9ywAwOUEZHONanRPJOL0xpatw9HKOjCZxsJoMPF3pqVmtU
MLit6fnbyzcn03Pc2tOvn8HWhoh/f3o5Mub9PTMT6o5ru/j82R922Llr16ig
WdCbO+voHAENjlgLaJiIf7YROOjTmSgWh3Dgk9HZdx9O3r68GJ2NY421PBp5
HQRL6x/wmLppnhwCfK8P+UhEksGDI9wIEDXQg+Plzu8aoAHYkee67W3+7vzf
piP5+hAx8vz4+ODzZ5UB7aTfHhEpHB7u74LoYHyHMB1sgfBxDZvIjaKVUYrJ
up7jn42fe1wRktWjR/q0Km+QOBCPCMcZDrT8+f7RvPv2Mx6K0aDNNapzB0bP
x6vpYMj/6nfv6e8P50DIH87P8O+r1ydv3oQ/lLxx9fr9xzdn3V/dyNP3b9+e
vzvjwfBUJ48UGFk/wjcI5OD95fTi/buTNwPcYCK/iV2BQYHRQEqael0bVJ0Z
0XJ3GK9OL//z/x0cI9oB04cHBy/ghPnD84Nnx/DhFrDOqxHj80fgjo3K1msD
WghmQXKcZ2vbZIUjunagl0oNXGsAvb//CTHz14n+42y+Pjj+kzzADScPPc6S
h4Sz7SdbgxmJOx7tWCZgM3new3QK78mPyWeP9+ihUhe9IwChZ5AqWZaYeqUH
KE9JKA3wbGpzbURRmC1lqEgZtuuKJKbo2a9cJJJJttcGeNeRAq7WwB8ZveAq
0DENC/0mqxemUTw1n6SXXKweawNmf+mMV1l+zrG+uMYXgJCQmMjEIFpamdxm
tYXhew+x2NH4Wcdij4EKm1tj4p0gHErktFecLEdxLcJMzSoGlhiky25TO1DZ
u4okcYZoX8pShFMRjzgGDyOvAG5QKV6Y6lVbNHZdgDhFFQwmK4rKPdeCuspc
MAQfI+Y2DJgp54SsAb+9g/lqA/zmSEsAHApFB2lPrw9J6IgiQdED4r6tM7Fq
Ui2gVGRneS3MAxg/uKmsQ6Nott+ggdjmWmZMBTeA2myGXsSAKeZnOI1mwHJG
niC+BmN1fpfBvIaBYVafGbAKJ0r97W9/A6zNrR1l4Eh6r8rwAHLhxrdAuaNP
JYzyLhx6UPfRop/DJ1zw85MwD1uF0WyT4+PjI5nmm+XLZJJ/Wb9Mpvlts9x/
E80xTMbD3tT9RD8C3I8awezIeFyQy/5yEKNde0QNRGlcV2g8e7YFkljxma7X
IFlFDsQTAEJ/r6e9h5qE5wwPvTA3YHseaQ8N6mZYwNTjLw60kdkDpuKKhQJ9
a8t50eYGGKQcwbBmo8GdAjCH6KCT1wguHL2+zoDMwB4E0YGbCCumz1EI9HfF
KznAbeOJ1RWZW+rBkwFNc4JurH+5o0sPPo6xzOC0GGwaDq7eRNBEyyaoaBIQ
xNxj+XxbfYkFYPsJEzDGTn4Mc7CNGmb4wgGgnvGjUKQgqk+uTi8uNHpJ4Prq
+TJD1xDkVjgYWJ/Urx/IA6IXZRt1Vi6M3r87PBjt3z075/N04PTqvdILSJhr
beo5yhiQZFWO9GgdO3Ym/4NO3aPD8QFi8xvYCIqOoxfPn4JE/5X9oUz6YEjl
5MAF66wkEbw3+D8DVFMg6qoaJOq3dbYgZ1MnLz1KXnqTgXCJvieSOaua0SUI
Y3s31JdIBFdmeyZ68wpJK7xbArHg+6OrZlNQcCIDNwxOLh0F01yZFZxGAYfD
Y2HH3vAXw+ImK2zO9r/pMfQMfJM/oHNuSOd64Y0EQ+JasQYuRuu2XrPzEKHR
otDAmVgjkJhGr9GxlgnumgBA+gRUdeZVaw47mpPqQZ8aSEy4YRtGkuCoDAEJ
6DaQ2lAekGGsr+lsa/N/YWb0qIISYhiRTmFG4Gi/EBoliMqqRdujZCprgpTz
6grQemVJny5RfNkFuFkFK+5d4QwgJ7LFN8FHI6bUyKjEp6TSZ21Du8IXRH6J
cgwybEiygwmCpMdQTB1yq/yJKSIhHppumCyS62xuBM3EnQQirQqnTJZdUNVk
B/BEHlaWYPQIofaOZe/4RZZF595RhRJrAENJZIPBEZLhUtiV9cOR6LIGJR8b
hHOA2XUHAIhUYLtnM1uAu2O8C4uwgWWXgXEUpKb34m1n9GVuokLw9H9dfnj/
bz/+/Pr91XQif1++/zD9/1H5A3VLpxFNSSiLpmUPZ5mYQwG1RAZeCYRIAFq6
KNZAa27GkcmUm3VRbVYxc1fXaJujBLNAnFnDR1BUjH1laWoQ3oaNMCIHFlqs
oPgchIzY3JumEZkQZgHboBLSKc2iaiwfcHW9FUvrxvSiddpH65DKBnGQO/GI
9bT6ZMoxCW7ABRq+PjwkQR7vrpxma/jaqEsfeugFzY7Gh96+53ACWvm07zTm
4PXSNQVfVeIr8DMOcyAGLe7c27Ky8cyBK4OP82AqAMg+ysf297CTfNa5Fu1S
5SVQL6KToqYVrDQdVkScCOUIENaB35Mj4zGLRVKxL870jc14pS8b0aqzNXZY
SEPRwf14kDhkQb5ieLElfr5ui2EPEozVoaBmKQSE07DhOTcWtfLWOcF7xCkY
nmzY8iDaR/8pA9uksUWKFMABqK58jIFXcLg6IZ9KFw9tok3YiQd+QSJIfRUT
NDFAhKqsXgHNdOYeAsb2HmAOFwvuaoTyECpTLM7O3l1RQsMN9cXlzVMQkA3q
X94mPDkOT8Y6eJL8qpsDX+cqy3NgGZrsFzAyu1hi7YIWlUUBJ2DDukoHk4u5
9YFtilr2krdvmw19XFhcDW2vI83HuwVCGBzu7x9M8tnzyeT4cEARsVsLhjQY
zDQTc52nNHSqccD/PjqBIfD/8F8YBmf5asPxW+MJMw+RMP9EhIP+snBQiXAY
7qQJlGCEuXlW1xuyVeCMXLYgqd6QZ3/F2Q7MUHTE3p+NIxhoxAKyHppThTkp
5IdTUIZVvwYqILl8/2gpf4LH9nFNh4P8IkHdHTsAF03/3h8JvGzXIoh2eekS
yfYZCox5+GMCM54C8piz01G4YzPBV+D4bzMMNsbcj8o8npEjPDH9og7qzYca
fpV1iqs2TB2pXBHtJstydJVwgLP5gIoPN9NSqIzsNQVHANy6WrFBV5qQKhDJ
A5NRiBA1FaX+eMngifAsDuWsX4jIiyIM7HfQnm+tEwO1w3qCye64CIXmjvJt
fuFfkc+RLxg2g3xjOWACS5LV1YLzhb5heMdvZ2lAsdSOPWt4AFNZt6QsjchP
2F8OXD9vwG7EyF0gMZiuC99FcyIWCULAgSQ8pqeXzFdMbhJcGgHUjtVZpw3Y
SIV1XFATsgrsR5UV5YzhRNFKQ1DA/CLKYgkQsh+awoMZOJ6AG1oDnKOqNkTI
SFOobxTzY97bgHcHYClLugiFWqZZ4XQolE3q1957stdqW97BQC/T+4qPPBWv
WvAlAAeDHQj+jKAFANcFuxBR8DUOe5q6roAIq/m8rXXe1mxAcC4GRVBvTRV7
R/GW8fjFokT9iPoss0XIE5UY+wG7sUYTRw1IGo0wvd26gdCQBhVTUF6ETN/R
1fRk+vGK8yL7GK3fi3QDIgu3rKIt16Zpa8pq8K6Gkd+B+Thv8uWl+5leEKF4
Tn9PN2uj6GzikICYfzFEHBTwGEEx4ycXygT67ajOiYyxtbj6FHzdAJWvOtUN
369EVnSJ5/SsSa4gB7Fq+2RqycaSP0YoB8KM7RqaC+xOsM7ZeaiRCfXXo6bF
cKA3sbolKK+UUZgm7ETxLojq6eiTWMAF7rKt0W9go4HIgDdPj9k7KYMx1gFX
aayvYcdmE4Ppw/+BSC/j/YjGo/eVj5Pl1oEKzDubNXa6UToU9to0dhU0vQgE
i8FMs8W9bGz35QoFpz4Zs45noEzELWXjt2fA+fEFQnUcuLYohyQ9O6O07TZt
sK6BbzpYQXYVVbkATmkdSiViCBUYgrgWSXGJ+aqSkwPw8eL07aUenEWi7WMZ
JNsgmCEAlD+loe6bORwZw5meIkNiGJlMHU8VZCDHKFAeiTGfUBhxWVWcgeEx
nkvy1khtgaltlZPJW2L+/gZjGAoDHUQpu5fzGKc947feD+LpUzAooJCunl1j
aGz34rpLr0kKQt6iADTOVioMqoLx3jZod6fIOx4fEfJenb8++Z6SEsfPnj8j
Z/AktvNCcmor1YTfHID846wxfjpE7GvvqsmOUmZG5Y3ERwUYX1azNDHQDhoV
rCpUV4uzzjZFleWgZk/KTQdkJToTBfvOXewALpgMANo1KAckNB8dimNvjde1
24G2nuANYVhfHwP+t0RaJVrXeDlVZBsAmOhDjD2MB/V8w6okEuyk9x8oEAEC
tkBMhdI1SQjBFkq0anJQbGv0Dy9KcrFY8ZxV5VdNiPzqvbNvH+uZZxgqCyH7
c12BrzUjBsYaKIPpd5XuoupyAGP9bdu0FL0DA9+FuFdtVhjlhNdcGv4EjF34
MBtam0CKMQbFcyqB3sQyAT7KPfcsWpD1GLO0pbq//wZLaD5enXxHVPx8//nX
oajAJw/1Bznj+0cAxMFn8ZiTWoaDUMuw29FgmFbGNBJQkVSSirdFCSP8WmKm
7GYDVgffnU85uRKTHH/tcz4htjJ4TUZxYn/0AikcqcWsxPWWavnyGoPTYKj2
lqAADyhSEHkDCVhhjeZez4uO9kt2b+bMyFJdqsXIHtoLIImSco+nJKmxRI/z
0b8GZNkB8DCIcSiJpNbOUxP1LDln9AnRKmWRQzQJItrOOVJr0TUr8AXkmmni
2gCeOSXdvRLWEOOTbW5f2CS2XmeAKm/oHe/v671XWe6p8jHm4sDipLpL2Mm3
PXsyEkSpW0tLJUGNwT8p48s5t1t2mdLShoDhrvJO5PXBi8Px/vhw/HQCepiU
8Lxq4dDICkSvL02/svOOCWsqi/UxAmAU/XfsIiz6BHPIXd0ostBERxOoju4n
oUJJ/p3oiJiUhFdGPrwy0d8cJMlngH60PPAZZ0kybwkbTDpflOHxMPgvHLMh
sxaPFjcs4qJBdb2yc+/12YWP+agfzOyK1WWI+oDo++H81dX70z+fT6mq4Pjr
naJPVB/KPtTYbHt2KtnzHivGB/TmDJWs+GxEdtvnuSUDJUQcSNsrjDBpkI4H
+wd67wrmxdLhRdihiwVFPOS/rTRzu6H0cv3XhBrGRXpibefMQQslGUUfD+qi
cRyEokQ/R136kcN+snlHWgE19XWUxXT9PGaXwdzOV6L52wTC52SXz4UFc6uX
vEyqdBJZ2I+vo3CJxe4ucRL4AGlsB4n9U8WCW39ZLvC5oGAILHpIu+eCTi85
HNspYE5vGyrbZaDal4HuDvCi1vE1ob5CHZ3IjvY9nVD40rG49tXhV6bxtcqS
/iTzH8yuuIY0eAFx6SiZUiT5syYFh+OvzrR5NWJOUMQJLoiWByp1Qj3OYMIS
c5BOIwzVWV0Cy2DcDfQC+NeGbvEhDw8J7C+NjwtbuqqdKB2qI2NNwAIrWuKg
E06Z71zA6VB+SZkFLBGikICtYVISIm4HEDxjVzeUxFRD3QO7m/IYe4j8F12u
RMJv5CzNsKIQa34KLG39Z5lgqrOvemmN5+MD9vhfdwTXubMHIrqOWCL/zzai
Xp+fnJ1/uFLCJvqlL+ZQgf7hWSzdhOjgKe1eEUHCp99md6mOL2BMbHXNRWpG
y+6ypg53Ss3D2JZ6SGR6Zcf2DQnN/3YGjrDh4d0d2Dlh9cdcLvY/Ust3kZN/
XMV7YpejeKkP9/d/E+Ghvn6Y8lJtTVm9kxnmT86w21B/L20fSv37T//+E9jf
2uS2qeqJhlkyQqAEP7B2SFDP+Q+9bmeFFBKN//pX8hOqOueSJa5E6RchwRf9
gmluQE3aT3Z0PEnyBGO2OZarVutQG9+Fp5pebcZIJh2oWPlICwjWVadlGCKn
SN9grL7AEi4AhwHkHlYslZDsfK+GY8+MF+PhzvUnen+oDwePt1cOAbdNf3Ex
tuO1YWDBGZB+JD5oQkUwS9va3wUhgXclxRd0AIlFAIcfdTWE0jjhrpzj+Ttx
r2PbiFJu6qc3COUVJT5Je32L3/11z2us29vbcX09HzElkuKCj/i/5y+ODx4J
FY6OxgegI88zqlRzyNWEpVDYXGKjn1lQHbOi3pzG3DX6Iiq5oJ4cfDqyuUjc
lZkvs9K6FSUWg4qLWifjAHKvW4aTS9cURVRRFBEzMnc478L0S2ZI7nGRQZf6
dmaVAZBzyRtz5snHiq+qkGxxSawS8xNZyxHROLws0Zw8p/qLrMA+7GwoqRUK
NvPYACJ+HxLy3jaiTNg6o9q0HVAlzD+nQWAzEIKG1NrT23e/Jgtnu+wbXdJI
kZZ5z/1Bnvl0QFQDFk75jMX908MRxoUtU4LTe/sI4OEfgY3/9PTwj0/w3xHQ
ke4PlHIXbP/yWfxRYcoFgOAn62cjDqgBFHsPscpqujQRqOLEg8e9z9lvKWv2
NXkekf5YMFH4i6krbw0jSPmmzFbcZ0ukRqVkExVexfD2iGUFV7gmG5IysDBQ
2rHyPAxR/SFE/d2IrT1RLdQ6wxh2l+3L9MICICrOhlPtBCpWicdL0j6aKvhM
DuZEgYct2YI0akBTzqLKyEpTtS5GALJhTk2M885DG8JSWKRjCVk0eeAuFbgr
PfWQ8Jih1uu27VsFZGNMyGHrlD3DLAGKnBgmMkOQI7bQJq9xWj1yG9iZoAgr
0FF6mv2zSo6Xq41tzIE3lWVLm0p0EN1uU86XdQWiLRMlzt1UIPPXlcVsRlcs
UWFeIjkf7yqpiH640yrZgqSQk14U2U+TIIEoAoSOmkltz4yLrERXea4Q1Qhu
/xp9fw5hc/2wh1tqPuGcVYR/tMk+mIXFomZfckKOrFgwG5klK+OJUJA4sjLW
BhApUctOGuMpsLDhwlomiG5XEpLoCmq9v8gqA2v5VR1DRaUh7qHEUwgzpM4z
NpSzXSh1MjghfC1wwHRnhC5qby7jTM7M4DPE93AHR6ouBcc9n6HMkxgo5hVG
3jK7YYN6g4X/SEweFliAGt/BmGkoySUp6NoQiRJk15J4o3hwLzPkIfE5TLX7
tQSXPtnuC23wJhK5tIQtgEQD6UuWuPpbPs/7R6JFJFrVU1c9L35H3TIKzF1K
bSuSIEpt2HlfWzCxseSb6oTixOxQlLfO8f1RUHxRud7tDugjhRZ3yp+dTE8Q
fEzsrtD5vP8dd3VzvzTlERGA7uQFMm8BUTldqEATT5OB/ksLKhuI8oqLB8LQ
UPwv6WNW7UIMCJX2UCmCymvGrROQKEp8BuN+62AoztzqYw+ovkdXs9vfnn2M
XWr+273xGD53XXsx2kOz3sOLMG2h89UtAc7fRJ88ZFT0txnbFI/FWPReAmKM
I+6+pDYSROQI+/hCAMhfoFBTCSeWVpUUFIlRkBSrMJfRp1o8emOpPgET8xIV
87OHpD1w/qyl3gfbKHShqxq2C1/siTxiRUUytK5a5PHarh+L7ZP50r4tFq+4
iI/KrcidxreiXSslB0dIni476vFlyAIqmllUoxJEO2sYlJfeUmPxVJsbCxaH
Et/xXZp4kbR2VnZxTKQTtAwAtJcDtINB5SAFsJUnJTFb/Nhj2GAORefiuMoE
Tb0xy6jeC+Shh3f47FKJEpOOastVlXMsPMKShPZY3O71W6jJM6jACW24f/r+
Ht5mzvsNJd84s6gyGejVECqRoIpAp0k5ceLFSH0W1cU8/frrw2egxRvjkvrR
YMx01hzGHPu1KOJJpMjZnp+PJsIw4V6f0D0lbDNIXoAYpLvPJvDbzhmE9mT1
zjPeBoA2ESeVYrr3VWBpAZxCfnZiXUUFjBjyiUmQjnpuaoquiwwSJY32D/Ak
1uZgEKyw5Sf9dvpx6OuWyworzbCrgyrHKl8jiLnCarWDmhMsqJ1Y0DuxwE2L
2IYWSiq7ekTqeuokGypLf/mY2JNBlXh7aUueUfGZB59r1yTs6MuMWY55aeS/
lR4AJxHHKBTzMC1I1Kwr/mbbClkxPdjQ6mKbh0RuOnMkd1WQu/ofkru7QYpv
SIgw09mNewLpzMyztldGeJu5YCwGBaOq9OVUnPnXSUc9pibFFg0VLEzGGlhg
/g9ymFILJ9vvIJIzZo+kA5mIyiU+E4g5H0WsrfuEysavA4b5EkDsTHaYYqyT
mG8d4EC+o+lpqqZqskIieKinGQQ49wDiENUlEVcLHi5dLgYn+gvJ0Z1vg2+p
1qYe+cY1/Ftsf5pLPpc+Wps56yix5cPd4FpU6wZAhB1xOIGtMN98FcsJu2VM
hup339OSRP1FfuzKocXV+HHZnFtihFyVSceJVNHlARDqN6nQz/D5u12RUIvd
XL51wPWqMr3cx1h+i+oCPRSv59PV+P4QKazeWkVYOZ7aF1tGcX+qxiUYCG6m
THhnxe7IJTcXkHsEZO9sburM3xW07r4E2+EVOInNxl8lxZL9GgQQCO6MS6yZ
1wtq7gfGLcgHES1egGI1LvTdlgpL+ZlMZbhrZ0QQWZdLktDjHKUxEz6SWA0W
vlwUsA7FB9tXaU27CASG/+KiSN/HAILnxnShClAdQMyoJ4CFa4zmYIJWCipl
3xNEXlIyDKhvTUyqgZllPqNmGRdL+AZDOezdl4CFoCc7yp4oqMppGxNKIur3
92KfDxNS8qdFJZcAT1ujz4NZlYYuiii5TribV0UY5qBRp4XlnryOq4N9A9qL
CtZ3wNeW2MTjNQ4STduMquvRDIm136pDrOEv9BDDoNl4W9eA21kiamVTNkbI
KACee4W4I44TxW/9JiJ3fne9qpS6+03uOoWuUJ6sPbvA1v/zu3Vh55auxfHY
fUdtARJ42zs/ffeY7gk7fUc3UhzQBXk+O+UvTIjKeOBAiDbCemqV1Z8otH3h
zdrIcIfVRnjvANqxZCqCBdOEyz5s6eMhtBwAoa6NyWdAydT8S47wyemff4Zv
vHcuWgIvEBycn54PsODZN8FxvMqLSIzLKEFZvgNl/zAvoESh9jV4d7ODDbww
/AL9wnKO16L+s4hx1G9knASILm/jJAiH8o1VuoqEKeJrVjV8iaCrVtS64uII
Y4E2nASPmi4kjQoYBZvaJdhohyKXUD/xegBjaLUHJzxkRfHCnTpbeEsrCXrw
YUv5IxjdPc2wXUp11JEcT+SNwhBLhIORAMkwdahAxym/UQla74AFM05ytwba
64A30cK+jl7CBNQHpvh+GUpnhXXadZQXCL6G78kOSpzW7ihEbd8N0kihPiJm
R+NPFNrq74GKWGzsqcWo6LcNSiANyQ/3ek0JJDwFne0KnPUT/pGC8gUvyWqU
SwhRruCa+BY18JtNxi2mOroPsy1BrVu+YWPTXdpDNhzbvhzkddrfOhbFulBB
2l8Yk2+oW+NS8KjPwPthFto7u3xzCY/OHqsuGnJ//41/TJ0Jz1+8oDsEJPfp
5qYEF6N6AAfisUiiW/aPR+nr87iBigEE7qr0K7vo+qbEfONToXSb2ioAocap
UDHM12NIfBmF51sQ0q7rbCFO7cq4/MWjIMJHthxd+CsjqF2+2e7SgBlH04/v
3p2/oVrl/WO8AS2jegriJIyW4Aq4MqoHF9IsrD4z9sThr4tL5XVGAIecFIln
SFMaDwsKBmlnR+mVSxyz5AV/a5BkZihkT4kQISSfxO7dC1N5Y4Rexu0ERYat
PImLkJ48nqzrn1wJnilK3KSzM1zpyxAhvgBisvqwhS4ORDGDCnNWXVw9rdeT
28cWJRrnCPNMfLyG+5QEh75NR8APnjguomKow4VmTmqYwpwAg1fwPWTYJsGA
8o3IU8rWyymwge6R5InFb95PxYUiQj98jsr3gIrM4zQjmHLsUlzhbbh4qlv+
hJNvuMpBLmNEY4nOHC8bBJfXyTWcbBFmNWy1zupNoCEsY/Bd6KEHXaFsD6/y
dl0nzbj6iRXfDJl/3mBPNDodJBtF1+O+iDbBe8sacA5mbdN1j3aNQfElBb5o
TGy2hOzxduhGusgpPclRLXZQscwPk8OcK8RbltzY44VzqQ7cq1vK6ABcJRxB
BaZefMEPrezbw+U2JM8x86WZg8wBv9vkPgEncQQgQt/NS32QEi/zaeteTAHt
kwCKkuqStkzBT9UkV3C4cPmCXIbVCHnrg8Nn4334z8FYXaGaCBvlc8Kkn7cD
y8744RuRepzO7nP3lprVIN3naKXl1QrM+jGlRay0bAerjhZq5P7mNMWYdXjy
V6VQjqlcRG32ETFc+Eut0kZpMgUk7c1no4KzsFM48uZ9DCppDDdunhUiomyY
bg3eqy0MYnpmNnRLwVLaZsEUtUh74X4JomtvlNJC4nYrPko4ol8ww89ENNvs
BlF8uRQ+tPGZKnZlGonLbtoCL4mjuLrnTW8gJJN9BSR5W3ocGkeiBvPpBV1i
qTEMPKLPQy7ew5NmGdkdfBiddgWjZRhuCOiapX+265/hlaWd0Y38/RsD9I4b
A77GsFx6YwBnPPnaBIqL4+4CR6VNrW6JtL5CoSn33/N1ZYAo9Kv8ZXGhg3PJ
6X2SpWKvr7AkyJZg+TlfwcaENhPpAgYRYht8CQueKLbchfu/Grx/b6xfiQOi
qtl164IC5O9N/dUWQQf7lF8Jt1tcyGW4GZdYZAqLRw0Ryg048mAQYhWNDBI3
ja+gv/oR/Mqiwn7sWoxh+gjOG7lH+MsbDuOVHhXrTKjP83Gi4UlCjPUPdGcZ
woBlyVsgOO8qkhCn9QCpj8XDJHVHDlO2dRib+L4JMszR0VB8GwbmpJLrjCjc
0V22hZJf+q8pqiT31605cwkcp6JIt8ghwdEIfPCxfu+vFiTnI904JgFxIz5Z
CgNVArn3I3xiw99gg4XaNr4ZJmoYpyGuqdbh0kN2P9kRw8MKNmOnkIm2c0Z/
cldylxvyTpQ3cHoBSxJOITwRL93fdMm3AmGdatPKjfb8wwnZ1oRxJVYXF5ea
1tQWU5wN7Jrlw+VBfHOYRLKqmVTPZV3cuYfGIbtEa/8LDrQwhkTrqhFxki0w
Fdo8zKhyy4OQrr/UDfsfCGS6Q58vGPxyIOU2LgAfyp3V6GB6lZverf4AreJM
W1dw6Cs+Bh/pJfR6kwtcGE6syIV2KKXoipHkdyDkNxTIqUytxt6F+6FLpV93
wUuR86Lotnah016FEZIQN4pcRGlIQdJwl7fFntbo6vz044eL6Y/kch08xetq
5nzpTSF278XJu5Ntm9dmZfY5dFyk1xfK1yO5ve9z/xcxiAN9bJ+mp2idVFql
NwCKDTRIfjaAVnEDX7+A17BYCnbiGTfqjz+l9c4IDP84kUOrnIzMJ9QgIBCO
6H5B9/hPsOPvsUKBShzi5hd1Rue1pi5A/DIUpQiTSaoVvOHzuzVXkkv5P+PE
0ah3VWmwdk6uKJdKivhHXR4ocEBE/4BtNn+mihLsRvJIru3fi2Bu0ulw202s
YOJ/EK9dMxCCxjhFcK9a4Io72rH83pE65Yro0xCZp2/p56++iCPF9y/RN+Am
gMVBJfhWDNaABuv48iaQZo9xRk7cXJRcYuRP8oKbcPknO0Lyc+uXSIKKWtNl
w2rwUN/T4MEzxF/KwSg0ctXJHAcWJl+wz3P/KEuffIZpfEHqy8E1iAEz2Dpo
Kz8qg7+w4wtB+Be+dPK7Xl3UmI1iqgAAuYtblvdhumXrbIam7TWHwy2XPaK7
iFwvZjbehlWBaUw5ZxDya2xSUN1NaTVZB/IJhCr/2A45eaRHyEBcm4r77kpA
ag32bgvmovrp9fmbi49ve1QW/7QYKPcnNpdf83LzJeiv5pcRvj6zbrQ0hW1X
o/39cXPXPMbU4iuQRlfy2hDmt++mv3V2gCvHH13xc9Mvc7G3Oup+3iFe7E0L
xiLeWA3jOoz7K5PVT4Jp33T1d2yTfi7L/wxMtGJ0olWP+kX/yLesDulKOrI2
4PTBGQDj8QPItaouMi5jbheUzZC8sxQXS7GF6q4gCLfscCZN1rAc6p9JbAGD
gxjIwemWUm0aY0gJlTFB2BUxqg8AGL5IPQlVxJujdSUKz8E2JbchbDWOzNHJ
xiCi8Ecv437Gw6YmFK4pbnYBWwHNj5MC9v9tjTsrwDs7KcydPgVNXG6yT8vq
xn0C8zmhshSvQ5VSBWBl3jp9sQR6p0+AHthMtXL4G0xv8YBegcFZActOq9Vq
AwNbvFjze4uxHdBODnZrbrYYevv4/wusGgPApnAAAA==
</rfc> </rfc>
 End of changes. 89 change blocks. 
1104 lines changed or deleted 398 lines changed or added

This html diff was produced by rfcdiff 1.48.