<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.11 1.6.16 (Ruby 3.1.2) 2.6.8) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-masque-connect-udp-15" docName="draft-ietf-masque-connect-udp-latest" category="std" consensus="true" submissionType="IETF" number="9298" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.10 3.13.1 -->
  <link href="https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp-latest" rel="prev"/>
  <front>
    <title>Proxying UDP in HTTP</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-masque-connect-udp-15"/> name="RFC" value="9298"/>
    <author initials="D." surname="Schinazi" fullname="David Schinazi">
      <organization>Google LLC</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>United States of America</country>
        </postal>
        <email>dschinazi.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2022" month="June" day="17"/> month="August"/>
    <area>Transport</area>
    <workgroup>MASQUE</workgroup>
    <keyword>quic</keyword>
    <keyword>http</keyword>
    <keyword>datagram</keyword>
    <keyword>udp</keyword>
    <keyword>proxy</keyword>
    <keyword>tunnels</keyword>
    <keyword>quic in quic</keyword>
    <keyword>turtles all the way down</keyword>
    <keyword>masque</keyword>
    <keyword>http-ng</keyword>
    <abstract>
      <t>This document describes how to proxy UDP in HTTP, similar to how the HTTP
CONNECT method allows proxying TCP in HTTP. More specifically, this document
defines a protocol that allows an HTTP client to create a tunnel for UDP
communications through an HTTP server that acts as a proxy.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <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"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        MASQUE Working Group mailing list (<eref target="mailto:masque@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/masque/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/masque/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>While HTTP provides the CONNECT method (see <xref section="9.3.6" sectionFormat="of" target="HTTP"/>) target="RFC9110"/>)
for creating a TCP <xref target="TCP"/> target="RFC0793"/> tunnel to a proxy, prior to this
specification it lacked a method for
doing so for UDP <xref target="UDP"/> traffic.</t> target="RFC0768"/> traffic prior to this specification.</t>
      <t>This document describes a protocol for tunnelling tunneling UDP to a server acting as a
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
<xref target="QUIC"/> target="RFC9000"/> or another protocol running over UDP. Unlike CONNECT, the HTTP CONNECT
method, the UDP proxy itself is identified with an absolute URL containing the
traffic's destination. Clients generate those URLs using a URI Template
<xref target="TEMPLATE"/>, target="RFC6570"/>, as described in <xref target="client-config"/>.</t>
      <t>This protocol supports all existing versions of HTTP by using HTTP Datagrams
<xref target="HTTP-DGRAM"/>. target="RFC9297"/>. When using HTTP/2 <xref target="H2"/> target="RFC9113"/> or HTTP/3
<xref target="H3"/>, target="RFC9114"/>, it uses HTTP Extended CONNECT as described in <xref target="EXT-CONNECT2"/> target="RFC8441"/>
and <xref target="EXT-CONNECT3"/>. target="RFC9220"/>. When using HTTP/1.x <xref target="H1"/>, target="RFC9112"/>, it uses HTTP Upgrade
as defined in <xref section="7.8" sectionFormat="of" target="HTTP"/>.</t> target="RFC9110"/>.</t>
      <section anchor="conventions">
        <name>Conventions and Definitions</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <t>In this document, we use the term "UDP proxy" to refer to the HTTP server that
acts upon the client's UDP tunnelling tunneling request to open a UDP socket to a target
server,
server and that generates the response to this request. If there are HTTP
intermediaries (as defined in <xref section="3.7" sectionFormat="of" target="HTTP"/>) target="RFC9110"/>) between the client and
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
(such as HTTP/1.1), any reference to "stream" in this document represents the
entire connection.</t>
      </section>
    </section>
    <section anchor="client-config">
      <name>Client Configuration</name>
      <t>HTTP clients are configured to use a UDP proxy with a URI Template
<xref target="TEMPLATE"/> target="RFC6570"/> that has the variables "target_host" and "target_port".
Examples are shown below:</t>
      <figure anchor="fig-template-examples">
        <name>URI Template Examples</name>
        <artwork type="ascii-art"><![CDATA[
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{?target_host,target_port}
]]></artwork>
      </figure>
      <t>The following requirements apply to the URI Template:</t>
      <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 in absolute form, form and <bcp14>MUST</bcp14> include non-empty scheme,
authority
authority, and path components.</li>
        <li>The path component of the URI Template <bcp14>MUST</bcp14> start with a slash "/".</li> ("/").</li>
        <li>All template variables <bcp14>MUST</bcp14> be within the path or query components of the URI.</li>
        <li>The URI template Template <bcp14>MUST</bcp14> contain the two variables "target_host" and
"target_port" and <bcp14>MAY</bcp14> contain other variables.</li>
        <li>The URI Template <bcp14>MUST NOT</bcp14> contain any non-ASCII unicode Unicode characters and <bcp14>MUST</bcp14>
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> target="RFC3986"/>).</li>
        <li>The URI Template <bcp14>MUST NOT</bcp14> use Reserved Expansion ("+" operator), Fragment
Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment
Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with
Semicolon-Prefix.</li>
      </ul>
      <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.
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
sending it to the UDP proxy.</t>
      <t>Since the
      <t>The original HTTP CONNECT method allowed conveying for the conveyance of the target host
and
port port, but not the scheme, proxy authority, path, nor query, there exist or query. Thus, clients
with proxy configuration interfaces that only allow the user to configure the
proxy host and the proxy port. port exist. Client implementations of this
specification that are constrained by such limitations <bcp14>MAY</bcp14> attempt to access UDP
proxying capabilities using the default template, which is defined as:
"https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/udp/{target_host}/{target_port}/" as
"https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/udp/{target_host}/{target_port}/",
where $PROXY_HOST and $PROXY_PORT are the configured host and port of the UDP
proxy
proxy, respectively. UDP proxy deployments <bcp14>SHOULD</bcp14> offer service at this location
if they need to interoperate with such clients.</t>
    </section>
    <section anchor="tunnelling-udp-over-http">
      <name>Tunnelling anchor="tunneling-udp-over-http">
      <name>Tunneling UDP over HTTP</name>
      <t>To allow negotiation of a tunnel for UDP over HTTP, this document defines the
"connect-udp" HTTP Upgrade Token. upgrade token. The resulting UDP tunnels use the Capsule
Protocol (see <xref section="3.2" sectionFormat="of" target="HTTP-DGRAM"/>) target="RFC9297"/>) with HTTP Datagrams in the format
defined in <xref target="format"/>.</t>
      <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
indicated by the client to the UDP proxy via the "target_host" and "target_port"
variables of the URI Template, Template; see <xref target="client-config"/>. If the request is
successful, the UDP proxy commits to converting received HTTP Datagrams into UDP
packets and vice versa until the tunnel is closed.</t>
      <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 target="client-config"/>.</t>
      <t>"target_host" supports using DNS names, IPv6 literals and IPv4 literals. Note
that IPv6 scoped addressing zone identifiers are not supported. Also note that this URI Template
expansion requires 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 percent-encoding, so for example
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>MUST</bcp14> be
percent-encoded. For example, if the target_host target host is "2001:db8::42", it will be
encoded in the URI as "2001%3Adb8%3A%3A42".</t> "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
expansion to determine the path and query of its request.</t>
      <t>If the request is successful, the UDP proxy commits to converting received HTTP
Datagrams into UDP packets, and vice versa, until the tunnel is closed.</t>
      <t>By virtue of the definition of the Capsule Protocol (see <xref section="3.2" sectionFormat="of" target="HTTP-DGRAM"/>), target="RFC9297"/>), UDP proxying requests do not carry any message content.
Similarly, successful UDP proxying responses also do not carry any message
content.</t>
      <section anchor="handling">
        <name>UDP Proxy Handling</name>
        <t>Upon receiving a UDP proxying request:</t>
        <ul spacing="normal">
          <li>if the recipient is configured to use another HTTP proxy, it will act as an
intermediary: it forwards
intermediary by forwarding the request to another HTTP server. Note that such
intermediaries may need to reencode 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
request encoding differs by version (see below).</li>
          <li>otherwise, the recipient will act as a UDP proxy: it proxy. It extracts the
"target_host" and "target_port" variables from the URI it has reconstructed
from the request headers, decodes their percent-encoding, and establishes a
tunnel by directly opening a UDP socket to the requested target.</li>
        </ul>
        <t>Unlike TCP, UDP is connection-less. connectionless. The UDP proxy that opens the UDP socket has
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
the target_host "target_host" is a DNS name, the UDP proxy <bcp14>MUST</bcp14> perform DNS resolution
before replying to the HTTP request. If errors occur during this process, the
UDP proxy <bcp14>MUST</bcp14> reject the request and <bcp14>SHOULD</bcp14> send details using an appropriate
"Proxy-Status"
Proxy-Status header field <xref target="PROXY-STATUS"/> (for target="RFC9209"/>. For example, if DNS
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> target="RFC9209"/>.</t>
        <t>UDP proxies can use connected UDP sockets if their operating system supports
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
socket, it <bcp14>MUST</bcp14> validate the IP source address and UDP source port on received
packets to ensure they match the client's request. Packets that do not match
<bcp14>MUST</bcp14> be discarded by the UDP proxy.</t>
        <t>The lifetime of the socket is tied to the request stream. The UDP proxy <bcp14>MUST</bcp14>
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 usable, it <bcp14>MUST</bcp14>
close the request stream. For example, this can happen when an ICMP "Destination Unreachable" Destination
Unreachable message is
received, received; see <xref section="3.1" sectionFormat="of" target="ICMP6"/>), it <bcp14>MUST</bcp14> close the request
stream. target="RFC4443"/>. UDP
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. UDP proxies that close sockets
after a period of inactivity <bcp14>SHOULD NOT</bcp14> use a period lower than two minutes, minutes; see
<xref section="4.3" sectionFormat="of" target="BEHAVE"/>.</t> target="RFC4787"/>.</t>
        <t>A successful response (as defined in Sections <xref format="counter" target="resp1"/> and <xref format="counter" target="resp23"/>)
indicates that the UDP proxy has opened a socket to the requested target and is
willing to proxy UDP payloads. Any response other than a successful response
indicates that the request has failed, and failed; thus, the client <bcp14>MUST</bcp14> therefore abort the request.</t>
        <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.
In IPv4, the Don't Fragment (DF) bit <bcp14>MUST</bcp14> be set set, if possible, to prevent
fragmentation on the path. Future extensions <bcp14>MAY</bcp14> remove these requirements.</t>
        <t>Implementers of UDP proxies will benefit from reading the guidance in
<xref target="UDP-USAGE"/>.</t> target="RFC8085"/>.</t>
      </section>
      <section anchor="req1">
        <name>HTTP/1.1 Request</name>
        <t>When using HTTP/1.1 <xref target="H1"/>, target="RFC9112"/>, a UDP proxying request will meet the following
requirements:</t>
        <ul spacing="normal">
          <li>the method <bcp14>SHALL</bcp14> be "GET".</li>
          <li>the request <bcp14>SHALL</bcp14> include a single "Host" Host header field containing the origin
of the UDP proxy.</li>
          <li>the request <bcp14>SHALL</bcp14> include a "Connection" Connection header field with value "Upgrade"
(note that this requirement is case-insensitive as per <xref section="7.6.1" sectionFormat="of" target="HTTP"/>).</li> target="RFC9110"/>).</li>
          <li>the request <bcp14>SHALL</bcp14> include an "Upgrade" Upgrade header field with value "connect-udp".</li>
        </ul>
        <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 error, error and <bcp14>SHOULD</bcp14>
use the 400 (Bad Request) status code.</t>
        <t>For example, if the client is configured with URI Template
"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
following request:</t>
        <figure anchor="fig-req-h1">
          <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
Host: example.org
Connection: Upgrade
Upgrade: connect-udp
Capsule-Protocol: ?1
]]></sourcecode>
]]></artwork>
        </figure>
        <t>In HTTP/1.1, this protocol uses the GET method to mimic the design of the
WebSocket Protocol <xref target="WEBSOCKET"/>.</t> target="RFC6455"/>.</t>
      </section>
      <section anchor="resp1">
        <name>HTTP/1.1 Response</name>
        <t>The UDP proxy <bcp14>SHALL</bcp14> indicate a successful response by replying with the
following requirements:</t>
        <ul spacing="normal">
          <li>the HTTP status code on the response <bcp14>SHALL</bcp14> be 101 (Switching Protocols).</li>
          <li>the reponse response <bcp14>SHALL</bcp14> include a "Connection" Connection header field with value "Upgrade"
(note that this requirement is case-insensitive as per <xref section="7.6.1" sectionFormat="of" target="HTTP"/>).</li> target="RFC9110"/>).</li>
          <li>the response <bcp14>SHALL</bcp14> include a single "Upgrade" Upgrade header field with value
"connect-udp".</li>
          <li>the response <bcp14>SHALL</bcp14> meet the requirements of HTTP responses that start the
Capsule Protocol; see <xref section="3.2" sectionFormat="of" target="HTTP-DGRAM"/>.</li> target="RFC9297"/>.</li>
        </ul>
        <t>If any of these requirements are not met, the client <bcp14>MUST</bcp14> treat this proxying
attempt as failed and abort the connection.</t>
        <t>For example, the UDP proxy could respond with:</t>
        <figure anchor="fig-resp-h1">
          <name>Example HTTP/1.1 Response</name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-udp
Capsule-Protocol: ?1
]]></sourcecode>
        </figure>
      </section>
      <section anchor="req23">
        <name>HTTP/2 and HTTP/3 Requests</name>
        <t>When using HTTP/2 <xref target="H2"/> target="RFC9113"/> or HTTP/3 <xref target="H3"/>, target="RFC9114"/>, UDP proxying requests use HTTP
Extended CONNECT. This requires that servers send an HTTP Setting as specified
in <xref target="EXT-CONNECT2"/> target="RFC8441"/> and <xref target="EXT-CONNECT3"/>, target="RFC9220"/> and that requests use HTTP
pseudo-header fields with the following requirements:</t>
        <ul spacing="normal">
          <li>The ":method" :method pseudo-header field <bcp14>SHALL</bcp14> be "CONNECT".</li>
          <li>The ":protocol" :protocol pseudo-header field <bcp14>SHALL</bcp14> be "connect-udp".</li>
          <li>The ":authority" :authority pseudo-header field <bcp14>SHALL</bcp14> contain the authority of the UDP
proxy.</li>
          <li>The ":path" :path and ":scheme" :scheme pseudo-header fields <bcp14>SHALL NOT</bcp14> be empty. Their
values <bcp14>SHALL</bcp14> contain the scheme and path from the URI Template after the URI
template
Template expansion process has been completed.</li>
        </ul>
        <t>A UDP proxying request that does not conform to these restrictions is
malformed (see <xref section="8.1.1" sectionFormat="of" target="H2"/> target="RFC9113"/> and <xref section="4.1.2" sectionFormat="of" target="H3"/>).</t> target="RFC9114"/>).</t>
        <t>For example, if the client is configured with URI Template
"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
following request:</t>
        <figure anchor="fig-req-h2">
          <name>Example HTTP/2 Request</name>
          <sourcecode type="http-message"><![CDATA[
HEADERS
:method = CONNECT
:protocol = connect-udp
:scheme = https
:path = /.well-known/masque/udp/192.0.2.6/443/
:authority = example.org
capsule-protocol = ?1
]]></sourcecode>
        </figure>
      </section>
      <section anchor="resp23">
        <name>HTTP/2 and HTTP/3 Responses</name>
        <t>The UDP proxy <bcp14>SHALL</bcp14> indicate a successful response by replying with the
following requirements:</t>
        <ul spacing="normal">
          <li>the HTTP status code on the response <bcp14>SHALL</bcp14> be in the 2xx (Successful) range.</li>
          <li>the response <bcp14>SHALL</bcp14> meet the requirements of HTTP responses that start the
Capsule Protocol; see <xref section="3.2" sectionFormat="of" target="HTTP-DGRAM"/>.</li> target="RFC9297"/>.</li>
        </ul>
        <t>If any of these requirements are not met, the client <bcp14>MUST</bcp14> treat this proxying
attempt as failed and abort the request.</t>
        <t>For example, the UDP proxy could respond with:</t>
        <figure anchor="fig-resp-h2">
          <name>Example HTTP/2 Response</name>
          <sourcecode type="http-message"><![CDATA[
HEADERS
:status = 200
capsule-protocol = ?1
]]></sourcecode>
        </figure>
      </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-version" header
field is a
<eref target="https://www.rfc-editor.org/rfc/rfc8941#section-3.1">List Structured Field</eref>.
Each list member <bcp14>MUST</bcp14> be an Integer.</t>
      </section>
    </section>
    <section anchor="context-id">
      <name>Context Identifiers</name>
      <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
payloads. Some of these extensions can augment UDP payloads with additional
data, while others can exchange data that is completely separate from UDP
payloads. In order to accomplish this, all HTTP Datagrams associated with UDP
Proxying request streams start with a context ID, Context ID field; see <xref target="format"/>.</t>
      <t>Context IDs are 62-bit integers (0 to 2<sup>62</sup>-1). Context IDs are encoded
as variable-length integers, integers; see <xref section="16" sectionFormat="of" target="QUIC"/>. target="RFC9000"/>. The context Context ID value of
0 is reserved for UDP payloads, while non-zero values are dynamically allocated:
non-zero allocated.
Non-zero even-numbered context Context IDs are client-allocated, and odd-numbered
context
Context IDs are proxy-allocated. The context Context ID namespace is tied to a given
HTTP request: request; it is possible for a context Context ID with the same numeric value to be
simultaneously allocated in distinct requests, potentially with different
semantics. Context IDs <bcp14>MUST NOT</bcp14> be re-allocated within a given HTTP namespace
but <bcp14>MAY</bcp14> be allocated in any order. The context Context ID allocation restrictions to the
use of even-numbered and odd-numbered context Context IDs exist in order to avoid the
need for synchronisation synchronization between endpoints. However, once a context Context ID has been
allocated, those restrictions do not apply to the use of the context ID: Context ID; it can
be used by any client or UDP proxy, independent of which endpoint initially
allocated it.</t>
      <t>Registration is the action by which an endpoint informs its peer of the
semantics and format of a given context Context ID. This document does not define how
registration occurs. Future extensions <bcp14>MAY</bcp14> use HTTP header fields or capsules to
register contexts. Context IDs. Depending on the method being used, it is possible for
datagrams to be received with Context IDs which that have not yet been registered,
for instance registered. For
instance, this can be due to reordering of the packet containing the datagram
and the packet containing the registration message during transmission.</t>
    </section>
    <section anchor="format">
      <name>HTTP Datagram Payload Format</name>
      <t>When HTTP Datagrams (see <xref section="2" sectionFormat="of" target="HTTP-DGRAM"/>) target="RFC9297"/>) are associated with UDP
proxying
Proxying request streams, the HTTP Datagram Payload field has the format defined
in <xref target="dgram-format"/>. target="dgram-format"/>, using notation from <xref section="1.3" sectionFormat="of" target="RFC9000"/>. Note that when
HTTP Datagrams are encoded using QUIC DATAGRAM frames <xref target="DGRAM"/>, target="RFC9221"/>,
the Context ID field defined below directly follows the Quarter Stream ID field field,
which is at the start of the QUIC DATAGRAM frame payload (see payload; see <xref section="2.1" sectionFormat="of" target="HTTP-DGRAM"/>).</t> target="RFC9297"/>.</t>
      <figure anchor="dgram-format">
        <name>UDP Proxying HTTP Datagram Format</name>
        <artwork type="ascii-art"><![CDATA[
UDP Proxying HTTP Datagram Payload {
  Context ID (i),
  UDP Proxying Payload (..),
}
]]></artwork>
      </figure>
      <dl spacing="compact">
        <dt>Context ID:</dt>
        <dd>
          <t>A variable-length integer (see <xref section="16" sectionFormat="of" target="QUIC"/>) target="RFC9000"/>) that contains the value
of the Context ID. If an HTTP/3 Datagram which that carries an unknown Context ID is
received, the receiver <bcp14>SHALL</bcp14> either drop that datagram silently or buffer it
temporarily (on the order of a round trip) while awaiting the registration of
the corresponding Context ID.</t>
        </dd>
        <dt>Payload:</dt>
        <dt>UDP Proxying Payload:</dt>
        <dd>
          <t>The payload of the datagram, whose semantics depend on the value of the
previous field. Note that this field can be empty.</t>
        </dd>
      </dl>
      <t>UDP packets are encoded using HTTP Datagrams with the Context ID field set to
zero. When the Context ID field is set to zero, the UDP Proxying Payload field
contains the unmodified payload of a UDP packet (referred to as "data octets" data octets in
<xref target="UDP"/>).</t> target="RFC0768"/>).</t>
      <t>By virtue of the definition of the UDP header <xref target="UDP"/>, target="RFC0768"/>, it is not possible to
encode UDP payloads longer than 65527 bytes. Therefore, endpoints <bcp14>MUST NOT</bcp14> send
HTTP Datagrams with a UDP Proxying Payload field longer than 65527 using Context
ID zero. An endpoint that receives an HTTP Datagram using Context ID zero whose
UDP Proxying Payload field is longer than 65527 <bcp14>MUST</bcp14> abort the corresponding
stream. If a UDP proxy knows it can only send out UDP packets of a certain
length due to its underlying link MTU, it has no choice but to discard incoming
HTTP Datagrams using Context ID zero whose UDP Proxying Payload field is longer
than that limit. If the discarded HTTP Datagram was transported by a DATAGRAM
capsule, the receiver <bcp14>SHOULD</bcp14> discard that capsule without buffering the capsule
contents.</t>
      <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 silently or
buffer it temporarily (on the order of a round trip) while awaiting the
corresponding request.</t>
      <t>Note that buffering datagrams (either because the request was not yet received, received
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
resource exhaustion occuring. occurring. For example, receivers can limit the total number
of buffered datagrams, datagrams or the cumulative size of buffered datagrams, datagrams on a
per-stream, per-context, or per-connection basis.</t>
      <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
note that such proxied packets may not be processed by the UDP proxy if it
responds to the request with a failure, failure or if the proxied packets are received by
the UDP proxy before the request and the UDP proxy chooses to not buffer them.</t>
    </section>
    <section anchor="performance">
      <name>Performance Considerations</name>
      <t>Bursty traffic can often lead to temporally correlated packet losses, which losses; in
turn turn,
this can lead to suboptimal responses from congestion controllers in protocols
running over UDP. To avoid this, UDP proxies <bcp14>SHOULD</bcp14> strive to avoid increasing
burstiness of UDP traffic: traffic; they <bcp14>SHOULD NOT</bcp14> queue packets in order to increase
batching.</t>
      <t>When the protocol running over UDP that is being proxied uses congestion control
(e.g., <xref target="QUIC"/>), target="RFC9000"/>), the proxied traffic will incur at least two nested congestion
controllers. The underlying HTTP connection <bcp14>MUST NOT</bcp14> disable congestion control
unless it has an out-of-band way of knowing with absolute certainty that the
inner traffic is congestion-controlled.</t>
      <t>If a client or UDP proxy with a connection containing a UDP proxying Proxying request
stream disables congestion control, it <bcp14>MUST NOT</bcp14> signal Explicit Congestion
Notification (ECN) <xref target="ECN"/> 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 to report ECN
feedback via QUIC ACK_ECN frames or the TCP "ECE" ECE bit, as the peer may not have
disabled congestion control.</t>
      <t>When the protocol running over UDP that is being proxied uses loss recovery
(e.g., <xref target="QUIC"/>), target="RFC9000"/>), and the underlying HTTP connection runs over TCP, the proxied
traffic will incur at least two nested loss recovery mechanisms. This can reduce
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
QUIC DATAGRAM frame.</t>
      <section anchor="mtu-considerations">
        <name>MTU Considerations</name>
        <t>When using HTTP/3 with the QUIC Datagram extension <xref target="DGRAM"/>, target="RFC9221"/>, UDP payloads
are transmitted in QUIC DATAGRAM frames. Since those cannot be fragmented, they
can only carry payloads up to a given length determined by the QUIC connection
configuration and the path MTU. Path MTU (PMTU). If a UDP proxy is using QUIC DATAGRAM
frames and it receives a UDP payload from the target that will not fit inside a
QUIC DATAGRAM frame, the UDP proxy <bcp14>SHOULD NOT</bcp14> send the UDP payload in a DATAGRAM
capsule, as that defeats the end-to-end unreliability characteristic that
methods such as Datagram Packetization Layer Path MTU PMTU Discovery (DPLPMTUD) depend on
<xref target="DPLPMTUD"/>. target="RFC8899"/>. In this scenario, the UDP proxy <bcp14>SHOULD</bcp14> drop the UDP
payload and send an ICMP "Packet Packet Too Big" Big message to the target, target; see <xref section="3.2" sectionFormat="of" target="ICMP6"/>.</t> target="RFC4443"/>.</t>
      </section>
      <section anchor="tunneling-of-ecn-marks">
        <name>Tunneling of ECN Marks</name>
        <t>UDP proxying does not create an IP-in-IP tunnel, so the guidance in
<xref target="ECN-TUNNEL"/> 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>
        <t>Note
        <t>In this specification, note that UDP proxying clients do not have the ability in this specification to
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
proxy.</t>
        <t>A UDP proxy <bcp14>MUST</bcp14> ignore ECN bits in the IP header of UDP packets received from
the target, and it <bcp14>MUST</bcp14> set the ECN bits to Not-ECT on UDP packets it sends to
the target. These do not relate to the ECN markings of packets sent between
client and UDP proxy in any way.</t>
      </section>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <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
attributed to the UDP proxy. HTTP servers that support UDP proxying ought to
restrict its use to authenticated users.</t>
      <t>There exist software and network deployments that perform access control checks
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.
Such software could be running on the same host as the UDP proxy, proxy or in the same
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
control, UDP proxying clients could use the UDP proxy to escalate their access
privileges beyond those they might otherwise have. This could lead to
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
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" sectionFormat="of" target="PROXY-STATUS"/> target="RFC9209"/> when rejecting such requests.</t>
      <t>UDP proxies share many similarities to with TCP CONNECT proxies when considering
them as infrastructure for abuse to enable denial of service denial-of-service (DoS) attacks. Both
can obfuscate the attacker's source address from the attack target. In the case
of a stateless volumetric attack (e.g., a TCP SYN flood or a UDP flood), both
types of proxies pass the traffic to the target host. With stateful volumetric
attacks (e.g., HTTP flooding) being sent over a TCP CONNECT proxy, the proxy
will only send data if the target has indicated its willingness to accept data
by responding with a TCP SYN-ACK. Once the path to the target is flooded, the
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
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
it is willing to forward until it has observed a response from the target, that
provides limited protection against denial of service DoS attacks when attacks target open UDP
ports where the protocol running over UDP would respond, respond and that would be
interpreted as willingness to accept UDP by the UDP proxy. Such a packet limit
could also cause issues for valid traffic.</t>
      <t>The security considerations described in <xref section="4" sectionFormat="of" target="HTTP-DGRAM"/> target="RFC9297"/> also apply
here. Since it is possible to tunnel IP packets over UDP, the guidance in
<xref target="TUNNEL-SECURITY"/> target="RFC6169"/> can apply.</t>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <section anchor="iana-upgrade">
        <name>HTTP Upgrade Token</name>
        <t>This document will request IANA to register
        <t>IANA has registered "connect-udp" in the "HTTP Upgrade Tokens" registry
maintained at &lt;<eref target="https://www.iana.org/assignments/http-upgrade-tokens"/>&gt;.</t>
        <dl spacing="compact">
          <dt>Value:</dt>
          <dd>
            <t>connect-udp</t>
          </dd>
          <dt>Description:</dt>
          <dd>
            <t>Proxying of UDP Payloads</t>
          </dd>
          <dt>Expected Version Tokens:</dt>
          <dd>
            <t>None</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t>This document</t>
            <t>RFC 9298</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-uri">
        <name>Well-Known URI</name>
        <t>This document will request IANA to register
        <t>IANA has registered "masque" in the "Well-Known URIs" registry maintained at
&lt;<eref target="https://www.iana.org/assignments/well-known-uris"/>&gt;.</t>
        <dl spacing="compact">
          <dt>URI Suffix:</dt>
          <dd>
            <t>masque</t>
          </dd>
          <dt>Change Controller:</dt>
          <dd>
            <t>IETF</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t>This document</t>
            <t>RFC 9298</t>
          </dd>
          <dt>Status:</dt>
          <dd>
            <t>permanent (if this document is approved)</t>
            <t>permanent</t>
          </dd>
          <dt>Related Information:</dt>
          <dd>
            <t>Includes all resources identified with the path prefix
"/.well-known/masque/udp/"</t>
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
      <displayreference target="H1" target="RFC9112" to="HTTP/1.1"/>
      <displayreference target="H2" target="RFC9113" to="HTTP/2"/>
      <displayreference target="H3" 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>
      <name>References</name>
      <references>
        <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="Reschke">
              <organization/>
            </author>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection 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="Thomson">
              <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 semantics 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 exchanges 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="Bishop">
              <organization/>
            </author>
            <date month="June" year="2022"/>
            <abstract>
              <t>The QUIC transport protocol has several features that are desirable

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9113.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 a transport for HTTP, such EDIT state as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that 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="Reschke">
              <organization/>
            </author>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, 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 07/07/22; companion document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 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="Iyengar">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <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 communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion 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 describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template 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> 9297 -->

<reference anchor="HTTP-DGRAM"> anchor="RFC9297" target="https://www.rfc-editor.org/info/rfc9297">
<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 conveying
   multiplexed, potentially unreliable datagrams inside an HTTP
   connection.

   In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC
   DATAGRAM extension.  When the QUIC DATAGRAM frame is unavailable or
   undesirable, they can be sent using the Capsule Protocol, a more
   general convention for conveying data in HTTP connections.

   HTTP Datagrams and the Capsule Protocol are intended for use by HTTP
   extensions, not applications.

              </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 Protocol (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-version-specific details need to be specified. This document describes how the mechanism 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</title>
            <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 signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  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</title>
            <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 protocol  specifications.  This document aims to reduce the ambiguity by clarifying that 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 convey the details of an intermediary's response handling, including generated errors.</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" month="August" year="2022"/>
            <abstract>
              <t>This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection.</t>
            </abstract>
</front>
<seriesInfo name="RFC" value="9221"/> value="9297"/>
<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="Ramakrishnan">
              <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 Congestion 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"/> 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"/>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="URI">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
              <organization/>
            </author>
            <author fullname="R. Fielding" initials="R." surname="Fielding">
              <organization/>
            </author>
            <author fullname="L. Masinter" initials="L." surname="Masinter">
              <organization/>
            </author>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [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 Protocol 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="Gupta">
              <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 Control 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="Audet">
              <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 different 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 that these applications will function properly.  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="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-passing transport that has no inherent congestion control mechanisms.  This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP.  Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</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 Internet transport must employ mechanisms to prevent congestion collapse and to establish 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 protocols (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 multicast 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 over 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 Transports</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 Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram.  This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased.  This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified 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 Datagram PMTUD into IETF datagram transports or applications that use datagram transports.</t>
              <t>This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, 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 notification (ECN) field of the IP header should be constructed on entry to and exit from any 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 decapsulation, 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 field 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 supported.  Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility.  Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification.  A thorough 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 that 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 administrators and future protocol developers.  The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed 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>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4787.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6455.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6169.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-schwartz-httpbis-helium-00.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-pardue-httpbis-http-network-tunnelling-00.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-schinazi-masque-00.xml"/>

      </references>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
 <t>This document is a product of the MASQUE Working Group, and
      the author thanks all MASQUE enthusiasts for their contibutions.
      contributions. This proposal was inspired directly or indirectly
      by prior work from many people, in particular
<eref target="https://www.ietf.org/archive/id/draft-schwartz-httpbis-helium-00.txt">HELIUM</eref> <xref target="I-D.schwartz-httpbis-helium"/>
      by Ben Schwartz,
<eref target="https://www.ietf.org/archive/id/draft-pardue-httpbis-http-network-tunnelling-00.txt">HiNT</eref> <contact fullname="Ben Schwartz"/>, <xref target="I-D.pardue-httpbis-http-network-tunnelling"/>
      by Lucas Pardue, <contact fullname="Lucas Pardue"/>, and the original
<eref target="https://www.ietf.org/archive/id/draft-schinazi-masque-00.txt">MASQUE Protocol</eref> MASQUE Protocol <xref target="I-D.schinazi-masque"/>  by the author of this document.</t>

      <t>The author would like to thank Eric Rescorla <contact fullname="Eric
      Rescorla"/> for suggesting the use of an HTTP method to proxy
      UDP. The author is indebted to Mark Nottingham <contact fullname="Mark
      Nottingham"/> and Lucas Pardue <contact fullname="Lucas Pardue"/> for the
      many improvements they contributed to this document. The
      extensibility design in this document came out of the HTTP
      Datagrams Design Team, whose members were Alan Frindell, Alex Chernyakhovsky, Ben Schwartz, Eric Rescorla,
Lucas Pardue, Marcus Ihlar, Martin Thomson, Mike Bishop, Tommy Pauly, Victor
Vasiliev, <contact
      fullname="Alan Frindell"/>, <contact fullname="Alex
      Chernyakhovsky"/>, <contact fullname="Ben Schwartz"/>, <contact
      fullname="Eric Rescorla"/>, <contact fullname="Lucas Pardue"/>,
      <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>
  </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>