<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-pardue-httpbis-http-network-tunnelling-01" category="info">

  <front>
    <title abbrev="HTTP-initiated Network Tunnelling (HiNT)">HTTP-initiated Network Tunnelling (HiNT)</title>

    <author initials="L." surname="Pardue" fullname="Lucas Pardue">
      <organization></organization>
      <address>
        <email>lucaspardue.24.7@gmail.com</email>
      </address>
    </author>

    <date year="2018" month="October" day="18"/>

    <area>Art</area>
    <workgroup>httpbis</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The HTTP CONNECT method allows an HTTP client to initiate, via a proxy, a
 TCP-based tunnel to a single destination origin. This memo explores options for
 expanding HTTP-initiated Network Tunnelling (HiNT) to cater for diverse UDP and
 IP associations.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>A wide range of network tunnelling solutions already exist (e.g. SOCKS
<xref target="RFC1928"/>, TURN <xref target="RFC5766"/> etc.), with various applicability. So why
consider creating another one? Several tunnelling specifications reserve well
known TCP or UDP ports that are easy to block. Even if port usage is
more agile, plain text communications allow potential attackers to easily
analyse traffic and cause interference.</t>

<t>This document we consider options for HTTP-initiated Network Tunnelling (HiNT)
as a solution. The use case is a client behind a forward proxy but other uses
may be supported. Using HTTP as a substrate for other protocols follows a trend
seen elsewhere (DNS Queries over HTTPS <xref target="DOH"/>). Shifting to an HTTP port, makes
port blocking less effective. However, the real advantage comes from securing
HTTP (TLS <xref target="RFC5246"/>, QUIC <xref target="QUIC-TRANSPORT"/>) to provide confidentiality,
integrity and authenticity, which makes analysis and interference harder. This
also enables secure communication to a remote proxy on the Internet (in contrast
to SOCKS etc.).</t>

<t>A HiNT session is initiated by some HTTP mechanism. This could be a HTTP request
or some binary frame format (HTTP/2 and HTTP/QUIC only).</t>

<figure title="HTTP/1.1 CONNECT-based TLS tunnel" anchor="fig-h1-connect"><artwork type="drawing"><![CDATA[
Client                              Forward Proxy             Server
+                                          +                       +
|  +------------------------------------+  |                       |
|  | TCP Connection                     |  |                       |
|  |                                    |  |                       |
|  |       CONNECT example.org          |  |                       |
+=========================================>|                       |
|  |              200 OK                |  |  +-----------------+  |
|<=========================================+  | TCP Connection  |  |
|  |                                    |  |  |                 |  |
|  |  +------------------------------------------------------+  |  |
|  |  | TLS Session                     |  |  |              |  |  |
|  |  |                                 |  |  |              |  |  |
|  |  |          GET /foo               |  |  |              |  |  |
+=================================================================>|
|  |  |           200 OK                |  |  |              |  |  |
|<=================================================================+
|  |  |                                 |  |  |              |  |  |
|  |  +------------------------------------------------------+  |  |
|  |                                    |  |  |                 |  |
|  +------------------------------------+  |  +-----------------+  |
+                                          +                       +
]]></artwork></figure>

<t>The CONNECT request method (see Section 4.3.6 of <xref target="RFC7231"/>) is commonly used
to establish a tunnelled TLS session with an origin identified by a
request-target. In HTTP/1.1, the entire client-to-proxy HTTP connection is
converted into a tunnel (<xref target="fig-h1-connect"/>). In HTTP/2 (see Section 8.3 of
<xref target="RFC7540"/>) and HTTP/QUIC (see Section 3.1.2 of <xref target="QUIC-HTTP"/>), a single
stream gets dedicated to a tunnel (<xref target="fig-h2-and-hq-connect"/>).</t>

<figure title="HTTP/2 and HTTP/QUIC CONNECT-based TLS tunnel" anchor="fig-h2-and-hq-connect"><artwork type="drawing"><![CDATA[
Client                              Forward Proxy             Server
+                                          +                       +
|  +------------------------------------+  |                       |
|  | TCP Connection or UDP Association  |  |                       |
|  |  +------------------------------+  |  |                       |
|  |  | TLS or QUIC Security Context |  |  |                       |
|  |  |  +------------------------+  |  |  |                       |
|  |  |  | HTTP/2 or HTTP/QUIC    |  |  |  |                       |
|  |  |  | Stream                 |  |  |  |                       |
|  |  |  |                        |  |  |  |                       |
|  |  |  |  CONNECT example.org   |  |  |  |                       |
+=========================================>|                       |
|  |  |  |         200 OK         |  |  |  |  +-----------------+  |
|<=========================================+  | TCP Connection  |  |
|  |  |  |                        |  |  |  |  |                 |  |
|  |  |  |  +------------------------------------------------+  |  |
|  |  |  |  | TLS Session         |  |  |  |  |              |  |  |
|  |  |  |  |  +------------------------------------------+  |  |  |
|  |  |  |  |  | HTTP/2 Stream    |  |  |  |  |           |  |  |  |
|  |  |  |  |  |                  |  |  |  |  |           |  |  |  |
|  |  |  |  |  |  GET /foo        |  |  |  |  |           |  |  |  |
+=================================================================>|
|  |  |  |  |  |   200 OK         |  |  |  |  |           |  |  |  |
|<=================================================================+
|  |  |  |  |  |                  |  |  |  |  |           |  |  |  |
|  |  |  |  |  +------------------------------------------+  |  |  |
|  |  |  |  |                     |  |  |  |  |              |  |  |
|  |  |  |  +------------------------------------------------+  |  |
|  |  |  |                        |  |  |  |  |                 |  |
|  |  |  +------------------------+  |  |  |  |                 |  |
|  |  |                              |  |  |  |                 |  |
|  |  +------------------------------+  |  |  |                 |  |
|  |                                    |  |  |                 |  |
|  +------------------------------------+  |  +-----------------+  |
+                                          +                       +
]]></artwork></figure>

<t>A proxy that supports CONNECT blindly forwards packets, in both directions,
using TCP for both client-to-proxy and proxy-to-origin hops. The use of TCP for
the latter hop is a limiting factor: other application or transport protocols
are unsupported. This document specifically concerns itself with finding a
solution that permits a UDP-based HTTP/QUIC client behind an HTTP proxy to
establish an HTTP/QUIC session with the origin. Without such a capability, there
continues to be a dependency on origins to support TCP-based HTTP (for a small
subset of the client population).</t>

<t>The document is arranged in the following order:</t>

<t><list style="symbols">
  <t>Design aspects are considered in <xref target="design-aspects"/>.</t>
  <t>Tunnel initiation options are surveyed in <xref target="hint-req-options"/>.</t>
  <t>Messaging (post-handshake data transfer) options are surveyed in <xref target="hint-messaging-options"/>.</t>
  <t>Four candidate solutions are presented in <xref target="candidate-solutions"/>, based on the above options.</t>
</list></t>

<t>Candidate solutions have the purpose of stimulating discussion in the community
in order to drive toward a single solution.</t>

</section>
<section anchor="notational-conventions" title="Notational Conventions">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” 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>

<section anchor="definitions" title="Definitions">

<t>Definitions of terms that are used in this document:</t>

<t><list style="symbols">
  <t>HiNT request: a message that requests the establishment of a network tunnel to a HiNT destination.</t>
  <t>HiNT response: a message that confirms the establishment of a network tunnel.</t>
  <t>HiNT message: a message that allows data transfer between client, proxy and/or destination during a HiNT session.</t>
  <t>HiNT client: an HTTP endpoint that sends a HiNT request to a HiNT proxy. Also referred to as a client.</t>
  <t>HiNT proxy: an HTTP endpoint that services HiNT requests. It returns a HiNT response that indicates the outcome of network tunnel creation. Also referred to as a proxy.</t>
  <t>HiNT destination: the service that the HiNT client is trying to reach via a HiNT proxy. Also referred to as a destination.</t>
  <t>HiNT session: a specific instance of a network tunnel.</t>
  <t>Network Tunnel: describes any forms of association between client and destination (end-to-end). A tunnel ceases to exist when both ends of the association are closed (implicitly or explicitly).</t>
</list></t>

</section>
</section>
<section anchor="design-aspects" title="Design Consideration Aspects">

<section anchor="http-version" title="HTTP Version">

<t>The design should consider if all HTTP Versions need be supported. Differences
in version syntax (in particular binary framing and streams) may provide certain
design advantages.</t>

</section>
<section anchor="http-forward-proxying" title="HTTP Forward Proxying">

<t>The design considers the “forward proxying” intermediary (see Section 2.3
of <xref target="RFC7230"/>) model, which is widely deployed.</t>

<t>HTTP clients may use a range of methods to discover the presence of an HTTP
proxy (WPAD, DHCP, manual configuration). Client application-layer
communications remain unaware of such configuration. (In other words, handshake
and data transfer interactions with the HTTP proxy are invisible to the
application layer.)</t>

<t>Intermediaries may themselves have an HTTP proxy configured. A client attempting
to initiate a tunnel to a remote host may end up traversing a proxy chain. This
is a useful design characteristic and should be considered when selecting a
preferred option.</t>

</section>
<section anchor="message-destination-agility" title="Message Destination Agility">

<t>The CONNECT method currently expresses a request-target. This is a “fixed
destination mode” where all messages travel on the same fixed TCP path to the
same destination (ignoring lower level network elements).</t>

<t>The design should consider if more agile approach i.e. a “per-message
destination mode” would support new network interaction models. This may add
per-message overhead but optimisation may be possible.</t>

</section>
<section anchor="pmtud" title="Path MTU Discovery">
<t>The design should consider that endpoints may want/be required to avoid IP
fragmentation. Support for reasonable attempts at path MTU discovery (PMTUD)
should be included. Traditional PMTUD methods (such as those described in
<xref target="RFC1191"/> and <xref target="RFC8201"/> are intended for TCP and rely on ICMP and ICMPv6
messages. <xref target="RFC2293"/> catalogs some of the problems with PMTUD. Packetization
Layer PMTUD (PLPMTUD) <xref target="RFC4821"/> is an extension that describes an algorithm
that can operate at the transport layer. Datagram PLPMTUD <xref target="DPLPMTUD"/> is a
proposed further extension that describes approaches for various UDP-based
transports.</t>

</section>
<section anchor="blind-vs-in-loop" title="Blind forwarding vs. in-the-loop Processing">
<t><xref target="RFC7230"/> describes a tunnel as “a blind relay between two connections
without changing messages”. This approach may be overly restrictive for new
interaction modes.</t>

<t>In the case of CONNECT for TCP-based tunnelling, the HiNT message sent by a
client (TCP/IP packet payload) is decapsulated at the proxy and recapsulated in
a new TCP/IP packet created and sent by the proxy. The proxy performs no
processing of the HiNT message.</t>

<t><xref target="HELIUM"/> proposes an alternative model, where the proxy does (and is expected
to) modify HiNT messages.</t>

</section>
<section anchor="hol" title="Head-of-line Blocking">
<t>The current design of CONNECT-based tunnelling reserves either a whole TCP
connection (HTTP/1.1) or an ordered byte stream (HTTP/2 and HTTP/QUIC) for the
client-to-proxy hop. These are subject to head-of-line (HoL) blocking. For
example, where there is an end-to-end tunnelled HTTP/2 connection, all of its
streams are subject to the blocking on the single reserved stream. It is unknown
to the author is this is perceived to be a high impact problem.</t>

<t>This document defines HTTP/2 and HTTP/QUIC frames (<xref target="msg-xfer"/>) that are sent on
HTTP/2 or QUIC streams respecitvely.</t>

<t>For UDP or IP-based tunnels, HoL blocking may be problematic. It is unlikely
that the application expects blocking to occur, leading to potential issues.
(QUIC is specifically designed to avoid HoL blocking and is designed to
operate on unreliable UDP, a reliable bearer may adversely affect performance.)</t>

<t>Future versions of QUIC may offer partial reliability. If it were used for the
client-to-proxy hop, it could help mitigate HoL blocking</t>

<t>The design should consider the tension between the benefits of tunnelling,
impact of HoL, and HTTP version <xref target="http-version"/>.</t>

</section>
</section>
<section anchor="candidate-solutions" title="Candidate Solutions">

<t>Strawman candidate solutions are presented in order of increasing perceived
complexity. It is hoped that wider input will help shape the solution.</t>

<section anchor="connect-method-augmentation" title="CONNECT Method Augmentation">

<t>Enhance or augment the current definitions of the CONNECT method in HTTP/1.x,
HTTP/2 and HTTP/QUIC. Data exchanges between a client and a single destination
will be conveyed over existing byte streams with no additional framing. Client
and proxy are required to assign meaning to groups of bytes delivered on the
stream, which may be impractical.</t>

</section>
<section anchor="udpassociate-with-hint-frames-for-http2-and-httpquic" title="UDPASSOCIATE with HINT Frames for HTTP/2 and HTTP/QUIC">

<t>Define a new method, UDPASSOCIATE (<xref target="UDPASSOCIATE-method"/>), that reserves a stream for
the carriage of newly defined HINT frames (<xref target="hint-message-framing"/>). Data
exchanges between a client and a single destination will be conveyed using these
frames. This requires HTTP/2 or HTTP/QUIC proxies, and precludes HTTP/1.x
(because there is no means for framing HiNT messages).</t>

</section>
<section anchor="helium-over-websockets-for-all-http-versions" title="HELIUM over WebSockets for all HTTP Versions">

<t>Tunnelling of UDP or IP using HELIUM (<xref target="HELIUM"/>) over WebSockets. Data
exchanges between a client and destination(s) will be conveyed using
CBOR-encoded HIP messages. WebSockets connections between client and proxy are
established by existing means. This option would work for all HTTP versions that
support WebSockets.</t>

</section>
<section anchor="helium-over-websockets-for-http11-native-framing-for-http2-or-httpquic" title="HELIUM over WebSockets for HTTP/1.1, Native Framing for HTTP/2 or HTTP/QUIC">
<t>Tunnelling of UDP or IP using HELIUM (<xref target="HELIUM"/>). Data exchanges between a
client and destination(s) will be conveyed using HIP messages appropriate for
the HTTP version.</t>

<t>For HTTP/1.x, WebSockets with CBOR-encoded HIP messages would be used.</t>

<t>For HTTP/2 and HTTP/QUIC, HIP messages would be framed and exchanged on a stream
reserved by the new method, IPASSOCIATE (<xref target="ipassociate-method"/>).</t>

<t>There are two framing options presented: light framing (<xref target="hip-h2"/>) that uses the
CBOR-encoded format, which would allow direct reuse of code to that used for the
above WebSocket substrate; full framing (<xref target="hip-full"/>) that uses the native features
of the application layer substrate, which may have advantages.</t>

</section>
</section>
<section anchor="technical-specification-for-hint-requests" title="Technical Specification for HiNT Requests">

<t>This section outlines the technical specifications required to support the
candidate solutions. Discussion of respective merits and drawbacks is captured
in <xref target="hint-req-options"/>.</t>

<section anchor="UDPASSOCIATE-method" title="The UDPASSOCIATE Method for HTTP/1.1x">
<t>In HTTP/1.x, the UDPASSOCIATE method requests that the recipient establish a
UDP-based tunnel to the destination origin server identified by the
request-target and, if successful, thereafter restrict its behavior to blind
forwarding of UDP datagram payloads, in both directions, until the tunnel is
closed.</t>

<t>UDPASSOCIATE is intended only for use in requests to a proxy. An origin server that
receives a UDPASSOCIATE request for itself MAY respond with a 2xx (Successful) status
code to indicate that a connection is established. TODO: explicitly ban this?</t>

<t>A client sending a UDPASSOCIATE request MUST send the authority form of
request-target (Section 5.3 of <xref target="RFC7230"/>); i.e., the request-target consists
of only the host name and port number of the tunnel destination, separated by a
colon. The port number is for UDP only.</t>

<figure><artwork><![CDATA[
  UDPASSOCIATE hq.example.com:50781 HTTP/1.1
  Host: hq.example.com:50781
]]></artwork></figure>

<t>The recipient proxy can establish a tunnel either by directly connecting to the
request-target or, if configured to use another proxy, by forwarding the UDPASSOCIATE
request to the next inbound proxy. Any 2xx (Successful) response indicates that
the sender (and all inbound proxies) will switch to tunnel mode immediately
after the blank line that concludes the successful response’s header section;
data received after that blank line is from the server identified by the
request-target. Any response other than a successful response indicates that the
tunnel has not yet been formed and that the connection remains governed by HTTP.</t>

<t>TODO: how do connectionless UDP associations affirm that connection to the
remote host succeeded? Perhaps a 2xx should be formed when the proxy believes it
has sufficient capability to send or receive packets.</t>

<t>A tunnel is closed when an intermediary detects that either side has
closed its connection (explicitly or implicitly). The intermediary MUST attempt
to send any outstanding data that came from the closed side to the other side,
close both connections, and then discard any remaining data left undelivered.</t>

<t>A server MUST NOT send any Transfer-Encoding or Content-Length header fields in
a 2xx (Successful) response to UDPASSOCIATE.  A client MUST ignore any Content-Length
or Transfer-Encoding header fields received in a successful response to UDPASSOCIATE.</t>

<t>A payload within a UDPASSOCIATE request message has no defined semantics.</t>

</section>
<section anchor="the-udpassociate-method-for-http2-and-httpquic" title="The UDPASSOCIATE Method for HTTP/2 and HTTP/QUIC">
<t>In HTTP/2 and HTTP/QUIC, the UDPASSOCIATE method requests the establishment of a
tunnel to a single remote host over a single stream. This mechanism has a few
differences from the header field mapping described in <xref target="RFC7540"/>, Section
8.1.2.3:</t>

<t><list style="symbols">
  <t>The “:method” pseudo-header field is set to “UDPASSOCIATE”</t>
  <t>The “:scheme” and “:path” pseudo-header fields MUST be omitted</t>
  <t>The “:authority” pseudo-header field contains the host and port to connect to (equivalent to the authority-form of the request-target of CONNECT requests (see <xref target="RFC7230"/>, Section 5.3)).</t>
</list></t>

<t>A UDPASSOCIATE method that does not conform to these restrictions is malformed (<xref target="RFC7540"/>, Section 8.1.2.6).</t>

<t>A proxy that supports UDPASSOCIATE can establish a tunnel to the server identified in
the “:authority” pseudo-header field. Once this is completed (see earlier TODO),
the proxy sends a HEADERS frame containing a 2xx series status code to the
client.</t>

<t>A successful UDPASSOCIATE request reserves the request stream for tunnelling. After
the initial HEADERS frame sent by each peer, all subsequent frames exchanged on
this stream correspond to data sent on the UDP association.
<xref target="hint-message-framing"/>, <xref target="hip-h2"/> and <xref target="hip-full"/> explore options for
application-level framing and the mapping to UDP. Some frame types MUST NOT be
sent on the reserved stream (e.g. RST_STREAM and more TBD). An endpoint that
receives any of these MUST respond with a connection error.</t>

<t>The UDP association can be closed (explicitly or implicitly) by either peer. It
is RECOMMENDED that peers close the association explicitly using tunnelled
application-level means (if possible). Once this has happened, the client SHOULD
close the reserved stream on the client-to-proxy hop. Closing the reserved
stream before an explicit close is likely to trigger an application-level
implicit close (i.e. idle timeout).</t>

</section>
<section anchor="ipassociate-method" title="The IPASSOCIATE Method">
<t>The IPASSOCIATE method can be used by a client to request that the recipient establish an IP-based tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behaviour to blind forwarding of IP payloads, in both direction, until the tunnel is closed.</t>

<t>The IPASSOCIATE method would look and behave much like the UDPASSOCIATE method.</t>

<t>TODO: expand this definition if this method is preferred or required. Additional parameters may be required to accommodate the extra capabilities of IP-based tunnels.</t>

</section>
</section>
<section anchor="msg-xfer" title="Technical Specification for HiNT Message Transfer">
<t>This section outlines the technical specifications required to support the
candidate solutions. Discussion of respective merits and drawbacks is captured
in <xref target="hint-messaging-options"/>.</t>

<section anchor="hint-message-framing" title="HiNT Message Framing">
<t>The HINT frame carries HiNT messages between client and proxy. Is intended to be
used with versions of HTTP that support binary framing. Definitions are provided
for HTTP/2 and HTTP/QUIC, differing only in their use of padding. (The QUIC
transport (<xref target="QUIC-TRANSPORT"/>) provides padding itself.) Frames are non-critical
extensions to their respective protocols. Endpoints that do not support these
frames will ignore them.</t>

<t>The payload of each HINT frame corresponds to a UDP datagram (or IP Packet?)
sent or received by a HiNT proxy. A separate HiNT request is REQUIRED in order
to initiate the tunnel with which these frames relate.</t>

<t>HINT frames are subject to flow control. The size of HINT frames should take
into consideration the path MTU. Methods for path MTU discovery are discussed in
<xref target="pmtud"/>.</t>

<t>Frames MUST be associated with a non-control stream. If a frame is received on a
control stream, the recipient MUST respond with a connection error. For HTTP/2
this is PROTOCOL_ERROR, for HTTP/QUIC this is TBD.</t>

<section anchor="hint-h2" title="The HINT HTTP/2 Frame">

<t>The HINT HTTP/2 frame (type=0xTBD) defines the following flags (based on HTTP/2 flags):</t>

<t><list style="hanging">
  <t hangText='END_STREAM (0x1):'>
  When set, bit 0 indicates that this frame is the last that
  the endpoint will send for the identified stream. Setting this flag causes the
  stream to enter one of the “half- closed” states or the “closed” state
  (<xref target="RFC7540"/>, Section 5.1).</t>
  <t hangText='PADDED (0x8):'>
  When set, bit 3 indicates that the Pad Length field and any padding that it
  describes are present.</t>
</list></t>

<figure title="HINT HTTP/2 frame payload" anchor="fig-hint-h2-frame"><artwork type="drawing"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pad Length? (8)|                Payload (*)                  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Padding (*)                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The HINT HTTP/2 frame payload has the following fields:</t>

<t><list style="hanging">
  <t hangText='Pad Length:'>
  An OPTIONAL 8-bit field containing the length of the frame padding in
  units of octets. This field is only present if the PADDED flag is set.</t>
  <t hangText='Payload:'>
  Arbitrary octets that correspond to messages sent to/from a HiNT proxy.</t>
  <t hangText='Padding:'>
  Padding octets that contain no application semantic value.
  Padding octets MUST be set to zero when sending. A receiver is not
  obligated to verify padding but MAY treat non-zero padding as a
  connection error (<xref target="RFC7540"/>, Section 5.4.1) of type PROTOCOL_ERROR.</t>
</list></t>

<t>HINT HTTP/2 frames are subject to flow control (<xref target="RFC7540"/>, Section 5.2) and
can only be sent when a stream is in the “open” or “half-closed (remote)” state.
If an HINT HTTP/2 frame is received whose stream is not in “open” or
“half-closed (local)” state, the recipient MUST respond with a stream error
(<xref target="RFC7540"/> Section 5.4.2) of type STREAM_CLOSED.</t>

<t>The HINT HTTP/2 frame is processed hop-by-hop. An intermediary MUST NOT forward
HINT HTTP/2 frames, though it can use the information contained in HINT HTTP/2
frames in forming new HINT HTTP/2 frames to send to its own proxy.</t>

</section>
<section anchor="hint-hq" title="The HINT HTTP/QUIC Frame">

<t>The HINT HTTP/QUIC frame (type=0xTBD) defines no flags.</t>

<figure title="HINT HTTP/QUIC frame payload" anchor="fig-hint-hq-frame"><artwork type="drawing"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Payload (*)                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The HINT HTTP/QUIC frame carries arbitrary octets that correspond to messages
sent to/from a HiNT proxy. The payload MUST be non-zero-length. If a HINT
HTTP/QUIC frame is received with with a payload length of zero, the recipient
MUST respond with a stream error (<xref target="QUIC-HTTP"/>, Section 6) of type TBD.</t>

<t>The HINT HTTP/QUIC frame is processed hop-by-hop. An intermediary MUST NOT forward
HINT HTTP/QUIC frames, though it can use the information contained in HINT HTTP/QUIC
frames in forming new HINT HTTP/QUIC frames to send to its own proxy.</t>

</section>
</section>
<section anchor="hip-h2" title="Light HIP HTTP/2 Framing">
<t>The HELIUM inner protocol (HIP) <xref target="HELIUM"/> defines an abstract message
structure that may be carried on a variety of substrates.</t>

<t>The HIP HTTP/2 frame (type=0xTBD) carries CBOR-encoded HIP message. The message
type is indicated in a frame field.</t>

<t>The frame is a non-critical extension. Endpoints that do not support it will
ignore it.</t>

<t>The size of frame should take into consideration the path MTU. Methods
for path MTU discovery are discussed in <xref target="pmtud"/>.</t>

<t>Frames MUST be associated with a non-control stream. If a frame is received on a
control stream, the recipient MUST respond with a connection error. For HTTP/2
this is PROTOCOL_ERROR.</t>

<t>The HIP HTTP/2 frame defines the following flags:</t>

<t><list style="hanging">
  <t hangText='END_STREAM (0x1):'>
  When set, bit 0 indicates that this frame is the
  last that the endpoint will send for the identified stream.
  Setting this flag causes the stream to enter one of the “half-
  closed” states or the “closed” state (<xref target="RFC7540"/>, Section 5.1).</t>
  <t hangText='PADDED (0x8):'>
  When set, bit 3 indicates that the Pad Length field and any padding that it
  describes are present.</t>
</list></t>

<figure title="HIP HTTP/2 frame payload" anchor="fig-hip-h2-frame"><artwork type="drawing"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pad Length? (8)|   Type (8)    |  HIP-CBOR Message (*)       ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Padding (*)                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The HIP HTTP/2 frame payload has the following fields:</t>

<t><list style="hanging">
  <t hangText='Pad Length:'>
  An OPTIONAL 8-bit field containing the length of the frame padding in
  units of octets. This field is only present if the PADDED flag is set.</t>
  <t hangText='Type:'>
  An 8-bit field that identifies the HIP message type as defined in
  <xref target="HELIUM"/>.</t>
  <t hangText='HIP-CBOR Message:'>
  A HIP message expressed in CBOR encoding including type, metadata
  (including padding), and packet or packet-prefix.</t>
  <t hangText='Padding:'>
  Padding octets that contain no application semantic value.
  Padding octets MUST be set to zero when sending. A receiver is not
  obligated to verify padding but MAY treat non-zero padding as a
  connection error (<xref target="RFC7540"/>, Section 5.4.1) of type PROTOCOL_ERROR.</t>
</list></t>

</section>
<section anchor="hip-full" title="Full HIP HTTP/2 Framing">
<t>The OHIP, IHIP and MHIP frames (collectively xHIP) encode all HIP message data
directly in the HTTP/2 frame structure.</t>

<t>These frames are non-critical extensions, endpoints that do not support them
will ignore them.</t>

<t>The size of these frames should take into consideration the path MTU. Methods
for path MTU discovery are discussed in Section 3.4.2.</t>

<t>Frames MUST be associated with a non-control stream. If a frame is received on a
control stream, the recipient MUST respond with a connection error. For HTTP/2
this is PROTOCOL_ERROR.</t>

<t>Each xHIP frame type contains zero or more instances of the Metadata-entry
field. Fields are processed by the HIP application layer.</t>

<figure><artwork type="drawing"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Metadata-entry (*)                                      ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>A Metadata-entry field is a tuple consisting of a Key and a length-delimited Value:</t>

<figure><artwork type="drawing"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Key (16)            |      Value Length (32)      ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...                             |      Value?                 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>Specifically:</t>

<t><list style="hanging">
  <t hangText='Key:'>
  An unsigned, 16-bit integer representing the HIP metadata key.</t>
  <t hangText='Value Length:'>
  An unsigned, 16-bit integer indicating the length, in octets of the Value field.</t>
  <t hangText='Value:'>
  An OPTIONAL sequence of octets containing an application-specific value.</t>
</list></t>

<section anchor="ohip-h2" title="The OHIP HTTP/2 Frame">
<t>The OHIP HTTP/2 frame (type=0xTBD) carries an “outbound” HIP message.</t>

<t>The OHIP HTTP/2 frame defines the following flags:</t>

<t><list style="hanging">
  <t hangText='END_STREAM (0x1):'>
  When set, bit 0 indicates that this frame is the
  last that the endpoint will send for the identified stream.
  Setting this flag causes the stream to enter one of the “half-
  closed” states or the “closed” state (<xref target="RFC7540"/>, Section 5.1).</t>
  <t hangText='METADATA (0x2):'>
  When set, bit 1 indicates that the Metadata Entries field and
  metadata that is describes are present</t>
  <t hangText='PADDED (0x8):'>
  When set, bit 3 indicates that the Pad Length field and any padding
  that it describes are present.</t>
</list></t>

<figure title="OHIP HTTP/2 frame payload" anchor="fig-ohip-h2-frame"><artwork type="drawing"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pad Length? (8)|   Metadata Entries? (16)      |             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Metadata (*)                        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Payload (*)                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Padding (*)                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The OHIP HTTP/2 frame payload has the following fields:</t>

<t><list style="hanging">
  <t hangText='Pad Length:'>
  An OPTIONAL 8-bit field containing the length of the frame padding in
  units of octets. This field is only present if the PADDED flag is set.</t>
  <t hangText='Metadata Entries:'>
  An OPTIONAL 16-bit field that indicates the number of Metadata-entries
   held in the Metadata field. This field is only present if the METADATA
   flag is set.</t>
  <t hangText='Metadata:'>
  Zero or more instances of the Metadata-entry field.</t>
  <t hangText='Payload:'>
  At most one packet (or prefix of a packet), in essence, a standard IP packet
  starting with an IP header.</t>
  <t hangText='Padding:'>
  Padding octets that contain no application semantic value.
  Padding octets MUST be set to zero when sending. A receiver is not
  obligated to verify padding but MAY treat non-zero padding as a
  connection error (<xref target="RFC7540"/>, Section 5.4.1) of type PROTOCOL_ERROR.</t>
</list></t>

</section>
<section anchor="ihip-h2" title="The IHIP HTTP/2 Frame">
<t>The IHIP HTTP/2 frame (type=0xTBD) carries an “inbound” HIP message.</t>

<t>The IHIP HTTP/2 frame defines the following flags:</t>

<t><list style="hanging">
  <t hangText='END_STREAM (0x1):'>
  When set, bit 0 indicates that this frame is the
  last that the endpoint will send for the identified stream.
  Setting this flag causes the stream to enter one of the “half-
  closed” states or the “closed” state (<xref target="RFC7540"/>, Section 5.1).</t>
  <t hangText='METADATA (0x2):'>
  When set, bit 1 indicates that the Metadata Entries field and
  metadata that is describes are present</t>
  <t hangText='PADDED (0x8):'>
  When set, bit 3 indicates that the Pad Length field and any padding
  that it describes are present.</t>
</list></t>

<figure title="IHIP HTTP/2 frame payload" anchor="fig-ihip-h2-frame"><artwork type="drawing"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pad Length? (8)|   Metadata Entries? (16)      |             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...                       Metadata (*)                        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Payload (*)                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Padding (*)                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The IHIP HTTP/2 frame payload has the following fields:</t>

<t><list style="hanging">
  <t hangText='Pad Length:'>
  An OPTIONAL 8-bit field containing the length of the frame padding in
  units of octets. This field is only present if the PADDED flag is set.</t>
  <t hangText='Metadata Entries:'>
  An OPTIONAL 16-bit field that indicates the number of Metadata-entries
   held in the Metadata field. This field is only present if the METADATA
   flag is set.</t>
  <t hangText='Metadata:'>
  Zero or more instances of the Metadata-entry field.</t>
  <t hangText='Payload:'>
  A packet, in essence, a standard IP packet starting with an IP header,
  as received by the proxy.</t>
  <t hangText='Padding:'>
  Padding octets that contain no application semantic value.
  Padding octets MUST be set to zero when sending. A receiver is not
  obligated to verify padding but MAY treat non-zero padding as a
  connection error (<xref target="RFC7540"/>, Section 5.4.1) of type PROTOCOL_ERROR.</t>
</list></t>

</section>
<section anchor="mhip-h2" title="The MHIP HTTP/2 Frame">
<t>The MHIP HTTP/2 frame (type=0xTBD) carries a “meta” HIP message.</t>

<t>The MHIP HTTP/2 frame defines the following flags:</t>

<t><list style="hanging">
  <t hangText='END_STREAM (0x1):'>
  When set, bit 0 indicates that this frame is the
  last that the endpoint will send for the identified stream.
  Setting this flag causes the stream to enter one of the “half-
  closed” states or the “closed” state (<xref target="RFC7540"/>, Section 5.1).</t>
  <t hangText='METADATA (0x2):'>
  When set, bit 1 indicates that the Metadata Entries field and
  metadata that is describes are present</t>
  <t hangText='ERROR (0x4):'>
  When set, bit 2 indicates that this frame includes an Error-len field.</t>
  <t hangText='PADDED (0x8):'>
  When set, bit 3 indicates that the Pad Length field and any padding
  that it describes are present.</t>
  <t hangText='PAYLOAD (0xc):'>
  When set, bit 4 indicates that the Payload field is present</t>
</list></t>

<figure title="MHIP HTTP/2 frame payload" anchor="fig-mhip-h2-frame"><artwork type="drawing"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pad Length? (8)|   Metadata Entries? (16)      |Err Length? (8)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Metadata (*)                        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Errors (*)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Payload? (*)                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Padding (*)                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The MHIP HTTP/2 frame payload has the following fields:</t>

<t><list style="hanging">
  <t hangText='Pad Length:'>
  An OPTIONAL 8-bit field containing the length of the frame padding in
  units of octets. This field is only present if the PADDED flag is set.</t>
  <t hangText='Metadata Entries:'>
  An OPTIONAL 16-bit field that indicates the number of Metadata-entries
   held in the Metadata field. This field is only present if the METADATA
   flag is set.</t>
  <t hangText='Err Length:'>
  An OPTIONAL 8-bit field containing the length of the Errors field.
  This field is only present if the ERROR flag is set.</t>
  <t hangText='Metadata:'>
  Zero or more instances of the Metadata-entry field.</t>
  <t hangText='Errors:'>
  An OPTIONAL octet array of length Err Length. Each octet of the array
  represents a HIP error as described in <xref target="HELIUM"/>.</t>
  <t hangText='Payload:'>
  An OPTIONAL payload containing a prefix of the outbound packet as
  sent, including any parts that were modified. This field is only present if
  the PAYLOAD flag is set.</t>
  <t hangText='Padding:'>
  Padding octets that contain no application semantic value.
  Padding octets MUST be set to zero when sending. A receiver is not
  obligated to verify padding but MAY treat non-zero padding as a
  connection error (<xref target="RFC7540"/>, Section 5.4.1) of type PROTOCOL_ERROR.</t>
</list></t>

</section>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This document is partly motivated by the desire to prevent exposure to
observers, to make detection and interference more difficult. The effectiveness
of this is dependent on the chosen solution. Where HTTP is used only to
bootstrap a HiNT session, messages will be carried without additional HTTP
traffic to mask them. A more secure option would be to both bootstrap and carry
HiNT messages inside an HTTP session. This of course relies on secure HTTP to
provide confidentiality.</t>

<t>It is noted that different HiNT traffic may have different characteristics (e.g.
volumes and timing) when compared to the HTTP context that it is operating in.
Session level encryption is weak with respect to traffic analysis. HTTP/2
provides further advice about the use of compression (<xref target="RFC7540"/> Section 10.6)
and padding (<xref target="RFC7540"/> Section 10.7) to mitigate the ability for an observer
to discriminate different forms of traffic. Additional application-layer padding
may help.</t>

<t>TODO: Proxy authentication might be used to establish the authority to create a
tunnel.</t>

<t>There are significant risks in establishing a tunnel to arbitrary servers.
Proxies that support HiNT requests SHOULD restrict a HiNT session to a limited
set of known ports or a configurable white list of safe request targets.</t>

<t>This section will address more security considerations once a single solution is
chosen.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<section anchor="UDPASSOCIATE-reg" title="UDPASSOCIATE Method Registration">

<t>This section registers the “UDPASSOCIATE” method in “HTTP Method Registry”
(<xref target="RFC7230"/>, Section 8.1).</t>

<t>Method Name: UDPASSOCIATE</t>

<t>Safe: No</t>

<t>Idempotent: No</t>

<t>Cacheable: No</t>

<t>Specification document(s): <xref target="UDPASSOCIATE-method"/> of this document</t>

</section>
<section anchor="IPASSOCIATE-reg" title="IPASSOCIATE Method Registration">

<t>This section registers the “IPASSOCIATE” method in “HTTP Method Registry”
(<xref target="RFC7230"/>, Section 8.1).</t>

<t>Method Name: IPASSOCIATE</t>

<t>Safe: No</t>

<t>Idempotent: No</t>

<t>Cacheable: No</t>

<t>Specification document(s): <xref target="ipassociate-method"/> of this document</t>

</section>
<section anchor="the-hint-http2-frame-type" title="The HINT HTTP/2 Frame Type">

<t>This section registers the “HINT” frame type in the “HTTP/2 Frame Type” registry (<xref target="RFC7540"/>, Section 11.2).</t>

<t>Frame Type: HINT</t>

<t>Code: 0XTBD</t>

<t>Specification: <xref target="hint-h2"/> of this document</t>

</section>
<section anchor="the-hint-httpquic-frame-type" title="The HINT HTTP/QUIC Frame Type">

<t>This section registers the “HINT” frame type in the “HTTP/QUIC Frame Type” registry (<xref target="QUIC-HTTP"/>, Section 9.3).</t>

<t>Frame Type: HINT</t>

<t>Code: 0XTBD</t>

<t>Specification: <xref target="hint-hq"/> of this document</t>

</section>
<section anchor="the-hip-http2-frame-type" title="The HIP HTTP/2 Frame Type">

<t>This section registers the “HIP” frame type in the “HTTP/2 Frame Type” registry (<xref target="RFC7540"/>, Section 11.2).</t>

<t>Frame Type: HIP</t>

<t>Code: 0XTBD</t>

<t>Specification: <xref target="hip-h2"/> of this document</t>

</section>
<section anchor="the-ohip-http2-frame-type" title="The OHIP HTTP/2 Frame Type">

<t>This section registers the “OHIP” frame type in the “HTTP/2 Frame Type” registry (<xref target="RFC7540"/>, Section 11.2).</t>

<t>Frame Type: OHIP</t>

<t>Code: 0XTBD</t>

<t>Specification: <xref target="ohip-h2"/> of this document</t>

</section>
<section anchor="the-ihip-http2-frame-type" title="The IHIP HTTP/2 Frame Type">

<t>This section registers the “IHIP” frame type in the “HTTP/2 Frame Type” registry (<xref target="RFC7540"/>, Section 11.2).</t>

<t>Frame Type: IHIP</t>

<t>Code: 0XTBD</t>

<t>Specification: <xref target="ihip-h2"/> of this document</t>

</section>
<section anchor="the-mhip-http2-frame-type" title="The MHIP HTTP/2 Frame Type">

<t>This section registers the “MHIP” frame type in the “HTTP/2 Frame Type” registry (<xref target="RFC7540"/>, Section 11.2).</t>

<t>Frame Type: MHIP</t>

<t>Code: 0XTBD</t>

<t>Specification: <xref target="mhip-h2"/> of this document</t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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="QUIC-HTTP" >
  <front>
    <title>Hypertext Transfer Protocol (HTTP) over QUIC</title>
    <author initials="M." surname="Bishop" fullname="Mike Bishop" role="editor">
      <organization>Akamai Technologies</organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-13"/>
</reference>
<reference anchor="HELIUM" >
  <front>
    <title>Hybrid Encapsulation Layer for IP and UDP Messages (HELIUM)</title>
    <author initials="B." surname="Schwartz" fullname="Ben Schwartz">
      <organization>Google</organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-schwartz-httpbis-helium-00"/>
</reference>




<reference  anchor="RFC7231" target='https://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>



<reference  anchor="RFC7540" target='https://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<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 perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>



<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<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="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>




    </references>

    <references title='Informative References'>

<reference anchor="QUIC-TRANSPORT" >
  <front>
    <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
    <author initials="J." surname="Iyengar" fullname="Jana Iyengar" role="editor">
      <organization>Fastly</organization>
    </author>
    <author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
      <organization>Mozilla</organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-13"/>
</reference>
<reference anchor="DOH" >
  <front>
    <title>DNS Queries over HTTPS</title>
    <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
      <organization>ICANN</organization>
    </author>
    <author initials="P." surname="McManus" fullname="Patrick McManus">
      <organization>Mozilla</organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-doh-dns-over-https-10"/>
</reference>
<reference anchor="H2-WEBSOCKETS" >
  <front>
    <title>Bootstrapping WebSockets with HTTP/2</title>
    <author initials="P." surname="McManus" fullname="Patrick McManus" role="editor">
      <organization>Mozilla</organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-h2-websockets-02"/>
</reference>
<reference anchor="DPLPMTUD" >
  <front>
    <title>Packetization Layer Path MTU Discovery for Datagram Transports</title>
    <author initials="I." surname="Ruengeler" fullname="Irene Ruengeler">
      <organization>Muenster University of Applied Sciences</organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-datagram-plpmtud-01"/>
</reference>




<reference  anchor="RFC1928" target='https://www.rfc-editor.org/info/rfc1928'>
<front>
<title>SOCKS Protocol Version 5</title>
<author initials='M.' surname='Leech' fullname='M. Leech'><organization /></author>
<author initials='M.' surname='Ganis' fullname='M. Ganis'><organization /></author>
<author initials='Y.' surname='Lee' fullname='Y. Lee'><organization /></author>
<author initials='R.' surname='Kuris' fullname='R. Kuris'><organization /></author>
<author initials='D.' surname='Koblas' fullname='D. Koblas'><organization /></author>
<author initials='L.' surname='Jones' fullname='L. Jones'><organization /></author>
<date year='1996' month='March' />
<abstract><t>This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='1928'/>
<seriesInfo name='DOI' value='10.17487/RFC1928'/>
</reference>



<reference  anchor="RFC5766" target='https://www.rfc-editor.org/info/rfc5766'>
<front>
<title>Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)</title>
<author initials='R.' surname='Mahy' fullname='R. Mahy'><organization /></author>
<author initials='P.' surname='Matthews' fullname='P. Matthews'><organization /></author>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<date year='2010' month='April' />
<abstract><t>If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers).  In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay.  This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay.  TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5766'/>
<seriesInfo name='DOI' value='10.17487/RFC5766'/>
</reference>



<reference  anchor="RFC5246" target='https://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2008' month='August' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>



<reference  anchor="RFC1191" target='https://www.rfc-editor.org/info/rfc1191'>
<front>
<title>Path MTU discovery</title>
<author initials='J.C.' surname='Mogul' fullname='J.C. Mogul'><organization /></author>
<author initials='S.E.' surname='Deering' fullname='S.E. Deering'><organization /></author>
<date year='1990' month='November' />
<abstract><t>This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path.  It specifies a small change to the way routers generate one type of ICMP message.  For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='1191'/>
<seriesInfo name='DOI' value='10.17487/RFC1191'/>
</reference>



<reference  anchor="RFC8201" target='https://www.rfc-editor.org/info/rfc8201'>
<front>
<title>Path MTU Discovery for IP version 6</title>
<author initials='J.' surname='McCann' fullname='J. McCann'><organization /></author>
<author initials='S.' surname='Deering' fullname='S. Deering'><organization /></author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></author>
<author initials='R.' surname='Hinden' fullname='R. Hinden' role='editor'><organization /></author>
<date year='2017' month='July' />
<abstract><t>This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4.  It obsoletes RFC 1981.</t></abstract>
</front>
<seriesInfo name='STD' value='87'/>
<seriesInfo name='RFC' value='8201'/>
<seriesInfo name='DOI' value='10.17487/RFC8201'/>
</reference>



<reference  anchor="RFC2293" target='https://www.rfc-editor.org/info/rfc2293'>
<front>
<title>Representing Tables and Subtrees in the X.500 Directory</title>
<author initials='S.' surname='Kille' fullname='S. Kille'><organization /></author>
<date year='1998' month='March' />
<abstract><t>This document defines techniques for representing two types of information mapping in the OSI Directory: Mapping from a key to a value (or set of values), as might be done in a table lookup, and mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry.  This is achieved by use of a directory subtree.  [STANDARDS-TRCK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2293'/>
<seriesInfo name='DOI' value='10.17487/RFC2293'/>
</reference>



<reference  anchor="RFC4821" target='https://www.rfc-editor.org/info/rfc4821'>
<front>
<title>Packetization Layer Path MTU Discovery</title>
<author initials='M.' surname='Mathis' fullname='M. Mathis'><organization /></author>
<author initials='J.' surname='Heffner' fullname='J. Heffner'><organization /></author>
<date year='2007' month='March' />
<abstract><t>This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets.  This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4821'/>
<seriesInfo name='DOI' value='10.17487/RFC4821'/>
</reference>




    </references>


<section anchor="acknowledgments" title="Acknowledgments">
<t>The first draft of this document was written with support from BBC Research &amp; Development while Lucas was 
employed there.</t>

<t>Many aspects of this document were inspired by the existing outputs of the HTTP
Working Group and the wider IETF community. Some aspects were inspired by Mark
Nottingham’s previous work on HTTP/2 VPN.</t>

<t>The author would like to thank Richard Bradbury, Katharine Daly, Piers O’Hanlon,
and Ben Schwartz for design input and review of this document.</t>

</section>
<section anchor="hint-req-options" title="HiNT Request Options">

<t>The following list presents options for a HiNT request in no particular order:</t>

<t><list style="numbers">
  <t>Enhance the CONNECT method (i.e. request/response headers) that permits negotiation of the proxy-to-destination transport protocol.
  <list style="symbols">
      <t>Pros:
      <list style="symbols">
          <t>Already widely supported for HTTP proxying use case.</t>
          <t>Bootstrapping WebSockets for HTTP/2 <xref target="H2-WEBSOCKETS"/> has made some headway here.</t>
        </list></t>
      <t>Cons:
      <list style="symbols">
          <t>Deployability may be unrealistic. New types of tunnelling behaviour may not meet expectations of extant endpoints.</t>
          <t>CONNECT method extension may not be popular. Need to consider if this is suited for all HTTP or specific version.</t>
        </list></t>
    </list></t>
  <t>Define a new method (e.g. UDPASSOCIATE <xref target="UDPASSOCIATE-method"/>) that is restricted to use UDP for the proxy-to-destination transport protocol.
  <list style="symbols">
      <t>Pros:
      <list style="symbols">
          <t>Clear demarcation between the conventional TCP case.</t>
          <t>Well suited for HTTP/QUIC use case.</t>
        </list></t>
      <t>Cons:
      <list style="symbols">
          <t>Limited applicability (because it is UDP-only?).</t>
        </list></t>
    </list></t>
  <t>Define a new method (e.g. IPASSOCIATE) that permits negotiation of the proxy-to-destination transport protocol.
  <list style="symbols">
      <t>Pros:
      <list style="symbols">
          <t>Clear demarcation between the conventional TCP case.</t>
          <t>Well suited for HTTP/QUIC use case.</t>
        </list></t>
      <t>Cons:
      <list style="symbols">
          <t>Too complicated for most needs (?).</t>
        </list></t>
    </list></t>
  <t>Define a substrate that is already supported by HTTP proxying i.e. WebSocket.
  <list style="symbols">
      <t>Pros:
      <list style="symbols">
          <t>Capable of functioning irrespective of HTTP version.</t>
        </list></t>
      <t>Cons:
      <list style="symbols">
          <t>Multiple layers requires implementation complexity and adds data transfer overhead.</t>
        </list></t>
    </list></t>
  <t>Define HTTP/2 and HTTP/QUIC means of HiNT request, e.g. a new frame or setting that is used to reserve a stream (or streams) for special processing of HiNT messages.
  <list style="symbols">
      <t>Pros:
      <list style="symbols">
          <t>Avoids coining a new method.</t>
        </list></t>
      <t>Cons:
      <list style="symbols">
          <t>Excludes HTTP/1.1.</t>
        </list></t>
    </list></t>
</list></t>

</section>
<section anchor="hint-messaging-options" title="HiNT Message Transfer Options">

<t>The following list presents options for framing of messages within a HiNT
session in no particular order:</t>

<t><list style="numbers">
  <t>Where CONNECT is used by an HTTP/1.1 client, each TCP/IP packet on the client-to-proxy hop maps directly to a packet (TCP/IP or UDP/IP) on the proxy-to-destination hop.
  <list style="symbols">
      <t>Pros:
      <list style="symbols">
          <t>“Simple” option that requires no new TCP framing definition.</t>
        </list></t>
      <t>Cons:
      <list style="symbols">
          <t>Breaks the layering model</t>
          <t>In practice, the endpoints are not likely to be able to do this.</t>
        </list></t>
    </list></t>
  <t>Where CONNECT is used by an HTTP/2 or HTTP/QUIC client, each DATA frame on the client-to-proxy hop maps directly to a packet (TCP/IP or UDP/IP) on the proxy-to-destination hop.
  <list style="symbols">
      <t>Pros:
      <list style="symbols">
          <t>Simple option that requires no additional framing.</t>
          <t>Client and proxy already handle DATA frames.</t>
        </list></t>
      <t>Cons:
      <list style="symbols">
          <t>DATA frames are delivered on streams, which are treated as an ordered byte stream. It may not be possible to treat them individually.</t>
        </list></t>
    </list></t>
  <t>Define framing format that uses a WebSocket substrate. For example, the HELIUM Inner Protocol <xref target="HELIUM"/>.
  <list style="symbols">
      <t>Pros:
      <list style="symbols">
          <t>Would be supported in HTTP/1.1, HTTP/2 and HTTP/QUIC (subject to further work).</t>
        </list></t>
      <t>Cons:
      <list style="symbols">
          <t>Framing overhead which could be optimised away in HTTP/2 and HTTP/QUIC.</t>
          <t>Requires WebSocket support in endpoints.</t>
          <t>Breaks the layering model(?).</t>
        </list></t>
    </list></t>
  <t>Define a new simple HTTP/2 and HTTP/QUIC extension frame for carriage of HiNT messages. (This would likely be subject to stream-level flow control). The frame payload would be encapsulated by the proxy. This approach is reliant on a fixed destination tunnel <xref target="message-destination-agility"/>.
  <list style="symbols">
      <t>Pros:
      <list style="symbols">
          <t>Clear separation between stream-based and message-based tunnels.</t>
          <t>Similar to how endpoints already handle CONNECT today.</t>
        </list></t>
      <t>Cons:
      <list style="symbols">
          <t>New frame may change the semantic of HTTP/2 and HTTP/QUIC. Therefore, it may need to be negotiated by a new SETTINGS parameter.</t>
          <t>Excludes HTTP/1.1</t>
          <t>Dependence on fixed destination tunnel may not support all desired interaction modes.</t>
        </list></t>
    </list></t>
  <t>Define a new HTTP/2 and HTTP/QUIC extension frame(s) for carriage of HiNT messages.
(This would likely be subject to stream-level flow control). This could express HELIUM Inner Protocol <xref target="HELIUM"/> messages directly and, by virtue, would support per-message destination.
  <list style="symbols">
      <t>Pros:
      <list style="symbols">
          <t>Clear separation between stream-based and message-based tunnels.</t>
          <t>Reduced overhead compared for HTTP/2 and HTTP/QUIC compared to carriage over WebSocket substrate.</t>
        </list></t>
      <t>Cons:
      <list style="symbols">
          <t>New frame may change the semantic of HTTP/2 and HTTP/QUIC. Therefore, it may need to be negotiated by a new SETTINGS parameter.</t>
          <t>Some divergence from HTTP/1.1.</t>
          <t>Differs from blind forwarding which is implemented in CONNECT proxies today.</t>
        </list></t>
    </list></t>
</list></t>

</section>
<section anchor="changelog" title="Changelog">

<t><list style='empty'>
  <t><spanx style="strong">RFC Editor’s Note:</spanx> Please remove this section prior to publication of a
final version of this document.</t>
</list></t>

<section anchor="since-draft-pardue-httpbis-http-network-tunnelling-00" title="Since draft-pardue-httpbis-http-network-tunnelling-00">
<t><list style="symbols">
  <t>Author’s address.</t>
</list></t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIAENlyFsAA+19e3fbRrLn//gUvfI5O2RCMJbsOI5mZ3xlSY41sR5XUiY7
u2fPHJBokliBAIMGJDGy97NvvbrRAEGJSuzJJNeaM7FEAv2orq761aOrwzAM
yqRM9a56e3l5FiZZUiZRqWN1osubvLhSl1WW6TRNsqnqvU1OLvtBNBoV+voR
L8T5OIvm0EVcRJMyXERFXOlwVpaLUWLo3zDjl8PSvRw+3Q7G0PA0L5a7Kskm
eRAki2JXlUVlyp2nT799uhNEhY521V5RBvj2tMirxa6ShoMrvYRP4111lJW6
gB7CA+w/CEwZZfE/ozTPYExLbYJFsqv+d5mPB8rkRVnoiYHflnP85f8EQVSV
s7zYDVQYKPhJMrOr3g3VGU2DPuLZvavGkfE/1vMoSXdVip/zpIc7z4ff/McU
Px+O83kQZHkxj8rkWkPz6vzN/s729rf463/+cLQfIoF3qSVZoq23y4UuSn1b
qssiysxEF+qsyGHkeQrEhsf7Kr+GD/H1LXozBhLuqruDvcvDD/SB0UWiDdKT
m1Yt8thVSnQ5CX+qkjEv0PYzetrRgn5C+VeIcjxUrxMzyxfuYybMcXKl29/k
xRQW7ioCUqhLPZ5leZpPYWDugSLHGes4KfMigE/fHr47+uG4TY5RkcTqMBtH
C1OlQMg8U++iJVBgkhfq6EzBQqsfDs7UsTYmmmoDVKJ2+r+SOmY8u4mK8uea
i3WaVPPw6dOHyfR6qC7k9RahXuts9Sui1Hd5Pk017AAYmeOYwDLK5fneycXZ
6fllkzz4HRAZCRC+jgzs0eMqLZNFqm/hdyTNhR5XhWZmWgDrfzSeKW2LGzHO
34bqaKmzaVS0CPK3KItWviKCvIlMmS67uWUdc17O8rnJszZ3ArWTbOVL6uU4
/zlJ02gtUx6cvm2S/ODkQv1nReTinYib8uJjkDXOZ2GcmRBbJa4z4fYGzHY2
VG/zyWQetad9FlXpylc06aP9vZOTta0dj4+jrDIrrZVFMr5a+bZBRdzFO+GP
h68vTve/P7y8aJLudZ6XBvhmsUDV8aMeXeTjK10adZOUM6LjVzsfg5Bux+6E
N3pkuJMQlMkmtPwVs1/LQ2fvzo4vfzhoUuMswnElP/syDbqZKXhUHSRmjHyw
JDF3EJXRtIjm9TY2H4NOpbm+mYaxNB4u0sW8rGJUyw8S6rsh7M+kmFWFKVuk
+i6PCxA+q18TrX7IQLAVJimXKp+ovZEuYq1r9uzo6nKo/gZ6vL0il/m89fmm
7XcKjgok5orcSMazSKftL3nNK50ZoGy7w8UiTWD2F+NEZ2NvcJ0dHw3VObQz
1aluy8WjQme649tHdR6EYaiiEe65MaAikICatpnaPz05Ody/VHMNawyKIk3z
GwP6gr8dQytZqcpcWew3UNdJpCK1KPLb5UABq1/un4Uj0jgM6PDpSAHngRJT
sTYgcJmx8yKZJhmK5sRAf/Nc6dtFmhcoPhf4hEEWD/BT0FcoGDZFndgl4keG
AjFRQhMWgIYCwgYGNn9C4zBDpsY8iWNUs09wYxR5XI3x2yDYAyEUawX7a6qR
lgJXVQ1XATmmFQ84SgGVxksYc2JK1dPDKSh8kHgXwd3dK8B429/uvPzwYaAu
fzg/UfzR19+8ePHhg9LleNgfsMC7jookr6A1XLZxNEpSWEdoKFc3s2Uwho5g
RIUaQ18l9h9leTmDD4DpX4Feh+lGaWN8Cz1OJtASDxIorItrrW7g6+Aqy28y
XDRYDyIRCRFVzqJSAcRWOjJLpOcoBWk5VIfXgFOSCT2lKsRVCuD2HFZNRdMk
BX5YpBGoVAKqAHPnVeb6JWaCN0vgoQRGGJUlSrrCYPvQTwJKHZR+uoTFAsac
wIgJqYyjCj5JUFwB6kUGhiUjrgHropojR95o5cjiMc8jDBuDTCrrOKT9gJ0C
escJwnfC+iM9S2BIEbYOWC1mxlejqlS8BvAW0COCj7Qy1QLppOOh+sFYBlbc
VUWbr9Q0TH51IXAehy77DuiggWUNSCqlU6Nv4Dmtet1QAxgKQMmHD31glVky
IdbAzSebF4cyUPPoCq0eXD5aUnwoBYSs9GSixwguETXcIBMNgAuA8TUuVXwd
ZSWuNqwpdDopQMgaRJDwfkDN9y7fXViW3nn+ArkcQSh81MSpMD4cFUz2GvcV
LNsE/iWOAC4fBLjO0wIFF6496hr8cozfAfuD4OUpKOYUXBt4zGcONYN10QUL
liBKDTBXFo1gkjxi3eRLlk8FyB9YDF5N/BBmbhWk6gFDwzhhvUBpweO0o3nH
DlFAIAtB28ZgczCimuFGS2CqucjWOdg6UZaYuci8cV6lMfJJxN8X+qcK5GMA
DEEvjUBSop4HFUxsAtifLb2vdmjS9CvROM/SJQ7l/7kf1OY3uDb7zLf3/rwR
Xj6j2fs/FygoiuDL+9/3f9Y9+mXwHv4TbvADLbxf08h7bOQ9Sav9HLYwieju
Jx9sZIOfTRuxSlPfRnOwsIagijds5Mu/bPrz18dMZ+fpU3X6ffd0VtfgS2rk
f2w8lC+71uD94wm7+qjXyEasso55bCMwTBBKF7IzNx7J+1Yjv2g6axv57vBS
fTXJ88c0sjmfrOefjuncxyfrprM5n6zln49J2I/CJw//PMSxj5BsazbgR5Gx
tQII7nbVk0kyDWfb4Zj3KRuYf9kivbE93LZyS+A6bhUGjVsfEF9pJ9dEMVmj
oAdwBN1HtPGfD58NXyAuvrv7b6D6v9l5to0antTbfI6KCSFRjGoTmgA1nJgZ
4hpGYNKt1Z2EfiNrGijGBZOEFWkUyDjCMiqmuhyCglZ2LoxV8HHU76TzwjIP
WZ+z7VILK4AF8Nc1ulMJOuRuQKp3d9ckGsEp29FOc+4vh89g5oHM/OvnT3Hm
Tc3ceP7ZcHu4w7RyTl54ZeDsowAwoQZrfoq+j1jHCFHQkOoY4E4IHYWzn/xx
/lcFAGK57NVG3Ua6+4HBfLlRI6xicva7s1MVsSuMjkyg+yWdJ5PXDubL9cJn
pZH3lk3F9GEeVF4LGzVywVy48syjGln3zOMa6YZWGzTyEZFVo5+WyvSf+PTI
alPC3ousfqHebCOr9fjqnpGsgKJHD+bLtY045q/Zd91I3t/TyMaEvbeRNsjb
oJGPi/Hqru7h2HXT+agY7yMS9qPwScfPIzn2o+yd7p/H7OKNVMZDjdz3s1kj
m6rRext5+OehRv6NEXgbqzWAeNuXcx8o3xMHFXlnxbtonI4EbJ3F6dK6Jo1a
UCDJDADjqlEO0DoGdExaxQyCijySqGzQA0lft3EzDox+w48Ek8/yhan9o4Bl
pYUA8Xcaleh1h2fYaZom84TckJNoXObFrjg6xa9tsZsLGNceUMzuUFXmOVCb
/l7n0U5hvkDVsS4yo5LS6HTCVsQk4ZhBFFivLlNtoQsYEw4OQ+NM5Jr4LS+v
9Zwy0fPAs2Ay762G+YJ0sKGNH+GDvMKlGqPRM44W4swnc6XQaIYAfcCoIRc7
egJjvdAZ2D1jckNyQ/St0MKLr7DbFVcP7Ic5kCJAr7IucVVwFDKZRb6Q/Ij+
kO06R0ZcpIIiG2gH0UvsekbK5ehF3Q2CL9SBNsk0UxFSHUlX1N52fvHuLqZH
Qnnkw4chvsdudusOpdUW3zw2YSowLZa2ASB4GYKBF8oj0gQnb5CjfpGD6TcD
njSz6EpjhDNi1pnoov9Qy3PbTqv9N3lVwLoAr2DE1I/kFOgN1gbIZBtyj4Xu
MfRy82KIzzga5dfaDgZ62O9oehbBI/jwoipgUrSLTJnMaZVgpnFixpU4k7lV
cViXyyDJeF2QI+IiwYZyMt1ciM0FMQKMZZ3kJVE+ShFTXqOBDENgNrjSS4VZ
UkZtHf9wcbk14H/VySn9fn4IzH1+eIC/X7zde/fO/WKfuHh7+sM7+D6Q3+o3
90+Pjw9PDvhl+FS1Pjre+wf8g/Jl6/Ts8uj0ZO/dFk8WbHPHnrgGvC/Ivw/L
gWsRoWlsxkUy4oV5DQJo+zmsj+RQffggvoiX2988//AhuJnpjPsibwT/CVRd
ohzSUYFtwObB3ZmUUQriEnowMwyL4R4FOj55AltgQmxMxPP+oL0GIsWLmKG7
w87FbTXaRxQnECfGLqwYM6XmV+Vzw44MK2iIDtBH1Io7sk+AGvRiqkOvF5Co
mdEr3VC8hce7QTd1g9LISnsSIW7sRlix8gZDViyBBsqpk68wHuvFgGMKINmZ
iBytO+X3d50gBsm4yBOMQJMChD+Nfdf6qGq6UKdDtYcBoELDsApxpdThvLon
enh9R8V1MgYh7fcEWvAIV62sUPVETbLze6iC0IPDxAZFgMGz1RiyBHIx7tg9
WJ6JG6tHwF1qWcbHneIHHvFQxpfFUmKB0BFoIg7ZP0ykTs6SRUJGsFoYcxbK
CENv61ioGXjddRsYo3cEWOa0k7ywfIuHaP/6nNODJUJYAv/0YfyOlBqkMQeU
KQSPu53BDTGLaEa/H9JmaY6btpfMEZgAOFsiLsF0BP4LFecTqwb3RfXx63ui
FO+etFQgiQ1ipr9jIgY8eveE0imv+U/xsfJbKG8wGOiC2MmEZJL/vgHC6rgV
Vz5IJhL2NKgbpG1lllkZ3VLgcoE5bmPQLYUfUOS0gVixw9H0FYasXUxWF2WU
ZIGMzQV/zbCeVMNliH5GfzZ2Gsz4W41YOTy7xfJ8ruMEx9Pwke4MnwW+N5l8
qvM81qkN/yaGMjJgjQArpTnoeRiWl55iaC6ITqM6a4Nd18QYsWRQsQomFS+c
y5s/YGnV+/Fs72CgDt7un2HUPKtAhZLwnFaFoCklvlUPz4YppmsFrcyHAtOB
MwC00Q2yG+p7RISN5oaqd5QJQCatPFAO7ATE/Q0RSxSMGMzXwNODq9hRkl0n
JhmlpEbh+8BH3jTSYT8IjurFwIQCpB48Owcsfa0FrTSRsB03MuCe26AA/ecL
BDCBlx9UO679MPssx2gC9AObUlULnBVxLqkC6WMW2eSggGwJWNBJlToOm0U4
e13AJpc0EdlCowY4pf0PM0HuImtg4aQcgzRmackRxi3uJMzelKB6MxQiIZBx
BU1kKCdASAALocyJVDs+QTYLDX5rktzqOPAFGPL0luKEDtzqc5umTMRILaA0
FPzHt8nSWmAeoCwmfdWQiUCZnBQq6GTgkVRjQ1YcAxFQzRtnBayVPHU6D7J2
kaPOSIZ6iBMB+0nAtO6aDrVlTZVM37jePX7l7Wxs5hewQRTHgdcw5bTMdBRz
Xg2s0zwx0g1n1gBsJr7m1etIjrx7QimLH+6bKalLq+l5IDcg6L4aaVrJxKrC
6zyJ1dFZAHJzihSU7Xohs0QDDISoySnJxO4DWPWSVwsHFruB9Sjhsx/U3Jpk
47SKycYtojgRtE6PObHVYwsS5SkaDD7+tZll299uA/LFjcAfvNx5Sh8UjJ7B
poxpqMhF+FSBEhQoerR/zB/gL9cvAsuHQ2lnZ+fbZ9AOCI0ozaeGU1NEjwJv
wJTnIoBoyHg4wktfDSR9lWbTk3TXvjT9/OUODpFyeGAjwSCNs9N9hAD7Ywp8
Xc7mAWNYDBEuNKVPCeKpfQgs1urMWOkTk6PkV+kS5fyC9P6kKkjsrh+C7ALN
WWU2P895EALXvajI1+iKsY4Y3JDXQM8kC6GbMM3zBarNMQIp+OruCTluwmsT
whP47YfAV3/+OKwwBU7YitjhgwtJm4LhEuw2L9RpghtxQWDqEdnRdn23ZP+5
HS5bC9kUOAOEGiY2Y0IYzRn2ctDewzjZI7FQI7ZjrZwUTmtkgmK+3aDGp3az
G/K4YHxXNEkPXvzq6EzcV/DPMs2jmGLKsbbHPdAQLC0Tiq+q8L+FnRGRBGq2
RlhbjkDYnl0r7NjiBoG/GJdmOXKKXS3hfH8GQIW7Oz5bAqslXCV8ixlkdGSj
xjAo8OtxxzmeTKEcNoPKBNaNouUEepLJstGTBWAgGsN8EgJBNbCaZPEBvMxT
Fniinqzgq9dlZT1sMij0nbBvDkaYgxgDqgVeyLxnA+19RMaReCEoMI++DY64
dCan9YkXUF+13YuzfEEER6RGXpvR/yXnaK5m/gR7b/N3fZesOETkGUg40CNn
oa0ccXaBl2QgA6snNCCdC4RJSiNRd9MeBS6Sy5G06pidLEI1i5/JFITuq4zS
aQN5mRPlyQITJABMNdbJNSsW8vfNkiko1zlwZ2nF6Up2a4z+BjQ/u/zFlB5o
MC9gbqbhLYAbyrC03gjicZDDdWCYXZYyZTRYwYgrASighflGQul0gqrBLABH
YR1qelhFzEMGFh/XREiTK2gucOaojzqZxU3dEBAiHwPDDgCuRLF8UicJJ8ZU
yPc9GjY033D9MoP7eroxSNlW3lOB1Rs5wnEQnQkpbZjzgACc/D3SQLtCsAml
j0NnEWXIWsGA9i6i5zdViTml19ZIA56ioeK7ORpnbIHBVLh1SeY+QtZTN9o6
jO7ZJAN8kpNFZzpdKPSpT3EO/lzvxXSkIUW1OUWB3K0zYK2S7eJaRgfCj/Ap
dDFwDOfMy7u7hiX7gczj2tV54Vydd0+6nKZBcAEK8wZIuJnrlT2euFkzFN8k
h91OQlsLj7UxVYkDgWa42Mh+N4xps0WFv8OWJwqCUbVgIex5S0GwWu11zCh/
r6rxXhAcZjP2cYD84y9Y8zlZ23QKrhoNiUtXuh0EXXuZUQtsEVLWsKntWkW+
F6TrMEVAc2PTh13fZOGSDwSp5UlpAWtZjqjbok1xCViLNnCRH1qMBho2xGFz
HWWyV+noLc0Ze8HdluKJC+cTF/FaZ2+T4AAWIygB+5hpD1tw7+LidP9o7/JQ
zn0dgeZ7w+LNJvO3SSbOWK1Y1zOlB83GQDT6f4f8ECVeiedVVGBkFZmNZ42j
okgie+7jhgQO9hbz2GrR68UYdCjEpMwxXNDgFyyoWllQjteVqC4D7lgAnKyO
6cz9wUUEo34gsTxNpoZxfBj0RpqPVzgVCoyBi8skt66iBgjpCwohxMOM5h3Z
o3hU23UF0qmGHEBMp2NkWtJWr8ZR/XbDm9HSI2HP9NdQMdh/fXoOCGGcx7SU
ZzW+8mfiwegub6TbH3VYkBMV3a4jOsoqsbdBDGSyiBuEcuoDOTKwBrQ3+4dI
XidCnjDefCNL5+0cnzMevyDrpVPw2AVo0JwtkEWRyGmYwDmyhCiCS5zsXDkg
unY5hdwj1rF+Oy0xMljzGm00NhbsvEmsWUkROCAoZoQvhI6aMihZWLezrkUQ
+2IKRsBou9kdZ+OZThHuqhSgYukeIKmzCGc7Du5VhiMNTfbmgyNW+vLM+CQW
ZwOA/JBIPj7PuJcbq0EJRzUd2evTS38G2zlN22PCz1ZGpcQOmoD9BYDJBNYX
33ZJ1q37KoPdkA1PNBcPQA2iLvwTbszyKLHOJVQjgNrYfNGqTAlQMy6yjawc
k6u1nt2QhNBWIcuQPE8Ss4V5Mapms08XlG6AWwMwzwisULIEwFJFMsTB+ug3
bHjEdA1dJsjE3/G3gLK69Ftw5OENmmqjJQElXthR0DowRbKg/eylOwR1tkTt
zy1nXSc6KRyFoKuRvY2Ua/pHkSYDdDeaaozWNXCNpEVEE8wisR4INNEwIyO6
TvKCjyImWRx4zhWRX/a8svUYdCe+AOwvk5SXXvITTMABIKB5g0R0lEtcZxQ7
RrLzWUSPbrmL0Km9Ng1ImkPXiFQl56Ru3oYssVVJXTne+4fEEGNJhlc7t7eq
d+FI1AfJAxsIM9h5t9ogo5h8zTx35akmUESnB6e7XlhLjSIOU7/C1CIR4hhV
ZUd852ApQ8CQde0sXEx4RjGDyfCtNe7ZuM7XlCvfjOv8mbzK9phh4z0yXXDn
wjtEenyGwgZ4Cpr1L7mYq/mIbQNvQT2eHMBYwf6yh/FAVeWpPeDpN5CwFiU1
mJEpzDlcqkmF2U9Dm4kMZsfu10+/ebntNiLWOMgxst/1lLRHVlq9wyTWgW6L
lcMR1iMDw2b25VSnTEIZEgRo0S0vaEvVERp8jmJhmTtkige1R0vfO9kWDoEX
TWetdovR7FFeWdyDvL5c5U0X//ZD37AFOEqdoS1Gvi7EPX57AFEFKxhg+zGH
OJgK6DcDa4HiUyW6FVg6sHMmyq4UOYlsboPgW+rPjcsN60+GXEuoY5gt/xxQ
VE12KIxL2o5Kv/FEDrzaWPsGwo3p48jBtId2CTqsDqxFL2pQ5j+LEJOXaqkx
L02TdrOYxMlsb9NzrNGoKaLEjMeHHIpIg/b/DFW/7ySm4790Ot47FY/ejqSY
O8La5h3b1YE8mo8GIflKnekCTGsjYquOcciYKRpX+z5HYClqFIxJGeA0TYVn
vmlj1KlypH5R3lCYhdbJJjbS4VsnxG0UnzqJsmaMOdYluZ045sMbC30jSF6R
/qRnfJenJyhRQs/rbAASH432SSxK6CewI8bcBsAaVHOKErsogssRDIzqWZ6S
/mk8suNyN8IBD08yNGuTZCAcAJPF6BLlgBHL4fK73lI9AQiWOZucSCY8bJO9
6sHaylLhIYJHTgLkoywAT97pbApDkA0ErJ/Ghr3s68UAzMaXK0NVx4updwpY
auq72Q0egl4dTbNvt2uTdbuq3T1l0DI4IPVKL3aqORuc4N3nzH4D1MXT6GZD
eNb2VtQHyVrmxwbwrCtdK/CD6843XW9NshTr1EBxVkvFDTmNTnOMAJffBHGd
TVJzp090gOJco6eRgecfgBvYTI7gJZ52Gz6jzDck1NYuz2lLLYyu4jxsNEzw
nBTOlk+HLfeyGc/0XG9x0uAuRlY7GzLMWBjImiclxlJsAw6rdA8AU3FJcDqk
4UBG6aQl/tpDu+A6SqUSSgMGhQKDuiCNFx1zq0qpLz4mcuRDwNTn8gJdfMEB
SowdoW5AdY8d83CMrqN3KMkpyJ6KCO51LpbixXrBHXYlmTcGsQawCDVWVSRI
iXKDNRiq04zS2DhYwo5dRG5EJh0VIDkKQrH9QVCrEZcHeLh3cHh+IQUTZD0Z
ypI24noZDJ89Y9f63Fk01lKkUy44X6G3wJ7X0POiAwJAMEHj5GyYtDVCG36k
nLyFxoIbiIsoiRsazkrrYPRdDwFRR3oc54W1FjCxCQW+xHusQPF1+jBY56gc
qNqZICkEtR1vy/I0qvI0Up4ozcTPKsPOraRgGYzVa+biT1HlcqFNrX5GOvBH
3YqtSRWd84vLf15cnh/uHVMPlKJy+fqgT0ZXI13Ts7eypexF2BLUXcu28rS9
Loq8kMyYFt2I3Ud1luBaXECLydgClxPDEZi75OU+KzmDgKlxrNbb6Yhe4+Lx
tUHMDpqzo7ZH9Xg4Iabv7yEU7DNMcgbVNVDekQBO1w7qEbRpLkvRGbHdh7es
0WDfsweXR3rC+tzNQ6YJo+GoIO05sJGnmsLIK3MKLD3lxR4lHiUx5rAlcw1w
ql/r3qNV1Xv3pMPPFrQftmlcvLDk60Lr0Ctw5Syge90iWTtM+gvcIm098Qvc
IlXtF1FNvwglPqz1hnQ6Q5RzhqyhGvsQ0zy/oq1IY4D9jhlKuMbrsIwzQLig
F7NoHTXDKZcMTDhaRr5Pm6tXOHccbPg6boWmPTyP20niSo1Y1ZhqEMTsHdGY
31N4p3CoetJkJdC9mWvRZgy6Yqx3T1z8/Xfhbew+EQMbqzk/G0a4e9KpOohH
6mAYR8xsprzzp6+LnoCE9FxslBIR0GbkMmheSJ3iAT4iaSUzD/0TGhJBpmRm
chSuAd0Mdzm7AyQTH7ZJCnuybYEBUmy6h5Mk/F6nmfW66lpJn8a+Km69Yd+G
MXFgGYg6wM4U+gxcypkRyZEU/nq6A3FDdegSFQX7EfLzWMXFBdmRIqYVZvLK
VraWD0yNIIe/bA5IiEOz4U/tcWSIE/te9UVbF7UBRrKzcZ7Aud2apzNIG/Kx
IhfYb6QLe5KIeIADAKzBZXaY71Zi0pUfg22l7kwwvkElu/KUrXWT/EyL6r8k
/okSM6ypDIhNmJDCYEQzzuAcin5hN2FHXicOQA5u2bRMzkDFXSWrby0Tp58c
ECGe4OHWKUV4loKXJ/GM3ZwCbo1nBy0FtRHUUXUsLLCI++z89PJ0//TdPw/P
z0/PB7UdS7Fk+xTALpIUrIOJoLK/aJ5WVACYDIL2EzyfHiLAvzy9RQDnspvK
xunDSRpNAdq4w3X2ffy4v4vFUwFQWUTYe3q73ceCpLvqR074LgcgIEr1dNWx
Rs48IWpJZ1ZFy8PrpCQslmR3pM5cGMxX3XaRLnTJ3lhqFwbH1Qo5DqcsnMLj
KOgtwgqN1jrcmoFNFoqy3SKzBPUR97TV+BgaWmO2fT3cRjik1NneAcJLIMTL
TkI86/AwwoaOlXh12AaOxA9kxRefYrKFWr081DpDp7voDBB+9We747Odjs+e
4evb8NUz9Vx9rV6ob9RL9e1jPgu+DH/l/4L3NXFeqd7L/srB8zORpr0v+qtT
GA6HH2MM646f48rRAnV2/lHH0HWenXd3KMacnGVf2eSibrbWSgGrj2bRyuYn
Tw7t8noZmK3B2rMnRtXLEFm74b6xhknKbC17zfYnShkr9uJxWkIW+bik7BLC
bM4XRYBAWJyRqbZ7jHY5u6t46/E0ZHgFDKlAYMLtWv+5b6c7WGTY1viKXG0N
BSozx+Fyu3bBm63SlCmVywuiWx+luo7SCvSkar9s1ZD4237WRW7PyWQMePas
uik4IwglQA7mxdSWo4JvMDfZUhSPaWDoEqVdScqMGrVfo38RWmiroPVC7Tnl
GU/IUdBSSlbv+5x0r/pf38sOFesK6DQBLvdIXDIcQLCym4LALJRzsKS3UESz
7Lb+AHa49kVYD4MjPkq2wu++Fr+hcxx1F4jloBvXRdDsIs0BLNoeNlH30jLR
OWhQoEHmnZrMrEr/uf/u9OLwYLhuz5JVRsnwMKxZvghHy5C8AntZR0AEvTti
j3asGs4jrzD9mY90SBqachcd5JnlcfYze01YqJtwPAy5DFNvOljDBmMQZeKO
v8ncHluFMIRzmijmpxX5VadddwOZLGeY8odVjfeopXt04r9GLf20Ti15q7ZW
M3nPWEM2eoRAD9YLdOUbYFYAW0EZsrYSyI/DCdrDacgOMox4n9sma32HDbYk
RPCQhHDWLFckrIXki1o+MOpfS6+PIRi88wy/QjaQof6QePCPTtwrIdQ7yrrD
9EDPyLEeEXKZM1E4YTIBFVdX8lY9eA9Pu7nTQVZGoOtTyu9b9kEfajWmwwTE
Y+LQYkaUrEM8eaa5pr/LkjNuWc7usbIsP6/LlWQOtUOhFSfNZ2tQUqhUSlFT
rIY7dYsfNfwa9VG6hxwXCRtagbgrklIatva6hEpqS11taqkHG1rq6vdvqa/j
gHtM649oQot56Azpx5vR0sJ9xvTDprQ0solB/dmc/ncwpy9RyMDvOEj4G7g3
ROnkXM81iviDm9OLDmv67AFjuvv737stjSzhxuYPibeOFRw8R097MUSJjEvU
oXHVepcabzOYdNRox5ZzIMVAD2ubfMTn9Iko0NkA41QRusjRO1d/J4Tpy4kb
PnRMigh/CzGkldx+tu/vs+8BdL3BUwVrMRflJdA+OIVnBurorVz3d4y/2FNZ
gL9SDqMA+90SEGPcw6duvEWnVXQ5tmLtN7aXg2asaetgRDugUwMfgLD6oZDN
PFgTqrHopxH4+KQgqK5R/ny483sGQocY2rp1jMA85pK7iG+hFcofsWWr3IHN
Y9nSAJDLYhlIUtIbziuToKKYOBK7J85bKarzR1XiNJQmke7VmZ9WgQZ77bE4
lYMpaYtU22MEkgwRqe+1XCskSi3ExNh5gmz9d5Smu3/oleMfpEFv+0Vj1eR7
ooHFsL1nO/2PuXLQyr384Y/h1b+Aey68QgIEj4AwDntUGZcMGKjtFwRD6Foq
Sr8RJGPRESsSZkMsqUm63Sfkw22KLdHEW5SuIxpdxBO3as1vZVm2DeU4e5Br
mkkDfjJkM+nK1fATNOGcoqct9Yse0dz3eJxu5nCI0KtdlXTWY6vhcQjWNPPZ
av2FVuvx4eXewd7lHpJlp5Ms2112qxWi6hCEKC6Zs16hBcfajMBNt9n6yWxm
CsqT1fzZXm6v0ytPjDdt209tL7uR3KP8P73N/q+KNfyb+g3yLsfBqjRteQ7W
PvB7dx20d8fqOEXr+g6FRoHe+ixpA1bKzfQzGlLWlJhiITw8aCuasaV1I+cR
/69HWCgeFmhmIZTwOh7/yexZOcrhY+cDI2H+uE8oAy0a6ITuocKzaniWzFVM
oywmuid96u7ngi/53MZnR8b9jgxJU++AUokPpY42h1JyarYLSa228hlJfUZS
n5HUb4+k1pu+n5GUHcNviKSSLiS1Kk1bSGrtA5+R1B8ISQkKehgn3YOSBtBU
ZBrHJUp7evUzgtoEQR13IKi5j6CON0RQagvVcBd6Wm3hM3r6XaIn4h3s+nln
1zv3rYitHwO79xD5FjPzfNHwGwEz7Pkf7073qOtxZ9fPu7tmheQEqiPTZ6gH
P+9hjRvP/+GdZsTUBkfwr0CUr/7rQsp5F6RcVTEtSLn2gc+Q8reClLWI+BW0
lW0nikRtMCRWYp8E3/JgVmdDi0z3QVJ+scygnv9QUWoFP2aLd+LT0JKLilId
FmBiRn3tq/paCVlNpO0NxXJ9o4ZL7b3Enm1I0aLvCPnA0G1zdTIWa9nComiq
tk7XKiT6IcYIlPAz693VQ1+fEXs3YscnKyoJ2bgozbQvNUA0AksDRJ/nZXJt
KzQi0bGKPV/9COtxTSU3bhe5ocz4PMhHXEkDzwjkak53gVJ1NxweVfxHhCt1
rHhz4EF/vAOt5Cx3TYX8gYKA7qUOLScT2ctXXS2aMR7Tyuoq8Qi6CqlOjFcd
GFsZFMY1yvMSM/IXresMB15dYVsNWXL67eUsXiV2uoEMWsEB8/zMFWeGwcLT
ZAzSVzcLSo/4okws7uENI4upp2XQrMaQ0LK4O73srYtSpxqLR1YF1ZBKqUJG
ZnvkGgx0GwpfE4dFJmO+pwGr7wcBl98HlrTl921BsZIpYuflCvrW3zcv9DJc
9Se4BsJTmh0ez0gwBbDPuwFrQ0VSLsNm69Gew0qVFk5T2W3iP9Jow8DeVM/V
c4A/iuXCVkq90dEVm+5Sf4Er1fCAI1iapUlABUr6mav0YO8OimK6gjEa4Xri
iFxR5TlllFJFwc5zeNtPhy/6XHHfIpZ1z33TJ5aw9z+QBJYqiRO5lkU2RyAX
3RVINHy2prS7bVEm1yiosnKVnbNSaM10unBlXM64/nkFo0CJJvdz0WkZW1MH
zU1XLIdG6+rFYvoiXcXjitg1SmFjpgwl58CAgSWuDPtfpC1WCF7tO3dIS0TD
MDjjqqKqUTOkcX+nVEGqC+o0ty3XwZDssECuVabrXRRXRKN7l90VfnhryM0M
noVXDD1rokldIoxr+5hhqxI1CQQgMHKIt7uRQI3kTtyGyF3tS36pdjHJKBK9
R3sneytit323ghRKOtfThA4Q0YUezQrShZ5+aI20oMfdlY6NGn3eBRd0p3mr
i+WWO4HaqnH3kj0G8vgJANDdZh3a4AKIuKtOcpAtsZ7ztTD89z7ex4Vk5z+b
ZXqslumZ/q5ac/2DsoLfPkyk6igp1aLU0aMIdfSp6HT08cnUVaG+m0rNY4DW
J4fZ+/dTA9/Z8hNz7dHqlXa25FXMMO1GItvbw52+zVTmkwN8djLYz2P4/en/
vHx90Jrxrq1+RJXuNpiadyD4186u1VRzgp2nL78dPvvlE/zp/gmePX7pzj7t
yp09PK/FA+u2mrP48LxOP/HETjeYWf7w1FZzCB6e2tEnntrRBlNLHp7aqnP/
4akdf+KpHW8wtfk9UwvDUGH1NdTKe2OEDamO6dIow+dmkwJQQQwIrFx5W92A
TXZTYPXajBGpxS90rvz1633QGEZHBVjj/10dIJbNF/ziDO9sfVeNsQH4fwC6
gG5IRtrQ4ZVjNInliuqOjjV7EhZJUVtj7jobQLaLqs5GJkvlx7ygm9a+w0ug
XO1PvnXr6PDyjZKbkPFyLqoAavte6eo4Kq6Ck5xiGLNo/idyVl/TPZt0XU5d
A+rvZycSs5EL9qQgIdUepOtLsit1nqBFEavXRRSPqmI5UN9H8E2B9dwPAMwP
1FmC3HT6p7dRloKVRgj8NVD8Yjy7AcP0Z4LUcqEaXyDGd0xeJ/pmhXQEv/w7
R9SpVEuVOhL+5R5ydNq58ggxOgeKV2a1fbk9+xO8G72pgNpuEGzjMWu+ngzp
37p4jGtoSiNfuerYHJw0ck8LGEpzdPdlepqXUoy0vub1dolVQP2qlnUpPHva
nQNRX6BhQO4l/msvBZgfL+2d3e7ucldczF0LTiYTXiQ6dC+/tsYslZLtuvJo
B51KO+GPh68BDH1/eHkB2xGdpXOYG99Vi9O8IeOl0HaIiJHrIR7QPeLWkpJz
93g7YJSSNTpUJ7DkXLW2cVOeV38T38LTXXOtS7nk0CL3CR4KQ0PGnQerJ9ha
qfoGWtseXXa8wMXGUbBN5d/VbF0XpkosUd2lUvB7nd5v71LakVKJzSvTpMpu
w1BYd22aC8FZy6m+ZQLLBtpA5a/imv0U5BvsvjlIOX7Tv7eQbpPKxGTFC42b
XPOjpjLKic9lDL+aHNbmg3dyFEiMYOEHd0UaexTwIhx0+bwClfHsPlp6AP0T
b7HfhFiXec4VuqVAxIQ80XhBC3CpUT2kz3OPPq5ehWOfSCRDLRLkqopaIpDg
ctt+zeyxnmvKxSKqjFQ6vVp4dTRtBVG3C7pmdFylZYKnxsjx4V2shyWJtbsJ
UtUXTnIoN4bpcmja1oK195cPg68dBTovb+UCzjg6T8wPFPEPsxRDHNzJLrzP
1LMOFinBXFd0wUxfueqR794lGYDFchu3GLfuFe4U3XijKh4esi74mse7KXh4
27xfcLtWiyv1clv6cbUc7eZa0t2ZNvFdrXK9A/YeWJ/OfQqUXbtWIFsKY2lT
d4/WtlSwHXAB1ebN0utrZmMtdFNf4sM3RklatrTBdw99hYeU82y9RMCKOp1L
tXVBTLpl3cJysaUwMMxZbsJ2tKoLL3cv5WtgoCtbIXPJVXLpCmv3xBGWyaEr
PKUiWX3cmU9Fl17JbzxCjJsU3ZI5KS3SRA/SvHWdZYP8lGIi++O3pD2Tfi3l
O65Z9SR3+zpJkYmA5bDkeT1Fswa61A/wmW7/8lWRAvYaPbpi0F5/btZc4k13
6DbABxeWZ2+45sSSOQVnr5O4wsOTvh607MVVmlR9A2DUdX0gn+h2l3mTVcF1
lI6ojtKZraPkBw67luBHGwWpdUl92+72oFv49vyKgeLGR1Oj301qW4PACneh
6th2jes/T5B/I4SbSfdVL/Xan1se8QkjRZGyLqy4dkuu6Frc7Ia5snPmNcyU
ik6wCv5dt03dgPWvE+NZWVIrsaYes469CMIrvihXJTVzGVzISmdj2JxV6sf+
XLm0RC4GxZ1OWDNNIg7MYWT/VjeuGrWxADDKpUC592UIegWR3DrmYfgkBat9
9CTT4hrEdOuENN6qF+8JggSVCt5gDzTw5GFzV1t5V+ZxtOxmthOn+nEv8vUf
nMhnA8gCaVbvkKYgCl7DQPeG01bW7sJ5Cz1t0W7klIvDy8ujk+8u6mr6w/Ua
3TeaKFY6Jum7dkWsKLGsjcYJx3clUBuxEwYZ2fh4ice2Cfv2BOes5+DgV3Iw
VtCnd6U8zINSqsYhTvPQtQ5A8+ukKCu82pQatGQB0yB05UhqKn5ihj3XcTWW
y8JJpLmw6rqi+Y3Aa03wxoXEnnz/t+Zt8kfFqC6nxMbkXauRq2N0ipzKhVgr
d2ywEkg8I0FqB8keX9g4JO91gMP7NOE0nwbBX9UXX5y/2VeHgBDy4k9GneSl
3v0C1htW2PBVXtdymYt1hC4KuQZ1UY1cWgndBfZX2IWIMsTI6fRRPQEhhXMl
z2MIRIkrHc7KcjFKDP0bZsBLoATD2ssRPn0ahGqPfG0wRglXDoP/DxNJBpRB
ugAA

-->

</rfc>

