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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="exp" consensus="true" docName="draft-ietf-tcpm-converters-19" ipr="trust200902">
     number="8803" ipr="trust200902" obsoletes="" updates="" xml:lang="en"
     tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="Convert Protocol">0-RTT TCP Convert Protocol</title>
    <seriesInfo name="RFC" value="8803"/>

    <author fullname="Olivier Bonaventure" initials="O." role="editor" surname="Bonaventure">
      <organization>Tessares</organization>
      <address>
<postal>
<street>Avenue Jean Monnet 1</street>
<city>B-1348 Louvain-la-Neuve</city>
<region></region>
<code></code>
<country>Belgium</country>
</postal>
        <email>Olivier.Bonaventure@tessares.net</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Boucadair">
      <organization>Orange</organization>
      <address>
        <postal>
          <street>Clos Courtel</street>
          <city>Rennes</city>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Sri Gundavelli" initials="S." surname="Gundavelli">
      <organization>Cisco</organization>
      <address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
        <email>sgundave@cisco.com</email>
      </address>
    </author>

    <author fullname="SungHoon Seo" initials="S." surname="Seo">
      <organization>Korea Telecom</organization>
      <address>
<postal>
<street>151 Taebong-ro</street>
<city>Seocho-gu, Seoul, 06763</city>
<region></region>
<code></code>
<country>Republic of Korea</country>
</postal>
        <email>sh.seo@kt.com</email>
      </address>
    </author>

    <author fullname="Benjamin Hesmans" initials="B." surname="Hesmans">
      <organization>Tessares</organization>
      <address>
<postal>
<street>Avenue Jean Monnet 1</street>
<city>B-1348 Louvain-la-Neuve</city>
<region></region>
<code></code>
<country>Belgium</country>
</postal>
        <email>Benjamin.Hesmans@tessares.net</email>
      </address>
    </author>

    <date day="21" month="March" year="2020" /> month="July" year="2020"/>
    <area>Transport</area>
    <workgroup>TCPM Working Group</workgroup>
    <keyword>Hybrid access</keyword>
    <keyword>aggregation</keyword>
    <keyword>transport evolution</keyword>
    <keyword>future internet</keyword>
    <keyword>extension</keyword>
    <keyword>Trafic Steering</keyword>
    <keyword>ATSSS</keyword>
    <keyword>Multipath TCP</keyword>
    <abstract>
      <t>This document specifies an application proxy, called Transport
      Converter, to assist the deployment of TCP extensions such as Multipath
      TCP. A Transport Converter may provide conversion service for one or
      more TCP extensions. The conversion service is provided by means of the
      0-RTT TCP Convert Protocol (Convert).</t>
      <t>This protocol provides 0-RTT (Zero Round-Trip Time) conversion
      service since no extra delay is induced by the protocol compared to
      connections that are not proxied. Also, the Convert Protocol does not
      require any encapsulation (no tunnels, tunnels whatsoever).</t>
      <t>This specification assumes an explicit model, where the Transport
      Converter is explicitly configured on hosts. As a sample applicability
      use case, this document specifies how the Convert Protocol applies for
      Multipath TCP.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <section anchor="pb" title="The Problem"> numbered="true" toc="default">
        <name>The Problem</name>
        <t>Transport protocols like TCP evolve regularly <xref
        target="RFC7414"></xref>.
        target="RFC7414" format="default"/>. TCP has been improved in
        different ways.  Some improvements such as changing the initial window
        size <xref
        target="RFC6928"></xref> target="RFC6928" format="default"/> or modifying the
        congestion control scheme can be applied independently on clients Clients and servers.
        Servers. Other improvements such as Selective Acknowledgments <xref
        target="RFC2018"></xref>
        target="RFC2018" format="default"/> or large windows <xref
        target="RFC7323"></xref>
        target="RFC7323" format="default"/> require a new TCP option or to change
        changing the semantics of some fields in the TCP header. These
        modifications must be deployed on both clients Clients and servers Servers to be
        actually used on the Internet. Experience with the latter class of TCP
        extensions reveals that their deployment can require many
        years. Fukuda reports in <xref
        target="Fukuda2011"></xref> target="Fukuda2011" format="default"/>
        results of a decade of measurements showing the deployment of
        Selective Acknowledgments, Window Scale, and TCP Timestamps. <xref target="ANRW17"></xref>
        target="ANRW17" format="default"/> describes measurements showing that
        TCP Fast Open (TFO) <xref target="RFC7413"></xref> target="RFC7413" format="default"/> is still
        not widely deployed.</t>
        <t>There are some situations where the transport stack used on clients Clients
        (or servers) Servers) can be upgraded at a faster pace than the transport stack
        running on servers Servers (or clients). Clients).

 In those situations, clients Clients (or Servers) would typically want to benefit
 from the features of an improved transport protocol even if the servers Servers (or
 Clients) have not yet been upgraded and
        conversely. upgraded.

Some assistance from the network to make use of these features is
valuable. For example, Performance Enhancing Proxies <xref
        target="RFC3135"></xref>, target="RFC3135"
format="default"/> and other service functions have been deployed as solutions
to improve TCP performance over links with specific characteristics.</t>

        <t>Recent examples of TCP extensions include Multipath TCP (MPTCP)
        <xref target="RFC6824"></xref> target="RFC8684" format="default"/> or TCPINC tcpcrypt <xref
        target="RFC8548"></xref>. target="RFC8548" format="default"/>. Those extensions
        provide features that are interesting for clients Clients such as wireless
        devices. With Multipath TCP, those devices could seamlessly use
        Wireless Local Area Network (WLAN) and cellular networks, networks for bonding
        purposes, faster hand-overs, or better resiliency. Unfortunately,
        deploying those extensions on both a wide range of clients Clients and servers Servers
        remains difficult.</t>
        <t>More recently, 5G bonding experimentation has been conducted into
        global range of the incumbent 4G (LTE) connectivity using newly
        devised clients Clients and a Multipath TCP proxy. Even if the 5G and the 4G
        bonding (that relies upon Multipath TCP) increases the bandwidth, it
        is as well also crucial to minimize latency for all the way entirely between
        endhosts end hosts
        regardless of whether intermediate nodes are inside or outside of the
        mobile core. In order to handle Ultra Reliable Low Latency
        Communication (URLLC) for the next generation next-generation mobile network,
        Multipath TCP and its proxy mechanism such as the one used to provide
        Access Traffic Steering, Switching, and Splitting (ATSSS) must be
        optimized to reduce latency <xref target="TS23501"></xref>.</t> target="TS23501"
        format="default"/>.</t>
      </section>

      <section anchor="network-assisted-connections-the-rationale"
               title="Network-Assisted numbered="true" toc="default">
        <name>Network-Assisted Connections: The Rationale"> Rationale</name>
        <t>This document specifies an application proxy, proxy called Transport
        Converter. A Transport Converter is a function that is installed by a
        network operator to aid the deployment of TCP extensions and to
        provide the benefits of such extensions to clients Clients in particular. A
        Transport Converter may provide conversion service for one or more TCP
        extensions. Which TCP extensions are eligible to for the conversion
        service is deployment-specific. deployment specific. The conversion service is provided by
        means of the 0-RTT TCP Convert Protocol (Convert), that which is an
        application-layer protocol which that uses a specific TCP port number on
        the Converter.</t>
        <t>The Convert Protocol provides Zero Round-Trip Time (0-RTT)
        conversion service since no extra delay is induced by the protocol
        compared to connections that are not proxied. Particularly, the
        Convert Protocol does not require extra signaling setup delays before
        making use of the conversion service. The Convert Protocol does not
        require any encapsulation (no tunnels, whatsoever).</t>
        <t>The Transport Converter adheres to the main steps drawn in Section
        3 of <xref target="RFC1919"></xref>.
        target="RFC1919" sectionFormat="of" section="3"/>. In particular, a
        Transport Converter achieves the following:</t>

        <t><list style="symbols">
            <t>Listen for client sessions;</t>

            <t>Receive from a client
        <ul spacing="normal">
          <li>Listening for Client sessions;</li>
          <li>Receiving the address of the server;</t>

            <t>Setup Server from the Client;</li>
          <li>Setting up a session to the server;</t>

            <t>Relay Server;</li>
          <li>Relaying control messages and data between the client Client and the
            server;</t>

            <t>Perform
            Server;</li>
          <li>Performing access controls according to local policies.</t>
          </list></t> policies.</li>
        </ul>

        <t>The main advantage of network-assisted conversion services is that
        they enable new TCP extensions to be used on a subset of the path
        between endpoints, which encourages the deployment of these
        extensions. Furthermore, the Transport Converter allows the client Client and
        the server Server to directly negotiate TCP extensions for the sake of native
        support along the full path.</t>
        <t>The Convert Protocol is a generic mechanism to provide 0-RTT
        conversion service. As a sample applicability use case, this document
        specifies how the Convert Protocol applies for Multipath TCP. It is
        out of scope of this document to provide a comprehensive list of all
        potential conversion services. Applicability documents may be defined
        in the future.</t>
        <t>This document does not assume that all the traffic is eligible to for
        the network-assisted conversion service. Only a subset of the traffic
        will be forwarded to a Transport Converter according to a set of
        policies. These policies, and how they are communicated to endpoints,
        are out of scope. Furthermore, it is possible to bypass the Transport
        Converter to connect directly to the servers Servers that already support the
        required TCP extension(s).</t>
        <t>This document assumes an explicit model in which a client Client is
        configured with one or a list of Transport Converters (statically or
        through protocols such as <xref
        target="I-D.boucadair-tcpm-dhc-converter"></xref>). target="I-D.boucadair-tcpm-dhc-converter" format="default"/>). Configuration
        means are outside the scope of this document.</t>
        <t>The use of a Transport Converter means that there is no end-to-end
        transport connection between the client Client and server. Server. This could
        potentially create problems in some scenarios such as those discussed
        in Section 4 of <xref target="RFC3135"></xref>. target="RFC3135" sectionFormat="of" section="4"/>. Some of these problems
        may not be applicable, for applicable. For example, a Transport Converter can inform a
        client
        Client by means of Network Failure (65) or Destination Unreachable
        (97) error messages (<xref target="sec-error"></xref>) target="sec-error" format="default"/>) that it
        encounters a failure problem; the client Client can react accordingly. An
        endpoint, or its network administrator, can assess the benefit
        provided by the Transport Converter service versus the risk. This is
        one reason why the Transport Converter functionality has to be
        explicitly requested by an endpoint.</t>

        <t>This

<t>
This document is organized as follows. First, follows:
</t>
<ul empty="true">
<li>
     <xref
        target="sec-socks"></xref> target="sec-socks"/> provides a brief overview of the differences
     between the well-known SOCKS protocol and the 0-RTT TCP Convert protocol. Protocol.
</li>
     <li> <xref target="sec-arch"></xref> target="sec-arch"/>  provides a brief explanation of the operation of Transport
     Converters. Then, </li>
<li>
     <xref target="sample-examples"/> includes a set of sample examples to illustrate the overall
    behavior.
</li>
     <li>
 <xref
        target="sec-protocol"></xref> target="sec-protocol"/> describes the Convert Protocol.
     </li>
     <li> <xref
        target="sec-tcpoptions"></xref> target="sec-tcpoptions"/> discusses how Transport Converters can be used to support
     different TCP extensions. </li>
<li>
     <xref
        target="sec-middleboxes"></xref> target="sec-middleboxes"/> then discusses the interactions with
        middleboxes, while middleboxes.
</li>
     <li> <xref target="sec-security"></xref> target="sec-security"/> focuses on the security considerations. </li>
     <li> <xref target="sec-api"></xref> target="sec-api"/> describes how a TCP stack would need to support the
       protocol described in this
        document.</t> document.
</li>
</ul>

      </section>
      <section title="Applicability Scope">
        <t>0-RTT numbered="true" toc="default">
        <name>Applicability Scope</name>
        <t>The 0-RTT TCP Convert Protocol specified in this document MUST <bcp14>MUST</bcp14> be used
        in a single administrative domain deployment model. That is, the
        entity offering the connectivity service to a client Client is also be the entity
        which
        that owns and operates the Transport Converter, with no transit over
        a third-party network.</t>
        <t>Future deployment of Transport Converters by third parties MUST
        <bcp14>MUST</bcp14> adhere to the mutual authentication requirements
        in <xref
        target="authorization"></xref> target="authorization" format="default"/> to prevent
        illegitimate traffic interception (<xref target="traffic-theft"></xref>), target="traffic-theft"
        format="default"/>) in particular.</t>
      </section>
    </section>

    <section anchor="conventions-and-definitions" numbered="true" toc="default">
      <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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

    </section>

    <section anchor="sec-socks" title="Differences numbered="true" toc="default">
      <name>Differences with SOCKSv5"> SOCKSv5</name>
      <t>Several IETF protocols provide proxy services; services, the closest to the
      0-RTT TCP Convert protocol Protocol being the SOCKSv5 protocol <xref
      target="RFC1928"></xref>. target="RFC1928"
      format="default"/>. This protocol is already used to deploy Multipath
      TCP in some cellular networks (Section 2.2 of <xref
      target="RFC8041"></xref>).</t> (<xref target="RFC8041" sectionFormat="of"
      section="2.2"/>).</t>
      <t>A SOCKS Client creates a connection to a SOCKS Proxy, exchanges
      authentication information, and indicates the IP address and port number
      of the target Server. At this point, the SOCKS Proxy creates a
      connection towards the target Server and relays all data between the two
      proxied connections. The operation of an implementation based on SOCKSv5
      (without authentication) is illustrated in <xref
      target="fig-socks5"></xref>.</t> target="fig-socks5" format="default"/>.</t>
      <figure anchor="fig-socks5"
              title="Establishment anchor="fig-socks5">
        <name>Establishment of a TCP Connection through a SOCKS Proxy Without Authentication">
        <artwork><![CDATA[ without Authentication</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Client                SOCKS Proxy               Server
   |                       |                       |
   | --------------------> |                       |
   |         SYN           |                       |
   | <-------------------- |                       |
   |       SYN+ACK         |                       |
   | --------------------> |                       |
   |         ACK           |                       |
   |                       |                       |
   | --------------------> |                       |
   |Version=5, Auth Methods|                       |
   | <-------------------- |                       |
   |       Method          |                       |
   | --------------------> |                       |
   |Auth Request (unless "No auth" method negotiated)
   | <-------------------- |                       |
   |     Auth Response     |                       |
   | --------------------> |                       |
   | Connect Server:Port   | --------------------> |
   |                       |          SYN          |
   |                       | <-------------------- |
   |                       |        SYN+ACK        |
   | <-------------------- |                       |
   |      Succeeded        |                       |
   | --------------------> |                       |
   |       Data1           |                       |
   |                       | --------------------> |
   |                       |         Data1         |
   |                       | <-------------------- |
   |                       |         Data2         |
   | <-------------------- |                       |
   |          Data2        |                       |
                         ...
]]></artwork>
      </figure>
      <t>When SOCKS is used, an "end-to-end" connection between a Client and a
      Server becomes a sequence of two TCP connections that are glued together
      on the SOCKS Proxy. The SOCKS Client and Server exchange control
      information at the beginning of the bytestream on the Client-Proxy
      connection. The SOCKS Proxy then creates the connection with the target
      Server and then glues the two connections together so that all bytes
      sent by the application (Client) to the SOCKS Proxy are relayed to the
      Server and vice versa.</t>
      <t>The Convert Protocol is also used on TCP proxies that relay data
      between an upstream and a downstream connection, but there are important
      differences with SOCKSv5. A first difference is that the 0-RTT TCP
      Convert
      protocol Protocol exchanges all the control information during the
      initial RTT.  This reduces the connection establishment delay compared
      to SOCKS SOCKS, which requires two or more round-trip-times round-trip times before the
      establishment of the downstream connection towards the final
      destination. In today's Internet, latency is an important metric metric, and
      various protocols have been tuned to reduce their latency <xref
      target="I-D.arkko-arch-low-latency"></xref>.
      target="I-D.arkko-arch-low-latency" format="default"/>. A recently
      proposed extension to SOCKS leverages the TCP Fast Open (TFO) option
      <xref
      target="I-D.olteanu-intarea-socks-6"></xref> target="I-D.olteanu-intarea-socks-6" format="default"/> to reduce
      this delay.</t>
      <t>A second difference is that the Convert Protocol explicitly takes the
      TCP extensions into account. By using the Convert Protocol, the Client
      can learn whether a given TCP extension is supported by the destination
      Server. This enables the Client to bypass the Transport Converter when
      the Server supports the required TCP extension(s). Neither SOCKSv5 <xref
      target="RFC1928"></xref>
      target="RFC1928" format="default"/> nor the proposed SOCKSv6 <xref
      target="I-D.olteanu-intarea-socks-6"></xref>
      target="I-D.olteanu-intarea-socks-6" format="default"/> provide such a
      feature.</t>
      <t>A third difference is that a Transport Converter will only confirm
      the establishment of the connection initiated by the Client provided
      that the downstream connection has already been accepted by the Server.
      If the Server refuses the connection establishment attempt from the
      Transport Converter, then the upstream connection from the Client is
      rejected as well. This feature is important for applications that check
      the availability of a Server or use the time to connect as a hint on the
      selection of a Server <xref target="RFC8305"></xref>.</t> target="RFC8305" format="default"/>.</t>
      <t>A fourth difference is that the 0-RTT TCP Convert protocol Protocol only allows
      the Client to specify the IP address/port number of the destination
      server
      Server and not a DNS name. We evaluated an alternate design that
      included the DNS name of the remote peer instead of its IP address as in
      SOCKS <xref target="RFC1928"></xref>. target="RFC1928" format="default"/>. However, that design
      was not adopted because it induces both an extra load and increased
      delays on the Transport Converter to handle and manage DNS resolution
      requests.  Note that the name resolution at the Converter may fail
      (e.g., private names discussed in Section 2.1 of <xref target="RFC6731"></xref>) target="RFC6731"
      sectionFormat="of" section="2.1"/>) or may not match the one that would
      be returned by a Client's resolution library (e.g., Section 2.2 of <xref target="RFC6731"></xref>).</t>
    </section>

    <section anchor="conventions-and-definitions"
             title="Conventions and Definitions">
      <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><xref target="RFC8174"></xref> when, and
      only when, they appear in all capitals, as shown here.</t>
      target="RFC6731" sectionFormat="of" section="2.2"/>).</t>
    </section>

    <section anchor="sec-arch" title="Architecture &amp; Behaviors"> numbered="true" toc="default">
      <name>Architecture and Behaviors</name>
      <section anchor="functional-elements" title="Functional Elements"> numbered="true" toc="default">
        <name>Functional Elements</name>
        <t>The Convert Protocol considers three functional elements:</t>

        <t><list style="symbols">
            <t>Clients;</t>

            <t>Transport Converters;</t>

            <t>Servers.</t>
          </list></t>
        <ul spacing="normal">
          <li>Clients</li>
          <li>Transport Converters</li>
          <li>Servers</li>
        </ul>
        <t>A Transport Converter is a network function that proxies all data
        exchanged over one upstream connection to one downstream connection
        and vice versa (<xref target="figtc"></xref>). The target="figtc" format="default"/>). Thus, the Transport
        Converter, thus,
        Converter maintains state that associates one upstream
        connection to a corresponding downstream connection.</t>
        <t>A connection can be initiated from both sides of the Transport
        Converter (External realm, Internal realm).</t>
        <figure anchor="figtc"
                title="A anchor="figtc">
          <name>A Transport Converter Proxies Data between Pairs of TCP Connections">
          <artwork><![CDATA[ Connections</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                           |
                           :
                           |
                     +------------+
Client <- upstream ->| Transport  |<- downstream -> Server
         connection  | Converter  |   connection
                     +------------+
                           |
            Internal realm : External realm
                           |
]]></artwork>
        </figure>
        <t>"Client" refers to a software instance embedded on a host that can
        reach a Transport Converter in the internal realm. The "Client" can
        initiate connections via a Transport Converter (referred to as
        outgoing connections). Also, the "Client" can accept incoming
        connections via a Transport Converter (referred to as incoming
        connections).</t>
        <t>A Transport Converter can be embedded in a standalone device or be
        activated as a service on a router. How such a function is enabled is
        deployment-specific.</t>
        deployment specific.</t>
        <t>The architecture assumes that new software will be installed on the
        Client hosts to interact with one or more Transport Converters.
        Furthermore, the architecture allows for making use of new TCP
        extensions even if those are not supported by a given server.</t> Server.</t>
        <t>A Client is configured, through means that are outside the scope of
        this document, with the names and/or the addresses of one or more
        Transport Converters and the TCP extensions that they support. The
        procedure for selecting a Transport Converter among a list of
        configured Transport Converters is outside the scope of this
        document.</t>
        <t>One of the benefits of this design is that different transport
        protocol extensions can be used on the upstream and the downstream
        connections. This encourages the deployment of new TCP extensions
        until they are widely supported by servers, supported, in particular.</t> particular,  by Servers.</t>
        <t>The architecture does not mandate anything on the Server side.</t>
        <t>Similar to SOCKS, the architecture does not interfere with
        end-to-end TLS connections <xref target="RFC8446"></xref> target="RFC8446" format="default"/> between the
        Client and the Server (<xref target="figtls"></xref>). target="figtls" format="default"/>). In other words,
        end-to-end TLS is supported in the presence of a Converter.</t>
        <figure anchor="figtls"
                title="End-to-end anchor="figtls">
          <name>End-to-end TLS via a Transport Converter">
          <artwork><![CDATA[ Converter</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    Client             Transport                Server
       |               Converter                  |
       |                   |                      |
       /==========================================\
      |            End-to-end TLS                  |
       \==========================================/

    * TLS messages exchanged between the Client
      and the Server are not shown.
]]></artwork>
        </figure>
        <t>It is out of scope of this document to elaborate on specific
        considerations related to the use of TLS in the Client-Converter
        connection leg to exchange Convert messages (in addition to the
        end-to-end TLS connection). In particular, (1) assessment of whether
        0-RTT data mode discussed in Section 2.3 of <xref
        target="RFC8446"></xref> target="RFC8446"
        sectionFormat="of" section="2.3"/> is safe under replay and (2)
        specification of a profile for its use (Section E.5 of <xref target="RFC8446"></xref>) (<xref target="RFC8446"
        sectionFormat="of" section="E.5"/>) are out of scope.</t>
      </section>
      <section anchor="sec-to" title="Theory numbered="true" toc="default">
        <name>Theory of Operation"> Operation</name>
        <t>At a high level, the objective of the Transport Converter is to
        allow the use a specific extension, e.g., Multipath TCP, on a subset
        of the path even if the peer does not support this extension. This is
        illustrated in <xref target="fig-highlevel"></xref> target="fig-highlevel" format="default"/> where the Client
        initiates a Multipath TCP connection with the Transport Converter
        (packets belonging to the Multipath TCP connection are shown with
        "===") while the Transport Converter uses a TCP connection with the
        Server.</t>
        <figure anchor="fig-highlevel"
                title="An anchor="fig-highlevel">
          <name>An Example of 0-RTT Network-Assisted Outgoing MPTCP Connection">
          <artwork><![CDATA[ Connection</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    Client             Transport                Server
       |               Converter                  |
       |                   |                      |
       |==================>|--------------------->|
       |                   |                      |
       |<==================|<---------------------|
       |                   |                      |
      Multipath TCP packets     TCP packets
]]></artwork>
        </figure>
        <t>The packets belonging to a connection established through a
        Transport Converter may follow a different path than the packets
        directly exchanged between the Client and the Server. Deployments
        should minimize the possible additional delay by carefully selecting
        the location of the Transport Converter used to reach a given
        destination.</t>
        <t>When establishing a connection, the Client can, depending on local
        policies, either contact the Server directly (e.g., by sending a TCP
        SYN towards the Server) or create the connection via a Transport
        Converter. In the latter case (that is, the conversion service is
        used), the Client initiates a connection towards the Transport
        Converter and indicates the IP address and port number of the Server
        within the connection establishment packet. Doing so enables the
        Transport Converter to immediately initiate a connection towards that
        Server,
        Server without experiencing an extra delay. The Transport Converter
        waits until the receipt of the confirmation that the Server agrees to
        establish the connection before confirming it to the Client.</t>
        <t>The Client places the destination address and port number of the
        Server in the payload of the SYN sent to the Transport Converter to
        minimize connection establishment delays. The Transport Converter
        maintains two connections that are combined together:</t>

        <t><list style="symbols">
            <t>the
        <ul spacing="normal">
          <li>The upstream connection is the one between the Client and the
            Transport Converter.</t>

            <t>the Converter.</li>
          <li>The downstream connection is the one between the Transport
            Converter and the Server.</t>
          </list></t> Server.</li>
        </ul>
        <t>Any user data received by the Transport Converter over the upstream
        (or downstream) connection is proxied over the downstream (or
        upstream) connection.</t>
        <t><xref target="fig-estab"></xref> target="fig-estab" format="default"/> illustrates the establishment of
        an outgoing TCP connection by a Client through a Transport
        Converter.</t>

        <t><list style="symbols">
            <t>Note:
	<aside><t>
          Note: The information shown between brackets in <xref
            target="fig-estab"></xref>
	  target="fig-estab" format="default"/> (and other figures in the
	  document) refers to Convert Protocol messages described in <xref
            target="sec-protocol"></xref>.</t>
          </list></t>
	    target="sec-protocol" format="default"/>.</t></aside>

        <figure anchor="fig-estab"
                title="Establishment anchor="fig-estab">
          <name>Establishment of an Outgoing TCP Connection Through through a Transport Converter">
          <artwork><![CDATA[ Converter</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                        Transport
    Client              Converter              Server
       |                   |                      |
       |SYN [->Server:port]|         SYN          |
       |------------------>|--------------------->|
       |<------------------|<---------------------|
       |    SYN+ACK [ ]    |        SYN+ACK       |
       |        ...        |          ...         |
]]></artwork>
        </figure>
        <t>The Client sends a SYN destined to the Transport Converter. The
        payload of this SYN contains the address and port number of the
        Server. The Transport Converter does not reply immediately to this
        SYN. It first tries to create a TCP connection towards the target
        Server. If this upstream connection succeeds, the Transport Converter
        confirms the establishment of the connection to the Client by
        returning a SYN+ACK and the first bytes of the bytestream contain
        information about the TCP options that were negotiated with the
        Server. Also, a state entry is instantiated for this connection. This
        state entry is used by the Converter to handle subsequent messages
        belonging to the connection.</t>
        <t>The connection can also be established from the Internet towards a
        Client via a Transport Converter (<xref target="fig-estab2"></xref>). target="fig-estab2"
        format="default"/>).  This is typically the case when the Client hosts
        an application server Server that listens to a specific port number. When the
        Converter receives an incoming SYN from a remote host, it checks if it
        can provide the conversion service for the destination IP address and
        destination port number of that SYN. The Transport Converter receives
        this SYN because it is, for example, on the path between the remote
        host and the Client or it provides address sharing address-sharing service for the
        Client (Section 2 of
        <xref target="RFC6269"></xref>). (<xref target="RFC6269" sectionFormat="of" section="2"/>). If
        the check fails, the packet is silently ignored by the Converter. If
        the check is successful, the Converter tries to initiate a TCP
        connection towards the Client from its own address and using its
        configured TCP options. In the SYN that corresponds to this connection
        attempt, the Transport Convert inserts a TLV message that indicates
        the source address and port number of the remote host. A transport
        session entry is created by the Converter for this connection. SYN+ACK
        and ACK will be then be exchanged between the Client, the Converter, and
        remote host to confirm the establishment of the connection. The
        Converter uses the transport session entry to proxy packets belonging
        to the connection.</t>
        <figure anchor="fig-estab2"
                title="Establishment anchor="fig-estab2">
          <name>Establishment of an Incoming TCP Connection Through through a Transport Converter">
          <artwork><![CDATA[ Converter</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  Transport              Remote
    Client              Converter             Host (RH)
       |                   |                      |
       |SYN [<-RH IP@:port]|         SYN          |
       |<------------------|<---------------------|
       |------------------>|--------------------->|
       |    SYN+ACK [ ]    |        SYN+ACK       |
       |        ...        |          ...         |

]]></artwork>
        </figure>
        <t>Standard TCP (<xref target="RFC0793"></xref>, Section 3.4) target="RFC0793" format="default" section="3.4"/>) allows a
        SYN packet to carry data inside its payload but forbids the receiver
        from delivering it to the application until completion of the
        three-way-handshake. To enable applications to exchange data in a TCP
        handshake, this specification follows an approach similar to TCP Fast
        Open <xref target="RFC7413"></xref> target="RFC7413" format="default"/> and thus thus, removes the constraint by
        allowing data in SYN packets to be delivered to the Transport
        Converter application.</t>
        <t>As discussed in <xref target="RFC7413"></xref>, target="RFC7413" format="default"/>, such
        change to TCP
        semantic semantics raises two issues. First, duplicate SYNs can
        cause problems for applications that rely on TCP; whether or not a
        given application is affected dependes depends on the details of that
        application protocol.  Second, TCP suffers from SYN flooding attacks
        <xref
        target="RFC4987"></xref>. target="RFC4987" format="default"/>. TFO solves these two
        problems for applications that can tolerate replays by using the TCP
        Fast Open option that includes a cookie. However, the utilization of
        this option consumes space in the limited TCP header. Furthermore,
        there are situations, as noted in Section 7.3 of <xref target="RFC7413"></xref> target="RFC7413"
        sectionFormat="of" section="7.3"/>, where it is possible to accept the
        payload of SYN packets without creating additional security risks such
        as a network where addresses cannot be spoofed and the Transport
        Converter only serves a set of hosts that are identified by these
        addresses.</t>
        <t>For these reasons, this specification does not mandate the use of
        the TCP Fast Open option when the Client sends a connection
        establishment packet towards a Transport Converter. The Convert
        Protocol includes an optional Cookie TLV that provides similar
        protection as the TCP Fast Open option without consuming space in the
        TCP header. Furthermore, this design allows for the use of longer
        cookies than <xref target="RFC7413"></xref>.</t> target="RFC7413" format="default"/>.</t>
        <t>If the downstream (or upstream) connection fails for some reason
        (excessive retransmissions, reception of an RST segment, etc.), then
        the Converter reacts by forcing the tear-down teardown of the upstream (or
        downstream) connection. In particular, if an ICMP error message that
        indicates a hard error is received on the downstream connection, the
        Converter echoes the Code field of that ICMP message in a Destination
        Unreachable Error TLV (see <xref target="sec-error"></xref>) target="sec-error" format="default"/>) that it
        transmits to the Client. Note that if an ICMP error message that
        indicates a soft error is received on the downstream connection, the
        Converter will retransmit the corresponding data until it is
        acknowledged or the connection times out. A classification of ICMP
        soft and hard errors is provided in Table 1 of <xref
        target="RFC5461"></xref>.</t> target="RFC5461" format="default"/>.</t>
        <t>The same reasoning applies when the upstream connection ends with
        an exchange of FIN segments. In this case, the Converter will also
        terminate the downstream connection by using FIN segments. If the
        downstream connection terminates with the exchange of FIN segments,
        the Converter should initiate a graceful termination of the upstream
        connection.</t>
      </section>
      <section anchor="sec-dbb"
               title="Data numbered="true" toc="default">
        <name>Data Processing at the Transport Converter"> Converter</name>
        <t>As mentioned in <xref target="sec-to"></xref>, target="sec-to" format="default"/>, the Transport
        Converter acts as a TCP proxy between the upstream connection (i.e.,
        between the Client and the Transport Converter) and the downstream
        connection (i.e., between the Transport Converter and the Server).</t>

        <t>The control messages, messages (i.e., the Convert messages discussed in <xref
        target="sec-protocol"></xref>, target="sec-protocol"
        format="default"/>) establish state (called, (called transport session entry)
        in the Transport Converter that will enable it to proxy between the
        two TCP connections.</t>
        <t>The Transport Converter uses the transport session entry to proxy
        packets belonging to the connection. An implementation example of a
        transport session entry for TCP connections is shown in <xref
        target="fig-dbt"></xref>.</t> target="fig-dbt" format="default"/>.</t>
        <figure anchor="fig-dbt" title="An anchor="fig-dbt">
          <name>An Example of Transport Session Entry">
          <artwork><![CDATA[ Entry</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                   (C,c) <--> (T,t), (S,s), Lifetime

   Where:
     * C
]]></artwork>

        </figure>

<t>   Where:</t>

<ul>
<li>C and c are the source IP address and source port number used by the
Client for the upstream connection.
     * S
</li>
<li>S and s are the Server's IP address and port number.
     * T
</li>
<li>T and t are the source IP address and source port number used by the
Transport Converter to proxy the connection.
     * Lifetime
</li>
<li>Lifetime is a timer that tracks the remaining lifetime of the entry as
assigned by the Converter. When the timer expires, the entry is deleted.
]]></artwork>
        </figure>
</li>
</ul>

        <t>Clients send packets bound to connections eligible to for the
        conversion service to the provisioned Transport Converter and
        destination port number. This applies for both control messages and
        data. Additional information is supplied by Clients to the Transport
        Converter by means of Convert messages as detailed in <xref
        target="sec-protocol"></xref>.
        target="sec-protocol" format="default"/>. User data can be included in
        SYN or non-SYN messages. User data is unambiguously distinguished from
        Convert TLVs by a Transport Converter owing to the Convert Fixed
        Header in the Convert messages (<xref target="sec-header"></xref>). target="sec-header"
        format="default"/>).  These Convert TLVs are destined to the Transport
        Convert and are, thus, removed by the Transport Converter when
        proxying between the two connections.</t>
        <t>Upon receipt of a packet that belongs to an existing connection
        between a Client and the Transport Converter Converter, the Converter proxies the
        user data to the Server using the information stored in the
        corresponding transport session entry. For example, in reference to
        <xref target="fig-dbt"></xref>, target="fig-dbt" format="default"/>, the Transport Converter proxies the
        data received from (C, c) (C,&wj;c) downstream using (T,t) as source transport
        address and (S,s) as destination transport address.</t>
        <t>A similar process happens for data sent from the Server. The
        Converter acts as a TCP proxy and sends the data to the Client relying
        upon the information stored in a transport session entry. The
        Converter associates a lifetime with state entries used to bind an
        upstream connection with its downstream connection.</t>
        <t>When Multipath TCP is used between the Client and the Transport
        Converter, the Converter maintains more state (e.g. (e.g., information about
        the subflows) for each Multipath TCP connection. The procedure
        described above continues to apply except that the Converter needs to
        manage the establishment/termination of subflows and schedule packets
        among the established ones. These operations are part of the Multipath
        TCP implementation. They are independent of the Convert protocol Protocol that
        only processes the Convert messages in the beginning of the
        bytestream.</t>
        <t>A Transport Converter may operate in address preservation mode
        (that is, the Converter does not rewrite the source IP address (i.e.,
        C==T)) or address sharing address-sharing mode (that is, an address pool is shared
        among all Clients serviced by the Converter (i.e., C!=T)); refer to
        <xref target="sec-add"></xref> target="sec-add" format="default"/> for more details. Which
        behavior to use by a Transport Converter is deployment-specific. deployment specific. If address sharing
        address-sharing mode is enabled, the Transport Converter MUST
        <bcp14>MUST</bcp14> adhere to REQ-2 of <xref
        target="RFC6888"></xref> target="RFC6888"
        format="default"/>, which implies a default "IP address pooling"
        behavior of "Paired" (as defined in Section 4.1 of <xref
        target="RFC4787"></xref>) MUST target="RFC4787"
        sectionFormat="of" section="4.1"/>) <bcp14>MUST</bcp14> be
        supported. This behavior is meant to avoid breaking applications that
        depend on the source address remaining constant.</t>
      </section>

      <section anchor="sec-add"
               title="Address numbered="true" toc="default">
        <name>Address Preservation vs. Address Sharing"> Sharing</name>
        <t>The Transport Converter is provided with instructions about the
        behavior to adopt with regards regard to the processing of source addresses
        of outgoing packets. The following sub-sections discusses subsections discuss two
        deployment models for illustration purposes. It is out of the scope of
        this document to make a recommendation.</t>
        <section anchor="sec-addp" title="Address Preservation"> numbered="true" toc="default">
          <name>Address Preservation</name>
          <t>In this model, the visible source IP address of a packet proxied
          by a Transport Converter to a Server is an IP address of the end
          host (Client). No dedicated IP address pool is provisioned to the
          Transport Converter, but the Transport Converter is located on the
          path between the Client and the Server.</t>
          <t>For Multipath TCP, the Transport Converter preserves the source
          IP address used by the Client when establishing the initial subflow.
          Data conveyed in secondary subflows will be proxied by the Transport
          Converter using the source IP address of the initial subflow. An
          example of a proxied Multipath TCP connection with address
          preservation is shown in <xref target="fig-addp"></xref>.</t> target="fig-addp" format="default"/>.</t>
          <figure anchor="fig-addp" title="Example anchor="fig-addp">
            <name>Example of Address Preservation">
            <artwork><![CDATA[ Preservation</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                                      Transport
       Client                        Converter          Server

        @:C1,C2                        @:Tc                @:S
           ||                            |                  |
           |src:C1     SYN         dst:Tc|src:C1       dst:S|
           |-------MPC [->S:port]------->|-------SYN------->|
           ||                            |                  |
           ||dst:C1                src:Tc|dst:C1       src:S|
           |<---------SYN/ACK------------|<-----SYN/ACK-----|
           ||                            |                  |
           |src:C1                 dst:Tc|src:C1       dst:S|
           |------------ACK------------->|-------ACK------->|
           |                             |                  |
           |src:C2          ...    dst:Tc|       ...        |
           ||<-----Secondary Subflow---->|src:C1       dst:S|
           ||                            |-------data------>|
           |               ..            |    ...           |

Legend:
  Tc: IP address used by the Transport Converter on the internal
      realm.
]]></artwork>
          </figure>
          <t>The Transport Converter must be on the forwarding path of
          incoming traffic. Because the same (destination) IP address is used
          for both proxied and non-proxied connections, the Transport
          Converter should not drop incoming packets it intercepts if no
          matching entry is found for the packets. Unless explicitly
          configured otherwise, such packets are forwarded according to the
          instructions of a local forwarding table.</t>
        </section>
        <section anchor="sec-adds" title="Address/Prefix Sharing"> numbered="true" toc="default">
          <name>Address/Prefix Sharing</name>
          <t>A pool of global IPv4 addresses is provisioned to the Transport
          Converter along with possible instructions about the address sharing address-sharing
          ratio to apply (see Appendix B of <xref target="RFC6269"></xref>). target="RFC6269"
	  sectionFormat="of" section="B"/>).
          An address is thus shared among multiple clients.</t> Clients.</t>
          <t>Likewise, rewriting the source IPv6 prefix <xref
          target="RFC6296"></xref> target="RFC6296" format="default"/> may be used to ease redirection of incoming
          IPv6 traffic towards the appropriate Transport Converter. A pool of
          IPv6 prefixes is then provisioned to the Transport Converter for
          this purpose.</t>
          <t>Adequate forwarding policies are enforced so that traffic
          destined to an address of such a pool is intercepted by the
          appropriate Transport Converter. Unlike <xref
          target="sec-addp"></xref>, target="sec-addp"
          format="default"/>, the Transport Converter drops incoming packets which
          that do not match an active transport session entry.</t>
          <t>An example is shown in <xref target="fig-adds"></xref>.</t> target="fig-adds" format="default"/>.</t>
          <figure anchor="fig-adds" title="Address Sharing">
            <artwork><![CDATA[ anchor="fig-adds">
            <name>Address Sharing</name>
         <artwork name="" type="" align="left" alt=""><![CDATA[
                                     Transport
      Client                         Converter          Server

         @:C                        @:Tc|Te                @:S
          |                             |                  |
          |src:C                  dst:Tc|src:Te       dst:S|
          |-------SYN [->S:port]------->|-------SYN------->|
          |                             |                  |
          |dst:C                  src:Tc|dst:Te       src:S|
          |<---------SYN/ACK------------|<-----SYN/ACK-----|
          |                             |                  |
          |src:C                  dst:Tc|src:Te       dst:S|
          |------------ACK------------->|-------ACK------->|
          |                             |                  |
          |              ...            |    ...           |

Legend:
  Tc: IP address used by the Transport Converter on the internal
      realm.
  Te: IP address used by the Transport Converter on the external
      realm.
]]></artwork>
          </figure>
        </section>
      </section>
    </section>
    <section anchor="sample-examples" title="Sample Examples"> numbered="true" toc="default">
      <name>Sample Examples</name>
      <section anchor="outgoing-converter-assisted-multipath-tcp-connections"
               title="Outgoing numbered="true" toc="default">
        <name>Outgoing Converter-Assisted Multipath TCP Connections"> Connections</name>
        <t>As an example, let us consider how the Convert Protocol can help
        the deployment of Multipath TCP. We assume that both the Client and
        the Transport Converter support Multipath TCP, TCP but consider two
        different cases depending on whether or not the Server supports Multipath TCP
        or not.</t> TCP.</t>
        <t>As a reminder, a Multipath TCP connection is created by placing the
        MP_CAPABLE (MPC) option in the SYN sent by the Client.</t>
        <t><xref target="fig-mpestab"></xref> target="fig-mpestab" format="default"/> describes the operation of the
        Transport Converter if the Server does not support Multipath TCP.</t>
        <figure anchor="fig-mpestab"
                title="Establishment anchor="fig-mpestab">
          <name>Establishment of a Multipath TCP Connection through a
          Transport Converter towards a Server that does not That Does Not support Multipath TCP">
          <artwork><![CDATA[
          TCP</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                        Transport
    Client              Converter              Server
       |SYN, MPC           |                      |
       |[->Server:port]    |         SYN, MPC     |
       |------------------>|--------------------->|
       |<------------------|<---------------------|
       |  SYN+ACK,MPC [.]  |      SYN+ACK         |
       |------------------>|--------------------->|
       |     ACK, MPC      |          ACK         |
       |        ...        |          ...         |
]]></artwork>
        </figure>
        <t>The Client tries to initiate a Multipath TCP connection by sending
        a SYN with the MP_CAPABLE option (MPC in <xref
        target="fig-mpestab"></xref>). target="fig-mpestab" format="default"/>). The SYN includes the address and port
        number of the target Server, that are extracted and used by the
        Transport Converter to initiate a Multipath TCP connection towards
        this Server. Since the Server does not support Multipath TCP, it
        replies with a SYN+ACK that does not contain the MP_CAPABLE option.
        The Transport Converter notes that the connection with the Server does
        not support Multipath TCP and returns the extended TCP header received
        from the Server to the Client.</t>
        <t>Note that, if the TCP connection is reset for some reason, the
        Converter tears down the Multipath TCP connection by transmitting a an
        MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with the
        transmission of DATA_FINs, the Converter terminates the TCP connection
        by using FIN segments. As a side note, given that with Multipath TCP,
        RST only has the scope of the subflow and will only close the
        concerned subflow but not affect the remaining subflows, the Converter
        does not terminate the downstream TCP connection upon receipt of an
        RST over a Multipath subflow.</t>
        <t><xref target="fig-mpestabok"></xref> target="fig-mpestabok" format="default"/> considers a Server that
        supports Multipath TCP. In this case, it replies to the SYN sent by
        the Transport Converter with the MP_CAPABLE option. Upon reception of
        this SYN+ACK, the Transport Converter confirms the establishment of
        the connection to the Client and indicates to the Client that the
        Server supports Multipath TCP. With this information, the Client has
        discovered that the Server supports Multipath TCP. This will enable
        the Client to bypass the Transport Converter for the subsequent
        Multipath TCP connections that it will initiate towards this
        Server.</t>
        <figure anchor="fig-mpestabok"
                title="Establishment anchor="fig-mpestabok">
          <name>Establishment of a Multipath TCP Connection through a
          Converter towards an MPTCP-capable Server">
          <artwork><![CDATA[ MPTCP-Capable Server</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                        Transport
    Client              Converter              Server
       |SYN, MPC           |                      |
       |[->Server:port]    |         SYN, MPC     |
       |------------------>|--------------------->|
       |<------------------|<---------------------|
       |SYN+ACK, MPC       |      SYN+ACK, MPC    |
       |[MPC supported]    |                      |
       |------------------>|--------------------->|
       |     ACK, MPC      |        ACK, MPC      |
       |        ...        |          ...         |

]]></artwork>
        </figure>
      </section>
      <section anchor="incoming-converter-assisted-multipath-tcp-connection"
               title="Incoming numbered="true" toc="default">
        <name>Incoming Converter-Assisted Multipath TCP Connection"> Connection</name>
        <t>An example of an incoming Converter-assisted Multipath TCP
        connection is depicted in <xref target="fig-inestab"></xref>. target="fig-inestab"
        format="default"/>. In order to support incoming connections from
        remote hosts, the Client may use
        PCP the Port Control Protocol (PCP) <xref target="RFC6887"></xref>
        target="RFC6887" format="default"/> to instruct the Transport
        Converter to create dynamic mappings. Those mappings will be used by
        the Transport Converter to intercept an incoming TCP connection
        destined to the Client and convert it into a Multipath TCP
        connection.</t>

        <t>Typically, the Client sends a PCP request to the Converter asking
        to create an explicit TCP mapping for (internal the internal IP address, address and
        internal port number). number. The Converter accepts the request by creating a
        TCP mapping (internal for the internal IP address, internal port number,
        external IP address, and external port number). number. The external IP
        address, external port number, and assigned lifetime are returned back
        to the Client in the PCP response. The external IP address and
        external port number will be then be advertised by the Client (or the
        user) using an out-of-band mechanism so that remote hosts can initiate
        TCP connections to the Client via the Converter. Note that the
        external and internal information may be the same.</t>
        <t>Then, when the Converter receives an incoming SYN, it checks its
        mapping table to verify if there is an active mapping matching the
        destination IP address and destination port of that SYN. If no entry
        is found, the Converter silently ignores the message. If an entry is
        found, the Converter inserts an MP_CAPABLE option and Connect TLV in
        the SYN packet, and rewrites the source IP address to one of its IP
        addresses and, eventually, the destination IP address and port number
        in accordance with the information stored in the mapping. SYN+ACK and
        ACK will be then be exchanged between the Client and the Converter to
        confirm the establishment of the initial subflow. The Client can add
        new subflows following normal Multipath TCP procedures.</t>
        <figure anchor="fig-inestab"
                title="Establishment anchor="fig-inestab">
          <name>Establishment of an Incoming Multipath TCP Connection through a Transport Converter">
          <artwork><![CDATA[ Converter</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                        Transport             Remote
    Client              Converter              Host
      |                     |                    |
      |<--------------------|<-------------------|
      |SYN, MPC             |         SYN        |
      |[Remote Host:port]   |                    |
      |-------------------->|------------------->|
      |      SYN+ACK, MPC   |       SYN+ACK      |
      |<--------------------|<-------------------|
      |       ACK, MPC      |           ACK      |
      |        ...          |          ...       |
]]></artwork>
        </figure>
        <t>It is out of scope of this document to define specific Convert TLVs
        to manage incoming connections (that is, TLVs that mimic PCP
        messages). These TLVs can be defined in a separate document.</t>
      </section>
    </section>
    <section anchor="sec-protocol" title="The numbered="true" toc="default">
      <name>The Convert Protocol (Convert)"> (Convert)</name>
      <t>This section defines the Convert Protocol (Convert, for short)
      messages that are exchanged between a Client and a Transport
      Converter.</t>
      <t>The Transport Converter listens on a specific TCP port number for
      Convert messages from Clients. That port number is configured by an
      administrator. Absent any policy, the Transport Converter SHOULD <bcp14>SHOULD</bcp14>
      silently ignore SYNs with no Convert TLVs.</t>
      <t>Convert messages may appear only in SYN, SYN+ACK, or ACK.</t>
      <t>Convert messages MUST <bcp14>MUST</bcp14> be included as the first bytes
      of the bytestream. All Convert messages starts start with a fixed header that
      is 32 bits long fixed header (<xref target="sec-header"></xref>) target="sec-header" format="default"/>) followed
      by one or more Convert TLVs (Type, Length, Value) (<xref target="sec-tlv"></xref>).</t>
      target="sec-tlv" format="default"/>).</t>
      <t>If the initial SYN message contains user data in its payload (e.g., see
      <xref target="RFC7413"></xref>), target="RFC7413" format="default"/>), that data MUST <bcp14>MUST</bcp14> be placed right after
      the Convert TLVs when generating the SYN.</t>
      <t>The protocol can be extended by defining new TLVs or bumping the
      version number if a different message format is needed. If a future
      version is defined but with a different message format, the version
      negotiation procedure defined in <xref target="sec-error"></xref> target="sec-error" format="default"/> (see
      "Unsupported Version") is meant to agree on a version that is supported
      by both peers.</t>

      <t><list style="symbols">

      <aside>
        <t>Implementation note 1: Several implementers expressed concerns
        about the use of TFO. As a reminder, the TFO Fast Open Cookie protects from some
        attack scenarios that affect open servers like web servers. The
        Convert Protocol is different and, as discussed in RFC7413, <xref
        target="RFC7413"/>, there are different ways to protect from such
        attacks. Instead of using a
          TFO cookie Fast Open Cookie inside the TCP options, which
        consumes precious space in the extended TCP header, the Convert
        Protocol supports the utilization of a Cookie that is placed in the
        SYN payload. This provides the same level of protection as a TFO Fast Open
        Cookie in environments were such protection is required.</t>
        <t>Implementation note 2: Error messages are not included in RST but
          sent in the bytestream. Implementers have indicated that processing
          RST on clients Clients was difficult on some platforms. This design
          simplifies client Client implementations.</t>
        </list></t>
      </aside>
      <section anchor="sec-header" title="The numbered="true" toc="default">
        <name>The Convert Fixed Header"> Header</name>
        <t>The Convert Protocol uses a 32 bits long fixed header that is 32 bits long sent
        by both the Client and the Transport Converter over each established
        connection. This header indicates both the version of the protocol
        used and the length of the Convert message.</t>
        <t>The Client and the Transport Converter MUST <bcp14>MUST</bcp14> send the fixed-sized
        header, shown in <xref target="fig-header"></xref>, target="fig-header" format="default"/>, as the first four
        bytes of the bytestream.</t>
        <figure anchor="fig-header" title="The anchor="fig-header">
          <name>The Convert Fixed Header">
          <artwork><![CDATA[ Header</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                     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
+---------------+---------------+-------------------------------+
|  Version      |  Total Length |          Magic Number         |
+---------------+---------------+-------------------------------+
]]></artwork>
        </figure>
        <t>The Version version is encoded as an 8 bits 8-bit unsigned integer value. This
        document specifies version 1. Version 0 is reserved by this document
        and MUST NOT <bcp14>MUST NOT</bcp14> be used.<list style="empty">
            <t>Note: used.</t>

<aside>

<t>
            Note: Early versions of this specification don't use a
            dedicated port number but only rely upon the IP address of the
            Converter. Having a bit set in the version Version field together with the
            length
            Total Length field allows to avoid mis-interpreting a avoids misinterpreting data in a SYN as Convert
	    TLVs. Since the design was updated to use a specific
            service port, that constraint was relaxed. Version 0 would work work,
            but given existing implementations already use Version 1, the use
            of Version 0 is maintained as reserved.</t>
          </list></t>
</aside>

        <t>The Total Length is the number of 32 bits word, 32-bit words, including the
        header, of the bytestream that are consumed by the Convert messages.
        Since Total Length is also an 8 bits 8-bit unsigned integer, those messages
        cannot consume more than 1020 bytes of data. This limits the number of
        bytes that a Transport Converter needs to process. A Total Length of
        zero is invalid and the connection MUST <bcp14>MUST</bcp14> be reset upon reception of a
        header with such a total length.</t>

        <t>The Magic Number field MUST <bcp14>MUST</bcp14> be set to the RFC number to be assigned
        to this document. 0x2263. This
	field is meant to further strengthen the protocol to unambiguously
	distinguish any data supplied by an application from Convert TLVs. <list style="symbols">
            <t>Note to the RFC Editor: Please replace "the RFC number to be
            assigned to this document" with the hex representation of the RFC
            number assigned to this document.</t>
          </list></t> </t>

        <t>The Total Length field unambiguously marks the number of 32 bits 32-bit
        words that carry Convert TLVs in the beginning of the bytestream.</t>
      </section>
      <section anchor="sec-tlv" title="Convert TLVs"> numbered="true" toc="default">
        <name>Convert TLVs</name>
        <section anchor="generic-convert-tlv-format"
                 title="Generic numbered="true" toc="default">
          <name>Generic Convert TLV Format"> Format</name>
          <t>The Convert Protocol uses variable length messages that are
          encoded using the generic TLV format depicted in <xref
          target="fi-generictlv"></xref>.</t> target="fi-generictlv" format="default"/>.</t>
          <t>The length of all TLVs used by the Convert Protocol is always a
          multiple of four bytes. All TLVs are aligned on 32 bits 32-bit boundaries.
          All TLV fields are encoded using the network byte order.</t>
          <figure anchor="fi-generictlv" title="Convert anchor="fi-generictlv">
            <name>Convert Generic TLV Format">
            <artwork><![CDATA[ Format</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                        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
   +---------------+---------------+-------------------------------+
   |     Type      |     Length    |             Value  ...        |
   +---------------+---------------+-------------------------------+
   //              ...   (optional) Value                         //
   +---------------------------------------------------------------+
]]></artwork>
          </figure>
          <t>The Length field covers Type, Length, and Value fields. It is
          expressed in units of 32 bits 32-bit words. If necessary, Value MUST <bcp14>MUST</bcp14> be
          padded with zeroes so that the length of the TLV is a multiple of 32
          bits.</t>
          <t>A given TLV MUST <bcp14>MUST</bcp14> only appear once on a connection. If a Client
          receives two or more instances of the same TLV over a Convert
          connection, it MUST <bcp14>MUST</bcp14> reset the associated TCP connection. If a
          Converter receives two or more instances of the same TLV over a
          Convert connection, it MUST <bcp14>MUST</bcp14> return a Malformed Message Error TLV and
          close the associated TCP connection.</t>
        </section>
        <section anchor="summary-of-supported-convert-tlvs"
                 title="Summary numbered="true" toc="default">
          <name>Summary of Supported Convert TLVs"> TLVs</name>
          <t>This document specifies the following Convert TLVs:</t>

          <figure anchor="tab-converter-tlv"
                  title="The

<table anchor="tab-converter-tlv">
  <name>The TLVs used Used by the Convert Protocol">
            <artwork><![CDATA[
+------+-----+----------+------------------------------------------+
| Type | Hex |  Length  | Description                              |
+------+-----+----------+------------------------------------------+
|   1  | 0x1 |    1     | Info TLV                                 |
|  10  | 0xA | Variable | Connect TLV                              |
|  20  | 0x14| Variable | Extended Protocol</name>
  <thead>
    <tr>
      <th>Type</th>
      <th>Hex</th>
      <th>Length</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>0x1</td>
      <td>1</td>
      <td>Info TLV</td>
    </tr>
    <tr>
      <td>10</td>
      <td>0xA</td>
      <td>Variable</td>
      <td>Connect TLV</td>
    </tr>
    <tr>
      <td>20</td>
      <td>0x14</td>
      <td>Variable</td>
      <td>Extended TCP Header TLV                  |
|  21  | 0x15| Variable | Supported TLV</td>
    </tr>
    <tr>
      <td>21</td>
      <td>0x15</td>
      <td>Variable</td>
      <td>Supported TCP Extensions TLV             |
|  22  | 0x16| Variable | Cookie TLV                               |
|  30  | 0x1E| Variable | Error TLV                                |
+------+-----+----------+------------------------------------------+
]]></artwork>
          </figure> TLV</td>
    </tr>
    <tr>
      <td>22</td>
      <td>0x16</td>
      <td>Variable</td>
      <td>Cookie TLV</td>
    </tr>
    <tr>
      <td>30</td>
      <td>0x1E</td>
      <td>Variable</td>
      <td>Error TLV</td>
    </tr>
  </tbody>
</table>

          <t>Type 0x0 is a reserved value. If a Client receives a TLV of type
          0x0, it MUST <bcp14>MUST</bcp14> reset the associated TCP connection. If a Converter
          receives a TLV of type 0x0, it MUST <bcp14>MUST</bcp14> return an Unsupported Message
          Error TLV and close the associated TCP connection.</t>
          <t>The Client typically sends sends, in the first connection it established
          with a Transport Converter Converter, the Info TLV (<xref
          target="sec-bootstrap-tlv"></xref>)
          target="sec-bootstrap-tlv" format="default"/>) to learn its
          capabilities.  Assuming the Client is authorized to invoke the
          Transport Converter, the latter replies with the Supported TCP
          Extensions TLV (<xref
          target="sec-supported"></xref>).</t> target="sec-supported"
          format="default"/>).</t>

          <t>The Client can request the establishment of connections to
          servers
          Servers by using the Connect TLV (<xref
          target="sec-connect"></xref>). target="sec-connect"
          format="default"/>). If the connection can be established with the
          final server, Server, the Transport Converter replies with the Extended TCP
          Header TLV (<xref target="sec-ext-header"></xref>). target="sec-ext-header" format="default"/>). If
          not, the Transport Converter MUST <bcp14>MUST</bcp14> return an Error TLV
          (<xref
          target="sec-error"></xref>) target="sec-error" format="default"/>) and then closes close the
          connection. The Transport Converter MUST NOT <bcp14>MUST NOT</bcp14> send an
          RST immediately after the detection of an error to let the Error TLV
          reach the Client. As explained later, the Client will anyway send an RST
          regardless upon reception of the Error TLV.</t>
        </section>
        <section anchor="sec-bootstrap-tlv" title="The numbered="true" toc="default">
          <name>The Info TLV"> TLV</name>
          <t>The Info TLV (<xref target="fig-bootstrap"></xref>) target="fig-bootstrap" format="default"/>) is
          an optional TLV which that can be sent by a Client to request the TCP
          extensions that are supported by a Transport Converter. It is
          typically sent on the first connection that a Client establishes
          with a Transport Converter to learn its capabilities. Assuming a
          Client is entitled to invoke the Transport Converter, the latter
          replies with the Supported TCP Extensions TLV described in <xref
          target="sec-supported"></xref>.</t>
          target="sec-supported" format="default"/>.</t>
          <figure anchor="fig-bootstrap" title="The anchor="fig-bootstrap">
            <name>The Info TLV">
            <artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                     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
+---------------+---------------+-------------------------------+
|     Type=0x1  |     Length    |             Zero              |
+---------------+---------------+-------------------------------+

]]></artwork>
          </figure>
        </section>
        <section anchor="sec-supported" title="Supported numbered="true" toc="default">
          <name>Supported TCP Extensions TLV"> TLV</name>
          <t>The Supported TCP Extensions TLV (<xref
          target="fig-supported"></xref>) target="fig-supported"
          format="default"/>) is used by a Transport Converter to announce the
          TCP options for which it provides a conversion service.  A Transport
          Converter SHOULD <bcp14>SHOULD</bcp14> include in this list the TCP options
          that it supports in outgoing SYNs.</t>
          <t>Each supported TCP option is encoded with its TCP option Kind
          listed in the "TCP "Transmission Control Protocol (TCP) Parameters"
          registry maintained by IANA. IANA <xref target="IANA-CONVERT"/>. The Unassigned field MUST
          <bcp14>MUST</bcp14> be set to zero by the Transport Converter and
          ignored by the Client.</t>
          <figure anchor="fig-supported"
                  title="The anchor="fig-supported">
            <name>The Supported TCP Extensions TLV">
            <artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                      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
 +---------------+---------------+-------------------------------+
 |     Type=0x15 |     Length    |           Unassigned          |
 +---------------+---------------+-------------------------------+
 |     Kind #1   |     Kind #2   |           ...                 |
 +---------------+---------------+-------------------------------+
 /                              ...                              /
 /                                                               /
 +---------------------------------------------------------------+
]]></artwork>
          </figure>
          <t>TCP option Kinds 1 and 2 defined in <xref
          target="RFC0793"></xref> target="RFC0793"
          format="default"/> are supported by all TCP implementations and thus MUST NOT
          thus, <bcp14>MUST NOT</bcp14> appear in this list.</t>
          <t>The list of Supported TCP Extensions is padded with 0 to end on a
          32 bits
          32-bit boundary.</t>
          <t>For example, if the Transport Converter supports Multipath TCP,
          Kind=30 will be present in the Supported TCP Extensions TLV that it
          returns in response to the Info TLV.</t>
        </section>
        <section anchor="sec-connect" title="Connect TLV"> numbered="true" toc="default">
          <name>Connect TLV</name>
          <t>The Connect TLV (<xref target="fig-connect"></xref>) target="fig-connect" format="default"/>) is used to
          request the establishment of a connection via a Transport Converter.
          This connection can be from or to a Client.</t>
          <t>The 'Remote Remote Peer Port' Port and 'Remote Remote Peer IP Address' Address fields
          contain the destination port number and IP address of the Server,
          for outgoing connections. For incoming connections destined to a
          Client serviced via a Transport Converter, these fields convey the
          source port number and IP address of the SYN packet received by the
          Transport Converter from the server.</t> Server.</t>

          <t>The Remote Peer IP Address MUST <bcp14>MUST</bcp14> be encoded as an
          IPv6 address.  IPv4 addresses MUST <bcp14>MUST</bcp14> be encoded using
          the IPv4-Mapped IPv4-mapped IPv6 Address address format defined in <xref target="RFC4291"></xref>.
          target="RFC4291" format="default"/>. Further, the Remote Peer IP address
          Address field MUST NOT <bcp14>MUST NOT</bcp14> include multicast, broadcast, and
          or host loopback addresses <xref target="RFC6890"></xref>. target="RFC6890"
          format="default"/>. If a Converter receives a Connect TLVs TLV with such
          invalid addresses, it
          MUST <bcp14>MUST</bcp14> reply with a Malformed
          Message Error TLV and close the associated TCP connection.</t>
          <t>We distinguish two types of Connect TLV based on their length:
          (1) the Base Connect TLV has a length set to 5 (i.e., 20 bytes) and
          contains a remote address and a remote port (<xref
          target="fig-connect"></xref>),
	  target="fig-connect" format="default"/>), and (2) the Extended Connect TLV spans
          more than 20 bytes and also includes the optional 'TCP Options' TCP Options
          field (<xref target="fig-econnect"></xref>). target="fig-econnect" format="default"/>). This field is used to
          request the advertisement of specific TCP options to the server.</t> Server.</t>
          <figure anchor="fig-connect" title="The anchor="fig-connect">
            <name>The Base Connect TLV">
            <artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                      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
 +---------------+---------------+-------------------------------+
 |     Type=0xA  |     Length    |      Remote Peer Port         |
 +---------------+---------------+-------------------------------+
 |                                                               |
 |         Remote Peer IP Address (128 bits)                     |
 |                                                               |
 |                                                               |
 +---------------------------------------------------------------+
]]></artwork>
          </figure>
          <figure anchor="fig-econnect" title="The anchor="fig-econnect">
            <name>The Extended Connect TLV">
            <artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                      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
 +---------------+---------------+-------------------------------+
 |     Type=0xA  |     Length    |      Remote Peer Port         |
 +---------------+---------------+-------------------------------+
 |                                                               |
 |         Remote Peer IP Address (128 bits)                     |
 |                                                               |
 |                                                               |
 +---------------------------------------------------------------+
 /                          TCP Options (Variable)               /
 /                              ...                              /
 +---------------------------------------------------------------+
]]></artwork>
          </figure>
          <t>The 'TCP Options' TCP Options field is a variable length field that carries a
          list of TCP option fields (<xref target="fig-tcpopt"></xref>). target="fig-tcpopt"
          format="default"/>). Each TCP option field is encoded as a block of
          2+n bytes where the first byte is the TCP option Kind and the second
          byte is the length of the TCP option as specified in <xref target="RFC0793"></xref>.
          target="RFC0793" format="default"/>. The minimum value for the TCP
          option Length is 2. The TCP options that do not include a length
          sub-field, i.e., option types 0 (EOL) and 1 (NOP) defined in <xref target="RFC0793"></xref> MUST NOT
          target="RFC0793" format="default"/> <bcp14>MUST NOT</bcp14> be
          placed inside the TCP options field of the Connect TLV. The optional
          Value field contains the variable-length part of the TCP option. A
          length of two 2 indicates the absence of the Value field. The TCP
          options field always ends on a 32 bits 32-bit boundary after being padded
          with zeros.</t>
          <figure anchor="fig-tcpopt" title="The anchor="fig-tcpopt">
            <name>The TCP Options Field">
            <artwork><![CDATA[ Field</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                     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
 +---------------+---------------+---------------+---------------+
 |  TCPOpt kind  | TCPOpt Length | Value  (opt)  |  ....         |
 +---------------+---------------+---------------+---------------+
 |                             ....                              |
 +---------------------------------------------------------------+
 |                              ...                              |
 +---------------------------------------------------------------+
]]></artwork>
          </figure>
          <t>Upon reception of a Base Connect TLV, and absent any policy
          (e.g., rate-limit) or resource exhaustion conditions, a Transport
          Converter attempts to establish a connection to the address and port
          that it contains. The Transport Converter MUST <bcp14>MUST</bcp14> use by default the
          TCP options that correspond to its local policy to establish this
          connection. </t>
          <t>Upon reception of an Extended Connect TLV, a Transport Converter
          first checks whether or not it supports the TCP Options listed in the 'TCP
          Options' TCP
          Options field. If not, it returns an error TLV set to "Unsupported
          TCP Option" (<xref target="sec-error"></xref>). target="sec-error" format="default"/>). If the above check
          succeeded
          succeeded, and absent any rate limit rate-limit policy or resource exhaustion
          conditions, a Transport Converter MUST <bcp14>MUST</bcp14> attempt to establish a
          connection to the address and port that it contains. It MUST <bcp14>MUST</bcp14> include
          in the SYN that it sends to the Server the options listed in the
          'TCP Options' sub-field
          TCP Options subfield and the TCP options that it would have used
          according to its local policies. For the TCP options that are
          included in the TCP Options field without an optional value, the
          Transport Converter MUST <bcp14>MUST</bcp14> generate its own value. For the TCP options
          that are included in the 'TCP Options' TCP Options field with an optional value,
          it MUST <bcp14>MUST</bcp14> copy the entire option in the SYN sent to the remote server. Server.
          This procedure is designed with TFO in mind. Particularly, this
          procedure allows to successfully exchange a TFO Fast Open Cookie between the
          client
          Client and the server. Server. See <xref target="sec-tcpoptions"></xref> target="sec-tcpoptions" format="default"/> for
          a detailed discussion of the different types of TCP options.</t>
          <t>The Transport Converter may refuse a Connect TLV request for
          various reasons (e.g., authorization failed, out of resources,
          invalid address type, or unsupported TCP option). An error message
          indicating the encountered error is returned to the requesting
          Client (<xref target="sec-error"></xref>). target="sec-error" format="default"/>). In order to prevent
          denial-of-service attacks, error messages sent to a Client SHOULD <bcp14>SHOULD</bcp14> be
          rate-limited.</t>
        </section>
        <section anchor="sec-ext-header" title="Extended numbered="true" toc="default">
          <name>Extended TCP Header TLV"> TLV</name>
          <t>The Extended TCP Header TLV (<xref
          target="fig-tcpheader"></xref>) target="fig-tcpheader"
          format="default"/>) is used by the Transport Converter to return to
          the Client the TCP options that were returned by the Server in the
          SYN+ACK packet. A Transport Converter MUST <bcp14>MUST</bcp14> return
          this TLV if the Client sent an Extended Connect TLV and the
          connection was accepted by the server. Server. </t>
          <figure anchor="fig-tcpheader" title="The anchor="fig-tcpheader">
            <name>The Extended TCP Header TLV">
            <artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                      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
 +---------------+---------------+-------------------------------+
 |     Type=0x14 |     Length    |           Unassigned          |
 +---------------+---------------+-------------------------------+
 /               Returned Extended TCP header                    /
 /                              ...                              /
 +---------------------------------------------------------------+
]]></artwork>
          </figure>
          <t>The Returned Extended TCP header field is a copy of the TCP
          Options that were included in the SYN+ACK received by the Transport
          Converter.</t>
          <t>The Unassigned field MUST <bcp14>MUST</bcp14> be set to zero by the sender and
          ignored by the receiver.</t>
        </section>
        <section anchor="sec-cookie-tlv" title="The numbered="true" toc="default">
          <name>The Cookie TLV"> TLV</name>
          <t>The Cookie TLV (<xref target="fig-cookie"></xref>) target="fig-cookie" format="default"/>) is
          an optional TLV which that is similar to the TCP Fast Open Cookie <xref
          target="RFC7413"></xref>.
          target="RFC7413" format="default"/>. A Transport Converter may want
          to verify that a Client can receive the packets that it sends to
          prevent attacks from spoofed addresses. This verification can be
          done by using a Cookie that is bound to, for example, the IP
          address(es) of the Client. This Cookie can be configured on the
          Client by means that are outside of this document or provided by the
          Transport Converter.</t>
          <t>A Transport Converter that has been configured to use the
          optional Cookie TLV MUST <bcp14>MUST</bcp14> verify the presence of this
          TLV in the payload of the received SYN. If this TLV is present, the
          Transport Converter MUST <bcp14>MUST</bcp14> validate the Cookie by means
          similar to those in
          Section 4.1.2 of <xref target="RFC7413"></xref> target="RFC7413" sectionFormat="of"
          section="4.1.2"/> (i.e., IsCookieValid). If the Cookie is valid, the
          connection establishment procedure can continue. Otherwise, the
          Transport Converter MUST <bcp14>MUST</bcp14> return an Error TLV set to
          "Not Authorized" and close the connection.</t>
          <t>If the received SYN did not contain a Cookie TLV, and cookie
          validation is required, the Transport Converter MAY <bcp14>MAY</bcp14> compute a Cookie
          bound to this Client address. In such case, the Transport Converter
          MUST
          <bcp14>MUST</bcp14> return an Error TLV set to "Missing Cookie" and the computed
          Cookie and close the connection. The Client will react to this error
          by first issuing a reset to terminate the connection. It also stores
          the received Cookie in its cache and attempts to reestablish a new
          connection to the Transport Converter that includes the Cookie
          TLV.</t>
          <t>The format of the Cookie TLV is shown in <xref
          target="fig-cookie"></xref>.</t> target="fig-cookie" format="default"/>.</t>
          <figure anchor="fig-cookie" title="The anchor="fig-cookie">
            <name>The Cookie TLV">
            <artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                      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
 +---------------+---------------+-------------------------------+
 |     Type=0x16 |     Length    |             Zero              |
 +---------------+---------------+-------------------------------+
 /                        Opaque  Cookie                         /
 /                              ...                              /
 +---------------------------------------------------------------+
]]></artwork>
          </figure>
        </section>
        <section anchor="sec-error" title="Error TLV"> numbered="true" toc="default">
          <name>Error TLV</name>
          <t>The Error TLV (<xref target="fig-error"></xref>) target="fig-error" format="default"/>) is meant to
          provide information about some errors that occurred during the
          processing of a Convert message. This TLV has a variable length.
          Upon reception of an Error TLV, a Client MUST <bcp14>MUST</bcp14> reset the associated
          connection.</t>
          <t>An Error TLV can be included in the SYN+ACK or an ACK.</t>
          <figure anchor="fig-error" title="The anchor="fig-error">
            <name>The Error TLV">
            <artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                      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
 +---------------+---------------+----------------+--------------+
 |     Type=0x1E |     Length    |    Error Code  |  Value       |
 +---------------+---------------+----------------+--------------+
 //              ...   (optional) Value                         //
 +---------------------------------------------------------------+
]]></artwork>
          </figure>

          <t>Different types of errors can occur while processing Convert
          messages. Each error is identified by an Error Code represented as
          an unsigned integer. Four classes of error codes are defined:</t>

          <t><list style="symbols">
              <t>Message
	  <dl newline="true">
            <dt>Message validation and processing errors (0-31 range):
              returned range):</dt>
              <dd>Returned upon reception of an invalid message (including valid
              messages but with invalid or unknown TLVs).</t>

              <t>Client-side TLVs).</dd>
            <dt>Client-side errors (32-63 range): the range):</dt><dd>The Client sent a request
              that could not be accepted by the Transport Converter (e.g.,
              unsupported operation).</t>

              <t>Converter-side operation).</dd>
            <dt>Converter-side errors (64-95 range): problems range):</dt><dd> Problems encountered on
              the Transport Converter (e.g., lack of resources) which that prevent
              it from fulfilling the Client's request.</t>

              <t>Errors request.</dd>
            <dt>Errors caused by the destination server Server (96-127 range): the range):</dt><dd>The
              final destination could not be reached or it replied with a
              reset.</t>
            </list></t>
              reset.</dd>
          </dl>
          <t>The following error codes are defined in this document:</t>

          <t><list style="symbols">
              <t>Unsupported
          <dl spacing="normal" newline="true">
            <dt>Unsupported Version (0): The (0):</dt><dd><t>The version number indicated in the
              fixed header of a message received from a peer is not supported.
              <vspace blankLines="1" />
              </t>
              <t> This error code MUST <bcp14>MUST</bcp14> be generated by a
              peer (e.g. (e.g., Transport Converter) when it receives a request
              having a version number that it does not support. <vspace
              blankLines="1" /> </t>
              <t> The value Value field MUST <bcp14>MUST</bcp14> be set to the version
              supported by the peer. When multiple versions are supported by
              the peer, it includes the list of supported version versions in the value Value
              field; each version is encoded in 8 bits. The list of supported
              versions MUST <bcp14>MUST</bcp14> be padded with zeros to end on a 32 bits 32-bit boundary.
              <vspace blankLines="1" />
              </t>
              <t> Upon receipt of this error code, the
              remote peer (e.g., Client) checks whether it supports one of the
              versions returned by the peer.

The highest common commonly supported version MUST number <bcp14>MUST</bcp14> be used by the remote
peer in subsequent exchanges with the peer.</t>

              <t>Malformed
            </dd>
            <dt>Malformed Message (1): This (1):</dt><dd><t>This error code is sent to
            indicate that a message received from a peer cannot be
            successfully parsed and validated. <vspace blankLines="1" /> </t>
              <t> Typically, this error code is sent by the Transport
              Converter if it receives a Connect TLV enclosing a multicast,
              broadcast, or loopback IP address. <vspace blankLines="1" /> </t>
              <t> To ease troubleshooting, the
              value Value field MUST <bcp14>MUST</bcp14>
              echo the received message using the format depicted in <xref target="shift"></xref>.
              target="shift" format="default"/>. This format allows to
              keep keeping
              the original alignment of the message that triggered the
              error. </t>
              <figure anchor="shift"
                  title="Error anchor="shift">
                <name>Error TLV to ease Ease Message Correlation">
                  <artwork><![CDATA[ Correlation</name>
                <artwork name="" type="" align="left" alt=""><![CDATA[
                      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
 +---------------+---------------+----------------+--------------+
 |     Type=0x1E |     Length    |    Error Code  |  Zeros       |
 +---------------+---------------+----------------+--------------+
 //        Echo the message which that triggered the error            //
 +---------------------------------------------------------------+
]]></artwork>
                </figure></t>

              <t>Unsupported
              </figure>
	    </dd>
            <dt>Unsupported Message (2): This (2):</dt><dd><t>This error code is sent to indicate
              that a message type received from a Client is not supported.
              <vspace blankLines="1" /> supported.</t>
              <t> To ease troubleshooting, the value Value field MUST <bcp14>MUST</bcp14>
              echo the received message using the format shown in <xref target="shift"></xref>.</t>

              <t>Missing
              target="shift" format="default"/>.</t>
            </dd>

            <dt>Missing Cookie (3): If (3):</dt><dd><t>If a Transport Converter requires the
              utilization of Cookies to prevent spoofing attacks and a Cookie
              TLV was not included in the Convert message, the Transport
              Converter MUST <bcp14>MUST</bcp14> return this error to the requesting client Client only
              if it computes a cookie for this client. Client. The first byte of the
              value
              Value field MUST <bcp14>MUST</bcp14> be set to zero and the remaining bytes of the
              Error TLV contain the Cookie computed by the Transport Converter
              for this Client. <vspace blankLines="1" /> </t>
              <t> A Client which that receives this error code SHOULD
              <bcp14>SHOULD</bcp14> cache the received Cookie and include it
              in subsequent Convert messages sent to that Transport
              Converter.</t>

              <t>Not
            </dd>
            <dt>Not Authorized (32): This (32):</dt><dd><t>This error code indicates that the
              Transport Converter refused to create a connection because of a
              lack of authorization (e.g., administratively prohibited,
              authorization failure, or invalid Cookie TLV). The Value field MUST <bcp14>MUST</bcp14>
              be set to zero. <vspace blankLines="1" /> </t>
              <t> This error code MUST <bcp14>MUST</bcp14>
              be sent by the Transport Converter when a request cannot be
              successfully processed because the authorization failed.</t>

              <t>Unsupported
            </dd>
            <dt>Unsupported TCP Option (33): A (33):</dt><dd><t>A TCP option that the Client
              requested to advertise to the final Server cannot be safely
              used. <vspace blankLines="1" /> </t>
              <t> The Value field is set to the
              type of the unsupported TCP option. If several unsupported TCP
              options were specified in the Connect TLV, then the list of
              unsupported TCP options is returned. The list of unsupported TCP
              options MUST <bcp14>MUST</bcp14> be padded with zeros to end on a 32 bits 32-bit
              boundary.</t>

              <t>Resource
            </dd>
            <dt>Resource Exceeded (64): This (64):</dt><dd><t>This error indicates that the
              Transport Converter does not have enough resources to perform
              the request. <vspace blankLines="1" /> </t>
              <t> This error MUST <bcp14>MUST</bcp14> be sent
              by the Transport Converter when it does not have sufficient
              resources to handle a new connection. The Transport Converter
              may indicate in the Value field the suggested delay (in seconds)
              that the Client SHOULD <bcp14>SHOULD</bcp14> wait before soliciting the Transport
              Converter for a new proxied connection. A Value of zero
              corresponds to a default delay of at least 30 seconds.</t>

              <t>Network
            </dd>
            <dt>Network Failure (65): This (65):</dt><dd><t>This error indicates that the Transport
              Converter is experiencing a network failure to proxy the
              request. <vspace blankLines="1" /> </t>
              <t> The Transport Converter MUST <bcp14>MUST</bcp14>
              send this error code when it experiences forwarding issues to
              proxy a connection. The Transport Converter may indicate in the
              Value field the suggested delay (in seconds) that the Client
              SHOULD
              <bcp14>SHOULD</bcp14> wait before soliciting the Transport Converter for a new
              proxied connection. A Value of zero corresponds to a default
              delay of at least 30 seconds.</t>

              <t>Connection
            </dd>
            <dt>Connection Reset (96): This (96):</dt><dd>This error indicates that the final
              destination responded with an RST segment. The Value field MUST <bcp14>MUST</bcp14>
              be set to zero.</t>

              <t>Destination zero.</dd>
            <dt>Destination Unreachable (97): This (97):</dt><dd><t>This error indicates that an
              ICMP message indicating a hard error (e.g., destination
              unreachable, port unreachable, or network unreachable) was
              received by the Transport Converter. The Value field MUST <bcp14>MUST</bcp14> echo
              the Code field of the received ICMP message. <vspace
              blankLines="1" />As </t>
              <t>As a reminder, TCP implementations are supposed
              to act on an ICMP error message passed up from the IP layer,
              directing it to the connection that triggered the error using
              the demultiplexing information included in the payload of that
              ICMP message. Such a demultiplexing issue does not apply for
              handling the "Destination Unreachable" Error TLV because the
              error is sent in-band. For this reason, the payload of the ICMP
              message is not echoed in the Destination Unreachable Error
              TLV.</t>
            </list></t>
            </dd>
          </dl>
          <t><xref target="tab-error-types"></xref> target="tab-error-types" format="default"/> summarizes the different
          error codes.</t>

          <figure anchor="tab-error-types" title="Convert Error Values">
            <artwork><![CDATA[
 +-------+------+-----------------------------------------------+
 |

<table anchor="tab-error-types">
  <name>Convert Error | Hex  | Description                                   |
 +-------+------+-----------------------------------------------+
 |    0  | 0x00 | Unsupported Version                           |
 |    1  | 0x01 | Malformed Message                             |
 |    2  | 0x02 | Unsupported Message                           |
 |    3  | 0x03 | Missing Cookie                                |
 |   32  | 0x20 | Not Authorized                                |
 |   33  | 0x21 | Unsupported TCP Option                        |
 |   64  | 0x40 | Resource Exceeded                             |
 |   65  | 0x41 | Network Failure                               |
 |   96  | 0x60 | Connection Reset                              |
 |   97  | 0x61 | Destination Unreachable                       |
 +-------+------+-----------------------------------------------+
]]></artwork>
          </figure> Values</name>
  <thead>
    <tr>
      <th>Error</th>
      <th>Hex</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>0x00</td>
      <td>Unsupported Version</td>
    </tr>
    <tr>
      <td>1</td>
      <td>0x01</td>
      <td>Malformed Message</td>
    </tr>
    <tr>
      <td>2</td>
      <td>0x02</td>
      <td>Unsupported Message</td>
    </tr>
    <tr>
      <td>3</td>
      <td>0x03</td>
      <td>Missing Cookie</td>
    </tr>
    <tr>
      <td>32</td>
      <td>0x20</td>
      <td>Not Authorized</td>
    </tr>
    <tr>
      <td>33</td>
      <td>0x21</td>
      <td>Unsupported TCP Option</td>
    </tr>
    <tr>
      <td>64</td>
      <td>0x40</td>
      <td>Resource Exceeded</td>
    </tr>
    <tr>
      <td>65</td>
      <td>0x41</td>
      <td>Network Failure</td>
    </tr>
    <tr>
      <td>96</td>
      <td>0x60</td>
      <td>Connection Reset</td>
    </tr>
    <tr>
      <td>97</td>
      <td>0x61</td>
      <td>Destination Unreachable</td>
    </tr>
  </tbody>
</table>

        </section>
      </section>
    </section>

    <section anchor="sec-tcpoptions"
             title="Compatibility numbered="true" toc="default">
      <name>Compatibility of Specific TCP Options with the Conversion Service"> Service</name>
      <t>In this section, we discuss how several deployed standard track Standards Track TCP
      options can be supported through the Convert Protocol. The other TCP
      options will be discussed in other documents.</t>
      <section anchor="base-tcp-options" title="Base numbered="true" toc="default">
        <name>Base TCP Options"> Options</name>
        <t>Three TCP options were initially defined in <xref
        target="RFC0793"></xref>: target="RFC0793"
        format="default"/>: End-of-Option List (Kind=0), No-Operation
        (Kind=1) (Kind=1),
        and Maximum Segment Size (Kind=2). The first two options are mainly
        used to pad the TCP header. There is no reason for a client Client to request
        a Transport Converter to specifically send these options towards the
        final destination.</t>
        <t>The Maximum Segment Size option (Kind=2) is used by a host to
        indicate the largest segment that it can receive over each connection.
        This value is a function of the stack that terminates the TCP
        connection. There is no reason for a Client to request a Transport
        Converter to advertise a specific MSS Maximum Segment Size (MSS) value to a remote server.</t> Server.</t>
        <t>A Transport Converter MUST <bcp14>MUST</bcp14> ignore options with Kind=0, 1 1, or 2 if
        they appear in a Connect TLV. It MUST NOT <bcp14>MUST NOT</bcp14> announce them in a Supported
        TCP Extensions TLV.</t>
      </section>

      <section anchor="window-scale-ws" title="Window numbered="true" toc="default">
        <name>Window Scale (WS)"> (WS)</name>
        <t>The Window Scale (WS) option (Kind=3) is defined in <xref
        target="RFC7323"></xref>.
        target="RFC7323" format="default"/>. As for the MSS option, the window
        scale factor that is used for a connection strongly depends on the TCP
        stack that handles the connection. When a Transport Converter opens a
        TCP connection towards a remote server Server on behalf of a Client, it SHOULD
        <bcp14>SHOULD</bcp14> use a WS option with a scaling factor that
        corresponds to the configuration of its stack. A local configuration MAY
        <bcp14>MAY</bcp14> allow for a WS option in the proxied message to be
        a function of the scaling factor of the incoming connection.</t>

        <t>There
        <t>From a deployment viewpoint, there is no benefit from a deployment viewpoint in enabling a
        Client of a Transport Converter to specifically request the
        utilization of the WS option (Kind=3) with a specific scaling factor
        towards a remote Server. For this reason, a Transport Converter MUST <bcp14>MUST</bcp14>
        ignore option Kind=3 if it appears in a Connect TLV. It MUST NOT

The Transport Converter <bcp14>MUST NOT</bcp14> announce it a WS option (Kind=3)
in a Supported TCP Extensions TLV.</t> TLV.
</t>
      </section>

      <section anchor="selective-acknowledgments"
               title="Selective Acknowledgments"> numbered="true" toc="default">
        <name>Selective Acknowledgments</name>
        <t>Two distinct TCP options were defined to support selective
        acknowledgments Selective
        Acknowledgment (SACK) in <xref target="RFC2018"></xref>. target="RFC2018" format="default"/>. This first one,
        SACK Permitted
        SACK-Permitted (Kind=4), is used to negotiate the utilization of
        selective acknowledgments
        Selective Acknowledgments during the three-way handshake. The second
        one, SACK (Kind=5), carries the selective acknowledgments Selective Acknowledgments inside
        regular segments.</t>
        <t>The SACK Permitted SACK-Permitted option (Kind=4) MAY <bcp14>MAY</bcp14> be advertised by a Transport
        Converter in the Supported TCP Extensions TLV. Clients connected to
        this Transport Converter MAY <bcp14>MAY</bcp14> include the SACK Permitted SACK-Permitted option in the
        Connect TLV.</t>
        <t>The SACK option (Kind=5) cannot be used during the three-way
        handshake. For this reason, a Transport Converter MUST <bcp14>MUST</bcp14> ignore option
        Kind=5 if it appears in a Connect TLV. It MUST NOT <bcp14>MUST NOT</bcp14> announce it in a
        TCP Supported Extensions TLV.</t>
      </section>
      <section anchor="timestamp" title="Timestamp"> numbered="true" toc="default">
        <name>Timestamp</name>
        <t>The Timestamp option <xref target="RFC7323"></xref> target="RFC7323" format="default"/> can be used
        during the three-way handshake to negotiate the utilization of
        timestamps during the TCP connection. It is notably used to improve
        round-trip-time estimations and to provide protection against wrapped
        sequence numbers Protection Against Wrapped
        Sequences (PAWS). As for the WS option, the timestamps are a
        property of a connection and there is limited benefit in enabling a
        client
        Client to request a Transport Converter to use the timestamp option
        when establishing a connection to a remote server. Server. Furthermore, the
        timestamps that are used by TCP stacks are specific to each stack and
        there is no benefit in enabling a client Client to specify the timestamp
        value that a Transport Converter could use to establish a connection
        to a remote server.</t> Server.</t>
        <t>A Transport Converter MAY <bcp14>MAY</bcp14> advertise the Timestamp option (Kind=8)
        in the TCP Supported Extensions TLV. The clients Clients connected to this
        Transport Converter MAY <bcp14>MAY</bcp14> include the Timestamp option in the Connect
        TLV but without any timestamp.</t>
      </section>
      <section anchor="multipath-tcp" title="Multipath TCP"> numbered="true" toc="default">
        <name>Multipath TCP</name>
        <t>The Multipath TCP options are defined in <xref
        target="RFC6824"></xref>. <xref target="RFC6824"></xref> target="RFC8684"
	format="default"/>, which defines one
        variable length TCP option (Kind=30) that includes a sub-type field to
        support several Multipath TCP options. There are several operational
        use cases where clients Clients would like to use Multipath TCP through a
        Transport Converter <xref target="IETFJ16"></xref>. target="IETFJ16" format="default"/>. However, none of
        these use cases require the Client to specify the content of the
        Multipath TCP option that the Transport Converter should send to a
        remote server.</t> Server.</t>
        <t>A Transport Converter which that supports Multipath TCP conversion
        service MUST <bcp14>MUST</bcp14> advertise the Multipath TCP option (Kind=30) in the
        Supported TCP Extensions TLV. Clients serviced by this Transport
        Converter may include the Multipath TCP option in the Connect TLV but
        without any content.</t>
      </section>
      <section anchor="tcp-fast-open" title="TCP numbered="true" toc="default">
        <name>TCP Fast Open"> Open</name>
        <t>The TCP Fast Open cookie Cookie option (Kind=34) is defined in <xref
        target="RFC7413"></xref>. target="RFC7413" format="default"/>. There are two different usages of this
        option that need to be supported by Transport Converters. The first
        utilization of the TCP Fast Open cookie Cookie option is to request a cookie
        from the server. Server. In this case, the option is sent with an empty cookie
        by the client Client, and the server Server returns the cookie. The second
        utilization of the TCP Fast Open cookie Cookie option is to send a cookie to
        the server. Server. In this case, the option contains a cookie.</t>
        <t>A Transport Converter MAY <bcp14>MAY</bcp14> advertise the TCP Fast Open cookie Cookie option
        (Kind=34) in the Supported TCP Extensions TLV. If a Transport
        Converter has advertised the support for TCP Fast Open in its
        Supported TCP Extensions TLV, it needs to be able to process two types
        of Connect TLV.</t>
        <t>If such a Transport Converter receives a Connect TLV with the TCP
        Fast Open cookie Cookie option that does not contain a cookie, it MUST
        <bcp14>MUST</bcp14> add an empty TCP Fast Open cookie Cookie option in the
        SYN sent to the remote
        server. Server. If the remote server Server supports TFO, it
        responds with a SYN-ACK according to the procedure in Section 4.1.2 of <xref
        target="RFC7413"></xref>.
        target="RFC7413" sectionFormat="of" section="4.1.2"/>. This SYN-ACK
        may contain a Fast Open option with a cookie. Upon receipt of the
        SYN-ACK by the Converter, it relays the Fast Open option with the cookie
        to the Client.</t>
        <t>If such a Transport Converter receives a Connect TLV with the TCP
        Fast Open cookie Cookie option that contains a cookie, it MUST <bcp14>MUST</bcp14> copy the TCP
        Fast Open cookie Cookie option in the SYN sent to the remote server.</t> Server.</t>
      </section>
      <section anchor="tcp-ao" title="TCP-AO">
        <t>TCP-AO numbered="true" toc="default">
        <name>TCP-AO</name>
        <t>The TCP Authentication Option (TCP-AO) <xref target="RFC5925"></xref> target="RFC5925"
        format="default"/> provides a technique to authenticate all the
        packets exchanged over a TCP connection. Given the nature of this
        extension, it is unlikely that the applications that require their
        packets to be authenticated end-to-end end to end would want their connections to
        pass through a converter. For this reason, we do not recommend the
        support of the TCP-AO option by Transport Converters. The only use
        cases where it could make sense to combine TCP-AO and the solution in
        this document are those where the TCP-AO-NAT extension <xref target="RFC6978"></xref>
        target="RFC6978" format="default"/> is in use.</t>
        <t>A Transport Converter MUST NOT <bcp14>MUST NOT</bcp14> advertise the TCP-AO option
        (Kind=29) in the Supported TCP Extensions TLV. If a Transport
        Converter receives a Connect TLV that contains the TCP-AO option, TCP-AO, it
        MUST
        <bcp14>MUST</bcp14> reject the establishment of the connection with
        error code set to "Unsupported TCP Option", except if the TCP-AO-NAT
        option is used.  Nevertheless, given that TCP-AO-NAT is Experimental,
        its usage is not currently defined and must be specified by some other
        document before it can be used.</t>
      </section>
    </section>
    <section anchor="sec-middleboxes" title="Interactions numbered="true" toc="default">
      <name>Interactions with Middleboxes"> Middleboxes</name>
      <t>The Convert Protocol is designed to be used in networks that do not
      contain middleboxes that interfere with TCP. Under such conditions, it
      is assumed that the network provider ensures that all involved on-path
      nodes are not breaking TCP signals (e.g., strip TCP options, discard
      some SYNs, etc.).</t>
      <t>Nevertheless, and in order to allow for a robust service, this
      section describes how a Client can detect middlebox interference and
      stop using the Transport Converter affected by this interference.</t>
      <t>Internet measurements <xref target="IMC11"></xref> target="IMC11" format="default"/> have shown that
      middleboxes can affect the deployment of TCP extensions. In this
      section, we focus the middleboxes that modify the payload since the
      Convert Protocol places its messages at the beginning of the
      bytestream.</t>
      <t>Consider a middlebox that removes the SYN payload. The Client can
      detect this problem by looking at the acknowledgment number field of the
      SYN+ACK if returned by the Transport Converter. The Client MUST <bcp14>MUST</bcp14> stop to
      use this Transport Converter given the middlebox interference.</t>
      <t>Consider now a middlebox that drops SYN/ACKs with a payload. The
      Client won't be able to establish a connection via the Transport
      Converter. The case of a middlebox that removes the payload of SYN+ACKs
      or from the packet that follows the SYN+ACK (but not the payload of SYN)
      can be detected by a Client. This is hinted by the absence of a valid
      Convert message in the response.</t>
      <t>As explained in <xref target="RFC7413"></xref>, target="RFC7413" format="default"/>, some CGNs (Carrier
      Carrier Grade NATs) NATs (CGNs) can affect the operation of TFO if they assign
      different IP addresses to the same end host. Such CGNs could affect the
      operation of the cookie validation used by the Convert Protocol. As a reminder CGNs,
      enabled on
      reminder, CGNs that are enabled on the path between a Client and a Transport Converter,
      Converter must adhere to the address preservation defined in <xref
      target="RFC6888"></xref>.
      target="RFC6888" format="default"/>. See also the discussion in Section 7.1 of <xref target="RFC7413"></xref>.</t>
      target="RFC7413" sectionFormat="of" section="7.1"/>.</t>
    </section>
    <section anchor="sec-security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>An implementation MUST <bcp14>MUST</bcp14> check that the Convert TLVs are properly
      framed within the boundary indicated by the Total Length in the fixed
      header (<xref target="sec-header"></xref>).</t> target="sec-header" format="default"/>).</t>
      <t>Additional security considerations are discussed in the following
      sub-sections.</t>
      subsections.</t>
      <section anchor="privacy-ingress-filtering"
               title="Privacy numbered="true" toc="default">
        <name>Privacy &amp; Ingress Filtering"> Filtering</name>
        <t>The Transport Converter may have access to privacy-related
        information (e.g., subscriber credentials). The Transport Converter is
        designed to not leak such sensitive information outside a local
        domain.</t>
        <t>Given its function and location in the network, a Transport
        Converter is in a position to observe all packets that it processes,
        to include payloads and meta-data; metadata, and has the ability to profile and
        conduct some traffic analysis of user behavior. The Transport
        Converter MUST <bcp14>MUST</bcp14> be as protected as a core IP router
        (e.g., Section 10
        of <xref target="RFC1812"></xref>).</t> target="RFC1812" sectionFormat="of"
        section="10"/>).</t>

        <t>Furthermore, ingress filtering policies MUST <bcp14>MUST</bcp14> be enforced at the
        network boundaries <xref target="RFC2827"></xref>.</t> target="RFC2827" format="default"/>.</t>
        <t>This document assumes that all network attachments are managed by
        the same administrative entity. Therefore, enforcing anti-spoofing
        filters at these network networks is a guard that hosts are not sending traffic
        with spoofed source IP addresses.</t>
      </section>
      <section anchor="authorization"
               title="Authentication numbered="true" toc="default">
        <name>Authentication and Authorization Considerations"> Considerations</name>
        <t>The Convert Protocol is RECOMMENDED to be used <bcp14>RECOMMENDED</bcp14> for use in a managed network
        where end hosts can be securely identified by their IP address. If
        such control is not exerted and there is a more open network
        environment, a strong mutual authentication scheme MUST <bcp14>MUST</bcp14> be defined to
        use the Convert Protocol.</t>
        <t>One possibility for mutual authentication is to use TLS to perform
        mutual authentication between the client Client and the Converter. That is,
        use TLS when a Client retrieves a Cookie from the Converter and rely
        on certificate-based client authentication, certificate-based, pre-shared key based key-based <xref
        target="RFC4279"></xref>
        target="RFC4279" format="default"/>, or raw public key based client key-based Client
        authentication <xref target="RFC7250"></xref> target="RFC7250" format="default"/> to secure
        this connection. If the authentication succeeds, the Converter returns
        a cookie to the Client.  Subsequent Connect messages will be
        authorized as a function of the content of the Cookie TLV. An attacker
        from within the network between a Client and a Transport Converter may
        intercept the Cookie and use it to be granted access to the conversion
        service. Such an attack is only possible if the attacker spoofs the IP
        address of the Client and the network does not filter packets with source spoofed
        source-spoofed IP addresses. </t>
        <t>The operator that manages the various network attachments
        (including the Transport Converters) has various options for enforcing
        authentication and authorization policies. For example, a
        non-exhaustive list of methods to achieve authorization is provided
        hereafter:</t>

        <t><list style="symbols">
            <t>The
        <ul spacing="normal">
          <li>The network provider may enforce a policy based on the
            International Mobile Subscriber Identity (IMSI) to verify that a
            user is allowed to benefit from the TCP converter service. If that
            authorization fails, the Packet Data Protocol (PDP) context/bearer
            will not be mounted. This method does not require any interaction
            with the Transport Converter for authorization matters.</t>

            <t>The matters.</li>
          <li>The network provider may enforce a policy based upon Access
            Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG)
            to control the hosts that are authorized to communicate with a
            Transport Converter. These ACLs may be installed as a result of
            RADIUS exchanges, e.g., <xref
            target="I-D.boucadair-radext-tcpm-converter"></xref>. target="I-D.boucadair-opsawg-tcpm-converter" format="default"/>. This method
            does not require any interaction with the Transport Converter for
            authorization matters.</t>

            <t>A matters.</li>
          <li>A device that embeds a Transport Converter may also host a
          RADIUS client Client that will solicit an a AAA server Server to check whether or
          not connections received from a given source IP address are
          authorized
            or not <xref
            target="I-D.boucadair-radext-tcpm-converter"></xref>.</t>
          </list></t> target="I-D.boucadair-opsawg-tcpm-converter"
          format="default"/>.</li>
        </ul>
        <t>A first safeguard against the misuse of Transport Converter
        resources by illegitimate users (e.g., users with access networks that
        are not managed by the same provider that operates the Transport
        Converter) is the Transport Converter to reject Convert connections
        received in the external realm. Only Convert connections received in
        the internal realm of a Transport Converter will be accepted.</t>
        <t>In deployments where network-assisted connections are not allowed
        between hosts of a domain (i.e., hairpinning), the Converter may be
        instructed to discard such connections. Hairpinned connections are
        thus rejected by the Transport Converter by returning an Error TLV set
        to "Not Authorized". Absent Otherwise, absent explicit configuration otherwise, configuration,
        hairpinning is enabled by the Converter (see <xref
        target="fig-hairp"></xref>.</t> target="fig-hairp"
        format="default"/>).</t>
        <figure anchor="fig-hairp" title="Hairpinning Example">
          <artwork><![CDATA[ anchor="fig-hairp">
          <name>Hairpinning Example</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
          <===Network Provider===>

   +----+ from X1:x1 to X2':x2'   +-----+ X1':x1'
   | C1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---
   +----+                         |  v  |
                                  |  v  |
                                  |  v  |
                                  |  v  |
   +----+ from X1':x1' to X2:x2   |  v  | X2':x2'
   | C2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---
   +----+                         +-----+
                                 Converter

   Note: X2':x2' may be equal to
         X2:x2
]]></artwork>
        </figure>

        <t></t>

      </section>
      <section anchor="denial-of-service" title="Denial numbered="true" toc="default">
        <name>Denial of Service"> Service</name>
        <t>Another possible risk is the amplification attacks attacks, since a Transport
        Converter sends a SYN towards a remote Server upon reception of a SYN
        from a Client. This could lead to amplification attacks if the SYN
        sent by the Transport Converter were larger than the SYN received from
        the Client Client, or if the Transport Converter retransmits the SYN. To
        mitigate such attacks, the Transport Converter SHOULD rate
        limit <bcp14>SHOULD</bcp14>
        rate-limit the number of pending requests for a given Client. It SHOULD
        <bcp14>SHOULD</bcp14> also avoid sending to remote Servers SYNs that are significantly
        longer than the SYN received from the Client. Client, to remote
        Servers.  Finally, the Transport Converter SHOULD <bcp14>SHOULD</bcp14> only
        retransmit a SYN to a Server after having received a retransmitted SYN
        from the corresponding Client. Means to protect against SYN flooding
        attacks should also be enabled (e.g.,
        Section 3 of <xref target="RFC4987"></xref>).</t> target="RFC4987"
        sectionFormat="of" section="3"/>).</t>
        <t>Attacks from within the network between a Client and a Transport
        Converter (including attacks that change the protocol version) are yet
        another threat. Means to ensure that illegitimate nodes cannot connect
        to a network should be implemented.</t>
      </section>

      <section anchor="traffic-theft" title="Traffic Theft"> numbered="true" toc="default">
        <name>Traffic Theft</name>
        <t>Traffic theft is a risk if an illegitimate Converter is inserted in
        the path. Indeed, inserting an illegitimate Converter in the
        forwarding path allows traffic interception and can therefore provide
        access to sensitive data issued by or destined to a host. Converter
        discovery and configuration are out of scope of this document.</t>
      </section>
      <section title="Logging"> numbered="true" toc="default">
        <name>Logging</name>
        <t>If the Converter is configured to behave in the address sharing address-sharing
        mode (<xref target="sec-adds"></xref>), target="sec-adds" format="default"/>), the logging recommendations
        discussed in Section 4 of <xref target="RFC6888"></xref> target="RFC6888" sectionFormat="of" section="4"/> need to be
        considered. Security-related issues encountered in address sharing address-sharing
        environments are documented in Section 13 of <xref
        target="RFC6269"></xref>.</t> target="RFC6269"
	sectionFormat="of" section="13"/>.</t>
      </section>
    </section>
    <section anchor="sec-iana" title="IANA Considerations">
      <t>Note to the RFC Editor: Please replace "THISRFC" in the following
      sub-sections with the RFC number to be assigned to this document.</t> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section anchor="sec-service" title="Convert numbered="true" toc="default">
        <name>Convert Service Name"> Name</name>
	<t>IANA is requested to assign has assigned a
        service name for the Convert Protocol from the "Service Name and
        Transport Protocol Port Number Registry" available at
        https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.</t>

        <figure>
          <artwork><![CDATA[
   Service Name:           convert
   Port Number:            N/A
   Transport Protocol(s):  TCP
   Description:            0-RTT TCP Convert Protocol
   Assignee:               IESG <iesg@ietf.org>
   Contact:                IETF
        &lt;<eref target="https://www.iana.org/assignments/service-names-port-numbers"/>&gt;.</t>

	<dl spacing="compact" indent="25">
	  <dt>Service Name:</dt><dd>convert</dd>
	  <dt>Port Number:</dt><dd>N/A</dd>
	  <dt>Transport Protocol(s):</dt><dd>TCP</dd>
	  <dt>Description:</dt><dd>0-RTT TCP Convert Protocol</dd>
	  <dt>Assignee:</dt><dd>IESG &lt;iesg@ietf.org&gt;</dd>
	  <dt>Contact:</dt><dd>IETF Chair <chair@ietf.org>
   Reference:              THISRFC
]]></artwork>
        </figure> &lt;chair@ietf.org&gt;</dd>
	  <dt>Reference:</dt><dd>RFC 8803</dd>
	</dl>

        <t>Clients may use this service name to fed feed the procedure defined in
        <xref target="RFC2782"></xref> target="RFC2782" format="default"/> to discover the IP address(es) and the
        port number used by the Transport Converters of a domain.</t>
      </section>
      <section anchor="the-convert-protocol-convert-parameters"
               title="The numbered="true" toc="default">
        <name>The Convert Protocol (Convert) Parameters"> Parameters</name>
        <t>IANA is requested to create has created a new "The TCP "TCP Convert Protocol
        (Convert) Parameters" registry.</t>
        <t>The following subsections detail new registries within "The Convert the "Convert
        Protocol (Convert) Parameters" registry.</t>
        <t>The Designated Expert designated expert is expected to ascertain the existence of
        suitable documentation as described in Section 4.6 of <xref
        target="RFC8126"></xref>
	target="RFC8126" sectionFormat="of" section="4.6"/> and to verify that the document is
        permanently and publicly available. The Designated Expert designated expert is also
        expected to check the clarity of purpose and use of the requested code
        points.</t>
        <t>Also, criteria that should be applied by the Designated Experts designated experts
        includes determining whether the proposed registration
        duplicates existing functionality, whether it is likely to be of
        general applicability or whether it is useful only for a private use, and whether
        the registration description is clear.

All requests should be directed to the review mailing list.  For both the
"Convert TLVs" and "Convert Errors" subregistries, IANA must only accept
registry updates to in the 128-191 range (for both "Convert TLVs" and
        "Convert Error Messages" sub-registries) from the Designated Experts
        and should direct all requests for registration to the review mailing
        list. designated experts.  It is
suggested that multiple Designated Experts designated experts be appointed.

        In cases where a registration decision could be perceived as creating
        a conflict of interest for a particular Expert, expert, that Expert expert should
        defer to the judgment of the other Experts.</t> experts.</t>
        <section anchor="convert-versions" title="Convert Versions"> numbered="true" toc="default">
          <name>Convert Versions</name>
          <t>IANA is requested to create has created the "Convert versions" sub-registry. Versions" subregistry.
          New values are assigned via IETF Review (Section 4.8 of <xref
          target="RFC8126"></xref>).</t> (<xref target="RFC8126"
          sectionFormat="of" section="4.8"/>).</t>
          <t>The initial values to be assigned at the creation of the registry
          are as follows:</t>

          <figure anchor="ver" title="Current Convert Versions">
            <artwork><![CDATA[ +---------+--------------------------------------+-------------+
 | Version | Description                          | Reference   |
 +---------+--------------------------------------+-------------+
 |    0    | Reserved                             |  THISRFC    |
 |    1    | Assigned                             |  THISRFC    |
 +---------+--------------------------------------+-------------+
]]></artwork>
          </figure>

	  <table anchor="ver">
            <name>Current Convert Versions</name>
	    <thead>
    <tr>
      <th>Version</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Reserved</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Assigned</td>
      <td>RFC 8803</td>
    </tr>
  </tbody>
</table>

        </section>
        <section anchor="convert-tlvs" title="Convert TLVs"> numbered="true" toc="default">
          <name>Convert TLVs</name>
          <t>IANA is requested to create has created the "Convert TLVs" sub-registry. subregistry. The
          procedure
          procedures for assigning values from this registry is are as follows:</t>

          <t><list style="symbols">
              <t>The values in the range 1-127 can be assigned via IETF
              Review.</t>

              <t>The values in the range 128-191 can be assigned via
              Specification Required.</t>

              <t>The values in the range 192-255 are reserved for Private
              Use.</t>
            </list></t>
	  <dl indent="10">
	    <dt>1-127:</dt><dd>IETF Review</dd>
            <dt>128-191:</dt><dd>Specification Required</dd>
            <dt>192-255:</dt><dd>Private Use</dd>
          </dl>
          <t>The initial values to be assigned at the creation of the registry
          are as follows:</t>

          <figure anchor="tlvs" title="Initial Convert TLVs">
            <artwork><![CDATA[
 +---------+--------------------------------------+-------------+
 |  Code   | Name                                 | Reference   |
 +---------+--------------------------------------+-------------+
 |    0    | Reserved                             |   THISRFC   |
 |    1    | Info TLV                             |   THISRFC   |
 |   10    | Connect TLV                          |   THISRFC   |
 |   20    | Extended

<table anchor="tlvs">
  <name>Initial Convert TLVs</name>
  <thead>
    <tr>
      <th>Code</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Reserved</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Info TLV</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>10</td>
      <td>Connect TLV</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>20</td>
      <td>Extended TCP Header TLV              |   THISRFC   |
 |   21    | Supported TLV</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>21</td>
      <td>Supported TCP Extension TLV          |   THISRFC   |
 |   22    | Cookie TLV                           |   THISRFC   |
 |   30    | Error TLV                            |   THISRFC   |
 +---------+--------------------------------------+-------------+
]]></artwork>
          </figure> TLV</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>22</td>
      <td>Cookie TLV</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>30</td>
      <td>Error TLV</td>
      <td>RFC 8803</td>
    </tr>
  </tbody>
</table>

        </section>
        <section anchor="convert-error-messages"
                 title="Convert numbered="true" toc="default">
          <name>Convert Error Messages"> Messages</name>
          <t>IANA is requested to create has created the "Convert Errors" sub-registry. subregistry.
          Codes in this registry are assigned as a function of the error type.
          Four types are defined; the following ranges are reserved for each
          of these types:</t>

          <t><list style="symbols">
              <t>Message
	  <dl indent="10">
            <dt>0-31:</dt><dd>Message validation and processing errors: 0-31</t>

              <t>Client-side errors: 32-63</t>

              <t>Transport errors</dd>
            <dt>32-63:</dt><dd>Client-side errors</dd>
            <dt>64-95:</dt><dd>Transport Converter-side errors: 64-95</t>

              <t>Errors errors</dd>
            <dt>96-127:</dt><dd>Errors caused by destination server: 96-127</t>
            </list></t> Server</dd>
          </dl>
          <t>The procedure procedures for assigning values from this sub-registry is subregistry are as
          follows:</t>

          <t><list style="symbols">
              <t>0-127: Values in this range are assigned via IETF Review.</t>

              <t>128-191: Values in this range are assigned via Specification
              Required.</t>

              <t>192-255: Values in this range are reserved for Private
              Use.</t>
            </list></t>
          <dl spacing="normal" indent="10">
            <dt>0-127:</dt><dd>IETF Review</dd>
            <dt>128-191:</dt><dd>Specification Required</dd>
            <dt>192-255:</dt><dd>Private Use</dd>
          </dl>
          <t>The initial values to be assigned at the creation of the registry
          are as follows:</t>

          <figure anchor="tab-error-summary"
                  title="Initial

<table anchor="tab-error-summary">
  <name>Initial Convert Error Codes">
            <artwork><![CDATA[
 +-------+-----------------------------------+-----------+
 | Error | Description                       | Reference |
 +-------+-----------------------------------+-----------+
 |    0  | Unsupported Version               |  THISRFC  |
 |    1  | Malformed Message                 |  THISRFC  |
 |    2  | Unsupported Message               |  THISRFC  |
 |    3  | Missing Cookie                    |  THISRFC  |
 |   32  | Not Authorized                    |  THISRFC  |
 |   33  | Unsupported TCP Option            |  THISRFC  |
 |   64  | Resource Exceeded                 |  THISRFC  |
 |   65  | Network Failure                   |  THISRFC  |
 |   96  | Connection Reset                  |  THISRFC  |
 |   97  | Destination Unreachable           |  THISRFC  |
 +-------+-----------------------------------+-----------+
]]></artwork>
          </figure> Codes</name>
  <thead>
    <tr>
      <th>Error</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Unsupported Version</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Malformed Message</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Unsupported Message</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>3</td>
      <td>Missing Cookie</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>32</td>
      <td>Not Authorized</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>33</td>
      <td>Unsupported TCP Option</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>64</td>
      <td>Resource Exceeded</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>65</td>
      <td>Network Failure</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>96</td>
      <td>Connection Reset</td>
      <td>RFC 8803</td>
    </tr>
    <tr>
      <td>97</td>
      <td>Destination Unreachable</td>
      <td>RFC 8803</td>
    </tr>
  </tbody>
</table>

        </section>
      </section>
    </section>
  </middle>
  <back>
    <references title="Normative References">

<displayreference target="I-D.boucadair-tcpm-dhc-converter" to="DHC-CONVERTER"/>
<displayreference target="I-D.olteanu-intarea-socks-6" to="INTAREA-SOCKS"/>

<displayreference target="I-D.boucadair-mptcp-plain-mode" to="MPTCP-PLAIN"/>

<displayreference target="I-D.peirens-mptcp-transparent" to="MPTCP-TRANSPARENT"/>
<displayreference target="I-D.arkko-arch-low-latency" to="LOW-LATENCY"/>
<displayreference target="I-D.boucadair-opsawg-tcpm-converter" to="TCPM-CONVERTER"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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.4291.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8684.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7413.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4987.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.5925.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6890.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6888.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.7323.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2018.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5461.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6731.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6978.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4279.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1812.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1919.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1928.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3135.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7414.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6887.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6928.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8041.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6269.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6296.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.boucadair-tcpm-dhc-converter.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8548.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.olteanu-intarea-socks-6.xml"/>

<reference anchor="RFC0793"
                 target="https://www.rfc-editor.org/info/rfc793"> anchor='I-D.boucadair-mptcp-plain-mode'>

<front>
          <title>Transmission Control Protocol</title>
<title>Extensions for Network-Assisted MPTCP Deployment Models</title>

<author fullname="J. Postel" initials="J." surname="Postel">
            <organization></organization>
          </author>

          <date month="September" year="1981" />
        </front>

        <seriesInfo name="STD" value="7" initials='M' surname='Boucadair' fullname='Mohamed Boucadair'>    <organization />

        <seriesInfo name="RFC" value="793" />

        <seriesInfo name="DOI" value="10.17487/RFC0793" />
      </reference>

      <reference anchor="RFC4291"
                 target="https://www.rfc-editor.org/info/rfc4291">
        <front>
          <title>IP Version 6 Addressing Architecture</title>

          <author fullname="R. Hinden" initials="R." surname="Hinden">
            <organization></organization>
</author>

<author fullname="S. Deering" initials="S." surname="Deering">
            <organization></organization>
          </author>

          <date month="February" year="2006" />

          <abstract>
            <t>This specification defines the addressing architecture of the
            IP Version 6 (IPv6) protocol. The document includes the IPv6
            addressing model, text representations of IPv6 addresses,
            definition of IPv6 unicast addresses, anycast addresses, and
            multicast addresses, and an IPv6 node's required addresses.</t>

            <t>This document obsoletes RFC 3513, "IP Version 6 Addressing
            Architecture". [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4291" />

        <seriesInfo name="DOI" value="10.17487/RFC4291" initials='C' surname='Jacquenet' fullname='Christian Jacquenet'>    <organization />
      </reference>

      <reference anchor="RFC6824"
                 target="https://www.rfc-editor.org/info/rfc6824">
        <front>
          <title>TCP Extensions for Multipath Operation with Multiple
          Addresses</title>
</author>

<author fullname="A. Ford" initials="A." surname="Ford">
            <organization></organization> initials='O' surname='Bonaventure' fullname='Olivier Bonaventure'>    <organization />
</author>

<author fullname="C. Raiciu" initials="C." surname="Raiciu">
            <organization></organization> initials='D' surname='Behaghel' fullname='Denis Behaghel'>    <organization />
</author>

<author fullname="M. Handley" initials="M." surname="Handley">
            <organization></organization> initials='S' surname='Secci' fullname='Stefano Secci'>    <organization />
</author>

<author fullname="O. Bonaventure" initials="O."
                  surname="Bonaventure">
            <organization></organization> initials='W' surname='Henderickx' fullname='Wim Henderickx'>    <organization />
</author>

          <date month="January" year="2013"

<author initials='R' surname='Skog' fullname='Robert Skog'>    <organization />

          <abstract>
            <t>TCP/IP communication is currently restricted to a single path
            per connection, yet multiple paths often exist between peers. The
            simultaneous use of these multiple paths for a TCP/IP session
            would improve resource usage within the network and, thus, improve
            user experience through higher throughput and improved resilience
            to network failure.</t>

            <t>Multipath TCP provides the ability to simultaneously use
            multiple paths between peers. This document presents a set of
            extensions to traditional TCP to support multipath operation. The
            protocol offers the same type of service to applications as TCP
            (i.e., reliable bytestream), and it provides the components
            necessary to establish and use multiple TCP flows across
            potentially disjoint paths. This document defines an Experimental
            Protocol for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="6824" />

        <seriesInfo name="DOI" value="10.17487/RFC6824" />
      </reference>

      <reference anchor="RFC7413"
                 target="https://www.rfc-editor.org/info/rfc7413">
        <front>
          <title>TCP Fast Open</title>

          <author fullname="Y. Cheng" initials="Y." surname="Cheng">
            <organization></organization>
          </author>

          <author fullname="J. Chu" initials="J." surname="Chu">
            <organization></organization>
          </author>

          <author fullname="S. Radhakrishnan" initials="S."
                  surname="Radhakrishnan">
            <organization></organization>
          </author>

          <author fullname="A. Jain" initials="A." surname="Jain">
            <organization></organization>
          </author>

          <date month="December" year="2014" />

          <abstract>
            <t>This document describes an experimental TCP mechanism called
            TCP Fast Open (TFO). TFO allows data to be carried in the SYN and
            SYN-ACK packets and consumed by the receiving end during the
            initial connection handshake, and saves up to one full round-trip
            time (RTT) compared to the standard TCP, which requires a
            three-way handshake (3WHS) to complete before data can be
            exchanged. However, TFO deviates from the standard TCP semantics,
            since the data in the SYN could be replayed to an application in
            some rare circumstances. Applications should not use TFO unless
            they can tolerate this issue, as detailed in the Applicability
            section.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="7413" />

        <seriesInfo name="DOI" value="10.17487/RFC7413" />
      </reference>

      <reference anchor="RFC4987"
                 target="https://www.rfc-editor.org/info/rfc4987">
        <front>
          <title>TCP SYN Flooding Attacks and Common Mitigations</title>

          <author fullname="W. Eddy" initials="W." surname="Eddy">
            <organization></organization>
          </author>

          <date month="August" year="2007" />

          <abstract>
            <t>This document describes TCP SYN flooding attacks, which have
            been well-known to the community for several years. Various
            countermeasures against these attacks, and the trade-offs of each,
            are described. This document archives explanations of the attack
            and common defense techniques for the benefit of TCP implementers
            and administrators of TCP servers or networks, but does not make
            any standards-level recommendations. This memo provides
            information for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4987" />

        <seriesInfo name="DOI" value="10.17487/RFC4987" />
      </reference>

      <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 fullname="S. Bradner" initials="S." surname="Bradner">
            <organization></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"
                 target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
          Words</title>

          <author fullname="B. Leiba" initials="B." surname="Leiba">
            <organization></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="RFC5925"
                 target="https://www.rfc-editor.org/info/rfc5925">
        <front>
          <title>The TCP Authentication Option</title>

          <author fullname="J. Touch" initials="J." surname="Touch">
            <organization></organization>
          </author>

          <author fullname="A. Mankin" initials="A." surname="Mankin">
            <organization></organization>
          </author>

          <author fullname="R. Bonica" initials="R." surname="Bonica">
            <organization></organization>
          </author>

          <date month="June" year="2010" />

          <abstract>
            <t>This document specifies the TCP Authentication Option (TCP-AO),
            which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP
            MD5). TCP-AO specifies the use of stronger Message Authentication
            Codes (MACs), protects against replays even for long-lived TCP
            connections, and provides more details on the association of
            security with TCP connections than TCP MD5. TCP-AO is compatible
            with either a static Master Key Tuple (MKT) configuration or an
            external, out-of-band MKT management mechanism; in either case,
            TCP-AO also protects connections when using the same MKT across
            repeated instances of a connection, using traffic keys derived
            from the MKT, and coordinates MKT changes between endpoints. The
            result is intended to support current infrastructure uses of TCP
            MD5, such as to protect long-lived connections (as used, e.g., in
            BGP and LDP), and to support a larger set of MACs with minimal
            other system and operational changes. TCP-AO uses a different
            option identifier than TCP MD5, even though TCP-AO and TCP MD5 are
            never permitted to be used simultaneously. TCP-AO supports IPv6,
            and is fully compatible with the proposed requirements for the
            replacement of TCP MD5. [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="5925" />

        <seriesInfo name="DOI" value="10.17487/RFC5925" />
      </reference>

      <reference anchor="RFC8126"
                 target="https://www.rfc-editor.org/info/rfc8126">
        <front>
          <title>Guidelines for Writing an IANA Considerations Section in
          RFCs</title>

          <author fullname="M. Cotton" initials="M." surname="Cotton">
            <organization></organization>
          </author>

          <author fullname="B. Leiba" initials="B." surname="Leiba">
            <organization></organization>
          </author>

          <author fullname="T. Narten" initials="T." surname="Narten">
            <organization></organization>
          </author>

          <date month="June" year="2017" />

          <abstract>
            <t>Many protocols make use of points of extensibility that use
            constants to identify various protocol parameters. To ensure that
            the values in these fields do not have conflicting uses and to
            promote interoperability, their allocations are often coordinated
            by a central record keeper. For IETF protocols, that role is
            filled by the Internet Assigned Numbers Authority (IANA).</t>

            <t>To make assignments in a given registry prudently, guidance
            describing the conditions under which new values should be
            assigned, as well as when and how modifications to existing values
            can be made, is needed. This document defines a framework for the
            documentation of these guidelines by specification authors, in
            order to assure that the provided guidance for the IANA
            Considerations is clear and addresses the various issues that are
            likely in the operation of a registry.</t>

            <t>This is the third edition of this document; it obsoletes RFC
            5226.</t>
          </abstract>
        </front>

        <seriesInfo name="BCP" value="26" />

        <seriesInfo name="RFC" value="8126" />

        <seriesInfo name="DOI" value="10.17487/RFC8126" />
      </reference>

      <reference anchor="RFC6890"
                 target="https://www.rfc-editor.org/info/rfc6890">
        <front>
          <title>Special-Purpose IP Address Registries</title>

          <author fullname="M. Cotton" initials="M." surname="Cotton">
            <organization></organization>
          </author>

          <author fullname="L. Vegoda" initials="L." surname="Vegoda">
            <organization></organization>
          </author>

          <author fullname="R. Bonica" initials="R." role="editor"
                  surname="Bonica">
            <organization></organization>
          </author>

          <author fullname="B. Haberman" initials="B." surname="Haberman">
            <organization></organization>
          </author>

          <date month="April" year="2013" />

          <abstract>
            <t>This memo reiterates the assignment of an IPv4 address block
            (192.0.0.0/24) to IANA. It also instructs IANA to restructure its
            IPv4 and IPv6 Special-Purpose Address Registries. Upon
            restructuring, the aforementioned registries will record all
            special-purpose address blocks, maintaining a common set of
            information regarding each address block.</t>
          </abstract>
        </front>

        <seriesInfo name="BCP" value="153" />

        <seriesInfo name="RFC" value="6890" />

        <seriesInfo name="DOI" value="10.17487/RFC6890" />
      </reference>

      <reference anchor="RFC6888"
                 target="https://www.rfc-editor.org/info/rfc6888">
        <front>
          <title>Common Requirements for Carrier-Grade NATs (CGNs)</title>

          <author fullname="S. Perreault" initials="S." role="editor"
                  surname="Perreault">
            <organization></organization>
          </author>

          <author fullname="I. Yamagata" initials="I." surname="Yamagata">
            <organization></organization>
          </author>

          <author fullname="S. Miyakawa" initials="S." surname="Miyakawa">
            <organization></organization>
          </author>

          <author fullname="A. Nakagawa" initials="A." surname="Nakagawa">
            <organization></organization>
          </author>

          <author fullname="H. Ashida" initials="H." surname="Ashida">
            <organization></organization>
          </author>

          <date month="April" year="2013" />

          <abstract>
            <t>This document defines common requirements for Carrier-Grade
            NATs (CGNs). It updates RFC 4787.</t>
          </abstract>
        </front>

        <seriesInfo name="BCP" value="127" />

        <seriesInfo name="RFC" value="6888" />

        <seriesInfo name="DOI" value="10.17487/RFC6888" />
      </reference>

      <reference anchor="RFC4787"
                 target="https://www.rfc-editor.org/info/rfc4787">
        <front>
          <title>Network Address Translation (NAT) Behavioral Requirements for
          Unicast UDP</title>

          <author fullname="F. Audet" initials="F." role="editor"
                  surname="Audet">
            <organization></organization>
          </author>

          <author fullname="C. Jennings" initials="C." surname="Jennings">
            <organization></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="RFC7323"
                 target="https://www.rfc-editor.org/info/rfc7323">
        <front>
          <title>TCP Extensions for High Performance</title>

          <author fullname="D. Borman" initials="D." surname="Borman">
            <organization></organization>
          </author>

          <author fullname="B. Braden" initials="B." surname="Braden">
            <organization></organization>
          </author>

          <author fullname="V. Jacobson" initials="V." surname="Jacobson">
            <organization></organization>
          </author>

          <author fullname="R. Scheffenegger" initials="R." role="editor"
                  surname="Scheffenegger">
            <organization></organization>
          </author>

          <date month="September" year="2014" />

          <abstract>
            <t>This document specifies a set of TCP extensions to improve
            performance over paths with a large bandwidth * delay product and
            to provide reliable operation over very high-speed paths. It
            defines the TCP Window Scale (WS) option and the TCP Timestamps
            (TS) option and their semantics. The Window Scale option is used
            to support larger receive windows, while the Timestamps option can
            be used for at least two distinct mechanisms, Protection Against
            Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM),
            that are also described herein.</t>

            <t>This document obsoletes RFC 1323 and describes changes from
            it.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="7323" />

        <seriesInfo name="DOI" value="10.17487/RFC7323" />
      </reference>

      <reference anchor="RFC2018"
                 target="https://www.rfc-editor.org/info/rfc2018">
        <front>
          <title>TCP Selective Acknowledgment Options</title>

          <author fullname="M. Mathis" initials="M." surname="Mathis">
            <organization></organization>
          </author>

          <author fullname="J. Mahdavi" initials="J." surname="Mahdavi">
            <organization></organization>
          </author>

          <author fullname="S. Floyd" initials="S." surname="Floyd">
            <organization></organization>
          </author>

          <author fullname="A. Romanow" initials="A." surname="Romanow">
            <organization></organization>
          </author>

          <date month="October" year="1996" />

          <abstract>
            <t>This memo proposes an implementation of SACK and discusses its
            performance and related issues. [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2018" />

        <seriesInfo name="DOI" value="10.17487/RFC2018" />
      </reference>

      <reference anchor="RFC2827"
                 target="https://www.rfc-editor.org/info/rfc2827">
        <front>
          <title>Network Ingress Filtering: Defeating Denial of Service
          Attacks which employ IP Source Address Spoofing</title>

          <author fullname="P. Ferguson" initials="P." surname="Ferguson">
            <organization></organization>
          </author>

          <author fullname="D. Senie" initials="D." surname="Senie">
            <organization></organization>
          </author>

          <date month="May" year="2000" />

          <abstract>
            <t>This paper discusses a simple, effective, and straightforward
            method for using ingress traffic filtering to prohibit DoS (Denial
            of Service) attacks which use forged IP addresses to be propagated
            from 'behind' an Internet Service Provider's (ISP) aggregation
            point. 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="38" />

        <seriesInfo name="RFC" value="2827" />

        <seriesInfo name="DOI" value="10.17487/RFC2827" />
      </reference>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.5461'?>

      <?rfc include='reference.RFC.6731'?>

      <reference anchor="RFC6978"
                 target="https://www.rfc-editor.org/info/rfc6978">
        <front>
          <title>A TCP Authentication Option Extension for NAT
          Traversal</title>

          <author fullname="J. Touch" initials="J." surname="Touch">
            <organization></organization>
          </author>

          <date month="July" year="2013" />

          <abstract>
            <t>This document describes an extension to the TCP Authentication
            Option (TCP-AO) to support its use over connections that pass
            through Network Address Translators and/or Network Address and
            Port Translators (NATs/NAPTs). This extension changes the data
            used to compute traffic keys, but it does not alter TCP-AO's
            packet processing or key generation algorithms.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="6978" />

        <seriesInfo name="DOI" value="10.17487/RFC6978" />
      </reference>

      <reference anchor="RFC2782"
                 target="https://www.rfc-editor.org/info/rfc2782">
        <front>
          <title>A DNS RR for specifying the location of services (DNS
          SRV)</title>

          <author fullname="A. Gulbrandsen" initials="A."
                  surname="Gulbrandsen">
            <organization></organization>
          </author>

          <author fullname="P. Vixie" initials="P." surname="Vixie">
            <organization></organization>
          </author>

          <author fullname="L. Esibov" initials="L." surname="Esibov">
            <organization></organization>
          </author>

          <date month="February" year="2000" />

          <abstract>
            <t>This document describes a DNS RR which specifies the location
            of the server(s) for a specific protocol and domain.
            [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2782" />

        <seriesInfo name="DOI" value="10.17487/RFC2782" />
      </reference>

      <reference anchor="RFC4279"
                 target="https://www.rfc-editor.org/info/rfc4279">
        <front>
          <title>Pre-Shared Key Ciphersuites for Transport Layer Security
          (TLS)</title>

          <author fullname="P. Eronen" initials="P." role="editor"
                  surname="Eronen">
            <organization></organization>
          </author>

          <author fullname="H. Tschofenig" initials="H." role="editor"
                  surname="Tschofenig">
            <organization></organization>
          </author>

          <date month="December" year="2005" />

          <abstract>
            <t>This document specifies three sets of new ciphersuites for the
            Transport Layer Security (TLS) protocol to support authentication
            based on pre-shared keys (PSKs). These pre-shared keys are
            symmetric keys, shared in advance among the communicating parties.
            The first set of ciphersuites uses only symmetric key operations
            for authentication. The second set uses a Diffie-Hellman exchange
            authenticated with a pre-shared key, and the third set combines
            public key authentication of the server with pre-shared key
            authentication of the client. [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4279" />

        <seriesInfo name="DOI" value="10.17487/RFC4279" />
      </reference>

      <reference anchor="RFC7250"
                 target="https://www.rfc-editor.org/info/rfc7250">
        <front>
          <title>Using Raw Public Keys in Transport Layer Security (TLS) and
          Datagram Transport Layer Security (DTLS)</title>

          <author fullname="P. Wouters" initials="P." role="editor"
                  surname="Wouters">
            <organization></organization>
          </author>

          <author fullname="H. Tschofenig" initials="H." role="editor"
                  surname="Tschofenig">
            <organization></organization>
          </author>

          <author fullname="J. Gilmore" initials="J." surname="Gilmore">
            <organization></organization>
          </author>

          <author fullname="S. Weiler" initials="S." surname="Weiler">
            <organization></organization>
          </author>

          <author fullname="T. Kivinen" initials="T." surname="Kivinen">
            <organization></organization>
          </author>

          <date month="June" year="2014" />

          <abstract>
            <t>This document specifies a new certificate type and two TLS
            extensions for exchanging raw public keys in Transport Layer
            Security (TLS) and Datagram Transport Layer Security (DTLS). The
            new certificate type allows raw public keys to be used for
            authentication.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="7250" />

        <seriesInfo name="DOI" value="10.17487/RFC7250" />
      </reference>

      <reference anchor="RFC1812"
                 target="https://www.rfc-editor.org/info/rfc1812">
        <front>
          <title>Requirements for IP Version 4 Routers</title>

          <author fullname="F. Baker" initials="F." role="editor"
                  surname="Baker">
            <organization></organization>
          </author>

          <date month="June" year="1995" />

          <abstract>
            <t>This memo defines and discusses requirements for devices that
            perform the network layer forwarding function of the Internet
            protocol suite. [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="1812" />

        <seriesInfo name="DOI" value="10.17487/RFC1812" />
      </reference>

      <reference anchor="RFC1919"
                 target="https://www.rfc-editor.org/info/rfc1919">
        <front>
          <title>Classical versus Transparent IP Proxies</title>

          <author fullname="M. Chatel" initials="M." surname="Chatel">
            <organization></organization>
          </author>

          <date month="March" year="1996" />

          <abstract>
            <t>This document explains "classical" and "transparent" proxy
            techniques and attempts to provide rules to help determine when
            each proxy system may be used without causing problems. This memo
            provides information for the Internet community. This memo does
            not specify an Internet standard of any kind.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="1919" />

        <seriesInfo name="DOI" value="10.17487/RFC1919" />
      </reference>

      <reference anchor="RFC1928"
                 target="https://www.rfc-editor.org/info/rfc1928">
        <front>
          <title>SOCKS Protocol Version 5</title>

          <author fullname="M. Leech" initials="M." surname="Leech">
            <organization></organization>
          </author>

          <author fullname="M. Ganis" initials="M." surname="Ganis">
            <organization></organization>
          </author>

          <author fullname="Y. Lee" initials="Y." surname="Lee">
            <organization></organization>
          </author>

          <author fullname="R. Kuris" initials="R." surname="Kuris">
            <organization></organization>
          </author>

          <author fullname="D. Koblas" initials="D." surname="Koblas">
            <organization></organization>
          </author>

          <author fullname="L. Jones" initials="L." surname="Jones">
            <organization></organization>
          </author>

          <date month="March" year="1996" />

          <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="RFC3135"
                 target="https://www.rfc-editor.org/info/rfc3135">
        <front>
          <title>Performance Enhancing Proxies Intended to Mitigate
          Link-Related Degradations</title>

          <author fullname="J. Border" initials="J." surname="Border">
            <organization></organization>
          </author>

          <author fullname="M. Kojo" initials="M." surname="Kojo">
            <organization></organization>
          </author>

          <author fullname="J. Griner" initials="J." surname="Griner">
            <organization></organization>
          </author>

          <author fullname="G. Montenegro" initials="G." surname="Montenegro">
            <organization></organization>
          </author>

          <author fullname="Z. Shelby" initials="Z." surname="Shelby">
            <organization></organization>
          </author>

          <date month="June" year="2001" />

          <abstract>
            <t>This document is a survey of Performance Enhancing Proxies
            (PEPs) often employed to improve degraded TCP performance caused
            by characteristics of specific link environments, for example, in
            satellite, wireless WAN, and wireless LAN environments. This memo
            provides information for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3135" />

        <seriesInfo name="DOI" value="10.17487/RFC3135" />
      </reference>

      <reference anchor="RFC7414"
                 target="https://www.rfc-editor.org/info/rfc7414">
        <front>
          <title>A Roadmap for Transmission Control Protocol (TCP)
          Specification Documents</title>

          <author fullname="M. Duke" initials="M." surname="Duke">
            <organization></organization>
          </author>

          <author fullname="R. Braden" initials="R." surname="Braden">
            <organization></organization>
          </author>

          <author fullname="W. Eddy" initials="W." surname="Eddy">
            <organization></organization>
          </author>

          <author fullname="E. Blanton" initials="E." surname="Blanton">
            <organization></organization>
          </author>

          <author fullname="A. Zimmermann" initials="A." surname="Zimmermann">
            <organization></organization>
          </author>

          <date month="February" year="2015" />

          <abstract>
            <t>This document contains a roadmap to the Request for Comments
            (RFC) documents relating to the Internet's Transmission Control
            Protocol (TCP). This roadmap provides a brief summary of the
            documents defining TCP and various TCP extensions that have
            accumulated in the RFC series. This serves as a guide and quick
            reference for both TCP implementers and other parties who desire
            information contained in the TCP-related RFCs.</t>

            <t>This document obsoletes RFC 4614.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="7414" />

        <seriesInfo name="DOI" value="10.17487/RFC7414" />
      </reference>

      <reference anchor="RFC6887"
                 target="https://www.rfc-editor.org/info/rfc6887">
        <front>
          <title>Port Control Protocol (PCP)</title>

          <author fullname="D. Wing" initials="D." role="editor"
                  surname="Wing">
            <organization></organization>
          </author>

          <author fullname="S. Cheshire" initials="S." surname="Cheshire">
            <organization></organization>
          </author>

          <author fullname="M. Boucadair" initials="M." surname="Boucadair">
            <organization></organization>
          </author>

          <author fullname="R. Penno" initials="R." surname="Penno">
            <organization></organization>
          </author>

          <author fullname="P. Selkirk" initials="P." surname="Selkirk">
            <organization></organization>
          </author>

          <date month="April" year="2013" />

          <abstract>
            <t>The Port Control Protocol allows an IPv6 or IPv4 host to
            control how incoming IPv6 or IPv4 packets are translated and
            forwarded by a Network Address Translator (NAT) or simple
            firewall, and also allows a host to optimize its outgoing NAT
            keepalive messages.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="6887" />

        <seriesInfo name="DOI" value="10.17487/RFC6887" />
      </reference>

      <reference anchor="RFC6928"
                 target="https://www.rfc-editor.org/info/rfc6928">
        <front>
          <title>Increasing TCP's Initial Window</title>

          <author fullname="J. Chu" initials="J." surname="Chu">
            <organization></organization>
          </author>

          <author fullname="N. Dukkipati" initials="N." surname="Dukkipati">
            <organization></organization>
          </author>

          <author fullname="Y. Cheng" initials="Y." surname="Cheng">
            <organization></organization>
          </author>

          <author fullname="M. Mathis" initials="M." surname="Mathis">
            <organization></organization>
          </author>

          <date month="April" year="2013" />

          <abstract>
            <t>This document proposes an experiment to increase the permitted
            TCP initial window (IW) from between 2 and 4 segments, as
            specified in RFC 3390, to 10 segments with a fallback to the
            existing recommendation when performance issues are detected. It
            discusses the motivation behind the increase, the advantages and
            disadvantages of the higher initial window, and presents results
            from several large-scale experiments showing that the higher
            initial window improves the overall performance of many web
            services without resulting in a congestion collapse. The document
            closes with a discussion of usage and deployment for further
            experimental purposes recommended by the IETF TCP Maintenance and
            Minor Extensions (TCPM) working group.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="6928" />

        <seriesInfo name="DOI" value="10.17487/RFC6928" />
      </reference>

      <reference anchor="RFC8041"
                 target="https://www.rfc-editor.org/info/rfc8041">
        <front>
          <title>Use Cases and Operational Experience with Multipath
          TCP</title>

          <author fullname="O. Bonaventure" initials="O."
                  surname="Bonaventure">
            <organization></organization>
          </author>

          <author fullname="C. Paasch" initials="C." surname="Paasch">
            <organization></organization>
          </author>

          <author fullname="G. Detal" initials="G." surname="Detal">
            <organization></organization>
          </author>

          <date month="January" year="2017" />

          <abstract>
            <t>This document discusses both use cases and operational
            experience with Multipath TCP (MPTCP) in real networks. It lists
            several prominent use cases where Multipath TCP has been
            considered and is being used. It also gives insight to some
            heuristics and decisions that have helped to realize these use
            cases and suggests possible improvements.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="8041" />

        <seriesInfo name="DOI" value="10.17487/RFC8041" />
      </reference>

      <reference anchor="RFC8305"
                 target="https://www.rfc-editor.org/info/rfc8305">
        <front>
          <title>Happy Eyeballs Version 2: Better Connectivity Using
          Concurrency</title>

          <author fullname="D. Schinazi" initials="D." surname="Schinazi">
            <organization></organization>
          </author>

          <author fullname="T. Pauly" initials="T." surname="Pauly">
            <organization></organization>
          </author>

          <date month="December" year="2017" />

          <abstract>
            <t>Many communication protocols operating over the modern Internet
            use hostnames. These often resolve to multiple IP addresses, each
            of which may have different performance and connectivity
            characteristics. Since specific addresses or address families
            (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a
            network, clients that attempt multiple connections in parallel
            have a chance of establishing a connection more quickly. This
            document specifies requirements for algorithms that reduce this
            user-visible delay and provides an example algorithm, referred to
            as "Happy Eyeballs". This document obsoletes the original
            algorithm description in RFC 6555.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="8305" />

        <seriesInfo name="DOI" value="10.17487/RFC8305" />
      </reference>

      <reference anchor="RFC8446"
                 target="https://www.rfc-editor.org/info/rfc8446">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version
          1.3</title>

          <author fullname="E. Rescorla" initials="E." surname="Rescorla">
            <organization></organization>
          </author>

          <date month="August" year="2018" />

          <abstract>
            <t>This document specifies version 1.3 of the Transport Layer
            Security (TLS) protocol. TLS allows client/server applications to
            communicate over the Internet in a way that is designed to prevent
            eavesdropping, tampering, and message forgery.</t>

            <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs
            5077, 5246, and 6961. This document also specifies new
            requirements for TLS 1.2 implementations.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="8446" />

        <seriesInfo name="DOI" value="10.17487/RFC8446" />
      </reference>

      <reference anchor="RFC6269"
                 target="https://www.rfc-editor.org/info/rfc6269">
        <front>
          <title>Issues with IP Address Sharing</title>

          <author fullname="M. Ford" initials="M." role="editor"
                  surname="Ford">
            <organization></organization>
          </author>

          <author fullname="M. Boucadair" initials="M." surname="Boucadair">
            <organization></organization>
          </author>

          <author fullname="A. Durand" initials="A." surname="Durand">
            <organization></organization>
          </author>

          <author fullname="P. Levis" initials="P." surname="Levis">
            <organization></organization>
          </author>

          <author fullname="P. Roberts" initials="P." surname="Roberts">
            <organization></organization>
          </author>

          <date month="June" year="2011" />

          <abstract>
            <t>The completion of IPv4 address allocations from IANA and the
            Regional Internet Registries (RIRs) is causing service providers
            around the world to question how they will continue providing IPv4
            connectivity service to their subscribers when there are no longer
            sufficient IPv4 addresses to allocate them one per subscriber.
            Several possible solutions to this problem are now emerging based
            around the idea of shared IPv4 addressing. These solutions give
            rise to a number of issues, and this memo identifies those common
            to all such address sharing approaches. Such issues include
            application failures, additional service monitoring complexity,
            new security vulnerabilities, and so on. Solution-specific
            discussions are out of scope.</t>

            <t>Deploying IPv6 is the only perennial way to ease pressure on
            the public IPv4 address pool without the need for address sharing
            mechanisms that give rise to the issues identified herein. This
            document is not an Internet Standards Track specification; it is
            published for informational purposes.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="6269" />

        <seriesInfo name="DOI" value="10.17487/RFC6269" />
      </reference>

      <reference anchor="RFC6296"
                 target="https://www.rfc-editor.org/info/rfc6296">
        <front>
          <title>IPv6-to-IPv6 Network Prefix Translation</title>

          <author fullname="M. Wasserman" initials="M." surname="Wasserman">
            <organization></organization>
          </author>

          <author fullname="F. Baker" initials="F." surname="Baker">
            <organization></organization>
          </author>

          <date month="June" year="2011" />

          <abstract>
            <t>This document describes a stateless, transport-agnostic
            IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that
            provides the address-independence benefit associated with
            IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between
            addresses in the "inside" and "outside" prefixes, preserving
            end-to-end reachability at the network layer. This document
            defines an Experimental Protocol for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="6296" />

        <seriesInfo name="DOI" value="10.17487/RFC6296" />
      </reference>

      <reference anchor="I-D.boucadair-tcpm-dhc-converter">
        <front>
          <title>DHCP Options for 0-RTT TCP Converters</title>

          <author fullname="Mohamed Boucadair" initials="M"
                  surname="Boucadair">
            <organization></organization>
          </author>

          <author fullname="Christian Jacquenet" initials="C"
                  surname="Jacquenet">
            <organization></organization>
          </author>

          <author fullname="Tirumaleswar Reddy.K" initials="T"
                  surname="Reddy.K">
            <organization></organization>
          </author>

          <date day="7" month="October" year="2019" />

          <abstract>
            <t>Because of the lack of important TCP extensions, e.g.,
            Multipath TCP support at the server side, some service providers
            now consider a network-assisted model that relies upon the
            activation of a dedicated function called Transport Converters.
            For example, network-assisted Multipath TCP deployment models are
            designed to facilitate the adoption of Multipath TCP for the
            establishment of multi-path communications without making any
            assumption about the support of Multipath TCP by the remote
            servers. Transport Converters located in the network are
            responsible for establishing multi-path communications on behalf
            of endpoints, thereby taking advantage of Multipath TCP
            capabilities to achieve different goals that include (but are not
            limited to) optimization of resource usage (e.g., bandwidth
            aggregation), of resiliency (e.g., primary/backup communication
            paths), and traffic offload management. This document focuses on
            the explicit deployment scheme where the identity of the Transport
            Converters is explicitly configured on connected hosts. This
            document specifies DHCP (IPv4 and IPv6) options to configure hosts
            with Converters parameters.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-boucadair-tcpm-dhc-converter-03" />

        <format target="http://www.ietf.org/internet-drafts/draft-boucadair-tcpm-dhc-converter-03.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC8548"
                 target="https://www.rfc-editor.org/info/rfc8548">
        <front>
          <title>Cryptographic Protection of TCP Streams (tcpcrypt)</title>

          <author fullname="A. Bittau" initials="A." surname="Bittau">
            <organization></organization>
          </author>

          <author fullname="D. Giffin" initials="D." surname="Giffin">
            <organization></organization>
          </author>

          <author fullname="M. Handley" initials="M." surname="Handley">
            <organization></organization>
          </author>

          <author fullname="D. Mazieres" initials="D." surname="Mazieres">
            <organization></organization>
          </author>

          <author fullname="Q. Slack" initials="Q." surname="Slack">
            <organization></organization>
          </author>

          <author fullname="E. Smith" initials="E." surname="Smith">
            <organization></organization>
          </author>

          <date month="May" year="2019" />

          <abstract>
            <t>This document specifies "tcpcrypt", a TCP encryption protocol
            designed for use in conjunction with the TCP Encryption
            Negotiation Option (TCP-ENO). Tcpcrypt coexists with middleboxes
            by tolerating resegmentation, NATs, and other manipulations of the
            TCP header. The protocol is self-contained and specifically
            tailored to TCP implementations, which often reside in kernels or
            other environments in which large external software dependencies
            can be undesirable. Because the size of TCP options is limited,
            the protocol requires one additional one-way message latency to
            perform key exchange before application data can be transmitted.
            However, the extra latency can be avoided between two hosts that
            have recently established a previous tcpcrypt connection.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="8548" />

        <seriesInfo name="DOI" value="10.17487/RFC8548" />
      </reference>

      <reference anchor="I-D.olteanu-intarea-socks-6">
        <front>
          <title>SOCKS Protocol Version 6</title>

          <author fullname="Vladimir Olteanu" initials="V" surname="Olteanu">
            <organization></organization>
          </author>

          <author fullname="Dragos Niculescu" initials="D" surname="Niculescu">
            <organization></organization>
          </author>

          <date day="4" month="November" year="2019" />

          <abstract>
            <t>The SOCKS protocol is used primarily to proxy TCP connections
            to arbitrary destinations via the use of a proxy server. Under the
            latest version of the protocol (version 5), it takes 2 RTTs (or 3,
            if authentication is used) before data can flow between the client
            and the server. This memo proposes SOCKS version 6, which reduces
            the number of RTTs used, takes full advantage of TCP Fast Open,
            and adds support for 0-RTT authentication.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-olteanu-intarea-socks-6-08" />

        <format target="http://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-08.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.boucadair-mptcp-plain-mode">
        <front>
          <title>Extensions for Network-Assisted MPTCP Deployment
          Models</title>

          <author fullname="Mohamed Boucadair" initials="M"
                  surname="Boucadair">
            <organization></organization>
          </author>

          <author fullname="Christian Jacquenet" initials="C"
                  surname="Jacquenet">
            <organization></organization>
          </author>

          <author fullname="Olivier Bonaventure" initials="O"
                  surname="Bonaventure">
            <organization></organization>
          </author>

          <author fullname="Denis Behaghel" initials="D" surname="Behaghel">
            <organization></organization>
          </author>

          <author fullname="stefano.secci@lip6.fr" initials="s"
                  surname="stefano.secci@lip6.fr">
            <organization></organization>
          </author>

          <author fullname="Wim Henderickx" initials="W" surname="Henderickx">
            <organization></organization>
          </author>

          <author fullname="Robert Skog" initials="R" surname="Skog">
            <organization></organization>
          </author>

          <author fullname="Suresh Vinapamula" initials="S"
                  surname="Vinapamula">
            <organization></organization>
          </author>

          <author fullname="SungHoon Seo" initials="S" surname="Seo">
            <organization></organization>
          </author>

          <author fullname="Wouter Cloetens" initials="W" surname="Cloetens">
            <organization></organization>
          </author>

          <author fullname="Ullrich Meyer" initials="U" surname="Meyer">
            <organization></organization>
          </author>

          <author fullname="Luis Contreras" initials="L" surname="Contreras">
            <organization></organization>
          </author>

          <author fullname="Bart Peirens" initials="B" surname="Peirens">
            <organization></organization>
          </author>

          <date day="9" month="March" year="2017" />

          <abstract>
            <t>Because of the lack of Multipath TCP (MPTCP) support at the
            server side, some service providers now consider a
            network-assisted model that relies upon the activation of a
            dedicated function called MPTCP Conversion Point (MCP).
            Network-Assisted MPTCP deployment models are designed to
            facilitate the adoption of MPTCP for the establishment of
            multi-path communications without making any assumption about the
            support of MPTCP by the communicating peers. MCPs located in the
            network are responsible for establishing multi-path communications
            on behalf of endpoints, thereby taking advantage of MPTCP
            capabilities to achieve different goals that include (but are not
            limited to) optimization of resource usage (e.g., bandwidth
            aggregation), of resiliency (e.g., primary/backup communication
            paths), and traffic offload management. This document specifies
            extensions for Network-Assisted MPTCP deployment models.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-boucadair-mptcp-plain-mode-10" />

        <format target="http://www.ietf.org/internet-drafts/draft-boucadair-mptcp-plain-mode-10.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.peirens-mptcp-transparent">
        <front>
          <title>Link bonding with transparent Multipath TCP</title>

          <author fullname="Bart Peirens" initials="B" surname="Peirens">
            <organization></organization>
          </author>

          <author fullname="Gregory Detal" initials="G" surname="Detal">
            <organization></organization>
          </author>

          <author fullname="Sebastien Barre" initials="S" surname="Barre">
            <organization></organization>
          </author>

          <author fullname="Olivier Bonaventure" initials="O"
                  surname="Bonaventure">
            <organization></organization>
          </author>

          <date day="8" month="July" year="2016" />

          <abstract>
            <t>This document describes the utilisation of the transparent
            Multipath TCP mode to enable network operators to provide link
            bonding services in hybrid access networks.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-peirens-mptcp-transparent-00" />

        <format target="http://www.ietf.org/internet-drafts/draft-peirens-mptcp-transparent-00.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.arkko-arch-low-latency">
        <front>
          <title>Low Latency Applications and the Internet
          Architecture</title>

          <author fullname="Jari Arkko" initials="J" surname="Arkko">
            <organization></organization>
</author>

          <author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
            <organization></organization>
          </author>

          <date day="30" month="October" year="2017" />

          <abstract>
            <t>Some recent Internet technology developments relate to
            improvements in communications latency. For instance, improvements
            in radio communications or the recent work in IETF transport,
            security, and web protocols. There are also potential applications
            where latency would play a more significant role than it has
            traditionally been in the Internet communications. Modern
            networking systems offer many tools for building low-latency
            networks, from highly optimised individual protocol components to
            software controlled, virtualised and tailored network functions.
            This memo views the developments from a system viewpoint, and
            considers the potential future stresses that the strive for
            low-latency support for applications may bring.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-arkko-arch-low-latency-02"

<author initials='S' surname='Vinapamula' fullname='Suresh Vinapamula'>    <organization />

        <format target="http://www.ietf.org/internet-drafts/draft-arkko-arch-low-latency-02.txt"
                type="TXT"
</author>

<author initials='S' surname='Seo' fullname='SungHoon Seo'>    <organization />
      </reference>

      <reference anchor="I-D.boucadair-radext-tcpm-converter">
        <front>
          <title>RADIUS Extensions for 0-RTT TCP Converters</title>
</author>

<author fullname="Mohamed Boucadair" initials="M"
                  surname="Boucadair">
            <organization></organization> initials='W' surname='Cloetens' fullname='Wouter Cloetens'>    <organization />
</author>

<author fullname="Christian Jacquenet" initials="C"
                  surname="Jacquenet">
            <organization></organization> initials='U' surname='Meyer' fullname='Ullrich Meyer'>    <organization />
</author>

<author initials='L' surname='Contreras' fullname='Luis Contreras'>   <organization />
</author>

<author initials='B' surname='Peirens' fullname='Bart Peirens'>  <organization />
</author>

<date day="15" month="April" year="2019" month='March' year='2017' />

          <abstract>
            <t>Because of the lack of Multipath TCP (MPTCP) support at the
            server side, some service providers now consider a
            network-assisted model that relies upon the activation of a
            dedicated function called Converters. Network-assisted MPTCP
            deployment models are designed to facilitate the adoption of MPTCP
            for the establishment of multi-path communications without making
            any assumption about the support of MPTCP by the communicating
            peers. Converters located in the network are responsible for
            establishing multi-path communications on behalf of endpoints,
            thereby taking advantage of MPTCP capabilities to achieve
            different goals that include (but are not limited to) optimization
            of resource usage (e.g., bandwidth aggregation), of resiliency
            (e.g., primary/backup communication paths), and traffic offload
            management. This document specifies a new Remote Authentication
            Dial-In User Service (RADIUS) attributes that carry the IP
            addresses that will be returned to authorized users to reach one
            or multiple Converters.</t>
          </abstract>
</front>
<seriesInfo name="Internet-Draft"
                    value="draft-boucadair-radext-tcpm-converter-02" />

        <format target="http://www.ietf.org/internet-drafts/draft-boucadair-radext-tcpm-converter-02.txt"
                type="TXT" name='Internet-Draft' value='draft-boucadair-mptcp-plain-mode-10' />
</reference>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.peirens-mptcp-transparent.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.arkko-arch-low-latency.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.boucadair-opsawg-tcpm-converter.xml"/>

<reference anchor="IANA-CONVERT" target="https://www.iana.org/assignments/tcp-convert-protocol-parameters/tcp-convert-protocol-parameters.xhtml">
<front>
<title>TCP Convert Protocol (Convert) Parameters
</title>
<author>
<organization>IANA
</organization>
</author>
</front>
</reference>

        <reference anchor="TS23501" target="https://www.3gpp.org/ftp/Specs/archive/23_series/23.501/">
          <front>
            <title>Technical Specification Group Services and System Aspects;
          System Architecture architecture for the 5G System; Stage 2 (Release 16)</title>

          <author initials="."
                  surname="3GPP
            <author>
              <organization>3GPP (3rd Generation Partnership Project)">
            <organization></organization> Project)
	      </organization>
            </author>
            <date year="2019" /> year="2019"/>
          </front>
        </reference>

        <reference anchor="Fukuda2011">
          <front>
            <title>An Analysis of Longitudinal TCP Passive Measurements (Short
          Paper)</title>
            <author initials="K." surname="Fukuda">
            <organization></organization>
              <organization/>
            </author>
            <date year="2011" /> year="2011"/>
          </front>

        <seriesInfo name="Traffic

<refcontent>Traffic Monitoring and Analysis. TMA 2011. Lecture Analysis</refcontent>
<refcontent>TMA 2011</refcontent>
<refcontent>Lecture Notes in Computer Science, vol 6613."
                    value="" /> vol. 6613</refcontent>
        </reference>

        <reference anchor="ANRW17">
          <front>
            <title>Tracking transport-layer evolution with PATHspider</title>
            <author initials="B." surname="Trammell">
            <organization></organization>
              <organization/>
            </author>
            <author initials="M." surname="Kuehlewind">
            <organization></organization>
              <organization/>
            </author>
            <author initials="P." surname="De Vaere">
            <organization></organization>
              <organization/>
            </author>
            <author initials="I." surname="Learmonth">
            <organization></organization>
              <organization/>
            </author>
            <author initials="G." surname="Fairhurst">
            <organization></organization>
              <organization/>
            </author>
            <date month="July" year="2017" /> year="2017"/>
          </front>

        <seriesInfo name="Applied
<refcontent>Applied Networking Research Workshop 2017 (ANRW17)"
                    value="" /> (ANRW17)</refcontent>
        </reference>

        <reference anchor="IMC11">
          <front>
            <title>Is it still possible to extend TCP?</title>
            <author initials="K." surname="Honda">
            <organization></organization>
              <organization/>
            </author>
            <author initials="Y." surname="Nishida">
            <organization></organization>
              <organization/>
            </author>
            <author initials="C." surname="Raiciu">
            <organization></organization>
              <organization/>
            </author>
            <author initials="A." surname="Greenhalgh">
            <organization></organization>
              <organization/>
            </author>
            <author initials="M." surname="Handley">
            <organization></organization>
              <organization/>
            </author>
            <author initials="T." surname="Hideyuki">
            <organization></organization>
              <organization/>
            </author>
            <date year="2011" /> month="November" year="2011"/>
          </front>
            <seriesInfo name="Proceedings name="DOI" value="10.1145/2068816.2068834"/>
	    <refcontent>Proceedings of the 2011 ACM SIGCOMM conference on
	    Internet measurement conference"
                    value="" /> conference
	    </refcontent>
        </reference>

        <reference anchor="IETFJ16">
          <front>
            <title>Multipath TCP Deployment</title> Deployments</title>

            <author initials="O." surname="Bonaventure">
            <organization></organization>
              <organization/>
            </author>
            <author initials="S." surname="Seo">
            <organization></organization>
              <organization/>
            </author>
            <date year="n.d." /> month="November" year="2016"></date>
          </front>

        <seriesInfo name="IETF Journal, Fall 2016" value="" />
	  <refcontent>IETF Journal</refcontent>
	  <refcontent>Vol. 12, Issue 2</refcontent>
        </reference>

        <reference anchor="HotMiddlebox13b"
                 target="http://inl.info.ucl.ac.be/publications/multipath-middlebox"> anchor="HOT-MIDDLEBOX13" target="https://inl.info.ucl.ac.be/publications/multipath-middlebox">
          <front>
            <title>Multipath in the Middle(Box)</title>
            <author initials="G." surname="Detal">
            <organization></organization>
              <organization/>
            </author>
            <author initials="C." surname="Paasch">
            <organization></organization>
              <organization/>
            </author>
            <author initials="O." surname="Bonaventure">
            <organization></organization>
              <organization/>
            </author>
            <date month="December" year="2013" /> year="2013"/>
          </front>
	    <seriesInfo name="HotMiddlebox'13" value="" /> name="DOI" value="10.1145/2535828.2535829"/>
	    <refcontent>HotMiddlebox'13</refcontent>
        </reference>
      </references>
    </references>

    <section anchor="sec-api"
             title="Example numbered="true" toc="default">
      <name>Example Socket API Changes to Support the 0-RTT TCP Convert Protocol"> Protocol</name>
      <section anchor="active-open-client-side"
               title="Active numbered="true" toc="default">
        <name>Active Open (Client Side)"> Side)</name>
        <t>On the client Client side, the support of the 0-RTT Converter protocol
        does not require any other changes than those identified in Appendix A
        of <xref target="RFC7413"></xref>.
        target="RFC7413" sectionFormat="of" section="A"/>. Those modifications
        are already supported by multiple TCP stacks.</t>
        <t>As an example, on Linux, a client Client can send the 0-RTT Convert
        message inside a SYN by using sendto with the MSG_FASTOPEN flag as
        shown in the example below:</t>

        <figure>
          <artwork><![CDATA[

        <artwork name="" type="" align="left" alt=""><![CDATA[
  s = socket(AF_INET, SOCK_STREAM, 0);

  sendto(s, buffer, buffer_len, MSG_FASTOPEN,
                 (struct sockaddr *) &server_addr, addr_len);
]]></artwork>
        </figure>

        <t>The client Client side of the Linux TCP TFO can be used in two different
        modes depending on the host configuration (sysctl tcp_fastopen
        variable):</t>

        <t><list style="symbols">
            <t>0x1: (client)
        <dl>
          <dt>0x1:</dt><dd>(client) enables sending data in the opening SYN on the
            client.</t>

            <t>0x4: (client) send
            Client.</dd>
          <dt>0x4:</dt><dd>(client) enables sending data in the opening SYN regardless of cookie
            availability and without a cookie option.</t>
          </list></t> option.</dd>
        </dl>

       <t>By setting this configuration variable to 0x5, a Linux client Client using
        the above code would send data inside the SYN without using a TFO
        option.</t>
      </section>
      <section anchor="passive-open-converter-side"
               title="Passive numbered="true" toc="default">
        <name>Passive Open (Converter Side)"> Side)</name>
        <t>The Converter needs to enable the reception of data inside the SYN
        independently of the utilization of the TFO option. This implies that
        the Transport Converter application cannot rely on the TFO cookies Fast Open Cookies to
        validate the reachability of the IP address that sent the SYN. It must
        rely on other techniques, such as the Cookie TLV described in this
        document, to verify this reachability.</t>
        <t><xref target="RFC7413"></xref> target="RFC7413" format="default"/> suggested the utilization of a
        TCP_FASTOPEN socket option the to enable the reception of SYNs containing
        data. Later, Appendix A of <xref target="RFC7413"></xref>, target="RFC7413" sectionFormat="of" section="A"/>
        mentioned:</t>

        <figure>
          <artwork><![CDATA[

<blockquote>
  Traditionally, accept() returns only after a socket is connected.
  But, for a Fast Open connection, accept() returns upon receiving
  a SYN with a valid Fast Open cookie and data, and the data is
  available to be read through, e.g., recvmsg(), read().
]]></artwork>
        </figure>
</blockquote>
        <t>To support the 0-RTT TCP Convert Protocol, this behavior should be
        modified as follows:</t>

        <figure>
          <artwork><![CDATA[
<blockquote>
  Traditionally, accept() returns only after a socket is connected.
  But, for a Fast Open connection, accept() returns upon receiving a
  SYN with data, and the data is available to be read through, e.g.,
  recvmsg(), read(). The application that receives such SYNs with
  data must be able to validate the reachability of the source of
  the SYN and also deal with replayed SYNs.
]]></artwork>
        </figure>
</blockquote>
        <t>The Linux server Server side can be configured with the following
        sysctls:</t>

        <t><list style="symbols">
            <t>0x2: (server)
        <dl spacing="normal">
          <dt>0x2:</dt><dd>(server) enables the server Server support, i.e., allowing data
            in a SYN packet to be accepted and passed to the application
            before a 3-way handshake finishes.</t>

            <t>0x200: (server) accept finishes.</dd>
          <dt>0x200:</dt><dd>(server) accepts data-in-SYN w/o any cookie option
            present.</t>
          </list></t>
            present.</dd>
        </dl>
        <t>However, this configuration is system-wide. system wide. This is convenient for
        typical Transport Converter deployments where no other applications
        relying on TFO are collocated on the same device.</t>
        <t>Recently, the TCP_FASTOPEN_NO_COOKIE socket option has been added
        to provide the same behavior on a per socket per-socket basis. This enables a
        single host to support both servers Servers that require the TFO cookie Fast Open Cookie and
        servers
        Servers that do not use it.</t>
      </section>
    </section>
    <section anchor="acknowledgments" numbered="no" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Although they could disagree with the contents of the document, we
      would like to thank Joe Touch and Juliusz Chroboczek <contact fullname="Joe Touch"/> and <contact fullname="Juliusz
      Chroboczek"/>, whose comments on the MPTCP mailing list have forced us to
      reconsider the design of the solution several times.</t>
      <t>We would like to thank Raphael Bauduin, Stefano Secci, Anandatirtha
      Nandugudi <contact fullname="Raphael Bauduin"/>,
      <contact fullname="Stefano Secci"/>, <contact fullname="Anandatirtha
      Nandugudi"/>, and Gregory <contact fullname="Gregory Vander Schueren Schueren"/> for their help in preparing this
      document. Nandini Ganesh <contact fullname="Nandini Ganesh"/> provided valuable feedback about the handling
      of TFO and the error codes. Yuchung Cheng and Praveen Balasubramanian <contact fullname="Yuchung Cheng"/> and
      <contact fullname="Praveen Balasubramanian"/>
      helped to clarify the discussion on supplying data in SYNs. Phil Eardley
      and Michael Scharf's <contact fullname="Phil Eardley"/>
      and <contact fullname="Michael Scharf"/> helped to clarify different parts of the text.
      Thanks to Eric Vyncke, Roman Danyliw, Benjamin Kaduk, <contact fullname="Éric Vyncke"/>, <contact fullname="Roman
      Danyliw"/>, <contact fullname="Benjamin Kaduk"/>, and Alexey
      Melnikov <contact fullname="Alexey
      Melnikov"/> for the IESG review, and Christian Huitema <contact fullname="Christian Huitema"/> for the security
      directorate Security
      Directorate review.</t>
      <t>Many thanks to Mirja Kuehlewind <contact fullname="Mirja Kühlewind"/> for the detailed AD review.</t>
      <t>This document builds upon earlier documents that proposed various
      forms of Multipath TCP proxies proxies: <xref
      target="I-D.boucadair-mptcp-plain-mode" />, format="default"/>, <xref
      target="I-D.peirens-mptcp-transparent" /> format="default"/>, and <xref
      target="HotMiddlebox13b" />.</t>
      target="HOT-MIDDLEBOX13" format="default"/>.</t>
      <t>From <xref target="I-D.boucadair-mptcp-plain-mode" />:</t> format="default"/>:</t>
      <t>Many thanks to Chi <contact fullname="Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi
      Nishida, and Christoph Paasch Phung"/>, <contact
      fullname="Mingui Zhang"/>, <contact fullname="Rao Shoaib"/>, <contact fullname="Yoshifumi
      Nishida"/>, and <contact fullname="Christoph Paasch"/> for their valuable comments.</t>
      <t>Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, <contact fullname="Ian Farrer"/>, <contact fullname="Mikael
      Abrahamsson"/>, <contact fullname="Alan Ford"/>, <contact fullname="Dan
      Wing"/>, and
      Sri Gundavelli <contact fullname="Sri Gundavelli"/> for the fruitful
      discussions in IETF#95 at IETF 95 (Buenos Aires).</t>
      <t>Special thanks to Pierrick Seite, Yannick <contact fullname="Pierrick Seite"/>, <contact
      fullname="Yannick Le Goff, Fred Klamm, and
      Xavier Grall Goff"/>, <contact fullname="Fred Klamm"/>, and
      <contact fullname="Xavier Grall"/> for their inputs.</t> input.</t>
      <t>Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas
      Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves
      Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun
      Srinivasan, and Raghavendra Mallya <contact fullname="Olaf Schleusing"/>, <contact
      fullname="Martin Gysi"/>, <contact fullname="Thomas Zasowski"/>,
      <contact fullname="Andreas
      Burkhard"/>, <contact fullname="Silka Simmen"/>, <contact
      fullname="Sandro Berger"/>, <contact fullname="Michael Melloul"/>,
      <contact fullname="Jean-Yves
      Flahaut"/>, <contact fullname="Adrien Desportes"/>, <contact
      fullname="Gregory Detal"/>, <contact fullname="Benjamin David"/>,
      <contact fullname="Arun
      Srinivasan"/>, and <contact fullname="Raghavendra Mallya"/> for the discussion.</t> their input.</t>
    </section>

    <section anchor="contributors" numbered="no" title="Contributors">
      <t>Bart Peirens numbered="false" toc="default">
      <name>Contributors</name>
      <t><contact fullname="Bart Peirens"/> contributed to an early draft version of the this document.</t>
      <t>As noted above, this document builds on two previous documents.</t>
      <t>The authors of <xref target="I-D.boucadair-mptcp-plain-mode" /> format="default"/>
      were:</t>

      <t>
        <list style="symbols">
          <t>Mohamed Boucadair</t>

          <t>Christian Jacquenet</t>

          <t>Olivier Bonaventure</t>

          <t>Denis Behaghel</t>

          <t>Stefano Secci</t>

          <t>Wim Henderickx</t>

          <t>Robert Skog</t>

          <t>Suresh Vinapamula</t>

          <t>SungHoon Seo</t>

          <t>Wouter Cloetens</t>

          <t>Ullrich Meyer</t>

          <t>Luis
      <ul spacing="normal">
        <li><t><contact fullname="Mohamed Boucadair"/></t></li>
        <li><t><contact fullname="Christian Jacquenet"/></t></li>
        <li><t><contact fullname="Olivier Bonaventure"/></t></li>
        <li><t><contact fullname="Denis Behaghel"/></t></li>
        <li><t><contact fullname="Stefano Secci"/></t></li>
        <li><t><contact fullname="Wim Henderickx"/></t></li>
        <li><t><contact fullname="Robert Skog"/></t></li>
        <li><t><contact fullname="Suresh Vinapamula"/></t></li>
        <li><t><contact fullname="SungHoon Seo"/></t></li>
        <li><t><contact fullname="Wouter Cloetens"/></t></li>
        <li><t><contact fullname="Ullrich Meyer"/></t></li>
        <li><t><contact fullname="Luis M. Contreras</t>

          <t>Bart Peirens</t>
        </list>
      </t> Contreras"/></t></li>
        <li><t><contact fullname="Bart Peirens"/></t></li>
      </ul>
      <t>The authors of <xref target="I-D.peirens-mptcp-transparent" /> format="default"/>
      were:</t>

      <t>
        <list style="symbols">
          <t>Bart Peirens</t>

          <t>Gregory Detal</t>

          <t>Sebastien Barre</t>

          <t>Olivier Bonaventure</t>
        </list>
      </t>
      <ul spacing="normal">
        <li><t><contact fullname="Bart Peirens"/></t></li>
        <li><t><contact fullname="Gregory Detal"/></t></li>
        <li><t><contact fullname="Sebastien Barre"/></t></li>
        <li><t><contact fullname="Olivier Bonaventure"/></t></li>
      </ul>
    </section>
  </back>

  <!-- ##markdown-source:
H4sIALp6RV4AA+296Xbb2Jko+n8/xb6utbqkFElL8qykciPLQynlQcdSxZ3u
06sWSEIiYhBgA6BkxfZ5svvvvtj9xj1goOSh0t23WysVSySwx28ex+OxabIm
T/ftzvjN6ak9PTy2h2VxkVaNPa7KppyVuUmm0yq92O9+MS9nRbKEl+dVctaM
s7Q5Gzez1XI84yfTqh7v3jfzpIFn9nb2dsY7e+PdO2YGH5yX1dW+Td+vjMlW
1b5tqnXd7O3sPNrZM0mVJvv2tEqKelVWjbksq3fnVble7eMCX9q38HdWnNvn
+Jl5l17BA/N9e1TAjEXajJ/gcoyZlXN4at+u63FSz7LM1E1SzH9N8rKA9Vyl
tVll+/ZfYS8jW8M8VXpWw29XS/zl34xJ1s2irPaNHRtrs6Let68n9nFZJBdp
0ayrFD7l7b/Os4ssrVrfldV5UmR/T5qsLGDhaV3Dvmr4oirxwNN51pQV/Jku
kyx3g0yCQf7UyEsT2FWwjJe4jPUsmSdZ5RbxslzAv/Pom3gJr+FAz3FlNWw1
beBC87KGW13DTeXWwhezrIFLeZMWBS0UDhAGvnNvZ2eH/loXDV7aMxhnlg5u
ZMkLmUx1IX8qaeLJrFwGmziZ2OfrYg57zfPM7eKkyuKP4y0cZvWs9FPV5/zo
n2b4eXeCk7T0I6+L85/KspAP43F/LgHk4I7ylMZw4y8mdVr+6V3TGvrxxP6U
1kuATzf847T4W7LMiuCLQQCQ0fWVibwSX7cpymoJ716kAIH2zbPDnQeP7siv
d/ce7cqv9x/u3ZVfH9zddQ88evhAft3b3X0kvz7cfaDP3nu0d899unffDfZo
x/368KEO9sAN9uDOnk6xt7OrD9x/9EB/3Xu4B88CThdnreXvPXi455b/QJf0
YO+ezrgLC9FfH7k17z7a07Hv7N6557d61y/0gVuHe/bhzl09oYd3dtxW7951
W927/8j9+og+PRo/8UDLhGy+mHlipoPcu/tQHy/zJk2K9TgrGiRa47qcvavH
PaMtVzDeeJUnWTFeIlrJE6s0q9Kilu8bInkwUtHoA0n17l05TqrZYpyXl+Mc
SGcxu+pOUCXz9H3TIr/42OnJHmAwHYa1jqTRz5ih+c7z42O7daea2+dpkVYE
r/Y4qRr4o15kKyT4f0tnzTa9JvziNJ0timyW5PZklc6yM/iV3iOaDDhWXWSz
tLZAcO3JVd2kS3tQw4NN/Xv3N+wpa+AjoHQWoMU2i9Teey5fw2NNcp7aPbv1
BtAyqVO7e59XoPxk9xEvKKnOkZotmmZV79++fXl5OblzvlpNAP9unzWr27jA
+jYeIUDj7b07v9ZplaU1/DaBg7kNgzxbv1vPExhx0zH9PJHnwmM4KOB/SX5V
Z7Utz+yLsjjPmjXwHTgYZKbHSV3DrPYl7AD2uYSbre3WCYwOfDRZpRVviVeE
SEN87wyOEwh6gYQVGR2eok4zsacvD3D3uxP7Qk7vVQmkA1YJxHy5WsPF25NZ
BnCSjuxFmdv793fvTOKj24U/D169ebv7YMOOgczBYpZLIMXxF8CAfl6nizy9
zIp5/NXxxD5J7V+SlHhg8MURLjeplmXRLOJvnsPBAggv1lXdRCBWJTPi841K
AgD+V7C5FDa1Jmi7zJqFPT44/aleZfO06pzlwWqVZ8AUX6XNpQgNb9I6RVgg
KaJelCs8jgd2i08jhLA/r/Mr+nIEGJCcr3FDRy8PrwOSn8pCYMR9+teJfZUB
KrU/P5zYN0k2y9bxxwfAGoFDF4skP190Tv4ngIY8vYo/P4XP4QSu1u+y8AiP
ACoa4PdZnttVCaA4zVPblCB3ARmZI4T+350zA2yfpSmKTgTSiJUIMPbg8KU9
OXp++PrlS5AFijO4YYAwC7eggpddeigPHulC3tHT02d/3r2/4Rw7klbwnWPs
bpsv13mTrRKABcS5J+kqL69wEZ294cT2zyDxADKNAOrgWGBJ9+G5n8rmZTaH
g52W73fvTPf7hwcUw/PgJ7cel++3h7fwHDGhSfLOlR8nII4urt1vuO5wdd+D
BO1P9Ek6m+Ae7nRoIZDCrMgnOMBkPcsnyWwyTW+v1tNcaHV9e6kbGy91dGPG
47FNpiAjJjOQQk4XQNlA0F/TpdZM64mw2wSRS8j+qirfX40s8IMc0M2J7qoz
pNUIwQ6JYd3QEc7dJSGQ4bURTNa4LluvAT+TOr7XiT3oG9gukyuc/gLA3zLn
w0Hw+JAFEWcBgR+kMZBMgVbGUwGFW/S+BruWQed2eoWQXTh06NOS7JZ8sj2x
cmor/UoGqkXJ2vqXtCrtGxCn5+PTCvjrabZMt/sWAbcP/18QvlYJnBnQP1wZ
UN31jBeG63ETgZSK0sMczxqGK4A90Hk2i6Sx8AUM1dBVAU2E48zrckQDdDYz
L2G1+HCV/vsaJBS47isLuJys6nXON74Fy2rWMEcOStMlTFCXKQyyPZHd15FY
ADcPEERgAzofgA2QJZSDcnwXyASfa8/twkj6AlBjJCrZ+Rq3CIMuyrqpJwyx
DMAgeX6H5Kgq4YBoYvvhuwz//gTffEeXDZsEKriEL1bTT8YaP6ueY23z7J1A
CrAaYN9Veg77rmAFHz6I+Pnp08TgEwuA0ykQa5st8Z5hZUAk5tkZET/QXZMr
ALKTcpnqAywDKIjPFqAbEZODpWXA8TOQHJCtlpdw/X9PeUKUbD99MgTDMPaV
vgDncZ7WtFH4FbaZWyAtMAVgYgHLYhylNQHCAcmHuWETZWFm8DGuA0ULBDeA
vIl5DWNW/es8Qd0IxXl7MHtXlJeA5uf8BC0QtYFPnxDJciRBhncgX6LWAF8K
LJnEFuklnW65oqWj7FfySTAg1KAhFU02I4yr8eyA5uTzWukvnXsKEm8Fd7AA
hs7HonTNLtcgSUyVyDCwTEsgIz27xqnxoECSAuJ1Zdc1P4/zKGObmKfvV0iO
ER1J5sBvAREQQlu0qwIsSHLBOXgsq0JaB9diFKeWiFRXIIwAgIhoCW8jJNJG
P3zwYimdHqBeQyeClADEfqBpZ2YZCpYgzsDBn5sugR28vpF9y8B2ArQ7pYPB
DSFJqptkuQKo+PCBZSNYBBCxWZVNAZH75uU94+vPEiDzrwHg7Nbps9fbDmsA
DAzSBhJIkL5cAl2EQ9eLIuKB5ACJFV18DeK03KonFE4ghJFARnR3JtdrtgCi
5Hq3FRPWq3PUkeYWSaE9gwXC3a2SGY6YFPGwhoetgLzhtoQiI7DAyIo6QOiP
8L2yDlc5cjB2Wa5zoMRXK9SSYI+XANIMbEV6BuTvrCqXOK05SxNk+ny1AR1p
OoQJyBESmjNBEl7SAqQGOssrkMCQEhm/VbhNYStwykKGmAmjCcctARCS5GNc
3jIB0gcHKswOfnHrg5u7SPJ1AuQTRHY44/Q9QEgOWsZxWpG+j4M+Bbm1mOG5
HROnESKA2vunTyNaU4l0xjgOvS6ET9FWiJg6zAXSU4u0T6gqp0NQtgpmhc8q
k2fFu5oRVNkPkhWUZAB7a6QoAGFv0hlihSy+7pE/gO3ma8CvWK7cenkM/wgw
o92FCB4ygaNXh/wp2gaAMQCfQajwIxoVUNxZOpacIY1BGg4HhrKKgo8S3ksg
FbBKEMJSUqkn5i3uL1raSMBQHkFTXY4ELlnim0zU7NsXB6/M1lsd7kWJyvsB
2r1EO9pmeAFtD3mdwkQ9MrisKWg1uMTVugJFIgU4FxSCy56P8fThI3wuJaII
O8pwI7OrifkFbUEgKoC8moOMyFfL5CI+JUemE6ILlsyGeD0B2TYK9hVa0eAd
ZLXZDE4DbvYlCngVXS/OdO+5W3ZK9BupFcsjjmsDeqCoQCwSwOs8L6dwLG5m
5sog/U4RZO4+t1svTp9uO+HqImvwcHEG4GlEyC4yJEYho0lacESy8sQ+DXAZ
VopP4q93/aLhpuic1itYcTwGrKlCo0hN70zhZTixZjFCdQ/QFOEG7tHOqvUM
BQrEaxAulihQiAmJgA0VIBwApBS8uUs8EZASSLBCoSep5gQscBJAfVk6QHhd
gn4IwwDZQbGWwbjGK0Nhe93wr7y1ZTnNcpRUqpQIZlkB28YFLUiPtb+8efHi
0G79kqOE+ybNMyQvAJ2X9oUs9LBcLteFMPdtZyoqAHDsubdYyUQCtqPWgeHx
Zk3Nhw/cC6WNrF46NMMRUU0gVgKrU4Q9mM3wANQoc9KkKZpkRvYEyMxsQb+S
kQvkrIaQeOvg9OTkZJuEEGQ8KOTgwdOwILmC5O7u4MMHMc+hNIkCqqDi+ICI
NLxz6MX4fRJf39BukVd/O+UMdAEzIHwnjjwzySLtA9gHDQX6R6IHbsoV3gTL
ckk2v17LI4j3J02AzLyxNij34c0Ej6OIyFg1Md9KEzSBJmjeLrLZorNIeBCA
8lwtJ82guuj3OlbmQ9Lp52qXHU+c6eqYI3cZ8VWLgczJC5e0pTXSCRQa5/hY
ShKeobMrkLBVLHV1tcD/pHormqaR4qM+dlP9lRdSZ+eAOYikddqsV7wwZARn
JcnjZCD0sk/P1the8M315X7dN5mjxFsr2CG/g1OAs81IbplXyWXBmoL4TJCK
AIlduQMC2tQ/MlAumJ3J3lmZ5yS/74MqbV8g3SkCUQS2XhMu/B6+RdkJtQiS
HBN9AkdJ5vNKWAUNSiZwtkeJqIrvn9C5Jzqmbo2f9o+9IYhRlXaJfrFz8SbM
kyZxvIouideg/NMPIkIpbJZIuIxW49/AhEgAKW1OYtCqRAsDCld0GXTSyfwC
JPaE5QAhcuNE6XIXNEg+Vq3vyqQFMTJVdWNCNk2dzgJnsZ4COOrBEccKePGq
zFBNM4zKAFPluqLD6NJXFtdD49azdYVMG8kdYUovlU/w+uvhs8QFzwGoZ2g6
KNLzskHeb1q7UrZco/6AJ0bOP9jciqZDrzvbLM7WaIyGXQ6RHeI6xNiB4XpO
HbAKpkf+CozDzgN8tybBXukiSAUspaFRpKZz6OWaBpTYfmrCRhTeYsskeURE
GEQeslTMgAcauohwhmDhCZG6Kl3gqV2koLDU9GZC9nk4SzL/9MDWhF0Zbjc6
eE1Mj0wdgEMkxRo+ZFQzJm0RwdEptscJgRUhsBEZB01uMcczNwD/iX1d5Fcd
cNZBL1Hjn6aoS1yCVMm0fog4BfiJpIIGcyhqyeJj9G8Wv+TurohbzJzAyNN4
LKKvw9uamAhFWHoOPSXTqxVsetA86RmWURQxQtOcfYnPGMT1+ZVDB3xAeMU8
pg9b9Xbn2gatp0j9mTA4WpzVoZWUdGERehIr4NZHBWq7VaNuxLYKwuWqXJ8v
AqOoiMrmw4frPOWfPm1PcGhahUjnJOLI8aN+QGBKd2DbGAP7J8ognLgfSnhA
pbcVyVQF3fW4Kcfwj/H2Ey9TDHEOvqyJtXTwpD8bh5BoeIbra0hiQdsx2efY
PAW6ZlJlZR0oEqSJZ/VsXQOJNxlGnPDcd3E3gTEEpiOLjCPdbnhEakRTQBil
YmhmOQttLv3HgtYuDr7wIDG9Mk7CFAUDPa45uo637t/bxut+QiYIvqtfCtgt
kF1Ega1HD7ZtWlVlZRwb3vrwoU5nY/oUrlpk0YaZU0HAhBY2nkD29HuiI7Ig
XCRO0XhcR/MUetMVV8mYgAqbqhfJHDVYdEuBjjGiIQAtUsFNNaqFUnWEs8Yf
kUqpiJ1rfr3K6nd6+UjPC8TOpEYP8+JqkHGqZpQQSUaTArP2wGGBOJ4SxYRL
SPz2OiiOs3K8EBu9WChDFp5VNZwGHznFl3z65CVzEIWqLD0j89dFBrKGkF11
QKBYEoI8WgXGaAAGqHx9+POJl8GV5zNvVR6oX6MVGBeAnvO++XHLiYAPL0H0
Qfmgj+IQJS90azpTZGUO2LHTgibyApAd9h/ggSi+1cQJem69dnZgUfCVEjtX
TdszKDt2ntEU54EFFcFkbB6C4RPRWIjeBq+gqI9WCRkM/ltXACww0hncPA4h
rgb9BmkVkkc+OreKZJVFB4O7TGjFbKpmY3ORxnuLlCx9ec5elJDeWot+sycB
zNA+CEIu7tkP33nYA9J8gnoLiCnkTPfsQWUctrCo4PJ7obRoM2xUnOiHMbgd
9WvpzO4rUXH2xLoaeFfRn6DcVe+WxeKOyYxJdsfAabeUQO9N9hyJxggy5GPG
HAiqHArxIlZQkyzn2ApJKvzYMVlbTPqeHVo1RQcgIxFrjAuNKwuWXUArJlml
JpZ4dOxUKfwyUNOdSMVK1YmwrIOGb1PIpjs+QwsZWi4KYXV3OJqzYrUY5cJQ
26LlwZGpJh6q6qwXRyjProw89UbXacI6j9Hr3UIwQ3EsPqJtshXALRG1Z4D9
8AGECYbBe2Qs+z/DP0ZuqvUTXE/7G9o7RlB8bL8kP4Of80vjnp8/XveSm/2v
r24+0x/6prrZTDDPDweHP/9D9hTOc+1MA19+++X9hVWWH++N7MEanSgpgN+8
/u2OnCf4TfdEG3nDYobdWhdkr7/1qiScugViMq3Aqe3z7S/alPW7kgmBvxYg
sv5Gu1K7t6Dm/jGSwQ2D3RCQIlS75qWBE7rRTC1U+2pAOlnPMCYvdaD02+Hu
E6D4u3172vRS58uvu6d4Db/hPdFMe+2ZvgLh20NufKn/ZzKZbGRuH/btd54X
cozij7eeghw4Bf1+ocbARF0IjueLQh/JKfatcOCDiAPfQjnvLcq6/CzwY5St
UF6xt7yKfatPs05UUGLfp/DWKWZWkBhSI60il/0ZSRO4zF6j/3m+JnHunB2P
IigHi2ehIxLOyBXHkowKYM6MHAhelq0GsObzTGI8WLaaXoGs1IDItNT5eOCx
CFNuneHc/B2pBiptifdAz8bFDHWFLXoNtyrS2GXLBaLbr0tvraNVwkGSbs/W
98Ddt8VL3lbjerjIhBzk6CWau6/9WpxanHAQ44BxNoe1qPlaHdqZxjTQ6CQ3
GgcRhV2v5FQZKOaggMoHfrMjO12rMYdcyksUfpMCTWv9mgmGhJ6hfhzou6EV
fkCZtYFsLrbPPhiZr6t2YB6MxuqHYUdu56LTCA3n4sbw3i2+CzbZif2vxjs3
6pSsyL3WVNlq3GAMljqncJ60jeOk6bujNAMCPjtX5t7Aw4FL5Ty5+r52MW4j
55SG3SX+8FGCQEM8wQeautZ1oPRJxE6Brq3Iw02Rb8b7uYdzWVCjO3BRGzg2
BpjMvSoOo7LGYHPSPNX5cfrstd2Kos22NaKQ5xvIzkE1PlgnuW7hnkjTA0W3
RCdTPzh1sCGw9DTJO11X5FfmuBK0c61R036s8SJ9440CikOhgnmaVIULvUjs
eYZBI5GhAhco+r43ewWXrXoi25vYK1WH81xv5L5csPXICKmQ6eprrNj2VZrR
ugVbTaDE20LcRe66+aH7112di6Rie6sGVNHlwV1WvXfXbyoll0RZaFhxtRxG
sgCzDNOC4LDlHJ3p0YFLL5UjO6EaLCgECf2TKzEReoIMSHoW0ucqPVvX1xEc
jEhdrji20Axc54hZDn7rqHIwoIsJ5G2heaVKMf2L7ZJoQBQLjBw9KeuOWlBU
kWdGcgGzRTp7RyCUXCRZrl4sElNkf/Ae2vuJB2bLNPCs4LSJXWR4HQyHNUez
ip1BR2CzzZ0dtg8AZ8DM1sVnsgaCh8Aj6pDEsKOQr9wbaW73GGhC7Ks9dyW/
m33y6oRSRifmLQAbxVPS0QIc5EiJ0c0AA2TnGnDDsYgkKBh9WWeq0mWJbomU
ArNqwJk5foV289CORP4KJqGhIc38VF4iRZVoEpn1MhEX4bxkqExnCd4M+sYK
ZnocpFdIVEVeJnMxZHFQ2lwCK4yIUAOOMwkAwzeXSYGOdtwerFizu8R4jl55
8x2/WzQudOgJejwz+ptllXfplcVMcFB/X/5ycnprxP/aV6/p9zdP/9cvR2+e
PsHfT346ePHC/cJPGPjj9S8v5Hv8zb+JSU9PXz3hl+FT2/ro5cFfb5Exz9x6
fXx69PrVwYtbHTMrCTXsISCb8apKBaki0+xjoKO7dy1TS8ze/fSJIXv3AUac
XpLNnKJoEVT5T3Z9rlbALnAIlGpmySprQFQbmYQDtIHypEQo6TSj7Mt/so9T
4ORZWdVi7CU7P0WkPXNODvuUjXn1gGiolmtEnCpNA/eITeVNijBhlKJwkj63
AIeJSEbCQKQXhQho0HIcoKbCqLNeqrA3NyXRmaKf7sHF4Ff9NBtv1gvH6AAD
DayZkX14IHoHL2VdjyiWpKFIVfSvqsu9BoaWkaYQrieW4MhkW1VkaSF3eO/a
6IyC98TN4bkUEXTC2JpcNprE1F2y2XIlFM4SiuAmOIXf05GdresGNLiq8xUl
PG1SWAc13Y1qsLX7X/DmD6HK/oMagv8w9lc+/uPHYO/2I3wXnOv4j4ExmH+C
s2W7lMAg6fbhlzda0eYtDR6yDcpbdL7Dn40D25sYFJqZ2hL6cU6j+Z+EAVjH
CahfGtsZxKqiAeEWn/4tFF0k0Qa0//KsuZSAYU5CSIF1zucaDIWhxyIziJN4
MSC+XWQJMbrBM2MV3a2CPeOMFZGKjQP1T7FFKxfVLaE4n/MS5whe3w4T6aLJ
WK5DrlguWy99xpx9r8Oc6LLrDeMQ/GdXDAupSig1QhddzYaFZQoVxKCaVygI
wBbQfNwOkWq7KtFdn4YOeQz0ipKcQFzw2TrItEnYO0udQh0G0LtEECZ5LoyF
7AzBAKw1I64y++Md1kPu+UHmISfk4A4ZJteGodIwkkXByQyYF5ZdJMKnExc7
QLAKujoFT6McxfqIY0VO1ZoPhgZLkEsSMmIN9EEEMBg66NBF4qeC4OvIPsW5
kJQgI+5oF/rjTAv9Pvh2iGBrQSwJn2H4RxQe2xPX6JOTMAJGwnZNpJuqBivh
NnhDhz1hSyNnrAyifILYIVYCemOHRt7WhoIygcpt0TVFHk4pvDyKBO9DJA2I
aEdvaoSnqsEsAawwa36upSxEQcHSDf0hbsuSvtOArCBiq3ctHGOoWx8Om3pd
ONVAQ+n9YyTeG9WBfNxDX56Z328YNlHGaqPRI+oVTGpREzeGrAIYtQNJ14Dt
uXXBfJIhGIGRhNaNEHV9sPOkB6FcwOMS0buhwOxmIUl9gXaNRwvvn2TLDEMD
1FLXgxFuROYzWOeCIM5bxe3pi5OI2LP4fvcuWp7CYJzDKNpWrSsiXOY1RdFh
xgwZUUizGbWniYw/kh0LekWtBvYkTPK4Rk4jEaLHdR5IS/FPLCm1XR2BpNQj
6fS/M/RZ+M7tH2/8879Nz5BP4xMcnuh/33yi23x4v6MRXZyc0zx6bl0mUQxS
I7zkOpC+diM3UIOpxuICijc2KGKgbNaNW+6QE4qczZNpiVyWcmBdSmUUokQW
/8b7E4RBEHRGLpSAA3upOU/PuSCJOGtUq/TBhhSKP89UKWKBYADXSBfhPP+y
IvvSaxeSwoptg5UADhoyKAF/QYuymF3L6d8kRXpYQyILUslckXAWN5v4k3Fk
DBB1cj4ZtdM043h/stDRl2FeLxlzHJXxoVxUCUGGn7hQxd4wGdwa7YztBSKH
KacVGRg4nIkjpPocVr0i6iqZvUsb9E1gVD9lnPPFDI5H+dxkhKCRbwHO3NqW
2LhomiBOU9KWpPbC4ArVvn2tDvqfn7R97FKWP37sc0aDEvtV8/yhO9HHXq/3
+GvmaaW9CtBY+ya4Ufn0Rh5vB9ZOUS3sUw6HRpxli24ng/K1Km2Uvh0oqUgH
SXRrQ7PaXrpGdjLDqhu9z4KCgdscuoteTidi0SG4OgM6oUuq6WUUJhYPnFvA
lzciux7GfbrcXhpdsxeUaia5YUckSE6zBP0IGNHuRVR8CdOgguDd3r1pdKUq
5SzKh35FiRlwx8UCcOjhjf1blAyesnELeUGUizUy4j5C3ywqNAGfdCe3xWSW
ZEIeh+MeMNAn8IGKbEWR7hLK3/KjDHJLqfKg5T4MKbdbkn450mF6EjzxuLbD
HZuA8g4FY/YqC2GMqLgfzDUxonJOSCSFCQ/5jAxDI8AVIUldRj7CAdN9tpQM
cLgC3ZUZ2FSi4Q6smqHMkWo1FS5uF6aJktGmN9r+MkFtxmkH5DHOVqGLDn14
ibcEh3LVeZVifG3p994+FPGzyzBkSNJ4Zbk/zVcTd1+ezJxK4/09N7oXo5J6
ckXOE/0SgLYWyWvD4Tts96s3PXEHEpPbnyitNmkMPegNvpmVy2lWBPE3ZLof
chpmPoF+g4Jje/FLhu03vA8MPIQmkTxwUFBEeMVugIozV7uZIcEQ5CCINFys
JONXtt1amgZCu/eCYAx8U4cJ3yN6EmboZlplgkNMEAhE+GXKB9dk/DYAcqiM
gUCO0L+gvo7mhtPT5P8C7Z2AdW5NBRwU7uOskfWqtH364i81u/m1oIIG4v/1
FYrULFYSkIFI6WVOvp2OyxxQ2plKY7HNkBFInaqbWClOO6bKllz3IIzMYUlS
AWJaCT918q8udMsVm7FsXnEVpFTJ2Q6M0x2HltNBIv9cO13lS90fXuTFv/pC
1gfEzM2y6Q3kMvsRgexfx3+U4FpcxL8NxKP7d/qE0Otk0x6Z8kZypsbP/qv9
t2g/cVxtVzadTCY9ZxB8Cu/cRNIkABoOrSy8UNkKsjzdBNIqcB5qXn0xR1EA
z5tZiFeiexHiNGIZhlRCfFnJRGjkHGBARqXIIdYQVDJYIXMPGD0tjafExGfD
kXdNlXGJApGrkraiNphrIhEuGZC3HpZSc8iziFi9dnxm1SzgXRe2E3Fy5AFV
2qyrgiVGBSt08zYUMYc74yjLbmCoHHccTzotOXaRor8kL40J8SXq3z7+vqO4
ivsoEf9wikXWXZmVQp24ZMJmI3kQgZrV7bdISNfApJ5oCzI+YABuYGKJFJ/4
3DQOtOVgJtfMNI0UIxc45MrB6s0rwTcbvF4B4d4jw6caOHwBNVqZuJY4GSny
fbSK3mjtAryCnGpaqAdSjTVRBZS3GhPl1yQSA43svHCIb1L8QoJvcHbKHKcg
pxr5ecbey7CyTY+OoBUTQvExzv4y4VcdZEbBGlFxCJXd+h2hCEN56lY6caki
aVB+ovEhRuSXVRFLzr0EQbYJckFl4fUiqbjGSrxPkaI1ro1jwjBNWHCcFREM
P62znINBs/OirHoAemKiQcgKTlU+QLcdtWFfCZRz/rZJlAlJlOyN7pjcJ5ex
UM/Rm+R4Dpw2rphlTRVYVJpnR7YL4qgdDQ1NYxyz16JzagdDMpBirGWCQpqT
DCU0LFQK63Jdza6l/8F1YthtUElRKrI4SsL0vIeY9NKigIRS8pf6KxsyCGww
hLeuayQZiB7oOBDwpvGZUYEeNSIS6xnYKVfneH/VbwZqD369C2XApPiGdvSZ
ot5PuP+tNz9tf4mwJ//GMt8fxm9+AiLzpxvKfF8iv32JnChL+M1kPj2LG8t+
e5uEvyNlBp8r/BlzQmEGFVOMLVLbsK8HFsbUJOQ7k7vb6ndn4VAIIyJCUlVX
RhRBcgeHyiCmTwByTrO5hmYTA6iYmM3THP9g6qUG+5BjsmkFsxXyNLQFUjTf
+DK5GqMMAdT9XYq1EkotcRSH+wa+HFVYmd66lzm8xMQFoqXegXDxqkQTY+29
sXFR2bCcLPOkNRWELLWkFXqoAOEzFvUSqW/lFuQPVUo2GDmcjQJ4uFE0L9S+
yoerwsWLGnE0iFY05uVrUWML66ol6yOr63VK5X+5ysN8zTMQ92DfO3NsVxmE
ogvKpasLEgiaWC5SUnKwsghlMox46vUZKbkEByTB5CU1RzLAfBIUWmjx2DWG
qpJgZkWNha/pNGuX9e2XEM5uXLhWU+YUk0PKA1VWC7Md4juUTA2KdJEYZ7aL
lu8yhK8gNjm1a4BM6aTj/JQyAF41xswAPGEsnOj3OYCOVLrTStG2E+rCeUYm
LN7Lsc98oYqQDyZ3XFUAvl9xqsXVggyneWDIV8u2F4KbmkCJu5L24a30rgYE
liPxFWV8pCtP68JY8My5SgwItWV5ls5dREavdavIJXSi9mWVJG5IzH4mwwrh
WA5L+X4dzAdA/4xluVrro2isWIzMnaiLZhHWFDa9kHC5iK2Gqh5fY7gOtIxe
pbm/YJ9CHNZk4fmTHJ5C2CM5S0OJWbJVQoRGH5XafK5Pdyd6xwSaJAqHsBlW
L2+BpAvTCQKvwsNDyYQ0X1woXVtEd+CCjtpZYXbIEMmityMocqFmC8h3yk1r
QEXGE11mXP9vRAxlFdR3eHNyCtd0znFXaTObsL9DlLNAEUlmDREDmGym5KBJ
k2qM61Q+46wAbaNrYKEWG3yduAUTDkmBtstNiS0ETqR8J4WrzoFzPzty6CnO
HpRtpVRcuA/xtnFcYopOAnR7DBuvHfULZ+i5odBMocPW3k4wsNaR6V1doOWc
VwB1oBG5UQOm3nNCHFT63Xcc4UttYGpavvhS+mgKB1XMp9NPxBCXnKARGkqb
EvnhIEtFwCAaRzVJSRAPdYS+i9zKJin6/HodDUNZT9t2Y7Baa9ChUVpOBi3e
OWsVqhy1JYPYYjwKvFBkvjFbXJt3NKSlbDva0ecSQhZK+pYIZFnjtZrwlHqy
rTdUH72x5mRupjkddOrBpN53n5ihWZA+tVPEM81ocRb/+bRB8nedjN+jJ20d
jmbbmPL/R7t1OsLSulsnoxr+eZGdpZiJRqFdb5HzSkLC7+whV0rnhB6verdK
98ingRKu80dGOrE3lNUgXuq0Jzysm5aB8Pt6Q80g9+4pg+43WfKAX3KlafB9
a9fTVI/eRZJnc5R1cv1CCBPfOpKEGhlhqv3FemxAN9HmADD6o0X8Jk4E3p7S
zJhRvA3KGoLSodbix0gzB+WYod2uVDxcIjqMbie5EIWKmonkEIUZsvtpibqw
ICn3NemplEtqIuKdEzAji7VEjuYi6ulW2+pPEI8VFqruhOlRFlsDEsWAk8z8
4lyYLkNJEhtFIYO9FGUxDvyfqBj519BPUCTLaXa+LtfY1GCeUdeEdWB+jvyZ
5Grs24g0KykjF+iz7D2M8hPJZS5wsbVLI5UPWXojMzVXI40nRhwbdOg4wx5V
QmCxb02y1bK8xj1Ndm/CMlx/m7LHVN38sqIMShcjkTgzAoq2TKrZIo6EmI/y
2nIewywolER8PYg0cMBjDq2nWoFeGHl2G7L3upiVIP1tiEO0WpFkBbt0KQIa
thfwh+ESyOGK42gBAivgERaYRODd59UTw+AWJUQ3/QpDokr8RNI8FatN51H0
tByEmgYVrV5gUqdUV6aF1c44HbqQKGhmQKoSusxVTot5sMnIJ2aibhPD95IM
yQOTMCsUF+FzHBNP5bk5i/NZ4aEja0HleZoV86hWSDvaE21dQzmQ5L9pFfxT
b9hgRMpgenxvrAylivDSKexiwAFYr6dnqLtxpwqKlRsKixWXrksd8XEGMNwF
y5VZsWb3BRJ9ChVkC0NckiKtqPhjzR18iuS8p2LI7ZYaoAtl0JgBEV3nPjiR
U1SiQSgDxFVg9tX+mOJhTIsy8dZFRGIfvX4lTUNcVzJ9U6mjS0WhnZLpQnAi
LgvqOZDQjA0lfQYzwjBqU9LJbObdPZRIUV1oe5G5xP0Zjfvr9ZpfVlkzJGKx
kmEOf/zxdJtiEdsuMz8JOeiSYC0lF9/BJ9HOwwlEIPN7GYXEjB5/jag2h/8X
zvp7po5IjKWy6HxO1UglFYqZOHJebocxlcRwBCw0Qgwy1YE0N4vuvt5tAj+X
FLlh9ZDil7gNAi7gzdP/NfYVOrFF9adPUhgfYSyTNhdnCYCfvRUcPJ4eTHzL
bwcGuYXJq+n8lt1KauPrp/tyzZNdNxf2wMZSxxpQ5ZJuRCQzbuCMeqNxEF9y
UWZwIQB775yZIjLZMvi7shaxB487HAlbplgAVnBQRT+QZ45DEL3AMvHyxYkc
taTzwyUPa3phNxImtEhi1yLaesoWwgJVh+CnuU9QHQi4ajig7n3hnjiewsWG
OasLrsy1oUDChJVyefqg2O5lGWaPUQF05owuII3kZelQhaAXZrkQSg5mulDb
M+L75RI+m6uV/7uhw3YHu8J0GrEaSUtLUnAyjsLuUoFQGNMIQkSrXsmEC8uy
yMTtXuKRWGWakx3XaOWviX1VBu1eWojg7lu0ECnK28sLpSLXIILCUBQ67pID
TSeAoD+MnU3JnS5m/bMIIY4d3UEQdI8+fdkJRGeRhoMshfVNDJm6SFm7YuTn
AlBJdeXZo7qyg7saUpG8UNt77X1LQMOICS0hbp7NyTkyrImYVNcwQgB6Xb3c
HrNI/08cs8g//cV23bddx7bEL4az/mn/cHd0uNd52319Out+dtJa98ehYov8
bc9H7QHqagYL4UUGDvF53cACwm/5s5POAOLZfnl8SOGV7GVve8Fh6I4H/Jtt
4SMu7HC3/RyuHbYQfYmfdbfg3fuwztsHhz/3OP/Db779FqJz9j+ffQv009qA
vwX/RfcWNu3g5lsIwFmiEWQL8Ye9A+hBO2p0wuSC13uDM9h8C7Jz1AJveAZB
OIV+O4k++2jMi/QcWBFaSU9n+yHpu854WBZ9lTxkRb6ex40MfkjwXPCGJ6t9
PPzWBpnIde9jJiZta1howboKZy4k0EiLm4l9LOF1jXqotgKNfzs8EFVN1YBn
lOZznbBi3FNifZg9sufHoP4xr8qVD1ZUXS6TbHVUHSlAsUCBh9sX+oCvMzRs
GjVEO9nsFy4pPdCFG72Xlxn6ytBd7VwBSeXODHcVdvRhJhgImMT0KPfLBMfc
UJvZSAC7DZd3lr3vyrbYluCAZRsYTHp4Hh1f3A3kzl6hp5eJc6sqYrIul25A
Im4pNoZEUK+sb9Vpio2bMDXtvX3sNZe9+4/YenhQhDCBlkDDGp7o30uSAfLU
tz40L7J3KZ84K5sdiePiPgpMeFAy2SMsPCB9oiSJz2CdNqyBSYl0YhBwcENj
aOemMDiSQnNWFff/6vW2+2sIFqK90dKidQeDfjYXYyjSPKru8/TfsVZehIuS
K8htGtEcgxqwlsrVHQS2WBOo1NpjUmVihyKeWAX77QMVtE8X1Cve6dKrTd5O
xM7adNCTNdh5KSETzYyK6yWcjN6xthmxtpkD70Hrlfvqm3jEbiz79Yh+myW/
G4p+KPsNjYBy38fTtPtxS/T7WobNDLX7WCByuFX0sdtAsvsiue+r109yXfex
QOpz6++T+r5W6PvPcv5fKvF99frjbye/qbB0Jo2xrpWWYOT0i0ZuVZr7YjnM
VSZpGaUoFPY7e8K0S4S0muxaLq/Krcon8sf6sI+7rSn0JCm8DyhPG9isq1Ni
hzo7GnRFLtJ8xT6RsDKRaTV6fJtGPRPJ67rJoRD2G5MSHi1jx1QixGiFZNty
5QJm1Nk7zI03WgM68KC5MszxwZAfteEAVUpSQSs7dYIdNCj4aH/Mz8RkURUq
Xh7/718PD44PHr94ardArXUVtjOf5BDWoXeZ0syFlitNxYx7ekWNggbA0WRR
KnunIkp8QRsNHAi+v3keJhzFyKLmP0gXPPbrL60czPidaMD/iDxMibwfkTlj
8m9ubZ1GQl8d+48pI8HhBefWP49+8q3yPQVONzTTGCI+dmMScxCcehLko22G
5VaaaF/+0iAmR4Uw4J6MRhGaEJMFhxGhvcTocHVbelsAarvA7EDZMa0QI9PX
lkyS0BNtvc3lwyl9aiMPMhv22d/fAFPbxAt+Qm3Hb0QzDJHgDL3eEjpKNlUH
2vE1zSTjs00R+RxbJSsCyo+h5EHJ8bYJd8NKY/ZjOCcKE1Yl4x4LQc2j+PZW
yEIwdruIBebU06Jc7YEuO0ArSdOODe5k1qVJxR75rtPXxEApgcSN1ER8efzr
s4OT08MXr0+eAq56lTbr8x8HmXo+iNdFJkp4MqLpk4PTg1+fHb1q+2dNEFbb
s1+N0zUYXSvxzLX2ksYkG7zHkdS74ZxeXEGLn2MwNPmpFxIbHjibXFQA4UDQ
eAD7IipszFDomrsnUT6gOuwgFcy0Y7B6BNU5MeiIdjtm0cZHTbT2vm6HCXFU
N1W0CPHPeUxizl6+A96uUkybzPULKC7G2nCMdYCE2pGmJVT0N28QGOjBRx/7
tPIyBqfAEj8bHHT25RnlrSI9ZZif3K5GM3Qub3lPZIrwPSKjTOeEHaKl5Crd
bGBu/RFGCIeLu7b9xxlVC45Sx4fwU4hd1vBsjpILuTYhub5WYvM//yO7fabs
5iDd7ymW3dw3wX7wExfX0NrPwBl8a3mv9fHX5Hre4OdzRMPy3dcJhz0iYcEV
6cazZEVIydB0i9suuBzTz1CEI5OgdGDtDpP0DxPxfwO6Z4Yym3HiYVaIeMg1
aas5SxYqWfVWOSdJJMjlriNihhZpdJccw+wa0POAmzOpuX2QJgGBlXoj86si
WWYzs0xWK5ifgkmQqerfzn1/fQS7cRbg8OhM63Takb0BA5hpzn4jXZ8GZSLM
u9DCFlFVPM16w0OR/ietSGUKrXwnzhQtuoIhBOyfocuUzZMAt0W7KsgjojL8
yLoPA0meBf8ojpQ9Rix78GKmV0HuYjRZ70Smb6IRCbCdNbkPO2tyX5lWwkLf
K3HtgWSOm8nw8jk6g4tTjcuz8RSj5JcpZldl9dK5DUKAjbsGdJhdBAEXWRKn
ZE2sE7Wd1E6LZWFB/gijSMVJow5Eqb5SjILkyGvLk0S1SGAHej3kUEP9CpPA
z65E1Ob+Td7doE879yBbxm5eoSQqTXJErsbYw9jJqouLfTC0SVQnjZAU14zg
SmQUoOW2lVw8ayGRlNkZGK7Y/6J+tMHoIukM0+mrxGkWIyre26w9JvefVltt
pkBT8otSFwwnzw5Hw8vVTMwX19rwBVwiQnpddY1OyFJgnZixQ40KubuIKR/K
V+Be8nYlWA14pkSFTUx4iHP3F9ngGhv2c2VBrLLRVyjcyxS9H+orvbJY76fu
lR5xsyU8dmb5V9kcLtYJnJsX1i+HbRLO+mXE3v7hX7N9GW/Q5me7s+g3kRul
VwS8mcFPpJkbVfn4MtPfZ1RZ59hjX5gqSibyAf19IpbG4tOjklgVhDJjvsgq
obh21yWCIoj7s+K35JNtCa1w+VuGVcjaiUA4QxyH3xmE60vVixLHc1H6gVmw
TadajYMHakIOBexojS8qse5jX4neBFQX19RJHeDcMYmwgKPB3P+QUke1njBU
F2me635Toi7bGVMjxV2aW6LdWDfUlsNicHl3fQCdVeNslHf27BQ5EYWpnFHa
mpgA2+lpQoh50WHDkwjCtkASTUf2RVqcN4uR/UuSr9NtHavJL8gibIw1Y3sU
J/CiXczu7oPmAqOhKKNfoy0IBFLiknO1bYWBM9ok4NlrsbN5PxXJ589eazUG
qbkgl0TWSC5aAgiVFtiQVoGK7WTlyvWXgSPC2IzLdKofTPrhHvHROd+Ipyet
4i5SYiEoGxK8cYmlTjgBFpcqK6XqHVxeBVUm15xRpFDaIxdy0Fo+apqUSmIj
CQyZSYUTDKaZUf/dqJxEjy141I+ZUd/WVkmVRM9bkk+0ZGwkLlFFEynN54pj
uGg3Ls0OY8VlMpLwNjOU5S6yqiy4gDkVR+QoHP8S2Z+5q+zElW7qB769ffu0
qhCsXSKqtNAI00vRoonm1Jr7H3SQ7iiEW2pprKY8sbEFOQ1s5tV4LOqWiZCA
1XypPylBKBxeg2Kc9sCRoh41ZamcoalT21xFe6on2r2iPy2VqbKgd38XRiNd
E4aJhF6wWlgHXNm92QhkFqaUtjApLExoY0ax0DRaNYi6SSQrWkmfS/Mi7VzF
05xIkTqWWuTQtSa/frlEgyl5mykvnMK4zv7uzmLUjppSyokEIKgEip1kB0n2
F0iw3eBma/uC3+8YuwMP79k79q69Z+/bB/ahffQ5n5kfWkLYdX+3f34wIGX9
RS5Npa7TsgFqzwwjlMJ+KTRpP9jEx2+whpuIdAreLNEN4ZA6V3VL0qBKGDQw
9oeMN+tCNoJ6OtbcwU69qTR/d8KbiGxpbRSudydu6B11pFUurzvqBgtgqf1p
1T6l5TjC85WCCb6Mo6I2doQaCZ0TTd0oXHer1gaV3YmdtBMFfdK9YT9qexFU
9mb4gJDnkN1NCTEXpzIyHcsdVLBod2dvx2MTVykgqkFFu9q7pQfNhjbeLu9V
iDSWtYzWDoP8Pa1KNGtmBdWdcIQmMOupvMaeT3SLmbjckRI1zmBGltXQLEys
5OYCDACwyOc+YZAL+PFCxP81QAtVpqdjxhuTntk5hb6aszX1IVtTUGwHWnjW
uFDCMqnebQIibdKNxQVj0fBGObXAseK3pNMSSI4cvv0ca8rHeg3m7C+TZqCT
MPGwC5DtaNN8wH0qhCAuO29xXecyE87AZhSrlmwl8mN5hgRbOcHcAQpm1NIe
euooR/JikpPUl/gI7fLMeD7BgryrBgFARzCB5R3l4KmMSIKxHRMjz/Ll1d29
8d1JETgcn+3vX2o9+Qz2Az9fy4FsqwfuFzEAq9o+6iqOD8GPgL1tG0NIi+nm
2HyTldy+HZ8TT7KldeS2dfKBn9u3+1byuT83YYoBrCtfVFh+HmAK46JyxoiQ
kKe5trGGiNSTt8gAO5FEW6/xZVhNVJpPRpSGTcIp0umkuhJl07epSOYuBxkp
Jaq+GssfoSlpSmjMbWGgTkaZ/hyvgY/R+BRwIT3Sy0J7uIay69GZt0Godd1g
ZKaqzdqz2ImBpPfgDBIvoafrRyVrPM5vmLFQIJVWxph36kEcRS0bf5NVYBQR
eqaSHCkk+gGlpjQrUjgO+bJcaMqG5TJ9P1kvlwm32ztxzShDjiDmo67YxHK5
sxaH7+xvpm0/hPga4NJnoBWKtkROPoJs+B7phxKTj/YJhasy89/48/FbrYTI
8ke7836XKdmuELmj4qykS7nu5yMOsrvDgxzA//9FGejHyAFy/SB7Msju3WiQ
p6GhQTTS3gF5EN3OvWgQDyA4ylPf9rU9Eg+yJ4Pcb23HFeq8wXbu6Haexttx
4H7tIN/kiq8j16BPj2fOSx+Q7NNFer1MQtQbgXnn/Q6TRad5iObSS924qjzS
EXnXUQp7E3plBuiVHR7XUaAChGXfu/bLiZAxsWGobi+/L9rNifVOqvRiPUwe
t/ryLSjYOy9SMdsGwriJJjKLiLl2qF6WQ2yxtE7LskF78kpsrqgu5MCsJDcW
g0SyPONu7Qe1FJYN7DZ46WvQwSoycFAQxUX5brB0A9sIuamdjaJgyd63CU1l
we7y0EAcHRg6IlzwQp9XseVEF+usicpFBzRL667Ja9wYuROQp33d21fAd8UF
lik2eTDrsHMMAyRP15O+b8JacOTtbjdyiIbnCF5YpwNzNxR+gLcuqmnBsF+3
NjnY7cM4UwLZuxKyU4bde3zTr3mqhlZ2dNHUDG10XcbjILd69EBGxnqMNEnI
w4R9f6sofIVc0UlxBcqRLMTgQrp4R6er86AgQQW83Gq0bziaZMkwGBAGF9Ie
Zmfya6gzBZo8HvfGoB/JLz4N0ZG11xgbGbpDjEWLk3sG742jKFwtaVoom+8Z
LMXcapIg8DLEkb4289Q1N2x83lsjRsXviEw1LnO9RaXUlCKr8NhSbyRYAS0y
A7QoCSgR1gFu8mE6ZL6EDpkWHeppyxbQpP8OhlnLCvGPKDVeoxD/C1qe+uWa
r1jDjSyzDk9CiUaR6dYnVSI2cBzGSX+5jI/XMSmcO2RSQX8sMwjmaLVcax5J
4I0jz7HUGmuMb3rU09mJLJA9o5/89PqXF0/UMwX/cjw0eq47s2kctfPZZUFP
RWwOgTTzKXXJiE5B0/O8WduVTgy+/hlLLZLHfK69SG/h18dJBbokusFuYVkv
9G9fuQqITIKODl4dfFE5oc+xOn21zekb2Hli9Lq3Eb36HB8fv+Eq6L6+23Wz
8t97rVW08o6/4Spud8aNfvomjn5uXzvEtT+3uxv53J+b+ZE8PgXUahOpIdUr
xq3agsKzy5ayvSAgxwQdf3q4O5qBO/Uya+ta3KiMZ8SMJY4EwmQ1ZSMxiQwx
rQWj6z4ws+1Qxx6uQZiYlnH6Ssq0+eK6g9m6A7knI4PH8SOo4L6KWhq64Tcd
rFEiqIIz1fbFesA1lYNUFoKkkHhIaOZglqEag3M0uO+FP3iVwnGHlmDW7W4b
5rZt6Bt+2mr0JoIgRYdIEUUTdZb+XmL8jlM4z2MY7Xu6+ujjo2OthvO9uguC
7MTBhoE4TrcWneZqImtzzCWMLqPb7w3tD6PgXX9HV4N08FRI2qvTYOkX6VUQ
d2tusGjfEavV07k3BsBlQ9aadkRn3X+mTncQ5mkSKbl4cd/XaW4VFmq94jVY
gw+OXyKuznkIncW5plygHhcZ3Xu0i/kV0hRmFC4yDHwPPIuo8Kk8QXbwWYJ9
pKZVmcz510SKQ9q8LFdTODfjly5ZF492KKtj0JQToE1oJ3HOVB0vtB1h+SPR
J76RpfltGlZ8p4oJaFzScvQOsadJ7apRZpU4Dfbt1u42zfEYvjbh8wuKUfK+
BeeclowOLv7s2n2G2QeJtlMkmOtQlJHd2tuO7QjhxPUq0arS5BePJkZvu4nS
r51q+T2ezWuWE4UIuP6pgYWEbe789QBpc7kRStpcCGooimqvOI9A/82Ev4NB
3apNsN0+vqXw9+U/H8MhBije1u4eR3RsXz/EN1jFFw/xjxH+BH9C0Q8JRoi3
VL3mfzDgfzDgC1fxxUN8PQZsUsICpmK31E3WPpHr9bibqIL/GFROe3C5jw8T
PpP43cNXyZPWjkTir1zMVEZ+NFW8Ak1QhFzhzc1sBZ+To4DsNu0HuSC+D0W0
07ycvSOJ5IdCJANuABmnEWiAoG88z+YBjXHjitbRo61ACrcQFHfVN+/FUlZX
2fOASQ/L9ZJ9iq5pVbAVHy+4xw1BOkYtqXOoUqsTvbDqOx0EiJHUsEA7hKKQ
Z3bs1tPXL9g9smu3Xr0+3u7Iz6JXh0GVLopdA+xNZNKjc/dhxgoSvFcncAWx
LsYJhBTMLIAxli2ELTD8PGgODE4c275GjbuTaU3NauTFYDbx9rRXbCT4jJyR
FMXS1tvF2zNNucxkHFXzZVl3/0DT+Gczjs7fRG/h3ACb7TtEBvhb/nRRyxKk
hWFb28TOJq06At9mFZtp5TXE8ttQ/Wt4zz9mFTch2Uwio7iHgCs9Q9hHat0t
75J0pDRWfAm1MNT6ikvFXhnq3DOymBI3pnhj7MOCsVmc9pu+XyTrms012HZK
EnH6vQXos1pSfnzpq8XEHWu1zXa7O59atpSctGpItXMYpPOKtjbpcxYY3yyL
nG4Nd2bIZeNk5nNrbGLTlEQcG20O2HZCOD2xvs5sZzh4oueGil7mO3S04rWk
LHZX+zB0hzQt4GBnhi6vh5V793xgUHT+ZgkDsS1v/MRqu1ZpyIQLQuvHLE3n
krASwBglWhJU6al/MWxRqIwAWHx3XwZfmItKoOS9T86a5nxN3B6sDGyDITiY
TWfsuLcvhdnjzbqkFrWYYWU44ScsDN4CWXIuP+tIGIFrXFO81IUVwgOvRTsx
h555El1aQRqmhW8UN0vdoDCG9bLQGKpNyzFhxtkAENKCTM9q1HA2K1dsDkUH
epU6d16r2qbckVifxDDDBuezNKH8gCCJLqzTErXensAta+1qpr24VmkHlfiG
jpIKGYRu+ORHZ4MLzmRDV1mscFGlZ0jQIsOis0vh1ChXYZ6j9BhXoq3hTWze
PqO1jTS9WtGMapuQYdIXcKDo5XXR5yndnlDRnIgIiHimgUhhIIqLTtHgEuOu
gpZPUawcBdEhJWHZnFVFVSPMPC2yJMdiJNomVFJGR/GaanfvLspCvMnT1Hhm
RhlE6AkZitVkr0gQt8Q3NfS4V118TnEWBSIONS2SKL+4Qkov6lAKqDtOidXR
jkcO7qnyAJv9h9zrYnnmeTG/hiLEz8IFCKXut8f2JAVhdicXwfFhRIpt5r+f
GWj37n+QF7xtdHijoV1Pewph9vz8V7JbOGTrNVzECKo5GxvPI7BkEHsJFFTh
TsYjYpuJKeq1XG0DwXS4lhulwDlcwpx/rodE1X8cWZH5Ks0xYPetC/tW7y5+
EEToBU84bwx+sjFAD3Ohpe2qdqQImaQOSiYGLAKAtpDhPpKXCZB1X2Upjrbj
wFjaGe1fO0B0JDDlD8INpKTAqizP0sDhJiyfppLGgq4ICJZ7cPG0iWll92sT
a/b9Ov8+xSU7R+NWWm8764g4qmlCGQymMtM0agcTVRtyDaOdxAa8mgwx7Soo
pqx8C8INNdoSrS1UD/bypLnQpzfFmiLB2qSBZeRK8/DC8bPu0jROYebXGhSP
kkoIejYON6TmlfHP1xrvcE2PSxJYtFqrrGp6Zfj4PHRazrGNm1ROfEtMBk/t
+HlU80h/wcG3J6rKaCmGmmcdtZleHPDgu9MiZM2kI+3EvG5c55+NO/Ph/t7r
y5TA3HpVNvbAxazfanmD4xj/7lGDEDqPyjMnwX2OxH1Lf8vpSm1DFYsHF25e
HvwVXl2u1k3qB3V93+l2tfpAoHi51CoZyKg8KetTeTKsxjDqOxh762XGxSZ4
ajoYw0dCi5rrmgYPLCzRRZE3GMnd6OoNy5aAaKxnw2xrjuCVrImyVT84SlFr
OBWcipNxlQR3K77KB+cszBa8xsBSAg87ADMJ1g3r0WcHETvyiPvbFtYjcRXl
Wevrnv44yhf+G4Yy3v+CSOHfNIjw9Sr5dzTFyoUN/fxXEuKE8ETFKBQaNeLZ
o71oZaQpikLmvtPIDs0PCfsLC8s03UbkVIWG3hHuW85m6wrZIJByJUS+qo0p
g+AfX2jlVPkYx8i0/GAT2zHzmZCajbzcM5xQFhH5/79hYuuDDiY+7cdEPsFD
zGXBD8Js8i/BxO4qvkEC+z/Ih8upSYEepMCFSPSka4QSkEdRhSAeRfw86knd
Ys61eGOdYSfDbvTsAOVKb8FtVKlIcy4ysF0FBU2EMOssT7TZtU9M4sIO4rTc
N8aOXUBcIKCQCdcvVza0tTO+s2srLJi3ve8zm6hMCdxI29SuoXnOrO2rxERf
1FQWi4yS1rq3YL3r4l2B/BJD/kByhKUyJo9JfNdF3dkb37/jVtWxswSxZugq
pyaVMA2KbKA2tO0qfTxfDH+h6c61DpJluYzZaGX3744f3XMrg/MEsrWMc8pE
V4lKyHdmzhN2wTvr4rYojaKgodJGutnZOj8DOUtDP61WIP2+1lOg5T5V+Axz
ecOgXbYu2a1H98e7ew+is+UcRhg5fJ5OVY+U0vVSukBycmAylctDJfLrBCVN
uR8ATxdarhoaw2uYsatljrZ2YH04qGbBuPq2WkLN5ct6uRe3QTxHITTuXpLY
VcqFF4OeKGTcROqJ6+rJ91OjPSMuj0DX2Ada21xSOfO50AG8Ypt7EodbW1I1
vd2tRdeValxEn92jCY4oCvsnVpxSN0lKgnT1LOTpupspoK+MuNR4IBNrGIp/
XOeUWwhW+Hsu5XbRLYWVaZmnCW9rcNRams/2Ve+ow9SCTogCn9kvrfYjTXy3
o9DN4S90JMi1rXWu+zyEUrM5OHZvtW8dO25xkZ0vUsqUXC6jG9Lj0esMMTdc
GTaP9x0ytLxpkMtIkxmm+52Q6K1dwqIYsjNv9ldsUoOS4I0S/w7qcPUtAj/0
VtY1EKj8CiNUtNCemhwUq8Jy9P3L2ECoMyyOHSymFTaOgAVqKiNVf5w6TOYi
1GEcb4WS5QEooYu/qco10HKAuhKdLaM2TPM1pbOFumXkbILzqhfZmeARG8mo
QYl9l6YrqvVdZecZVWnHok1hHeygAGGLFrpb3PusW8TVKAGkQgntq/QJtX10
8D/dkcRmC5AP4DQoraA/G57MMH3VSJkV4xihMZTtnwRDYhXlQsGBno/+mrD4
J0s1Gt4VKjc3slrh6wEydF19M8mKP40j8vhw8O0N/IDs4Opz8p2dojKTvkwA
jBXk+TgLrNqDrunqGZisGHYOnHGIpBmHtW3UFycjW3L6TD1omaJDlqiCpkUH
W8deB/5rwIB+4WtCwBQbB1HY7MOtIJIuabULiQU6djrPw6YZUQ8w6d3OzchZ
6sMBYp+zOqJ98Wc4CySrVbnIpuh/7fNSr6t0FMrXoZUybWYT6XHxl82wsln4
ubZfFpVXUNglcBrgEKx7IEwF7ez7XO+TDhn0LiW4LkT+gzA01N2QK0JDa6E7
oaPWKCNFNBJ41RUcLDc5wzOXepkieIWHRwTXyVxEWAWfAkWCXgxiNIFO1VLG
uj9SQIsVh/GxKuqHAU2NtupQoWlouCCKYKLbuO6doUppgaxFR9krbo3tG41F
evpeIphAU4rRahNGBSZyVENUCqaKyWlBtfCdokSEO61QzAmpZgeKPwuAQ9mb
ooiQd62x+rJAVDA5iF/zHLE8NjEPV1BBZpxceR4tpDaELPJZrs/PGWznaQ7P
byHBoxjretudmVcAlYReJhlC7xmme9UU3+QCTIaoNskHuHrAyfdZbCwD1OKF
aXVTH/5Xc5iIBgvSKlXfarCMB4DYnR1dsxBbKS75jMkVgMW9m4NFTGi5EGBa
weZnLPBp5UqhhWK5fH/VBxcbeLIUco7pn4KFmzKtcSA4PuyyhfOjc0PlCJw0
+R9guAYYDj1bfEM2261H96+Fhl7rhCzCGSG4FLuE8fSR7gG+N8aCfG7UXwoy
dJApeuvRg41Lw+zdw5fH4apw3rUfYsQRk9En2ENbgDb4nMRLFYBwFCFXQ+nf
PVtzUjjaEwlQwxQEJ1zRklW2NthzE6vD0QbHZOv89AlAD6sugmzEErSPyAtM
OtfZ1NWKGxW4+xwjrqujxzUUP6dyYtue/TVrsGjdpyJ/OzvwT5+ZauMatOIi
jYAFGLsK+jW7oBGkWuHOXmsN14+hI9yREe7gGmJt6vqTxBHuyBr28BxaIvQN
R5A17O22dhFId5tHuH+XR7iLa+iKHDdYw/17MgKuoc2bbrSLR/d5hPs7vvyl
J2g3GuGBjLDLUN1LfgZH+Gqovs490iII7fq+jJVEf2rKcMPqGMsV7IAqd3Gx
1jDbWwOnnbnq0Nc1OpHYVCns7SOFjZFevtoaaARCsoYL20V56WTqebrKyyu4
faxdCwLpHJs3g5YVCLdGK6X5AizSYCnU34/DKum2JLNfOIjWGYnat/BjasuW
NhuUMhJGwZnTRZWmXZFf+p/lVwMZZ/v2aTHHGF7BjhcgxJstKnyysz0CLIQv
xGlh+eNdTmR7mbynbLoT7jltTwBN5Ym9bU6fY6sClf+VJWGoORoLRAUiwSbx
IfdsX6fT4SjwopQ4aonqZpuFCUoBDNbC0nIArvYlzlIH+SGuC3tqWFkL2Ky4
Gnr3qA3oZathTHHC1SpiY1lqcuwuXzfantuZ4sOIOt+dJJbwONJpjadhztaF
q31IAhy1EmIpZlOT8OhATXSgnXp+G4qLORU38bUWXp6cyPpIVIuD+ofC3DiX
g2ImPbAi6jLYjYCbweL2JP5ZC18biZIKMh01LwQTJsPaZ0vuH3ZNog+g0VuY
EBD9BKAEgPftyTbfe+fj+NLv0KW38enBnT0Or6xdbimcjqS1ssnuksetadyz
ZNaUvqUNwZBAuSf5dVOVxXl+hU1tNWVSLzi4ftYXuwU3uTBlb64I9pqqpQtq
FMQkHX7ju7RkZlqAZMFVhBhuyIUjagFnRbw90aMSzx3ulbq50m6NeFMjCV8W
TbGOrqcT6v+0QcpApcya6BmKc0vQE0iH5ufVMEfRNJyJuqT6RW0M4tUZuQvX
M7JTNIgJgiNK07SA22/U1M0MYsmNVNPLVZlxkSjqWB6Vl6TDG+jgG1GssNRJ
q90VfuT360BSD1xGMfHJdy9WWplLXlCmGSujAXgJkDZM1f7xDvtPBElre0Ms
ZWNrYjbV0GIcPUnzlPu7HszQsZ+ncyKjyPOAtXBdnVnTZX2KoEEGUe3GSlpj
KRbv7ew+5IRxKkCDDKwsQKs6wUDyY6SyDS6WT/0ucEhfnsYU6XkpPeO7tzY4
dRDVBOgBTHyMBWgRo+tF8i5lWUES4f1SeAH3YAGaxk/wPDiJZJFX6fkaw3GF
FWm2U2t3EWjd3baIa9M0bEdMzK7P9nCD0mgTbVeo+JX60NReyIPZ1UbfDC7W
u0oc5AV7i3Z0bzuwyNLlBYFlvVfwjEhXP45sZGyMI/fEx/hlOEJH6A7U9OHI
abbEwNTlSpLX9E9dRcCgNMj+BvvGWxmEaepwpvOEQNztC6FOQCCGXu7LlhgB
mJoKjbzjBtTuMQ6HEdwZhwNy22EfKhj15jvHzNDGXlZcooxdNjPtElTbreMD
4NsTE3BjRzO5iHaweGpzg8ODqMvqRcSExdHF1F9y1RwLyAoTkPlZpz7yoDyl
7gm3DiWrZBZ0ccacAhGHGbcFLa26hvW4Rra1OZfAgCePOWpOdqgpadrJcmiF
p6KsJFdEmw5YXszWvEDOw3ACjJtdZcPhDlgcA7Rmx0mQKHzNjgdFS5QKvC+m
DxeYBjzcVh9IhF0dUoXoJP0SzQZyZYfJVWcBVDs3LuiokWzlGohEceWvj9E7
KkspqknU2DfQrzpy6f2He3eRowV/GG2Ciw7zdoWYwOslssWOmINdsE6C7bJJ
d1dzcshiWWnuXaBqIqgH6oMuKC6h5llAn2pXLcZ1qiQooY6ojDkmHn5jN2PY
+dHT02d/3r2PIfM/lZcpFY4sOMjGsFroZxbffujti8GbnNkszNFF9u10owNK
445YKy19Kb5rgJv93f3FSntKOUsefoQNvWv113yTCgnKvX3FTG0POJRWFmJD
3wJMl3d3MELOXNhdmONmXKken/YmIezx/u72q22SFUeAyVUkSKoUi7RZs+tf
47vC68XufaJYRBFuPedQhxaRHnl+0/KzOtbP5dtOcVA1ZyEYMxfwA9ScTMN+
DExnudJhxA8wizuSitYntSYkfwefj8TRz9uIyaRhBkW+aJZBVJ/RDu5h5otZ
ykI+gwXcBDZuJLmawYggyjLw8jH715giovwRL4FzjDbqPqRaU3tIwxBGJNp3
ihysIcrRANTAuVdA7w9yM850uumwpAaWOLF96ho/hUvmVMRkPndwZjaC9o1q
Q7gN9WnOAxuyN9+QBy3jNxKXtPj6TRglXOOD11RyG/5lAnTv0d49EMuDqvwg
5C6K7N/FqLbGoIyGrYlYZRuXo7m3vhG9tE9ry97PqY8cLqfg0hpCx4xr18Fh
uNgTFdlrfuU5F0jWuWTmihQZsMascosQ+AzWOcdwjnFTjhHVmXdfJlxDIavC
UsyGDMAIzY6Bz7wXsmOZQPs8V2CDSy+XoMFyaqFimqdBeLpyPUMEmW3wRX5l
2lJHJgH/wLzeUXAHS6cw4xRYhw7vatSV+dpzsahLLh0VZji62ndy8+NXB6e+
Y4oV2ezRg4cACBnph9widYP9lDTFNpkLti326UfbKm9+IWEbQK8YczrTj4wv
p/w3KmS46KlGHpsrGWWD+AhNte135N0aIfinq8ZVdvdH6xmfRFqhD+kIkyeS
WWBvfpnN53k6Ld+n2vh16T8ZaFJuXUt0x/zX4qkRt3tUK1CL7tlgZJWmYTko
ZPBaYPUT+wuVFCBiNwvKLBGGmqTm3scOQdXNL6SjAqyr15WLHgBage1r8gtK
GBmT0FWgZ91on/kpINY7VORIJYQtJXmtcYI1quSh7D4itxR6vzBBz2AfDw0B
NOYVytSwphxYE6cvZ0HFGG+nBT2unK7JF0LCIwdsG/HAua447H+LSg9w5yd/
jP78UO3HGeumXAX9dHtz8EGqmzWByBoOgpna+CccK6Yp4lGy7Qz0h5eHu7ug
N1G0GGfj0hmHl4qL5PE5psHbhKXAkO+QNOl1PZ4B3WBU6sDKspy73H7J36+x
0bUqkjGEUuHImkzoLnRVQGZzN2QYqSZASoJzFsq/LC/EwcBF7GkVk3bnNLkl
2ptkLuFZ58gwKfiZiGBsnNQMFQ0nMTKJ1O64QSOsYBEcbYWQ4EwsWE2nBxbO
HWvsh6nwPAqCxtaZzKtyVeNCb8NCXQcqPZkoi70svm9CIW6gIhq2Hti4SeRS
kns0fD9BhQc5xRr9aU5fkAYE9J5UpLDhkW+h7oXkoTvYtivRQfeshuBDF0qe
UWjoAs/RXVlQIzSxGkUcRVarCKUNMjAkP2rWFitrI04RPnz+CqjVIZm/K/u8
SoBlAPGvt1uoaJyFAYHr9Nlr71ikYi9B+JHP3Eida4o61KbSiWACbBSIM05t
WEYIUD6cx3qVKcyQ3NQGk4yVZOjKiA3gJCM2tvmUP6LiUyD8KXn2Dr3a1uu2
GdklUttkzgJIXHFvxW02EyG9bbPRQ3SEGKyyRjUTiKj5YmpBHY8Hk91WFQ9U
0/HrdYXhGopGIkpqRyz5mjLK4RCyi2R2Zf8J2PQ5re5ZlsMGkJpvLMhGJDmZ
sU6E6hGNM67SXPL3fHo5cza0XTGXqTCanlJmYYPbg/GUbY6PqJED4yQ+bVA8
zMjlEk6lxWIS8V3OSwx7gGNhgRxJs/NFEreU+oGhQiHsfcjZABqn8ftu4aoo
Cp0iPRohT73vaAO+uenUWdhTqeI8Q0cG4ATI5kFeKd3z7sPdPe6dGdmeM7m8
M708Vw8x6DUCx4Rmo1iKMb6pvHjiHu49kC73kVBNUlAg46gURIk1C+bYKOAs
kyI599iGaGzi5Afu9Hcltp8z2gCvjngVfDl2aTu8IeWjdWp02kjmQhLBs1PO
E1ANcopUCYZ5S/sRKYQkkWVHx76nCRu3DsJ0hWEZFEksRafGMqju2smirHoo
/XKBSnGqOCtmUd7aCUUeIJKtmzWmT3n9jmyMs0W6DG41cLaqY0Oz1f2qC+4Y
gqEH1p/fRQYzsTfS2tcFdiQBEiOhXmwzwiFPX5ygNqBx+f3LUsrYNWnF4a0U
czFy40qGiUvuANk3VZ0nNrYFsiSVzckx68yaGephVMcqHXMTF509Wt8Iae64
XiSYxP0OOBA/Kx10HjwC9Q84tamSS7tag4AwCx7qHVCI7t69HXiVjGszilJv
18h1RYja18jlYOtRa3OuyGzLTqecHthgmCZFamHQjpjC2EzQ0pfISTv6wtvR
ZXZXEsdScJ4XoRWMBWjGyLjruASHRzvSNshDx7DASEnSB5NhrTG1SLJqxeLw
dvsAkLVMuV99tVafj1OA1lGcFsDtTzJUz5Ko+xlrwZuT3aZXcuxMfXpKK7Vq
TgEN5/q9KChhHH47jKZxZa6CrXKuNAsVsSSCJL6moqpYv4JeQcu4tTetbvKH
H3/8USNej0UphY/+iI/gfxRJ+gMj0z/v7r/fxV398973++/3vtev4ft/3oVP
dr/HNz7aw1378Y+bfjhANRh+MDbW2guKb7325zd+Mj4G2isfBJyDf1IPRo5h
z378w6afGx/DDxp6ft1PlFCC/wH4pfvuvgRDgAgAGeYsOP7RfWz62QRQ8K3W
UCEY1PDgnwIYfspV/yg6GCXUaeosDFG23ywWPX1nYnV64yuRT4qZ8BOqbUta
DxsqQCEpOBKXuRPocVVWv9OuFLgaX8dQc3xJRx+Ip+JyiQkXse6PzeppPc3P
I+SYltrF2gjIpexS7F1P5rvQBSlrvdoxRVBR4CqFKHoTd5zmHThJy8psaLGI
PBU+XWaNUzZBpS1Bj22yczRts4VfCwgPDSPBhr5YORkLxIAA57MSkUu8ZbUY
nVjX1/M6ckGLpNgkF2U2N05YK+NLIA0/hBzQA+hkiyZHw0YRnpDZdEITUGkK
rVLQn7kly0KrdHBiDkrwF4YM7pEhtT7chOhI1peQ2SisCLfVqEtf6HliXnKR
y1JFfxdZQ+/mZYlPu1Ke4rimYyNRntmIKAaqD95x2uDdRw8fsJaAzg8Rg0Gi
PWuM0T8b/JNLvDJGcRWgPE/PMwoFSmNVDFaXVqzaGdWIgUkdgTCMKcz8tbDQ
oVH4soJEO8L+RGwhsjAyBinuUbVCvmRWFVwBM6+DeVUQtP2Ek/e4LkHV6jnJ
poTg4lGyQBfOlXbuC9i4FB+lIMJZufJVPVUnEufSQSzaxVo3KxJsodCoY9YV
fDsYLFveo02ZoALTAOCKzUVUu7aQiXn2MVl2SqGUeF1h7FVFYWbLFF1aWb2U
CvquvmtiirIYayOCC59vvExhaEkWnC1QcG8xAbZFcoFWvD5CHi4KdNpnRkfO
5rai3RDC1oxU5INMxRq48rKcYq2uE29aOJqzdmm3jl6eHG3bdlldyuSrGaRV
Ym1akcXqvpwFXEO6dJM4nzTdNH9MVBUCesyGvicIjE4J2zp+crzNovf75vY0
BegiBk9Cu8RELqnQ1Fw4C5+v9/uqFzAprrgygHOrBE7XoUzQaK1LrK2JsRFf
cBPEGw8I9ySHFxTWnPJXart1cPiiBpleSh4gBX2M5VqmiF0qoT4HcMN4x63H
r55vU7mMks4Fh8E9sN7gCH+gzbAzcLku2CurNcgGe+ligBGuKNQq4M5VLwKy
jPmtAMpvDp4c/XKCY7kaPFR9QQ0vR+Mnk2m5niVzkIXGaPF832BO03LsQIQk
9r574wo37uq+1b0dAGmjaCM6qBQYMQkyQ+Y6Yh2UJZPIbl3MpIAzAaIkFiMN
Pzg40CQEPHfqYqI1k0JdK0xulbh8ZvvO0uIr3sbXiRmzfD43PWH0zHIsDxZ0
OF+jUqiMkz0KtRTk6JeFNNV/emUiFoUEwXng+A92KzCPiR2Mqu96Q5dx9mqH
QVxAk8i+5gb1FRTLWt8FgioJROTDVTNU36kjZcSYFvWgjc8SsqKxRwX9URP7
GsWaawbhUCOg8OUyrbqDsAzcK7DCQZqgNB+ZoI8OXh20zc9sfc7g0EB5QJVG
bRsgr9in8wzY4749zqk8EZahg2ntrdOfjk7g+1uuHpwrQoeRkHUaepV1LC28
xuERtTcgt5k3d/+mU9FsxVd4iWonp48wXxF3k7mifCJMsA8jcVF/Bb6qMc9t
y6FxfOVWNBXSRX+qjlkc41+veB9vAEzrprq6BQIz8BiU/AyaPJtmVe/fvn15
eTnBQ52U1fltXhRJD7dlXWNcVz3G8ccSpL3hq8n7RbPMry+rGm5iP9AvBVnx
kWAP4RP21e0DyuLv7Hqr3t6n+ir4dZASHr29M35zekrMuXPE8O0B33a0JPw5
enry3P4BBJ/zP2Vpc4Zn9UflXkCK249bjFu1h6gF2z/M8J/4tTep+CpbLwq0
bjw8o0kYSJXVURoDEUDXmcSy+UrqgZ/oX9FK/+Dh3r+pbYyCkPDxVh1+NcHS
MQtahJ6wPokyNNhxIwXbawrfkk+2QdypYNX47gCquNpJWIrCtWgbHtH4EW9h
5gyBf6cKJRWMcp3lsesQjS/PZ1JFD47rVrB+s3H9ndmekPsp4QB1TFLQSiUz
RwXQAq0VttL3aB0Vn2u9zhpCVqU4IpTXLtpiHhflv+/Ut4e7e/c/feLrK00o
vpIzUF0yKF+nFbChlHRiqgJL1mv8Q2kFd4nr3QjJBOFumMmzDT+pJON7ta5W
GEuFwwtzZZ+x3jDFDFHuHfAaY80BDDuCS8/QE5Xwun3FR4pu8yDYWVjtwt0N
OrsxvRZvWyUPQQpc0VxvSxypaw6bS2u+B8ovFMt3gj6NUVjykTJKOO6O+ATs
imuB5hp/x44Q7DIRvwZncLbO2VbAVg7yfbIUwTE48oLUuQ/XGBS6QNsRcDuM
s0SkIX8xDcqc1CgogsQ9ZyGC2eXu3sPx7iMp7Gu3cAnTEtifS+PH+rvcF6GV
2S8lJeBLZJ4eUba91uOvw+h1UIgPX98cZNgZe/8iQ0+0R14mLB9TMoHKZZSy
gkojWgvoCH0FHNaHtXhpz+wMMWXGehHGKYcRg0n7eGcZOsklRAAdq2hJYBtN
zXRI8mdA04dLJuGfpBxtI5YYbMiazShbjxcx4lUK3uhRIAvQK/nbWiJqpIgf
GyxlC9JdS69CaotcQytJUtBXJL8gvrerCShUl4YSfUSyVlEHw1mIg73hO9jy
NOZhi8ZsC6GTcgVWhmvJTkJ4+Py8H8lBKKaV+DYr+zcsIHPjChfxY1S8RSu0
3LB2zEfPsm2rIPqXr8FSARkenBQlH97mSHS0BpUPrI0KyOBXB3rUnzXCV+9i
o6ASQi3SlM+AWCZBMbQSH/LyDCEb7VoqjCPcCR2iKQS2kE+FoAWqr6+a7HqL
MjHcpfrX4mkfQofJ5iGEuvYNorVPGAneSEuYa8Z7tDfeu3ePELRSMMG9HwvT
+IUCjv8r4qB0G8BqOyi1Xvfzj8LBzWsIUaiFg0fFWUlu388eYVfWEAZqf94I
ezLCUFPFG4wguxgIN49H6R9hT3fhauN+5i7u6C6cB/1zRvjHUbNYHPoMusal
+NuU7ZCCuzUNIcTIAH37AjGkRPDVKuUeEIYTi4Js0t+3rB4V1wfvUBNKIHZJ
lTTM53WL2LfYLaK/acO+paYNZC3uaozxk9REobdrQbdjwb7ljgVM/m7MGsLD
Z/ZgAvYAU+/goPtSyMp1JWB6vElQmtDbwgFu+v4gU8ChmPhvGGqYJdj/MJ7w
GeXHwme+rLBfyBW+rARaZw32cwv7hXLVlxX26xvh8wr79Y3weYX9ekb4zMJ+
fSN8XmG/nhE+s7Bf3wifV9ivZ4TPLOzXN8LnFfZrjfDVUL0Jb+PCflzh8yru
IhZyPWJWGL8DA1vqnGA0hMh8p/E99qQkF+bB8RGaQYnnAO0R2YKIDBtiO0Y8
tp0nq4zDyw+4Kg5lb25pPVvgF9vGvI6iRZGJsPe0lVQYzZNSy0+eyfnXQuca
a97aRkPCQ6j9pY+7BSp8sKKAlff2oBNAf0qPU+KPS8Ikop/DRc+v4oxzZ7nw
tT0mlEKBTnl1oFN1v2L9fuTrlKB2obXxWifpUzNqinKggBDXlBVfgotw/o6X
J89/fXZwcvr6+CmGjSTnKGi4toVoi5BlcKTWdSzA1vZHW9Pdbx08+/Xo1dPT
kT15ffjzryenb54evBzZne3fI7zwOrbqkZ2uMYlD//01T4tRtKpRN+Bti2M7
aSI0V9vfbdt/YpHgV/x7REZsHAom2yjUcXKOhyAFGjpvuhRMOwkr7+CphHUG
8KZTNMlqBJPke5CrNI4H2aqv6lmT22a2+vUswVwnAGqt4rGtssd7kBy2ZtJq
hgN1aheRzvEphWatkHyD91uGuDCRge4GAxGwDL0N/D6psA4dGe8lcFgMwBzN
TUZJrurgQ4ulir0xj7FQYyPVpDmAOdi2q1MCcLfz/h5CMR+vnDsDJoJaMi0v
Uimx7QttyKrpejSYTdciYSh0S245QDbsMco4nnD4ODSmHWF0PqaJYSg1V7Pn
lS7SOHyvbw2Y7IOXzsZzLfbfU1nBr00SrTDG75pa92EStxa90qB1HXTmu5VE
rXyFobiSq7FjR+zp7LlPpX1ww+ZjnYGpoEtnByzlKL92C9TYExHZnUZR4Azn
grtVTbC6tG8dHJpzO0dIufGeRjFx0coUpAQN3BmF/818G1y8w4l9kVB2lSfg
JibgI4urhyGoXd5mYgf3xqm+HBzIdvetbReEz9Z4ivhLdOFZUD0NEfXxuhmJ
GyCsU6AiRs+oLrg0wyBCGEIRwmXpdQoeJIJGI+fRk0C3wCVsRTmoKBKV0/o1
EAdmu1jW51vbI/p6a3uymaye+rJCw6xeej5hdcqLrKwCFw8zT1Z6b6h7/Ke4
CwoOc7dxzYEPH7exPQdOBsKQKEj6qCT5E34SxLu5YRhC6iB99VoyIdJ16eKN
YRDKUURP3zwFRZKGp/CKKw5Ura+DBcdOJRiIiKiw1Jlvle5EEmesMMwvnVb+
fm8f8xxwEM8ZadUyMIPcyHKWSKI2DzkMK8VlKQuaM2nLqCck2TWSutZgj/i8
uXMCjXOnVW7vDHPTFpgHJuvc2QlWyuPTKsZZMSb4uF1aLo4U1iORPp9AHF2t
qx52igaMKyCWy/ElHKTP3aXIiYI46hkbhbAiaS9v6cnPKYXmR7VDkB2ISIP8
BqXYGV4OlwoRTkRhSxxKBit/AwCJ/HCkMZCOcv/66vWvh69f/3z0NKbhVIFn
Slmxc0mL07qBbnhHI9D6hD45HWKa1FktZ6AQkWD4/nmeuprOSorIy1lLcHi7
LkrAUdljGT4nxUvQe501UpWiXdQU1CiOkEjnP94qStSQDnKUUriW+JUE+s8z
kM6x4reDd8mmcv23HAc1l2mrgBrqI+/sn0tYbUkMGRb653Wereu/g5pVldNy
9vcUo+xABTFcaKVxpYdfHqM8G/pTOQeXszrNWqpVaeYFr4Ucqp46cMUUVyuO
yt3BebztX+ibZLVI0tw+TtbzdQb086RJzxKAtZN0NstG5qDAsuxNVsHj9hX8
vj5fzzPa1XOQSUtQQ/+SUEr1yWyxRnFb46Oyyi7SfIU2U8CaVVI52dOFZ9GA
gJj2eVKk9cJFEpPHkwjiGUh9UyqZSO2rSWrHesxSZYFAXqh31N7ir3D0azSl
LFKKVp8DS4ODhNU9TvKkXk+rZJkUGVA4XKMYgzEeQipBBMnYJTd9ZDRT8ZyI
qj1eZLl9SnI5y98vsxmdJpxFUp19X/eM7rUSdEI7iMKIYbill1ShEG+Grvpl
Vv0tsT+v00WeYoFrF3vGwTAw8sETy154jOOJs3mn6yyfC/9LkyrPwlL3jDQu
ykJD1NEGVqO4FdeS44rPdSeGc7kCRWlMlQTGqGSBbGb4mRXcf1rU8gQlTsB+
YWaJefnw4aeycTVidu9MKfLzGRqAr5+EuI1tndXhIrNP8M6P8eZBQYX7Wmf2
X9BOMAI4B5BelEk2Hdm/ltjXcL3MKPEK64DORQoABM1Q6VuAcpLUgL0elh1I
Ks5qZyKd/wiA6VlSVcgTXmbvEAwOAMwWybKmAksHOT5QVvORfQK/vaWWjNIm
76QCHMAU7Ys0zzN3y2fVOmswEMWDIxmY0Z793aN7duvxOi1KitE+wJaJ27wm
Mlcj6ru1HcPdVxmg0UmaNSmcAGgr+OeL1D4vz85G9hmy95/zZLl0a/pnIOdc
+yHPg3PIitW6tXkuYVDa13lyhqCfp6TzwTFgmEVhn1/V2QgeLpfARv4lqUFW
fAcfHBRzLD6FAz1eV+8AY+BoTrL8HQgAGZ4x/AVrqUr7OMVcqZFDr5dwSkDL
RvbPaVKM/3rBvZ2e5XDYKB4ezLHjE5rwyIoDqpGSqieANvDa47T4W7KElT2B
PcKkB9W6kGsosoukTgoGhzfJOZJfWEOCBuL8KvEI6G5kwj00igaUrHVTVr1s
5nGCUjXjBAfC48MSX8boeeU6yraYDFubgLmh/IPq96gVPiCIXrLZA7tiEi6H
bS1IMiXDcM3WsOtQjJLUxL1UAgzD3I/1cfIgEaYgAf1zMsNc5bTBj1/nGUHN
YxDysTfnGsWxMaX81XDsCzjQNMdPIjaDH7zNlvYnVNURTt9TU7pySmG778pz
egNLASzsX7IiWSXLdZ7wh8X5T2WJIXYljcLVFA7zMkWnKDUizPMKa3u+TK9S
WvqLNazl5YTvDHgkPRVe0MBxbSJp/rSigeDvCPRoySlIRE1GrKji4+k7NQQq
MnHaF7D/HpA6DWocOUUFK9XMtYMYBwpq0w0Ue3fsvnc3MbSNovobKofF5J8i
mNFEghXdeBx4dryzC8OxRKjr+PCh1Qnmk9ofNMMpMP16Vhg3f6mjursDNeZG
wlFV9lcjCrp5XeUnPg7Sk14f/nxCfVHhpdqFsFFpfTIycOtj5oJAGgDNI/sw
bXuXtw06zsuBJ/b4iTvDT9zhJ+4OP3GXn7i3T3lQ5xXH1eYlnZkTiMhXimYq
KqRF2QyLkqVFdJ6w8B+UaQg1O/daIin2CO+Uvd+1ice+6X0kk79rl9yUNsRA
1GaN9FdABynqT1iUYgIwz8JotN70/arijqJAEGcplUQQKS9zpYKXqfbRRQAU
s5bkU4rDmAoWcRalrUG1wUvUNA4uIERWXNUWSP69TKf6waQ/9hkJrINP0q/r
uHeQmKNIi+Kyy8ELoHxGmZ+80CANF8uxgobIFWVCE6noN4EhM6oTx3WKUQGg
Si1wgjMCWSBFM1frKQ0jTLjxj/AMV8ZYCx33WvPkmLV9CuVpaF/TqEQZa3Wu
vKZTBnO4b8rwDsvK17LDQ91hVJ9EuqjiEQUveUDgXqi/ozkel2WDAaGrIKDA
qah1xvnZSAc1r3AYa3hQdpv5gm6S/aPtoum6qdOkdHwQwKZKymSmlbMJKr7Z
oxDWCS+1cdHcCd8an0HbdqM7xK2psyBCFQarNqSKILDDhTQkqWt+OjMKt/Na
Eb+N6LxbEpyZxqWUk4PsYOZdgKEihHqJP8cIf/VQJwaI1j0mWvf3efSINtfc
tUlpGSvUovj6FGpMwSDplrXFMNDYvn3+4hBJz+/sLxQoPWc6L0mLUsEZrQS3
glCPW5QLKCh260RZzAFB1i0a7RBlWyQ5WuVDa7SGep4EcbA1rV3Vg4Z5g1K1
2xslEtPnYVUFZx/RKm9ZLQnevAsubbNN7z0DflRgxhcc7IN9G2zc3wmTyn7N
FE+E6qti2RKMPxdqSHQD8AZb6AS5JkjJHt1hXMuT9xSpogTfobTWkcfQlID8
TWhxr3Cx+MsBSQOh69U5SUN/swAb7u/hfvBivUAmHyvfvGNuwSUUKqxyi2M8
cmOQ90TZuAMylwMnnTRyZF3YCwheg/d3d8a7d3iIwBHufTFtcEW1fx9nk3SX
QAg7r8r1iu8CkLRI20UysHJnkTJFtT9wMWcaw8khZHMi4sI6PpEDXQs7Mn9A
u3DFAUbeakQWBIvnsQvCxVmG94hAZLfoDhfpCvjU3F5izsZ4vdqmJ0HIeJNe
Ir3tmiPah+BsDu40XOY3YAUI1D//v/+P2CmM+f8AhbiP3EOEAQA=

-->

</rfc>