rfc8803xml2.original.xml   rfc8803.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="exp" conse
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 --> nsus="true" docName="draft-ietf-tcpm-converters-19" indexInclude="true" ipr="tru
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> st200902" number="8803" prepTime="2020-07-28T16:11:24" scripts="Common,Latin" so
<?rfc toc="yes"?> rtRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true
<?rfc sortrefs="yes"?> " xml:lang="en">
<?rfc symrefs="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters-19" re
<rfc category="exp" docName="draft-ietf-tcpm-converters-19" ipr="trust200902"> l="prev"/>
<link href="https://dx.doi.org/10.17487/rfc8803" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/>
<front> <front>
<title abbrev="Convert Protocol">0-RTT TCP Convert Protocol</title> <title abbrev="Convert Protocol">0-RTT TCP Convert Protocol</title>
<seriesInfo name="RFC" value="8803" stream="IETF"/>
<author fullname="Olivier Bonaventure" initials="O." role="editor" <author fullname="Olivier Bonaventure" initials="O." role="editor" surname="
surname="Bonaventure"> Bonaventure">
<organization>Tessares</organization> <organization showOnFrontPage="true">Tessares</organization>
<address> <address>
<postal>
<street>Avenue Jean Monnet 1</street>
<city>B-1348 Louvain-la-Neuve</city>
<region/>
<code/>
<country>Belgium</country>
</postal>
<email>Olivier.Bonaventure@tessares.net</email> <email>Olivier.Bonaventure@tessares.net</email>
</address> </address>
</author> </author>
<author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Bo
<author fullname="Mohamed Boucadair" initials="M." role="editor" ucadair">
surname="Boucadair"> <organization showOnFrontPage="true">Orange</organization>
<organization>Orange</organization>
<address> <address>
<postal> <postal>
<street>Clos Courtel</street> <street>Clos Courtel</street>
<city>Rennes</city> <city>Rennes</city>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Sri Gundavelli" initials="S." surname="Gundavelli"> <author fullname="Sri Gundavelli" initials="S." surname="Gundavelli">
<organization>Cisco</organization> <organization showOnFrontPage="true">Cisco</organization>
<address> <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> <email>sgundave@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="SungHoon Seo" initials="S." surname="Seo"> <author fullname="SungHoon Seo" initials="S." surname="Seo">
<organization>Korea Telecom</organization> <organization showOnFrontPage="true">Korea Telecom</organization>
<address> <address>
<postal>
<street>151 Taebong-ro</street>
<city>Seocho-gu, Seoul, 06763</city>
<region/>
<code/>
<country>Republic of Korea</country>
</postal>
<email>sh.seo@kt.com</email> <email>sh.seo@kt.com</email>
</address> </address>
</author> </author>
<author fullname="Benjamin Hesmans" initials="B." surname="Hesmans"> <author fullname="Benjamin Hesmans" initials="B." surname="Hesmans">
<organization>Tessares</organization> <organization showOnFrontPage="true">Tessares</organization>
<address> <address>
<postal>
<street>Avenue Jean Monnet 1</street>
<city>B-1348 Louvain-la-Neuve</city>
<region/>
<code/>
<country>Belgium</country>
</postal>
<email>Benjamin.Hesmans@tessares.net</email> <email>Benjamin.Hesmans@tessares.net</email>
</address> </address>
</author> </author>
<date month="07" year="2020"/>
<date day="21" month="March" year="2020" />
<area>Transport</area> <area>Transport</area>
<workgroup>TCPM Working Group</workgroup> <workgroup>TCPM Working Group</workgroup>
<keyword>Hybrid access</keyword> <keyword>Hybrid access</keyword>
<keyword>aggregation</keyword> <keyword>aggregation</keyword>
<keyword>transport evolution</keyword> <keyword>transport evolution</keyword>
<keyword>future internet</keyword> <keyword>future internet</keyword>
<keyword>extension</keyword> <keyword>extension</keyword>
<keyword>Trafic Steering</keyword> <keyword>Trafic Steering</keyword>
<keyword>ATSSS</keyword> <keyword>ATSSS</keyword>
<keyword>Multipath TCP</keyword> <keyword>Multipath TCP</keyword>
<abstract pn="section-abstract">
<abstract> <t pn="section-abstract-1">This document specifies an application proxy, c
<t>This document specifies an application proxy, called Transport alled Transport
Converter, to assist the deployment of TCP extensions such as Multipath Converter, to assist the deployment of TCP extensions such as Multipath
TCP. A Transport Converter may provide conversion service for one or TCP. A Transport Converter may provide conversion service for one or
more TCP extensions. The conversion service is provided by means of the more TCP extensions. The conversion service is provided by means of the
TCP Convert Protocol (Convert).</t> 0-RTT TCP Convert Protocol (Convert).</t>
<t pn="section-abstract-2">This protocol provides 0-RTT (Zero Round-Trip T
<t>This protocol provides 0-RTT (Zero Round-Trip Time) conversion ime) conversion
service since no extra delay is induced by the protocol compared to service since no extra delay is induced by the protocol compared to
connections that are not proxied. Also, the Convert Protocol does not connections that are not proxied. Also, the Convert Protocol does not
require any encapsulation (no tunnels, whatsoever).</t> require any encapsulation (no tunnels whatsoever).</t>
<t pn="section-abstract-3">This specification assumes an explicit model, w
<t>This specification assumes an explicit model, where the Transport here the Transport
Converter is explicitly configured on hosts. As a sample applicability Converter is explicitly configured on hosts. As a sample applicability
use case, this document specifies how the Convert Protocol applies for use case, this document specifies how the Convert Protocol applies for
Multipath TCP.</t> Multipath TCP.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t pn="section-boilerplate.1-1">
This document is not an Internet Standards Track specification; it i
s
published for examination, experimental implementation, and
evaluation.
</t>
<t pn="section-boilerplate.1-2">
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF communit
y.
It has received public review and has been approved for publication
by the Internet Engineering Steering Group (IESG). Not all document
s
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
</t>
<t pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8803" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter
" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-introduction">Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derive
dContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-the-problem">
The Problem</xref></t>
</li>
<li pn="section-toc.1-1.1.2.2">
<t keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derive
dContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-network-assis
ted-connection">Network-Assisted Connections: The Rationale</xref></t>
</li>
<li pn="section-toc.1-1.1.2.3">
<t keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><xref derive
dContent="1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-applicability
-scope">Applicability Scope</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter
" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-conventions-and-definitions">Conventions and
Definitions</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter
" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-differences-with-socksv5">Differences with SO
CKSv5</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter
" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-architecture-and-behaviors">Architecture and
Behaviors</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" forma
t="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-functional-elements">Functional E
lements</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" forma
t="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-theory-of-operation">Theory of Op
eration</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" forma
t="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-data-processing-at-the-tran">Data
Processing at the Transport Converter</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" forma
t="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-address-preservation-vs-add">Addr
ess Preservation vs. Address Sharing</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.4.2">
<li pn="section-toc.1-1.4.2.4.2.1">
<t pn="section-toc.1-1.4.2.4.2.1.1"><xref derivedContent="4.
4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-address-preservation"
>Address Preservation</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4.2.2">
<t pn="section-toc.1-1.4.2.4.2.2.1"><xref derivedContent="4.
4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-address-prefix-sharin
g">Address/Prefix Sharing</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter
" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-sample-examples">Sample Examples</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" forma
t="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-outgoing-converter-assisted">Outg
oing Converter-Assisted Multipath TCP Connections</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" forma
t="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-incoming-converter-assisted">Inco
ming Converter-Assisted Multipath TCP Connection</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter
" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-the-convert-protocol-conver">The Convert Prot
ocol (Convert)</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" forma
t="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-the-convert-fixed-header">The Con
vert Fixed Header</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" forma
t="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-convert-tlvs">Convert TLVs</xref>
</t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.2.2">
<li pn="section-toc.1-1.6.2.2.2.1">
<t pn="section-toc.1-1.6.2.2.2.1.1"><xref derivedContent="6.
2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-generic-convert-tlv-f
ormat">Generic Convert TLV Format</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.2">
<t pn="section-toc.1-1.6.2.2.2.2.1"><xref derivedContent="6.
2.2" format="counter" sectionFormat="of" target="section-6.2.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-summary-of-supported-
conver">Summary of Supported Convert TLVs</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.3">
<t pn="section-toc.1-1.6.2.2.2.3.1"><xref derivedContent="6.
2.3" format="counter" sectionFormat="of" target="section-6.2.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-the-info-tlv">The Inf
o TLV</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.4">
<t pn="section-toc.1-1.6.2.2.2.4.1"><xref derivedContent="6.
2.4" format="counter" sectionFormat="of" target="section-6.2.4"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-supported-tcp-extensi
ons-tl">Supported TCP Extensions TLV</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.5">
<t pn="section-toc.1-1.6.2.2.2.5.1"><xref derivedContent="6.
2.5" format="counter" sectionFormat="of" target="section-6.2.5"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-connect-tlv">Connect
TLV</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.6">
<t pn="section-toc.1-1.6.2.2.2.6.1"><xref derivedContent="6.
2.6" format="counter" sectionFormat="of" target="section-6.2.6"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-extended-tcp-header-t
lv">Extended TCP Header TLV</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.7">
<t pn="section-toc.1-1.6.2.2.2.7.1"><xref derivedContent="6.
2.7" format="counter" sectionFormat="of" target="section-6.2.7"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-the-cookie-tlv">The C
ookie TLV</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.8">
<t pn="section-toc.1-1.6.2.2.2.8.1"><xref derivedContent="6.
2.8" format="counter" sectionFormat="of" target="section-6.2.8"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-error-tlv">Error TLV<
/xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter
" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-compatibility-of-specific-t">Compatibility of
Specific TCP Options with the Conversion Service</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" forma
t="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-base-tcp-options">Base TCP Option
s</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" forma
t="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-window-scale-ws">Window Scale (WS
)</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" forma
t="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-selective-acknowledgments">Select
ive Acknowledgments</xref></t>
</li>
<li pn="section-toc.1-1.7.2.4">
<t pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" forma
t="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-timestamp">Timestamp</xref></t>
</li>
<li pn="section-toc.1-1.7.2.5">
<t pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" forma
t="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-multipath-tcp">Multipath TCP</xre
f></t>
</li>
<li pn="section-toc.1-1.7.2.6">
<t pn="section-toc.1-1.7.2.6.1"><xref derivedContent="7.6" forma
t="counter" sectionFormat="of" target="section-7.6"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-tcp-fast-open">TCP Fast Open</xre
f></t>
</li>
<li pn="section-toc.1-1.7.2.7">
<t pn="section-toc.1-1.7.2.7.1"><xref derivedContent="7.7" forma
t="counter" sectionFormat="of" target="section-7.7"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-tcp-ao">TCP-AO</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter
" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-interactions-with-middlebox">Interactions wit
h Middleboxes</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter
" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-security-considerations">Security Considerati
ons</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" forma
t="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-privacy-ingress-filtering">Privac
y &amp; Ingress Filtering</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" forma
t="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-authentication-and-authoriz">Auth
entication and Authorization Considerations</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3">
<t pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" forma
t="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-denial-of-service">Denial of Serv
ice</xref></t>
</li>
<li pn="section-toc.1-1.9.2.4">
<t pn="section-toc.1-1.9.2.4.1"><xref derivedContent="9.4" forma
t="counter" sectionFormat="of" target="section-9.4"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-traffic-theft">Traffic Theft</xre
f></t>
</li>
<li pn="section-toc.1-1.9.2.5">
<t pn="section-toc.1-1.9.2.5.1"><xref derivedContent="9.5" forma
t="counter" sectionFormat="of" target="section-9.5"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-logging">Logging</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t pn="section-toc.1-1.10.1"><xref derivedContent="10" format="count
er" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="ti
tle" sectionFormat="of" target="name-iana-considerations">IANA Considerations</x
ref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" for
mat="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent=
"" format="title" sectionFormat="of" target="name-convert-service-name">Convert
Service Name</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2">
<t pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" for
mat="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent=
"" format="title" sectionFormat="of" target="name-the-convert-protocol-convert">
The Convert Protocol (Convert) Parameters</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.10.2.2.2">
<li pn="section-toc.1-1.10.2.2.2.1">
<t pn="section-toc.1-1.10.2.2.2.1.1"><xref derivedContent="1
0.2.1" format="counter" sectionFormat="of" target="section-10.2.1"/>.  <xref der
ivedContent="" format="title" sectionFormat="of" target="name-convert-versions">
Convert Versions</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2.2.2">
<t pn="section-toc.1-1.10.2.2.2.2.1"><xref derivedContent="1
0.2.2" format="counter" sectionFormat="of" target="section-10.2.2"/>.  <xref der
ivedContent="" format="title" sectionFormat="of" target="name-convert-tlvs-2">Co
nvert TLVs</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2.2.3">
<t pn="section-toc.1-1.10.2.2.2.3.1"><xref derivedContent="1
0.2.3" format="counter" sectionFormat="of" target="section-10.2.3"/>.  <xref der
ivedContent="" format="title" sectionFormat="of" target="name-convert-error-mess
ages">Convert Error Messages</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11">
<t pn="section-toc.1-1.11.1"><xref derivedContent="11" format="count
er" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="ti
tle" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.11.2">
<li pn="section-toc.1-1.11.2.1">
<t pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" for
mat="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent=
"" format="title" sectionFormat="of" target="name-normative-references">Normativ
e References</xref></t>
</li>
<li pn="section-toc.1-1.11.2.2">
<t pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" for
mat="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent=
"" format="title" sectionFormat="of" target="name-informative-references">Inform
ative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12">
<t pn="section-toc.1-1.12.1"><xref derivedContent="Appendix A" forma
t="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedCont
ent="" format="title" sectionFormat="of" target="name-example-socket-api-changes
-">Example Socket API Changes to Support the 0-RTT TCP Convert Protocol</xref></
t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t pn="section-toc.1-1.12.2.1.1"><xref derivedContent="A.1" form
at="counter" sectionFormat="of" target="section-a.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-active-open-client-side">Active
Open (Client Side)</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2">
<t pn="section-toc.1-1.12.2.2.1"><xref derivedContent="A.2" form
at="counter" sectionFormat="of" target="section-a.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-passive-open-converter-side">Pas
sive Open (Converter Side)</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" s
ectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="t
itle" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t
>
</li>
<li pn="section-toc.1-1.14">
<t pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" s
ectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="t
itle" sectionFormat="of" target="name-contributors">Contributors</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" s
ectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="t
itle" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xre
f></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="pb" title="The Problem"> ="section-1">
<t>Transport protocols like TCP evolve regularly <xref <name slugifiedName="name-introduction">Introduction</name>
target="RFC7414"></xref>. TCP has been improved in different ways. <section anchor="pb" numbered="true" toc="include" removeInRFC="false" pn=
Some improvements such as changing the initial window size <xref "section-1.1">
target="RFC6928"></xref> or modifying the congestion control scheme <name slugifiedName="name-the-problem">The Problem</name>
can be applied independently on clients and servers. Other <t pn="section-1.1-1">Transport protocols like TCP evolve regularly <xre
improvements such as Selective Acknowledgments <xref f target="RFC7414" format="default" sectionFormat="of" derivedContent="RFC7414"/
target="RFC2018"></xref> or large windows <xref >. TCP has been improved in
target="RFC7323"></xref> require a new TCP option or to change the different ways. Some improvements such as changing the initial window
semantics of some fields in the TCP header. These modifications must size <xref target="RFC6928" format="default" sectionFormat="of" derivedC
be deployed on both clients and servers to be actually used on the ontent="RFC6928"/> or modifying the
Internet. Experience with the latter class of TCP extensions reveals congestion control scheme can be applied independently on Clients and
that their deployment can require many years. Fukuda reports in <xref Servers. Other improvements such as Selective Acknowledgments <xref targ
target="Fukuda2011"></xref> results of a decade of measurements et="RFC2018" format="default" sectionFormat="of" derivedContent="RFC2018"/> or l
showing the deployment of Selective Acknowledgments, Window Scale, and arge windows <xref target="RFC7323" format="default" sectionFormat="of" derivedC
TCP Timestamps. <xref target="ANRW17"></xref> describes measurements ontent="RFC7323"/> require a new TCP option or
showing that TCP Fast Open (TFO) <xref target="RFC7413"></xref> is changing the semantics of some fields in the TCP header. These
still not widely deployed.</t> modifications must be deployed on both Clients and Servers to be
actually used on the Internet. Experience with the latter class of TCP
<t>There are some situations where the transport stack used on clients extensions reveals that their deployment can require many
(or servers) can be upgraded at a faster pace than the transport stack years. Fukuda reports in <xref target="Fukuda2011" format="default" sect
running on servers (or clients). In those situations, clients would ionFormat="of" derivedContent="Fukuda2011"/>
typically want to benefit from the features of an improved transport results of a decade of measurements showing the deployment of
protocol even if the servers have not yet been upgraded and Selective Acknowledgments, Window Scale, and TCP Timestamps. <xref targe
conversely. Some assistance from the network to make use of these t="ANRW17" format="default" sectionFormat="of" derivedContent="ANRW17"/> describ
features is valuable. For example, Performance Enhancing Proxies <xref es measurements showing that
target="RFC3135"></xref>, and other service functions have been TCP Fast Open (TFO) <xref target="RFC7413" format="default" sectionForma
deployed as solutions to improve TCP performance over links with t="of" derivedContent="RFC7413"/> is still
specific characteristics.</t> not widely deployed.</t>
<t pn="section-1.1-2">There are some situations where the transport stac
k used on Clients
(or Servers) can be upgraded at a faster pace than the transport stack
running on Servers (or Clients).
<t>Recent examples of TCP extensions include Multipath TCP (MPTCP) In those situations, Clients (or Servers) would typically want to benefit
<xref target="RFC6824"></xref> or TCPINC <xref from the features of an improved transport protocol even if the Servers (or
target="RFC8548"></xref>. Those extensions provide features that are Clients) have not yet been upgraded.
interesting for clients such as wireless devices. With Multipath TCP,
those devices could seamlessly use Wireless Local Area Network (WLAN)
and cellular networks, for bonding purposes, faster hand-overs, or
better resiliency. Unfortunately, deploying those extensions on both a
wide range of clients and servers remains difficult.</t>
<t>More recently, 5G bonding experimentation has been conducted into Some assistance from the network to make use of these features is
valuable. For example, Performance Enhancing Proxies <xref target="RFC3135" form
at="default" sectionFormat="of" derivedContent="RFC3135"/> and other service fun
ctions have been deployed as solutions
to improve TCP performance over links with specific characteristics.</t>
<t pn="section-1.1-3">Recent examples of TCP extensions include Multipat
h TCP (MPTCP)
<xref target="RFC8684" format="default" sectionFormat="of" derivedConten
t="RFC8684"/> or tcpcrypt <xref target="RFC8548" format="default" sectionFormat=
"of" derivedContent="RFC8548"/>. Those extensions
provide features that are interesting for Clients such as wireless
devices. With Multipath TCP, those devices could seamlessly use
Wireless Local Area Network (WLAN) and cellular networks for bonding
purposes, faster hand-overs, or better resiliency. Unfortunately,
deploying those extensions on both a wide range of Clients and Servers
remains difficult.</t>
<t pn="section-1.1-4">More recently, 5G bonding experimentation has been
conducted into
global range of the incumbent 4G (LTE) connectivity using newly global range of the incumbent 4G (LTE) connectivity using newly
devised clients and a Multipath TCP proxy. Even if the 5G and the 4G devised Clients and a Multipath TCP proxy. Even if the 5G and 4G
bonding (that relies upon Multipath TCP) increases the bandwidth, it bonding (that relies upon Multipath TCP) increases the bandwidth, it
is as well crucial to minimize latency for all the way between is also crucial to minimize latency entirely between end hosts
endhosts regardless of whether intermediate nodes are inside or regardless of whether intermediate nodes are inside or outside of the
outside of the mobile core. In order to handle Ultra Reliable Low mobile core. In order to handle Ultra-Reliable Low Latency
Latency Communication (URLLC) for the next generation mobile network, Communication (URLLC) for the next-generation mobile network,
Multipath TCP and its proxy mechanism such as the one used to provide Multipath TCP and its proxy mechanism such as the one used to provide
Access Traffic Steering, Switching, and Splitting (ATSSS) must be Access Traffic Steering, Switching, and Splitting (ATSSS) must be
optimized to reduce latency <xref target="TS23501"></xref>.</t> optimized to reduce latency <xref target="TS23501" format="default" sect ionFormat="of" derivedContent="TS23501"/>.</t>
</section> </section>
<section anchor="network-assisted-connections-the-rationale" numbered="tru
<section anchor="network-assisted-connections-the-rationale" e" toc="include" removeInRFC="false" pn="section-1.2">
title="Network-Assisted Connections: The Rationale"> <name slugifiedName="name-network-assisted-connection">Network-Assisted
<t>This document specifies an application proxy, called Transport Connections: The Rationale</name>
<t pn="section-1.2-1">This document specifies an application proxy calle
d Transport
Converter. A Transport Converter is a function that is installed by a Converter. A Transport Converter is a function that is installed by a
network operator to aid the deployment of TCP extensions and to network operator to aid the deployment of TCP extensions and to
provide the benefits of such extensions to clients in particular. A provide the benefits of such extensions to Clients in particular. A
Transport Converter may provide conversion service for one or more TCP Transport Converter may provide conversion service for one or more TCP
extensions. Which TCP extensions are eligible to the conversion extensions. Which TCP extensions are eligible for the conversion
service is deployment-specific. The conversion service is provided by service is deployment specific. The conversion service is provided by
means of the 0-RTT TCP Convert Protocol (Convert), that is an means of the 0-RTT TCP Convert Protocol (Convert), which is an
application-layer protocol which uses a specific TCP port number on application-layer protocol that uses a specific TCP port number on
the Converter.</t> the Converter.</t>
<t pn="section-1.2-2">The Convert Protocol provides Zero Round-Trip Time
<t>The Convert Protocol provides Zero Round-Trip Time (0-RTT) (0-RTT)
conversion service since no extra delay is induced by the protocol conversion service since no extra delay is induced by the protocol
compared to connections that are not proxied. Particularly, the compared to connections that are not proxied. Particularly, the
Convert Protocol does not require extra signaling setup delays before Convert Protocol does not require extra signaling setup delays before
making use of the conversion service. The Convert Protocol does not making use of the conversion service. The Convert Protocol does not
require any encapsulation (no tunnels, whatsoever).</t> require any encapsulation (no tunnels, whatsoever).</t>
<t pn="section-1.2-3">The Transport Converter adheres to the main steps
<t>The Transport Converter adheres to the main steps drawn in Section drawn in <xref target="RFC1919" sectionFormat="of" section="3" format="default"
3 of <xref target="RFC1919"></xref>. In particular, a Transport derivedLink="https://rfc-editor.org/rfc/rfc1919#section-3" derivedContent="RFC19
Converter achieves the following:</t> 19"/>. In particular, a
Transport Converter achieves the following:</t>
<t><list style="symbols"> <ul spacing="normal" bare="false" empty="false" pn="section-1.2-4">
<t>Listen for client sessions;</t> <li pn="section-1.2-4.1">Listening for Client sessions;</li>
<li pn="section-1.2-4.2">Receiving the address of the Server from the
<t>Receive from a client the address of the server;</t> Client;</li>
<li pn="section-1.2-4.3">Setting up a session to the Server;</li>
<t>Setup a session to the server;</t> <li pn="section-1.2-4.4">Relaying control messages and data between th
e Client and the
<t>Relay control messages and data between the client and the Server;</li>
server;</t> <li pn="section-1.2-4.5">Performing access controls according to local
policies.</li>
<t>Perform access controls according to local policies.</t> </ul>
</list></t> <t pn="section-1.2-5">The main advantage of network-assisted conversion
services is that
<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 they enable new TCP extensions to be used on a subset of the path
between endpoints, which encourages the deployment of these between endpoints, which encourages the deployment of these
extensions. Furthermore, the Transport Converter allows the client and extensions. Furthermore, the Transport Converter allows the Client and
the server to directly negotiate TCP extensions for the sake of native the Server to directly negotiate TCP extensions for the sake of native
support along the full path.</t> support along the full path.</t>
<t pn="section-1.2-6">The Convert Protocol is a generic mechanism to pro
<t>The Convert Protocol is a generic mechanism to provide 0-RTT vide 0-RTT
conversion service. As a sample applicability use case, this document conversion service. As a sample applicability use case, this document
specifies how the Convert Protocol applies for Multipath TCP. It is specifies how the Convert Protocol applies for Multipath TCP. It is
out of scope of this document to provide a comprehensive list of all out of scope of this document to provide a comprehensive list of all
potential conversion services. Applicability documents may be defined potential conversion services. Applicability documents may be defined
in the future.</t> in the future.</t>
<t pn="section-1.2-7">This document does not assume that all the traffic
<t>This document does not assume that all the traffic is eligible to is eligible for
the network-assisted conversion service. Only a subset of the traffic the network-assisted conversion service. Only a subset of the traffic
will be forwarded to a Transport Converter according to a set of will be forwarded to a Transport Converter according to a set of
policies. These policies, and how they are communicated to endpoints, policies. These policies, and how they are communicated to endpoints,
are out of scope. Furthermore, it is possible to bypass the Transport are out of scope. Furthermore, it is possible to bypass the Transport
Converter to connect directly to the servers that already support the Converter to connect directly to the Servers that already support the
required TCP extension(s).</t> required TCP extension(s).</t>
<t pn="section-1.2-8">This document assumes an explicit model in which a
<t>This document assumes an explicit model in which a client is Client is
configured with one or a list of Transport Converters (statically or configured with one or a list of Transport Converters (statically or
through protocols such as <xref through protocols such as <xref target="I-D.boucadair-tcpm-dhc-converter
target="I-D.boucadair-tcpm-dhc-converter"></xref>). Configuration " format="default" sectionFormat="of" derivedContent="DHC-CONVERTER"/>). Configu
ration
means are outside the scope of this document.</t> means are outside the scope of this document.</t>
<t pn="section-1.2-9">The use of a Transport Converter means that there
<t>The use of a Transport Converter means that there is no end-to-end is no end-to-end
transport connection between the client and server. This could transport connection between the Client and Server. This could
potentially create problems in some scenarios such as those discussed potentially create problems in some scenarios such as those discussed
in Section 4 of <xref target="RFC3135"></xref>. Some of these problems in <xref target="RFC3135" sectionFormat="of" section="4" format="default
may not be applicable, for example, a Transport Converter can inform a " derivedLink="https://rfc-editor.org/rfc/rfc3135#section-4" derivedContent="RFC
client by means of Network Failure (65) or Destination Unreachable 3135"/>. Some of these problems
(97) error messages (<xref target="sec-error"></xref>) that it may not be applicable. For example, a Transport Converter can inform a
encounters a failure problem; the client can react accordingly. An Client by means of Network Failure (65) or Destination Unreachable
(97) error messages (<xref target="sec-error" format="default" sectionFo
rmat="of" derivedContent="Section 6.2.8"/>) that it
encounters a failure problem; the Client can react accordingly. An
endpoint, or its network administrator, can assess the benefit endpoint, or its network administrator, can assess the benefit
provided by the Transport Converter service versus the risk. This is provided by the Transport Converter service versus the risk. This is
one reason why the Transport Converter functionality has to be one reason why the Transport Converter functionality has to be
explicitly requested by an endpoint.</t> explicitly requested by an endpoint.</t>
<t pn="section-1.2-10">
<t>This document is organized as follows. First, <xref This document is organized as follows:
target="sec-socks"></xref> provides a brief overview of the </t>
differences between the well-known SOCKS protocol and the 0-RTT <ul empty="true" bare="false" spacing="normal" pn="section-1.2-11">
Convert protocol. <xref target="sec-arch"></xref> provides a brief <li pn="section-1.2-11.1">
explanation of the operation of Transport Converters. Then, <xref <xref target="sec-socks" format="default" sectionFormat="of" derived
target="sec-protocol"></xref> describes the Convert Protocol. <xref Content="Section 3"/> provides a brief overview of the differences
target="sec-tcpoptions"></xref> discusses how Transport Converters can between the well-known SOCKS protocol and the 0-RTT TCP Convert Protocol.
be used to support different TCP extensions. <xref </li>
target="sec-middleboxes"></xref> then discusses the interactions with <li pn="section-1.2-11.2">
middleboxes, while <xref target="sec-security"></xref> focuses on the <xref target="sec-arch" format="default" sectionFormat="of" derivedC
security considerations. <xref target="sec-api"></xref> describes how ontent="Section 4"/> provides a brief explanation of the operation of Transport
a TCP stack would need to support the protocol described in this Converters. </li>
document.</t> <li pn="section-1.2-11.3">
<xref target="sample-examples" format="default" sectionFormat="of" d
erivedContent="Section 5"/> includes a set of sample examples to illustrate the
overall
behavior.
</li>
<li pn="section-1.2-11.4">
<xref target="sec-protocol" format="default" sectionFormat="of" deri
vedContent="Section 6"/> describes the Convert Protocol.
</li>
<li pn="section-1.2-11.5">
<xref target="sec-tcpoptions" format="default" sectionFormat="of" de
rivedContent="Section 7"/> discusses how Transport Converters can be used to sup
port
different TCP extensions. </li>
<li pn="section-1.2-11.6">
<xref target="sec-middleboxes" format="default" sectionFormat="of" d
erivedContent="Section 8"/> then discusses the interactions with middleboxes.
</li>
<li pn="section-1.2-11.7">
<xref target="sec-security" format="default" sectionFormat="of" deri
vedContent="Section 9"/> focuses on security considerations. </li>
<li pn="section-1.2-11.8">
<xref target="sec-api" format="default" sectionFormat="of" derivedCo
ntent="Appendix A"/> describes how a TCP stack would need to support the
protocol described in this document.
</li>
</ul>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.3
<section title="Applicability Scope"> ">
<t>0-RTT TCP Convert Protocol specified in this document MUST be used <name slugifiedName="name-applicability-scope">Applicability Scope</name
>
<t pn="section-1.3-1">The 0-RTT TCP Convert Protocol specified in this d
ocument <bcp14>MUST</bcp14> be used
in a single administrative domain deployment model. That is, the in a single administrative domain deployment model. That is, the
entity offering the connectivity service to a client is also be entity entity offering the connectivity service to a Client is also the entity
which owns and operates the Transport Converter, with no transit over that owns and operates the Transport Converter, with no transit over
a third-party network.</t> a third-party network.</t>
<t pn="section-1.3-2">Future deployment of Transport Converters by third
<t>Future deployment of Transport Converters by third parties MUST parties
adhere to the mutual authentication requirements in <xref <bcp14>MUST</bcp14> adhere to the mutual authentication requirements
target="authorization"></xref> to prevent illegitimate traffic in <xref target="authorization" format="default" sectionFormat="of" deri
interception (<xref target="traffic-theft"></xref>), in vedContent="Section 9.2"/> to prevent
particular.</t> illegitimate traffic interception (<xref target="traffic-theft" format="
default" sectionFormat="of" derivedContent="Section 9.4"/>) in particular.</t>
</section> </section>
</section> </section>
<section anchor="conventions-and-definitions" numbered="true" toc="include"
<section anchor="sec-socks" title="Differences with SOCKSv5"> removeInRFC="false" pn="section-2">
<t>Several IETF protocols provide proxy services; the closest to the <name slugifiedName="name-conventions-and-definitions">Conventions and Def
0-RTT Convert protocol being the SOCKSv5 protocol <xref initions</name>
target="RFC1928"></xref>. This protocol is already used to deploy <t pn="section-2-1">
Multipath TCP in some cellular networks (Section 2.2 of <xref The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
target="RFC8041"></xref>).</t> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
<t>A SOCKS Client creates a connection to a SOCKS Proxy, exchanges OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="sec-socks" numbered="true" toc="include" removeInRFC="false
" pn="section-3">
<name slugifiedName="name-differences-with-socksv5">Differences with SOCKS
v5</name>
<t pn="section-3-1">Several IETF protocols provide proxy services, the clo
sest to the
0-RTT TCP Convert Protocol being the SOCKSv5 protocol <xref target="RFC192
8" format="default" sectionFormat="of" derivedContent="RFC1928"/>. This protocol
is already used to deploy Multipath
TCP in some cellular networks (<xref target="RFC8041" sectionFormat="of" s
ection="2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8041#se
ction-2.2" derivedContent="RFC8041"/>).</t>
<t pn="section-3-2">A SOCKS Client creates a connection to a SOCKS Proxy,
exchanges
authentication information, and indicates the IP address and port number authentication information, and indicates the IP address and port number
of the target Server. At this point, the SOCKS Proxy creates a of the target Server. At this point, the SOCKS Proxy creates a
connection towards the target Server and relays all data between the two connection towards the target Server and relays all data between the two
proxied connections. The operation of an implementation based on SOCKSv5 proxied connections. The operation of an implementation based on SOCKSv5
(without authentication) is illustrated in <xref (without authentication) is illustrated in <xref target="fig-socks5" forma
target="fig-socks5"></xref>.</t> t="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
<figure anchor="fig-socks5" align="left" suppress-title="false" pn="figure
<figure anchor="fig-socks5" -1">
title="Establishment of a TCP Connection through a SOCKS Proxy Wit <name slugifiedName="name-establishment-of-a-tcp-conn">Establishment of
hout Authentication"> a TCP Connection through a SOCKS Proxy without Authentication</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-3-3.1">
Client SOCKS Proxy Server Client SOCKS Proxy Server
| | | | | |
| --------------------> | | | --------------------&gt; | |
| SYN | | | SYN | |
| <-------------------- | | | &lt;-------------------- | |
| SYN+ACK | | | SYN+ACK | |
| --------------------> | | | --------------------&gt; | |
| ACK | | | ACK | |
| | | | | |
| --------------------> | | | --------------------&gt; | |
|Version=5, Auth Methods| | |Version=5, Auth Methods| |
| <-------------------- | | | &lt;-------------------- | |
| Method | | | Method | |
| --------------------> | | | --------------------&gt; | |
|Auth Request (unless "No auth" method negotiated) |Auth Request (unless "No auth" method negotiated)
| <-------------------- | | | &lt;-------------------- | |
| Auth Response | | | Auth Response | |
| --------------------> | | | --------------------&gt; | |
| Connect Server:Port | --------------------> | | Connect Server:Port | --------------------&gt; |
| | SYN | | | SYN |
| | <-------------------- | | | &lt;-------------------- |
| | SYN+ACK | | | SYN+ACK |
| <-------------------- | | | &lt;-------------------- | |
| Succeeded | | | Succeeded | |
| --------------------> | | | --------------------&gt; | |
| Data1 | | | Data1 | |
| | --------------------> | | | --------------------&gt; |
| | Data1 | | | Data1 |
| | <-------------------- | | | &lt;-------------------- |
| | Data2 | | | Data2 |
| <-------------------- | | | &lt;-------------------- | |
| Data2 | | | Data2 | |
... ...
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-3-4">When SOCKS is used, an "end-to-end" connection between
<t>When SOCKS is used, an "end-to-end" connection between a Client and a a Client and a
Server becomes a sequence of two TCP connections that are glued together Server becomes a sequence of two TCP connections that are glued together
on the SOCKS Proxy. The SOCKS Client and Server exchange control on the SOCKS Proxy. The SOCKS Client and Server exchange control
information at the beginning of the bytestream on the Client-Proxy information at the beginning of the bytestream on the Client-Proxy
connection. The SOCKS Proxy then creates the connection with the target connection. The SOCKS Proxy then creates the connection with the target
Server and then glues the two connections together so that all bytes 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 sent by the application (Client) to the SOCKS Proxy are relayed to the
Server and vice versa.</t> Server and vice versa.</t>
<t pn="section-3-5">The Convert Protocol is also used on TCP proxies that
<t>The Convert Protocol is also used on TCP proxies that relay data relay data
between an upstream and a downstream connection, but there are important between an upstream and a downstream connection, but there are important
differences with SOCKSv5. A first difference is that the 0-RTT Convert differences with SOCKSv5. A first difference is that the 0-RTT TCP
protocol exchanges all the control information during the initial RTT. Convert Protocol exchanges all the control information during the
This reduces the connection establishment delay compared to SOCKS which initial RTT. This reduces the connection establishment delay compared
requires two or more round-trip-times before the establishment of the to SOCKS, which requires two or more round-trip times before the
downstream connection towards the final destination. In today's establishment of the downstream connection towards the final
Internet, latency is an important metric and various protocols have been destination. In today's Internet, latency is an important metric, and
tuned to reduce their latency <xref various protocols have been tuned to reduce their latency <xref target="I-
target="I-D.arkko-arch-low-latency"></xref>. A recently proposed D.arkko-arch-low-latency" format="default" sectionFormat="of" derivedContent="LO
extension to SOCKS leverages the TCP Fast Open (TFO) option <xref W-LATENCY"/>. A recently
target="I-D.olteanu-intarea-socks-6"></xref> to reduce this delay.</t> proposed extension to SOCKS leverages the TCP Fast Open (TFO) option
<xref target="I-D.olteanu-intarea-socks-6" format="default" sectionFormat=
<t>A second difference is that the Convert Protocol explicitly takes the "of" derivedContent="INTAREA-SOCKS"/> to reduce
this delay.</t>
<t pn="section-3-6">A second difference is that the Convert Protocol expli
citly takes the
TCP extensions into account. By using the Convert Protocol, the Client TCP extensions into account. By using the Convert Protocol, the Client
can learn whether a given TCP extension is supported by the destination can learn whether a given TCP extension is supported by the destination
Server. This enables the Client to bypass the Transport Converter when Server. This enables the Client to bypass the Transport Converter when
the Server supports the required TCP extension(s). Neither SOCKSv5 <xref the Server supports the required TCP extension(s). Neither SOCKSv5 <xref t
target="RFC1928"></xref> nor the proposed SOCKSv6 <xref arget="RFC1928" format="default" sectionFormat="of" derivedContent="RFC1928"/> n
target="I-D.olteanu-intarea-socks-6"></xref> provide such a feature.</t> or the proposed SOCKSv6 <xref target="I-D.olteanu-intarea-socks-6" format="defau
lt" sectionFormat="of" derivedContent="INTAREA-SOCKS"/> provide such a
<t>A third difference is that a Transport Converter will only confirm feature.</t>
<t pn="section-3-7">A third difference is that a Transport Converter will
only confirm
the establishment of the connection initiated by the Client provided the establishment of the connection initiated by the Client provided
that the downstream connection has already been accepted by the Server. that the downstream connection has already been accepted by the Server.
If the Server refuses the connection establishment attempt from the If the Server refuses the connection establishment attempt from the
Transport Converter, then the upstream connection from the Client is Transport Converter, then the upstream connection from the Client is
rejected as well. This feature is important for applications that check 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 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> selection of a Server <xref target="RFC8305" format="default" sectionForma
t="of" derivedContent="RFC8305"/>.</t>
<t>A fourth difference is that the 0-RTT Convert protocol only allows <t pn="section-3-8">A fourth difference is that the 0-RTT TCP Convert Prot
ocol only allows
the Client to specify the IP address/port number of the destination the Client to specify the IP address/port number of the destination
server and not a DNS name. We evaluated an alternate design that 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 included the DNS name of the remote peer instead of its IP address as in
SOCKS <xref target="RFC1928"></xref>. However, that design was not SOCKS <xref target="RFC1928" format="default" sectionFormat="of" derivedCo
adopted because it induces both an extra load and increased delays on ntent="RFC1928"/>. However, that design
the Transport Converter to handle and manage DNS resolution requests. was not adopted because it induces both an extra load and increased
Note that the name resolution at the Converter may fail (e.g., private delays on the Transport Converter to handle and manage DNS resolution
names discussed in Section 2.1 of <xref target="RFC6731"></xref>) or may requests. Note that the name resolution at the Converter may fail
not match the one that would be returned by a Client's resolution (e.g., private names discussed in <xref target="RFC6731" sectionFormat="of
library (e.g., Section 2.2 of <xref target="RFC6731"></xref>).</t> " section="2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6731
</section> #section-2.1" derivedContent="RFC6731"/>) or may not match the one that would
be returned by a Client's resolution library (e.g., <xref target="RFC6731"
<section anchor="conventions-and-definitions" sectionFormat="of" section="2.2" format="default" derivedLink="https://rfc-edit
title="Conventions and Definitions"> or.org/rfc/rfc6731#section-2.2" derivedContent="RFC6731"/>).</t>
<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>
</section> </section>
<section anchor="sec-arch" numbered="true" toc="include" removeInRFC="false"
<section anchor="sec-arch" title="Architecture &amp; Behaviors"> pn="section-4">
<section anchor="functional-elements" title="Functional Elements"> <name slugifiedName="name-architecture-and-behaviors">Architecture and Beh
<t>The Convert Protocol considers three functional elements:</t> aviors</name>
<section anchor="functional-elements" numbered="true" toc="include" remove
<t><list style="symbols"> InRFC="false" pn="section-4.1">
<t>Clients;</t> <name slugifiedName="name-functional-elements">Functional Elements</name
>
<t>Transport Converters;</t> <t pn="section-4.1-1">The Convert Protocol considers three functional el
ements:</t>
<t>Servers.</t> <ul spacing="normal" bare="false" empty="false" pn="section-4.1-2">
</list></t> <li pn="section-4.1-2.1">Clients</li>
<li pn="section-4.1-2.2">Transport Converters</li>
<t>A Transport Converter is a network function that proxies all data <li pn="section-4.1-2.3">Servers</li>
</ul>
<t pn="section-4.1-3">A Transport Converter is a network function that p
roxies all data
exchanged over one upstream connection to one downstream connection exchanged over one upstream connection to one downstream connection
and vice versa (<xref target="figtc"></xref>). The Transport and vice versa (<xref target="figtc" format="default" sectionFormat="of"
Converter, thus, maintains state that associates one upstream derivedContent="Figure 2"/>). Thus, the Transport
Converter maintains state that associates one upstream
connection to a corresponding downstream connection.</t> connection to a corresponding downstream connection.</t>
<t pn="section-4.1-4">A connection can be initiated from both sides of t
<t>A connection can be initiated from both sides of the Transport he Transport
Converter (External realm, Internal realm).</t> Converter (External realm, Internal realm).</t>
<figure anchor="figtc" align="left" suppress-title="false" pn="figure-2"
<figure anchor="figtc" >
title="A Transport Converter Proxies Data between Pairs of TCP C <name slugifiedName="name-a-transport-converter-proxi">A Transport Con
onnections"> verter Proxies Data between Pairs of TCP Connections</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-4.1-5.1">
| |
: :
| |
+------------+ +------------+
Client <- upstream ->| Transport |<- downstream -&gt; Server Client <- upstream -&gt;| Transport |&lt;- downstream -&gt; Server
connection | Converter | connection connection | Converter | connection
+------------+ +------------+
| |
Internal realm : External realm Internal realm : External realm
| |
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.1-6">"Client" refers to a software instance embedded on
<t>"Client" refers to a software instance embedded on a host that can a host that can
reach a Transport Converter in the internal realm. The "Client" can reach a Transport Converter in the internal realm. The "Client" can
initiate connections via a Transport Converter (referred to as initiate connections via a Transport Converter (referred to as
outgoing connections). Also, the "Client" can accept incoming outgoing connections). Also, the "Client" can accept incoming
connections via a Transport Converter (referred to as incoming connections via a Transport Converter (referred to as incoming
connections).</t> connections).</t>
<t pn="section-4.1-7">A Transport Converter can be embedded in a standal
<t>A Transport Converter can be embedded in a standalone device or be one device or be
activated as a service on a router. How such function is enabled is activated as a service on a router. How such a function is enabled is
deployment-specific.</t> deployment specific.</t>
<t pn="section-4.1-8">The architecture assumes that new software will be
<t>The architecture assumes that new software will be installed on the installed on the
Client hosts to interact with one or more Transport Converters. Client hosts to interact with one or more Transport Converters.
Furthermore, the architecture allows for making use of new TCP Furthermore, the architecture allows for making use of new TCP
extensions even if those are not supported by a given server.</t> extensions even if those are not supported by a given Server.</t>
<t pn="section-4.1-9">A Client is configured, through means that are out
<t>A Client is configured, through means that are outside the scope of side the scope of
this document, with the names and/or the addresses of one or more this document, with the names and/or addresses of one or more
Transport Converters and the TCP extensions that they support. The Transport Converters and the TCP extensions that they support. The
procedure for selecting a Transport Converter among a list of procedure for selecting a Transport Converter among a list of
configured Transport Converters is outside the scope of this configured Transport Converters is outside the scope of this
document.</t> document.</t>
<t pn="section-4.1-10">One of the benefits of this design is that differ
<t>One of the benefits of this design is that different transport ent transport
protocol extensions can be used on the upstream and the downstream protocol extensions can be used on the upstream and the downstream
connections. This encourages the deployment of new TCP extensions connections. This encourages the deployment of new TCP extensions
until they are widely supported by servers, in particular.</t> until they are widely supported, in particular, by Servers.</t>
<t pn="section-4.1-11">The architecture does not mandate anything on the
<t>The architecture does not mandate anything on the Server side.</t> Server side.</t>
<t pn="section-4.1-12">Similar to SOCKS, the architecture does not inter
<t>Similar to SOCKS, the architecture does not interfere with fere with
end-to-end TLS connections <xref target="RFC8446"></xref> between the end-to-end TLS connections <xref target="RFC8446" format="default" secti
Client and the Server (<xref target="figtls"></xref>). In other words, onFormat="of" derivedContent="RFC8446"/> between the
Client and the Server (<xref target="figtls" format="default" sectionFor
mat="of" derivedContent="Figure 3"/>). In other words,
end-to-end TLS is supported in the presence of a Converter.</t> end-to-end TLS is supported in the presence of a Converter.</t>
<figure anchor="figtls" align="left" suppress-title="false" pn="figure-3
<figure anchor="figtls" ">
title="End-to-end TLS via a Transport Converter"> <name slugifiedName="name-end-to-end-tls-via-a-transp">End-to-end TLS
<artwork><![CDATA[ via a Transport Converter</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1-13.1">
Client Transport Server Client Transport Server
| Converter | | Converter |
| | | | | |
/==========================================\ /==========================================\
| End-to-end TLS | | End-to-end TLS |
\==========================================/ \==========================================/
* TLS messages exchanged between the Client * TLS messages exchanged between the Client
and the Server are not shown. and the Server are not shown.
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.1-14">It is out of scope of this document to elaborate
<t>It is out of scope of this document to elaborate on specific on specific
considerations related to the use of TLS in the Client-Converter considerations related to the use of TLS in the Client-Converter
connection leg to exchange Convert messages (in addition to the connection leg to exchange Convert messages (in addition to the
end-to-end TLS connection). In particular, (1) assessment whether end-to-end TLS connection). In particular, (1) assessment of whether
0-RTT data mode discussed in Section 2.3 of <xref 0-RTT data mode discussed in <xref target="RFC8446" sectionFormat="of" s
target="RFC8446"></xref> is safe under replay and (2) specification of ection="2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#se
a profile for its use (Section E.5 of <xref target="RFC8446"></xref>) ction-2.3" derivedContent="RFC8446"/> is safe under replay and (2)
are out of scope.</t> specification of a profile for its use (<xref target="RFC8446" sectionFo
rmat="of" section="E.5" format="default" derivedLink="https://rfc-editor.org/rfc
/rfc8446#appendix-E.5" derivedContent="RFC8446"/>) are out of scope.</t>
</section> </section>
<section anchor="sec-to" numbered="true" toc="include" removeInRFC="false"
<section anchor="sec-to" title="Theory of Operation"> pn="section-4.2">
<t>At a high level, the objective of the Transport Converter is to <name slugifiedName="name-theory-of-operation">Theory of Operation</name
>
<t pn="section-4.2-1">At a high level, the objective of the Transport Co
nverter is to
allow the use a specific extension, e.g., Multipath TCP, on a subset 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 of the path even if the peer does not support this extension. This is
illustrated in <xref target="fig-highlevel"></xref> where the Client illustrated in <xref target="fig-highlevel" format="default" sectionForm at="of" derivedContent="Figure 4"/> where the Client
initiates a Multipath TCP connection with the Transport Converter initiates a Multipath TCP connection with the Transport Converter
(packets belonging to the Multipath TCP connection are shown with (packets belonging to the Multipath TCP connection are shown with
"===") while the Transport Converter uses a TCP connection with the "===") while the Transport Converter uses a TCP connection with the
Server.</t> Server.</t>
<figure anchor="fig-highlevel" align="left" suppress-title="false" pn="f
<figure anchor="fig-highlevel" igure-4">
title="An Example of 0-RTT Network-Assisted Outgoing MPTCP Conne <name slugifiedName="name-an-example-of-0-rtt-network">An Example of 0
ction"> -RTT Network-Assisted Outgoing MPTCP Connection</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-4.2-2.1">
Client Transport Server Client Transport Server
| Converter | | Converter |
| | | | | |
|==================>|---------------------&gt;| |==================>|---------------------&gt;|
| | | | | |
|<==================|&lt;---------------------| |<==================|&lt;---------------------|
| | | | | |
Multipath TCP packets TCP packets Multipath TCP packets TCP packets
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.2-3">The packets belonging to a connection established
<t>The packets belonging to a connection established through a through a
Transport Converter may follow a different path than the packets Transport Converter may follow a different path than the packets
directly exchanged between the Client and the Server. Deployments directly exchanged between the Client and the Server. Deployments
should minimize the possible additional delay by carefully selecting should minimize the possible additional delay by carefully selecting
the location of the Transport Converter used to reach a given the location of the Transport Converter used to reach a given
destination.</t> destination.</t>
<t pn="section-4.2-4">When establishing a connection, the Client can, de
<t>When establishing a connection, the Client can, depending on local pending on local
policies, either contact the Server directly (e.g., by sending a TCP policies, either contact the Server directly (e.g., by sending a TCP
SYN towards the Server) or create the connection via a Transport SYN towards the Server) or create the connection via a Transport
Converter. In the latter case (that is, the conversion service is Converter. In the latter case (that is, the conversion service is
used), the Client initiates a connection towards the Transport used), the Client initiates a connection towards the Transport
Converter and indicates the IP address and port number of the Server Converter and indicates the IP address and port number of the Server
within the connection establishment packet. Doing so enables the within the connection establishment packet. Doing so enables the
Transport Converter to immediately initiate a connection towards that Transport Converter to immediately initiate a connection towards that
Server, without experiencing an extra delay. The Transport Converter Server without experiencing an extra delay. The Transport Converter
waits until the receipt of the confirmation that the Server agrees to waits until the receipt of the confirmation that the Server agrees to
establish the connection before confirming it to the Client.</t> establish the connection before confirming it to the Client.</t>
<t pn="section-4.2-5">The Client places the destination address and port
<t>The Client places the destination address and port number of the number of the
Server in the payload of the SYN sent to the Transport Converter to Server in the payload of the SYN sent to the Transport Converter to
minimize connection establishment delays. The Transport Converter minimize connection establishment delays. The Transport Converter
maintains two connections that are combined together:</t> maintains two connections that are combined together:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-4.2-6">
<t><list style="symbols"> <li pn="section-4.2-6.1">The upstream connection is the one between th
<t>the upstream connection is the one between the Client and the e Client and the
Transport Converter.</t> Transport Converter.</li>
<li pn="section-4.2-6.2">The downstream connection is the one between
<t>the downstream connection is the one between the Transport the Transport
Converter and the Server.</t> Converter and the Server.</li>
</list></t> </ul>
<t pn="section-4.2-7">Any user data received by the Transport Converter
<t>Any user data received by the Transport Converter over the upstream over the upstream
(or downstream) connection is proxied over the downstream (or (or downstream) connection is proxied over the downstream (or
upstream) connection.</t> upstream) connection.</t>
<t pn="section-4.2-8"><xref target="fig-estab" format="default" sectionF
<t><xref target="fig-estab"></xref> illustrates the establishment of ormat="of" derivedContent="Figure 5"/> illustrates the establishment of
an outgoing TCP connection by a Client through a Transport an outgoing TCP connection by a Client through a Transport
Converter.</t> Converter.</t>
<aside pn="section-4.2-9">
<t><list style="symbols"> <t pn="section-4.2-9.1">
<t>Note: The information shown between brackets in <xref Note: The information shown between brackets in <xref target="fig-esta
target="fig-estab"></xref> (and other figures in the document) b" format="default" sectionFormat="of" derivedContent="Figure 5"/> (and other fi
refers to Convert Protocol messages described in <xref gures in the
target="sec-protocol"></xref>.</t> document) refers to Convert Protocol messages described in <xref target
</list></t> ="sec-protocol" format="default" sectionFormat="of" derivedContent="Section 6"/>
.</t>
<figure anchor="fig-estab" </aside>
title="Establishment of an Outgoing TCP Connection Through a Tra <figure anchor="fig-estab" align="left" suppress-title="false" pn="figur
nsport Converter"> e-5">
<artwork><![CDATA[ <name slugifiedName="name-establishment-of-an-outgoin">Establishment o
f an Outgoing TCP Connection through a Transport Converter</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2-10.1">
Transport Transport
Client Converter Server Client Converter Server
| | | | | |
|SYN [->Server:port]| SYN | |SYN [-&gt;Server:port]| SYN |
|------------------>|--------------------->| |------------------&gt;|---------------------&gt;|
|<------------------|<---------------------| |&lt;------------------|&lt;---------------------|
| SYN+ACK [ ] | SYN+ACK | | SYN+ACK [ ] | SYN+ACK |
| ... | ... | | ... | ... |
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.2-11">The Client sends a SYN destined to the Transport
<t>The Client sends a SYN destined to the Transport Converter. The Converter. The
payload of this SYN contains the address and port number of the payload of this SYN contains the address and port number of the
Server. The Transport Converter does not reply immediately to this Server. The Transport Converter does not reply immediately to this
SYN. It first tries to create a TCP connection towards the target SYN. It first tries to create a TCP connection towards the target
Server. If this upstream connection succeeds, the Transport Converter Server. If this upstream connection succeeds, the Transport Converter
confirms the establishment of the connection to the Client by confirms the establishment of the connection to the Client by
returning a SYN+ACK and the first bytes of the bytestream contain returning a SYN+ACK and the first bytes of the bytestream contain
information about the TCP options that were negotiated with the information about the TCP options that were negotiated with the
Server. Also, a state entry is instantiated for this connection. This Server. Also, a state entry is instantiated for this connection. This
state entry is used by the Converter to handle subsequent messages state entry is used by the Converter to handle subsequent messages
belonging to the connection.</t> belonging to the connection.</t>
<t pn="section-4.2-12">The connection can also be established from the I
<t>The connection can also be established from the Internet towards a nternet towards a
Client via a Transport Converter (<xref target="fig-estab2"></xref>). Client via a Transport Converter (<xref target="fig-estab2" format="defa
This is typically the case when the Client hosts an application server ult" sectionFormat="of" derivedContent="Figure 6"/>). This is typically the cas
that listens to a specific port number. When the Converter receives an e when the Client hosts
incoming SYN from a remote host, it checks if it can provide the an application Server that listens to a specific port number. When the
conversion service for the destination IP address and destination port Converter receives an incoming SYN from a remote host, it checks if it
number of that SYN. The Transport Converter receives this SYN because can provide the conversion service for the destination IP address and
it is, for example, on the path between the remote host and the Client destination port number of that SYN. The Transport Converter receives
or it provides address sharing service for the Client (Section 2 of this SYN because it is, for example, on the path between the remote
<xref target="RFC6269"></xref>). If the check fails, the packet is host and the Client or it provides address-sharing service for the
silently ignored by the Converter. If the check is successful, the Client (<xref target="RFC6269" sectionFormat="of" section="2" format="de
Converter tries to initiate a TCP connection towards the Client from fault" derivedLink="https://rfc-editor.org/rfc/rfc6269#section-2" derivedContent
its own address and using its configured TCP options. In the SYN that ="RFC6269"/>). If
corresponds to this connection attempt, the Transport Convert inserts the check fails, the packet is silently ignored by the Converter. If
a TLV message that indicates the source address and port number of the the check is successful, the Converter tries to initiate a TCP
remote host. A transport session entry is created by the Converter for connection towards the Client from its own address and using its
this connection. SYN+ACK and ACK will be then exchanged between the configured TCP options. In the SYN that corresponds to this connection
Client, the Converter, and remote host to confirm the establishment of attempt, the Transport Convert inserts a TLV message that indicates
the connection. The Converter uses the transport session entry to the source address and port number of the remote host. A transport
proxy packets belonging to the connection.</t> session entry is created by the Converter for this connection. SYN+ACK
and ACK will then be exchanged between the Client, the Converter, and
<figure anchor="fig-estab2" remote host to confirm the establishment of the connection. The
title="Establishment of an Incoming TCP Connection Through a Tra Converter uses the transport session entry to proxy packets belonging
nsport Converter"> to the connection.</t>
<artwork><![CDATA[ <figure anchor="fig-estab2" align="left" suppress-title="false" pn="figu
re-6">
<name slugifiedName="name-establishment-of-an-incomin">Establishment o
f an Incoming TCP Connection through a Transport Converter</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2-13.1">
Transport Remote Transport Remote
Client Converter Host (RH) Client Converter Host (RH)
| | | | | |
|SYN [<-RH IP@:port]| SYN | |SYN [&lt;-RH IP@:port]| SYN |
|<------------------|<---------------------| |&lt;------------------|&lt;---------------------|
|------------------>|--------------------->| |------------------&gt;|---------------------&gt;|
| SYN+ACK [ ] | SYN+ACK | | SYN+ACK [ ] | SYN+ACK |
| ... | ... | | ... | ... |
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.2-14">Standard TCP (<xref target="RFC0793" format="defa
<t>Standard TCP (<xref target="RFC0793"></xref>, Section 3.4) allows a ult" section="3.4" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rf
c793#section-3.4" derivedContent="RFC0793"/>) allows a
SYN packet to carry data inside its payload but forbids the receiver SYN packet to carry data inside its payload but forbids the receiver
from delivering it to the application until completion of the from delivering it to the application until completion of the
three-way-handshake. To enable applications to exchange data in a TCP three-way-handshake. To enable applications to exchange data in a TCP
handshake, this specification follows an approach similar to TCP Fast handshake, this specification follows an approach similar to TCP Fast
Open <xref target="RFC7413"></xref> and thus removes the constraint by Open <xref target="RFC7413" format="default" sectionFormat="of" derivedC ontent="RFC7413"/> and thus, removes the constraint by
allowing data in SYN packets to be delivered to the Transport allowing data in SYN packets to be delivered to the Transport
Converter application.</t> Converter application.</t>
<t pn="section-4.2-15">As discussed in <xref target="RFC7413" format="de
<t>As discussed in <xref target="RFC7413"></xref>, such change to TCP fault" sectionFormat="of" derivedContent="RFC7413"/>, such
semantic raises two issues. First, duplicate SYNs can cause problems change to TCP semantics raises two issues. First, duplicate SYNs can
for applications that rely on TCP; whether or not a given application cause problems for applications that rely on TCP; whether or not a
is affected dependes on the details of that application protocol. given application is affected depends on the details of that
Second, TCP suffers from SYN flooding attacks <xref application protocol. Second, TCP suffers from SYN flooding attacks
target="RFC4987"></xref>. TFO solves these two problems for <xref target="RFC4987" format="default" sectionFormat="of" derivedConten
applications that can tolerate replays by using the TCP Fast Open t="RFC4987"/>. TFO solves these two
option that includes a cookie. However, the utilization of this option problems for applications that can tolerate replays by using the TCP
consumes space in the limited TCP header. Furthermore, there are Fast Open option that includes a cookie. However, the utilization of
situations, as noted in Section 7.3 of <xref target="RFC7413"></xref> this option consumes space in the limited TCP header. Furthermore,
where it is possible to accept the payload of SYN packets without there are situations, as noted in <xref target="RFC7413" sectionFormat="
creating additional security risks such as a network where addresses of" section="7.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc74
cannot be spoofed and the Transport Converter only serves a set of 13#section-7.3" derivedContent="RFC7413"/>, where it is possible to accept the
hosts that are identified by these addresses.</t> payload of SYN packets without creating additional security risks such
as a network where addresses cannot be spoofed and the Transport
<t>For these reasons, this specification does not mandate the use of Converter only serves a set of hosts that are identified by these
addresses.</t>
<t pn="section-4.2-16">For these reasons, this specification does not ma
ndate the use of
the TCP Fast Open option when the Client sends a connection the TCP Fast Open option when the Client sends a connection
establishment packet towards a Transport Converter. The Convert establishment packet towards a Transport Converter. The Convert
Protocol includes an optional Cookie TLV that provides similar Protocol includes an optional Cookie TLV that provides similar
protection as the TCP Fast Open option without consuming space in the protection as the TCP Fast Open option without consuming space in the
TCP header. Furthermore, this design allows for the use of longer TCP header. Furthermore, this design allows for the use of longer
cookies than <xref target="RFC7413"></xref>.</t> cookies than <xref target="RFC7413" format="default" sectionFormat="of"
derivedContent="RFC7413"/>.</t>
<t>If the downstream (or upstream) connection fails for some reason <t pn="section-4.2-17">If the downstream (or upstream) connection fails
for some reason
(excessive retransmissions, reception of an RST segment, etc.), then (excessive retransmissions, reception of an RST segment, etc.), then
the Converter reacts by forcing the tear-down of the upstream (or the Converter reacts by forcing the teardown of the upstream (or
downstream) connection. In particular, if an ICMP error message that downstream) connection. In particular, if an ICMP error message that
indicates a hard error is received on the downstream connection, the indicates a hard error is received on the downstream connection, the
Converter echoes the Code field of that ICMP message in a Destination Converter echoes the Code field of that ICMP message in a Destination
Unreachable Error TLV (see <xref target="sec-error"></xref>) that it Unreachable Error TLV (see <xref target="sec-error" format="default" sec tionFormat="of" derivedContent="Section 6.2.8"/>) that it
transmits to the Client. Note that if an ICMP error message that transmits to the Client. Note that if an ICMP error message that
indicates a soft error is received on the downstream connection, the indicates a soft error is received on the downstream connection, the
Converter will retransmit the corresponding data until it is Converter will retransmit the corresponding data until it is
acknowledged or the connection times out. A classification of ICMP acknowledged or the connection times out. A classification of ICMP
soft and hard errors is provided in Table 1 of <xref soft and hard errors is provided in Table 1 of <xref target="RFC5461" fo
target="RFC5461"></xref>.</t> rmat="default" sectionFormat="of" derivedContent="RFC5461"/>.</t>
<t pn="section-4.2-18">The same reasoning applies when the upstream conn
<t>The same reasoning applies when the upstream connection ends with ection ends with
an exchange of FIN segments. In this case, the Converter will also an exchange of FIN segments. In this case, the Converter will also
terminate the downstream connection by using FIN segments. If the terminate the downstream connection by using FIN segments. If the
downstream connection terminates with the exchange of FIN segments, downstream connection terminates with the exchange of FIN segments,
the Converter should initiate a graceful termination of the upstream the Converter should initiate a graceful termination of the upstream
connection.</t> connection.</t>
</section> </section>
<section anchor="sec-dbb" numbered="true" toc="include" removeInRFC="false
<section anchor="sec-dbb" " pn="section-4.3">
title="Data Processing at the Transport Converter"> <name slugifiedName="name-data-processing-at-the-tran">Data Processing a
<t>As mentioned in <xref target="sec-to"></xref>, the Transport t the Transport Converter</name>
<t pn="section-4.3-1">As mentioned in <xref target="sec-to" format="defa
ult" sectionFormat="of" derivedContent="Section 4.2"/>, the Transport
Converter acts as a TCP proxy between the upstream connection (i.e., Converter acts as a TCP proxy between the upstream connection (i.e.,
between the Client and the Transport Converter) and the downstream between the Client and the Transport Converter) and the downstream
connection (i.e., between the Transport Converter and the Server).</t> connection (i.e., between the Transport Converter and the Server).</t>
<t pn="section-4.3-2">The control messages (i.e., the Convert messages d
<t>The control messages, discussed in <xref iscussed in <xref target="sec-protocol" format="default" sectionFormat="of" deri
target="sec-protocol"></xref>, establish state (called, transport vedContent="Section 6"/>) establish state (called transport session entry)
session entry) in the Transport Converter that will enable it to proxy in the Transport Converter that will enable it to proxy between the
between the two TCP connections.</t> two TCP connections.</t>
<t pn="section-4.3-3">The Transport Converter uses the transport session
<t>The Transport Converter uses the transport session entry to proxy entry to proxy
packets belonging to the connection. An implementation example of a packets belonging to the connection. An implementation example of a
transport session entry for TCP connections is shown in <xref transport session entry for TCP connections is shown in <xref target="fi
target="fig-dbt"></xref>.</t> g-dbt" format="default" sectionFormat="of" derivedContent="Figure 7"/>.</t>
<figure anchor="fig-dbt" align="left" suppress-title="false" pn="figure-
<figure anchor="fig-dbt" title="An Example of Transport Session Entry"> 7">
<artwork><![CDATA[ <name slugifiedName="name-an-example-of-transport-ses">An Example of T
(C,c) <--> (T,t), (S,s), Lifetime ransport Session Entry</name>
<artwork name="" type="" align="left" alt="" pn="section-4.3-4.1">
Where: (C,c) &lt;--&gt; (T,t), (S,s), Lifetime
* C and c are the source IP address and source port number </artwork>
used by the Client for the upstream connection.
* S and s are the Server's IP address and port number.
* T and t are the source IP address and source port number
used by the Transport Converter to proxy the connection.
* 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> </figure>
<t pn="section-4.3-5"> Where:</t>
<t>Clients send packets bound to connections eligible to the <ul bare="false" empty="false" spacing="normal" pn="section-4.3-6">
<li pn="section-4.3-6.1">C and c are the source IP address and source
port number used by the
Client for the upstream connection.
</li>
<li pn="section-4.3-6.2">S and s are the Server's IP address and port
number.
</li>
<li pn="section-4.3-6.3">T and t are the source IP address and source
port number used by the
Transport Converter to proxy the connection.
</li>
<li pn="section-4.3-6.4">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.
</li>
</ul>
<t pn="section-4.3-7">Clients send packets bound to connections eligible
for the
conversion service to the provisioned Transport Converter and conversion service to the provisioned Transport Converter and
destination port number. This applies for both control messages and destination port number. This applies for both control messages and
data. Additional information is supplied by Clients to the Transport data. Additional information is supplied by Clients to the Transport
Converter by means of Convert messages as detailed in <xref Converter by means of Convert messages as detailed in <xref target="sec-
target="sec-protocol"></xref>. User data can be included in SYN or protocol" format="default" sectionFormat="of" derivedContent="Section 6"/>. User
non-SYN messages. User data is unambiguously distinguished from 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 Convert TLVs by a Transport Converter owing to the Convert Fixed
Header in the Convert messages (<xref target="sec-header"></xref>). Header in the Convert messages (<xref target="sec-header" format="defaul
These Convert TLVs are destined to the Transport Convert and are, t" sectionFormat="of" derivedContent="Section 6.1"/>). These Convert TLVs are d
thus, removed by the Transport Converter when proxying between the two estined to the Transport
connections.</t> 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 <t pn="section-4.3-8">Upon receipt of a packet that belongs to an existi
between a Client and the Transport Converter the Converter proxies the ng connection
between a Client and the Transport Converter, the Converter proxies the
user data to the Server using the information stored in the user data to the Server using the information stored in the
corresponding transport session entry. For example, in reference to corresponding transport session entry. For example, in reference to
<xref target="fig-dbt"></xref>, the Transport Converter proxies the <xref target="fig-dbt" format="default" sectionFormat="of" derivedConten
data received from (C, c) downstream using (T,t) as source transport t="Figure 7"/>, the Transport Converter proxies the
data received from (C,⁠c) downstream using (T,t) as source transport
address and (S,s) as destination transport address.</t> address and (S,s) as destination transport address.</t>
<t pn="section-4.3-9">A similar process happens for data sent from the S
<t>A similar process happens for data sent from the Server. The erver. The
Converter acts as a TCP proxy and sends the data to the Client relying Converter acts as a TCP proxy and sends the data to the Client relying
upon the information stored in a transport session entry. The upon the information stored in a transport session entry. The
Converter associates a lifetime with state entries used to bind an Converter associates a lifetime with state entries used to bind an
upstream connection with its downstream connection.</t> upstream connection with its downstream connection.</t>
<t pn="section-4.3-10">When Multipath TCP is used between the Client and
<t>When Multipath TCP is used between the Client and the Transport the Transport
Converter, the Converter maintains more state (e.g. information about Converter, the Converter maintains more state (e.g., information about
the subflows) for each Multipath TCP connection. The procedure the subflows) for each Multipath TCP connection. The procedure
described above continues to apply except that the Converter needs to described above continues to apply except that the Converter needs to
manage the establishment/termination of subflows and schedule packets manage the establishment/termination of subflows and schedule packets
among the established ones. These operations are part of the Multipath among the established ones. These operations are part of the Multipath
TCP implementation. They are independent of the Convert protocol that TCP implementation. They are independent of the Convert Protocol that
only processes the Convert messages in the beginning of the only processes the Convert messages in the beginning of the
bytestream.</t> bytestream.</t>
<t pn="section-4.3-11">A Transport Converter may operate in address pres
<t>A Transport Converter may operate in address preservation mode ervation mode
(that is, the Converter does not rewrite the source IP address (i.e., (that is, the Converter does not rewrite the source IP address (i.e.,
C==T)) or address sharing mode (that is, an address pool is shared C==T)) or address-sharing mode (that is, an address pool is shared
among all Clients serviced by the Converter (i.e., C!=T)); refer to among all Clients serviced by the Converter (i.e., C!=T)); refer to
<xref target="sec-add"></xref> for more details. Which behavior to use <xref target="sec-add" format="default" sectionFormat="of" derivedConten
by a Transport Converter is deployment-specific. If address sharing t="Section 4.4"/> for more details. Which
mode is enabled, the Transport Converter MUST adhere to REQ-2 of <xref behavior to use by a Transport Converter is deployment specific. If
target="RFC6888"></xref> which implies a default "IP address pooling" address-sharing mode is enabled, the Transport Converter
behavior of "Paired" (as defined in Section 4.1 of <xref <bcp14>MUST</bcp14> adhere to REQ-2 of <xref target="RFC6888" format="de
target="RFC4787"></xref>) MUST be supported. This behavior is meant to fault" sectionFormat="of" derivedContent="RFC6888"/>, which implies a default "I
avoid breaking applications that depend on the source address P address pooling"
remaining constant.</t> behavior of "Paired" (as defined in <xref target="RFC4787" sectionFormat
="of" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc
4787#section-4.1" derivedContent="RFC4787"/>) <bcp14>MUST</bcp14> be
supported. This behavior is meant to avoid breaking applications that
depend on the source address remaining constant.</t>
</section> </section>
<section anchor="sec-add" numbered="true" toc="include" removeInRFC="false
<section anchor="sec-add" " pn="section-4.4">
title="Address Preservation vs. Address Sharing"> <name slugifiedName="name-address-preservation-vs-add">Address Preservat
<t>The Transport Converter is provided with instructions about the ion vs. Address Sharing</name>
behavior to adopt with regards to the processing of source addresses <t pn="section-4.4-1">The Transport Converter is provided with instructi
of outgoing packets. The following sub-sections discusses two ons about the
behavior to adopt with regard to the processing of source addresses
of outgoing packets. The following subsections discuss two
deployment models for illustration purposes. It is out of the scope of deployment models for illustration purposes. It is out of the scope of
this document to make a recommendation.</t> this document to make a recommendation.</t>
<section anchor="sec-addp" numbered="true" toc="include" removeInRFC="fa
<section anchor="sec-addp" title="Address Preservation"> lse" pn="section-4.4.1">
<t>In this model, the visible source IP address of a packet proxied <name slugifiedName="name-address-preservation">Address Preservation</
name>
<t pn="section-4.4.1-1">In this model, the visible source IP address o
f a packet proxied
by a Transport Converter to a Server is an IP address of the end 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 host (Client). No dedicated IP address pool is provisioned to the
Transport Converter, but the Transport Converter is located on the Transport Converter, but the Transport Converter is located on the
path between the Client and the Server.</t> path between the Client and the Server.</t>
<t pn="section-4.4.1-2">For Multipath TCP, the Transport Converter pre
<t>For Multipath TCP, the Transport Converter preserves the source serves the source
IP address used by the Client when establishing the initial subflow. IP address used by the Client when establishing the initial subflow.
Data conveyed in secondary subflows will be proxied by the Transport Data conveyed in secondary subflows will be proxied by the Transport
Converter using the source IP address of the initial subflow. An Converter using the source IP address of the initial subflow. An
example of a proxied Multipath TCP connection with address example of a proxied Multipath TCP connection with address
preservation is shown in <xref target="fig-addp"></xref>.</t> preservation is shown in <xref target="fig-addp" format="default" sect
ionFormat="of" derivedContent="Figure 8"/>.</t>
<figure anchor="fig-addp" title="Example of Address Preservation"> <figure anchor="fig-addp" align="left" suppress-title="false" pn="figu
<artwork><![CDATA[ re-8">
Transport <name slugifiedName="name-example-of-address-preserva">Example of Ad
Client Converter Server dress Preservation</name>
<artwork name="" type="" align="left" alt="" pn="section-4.4.1-3.1">
Transport
Client Converter Server
@:C1,C2 @:Tc @:S @:C1,C2 @:Tc @:S
|| | | || | |
|src:C1 SYN dst:Tc|src:C1 dst:S| |src:C1 SYN dst:Tc|src:C1 dst:S|
|-------MPC [->S:port]------->|-------SYN------->| |-------MPC [-&gt;S:port]-------&gt;|-------SYN-------&gt;|
|| | | || | |
||dst:C1 src:Tc|dst:C1 src:S| ||dst:C1 src:Tc|dst:C1 src:S|
|<---------SYN/ACK------------|<-----SYN/ACK-----| |&lt;---------SYN/ACK------------|&lt;-----SYN/ACK-----|
|| | | || | |
|src:C1 dst:Tc|src:C1 dst:S| |src:C1 dst:Tc|src:C1 dst:S|
|------------ACK------------->|-------ACK------->| |------------ACK-------------&gt;|-------ACK-------&gt;|
| | | | | |
|src:C2 ... dst:Tc| ... | |src:C2 ... dst:Tc| ... |
||<-----Secondary Subflow---->|src:C1 dst:S| ||&lt;-----Secondary Subflow----&gt;|src:C1 dst:S|
|| |-------data------>| || |-------data------&gt;|
| .. | ... | | .. | ... |
Legend: Legend:
Tc: IP address used by the Transport Converter on the internal Tc: IP address used by the Transport Converter on the internal
realm. realm.
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.4.1-4">The Transport Converter must be on the forward
<t>The Transport Converter must be on the forwarding path of ing path of
incoming traffic. Because the same (destination) IP address is used incoming traffic. Because the same (destination) IP address is used
for both proxied and non-proxied connections, the Transport for both proxied and non-proxied connections, the Transport
Converter should not drop incoming packets it intercepts if no Converter should not drop incoming packets it intercepts if no
matching entry is found for the packets. Unless explicitly matching entry is found for the packets. Unless explicitly
configured otherwise, such packets are forwarded according to the configured otherwise, such packets are forwarded according to the
instructions of a local forwarding table.</t> instructions of a local forwarding table.</t>
</section> </section>
<section anchor="sec-adds" numbered="true" toc="include" removeInRFC="fa
<section anchor="sec-adds" title="Address/Prefix Sharing"> lse" pn="section-4.4.2">
<t>A pool of global IPv4 addresses is provisioned to the Transport <name slugifiedName="name-address-prefix-sharing">Address/Prefix Shari
Converter along with possible instructions about the address sharing ng</name>
ratio to apply (see Appendix B of <xref target="RFC6269"></xref>). <t pn="section-4.4.2-1">A pool of global IPv4 addresses is provisioned
An address is thus shared among multiple clients.</t> to the Transport
Converter along with possible instructions about the address-sharing
<t>Likewise, rewriting the source IPv6 prefix <xref ratio to apply (see <xref target="RFC6269" sectionFormat="of" section=
target="RFC6296"></xref> may be used to ease redirection of incoming "B" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6269#appendix-B"
derivedContent="RFC6269"/>).
An address is thus shared among multiple Clients.</t>
<t pn="section-4.4.2-2">Likewise, rewriting the source IPv6 prefix <xr
ef target="RFC6296" format="default" sectionFormat="of" derivedContent="RFC6296"
/> may be used to ease redirection of incoming
IPv6 traffic towards the appropriate Transport Converter. A pool of IPv6 traffic towards the appropriate Transport Converter. A pool of
IPv6 prefixes is then provisioned to the Transport Converter for IPv6 prefixes is then provisioned to the Transport Converter for
this purpose.</t> this purpose.</t>
<t pn="section-4.4.2-3">Adequate forwarding policies are enforced so t
hat traffic
destined to an address of such a pool is intercepted by the
appropriate Transport Converter. Unlike <xref target="sec-addp" format
="default" sectionFormat="of" derivedContent="Section 4.4.1"/>, the Transport Co
nverter drops incoming packets
that do not match an active transport session entry.</t>
<t pn="section-4.4.2-4">An example is shown in <xref target="fig-adds"
format="default" sectionFormat="of" derivedContent="Figure 9"/>.</t>
<figure anchor="fig-adds" align="left" suppress-title="false" pn="figu
re-9">
<name slugifiedName="name-address-sharing">Address Sharing</name>
<artwork name="" type="" align="left" alt="" pn="section-4.4.2-5.1">
Transport
Client Converter Server
<t>Adequate forwarding policies are enforced so that traffic @:C @:Tc|Te @:S
destined to an address of such pool is intercepted by the | | |
appropriate Transport Converter. Unlike <xref |src:C dst:Tc|src:Te dst:S|
target="sec-addp"></xref>, the Transport Converter drops incoming |-------SYN [-&gt;S:port]-------&gt;|-------SYN-------&gt;|
packets which do not match an active transport session entry.</t> | | |
|dst:C src:Tc|dst:Te src:S|
<t>An example is shown in <xref target="fig-adds"></xref>.</t> |&lt;---------SYN/ACK------------|&lt;-----SYN/ACK-----|
| | |
<figure anchor="fig-adds" title="Address Sharing"> |src:C dst:Tc|src:Te dst:S|
<artwork><![CDATA[ |------------ACK-------------&gt;|-------ACK-------&gt;|
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: Legend:
Tc: IP address used by the Transport Converter on the internal Tc: IP address used by the Transport Converter on the internal
realm. realm.
Te: IP address used by the Transport Converter on the external Te: IP address used by the Transport Converter on the external
realm. realm.
]]></artwork> </artwork>
</figure> </figure>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sample-examples" numbered="true" toc="include" removeInRFC=
<section anchor="sample-examples" title="Sample Examples"> "false" pn="section-5">
<section anchor="outgoing-converter-assisted-multipath-tcp-connections" <name slugifiedName="name-sample-examples">Sample Examples</name>
title="Outgoing Converter-Assisted Multipath TCP Connections"> <section anchor="outgoing-converter-assisted-multipath-tcp-connections" nu
<t>As an example, let us consider how the Convert Protocol can help mbered="true" toc="include" removeInRFC="false" pn="section-5.1">
<name slugifiedName="name-outgoing-converter-assisted">Outgoing Converte
r-Assisted Multipath TCP Connections</name>
<t pn="section-5.1-1">As an example, let us consider how the Convert Pro
tocol can help
the deployment of Multipath TCP. We assume that both the Client and the deployment of Multipath TCP. We assume that both the Client and
the Transport Converter support Multipath TCP, but consider two the Transport Converter support Multipath TCP but consider two
different cases depending on whether the Server supports Multipath TCP different cases depending on whether or not the Server supports Multipat
or not.</t> h TCP.</t>
<t pn="section-5.1-2">As a reminder, a Multipath TCP connection is creat
<t>As a reminder, a Multipath TCP connection is created by placing the ed by placing the
MP_CAPABLE (MPC) option in the SYN sent by the Client.</t> MP_CAPABLE (MPC) option in the SYN sent by the Client.</t>
<t pn="section-5.1-3"><xref target="fig-mpestab" format="default" sectio
<t><xref target="fig-mpestab"></xref> describes the operation of the nFormat="of" derivedContent="Figure 10"/> describes the operation of the
Transport Converter if the Server does not support Multipath TCP.</t> Transport Converter if the Server does not support Multipath TCP.</t>
<figure anchor="fig-mpestab" align="left" suppress-title="false" pn="fig
<figure anchor="fig-mpestab" ure-10">
title="Establishment of a Multipath TCP Connection through a Tra <name slugifiedName="name-establishment-of-a-multipat">Establishment o
nsport Converter towards a Server that does not support Multipath TCP"> f a Multipath TCP Connection through a
<artwork><![CDATA[ Transport Converter towards a Server That Does Not support Multipath
TCP</name>
<artwork name="" type="" align="left" alt="" pn="section-5.1-4.1">
Transport Transport
Client Converter Server Client Converter Server
|SYN, MPC | | |SYN, MPC | |
|[->Server:port] | SYN, MPC | |[-&gt;Server:port] | SYN, MPC |
|------------------>|--------------------->| |------------------&gt;|---------------------&gt;|
|<------------------|<---------------------| |&lt;------------------|&lt;---------------------|
| SYN+ACK,MPC [.] | SYN+ACK | | SYN+ACK,MPC [.] | SYN+ACK |
|------------------>|---------------------&gt;| |------------------>|---------------------&gt;|
| ACK, MPC | ACK | | ACK, MPC | ACK |
| ... | ... | | ... | ... |
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-5.1-5">The Client tries to initiate a Multipath TCP conne
<t>The Client tries to initiate a Multipath TCP connection by sending ction by sending
a SYN with the MP_CAPABLE option (MPC in <xref a SYN with the MP_CAPABLE option (MPC in <xref target="fig-mpestab" form
target="fig-mpestab"></xref>). The SYN includes the address and port at="default" sectionFormat="of" derivedContent="Figure 10"/>). The SYN includes
the address and port
number of the target Server, that are extracted and used by the number of the target Server, that are extracted and used by the
Transport Converter to initiate a Multipath TCP connection towards Transport Converter to initiate a Multipath TCP connection towards
this Server. Since the Server does not support Multipath TCP, it this Server. Since the Server does not support Multipath TCP, it
replies with a SYN+ACK that does not contain the MP_CAPABLE option. replies with a SYN+ACK that does not contain the MP_CAPABLE option.
The Transport Converter notes that the connection with the Server does The Transport Converter notes that the connection with the Server does
not support Multipath TCP and returns the extended TCP header received not support Multipath TCP and returns the extended TCP header received
from the Server to the Client.</t> from the Server to the Client.</t>
<t pn="section-5.1-6">Note that, if the TCP connection is reset for some
<t>Note that, if the TCP connection is reset for some reason, the reason, the
Converter tears down the Multipath TCP connection by transmitting a Converter tears down the Multipath TCP connection by transmitting an
MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with the MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with the
transmission of DATA_FINs, the Converter terminates the TCP connection transmission of DATA_FINs, the Converter terminates the TCP connection
by using FIN segments. As a side note, given that with Multipath TCP, 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 RST only has the scope of the subflow and will only close the
concerned subflow but not affect the remaining subflows, the Converter concerned subflow but not affect the remaining subflows, the Converter
does not terminate the downstream TCP connection upon receipt of an does not terminate the downstream TCP connection upon receipt of an
RST over a Multipath subflow.</t> RST over a Multipath subflow.</t>
<t pn="section-5.1-7"><xref target="fig-mpestabok" format="default" sect
<t><xref target="fig-mpestabok"></xref> considers a Server that ionFormat="of" derivedContent="Figure 11"/> considers a Server that
supports Multipath TCP. In this case, it replies to the SYN sent by supports Multipath TCP. In this case, it replies to the SYN sent by
the Transport Converter with the MP_CAPABLE option. Upon reception of the Transport Converter with the MP_CAPABLE option. Upon reception of
this SYN+ACK, the Transport Converter confirms the establishment of this SYN+ACK, the Transport Converter confirms the establishment of
the connection to the Client and indicates to the Client that the the connection to the Client and indicates to the Client that the
Server supports Multipath TCP. With this information, the Client has Server supports Multipath TCP. With this information, the Client has
discovered that the Server supports Multipath TCP. This will enable discovered that the Server supports Multipath TCP. This will enable
the Client to bypass the Transport Converter for the subsequent the Client to bypass the Transport Converter for the subsequent
Multipath TCP connections that it will initiate towards this Multipath TCP connections that it will initiate towards this
Server.</t> Server.</t>
<figure anchor="fig-mpestabok" align="left" suppress-title="false" pn="f
<figure anchor="fig-mpestabok" igure-11">
title="Establishment of a Multipath TCP Connection through a Con <name slugifiedName="name-establishment-of-a-multipath">Establishment
verter towards an MPTCP-capable Server"> of a Multipath TCP Connection through a
<artwork><![CDATA[ Converter towards an MPTCP-Capable Server</name>
<artwork name="" type="" align="left" alt="" pn="section-5.1-8.1">
Transport Transport
Client Converter Server Client Converter Server
|SYN, MPC | | |SYN, MPC | |
|[->Server:port] | SYN, MPC | |[-&gt;Server:port] | SYN, MPC |
|------------------>|--------------------->| |------------------&gt;|---------------------&gt;|
|<------------------|<---------------------| |&lt;------------------|&lt;---------------------|
|SYN+ACK, MPC | SYN+ACK, MPC | |SYN+ACK, MPC | SYN+ACK, MPC |
|[MPC supported] | | |[MPC supported] | |
|------------------>|---------------------&gt;| |------------------>|---------------------&gt;|
| ACK, MPC | ACK, MPC | | ACK, MPC | ACK, MPC |
| ... | ... | | ... | ... |
]]></artwork> </artwork>
</figure> </figure>
</section> </section>
<section anchor="incoming-converter-assisted-multipath-tcp-connection" num
<section anchor="incoming-converter-assisted-multipath-tcp-connection" bered="true" toc="include" removeInRFC="false" pn="section-5.2">
title="Incoming Converter-Assisted Multipath TCP Connection"> <name slugifiedName="name-incoming-converter-assisted">Incoming Converte
<t>An example of an incoming Converter-assisted Multipath TCP r-Assisted Multipath TCP Connection</name>
connection is depicted in <xref target="fig-inestab"></xref>. In order <t pn="section-5.2-1">An example of an incoming Converter-assisted Multi
to support incoming connections from remote hosts, the Client may use path TCP
PCP <xref target="RFC6887"></xref> to instruct the Transport Converter connection is depicted in <xref target="fig-inestab" format="default" se
to create dynamic mappings. Those mappings will be used by the ctionFormat="of" derivedContent="Figure 12"/>. In order to support incoming conn
Transport Converter to intercept an incoming TCP connection destined ections from
to the Client and convert it into a Multipath TCP connection.</t> remote hosts, the Client may use the Port Control Protocol (PCP) <xref t
arget="RFC6887" format="default" sectionFormat="of" derivedContent="RFC6887"/> t
<t>Typically, the Client sends a PCP request to the Converter asking o instruct the Transport
to create an explicit TCP mapping for (internal IP address, internal Converter to create dynamic mappings. Those mappings will be used by
port number). The Converter accepts the request by creating a TCP the Transport Converter to intercept an incoming TCP connection
mapping (internal IP address, internal port number, external IP destined to the Client and convert it into a Multipath TCP
address, external port number). The external IP address, external port connection.</t>
number, and assigned lifetime are returned back the Client in the PCP <t pn="section-5.2-2">Typically, the Client sends a PCP request to the C
response. The external IP address and external port number will be onverter asking
then advertised by the Client (or the user) using an out-of-band to create an explicit TCP mapping for the internal IP address and
mechanism so that remote hosts can initiate TCP connections to the internal port number. The Converter accepts the request by creating a
Client via the Converter. Note that the external and internal TCP mapping for the internal IP address, internal port number,
information may be the same.</t> external IP address, and external port number. The external IP
address, external port number, and assigned lifetime are returned back
<t>Then, when the Converter receives an incoming SYN, it checks its to the Client in the PCP response. The external IP address and
external port number will 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 pn="section-5.2-3">Then, when the Converter receives an incoming SYN,
it checks its
mapping table to verify if there is an active mapping matching the mapping table to verify if there is an active mapping matching the
destination IP address and destination port of that SYN. If no entry destination IP address and destination port of that SYN. If no entry
is found, the Converter silently ignores the message. If an entry is is found, the Converter silently ignores the message. If an entry is
found, the Converter inserts an MP_CAPABLE option and Connect TLV in found, the Converter inserts an MP_CAPABLE option and Connect TLV in
the SYN packet, rewrites the source IP address to one of its IP the SYN packet, and rewrites the source IP address to one of its IP
addresses and, eventually, the destination IP address and port number addresses and, eventually, the destination IP address and port number
in accordance with the information stored in the mapping. SYN+ACK and in accordance with the information stored in the mapping. SYN+ACK and
ACK will be then exchanged between the Client and the Converter to ACK will then be exchanged between the Client and the Converter to
confirm the establishment of the initial subflow. The Client can add confirm the establishment of the initial subflow. The Client can add
new subflows following normal Multipath TCP procedures.</t> new subflows following normal Multipath TCP procedures.</t>
<figure anchor="fig-inestab" align="left" suppress-title="false" pn="fig
<figure anchor="fig-inestab" ure-12">
title="Establishment of an Incoming Multipath TCP Connection thr <name slugifiedName="name-establishment-of-an-incoming">Establishment
ough a Transport Converter"> of an Incoming Multipath TCP Connection through a Transport Converter</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-5.2-4.1">
Transport Remote Transport Remote
Client Converter Host Client Converter Host
| | | | | |
|<--------------------|&lt;-------------------| |<--------------------|&lt;-------------------|
|SYN, MPC | SYN | |SYN, MPC | SYN |
|[Remote Host:port] | | |[Remote Host:port] | |
|-------------------->|-------------------&gt;| |-------------------->|-------------------&gt;|
| SYN+ACK, MPC | SYN+ACK | | SYN+ACK, MPC | SYN+ACK |
|<--------------------|&lt;-------------------| |<--------------------|&lt;-------------------|
| ACK, MPC | ACK | | ACK, MPC | ACK |
| ... | ... | | ... | ... |
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-5.2-5">It is out of scope of this document to define spec
<t>It is out of scope of this document to define specific Convert TLVs ific Convert TLVs
to manage incoming connections (that is, TLVs that mimic PCP to manage incoming connections (that is, TLVs that mimic PCP
messages). These TLVs can be defined in a separate document.</t> messages). These TLVs can be defined in a separate document.</t>
</section> </section>
</section> </section>
<section anchor="sec-protocol" numbered="true" toc="include" removeInRFC="fa
<section anchor="sec-protocol" title="The Convert Protocol (Convert)"> lse" pn="section-6">
<t>This section defines the Convert Protocol (Convert, for short) <name slugifiedName="name-the-convert-protocol-conver">The Convert Protoco
l (Convert)</name>
<t pn="section-6-1">This section defines the Convert Protocol (Convert, fo
r short)
messages that are exchanged between a Client and a Transport messages that are exchanged between a Client and a Transport
Converter.</t> Converter.</t>
<t pn="section-6-2">The Transport Converter listens on a specific TCP port
<t>The Transport Converter listens on a specific TCP port number for number for
Convert messages from Clients. That port number is configured by an Convert messages from Clients. That port number is configured by an
administrator. Absent any policy, the Transport Converter SHOULD administrator. Absent any policy, the Transport Converter <bcp14>SHOULD</b cp14>
silently ignore SYNs with no Convert TLVs.</t> silently ignore SYNs with no Convert TLVs.</t>
<t pn="section-6-3">Convert messages may appear only in SYN, SYN+ACK, or A
<t>Convert messages may appear only in SYN, SYN+ACK, or ACK.</t> CK.</t>
<t pn="section-6-4">Convert messages <bcp14>MUST</bcp14> be included as th
<t>Convert messages MUST be included as the first bytes of the e first bytes
bytestream. All Convert messages starts with a 32 bits long fixed header of the bytestream. All Convert messages start with a fixed header that
(<xref target="sec-header"></xref>) followed by one or more Convert TLVs is 32 bits long (<xref target="sec-header" format="default" sectionFormat=
(Type, Length, Value) (<xref target="sec-tlv"></xref>).</t> "of" derivedContent="Section 6.1"/>) followed
by one or more Convert TLVs (Type, Length, Value) (<xref target="sec-tlv"
<t>If the initial SYN message contains user data in its payload (e.g., format="default" sectionFormat="of" derivedContent="Section 6.2"/>).</t>
<xref target="RFC7413"></xref>), that data MUST be placed right after <t pn="section-6-5">If the initial SYN message contains user data in its p
ayload (e.g., see
<xref target="RFC7413" format="default" sectionFormat="of" derivedContent=
"RFC7413"/>), that data <bcp14>MUST</bcp14> be placed right after
the Convert TLVs when generating the SYN.</t> the Convert TLVs when generating the SYN.</t>
<t pn="section-6-6">The protocol can be extended by defining new TLVs or b
<t>The protocol can be extended by defining new TLVs or bumping the umping the
version number if a different message format is needed. If a future version number if a different message format is needed. If a future
version is defined but with a different message format, the version version is defined but with a different message format, the version
negotiation procedure defined in <xref target="sec-error"></xref> (see negotiation procedure defined in <xref target="sec-error" format="default" sectionFormat="of" derivedContent="Section 6.2.8"/> (see
"Unsupported Version") is meant to agree on a version that is supported "Unsupported Version") is meant to agree on a version that is supported
by both peers.</t> by both peers.</t>
<aside pn="section-6-7">
<t><list style="symbols"> <t pn="section-6-7.1">Implementation note 1: Several implementers expres
<t>Implementation note 1: Several implementers expressed concerns sed concerns
about the use of TFO. As a reminder, the TFO Cookie protects from about the use of TFO. As a reminder, the Fast Open Cookie protects from
some attack scenarios that affect open servers like web servers. The some
Convert Protocol is different and, as discussed in RFC7413, there attack scenarios that affect open servers like web servers. The
are different ways to protect from such attacks. Instead of using a Convert Protocol is different and, as discussed in <xref target="RFC7413
TFO cookie inside the TCP options, which consumes precious space in " format="default" sectionFormat="of" derivedContent="RFC7413"/>, there are diff
the extended TCP header, the Convert Protocol supports the erent ways to protect from such
utilization of a Cookie that is placed in the SYN payload. This attacks. Instead of using a Fast Open Cookie inside the TCP options, whi
provides the same level of protection as a TFO Cookie in ch
environments were such protection is required.</t> consumes precious space in the extended TCP header, the Convert
Protocol supports the utilization of a Cookie that is placed in the
<t>Implementation note 2: Error messages are not included in RST but SYN payload. This provides the same level of protection as a Fast Open
Cookie in environments were such protection is required.</t>
<t pn="section-6-7.2">Implementation note 2: Error messages are not incl
uded in RST but
sent in the bytestream. Implementers have indicated that processing sent in the bytestream. Implementers have indicated that processing
RST on clients was difficult on some platforms. This design RST on Clients was difficult on some platforms. This design
simplifies client implementations.</t> simplifies Client implementations.</t>
</list></t> </aside>
<section anchor="sec-header" numbered="true" toc="include" removeInRFC="fa
<section anchor="sec-header" title="The Convert Fixed Header"> lse" pn="section-6.1">
<t>The Convert Protocol uses a 32 bits long fixed header that is sent <name slugifiedName="name-the-convert-fixed-header">The Convert Fixed He
ader</name>
<t pn="section-6.1-1">The Convert Protocol uses a fixed header that is 3
2 bits long sent
by both the Client and the Transport Converter over each established by both the Client and the Transport Converter over each established
connection. This header indicates both the version of the protocol connection. This header indicates both the version of the protocol
used and the length of the Convert message.</t> used and the length of the Convert message.</t>
<t pn="section-6.1-2">The Client and the Transport Converter <bcp14>MUST
<t>The Client and the Transport Converter MUST send the fixed-sized </bcp14> send the fixed-sized
header, shown in <xref target="fig-header"></xref>, as the first four header, shown in <xref target="fig-header" format="default" sectionForma
t="of" derivedContent="Figure 13"/>, as the first four
bytes of the bytestream.</t> bytes of the bytestream.</t>
<figure anchor="fig-header" align="left" suppress-title="false" pn="figu
<figure anchor="fig-header" title="The Convert Fixed Header"> re-13">
<artwork><![CDATA[ <name slugifiedName="name-the-convert-fixed-header-2">The Convert Fixe
d Header</name>
<artwork name="" type="" align="left" alt="" pn="section-6.1-3.1">
1 2 3 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 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 | | Version | Total Length | Magic Number |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-6.1-4">The version is encoded as an 8-bit unsigned intege
<t>The Version is encoded as an 8 bits unsigned integer value. This r value. This
document specifies version 1. Version 0 is reserved by this document document specifies version 1. Version 0 is reserved by this document
and MUST NOT be used.<list style="empty"> and <bcp14>MUST NOT</bcp14> be used.</t>
<t>Note: Early versions of this specification don't use a <aside pn="section-6.1-5">
<t pn="section-6.1-5.1">
Note: Early versions of this specification don't use a
dedicated port number but only rely upon the IP address of the dedicated port number but only rely upon the IP address of the
Converter. Having a bit set in the version field together with the Converter. Having a bit set in the Version field together with the
length field allows to avoid mis-interpreting a data in a SYN as Total Length field avoids misinterpreting data in a SYN as Convert
Convert TLVs. Since the design was updated to use a specific TLVs. Since the design was updated to use a specific
service port, that constraint was relaxed. Version 0 would work service port, that constraint was relaxed. Version 0 would work,
but given existing implementations already use Version 1, the use but given existing implementations already use Version 1, the use
of Version 0 is maintained as reserved.</t> of Version 0 is maintained as reserved.</t>
</list></t> </aside>
<t pn="section-6.1-6">The Total Length is the number of 32-bit words, in
<t>The Total Length is the number of 32 bits word, including the cluding the
header, of the bytestream that are consumed by the Convert messages. header, of the bytestream that are consumed by the Convert messages.
Since Total Length is also an 8 bits unsigned integer, those messages Since Total Length is also an 8-bit unsigned integer, those messages
cannot consume more than 1020 bytes of data. This limits the number of 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 bytes that a Transport Converter needs to process. A Total Length of
zero is invalid and the connection MUST be reset upon reception of a zero is invalid and the connection <bcp14>MUST</bcp14> be reset upon rec
header with such total length.</t> eption of a
header with such a total length.</t>
<t>The Magic Number field MUST be set to the RFC number to be assigned <t pn="section-6.1-7">The Magic Number field <bcp14>MUST</bcp14> be set
to this document. This field is meant to further strengthen the to 0x2263. This
protocol to unambiguously distinguish any data supplied by an field is meant to further strengthen the protocol to unambiguously
application from Convert TLVs. <list style="symbols"> distinguish any data supplied by an application from Convert TLVs. </t>
<t>Note to the RFC Editor: Please replace "the RFC number to be <t pn="section-6.1-8">The Total Length field unambiguously marks the num
assigned to this document" with the hex representation of the RFC ber of 32-bit
number assigned to this document.</t>
</list></t>
<t>The Total Length field unambiguously marks the number of 32 bits
words that carry Convert TLVs in the beginning of the bytestream.</t> words that carry Convert TLVs in the beginning of the bytestream.</t>
</section> </section>
<section anchor="sec-tlv" numbered="true" toc="include" removeInRFC="false
<section anchor="sec-tlv" title="Convert TLVs"> " pn="section-6.2">
<section anchor="generic-convert-tlv-format" <name slugifiedName="name-convert-tlvs">Convert TLVs</name>
title="Generic Convert TLV Format"> <section anchor="generic-convert-tlv-format" numbered="true" toc="includ
<t>The Convert Protocol uses variable length messages that are e" removeInRFC="false" pn="section-6.2.1">
encoded using the generic TLV format depicted in <xref <name slugifiedName="name-generic-convert-tlv-format">Generic Convert
target="fi-generictlv"></xref>.</t> TLV Format</name>
<t pn="section-6.2.1-1">The Convert Protocol uses variable length mess
<t>The length of all TLVs used by the Convert Protocol is always a ages that are
multiple of four bytes. All TLVs are aligned on 32 bits boundaries. encoded using the generic TLV format depicted in <xref target="fi-gene
rictlv" format="default" sectionFormat="of" derivedContent="Figure 14"/>.</t>
<t pn="section-6.2.1-2">The length of all TLVs used by the Convert Pro
tocol is always a
multiple of four bytes. All TLVs are aligned on 32-bit boundaries.
All TLV fields are encoded using the network byte order.</t> All TLV fields are encoded using the network byte order.</t>
<figure anchor="fi-generictlv" align="left" suppress-title="false" pn=
<figure anchor="fi-generictlv" title="Convert Generic TLV Format"> "figure-14">
<artwork><![CDATA[ <name slugifiedName="name-convert-generic-tlv-format">Convert Generi
c TLV Format</name>
<artwork name="" type="" align="left" alt="" pn="section-6.2.1-3.1">
1 2 3 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 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 ... | | Type | Length | Value ... |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
// ... (optional) Value // // ... (optional) Value //
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-6.2.1-4">The Length field covers Type, Length, and Valu
<t>The Length field covers Type, Length, and Value fields. It is e fields. It is
expressed in units of 32 bits words. If necessary, Value MUST be expressed in units of 32-bit words. If necessary, Value <bcp14>MUST</b
cp14> be
padded with zeroes so that the length of the TLV is a multiple of 32 padded with zeroes so that the length of the TLV is a multiple of 32
bits.</t> bits.</t>
<t pn="section-6.2.1-5">A given TLV <bcp14>MUST</bcp14> only appear on
<t>A given TLV MUST only appear once on a connection. If a Client ce on a connection. If a Client
receives two or more instances of the same TLV over a Convert receives two or more instances of the same TLV over a Convert
connection, it MUST reset the associated TCP connection. If a connection, it <bcp14>MUST</bcp14> reset the associated TCP connection . If a
Converter receives two or more instances of the same TLV over a Converter receives two or more instances of the same TLV over a
Convert connection, it MUST return a Malformed Message Error TLV and Convert connection, it <bcp14>MUST</bcp14> return a Malformed Message Error TLV and
close the associated TCP connection.</t> close the associated TCP connection.</t>
</section> </section>
<section anchor="summary-of-supported-convert-tlvs" numbered="true" toc=
<section anchor="summary-of-supported-convert-tlvs" "include" removeInRFC="false" pn="section-6.2.2">
title="Summary of Supported Convert TLVs"> <name slugifiedName="name-summary-of-supported-conver">Summary of Supp
<t>This document specifies the following Convert TLVs:</t> orted Convert TLVs</name>
<t pn="section-6.2.2-1">This document specifies the following Convert
<figure anchor="tab-converter-tlv" TLVs:</t>
title="The TLVs used by the Convert Protocol"> <table anchor="tab-converter-tlv" align="center" pn="table-1">
<artwork><![CDATA[ <name slugifiedName="name-the-tlvs-used-by-the-conver">The TLVs Used
+------+-----+----------+------------------------------------------+ by the Convert Protocol</name>
| Type | Hex | Length | Description | <thead>
+------+-----+----------+------------------------------------------+ <tr>
| 1 | 0x1 | 1 | Info TLV | <th align="left" colspan="1" rowspan="1">Type</th>
| 10 | 0xA | Variable | Connect TLV | <th align="left" colspan="1" rowspan="1">Hex</th>
| 20 | 0x14| Variable | Extended TCP Header TLV | <th align="left" colspan="1" rowspan="1">Length</th>
| 21 | 0x15| Variable | Supported TCP Extensions TLV | <th align="left" colspan="1" rowspan="1">Description</th>
| 22 | 0x16| Variable | Cookie TLV | </tr>
| 30 | 0x1E| Variable | Error TLV | </thead>
+------+-----+----------+------------------------------------------+ <tbody>
]]></artwork> <tr>
</figure> <td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">0x1</td>
<t>Type 0x0 is a reserved value. If a Client receives a TLV of type <td align="left" colspan="1" rowspan="1">1</td>
0x0, it MUST reset the associated TCP connection. If a Converter <td align="left" colspan="1" rowspan="1">Info TLV</td>
receives a TLV of type 0x0, it MUST return an Unsupported Message </tr>
<tr>
<td align="left" colspan="1" rowspan="1">10</td>
<td align="left" colspan="1" rowspan="1">0xA</td>
<td align="left" colspan="1" rowspan="1">Variable</td>
<td align="left" colspan="1" rowspan="1">Connect TLV</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">20</td>
<td align="left" colspan="1" rowspan="1">0x14</td>
<td align="left" colspan="1" rowspan="1">Variable</td>
<td align="left" colspan="1" rowspan="1">Extended TCP Header TLV
</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">21</td>
<td align="left" colspan="1" rowspan="1">0x15</td>
<td align="left" colspan="1" rowspan="1">Variable</td>
<td align="left" colspan="1" rowspan="1">Supported TCP Extension
s TLV</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">22</td>
<td align="left" colspan="1" rowspan="1">0x16</td>
<td align="left" colspan="1" rowspan="1">Variable</td>
<td align="left" colspan="1" rowspan="1">Cookie TLV</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">30</td>
<td align="left" colspan="1" rowspan="1">0x1E</td>
<td align="left" colspan="1" rowspan="1">Variable</td>
<td align="left" colspan="1" rowspan="1">Error TLV</td>
</tr>
</tbody>
</table>
<t pn="section-6.2.2-3">Type 0x0 is a reserved value. If a Client rece
ives a TLV of type
0x0, it <bcp14>MUST</bcp14> reset the associated TCP connection. If a
Converter
receives a TLV of type 0x0, it <bcp14>MUST</bcp14> return an Unsupport
ed Message
Error TLV and close the associated TCP connection.</t> Error TLV and close the associated TCP connection.</t>
<t pn="section-6.2.2-4">The Client typically sends, in the first conne
<t>The Client typically sends in the first connection it established ction it established
with a Transport Converter the Info TLV (<xref with a Transport Converter, the Info TLV (<xref target="sec-bootstrap-
target="sec-bootstrap-tlv"></xref>) to learn its capabilities. tlv" format="default" sectionFormat="of" derivedContent="Section 6.2.3"/>) to le
Assuming the Client is authorized to invoke the Transport Converter, arn its
the latter replies with the Supported TCP Extensions TLV (<xref capabilities. Assuming the Client is authorized to invoke the
target="sec-supported"></xref>).</t> Transport Converter, the latter replies with the Supported TCP
Extensions TLV (<xref target="sec-supported" format="default" sectionF
<t>The Client can request the establishment of connections to ormat="of" derivedContent="Section 6.2.4"/>).</t>
servers by using the Connect TLV (<xref <t pn="section-6.2.2-5">The Client can request the establishment of co
target="sec-connect"></xref>). If the connection can be established nnections to
with the final server, the Transport Converter replies with the Servers by using the Connect TLV (<xref target="sec-connect" format="d
Extended TCP Header TLV (<xref target="sec-ext-header"></xref>). If efault" sectionFormat="of" derivedContent="Section 6.2.5"/>). If the connection
not, the Transport Converter MUST return an Error TLV (<xref can be established with the
target="sec-error"></xref>) and then closes the connection. The final Server, the Transport Converter replies with the Extended TCP
Transport Converter MUST NOT send an RST immediately after the Header TLV (<xref target="sec-ext-header" format="default" sectionForm
detection of an error to let the Error TLV reach the Client. As at="of" derivedContent="Section 6.2.6"/>). If
explained later, the Client will anyway send an RST upon reception not, the Transport Converter <bcp14>MUST</bcp14> return an Error TLV
of the Error TLV.</t> (<xref target="sec-error" format="default" sectionFormat="of" derivedC
ontent="Section 6.2.8"/>) and then close the
connection. The Transport Converter <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 send an RST
regardless upon reception of the Error TLV.</t>
</section> </section>
<section anchor="sec-bootstrap-tlv" numbered="true" toc="include" remove
<section anchor="sec-bootstrap-tlv" title="The Info TLV"> InRFC="false" pn="section-6.2.3">
<t>The Info TLV (<xref target="fig-bootstrap"></xref>) is an <name slugifiedName="name-the-info-tlv">The Info TLV</name>
optional TLV which can be sent by a Client to request the TCP <t pn="section-6.2.3-1">The Info TLV (<xref target="fig-bootstrap" for
mat="default" sectionFormat="of" derivedContent="Figure 15"/>) is
an optional TLV that can be sent by a Client to request the TCP
extensions that are supported by a Transport Converter. It is extensions that are supported by a Transport Converter. It is
typically sent on the first connection that a Client establishes typically sent on the first connection that a Client establishes
with a Transport Converter to learn its capabilities. Assuming a with a Transport Converter to learn its capabilities. Assuming a
Client is entitled to invoke the Transport Converter, the latter Client is entitled to invoke the Transport Converter, the latter
replies with the Supported TCP Extensions TLV described in <xref replies with the Supported TCP Extensions TLV described in <xref targe
target="sec-supported"></xref>.</t> t="sec-supported" format="default" sectionFormat="of" derivedContent="Section 6.
2.4"/>.</t>
<figure anchor="fig-bootstrap" title="The Info TLV"> <figure anchor="fig-bootstrap" align="left" suppress-title="false" pn=
<artwork><![CDATA[ "figure-15">
<name slugifiedName="name-the-info-tlv-2">The Info TLV</name>
<artwork name="" type="" align="left" alt="" pn="section-6.2.3-2.1">
1 2 3 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 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 | | Type=0x1 | Length | Zero |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
]]></artwork> </artwork>
</figure> </figure>
</section> </section>
<section anchor="sec-supported" numbered="true" toc="include" removeInRF
<section anchor="sec-supported" title="Supported TCP Extensions TLV"> C="false" pn="section-6.2.4">
<t>The Supported TCP Extensions TLV (<xref <name slugifiedName="name-supported-tcp-extensions-tl">Supported TCP E
target="fig-supported"></xref>) is used by a Transport Converter to xtensions TLV</name>
announce the TCP options for which it provides a conversion service. <t pn="section-6.2.4-1">The Supported TCP Extensions TLV (<xref target
A Transport Converter SHOULD include in this list the TCP options ="fig-supported" format="default" sectionFormat="of" derivedContent="Figure 16"/
>) is used by a Transport Converter to announce the
TCP options for which it provides a conversion service. A Transport
Converter <bcp14>SHOULD</bcp14> include in this list the TCP options
that it supports in outgoing SYNs.</t> that it supports in outgoing SYNs.</t>
<t pn="section-6.2.4-2">Each supported TCP option is encoded with its
<t>Each supported TCP option is encoded with its TCP option Kind TCP option Kind
listed in the "TCP Parameters" registry maintained by IANA. The listed in the "Transmission Control Protocol (TCP) Parameters"
Unassigned field MUST be set to zero by the Transport Converter and registry maintained by IANA <xref target="IANA-CONVERT" format="defaul
t" sectionFormat="of" derivedContent="IANA-CONVERT"/>. The Unassigned field
<bcp14>MUST</bcp14> be set to zero by the Transport Converter and
ignored by the Client.</t> ignored by the Client.</t>
<figure anchor="fig-supported" align="left" suppress-title="false" pn=
<figure anchor="fig-supported" "figure-16">
title="The Supported TCP Extensions TLV"> <name slugifiedName="name-the-supported-tcp-extension">The Supported
<artwork><![CDATA[ TCP Extensions TLV</name>
<artwork name="" type="" align="left" alt="" pn="section-6.2.4-3.1">
1 2 3 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 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 | | Type=0x15 | Length | Unassigned |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Kind #1 | Kind #2 | ... | | Kind #1 | Kind #2 | ... |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
/ ... / / ... /
/ / / /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-6.2.4-4">TCP option Kinds 1 and 2 defined in <xref targ
<t>TCP option Kinds 1 and 2 defined in <xref et="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/> are
target="RFC0793"></xref> are supported by all TCP implementations supported by all TCP implementations and
and thus MUST NOT appear in this list.</t> thus, <bcp14>MUST NOT</bcp14> appear in this list.</t>
<t pn="section-6.2.4-5">The list of Supported TCP Extensions is padded
<t>The list of Supported TCP Extensions is padded with 0 to end on a with 0 to end on a
32 bits boundary.</t> 32-bit boundary.</t>
<t pn="section-6.2.4-6">For example, if the Transport Converter suppor
<t>For example, if the Transport Converter supports Multipath TCP, ts Multipath TCP,
Kind=30 will be present in the Supported TCP Extensions TLV that it Kind=30 will be present in the Supported TCP Extensions TLV that it
returns in response to Info TLV.</t> returns in response to the Info TLV.</t>
</section> </section>
<section anchor="sec-connect" numbered="true" toc="include" removeInRFC=
<section anchor="sec-connect" title="Connect TLV"> "false" pn="section-6.2.5">
<t>The Connect TLV (<xref target="fig-connect"></xref>) is used to <name slugifiedName="name-connect-tlv">Connect TLV</name>
<t pn="section-6.2.5-1">The Connect TLV (<xref target="fig-connect" fo
rmat="default" sectionFormat="of" derivedContent="Figure 17"/>) is used to
request the establishment of a connection via a Transport Converter. request the establishment of a connection via a Transport Converter.
This connection can be from or to a Client.</t> This connection can be from or to a Client.</t>
<t pn="section-6.2.5-2">The Remote Peer Port and Remote Peer IP Addres
<t>The 'Remote Peer Port' and 'Remote Peer IP Address' fields s fields
contain the destination port number and IP address of the Server, contain the destination port number and IP address of the Server,
for outgoing connections. For incoming connections destined to a for outgoing connections. For incoming connections destined to a
Client serviced via a Transport Converter, these fields convey the Client serviced via a Transport Converter, these fields convey the
source port number and IP address of the SYN packet received by the source port number and IP address of the SYN packet received by the
Transport Converter from the server.</t> Transport Converter from the Server.</t>
<t pn="section-6.2.5-3">The Remote Peer IP Address <bcp14>MUST</bcp14>
<t>The Remote Peer IP Address MUST be encoded as an IPv6 address. be encoded as an
IPv4 addresses MUST be encoded using the IPv4-Mapped IPv6 Address IPv6 address. IPv4 addresses <bcp14>MUST</bcp14> be encoded using
format defined in <xref target="RFC4291"></xref>. Further, Remote the IPv4-mapped IPv6 address format defined in <xref target="RFC4291"
Peer IP address field MUST NOT include multicast, broadcast, and format="default" sectionFormat="of" derivedContent="RFC4291"/>. Further, the Rem
host loopback addresses <xref target="RFC6890"></xref>. If a ote Peer IP
Converter receives a Connect TLVs with such invalid addresses, it Address field <bcp14>MUST NOT</bcp14> include multicast, broadcast,
MUST reply with a Malformed Message Error TLV and close the or host loopback addresses <xref target="RFC6890" format="default" sec
associated TCP connection.</t> tionFormat="of" derivedContent="RFC6890"/>. If a Converter receives a Connect TL
V with such
<t>We distinguish two types of Connect TLV based on their length: invalid addresses, it <bcp14>MUST</bcp14> reply with a Malformed
Message Error TLV and close the associated TCP connection.</t>
<t pn="section-6.2.5-4">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 (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 contains a remote address and a remote port (<xref target="fig-connect
target="fig-connect"></xref>), (2) the Extended Connect TLV spans " format="default" sectionFormat="of" derivedContent="Figure 17"/>), and (2) the
more than 20 bytes and also includes the optional 'TCP Options' Extended Connect TLV spans
field (<xref target="fig-econnect"></xref>). This field is used to more than 20 bytes and also includes the optional TCP Options
request the advertisement of specific TCP options to the server.</t> field (<xref target="fig-econnect" format="default" sectionFormat="of"
derivedContent="Figure 18"/>). This field is used to
<figure anchor="fig-connect" title="The Base Connect TLV"> request the advertisement of specific TCP options to the Server.</t>
<artwork><![CDATA[ <figure anchor="fig-connect" align="left" suppress-title="false" pn="f
igure-17">
<name slugifiedName="name-the-base-connect-tlv">The Base Connect TLV
</name>
<artwork name="" type="" align="left" alt="" pn="section-6.2.5-5.1">
1 2 3 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 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 | | Type=0xA | Length | Remote Peer Port |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| | | |
| Remote Peer IP Address (128 bits) | | Remote Peer IP Address (128 bits) |
| | | |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> </artwork>
</figure> </figure>
<figure anchor="fig-econnect" align="left" suppress-title="false" pn="
<figure anchor="fig-econnect" title="The Extended Connect TLV"> figure-18">
<artwork><![CDATA[ <name slugifiedName="name-the-extended-connect-tlv">The Extended Con
nect TLV</name>
<artwork name="" type="" align="left" alt="" pn="section-6.2.5-6.1">
1 2 3 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 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 | | Type=0xA | Length | Remote Peer Port |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| | | |
| Remote Peer IP Address (128 bits) | | Remote Peer IP Address (128 bits) |
| | | |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
/ TCP Options (Variable) / / TCP Options (Variable) /
/ ... / / ... /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-6.2.5-7">The TCP Options field is a variable length fie
<t>The 'TCP Options' field is a variable length field that carries a ld that carries a
list of TCP option fields (<xref target="fig-tcpopt"></xref>). Each list of TCP option fields (<xref target="fig-tcpopt" format="default"
TCP option field is encoded as a block of 2+n bytes where the first sectionFormat="of" derivedContent="Figure 19"/>). Each TCP option field is encod
byte is the TCP option Kind and the second byte is the length of the ed as a block of
TCP option as specified in <xref target="RFC0793"></xref>. The 2+n bytes where the first byte is the TCP option Kind and the second
minimum value for the TCP option Length is 2. The TCP options that byte is the length of the TCP option as specified in <xref target="RFC
do not include a length sub-field, i.e., option types 0 (EOL) and 1 0793" format="default" sectionFormat="of" derivedContent="RFC0793"/>. The minimu
(NOP) defined in <xref target="RFC0793"></xref> MUST NOT be placed m value for the TCP
inside the TCP options field of the Connect TLV. The optional Value option Length is 2. The TCP options that do not include a length
field contains the variable-length part of the TCP option. A length sub-field, i.e., option types 0 (EOL) and 1 (NOP) defined in <xref tar
of two indicates the absence of the Value field. The TCP options get="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/> <bc
field always ends on a 32 bits boundary after being padded with p14>MUST NOT</bcp14> be
zeros.</t> placed inside the TCP options field of the Connect TLV. The optional
Value field contains the variable-length part of the TCP option. A
<figure anchor="fig-tcpopt" title="The TCP Options Field"> length of 2 indicates the absence of the Value field. The TCP
<artwork><![CDATA[ options field always ends on a 32-bit boundary after being padded
with zeros.</t>
<figure anchor="fig-tcpopt" align="left" suppress-title="false" pn="fi
gure-19">
<name slugifiedName="name-the-tcp-options-field">The TCP Options Fie
ld</name>
<artwork name="" type="" align="left" alt="" pn="section-6.2.5-8.1">
1 2 3 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 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) | .... | | TCPOpt kind | TCPOpt Length | Value (opt) | .... |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| .... | | .... |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| ... | | ... |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-6.2.5-9">Upon reception of a Base Connect TLV, and abse
<t>Upon reception of a Base Connect TLV, and absent any policy nt any policy
(e.g., rate-limit) or resource exhaustion conditions, a Transport (e.g., rate-limit) or resource exhaustion conditions, a Transport
Converter attempts to establish a connection to the address and port Converter attempts to establish a connection to the address and port
that it contains. The Transport Converter MUST use by default the that it contains. The Transport Converter <bcp14>MUST</bcp14> use by d efault the
TCP options that correspond to its local policy to establish this TCP options that correspond to its local policy to establish this
connection. </t> connection. </t>
<t pn="section-6.2.5-10">Upon reception of an Extended Connect TLV, a
<t>Upon reception of an Extended Connect TLV, a Transport Converter Transport Converter
first checks whether it supports the TCP Options listed in the 'TCP first checks whether or not it supports the TCP Options listed in the
Options' field. If not, it returns an error TLV set to "Unsupported TCP
TCP Option" (<xref target="sec-error"></xref>). If the above check Options field. If not, it returns an error TLV set to "Unsupported
succeeded and absent any rate limit policy or resource exhaustion TCP Option" (<xref target="sec-error" format="default" sectionFormat="
conditions, a Transport Converter MUST attempt to establish a of" derivedContent="Section 6.2.8"/>). If the above check
connection to the address and port that it contains. It MUST include succeeded, and absent any rate-limit policy or resource exhaustion
conditions, a Transport Converter <bcp14>MUST</bcp14> attempt to estab
lish a
connection to the address and port that it contains. It <bcp14>MUST</b
cp14> include
in the SYN that it sends to the Server the options listed in the in the SYN that it sends to the Server the options listed in the
'TCP Options' sub-field and the TCP options that it would have used TCP Options subfield and the TCP options that it would have used
according to its local policies. For the TCP options that are according to its local policies. For the TCP options that are
included in the TCP Options field without an optional value, the included in the TCP Options field without an optional value, the
Transport Converter MUST generate its own value. For the TCP options Transport Converter <bcp14>MUST</bcp14> generate its own value. For th
that are included in the 'TCP Options' field with an optional value, e TCP options
it MUST copy the entire option in the SYN sent to the remote server. that are included in the TCP Options field with an optional value,
it <bcp14>MUST</bcp14> copy the entire option in the SYN sent to the r
emote Server.
This procedure is designed with TFO in mind. Particularly, this This procedure is designed with TFO in mind. Particularly, this
procedure allows to successfully exchange a TFO Cookie between the procedure allows to successfully exchange a Fast Open Cookie between t
client and the server. See <xref target="sec-tcpoptions"></xref> for he
Client and the Server. See <xref target="sec-tcpoptions" format="defau
lt" sectionFormat="of" derivedContent="Section 7"/> for
a detailed discussion of the different types of TCP options.</t> a detailed discussion of the different types of TCP options.</t>
<t pn="section-6.2.5-11">The Transport Converter may refuse a Connect
<t>The Transport Converter may refuse a Connect TLV request for TLV request for
various reasons (e.g., authorization failed, out of resources, various reasons (e.g., authorization failed, out of resources,
invalid address type, unsupported TCP option). An error message invalid address type, or unsupported TCP option). An error message
indicating the encountered error is returned to the requesting indicating the encountered error is returned to the requesting
Client (<xref target="sec-error"></xref>). In order to prevent Client (<xref target="sec-error" format="default" sectionFormat="of" d
denial-of-service attacks, error messages sent to a Client SHOULD be erivedContent="Section 6.2.8"/>). In order to prevent
denial-of-service attacks, error messages sent to a Client <bcp14>SHOU
LD</bcp14> be
rate-limited.</t> rate-limited.</t>
</section> </section>
<section anchor="sec-ext-header" numbered="true" toc="include" removeInR
<section anchor="sec-ext-header" title="Extended TCP Header TLV"> FC="false" pn="section-6.2.6">
<t>The Extended TCP Header TLV (<xref <name slugifiedName="name-extended-tcp-header-tlv">Extended TCP Header
target="fig-tcpheader"></xref>) is used by the Transport Converter TLV</name>
to return to the Client the TCP options that were returned by the <t pn="section-6.2.6-1">The Extended TCP Header TLV (<xref target="fig
Server in the SYN+ACK packet. A Transport Converter MUST return this -tcpheader" format="default" sectionFormat="of" derivedContent="Figure 20"/>) is
TLV if the Client sent an Extended Connect TLV and the connection used by the Transport Converter to return to
was accepted by the server. </t> the Client the TCP options that were returned by the Server in the
SYN+ACK packet. A Transport Converter <bcp14>MUST</bcp14> return
<figure anchor="fig-tcpheader" title="The Extended TCP Header TLV"> this TLV if the Client sent an Extended Connect TLV and the
<artwork><![CDATA[ connection was accepted by the Server. </t>
<figure anchor="fig-tcpheader" align="left" suppress-title="false" pn=
"figure-20">
<name slugifiedName="name-the-extended-tcp-header-tlv">The Extended
TCP Header TLV</name>
<artwork name="" type="" align="left" alt="" pn="section-6.2.6-2.1">
1 2 3 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 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 | | Type=0x14 | Length | Unassigned |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
/ Returned Extended TCP header / / Returned Extended TCP header /
/ ... / / ... /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-6.2.6-3">The Returned Extended TCP header field is a co
<t>The Returned Extended TCP header field is a copy of the TCP py of the TCP
Options that were included in the SYN+ACK received by the Transport Options that were included in the SYN+ACK received by the Transport
Converter.</t> Converter.</t>
<t pn="section-6.2.6-4">The Unassigned field <bcp14>MUST</bcp14> be se
<t>The Unassigned field MUST be set to zero by the sender and t to zero by the sender and
ignored by the receiver.</t> ignored by the receiver.</t>
</section> </section>
<section anchor="sec-cookie-tlv" numbered="true" toc="include" removeInR
<section anchor="sec-cookie-tlv" title="The Cookie TLV"> FC="false" pn="section-6.2.7">
<t>The Cookie TLV (<xref target="fig-cookie"></xref>) is an optional <name slugifiedName="name-the-cookie-tlv">The Cookie TLV</name>
TLV which is similar to the TCP Fast Open Cookie <xref <t pn="section-6.2.7-1">The Cookie TLV (<xref target="fig-cookie" form
target="RFC7413"></xref>. A Transport Converter may want to verify at="default" sectionFormat="of" derivedContent="Figure 21"/>) is
that a Client can receive the packets that it sends to prevent an optional TLV that is similar to the TCP Fast Open Cookie <xref targ
attacks from spoofed addresses. This verification can be done by et="RFC7413" format="default" sectionFormat="of" derivedContent="RFC7413"/>. A T
using a Cookie that is bound to, for example, the IP address(es) of ransport Converter may want
the Client. This Cookie can be configured on the Client by means to verify that a Client can receive the packets that it sends to
that are outside of this document or provided by the Transport prevent attacks from spoofed addresses. This verification can be
Converter.</t> 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
<t>A Transport Converter that has been configured to use the Client by means that are outside of this document or provided by the
optional Cookie TLV MUST verify the presence of this TLV in the Transport Converter.</t>
payload of the received SYN. If this TLV is present, the Transport <t pn="section-6.2.7-2">A Transport Converter that has been configured
Converter MUST validate the Cookie by means similar to those in to use the
Section 4.1.2 of <xref target="RFC7413"></xref> (i.e., optional Cookie TLV <bcp14>MUST</bcp14> verify the presence of this
IsCookieValid). If the Cookie is valid, the connection establishment TLV in the payload of the received SYN. If this TLV is present, the
procedure can continue. Otherwise, the Transport Converter MUST Transport Converter <bcp14>MUST</bcp14> validate the Cookie by means
return an Error TLV set to "Not Authorized" and close the similar to those in <xref target="RFC7413" sectionFormat="of" section=
connection.</t> "4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7413#section
-4.1.2" derivedContent="RFC7413"/> (i.e., IsCookieValid). If the Cookie is valid
<t>If the received SYN did not contain a Cookie TLV, and cookie , the
validation is required, the Transport Converter MAY compute a Cookie connection establishment procedure can continue. Otherwise, the
Transport Converter <bcp14>MUST</bcp14> return an Error TLV set to
"Not Authorized" and close the connection.</t>
<t pn="section-6.2.7-3">If the received SYN did not contain a Cookie T
LV, and cookie
validation is required, the Transport Converter <bcp14>MAY</bcp14> com
pute a Cookie
bound to this Client address. In such case, the Transport Converter bound to this Client address. In such case, the Transport Converter
MUST return an Error TLV set to "Missing Cookie" and the computed <bcp14>MUST</bcp14> return an Error TLV set to "Missing Cookie" and th e computed
Cookie and close the connection. The Client will react to this error Cookie and close the connection. The Client will react to this error
by first issuing a reset to terminate the connection. It also stores by first issuing a reset to terminate the connection. It also stores
the received Cookie in its cache and attempts to reestablish a new the received Cookie in its cache and attempts to reestablish a new
connection to the Transport Converter that includes the Cookie connection to the Transport Converter that includes the Cookie
TLV.</t> TLV.</t>
<t pn="section-6.2.7-4">The format of the Cookie TLV is shown in <xref
<t>The format of the Cookie TLV is shown in <xref target="fig-cookie" format="default" sectionFormat="of" derivedContent="Figure
target="fig-cookie"></xref>.</t> 21"/>.</t>
<figure anchor="fig-cookie" align="left" suppress-title="false" pn="fi
<figure anchor="fig-cookie" title="The Cookie TLV"> gure-21">
<artwork><![CDATA[ <name slugifiedName="name-the-cookie-tlv-2">The Cookie TLV</name>
<artwork name="" type="" align="left" alt="" pn="section-6.2.7-5.1">
1 2 3 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 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 | | Type=0x16 | Length | Zero |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
/ Opaque Cookie / / Opaque Cookie /
/ ... / / ... /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> </artwork>
</figure> </figure>
</section> </section>
<section anchor="sec-error" numbered="true" toc="include" removeInRFC="f
<section anchor="sec-error" title="Error TLV"> alse" pn="section-6.2.8">
<t>The Error TLV (<xref target="fig-error"></xref>) is meant to <name slugifiedName="name-error-tlv">Error TLV</name>
<t pn="section-6.2.8-1">The Error TLV (<xref target="fig-error" format
="default" sectionFormat="of" derivedContent="Figure 22"/>) is meant to
provide information about some errors that occurred during the provide information about some errors that occurred during the
processing of a Convert message. This TLV has a variable length. processing of a Convert message. This TLV has a variable length.
Upon reception of an Error TLV, a Client MUST reset the associated Upon reception of an Error TLV, a Client <bcp14>MUST</bcp14> reset the associated
connection.</t> connection.</t>
<t pn="section-6.2.8-2">An Error TLV can be included in the SYN+ACK or
<t>An Error TLV can be included in the SYN+ACK or an ACK.</t> an ACK.</t>
<figure anchor="fig-error" align="left" suppress-title="false" pn="fig
<figure anchor="fig-error" title="The Error TLV"> ure-22">
<artwork><![CDATA[ <name slugifiedName="name-the-error-tlv">The Error TLV</name>
<artwork name="" type="" align="left" alt="" pn="section-6.2.8-3.1">
1 2 3 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 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 | | Type=0x1E | Length | Error Code | Value |
+---------------+---------------+----------------+--------------+ +---------------+---------------+----------------+--------------+
// ... (optional) Value // // ... (optional) Value //
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-6.2.8-4">Different types of errors can occur while proc
<t>Different types of errors can occur while processing Convert essing Convert
messages. Each error is identified by an Error Code represented as messages. Each error is identified by an Error Code represented as
an unsigned integer. Four classes of error codes are defined:</t> an unsigned integer. Four classes of error codes are defined:</t>
<dl newline="true" spacing="normal" pn="section-6.2.8-5">
<t><list style="symbols"> <dt pn="section-6.2.8-5.1">Message validation and processing errors
<t>Message validation and processing errors (0-31 range): (0-31 range):</dt>
returned upon reception of an invalid message (including valid <dd pn="section-6.2.8-5.2">Returned upon reception of an invalid mes
messages but with invalid or unknown TLVs).</t> sage (including valid
messages but with invalid or unknown TLVs).</dd>
<t>Client-side errors (32-63 range): the Client sent a request <dt pn="section-6.2.8-5.3">Client-side errors (32-63 range):</dt>
<dd pn="section-6.2.8-5.4">The Client sent a request
that could not be accepted by the Transport Converter (e.g., that could not be accepted by the Transport Converter (e.g.,
unsupported operation).</t> unsupported operation).</dd>
<dt pn="section-6.2.8-5.5">Converter-side errors (64-95 range):</dt>
<t>Converter-side errors (64-95 range): problems encountered on <dd pn="section-6.2.8-5.6"> Problems encountered on
the Transport Converter (e.g., lack of resources) which prevent the Transport Converter (e.g., lack of resources) that prevent
it from fulfilling the Client's request.</t> it from fulfilling the Client's request.</dd>
<dt pn="section-6.2.8-5.7">Errors caused by the destination Server (
<t>Errors caused by the destination server (96-127 range): the 96-127 range):</dt>
<dd pn="section-6.2.8-5.8">The
final destination could not be reached or it replied with a final destination could not be reached or it replied with a
reset.</t> reset.</dd>
</list></t> </dl>
<t pn="section-6.2.8-6">The following error codes are defined in this
<t>The following error codes are defined in this document:</t> document:</t>
<dl spacing="normal" newline="true" pn="section-6.2.8-7">
<t><list style="symbols"> <dt pn="section-6.2.8-7.1">Unsupported Version (0):</dt>
<t>Unsupported Version (0): The version number indicated in the <dd pn="section-6.2.8-7.2">
<t pn="section-6.2.8-7.2.1">The version number indicated in the
fixed header of a message received from a peer is not supported. fixed header of a message received from a peer is not supported.
<vspace blankLines="1" /> This error code MUST be generated by a </t>
peer (e.g. Transport Converter) when it receives a request <t pn="section-6.2.8-7.2.2"> This error code <bcp14>MUST</bcp14> b
having a version number that it does not support. <vspace e generated by a
blankLines="1" /> The value field MUST be set to the version peer (e.g., Transport Converter) when it receives a request
having a version number that it does not support. </t>
<t pn="section-6.2.8-7.2.3"> The Value field <bcp14>MUST</bcp14> b
e set to the version
supported by the peer. When multiple versions are supported by supported by the peer. When multiple versions are supported by
the peer, it includes the list of supported version in the value the peer, it includes the list of supported versions in the Value
field; each version is encoded in 8 bits. The list of supported field; each version is encoded in 8 bits. The list of supported
versions MUST be padded with zeros to end on a 32 bits boundary. versions <bcp14>MUST</bcp14> be padded with zeros to end on a 32-b
<vspace blankLines="1" /> Upon receipt of this error code, the it boundary.
</t>
<t pn="section-6.2.8-7.2.4"> Upon receipt of this error code, the
remote peer (e.g., Client) checks whether it supports one of the remote peer (e.g., Client) checks whether it supports one of the
versions returned by the peer. The highest common supported versions returned by the peer.
version MUST be used by the remote peer in subsequent exchanges
with the peer.</t>
<t>Malformed Message (1): This error code is sent to indicate The highest commonly supported version number <bcp14>MUST</bcp14> be used by the
that a message received from a peer cannot be successfully remote
parsed and validated. <vspace blankLines="1" /> Typically, this peer in subsequent exchanges with the peer.</t>
error code is sent by the Transport Converter if it receives a </dd>
Connect TLV enclosing a multicast, broadcast, or loopback IP <dt pn="section-6.2.8-7.3">Malformed Message (1):</dt>
address. <vspace blankLines="1" /> To ease troubleshooting, the <dd pn="section-6.2.8-7.4">
value field MUST echo the received message using the format <t pn="section-6.2.8-7.4.1">This error code is sent to
depicted in <xref target="shift"></xref>. This format allows to indicate that a message received from a peer cannot be
keep the original alignment of the message that triggered the successfully parsed and validated. </t>
error. <figure anchor="shift" <t pn="section-6.2.8-7.4.2"> Typically, this error code is sent by
title="Error TLV to ease Message Correlation"> the Transport
<artwork><![CDATA[ Converter if it receives a Connect TLV enclosing a multicast,
broadcast, or loopback IP address. </t>
<t pn="section-6.2.8-7.4.3"> To ease troubleshooting, the Value fi
eld <bcp14>MUST</bcp14>
echo the received message using the format depicted in <xref targe
t="shift" format="default" sectionFormat="of" derivedContent="Figure 23"/>. This
format allows keeping
the original alignment of the message that triggered the
error. </t>
<figure anchor="shift" align="left" suppress-title="false" pn="fig
ure-23">
<name slugifiedName="name-error-tlv-to-ease-message-c">Error TLV
to Ease Message Correlation</name>
<artwork name="" type="" align="left" alt="" pn="section-6.2.8-7
.4.4.1">
1 2 3 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 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 | | Type=0x1E | Length | Error Code | Zeros |
+---------------+---------------+----------------+--------------+ +---------------+---------------+----------------+--------------+
// Echo the message which triggered the error // // Echo the message that triggered the error //
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> </artwork>
</figure></t> </figure>
</dd>
<t>Unsupported Message (2): This error code is sent to indicate <dt pn="section-6.2.8-7.5">Unsupported Message (2):</dt>
that a message type received from a Client is not supported. <dd pn="section-6.2.8-7.6">
<vspace blankLines="1" /> To ease troubleshooting, the value <t pn="section-6.2.8-7.6.1">This error code is sent to indicate
field MUST echo the received message using the format shown in that a message type received from a Client is not supported.</t>
<xref target="shift"></xref>.</t> <t pn="section-6.2.8-7.6.2"> To ease troubleshooting, the Value fi
eld <bcp14>MUST</bcp14>
<t>Missing Cookie (3): If a Transport Converter requires the echo the received message using the format shown in <xref target="
shift" format="default" sectionFormat="of" derivedContent="Figure 23"/>.</t>
</dd>
<dt pn="section-6.2.8-7.7">Missing Cookie (3):</dt>
<dd pn="section-6.2.8-7.8">
<t pn="section-6.2.8-7.8.1">If a Transport Converter requires the
utilization of Cookies to prevent spoofing attacks and a Cookie utilization of Cookies to prevent spoofing attacks and a Cookie
TLV was not included in the Convert message, the Transport TLV was not included in the Convert message, the Transport
Converter MUST return this error to the requesting client only Converter <bcp14>MUST</bcp14> return this error to the requesting
if it computes a cookie for this client. The first byte of the Client only
value field MUST be set to zero and the remaining bytes of the if it computes a cookie for this Client. The first byte of the
Value field <bcp14>MUST</bcp14> be set to zero and the remaining b
ytes of the
Error TLV contain the Cookie computed by the Transport Converter Error TLV contain the Cookie computed by the Transport Converter
for this Client. <vspace blankLines="1" /> A Client which for this Client. </t>
receives this error code SHOULD cache the received Cookie and <t pn="section-6.2.8-7.8.2"> A Client that receives this error cod
include it in subsequent Convert messages sent to that Transport e
<bcp14>SHOULD</bcp14> cache the received Cookie and include it
in subsequent Convert messages sent to that Transport
Converter.</t> Converter.</t>
</dd>
<t>Not Authorized (32): This error code indicates that the <dt pn="section-6.2.8-7.9">Not Authorized (32):</dt>
<dd pn="section-6.2.8-7.10">
<t pn="section-6.2.8-7.10.1">This error code indicates that the
Transport Converter refused to create a connection because of a Transport Converter refused to create a connection because of a
lack of authorization (e.g., administratively prohibited, lack of authorization (e.g., administratively prohibited,
authorization failure, invalid Cookie TLV). The Value field MUST authorization failure, or invalid Cookie TLV). The Value field <bc
be set to zero. <vspace blankLines="1" /> This error code MUST p14>MUST</bcp14>
be set to zero. </t>
<t pn="section-6.2.8-7.10.2"> This error code <bcp14>MUST</bcp14>
be sent by the Transport Converter when a request cannot be be sent by the Transport Converter when a request cannot be
successfully processed because the authorization failed.</t> successfully processed because the authorization failed.</t>
</dd>
<t>Unsupported TCP Option (33): A TCP option that the Client <dt pn="section-6.2.8-7.11">Unsupported TCP Option (33):</dt>
<dd pn="section-6.2.8-7.12">
<t pn="section-6.2.8-7.12.1">A TCP option that the Client
requested to advertise to the final Server cannot be safely requested to advertise to the final Server cannot be safely
used. <vspace blankLines="1" /> The Value field is set to the used. </t>
<t pn="section-6.2.8-7.12.2"> The Value field is set to the
type of the unsupported TCP option. If several unsupported TCP type of the unsupported TCP option. If several unsupported TCP
options were specified in the Connect TLV, then the list of options were specified in the Connect TLV, then the list of
unsupported TCP options is returned. The list of unsupported TCP unsupported TCP options is returned. The list of unsupported TCP
options MUST be padded with zeros to end on a 32 bits options <bcp14>MUST</bcp14> be padded with zeros to end on a 32-bi t
boundary.</t> boundary.</t>
</dd>
<t>Resource Exceeded (64): This error indicates that the <dt pn="section-6.2.8-7.13">Resource Exceeded (64):</dt>
<dd pn="section-6.2.8-7.14">
<t pn="section-6.2.8-7.14.1">This error indicates that the
Transport Converter does not have enough resources to perform Transport Converter does not have enough resources to perform
the request. <vspace blankLines="1" /> This error MUST be sent the request. </t>
<t pn="section-6.2.8-7.14.2"> This error <bcp14>MUST</bcp14> be se
nt
by the Transport Converter when it does not have sufficient by the Transport Converter when it does not have sufficient
resources to handle a new connection. The Transport Converter resources to handle a new connection. The Transport Converter
may indicate in the Value field the suggested delay (in seconds) may indicate in the Value field the suggested delay (in seconds)
that the Client SHOULD wait before soliciting the Transport that the Client <bcp14>SHOULD</bcp14> wait before soliciting the T ransport
Converter for a new proxied connection. A Value of zero Converter for a new proxied connection. A Value of zero
corresponds to a default delay of at least 30 seconds.</t> corresponds to a default delay of at least 30 seconds.</t>
</dd>
<t>Network Failure (65): This error indicates that the Transport <dt pn="section-6.2.8-7.15">Network Failure (65):</dt>
<dd pn="section-6.2.8-7.16">
<t pn="section-6.2.8-7.16.1">This error indicates that the Transpo
rt
Converter is experiencing a network failure to proxy the Converter is experiencing a network failure to proxy the
request. <vspace blankLines="1" /> The Transport Converter MUST request. </t>
<t pn="section-6.2.8-7.16.2"> The Transport Converter <bcp14>MUST<
/bcp14>
send this error code when it experiences forwarding issues to send this error code when it experiences forwarding issues to
proxy a connection. The Transport Converter may indicate in the proxy a connection. The Transport Converter may indicate in the
Value field the suggested delay (in seconds) that the Client Value field the suggested delay (in seconds) that the Client
SHOULD wait before soliciting the Transport Converter for a new <bcp14>SHOULD</bcp14> wait before soliciting the Transport Convert er for a new
proxied connection. A Value of zero corresponds to a default proxied connection. A Value of zero corresponds to a default
delay of at least 30 seconds.</t> delay of at least 30 seconds.</t>
</dd>
<t>Connection Reset (96): This error indicates that the final <dt pn="section-6.2.8-7.17">Connection Reset (96):</dt>
destination responded with an RST segment. The Value field MUST <dd pn="section-6.2.8-7.18">This error indicates that the final
be set to zero.</t> destination responded with an RST segment. The Value field <bcp14>
MUST</bcp14>
<t>Destination Unreachable (97): This error indicates that an be set to zero.</dd>
<dt pn="section-6.2.8-7.19">Destination Unreachable (97):</dt>
<dd pn="section-6.2.8-7.20">
<t pn="section-6.2.8-7.20.1">This error indicates that an
ICMP message indicating a hard error (e.g., destination ICMP message indicating a hard error (e.g., destination
unreachable, port unreachable, or network unreachable) was unreachable, port unreachable, or network unreachable) was
received by the Transport Converter. The Value field MUST echo received by the Transport Converter. The Value field <bcp14>MUST</
the Code field of the received ICMP message. <vspace bcp14> echo
blankLines="1" />As a reminder, TCP implementations are supposed the Code field of the received ICMP message. </t>
<t pn="section-6.2.8-7.20.2">As a reminder, TCP implementations ar
e supposed
to act on an ICMP error message passed up from the IP layer, to act on an ICMP error message passed up from the IP layer,
directing it to the connection that triggered the error using directing it to the connection that triggered the error using
the demultiplexing information included in the payload of that the demultiplexing information included in the payload of that
ICMP message. Such demultiplexing issue does not apply for ICMP message. Such a demultiplexing issue does not apply for
handling the "Destination Unreachable" Error TLV because the handling the "Destination Unreachable" Error TLV because the
error is sent in-band. For this reason, the payload of the ICMP error is sent in-band. For this reason, the payload of the ICMP
message is not echoed in the Destination Unreachable Error message is not echoed in the Destination Unreachable Error
TLV.</t> TLV.</t>
</list></t> </dd>
</dl>
<t><xref target="tab-error-types"></xref> summarizes the different <t pn="section-6.2.8-8"><xref target="tab-error-types" format="default
" sectionFormat="of" derivedContent="Table 2"/> summarizes the different
error codes.</t> error codes.</t>
<table anchor="tab-error-types" align="center" pn="table-2">
<figure anchor="tab-error-types" title="Convert Error Values"> <name slugifiedName="name-convert-error-values">Convert Error Values
<artwork><![CDATA[ </name>
+-------+------+-----------------------------------------------+ <thead>
| Error | Hex | Description | <tr>
+-------+------+-----------------------------------------------+ <th align="left" colspan="1" rowspan="1">Error</th>
| 0 | 0x00 | Unsupported Version | <th align="left" colspan="1" rowspan="1">Hex</th>
| 1 | 0x01 | Malformed Message | <th align="left" colspan="1" rowspan="1">Description</th>
| 2 | 0x02 | Unsupported Message | </tr>
| 3 | 0x03 | Missing Cookie | </thead>
| 32 | 0x20 | Not Authorized | <tbody>
| 33 | 0x21 | Unsupported TCP Option | <tr>
| 64 | 0x40 | Resource Exceeded | <td align="left" colspan="1" rowspan="1">0</td>
| 65 | 0x41 | Network Failure | <td align="left" colspan="1" rowspan="1">0x00</td>
| 96 | 0x60 | Connection Reset | <td align="left" colspan="1" rowspan="1">Unsupported Version</td
| 97 | 0x61 | Destination Unreachable | >
+-------+------+-----------------------------------------------+ </tr>
]]></artwork> <tr>
</figure> <td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">0x01</td>
<td align="left" colspan="1" rowspan="1">Malformed Message</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">0x02</td>
<td align="left" colspan="1" rowspan="1">Unsupported Message</td
>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">0x03</td>
<td align="left" colspan="1" rowspan="1">Missing Cookie</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">32</td>
<td align="left" colspan="1" rowspan="1">0x20</td>
<td align="left" colspan="1" rowspan="1">Not Authorized</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">33</td>
<td align="left" colspan="1" rowspan="1">0x21</td>
<td align="left" colspan="1" rowspan="1">Unsupported TCP Option<
/td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">64</td>
<td align="left" colspan="1" rowspan="1">0x40</td>
<td align="left" colspan="1" rowspan="1">Resource Exceeded</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">65</td>
<td align="left" colspan="1" rowspan="1">0x41</td>
<td align="left" colspan="1" rowspan="1">Network Failure</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">96</td>
<td align="left" colspan="1" rowspan="1">0x60</td>
<td align="left" colspan="1" rowspan="1">Connection Reset</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">97</td>
<td align="left" colspan="1" rowspan="1">0x61</td>
<td align="left" colspan="1" rowspan="1">Destination Unreachable
</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec-tcpoptions" numbered="true" toc="include" removeInRFC="
<section anchor="sec-tcpoptions" false" pn="section-7">
title="Compatibility of Specific TCP Options with the Conversion Se <name slugifiedName="name-compatibility-of-specific-t">Compatibility of Sp
rvice"> ecific TCP Options with the Conversion Service</name>
<t>In this section, we discuss how several deployed standard track TCP <t pn="section-7-1">In this section, we discuss how several deployed Stand
ards Track TCP
options can be supported through the Convert Protocol. The other TCP options can be supported through the Convert Protocol. The other TCP
options will be discussed in other documents.</t> options will be discussed in other documents.</t>
<section anchor="base-tcp-options" numbered="true" toc="include" removeInR
<section anchor="base-tcp-options" title="Base TCP Options"> FC="false" pn="section-7.1">
<t>Three TCP options were initially defined in <xref <name slugifiedName="name-base-tcp-options">Base TCP Options</name>
target="RFC0793"></xref>: End-of-Option List (Kind=0), No-Operation <t pn="section-7.1-1">Three TCP options were initially defined in <xref
(Kind=1) and Maximum Segment Size (Kind=2). The first two options are target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/>:
mainly used to pad the TCP header. There is no reason for a client to End-of-Option List (Kind=0), No-Operation (Kind=1),
request a Transport Converter to specifically send these options and Maximum Segment Size (Kind=2). The first two options are mainly
towards the final destination.</t> used to pad the TCP header. There is no reason for a Client to request
a Transport Converter to specifically send these options towards the
<t>The Maximum Segment Size option (Kind=2) is used by a host to final destination.</t>
<t pn="section-7.1-2">The Maximum Segment Size option (Kind=2) is used b
y a host to
indicate the largest segment that it can receive over each connection. indicate the largest segment that it can receive over each connection.
This value is function of the stack that terminates the TCP This value is a function of the stack that terminates the TCP
connection. There is no reason for a Client to request a Transport connection. There is no reason for a Client to request a Transport
Converter to advertise a specific MSS value to a remote server.</t> Converter to advertise a specific Maximum Segment Size (MSS) value to a
remote Server.</t>
<t>A Transport Converter MUST ignore options with Kind=0, 1 or 2 if <t pn="section-7.1-3">A Transport Converter <bcp14>MUST</bcp14> ignore o
they appear in a Connect TLV. It MUST NOT announce them in a Supported ptions with Kind=0, 1, or 2 if
they appear in a Connect TLV. It <bcp14>MUST NOT</bcp14> announce them i
n a Supported
TCP Extensions TLV.</t> TCP Extensions TLV.</t>
</section> </section>
<section anchor="window-scale-ws" numbered="true" toc="include" removeInRF
<section anchor="window-scale-ws" title="Window Scale (WS)"> C="false" pn="section-7.2">
<t>The Window Scale (WS) option (Kind=3) is defined in <xref <name slugifiedName="name-window-scale-ws">Window Scale (WS)</name>
target="RFC7323"></xref>. As for the MSS option, the window scale <t pn="section-7.2-1">The Window Scale (WS) option (Kind=3) is defined i
factor that is used for a connection strongly depends on the TCP stack n <xref target="RFC7323" format="default" sectionFormat="of" derivedContent="RFC
that handles the connection. When a Transport Converter opens a TCP 7323"/>. As for the MSS option, the window
connection towards a remote server on behalf of a Client, it SHOULD scale factor that is used for a connection strongly depends on the TCP
use a WS option with a scaling factor that corresponds to the stack that handles the connection. When a Transport Converter opens a
configuration of its stack. A local configuration MAY allow for WS TCP connection towards a remote Server on behalf of a Client, it
option in the proxied message to be function of the scaling factor of <bcp14>SHOULD</bcp14> use a WS option with a scaling factor that
the incoming connection.</t> corresponds to the configuration of its stack. A local configuration
<bcp14>MAY</bcp14> allow for a WS option in the proxied message to be
<t>There is no benefit from a deployment viewpoint in enabling a a function of the scaling factor of the incoming connection.</t>
<t pn="section-7.2-2">From a deployment viewpoint, there is no benefit i
n enabling a
Client of a Transport Converter to specifically request the Client of a Transport Converter to specifically request the
utilization of the WS option (Kind=3) with a specific scaling factor utilization of the WS option (Kind=3) with a specific scaling factor
towards a remote Server. For this reason, a Transport Converter MUST towards a remote Server. For this reason, a Transport Converter <bcp14>M
ignore option Kind=3 if it appears in a Connect TLV. It MUST NOT UST</bcp14>
announce it in a Supported TCP Extensions TLV.</t> ignore option Kind=3 if it appears in a Connect TLV.
</section>
<section anchor="selective-acknowledgments" The Transport Converter <bcp14>MUST NOT</bcp14> announce a WS option (Kind=3)
title="Selective Acknowledgments"> in a Supported TCP Extensions TLV.
<t>Two distinct TCP options were defined to support selective </t>
acknowledgments in <xref target="RFC2018"></xref>. This first one, </section>
SACK Permitted (Kind=4), is used to negotiate the utilization of <section anchor="selective-acknowledgments" numbered="true" toc="include"
selective acknowledgments during the three-way handshake. The second removeInRFC="false" pn="section-7.3">
one, SACK (Kind=5), carries the selective acknowledgments inside <name slugifiedName="name-selective-acknowledgments">Selective Acknowled
gments</name>
<t pn="section-7.3-1">Two distinct TCP options were defined to support S
elective
Acknowledgment (SACK) in <xref target="RFC2018" format="default" section
Format="of" derivedContent="RFC2018"/>. This first one,
SACK-Permitted (Kind=4), is used to negotiate the utilization of
Selective Acknowledgments during the three-way handshake. The second
one, SACK (Kind=5), carries the Selective Acknowledgments inside
regular segments.</t> regular segments.</t>
<t pn="section-7.3-2">The SACK-Permitted option (Kind=4) <bcp14>MAY</bcp
<t>The SACK Permitted option (Kind=4) MAY be advertised by a Transport 14> be advertised by a Transport
Converter in the Supported TCP Extensions TLV. Clients connected to Converter in the Supported TCP Extensions TLV. Clients connected to
this Transport Converter MAY include the SACK Permitted option in the this Transport Converter <bcp14>MAY</bcp14> include the SACK-Permitted o ption in the
Connect TLV.</t> Connect TLV.</t>
<t pn="section-7.3-3">The SACK option (Kind=5) cannot be used during the
<t>The SACK option (Kind=5) cannot be used during the three-way three-way
handshake. For this reason, a Transport Converter MUST ignore option handshake. For this reason, a Transport Converter <bcp14>MUST</bcp14> ig
Kind=5 if it appears in a Connect TLV. It MUST NOT announce it in a nore option
Kind=5 if it appears in a Connect TLV. It <bcp14>MUST NOT</bcp14> announ
ce it in a
TCP Supported Extensions TLV.</t> TCP Supported Extensions TLV.</t>
</section> </section>
<section anchor="timestamp" numbered="true" toc="include" removeInRFC="fal
<section anchor="timestamp" title="Timestamp"> se" pn="section-7.4">
<t>The Timestamp option <xref target="RFC7323"></xref> can be used <name slugifiedName="name-timestamp">Timestamp</name>
<t pn="section-7.4-1">The Timestamp option <xref target="RFC7323" format
="default" sectionFormat="of" derivedContent="RFC7323"/> can be used
during the three-way handshake to negotiate the utilization of during the three-way handshake to negotiate the utilization of
timestamps during the TCP connection. It is notably used to improve timestamps during the TCP connection. It is notably used to improve
round-trip-time estimations and to provide protection against wrapped round-trip-time estimations and to provide Protection Against Wrapped
sequence numbers (PAWS). As for the WS option, the timestamps are a Sequences (PAWS). As for the WS option, the timestamps are a
property of a connection and there is limited benefit in enabling a property of a connection and there is limited benefit in enabling a
client to request a Transport Converter to use the timestamp option Client to request a Transport Converter to use the timestamp option
when establishing a connection to a remote server. Furthermore, the when establishing a connection to a remote Server. Furthermore, the
timestamps that are used by TCP stacks are specific to each stack and timestamps that are used by TCP stacks are specific to each stack and
there is no benefit in enabling a client to specify the timestamp there is no benefit in enabling a Client to specify the timestamp
value that a Transport Converter could use to establish a connection value that a Transport Converter could use to establish a connection
to a remote server.</t> to a remote Server.</t>
<t pn="section-7.4-2">A Transport Converter <bcp14>MAY</bcp14> advertise
<t>A Transport Converter MAY advertise the Timestamp option (Kind=8) the Timestamp option (Kind=8)
in the TCP Supported Extensions TLV. The clients connected to this in the TCP Supported Extensions TLV. The Clients connected to this
Transport Converter MAY include the Timestamp option in the Connect Transport Converter <bcp14>MAY</bcp14> include the Timestamp option in t
he Connect
TLV but without any timestamp.</t> TLV but without any timestamp.</t>
</section> </section>
<section anchor="multipath-tcp" numbered="true" toc="include" removeInRFC=
<section anchor="multipath-tcp" title="Multipath TCP"> "false" pn="section-7.5">
<t>The Multipath TCP options are defined in <xref <name slugifiedName="name-multipath-tcp">Multipath TCP</name>
target="RFC6824"></xref>. <xref target="RFC6824"></xref> defines one <t pn="section-7.5-1">The Multipath TCP options are defined in <xref tar
get="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/>, wh
ich defines one
variable length TCP option (Kind=30) that includes a sub-type field to variable length TCP option (Kind=30) that includes a sub-type field to
support several Multipath TCP options. There are several operational support several Multipath TCP options. There are several operational
use cases where clients would like to use Multipath TCP through a use cases where Clients would like to use Multipath TCP through a
Transport Converter <xref target="IETFJ16"></xref>. However, none of Transport Converter <xref target="IETFJ16" format="default" sectionForma
t="of" derivedContent="IETFJ16"/>. However, none of
these use cases require the Client to specify the content of the these use cases require the Client to specify the content of the
Multipath TCP option that the Transport Converter should send to a Multipath TCP option that the Transport Converter should send to a
remote server.</t> remote Server.</t>
<t pn="section-7.5-2">A Transport Converter that supports Multipath TCP
<t>A Transport Converter which supports Multipath TCP conversion conversion
service MUST advertise the Multipath TCP option (Kind=30) in the service <bcp14>MUST</bcp14> advertise the Multipath TCP option (Kind=30)
in the
Supported TCP Extensions TLV. Clients serviced by this Transport Supported TCP Extensions TLV. Clients serviced by this Transport
Converter may include the Multipath TCP option in the Connect TLV but Converter may include the Multipath TCP option in the Connect TLV but
without any content.</t> without any content.</t>
</section> </section>
<section anchor="tcp-fast-open" numbered="true" toc="include" removeInRFC=
<section anchor="tcp-fast-open" title="TCP Fast Open"> "false" pn="section-7.6">
<t>The TCP Fast Open cookie option (Kind=34) is defined in <xref <name slugifiedName="name-tcp-fast-open">TCP Fast Open</name>
target="RFC7413"></xref>. There are two different usages of this <t pn="section-7.6-1">The TCP Fast Open Cookie option (Kind=34) is defin
ed in <xref target="RFC7413" format="default" sectionFormat="of" derivedContent=
"RFC7413"/>. There are two different usages of this
option that need to be supported by Transport Converters. The first option that need to be supported by Transport Converters. The first
utilization of the TCP Fast Open cookie option is to request a cookie utilization of the TCP Fast Open Cookie option is to request a cookie
from the server. In this case, the option is sent with an empty cookie from the Server. In this case, the option is sent with an empty cookie
by the client and the server returns the cookie. The second by the Client, and the Server returns the cookie. The second
utilization of the TCP Fast Open cookie option is to send a cookie to utilization of the TCP Fast Open Cookie option is to send a cookie to
the server. In this case, the option contains a cookie.</t> the Server. In this case, the option contains a cookie.</t>
<t pn="section-7.6-2">A Transport Converter <bcp14>MAY</bcp14> advertise
<t>A Transport Converter MAY advertise the TCP Fast Open cookie option the TCP Fast Open Cookie option
(Kind=34) in the Supported TCP Extensions TLV. If a Transport (Kind=34) in the Supported TCP Extensions TLV. If a Transport
Converter has advertised the support for TCP Fast Open in its Converter has advertised the support for TCP Fast Open in its
Supported TCP Extensions TLV, it needs to be able to process two types Supported TCP Extensions TLV, it needs to be able to process two types
of Connect TLV.</t> of Connect TLV.</t>
<t pn="section-7.6-3">If such a Transport Converter receives a Connect T
<t>If such a Transport Converter receives a Connect TLV with the TCP LV with the TCP
Fast Open cookie option that does not contain a cookie, it MUST add an Fast Open Cookie option that does not contain a cookie, it
empty TCP Fast Open cookie option in the SYN sent to the remote <bcp14>MUST</bcp14> add an empty TCP Fast Open Cookie option in the
server. If the remote server supports TFO, it responds with a SYN-ACK SYN sent to the remote Server. If the remote Server supports TFO, it
according to the procedure in Section 4.1.2 of <xref responds with a SYN-ACK according to the procedure in <xref target="RFC7
target="RFC7413"></xref>. This SYN-ACK may contain a Fast Open option 413" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rf
with a cookie. Upon receipt of the SYN-ACK by the Converter, it relays c-editor.org/rfc/rfc7413#section-4.1.2" derivedContent="RFC7413"/>. This SYN-ACK
Fast Open option with the cookie to the Client.</t> 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
<t>If such a Transport Converter receives a Connect TLV with the TCP to the Client.</t>
Fast Open cookie option that contains a cookie, it MUST copy the TCP <t pn="section-7.6-4">If such a Transport Converter receives a Connect T
Fast Open cookie option in the SYN sent to the remote server.</t> LV with the TCP
Fast Open Cookie option that contains a cookie, it <bcp14>MUST</bcp14> c
opy the TCP
Fast Open Cookie option in the SYN sent to the remote Server.</t>
</section> </section>
<section anchor="tcp-ao" numbered="true" toc="include" removeInRFC="false"
<section anchor="tcp-ao" title="TCP-AO"> pn="section-7.7">
<t>TCP-AO <xref target="RFC5925"></xref> provides a technique to <name slugifiedName="name-tcp-ao">TCP-AO</name>
authenticate all the packets exchanged over a TCP connection. Given <t pn="section-7.7-1">The TCP Authentication Option (TCP-AO) <xref targe
the nature of this extension, it is unlikely that the applications t="RFC5925" format="default" sectionFormat="of" derivedContent="RFC5925"/> provi
that require their packets to be authenticated end-to-end would want des a technique to authenticate all the
their connections to pass through a converter. For this reason, we do packets exchanged over a TCP connection. Given the nature of this
not recommend the support of the TCP-AO option by Transport extension, it is unlikely that the applications that require their
Converters. The only use cases where it could make sense to combine packets to be authenticated end to end would want their connections to
TCP-AO and the solution in this document are those where the pass through a converter. For this reason, we do not recommend the
TCP-AO-NAT extension <xref target="RFC6978"></xref> is in use.</t> support of the TCP-AO by Transport Converters. The only use
cases where it could make sense to combine TCP-AO and the solution in
<t>A Transport Converter MUST NOT advertise the TCP-AO option this document are those where the TCP-AO-NAT extension <xref target="RFC
6978" format="default" sectionFormat="of" derivedContent="RFC6978"/> is in use.<
/t>
<t pn="section-7.7-2">A Transport Converter <bcp14>MUST NOT</bcp14> adve
rtise the TCP-AO
(Kind=29) in the Supported TCP Extensions TLV. If a Transport (Kind=29) in the Supported TCP Extensions TLV. If a Transport
Converter receives a Connect TLV that contains the TCP-AO option, it Converter receives a Connect TLV that contains the TCP-AO, it
MUST reject the establishment of the connection with error code set to <bcp14>MUST</bcp14> reject the establishment of the connection with
"Unsupported TCP Option", except if the TCP-AO-NAT option is used. error code set to "Unsupported TCP Option", except if the TCP-AO-NAT
Nevertheless, given that TCP-AO-NAT is Experimental, its usage is not option is used. Nevertheless, given that TCP-AO-NAT is Experimental,
currently defined and must be specified by some other document before its usage is not currently defined and must be specified by some other
it can be used.</t> document before it can be used.</t>
</section> </section>
</section> </section>
<section anchor="sec-middleboxes" numbered="true" toc="include" removeInRFC=
<section anchor="sec-middleboxes" title="Interactions with Middleboxes"> "false" pn="section-8">
<t>The Convert Protocol is designed to be used in networks that do not <name slugifiedName="name-interactions-with-middlebox">Interactions with M
iddleboxes</name>
<t pn="section-8-1">The Convert Protocol is designed to be used in network
s that do not
contain middleboxes that interfere with TCP. Under such conditions, it contain middleboxes that interfere with TCP. Under such conditions, it
is assumed that the network provider ensures that all involved on-path is assumed that the network provider ensures that all involved on-path
nodes are not breaking TCP signals (e.g., strip TCP options, discard nodes are not breaking TCP signals (e.g., strip TCP options, discard
some SYNs, etc.).</t> some SYNs, etc.).</t>
<t pn="section-8-2">Nevertheless, and in order to allow for a robust servi
<t>Nevertheless, and in order to allow for a robust service, this ce, this
section describes how a Client can detect middlebox interference and section describes how a Client can detect middlebox interference and
stop using the Transport Converter affected by this interference.</t> stop using the Transport Converter affected by this interference.</t>
<t pn="section-8-3">Internet measurements <xref target="IMC11" format="def
<t>Internet measurements <xref target="IMC11"></xref> have shown that ault" sectionFormat="of" derivedContent="IMC11"/> have shown that
middleboxes can affect the deployment of TCP extensions. In this middleboxes can affect the deployment of TCP extensions. In this
section, we focus the middleboxes that modify the payload since the section, we focus the middleboxes that modify the payload since the
Convert Protocol places its messages at the beginning of the Convert Protocol places its messages at the beginning of the
bytestream.</t> bytestream.</t>
<t pn="section-8-4">Consider a middlebox that removes the SYN payload. The
<t>Consider a middlebox that removes the SYN payload. The Client can Client can
detect this problem by looking at the acknowledgment number field of the detect this problem by looking at the acknowledgment number field of the
SYN+ACK if returned by the Transport Converter. The Client MUST stop to SYN+ACK if returned by the Transport Converter. The Client <bcp14>MUST</bc p14> stop to
use this Transport Converter given the middlebox interference.</t> use this Transport Converter given the middlebox interference.</t>
<t pn="section-8-5">Consider now a middlebox that drops SYN/ACKs with a pa
<t>Consider now a middlebox that drops SYN/ACKs with a payload. The yload. The
Client won't be able to establish a connection via the Transport 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 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) 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 can be detected by a Client. This is hinted by the absence of a valid
Convert message in the response.</t> Convert message in the response.</t>
<t pn="section-8-6">As explained in <xref target="RFC7413" format="default
<t>As explained in <xref target="RFC7413"></xref>, some CGNs (Carrier " sectionFormat="of" derivedContent="RFC7413"/>, some
Grade NATs) can affect the operation of TFO if they assign different IP Carrier Grade NATs (CGNs) can affect the operation of TFO if they assign
addresses to the same end host. Such CGNs could affect the operation of different IP addresses to the same end host. Such CGNs could affect the
the cookie validation used by the Convert Protocol. As a reminder CGNs, operation of the cookie validation used by the Convert Protocol. As a
enabled on the path between a Client and a Transport Converter, must reminder, CGNs that are enabled on the path between a Client and a Transpo
adhere to the address preservation defined in <xref rt
target="RFC6888"></xref>. See also the discussion in Section 7.1 of Converter must adhere to the address preservation defined in <xref target=
<xref target="RFC7413"></xref>.</t> "RFC6888" format="default" sectionFormat="of" derivedContent="RFC6888"/>. See al
so the discussion in <xref target="RFC7413" sectionFormat="of" section="7.1" for
mat="default" derivedLink="https://rfc-editor.org/rfc/rfc7413#section-7.1" deriv
edContent="RFC7413"/>.</t>
</section> </section>
<section anchor="sec-security" numbered="true" toc="include" removeInRFC="fa
<section anchor="sec-security" title="Security Considerations"> lse" pn="section-9">
<t>An implementation MUST check that the Convert TLVs are properly <name slugifiedName="name-security-considerations">Security Considerations
</name>
<t pn="section-9-1">An implementation <bcp14>MUST</bcp14> check that the C
onvert TLVs are properly
framed within the boundary indicated by the Total Length in the fixed framed within the boundary indicated by the Total Length in the fixed
header (<xref target="sec-header"></xref>).</t> header (<xref target="sec-header" format="default" sectionFormat="of" deri
vedContent="Section 6.1"/>).</t>
<t>Additional security considerations are discussed in the following <t pn="section-9-2">Additional security considerations are discussed in th
sub-sections.</t> e following
subsections.</t>
<section anchor="privacy-ingress-filtering" <section anchor="privacy-ingress-filtering" numbered="true" toc="include"
title="Privacy &amp; Ingress Filtering"> removeInRFC="false" pn="section-9.1">
<t>The Transport Converter may have access to privacy-related <name slugifiedName="name-privacy-ingress-filtering">Privacy &amp; Ingre
ss Filtering</name>
<t pn="section-9.1-1">The Transport Converter may have access to privacy
-related
information (e.g., subscriber credentials). The Transport Converter is information (e.g., subscriber credentials). The Transport Converter is
designed to not leak such sensitive information outside a local designed to not leak such sensitive information outside a local
domain.</t> domain.</t>
<t pn="section-9.1-2">Given its function and location in the network, a
<t>Given its function and location in the network, a Transport Transport
Converter is in a position to observe all packets that it processes, Converter is in a position to observe all packets that it processes,
to include payloads and meta-data; and has the ability to profile and to include payloads and metadata, and has the ability to profile and
conduct some traffic analysis of user behavior. The Transport conduct some traffic analysis of user behavior. The Transport
Converter MUST be as protected as a core IP router (e.g., Section 10 Converter <bcp14>MUST</bcp14> be as protected as a core IP router
of <xref target="RFC1812"></xref>).</t> (e.g., <xref target="RFC1812" sectionFormat="of" section="10" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc1812#section-10" derivedConten
<t>Furthermore, ingress filtering policies MUST be enforced at the t="RFC1812"/>).</t>
network boundaries <xref target="RFC2827"></xref>.</t> <t pn="section-9.1-3">Furthermore, ingress filtering policies <bcp14>MUS
T</bcp14> be enforced at the
<t>This document assumes that all network attachments are managed by network boundaries <xref target="RFC2827" format="default" sectionFormat
="of" derivedContent="RFC2827"/>.</t>
<t pn="section-9.1-4">This document assumes that all network attachments
are managed by
the same administrative entity. Therefore, enforcing anti-spoofing the same administrative entity. Therefore, enforcing anti-spoofing
filters at these network is a guard that hosts are not sending traffic filters at these networks is a guard that hosts are not sending traffic
with spoofed source IP addresses.</t> with spoofed source IP addresses.</t>
</section> </section>
<section anchor="authorization" numbered="true" toc="include" removeInRFC=
<section anchor="authorization" "false" pn="section-9.2">
title="Authentication and Authorization Considerations"> <name slugifiedName="name-authentication-and-authoriz">Authentication an
<t>The Convert Protocol is RECOMMENDED to be used in a managed network d Authorization Considerations</name>
<t pn="section-9.2-1">The Convert Protocol is <bcp14>RECOMMENDED</bcp14>
for use in a managed network
where end hosts can be securely identified by their IP address. If where end hosts can be securely identified by their IP address. If
such control is not exerted and there is a more open network such control is not exerted and there is a more open network
environment, a strong mutual authentication scheme MUST be defined to environment, a strong mutual authentication scheme <bcp14>MUST</bcp14> b e defined to
use the Convert Protocol.</t> use the Convert Protocol.</t>
<t pn="section-9.2-2">One possibility for mutual authentication is to us
<t>One possibility for mutual authentication is to use TLS to perform e TLS to perform
mutual authentication between the client and the Converter. That is, mutual authentication between the Client and the Converter. That is,
use TLS when a Client retrieves a Cookie from the Converter and rely use TLS when a Client retrieves a Cookie from the Converter and rely
on certificate-based client authentication, pre-shared key based <xref on certificate-based, pre-shared key-based <xref target="RFC4279" format
target="RFC4279"></xref> or raw public key based client authentication ="default" sectionFormat="of" derivedContent="RFC4279"/>, or raw public key-base
<xref target="RFC7250"></xref> to secure this connection. If the d Client
authentication succeeds, the Converter returns a cookie to the Client. authentication <xref target="RFC7250" format="default" sectionFormat="of
Subsequent Connect messages will be authorized as a function of the " derivedContent="RFC7250"/> to secure
content of the Cookie TLV. An attacker from within the network between this connection. If the authentication succeeds, the Converter returns
a Client and a Transport Converter may intercept the Cookie and use it a cookie to the Client. Subsequent Connect messages will be
to be granted access to the conversion service. Such attack is only authorized as a function of the content of the Cookie TLV. An attacker
possible if the attacker spoofs the IP address of the Client and the from within the network between a Client and a Transport Converter may
network does not filter packets with source spoofed IP addresses. </t> 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
<t>The operator that manages the various network attachments address of the Client and the network does not filter packets with
source-spoofed IP addresses. </t>
<t pn="section-9.2-3">The operator that manages the various network atta
chments
(including the Transport Converters) has various options for enforcing (including the Transport Converters) has various options for enforcing
authentication and authorization policies. For example, a authentication and authorization policies. For example, a
non-exhaustive list of methods to achieve authorization is provided non-exhaustive list of methods to achieve authorization is provided
hereafter:</t> hereafter:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-9.2-4">
<t><list style="symbols"> <li pn="section-9.2-4.1">The network provider may enforce a policy bas
<t>The network provider may enforce a policy based on the ed on the
International Mobile Subscriber Identity (IMSI) to verify that a International Mobile Subscriber Identity (IMSI) to verify that a
user is allowed to benefit from the TCP converter service. If that user is allowed to benefit from the TCP converter service. If that
authorization fails, the Packet Data Protocol (PDP) context/bearer authorization fails, the Packet Data Protocol (PDP) context/bearer
will not be mounted. This method does not require any interaction will not be mounted. This method does not require any interaction
with the Transport Converter for authorization matters.</t> with the Transport Converter for authorization matters.</li>
<li pn="section-9.2-4.2">The network provider may enforce a policy bas
<t>The network provider may enforce a policy based upon Access ed upon Access
Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG) Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG)
to control the hosts that are authorized to communicate with a to control the hosts that are authorized to communicate with a
Transport Converter. These ACLs may be installed as a result of Transport Converter. These ACLs may be installed as a result of
RADIUS exchanges, e.g., <xref RADIUS exchanges, e.g., <xref target="I-D.boucadair-opsawg-tcpm-conv
target="I-D.boucadair-radext-tcpm-converter"></xref>. This method erter" format="default" sectionFormat="of" derivedContent="TCPM-CONVERTER"/>. Th
is method
does not require any interaction with the Transport Converter for does not require any interaction with the Transport Converter for
authorization matters.</t> authorization matters.</li>
<li pn="section-9.2-4.3">A device that embeds a Transport Converter ma
<t>A device that embeds a Transport Converter may also host a y also host a
RADIUS client that will solicit an AAA server to check whether RADIUS Client that will solicit a AAA Server to check whether or
connections received from a given source IP address are authorized not connections received from a given source IP address are
or not <xref authorized <xref target="I-D.boucadair-opsawg-tcpm-converter" format="
target="I-D.boucadair-radext-tcpm-converter"></xref>.</t> default" sectionFormat="of" derivedContent="TCPM-CONVERTER"/>.</li>
</list></t> </ul>
<t pn="section-9.2-5">A first safeguard against the misuse of Transport
<t>A first safeguard against the misuse of Transport Converter Converter
resources by illegitimate users (e.g., users with access networks that resources by illegitimate users (e.g., users with access networks that
are not managed by the same provider that operates the Transport are not managed by the same provider that operates the Transport
Converter) is the Transport Converter to reject Convert connections Converter) is the Transport Converter to reject Convert connections
received in the external realm. Only Convert connections received in received in the external realm. Only Convert connections received in
the internal realm of a Transport Converter will be accepted.</t> the internal realm of a Transport Converter will be accepted.</t>
<t pn="section-9.2-6">In deployments where network-assisted connections
<t>In deployments where network-assisted connections are not allowed are not allowed
between hosts of a domain (i.e., hairpinning), the Converter may be between hosts of a domain (i.e., hairpinning), the Converter may be
instructed to discard such connections. Hairpinned connections are instructed to discard such connections. Hairpinned connections are
thus rejected by the Transport Converter by returning an Error TLV set thus rejected by the Transport Converter by returning an Error TLV set
to "Not Authorized". Absent explicit configuration otherwise, to "Not Authorized". Otherwise, absent explicit configuration,
hairpinning is enabled by the Converter (see <xref hairpinning is enabled by the Converter (see <xref target="fig-hairp" fo
target="fig-hairp"></xref>.</t> rmat="default" sectionFormat="of" derivedContent="Figure 24"/>).</t>
<figure anchor="fig-hairp" align="left" suppress-title="false" pn="figur
<figure anchor="fig-hairp" title="Hairpinning Example"> e-24">
<artwork><![CDATA[ <name slugifiedName="name-hairpinning-example">Hairpinning Example</na
<===Network Provider===> me>
<artwork name="" type="" align="left" alt="" pn="section-9.2-7.1">
&lt;===Network Provider===&gt;
+----+ from X1:x1 to X2':x2' +-----+ X1':x1' +----+ from X1:x1 to X2':x2' +-----+ X1':x1'
| C1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>&gt;--+--- | C1 |>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt ;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;--+---
+----+ | v | +----+ | v |
| v | | v |
| v | | v |
| v | | v |
+----+ from X1':x1' to X2:x2 | v | X2':x2' +----+ from X1':x1' to X2:x2 | v | X2':x2'
| C2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<&lt;--+--- | C2 |<&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt ;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;--+---
+----+ +-----+ +----+ +-----+
Converter Converter
Note: X2':x2' may be equal to Note: X2':x2' may be equal to
X2:x2 X2:x2
]]></artwork> </artwork>
</figure> </figure>
<t></t>
</section> </section>
<section anchor="denial-of-service" numbered="true" toc="include" removeIn
<section anchor="denial-of-service" title="Denial of Service"> RFC="false" pn="section-9.3">
<t>Another possible risk is the amplification attacks since a <name slugifiedName="name-denial-of-service">Denial of Service</name>
Transport Converter sends a SYN towards a remote Server upon reception <t pn="section-9.3-1">Another possible risk is amplification attacks, si
of a SYN from a Client. This could lead to amplification attacks if nce a Transport
the SYN sent by the Transport Converter were larger than the SYN Converter sends a SYN towards a remote Server upon reception of a SYN
received from the Client or if the Transport Converter retransmits the from a Client. This could lead to amplification attacks if the SYN
SYN. To mitigate such attacks, the Transport Converter SHOULD rate sent by the Transport Converter were larger than the SYN received from
limit the number of pending requests for a given Client. It SHOULD the Client, or if the Transport Converter retransmits the SYN. To
also avoid sending to remote Servers SYNs that are significantly mitigate such attacks, the Transport Converter <bcp14>SHOULD</bcp14>
longer than the SYN received from the Client. Finally, the Transport rate-limit the number of pending requests for a given Client. It
Converter SHOULD only retransmit a SYN to a Server after having <bcp14>SHOULD</bcp14> also avoid sending SYNs that are significantly
received a retransmitted SYN from the corresponding Client. Means to longer than the SYN received from the Client, to remote
protect against SYN flooding attacks should also be enabled (e.g., Servers. Finally, the Transport Converter <bcp14>SHOULD</bcp14> only
Section 3 of <xref target="RFC4987"></xref>).</t> retransmit a SYN to a Server after having received a retransmitted SYN
from the corresponding Client. Means to protect against SYN flooding
<t>Attacks from within the network between a Client and a Transport attacks should also be enabled (e.g., <xref target="RFC4987" sectionForm
at="of" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc
4987#section-3" derivedContent="RFC4987"/>).</t>
<t pn="section-9.3-2">Attacks from within the network between a Client a
nd a Transport
Converter (including attacks that change the protocol version) are yet Converter (including attacks that change the protocol version) are yet
another threat. Means to ensure that illegitimate nodes cannot connect another threat. Means to ensure that illegitimate nodes cannot connect
to a network should be implemented.</t> to a network should be implemented.</t>
</section> </section>
<section anchor="traffic-theft" numbered="true" toc="include" removeInRFC=
<section anchor="traffic-theft" title="Traffic Theft"> "false" pn="section-9.4">
<t>Traffic theft is a risk if an illegitimate Converter is inserted in <name slugifiedName="name-traffic-theft">Traffic Theft</name>
<t pn="section-9.4-1">Traffic theft is a risk if an illegitimate Convert
er is inserted in
the path. Indeed, inserting an illegitimate Converter in the the path. Indeed, inserting an illegitimate Converter in the
forwarding path allows traffic interception and can therefore provide forwarding path allows traffic interception and can therefore provide
access to sensitive data issued by or destined to a host. Converter access to sensitive data issued by or destined to a host. Converter
discovery and configuration are out of scope of this document.</t> discovery and configuration are out of scope of this document.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-9.5
<section title="Logging"> ">
<t>If the Converter is configured to behave in the address sharing <name slugifiedName="name-logging">Logging</name>
mode (<xref target="sec-adds"></xref>), the logging recommendations <t pn="section-9.5-1">If the Converter is configured to behave in the ad
discussed in Section 4 of <xref target="RFC6888"></xref> need to be dress-sharing
considered. Security-related issues encountered in address sharing mode (<xref target="sec-adds" format="default" sectionFormat="of" derive
environments are documented in Section 13 of <xref dContent="Section 4.4.2"/>), the logging recommendations
target="RFC6269"></xref>.</t> discussed in <xref target="RFC6888" sectionFormat="of" section="4" forma
t="default" derivedLink="https://rfc-editor.org/rfc/rfc6888#section-4" derivedCo
ntent="RFC6888"/> need to be
considered. Security-related issues encountered in address-sharing
environments are documented in <xref target="RFC6269" sectionFormat="of"
section="13" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6269#s
ection-13" derivedContent="RFC6269"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec-iana" numbered="true" toc="include" removeInRFC="false"
<section anchor="sec-iana" title="IANA Considerations"> pn="section-10">
<t>Note to the RFC Editor: Please replace "THISRFC" in the following <name slugifiedName="name-iana-considerations">IANA Considerations</name>
sub-sections with the RFC number to be assigned to this document.</t> <section anchor="sec-service" numbered="true" toc="include" removeInRFC="f
alse" pn="section-10.1">
<section anchor="sec-service" title="Convert Service Name"> <name slugifiedName="name-convert-service-name">Convert Service Name</na
<t>IANA is requested to assign a service name for the Convert Protocol me>
from the "Service Name and Transport Protocol Port Number Registry" <t pn="section-10.1-1">IANA has assigned a
available at service name for the Convert Protocol from the "Service Name and
https://www.iana.org/assignments/service-names-port-numbers/service-name Transport Protocol Port Number Registry" available at
s-port-numbers.xhtml.</t> &lt;<eref target="https://www.iana.org/assignments/service-names-port-nu
mbers" brackets="none"/>&gt;.</t>
<figure> <dl spacing="compact" indent="25" newline="false" pn="section-10.1-2">
<artwork><![CDATA[ <dt pn="section-10.1-2.1">Service Name:</dt>
Service Name: convert <dd pn="section-10.1-2.2">convert</dd>
Port Number: N/A <dt pn="section-10.1-2.3">Port Number:</dt>
Transport Protocol(s): TCP <dd pn="section-10.1-2.4">N/A</dd>
Description: 0-RTT TCP Convert Protocol <dt pn="section-10.1-2.5">Transport Protocol(s):</dt>
Assignee: IESG <iesg@ietf.org> <dd pn="section-10.1-2.6">TCP</dd>
Contact: IETF Chair <chair@ietf.org> <dt pn="section-10.1-2.7">Description:</dt>
Reference: THISRFC <dd pn="section-10.1-2.8">0-RTT TCP Convert Protocol</dd>
]]></artwork> <dt pn="section-10.1-2.9">Assignee:</dt>
</figure> <dd pn="section-10.1-2.10">IESG &lt;iesg@ietf.org&gt;</dd>
<dt pn="section-10.1-2.11">Contact:</dt>
<t>Clients may use this service name to fed the procedure defined in <dd pn="section-10.1-2.12">IETF Chair &lt;chair@ietf.org&gt;</dd>
<xref target="RFC2782"></xref> to discover the IP address(es) and the <dt pn="section-10.1-2.13">Reference:</dt>
<dd pn="section-10.1-2.14">RFC 8803</dd>
</dl>
<t pn="section-10.1-3">Clients may use this service name to feed the pro
cedure defined in
<xref target="RFC2782" format="default" sectionFormat="of" derivedConten
t="RFC2782"/> to discover the IP address(es) and the
port number used by the Transport Converters of a domain.</t> port number used by the Transport Converters of a domain.</t>
</section> </section>
<section anchor="the-convert-protocol-convert-parameters" numbered="true"
<section anchor="the-convert-protocol-convert-parameters" toc="include" removeInRFC="false" pn="section-10.2">
title="The Convert Protocol (Convert) Parameters"> <name slugifiedName="name-the-convert-protocol-convert">The Convert Prot
<t>IANA is requested to create a new "The TCP Convert Protocol ocol (Convert) Parameters</name>
<t pn="section-10.2-1">IANA has created a new "TCP Convert Protocol
(Convert) Parameters" registry.</t> (Convert) Parameters" registry.</t>
<t pn="section-10.2-2">The following subsections detail new registries w
<t>The following subsections detail new registries within "The Convert ithin the "Convert
Protocol (Convert) Parameters" registry.</t> Protocol (Convert) Parameters" registry.</t>
<t pn="section-10.2-3">The designated expert is expected to ascertain th
<t>The Designated Expert is expected to ascertain the existence of e existence of
suitable documentation as described in Section 4.6 of <xref suitable documentation as described in <xref target="RFC8126" sectionFor
target="RFC8126"></xref> and to verify that the document is mat="of" section="4.6" format="default" derivedLink="https://rfc-editor.org/rfc/
permanently and publicly available. The Designated Expert is also rfc8126#section-4.6" derivedContent="RFC8126"/> and to verify that the document
is
permanently and publicly available. The designated expert is also
expected to check the clarity of purpose and use of the requested code expected to check the clarity of purpose and use of the requested code
points.</t> points.</t>
<t pn="section-10.2-4">Also, criteria that should be applied by the desi
gnated experts
includes determining whether the proposed registration
duplicates existing functionality, whether it is likely to be of
general applicability or useful only for private use, and whether
the registration description is clear.
<t>Also, criteria that should be applied by the Designated Experts All requests should be directed to the review mailing list. For both the
includes determining whether the proposed registration duplicates "Convert TLVs" and "Convert Errors" subregistries, IANA must only accept
existing functionality, whether it is likely to be of general registry updates in the 128-191 range from the designated experts. It is
applicability or whether it is useful only for a private use, and suggested that multiple designated experts be appointed.
whether the registration description is clear. IANA must only accept
registry updates to 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. It is suggested that multiple Designated Experts be appointed.
In cases where a registration decision could be perceived as creating
a conflict of interest for a particular Expert, that Expert should
defer to the judgment of the other Experts.</t>
<section anchor="convert-versions" title="Convert Versions">
<t>IANA is requested to create the "Convert versions" sub-registry.
New values are assigned via IETF Review (Section 4.8 of <xref
target="RFC8126"></xref>).</t>
<t>The initial values to be assigned at the creation of the registry In cases where a registration decision could be perceived as creating
a conflict of interest for a particular expert, that expert should
defer to the judgment of the other experts.</t>
<section anchor="convert-versions" numbered="true" toc="include" removeI
nRFC="false" pn="section-10.2.1">
<name slugifiedName="name-convert-versions">Convert Versions</name>
<t pn="section-10.2.1-1">IANA has created the "Convert Versions" subre
gistry.
New values are assigned via IETF Review (<xref target="RFC8126" sectio
nFormat="of" section="4.8" format="default" derivedLink="https://rfc-editor.org/
rfc/rfc8126#section-4.8" derivedContent="RFC8126"/>).</t>
<t pn="section-10.2.1-2">The initial values of the registry
are as follows:</t> are as follows:</t>
<table anchor="ver" align="center" pn="table-3">
<figure anchor="ver" title="Current Convert Versions"> <name slugifiedName="name-current-convert-versions">Current Convert
<artwork><![CDATA[ +---------+-------------------------------------- Versions</name>
+-------------+ <thead>
| Version | Description | Reference | <tr>
+---------+--------------------------------------+-------------+ <th align="left" colspan="1" rowspan="1">Version</th>
| 0 | Reserved | THISRFC | <th align="left" colspan="1" rowspan="1">Description</th>
| 1 | Assigned | THISRFC | <th align="left" colspan="1" rowspan="1">Reference</th>
+---------+--------------------------------------+-------------+ </tr>
]]></artwork> </thead>
</figure> <tbody>
<tr>
<td align="left" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">Reserved</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">Assigned</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="convert-tlvs" numbered="true" toc="include" removeInRFC
<section anchor="convert-tlvs" title="Convert TLVs"> ="false" pn="section-10.2.2">
<t>IANA is requested to create the "Convert TLVs" sub-registry. The <name slugifiedName="name-convert-tlvs-2">Convert TLVs</name>
procedure for assigning values from this registry is as follows:</t> <t pn="section-10.2.2-1">IANA has created the "Convert TLVs" subregist
ry. The
<t><list style="symbols"> procedures for assigning values from this registry are as follows:</t>
<t>The values in the range 1-127 can be assigned via IETF <dl indent="10" newline="false" spacing="normal" pn="section-10.2.2-2"
Review.</t> >
<dt pn="section-10.2.2-2.1">1-127:</dt>
<t>The values in the range 128-191 can be assigned via <dd pn="section-10.2.2-2.2">IETF Review</dd>
Specification Required.</t> <dt pn="section-10.2.2-2.3">128-191:</dt>
<dd pn="section-10.2.2-2.4">Specification Required</dd>
<t>The values in the range 192-255 are reserved for Private <dt pn="section-10.2.2-2.5">192-255:</dt>
Use.</t> <dd pn="section-10.2.2-2.6">Private Use</dd>
</list></t> </dl>
<t pn="section-10.2.2-3">The initial values of the registry
<t>The initial values to be assigned at the creation of the registry
are as follows:</t> are as follows:</t>
<table anchor="tlvs" align="center" pn="table-4">
<figure anchor="tlvs" title="Initial Convert TLVs"> <name slugifiedName="name-initial-convert-tlvs">Initial Convert TLVs
<artwork><![CDATA[ </name>
+---------+--------------------------------------+-------------+ <thead>
| Code | Name | Reference | <tr>
+---------+--------------------------------------+-------------+ <th align="left" colspan="1" rowspan="1">Code</th>
| 0 | Reserved | THISRFC | <th align="left" colspan="1" rowspan="1">Name</th>
| 1 | Info TLV | THISRFC | <th align="left" colspan="1" rowspan="1">Reference</th>
| 10 | Connect TLV | THISRFC | </tr>
| 20 | Extended TCP Header TLV | THISRFC | </thead>
| 21 | Supported TCP Extension TLV | THISRFC | <tbody>
| 22 | Cookie TLV | THISRFC | <tr>
| 30 | Error TLV | THISRFC | <td align="left" colspan="1" rowspan="1">0</td>
+---------+--------------------------------------+-------------+ <td align="left" colspan="1" rowspan="1">Reserved</td>
]]></artwork> <td align="left" colspan="1" rowspan="1">RFC 8803</td>
</figure> </tr>
<tr>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">Info TLV</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">10</td>
<td align="left" colspan="1" rowspan="1">Connect TLV</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">20</td>
<td align="left" colspan="1" rowspan="1">Extended TCP Header TLV
</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">21</td>
<td align="left" colspan="1" rowspan="1">Supported TCP Extension
TLV</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">22</td>
<td align="left" colspan="1" rowspan="1">Cookie TLV</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">30</td>
<td align="left" colspan="1" rowspan="1">Error TLV</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="convert-error-messages" numbered="true" toc="include" r
<section anchor="convert-error-messages" emoveInRFC="false" pn="section-10.2.3">
title="Convert Error Messages"> <name slugifiedName="name-convert-error-messages">Convert Error Messag
<t>IANA is requested to create the "Convert Errors" sub-registry. es</name>
<t pn="section-10.2.3-1">IANA has created the "Convert Errors" subregi
stry.
Codes in this registry are assigned as a function of the error type. Codes in this registry are assigned as a function of the error type.
Four types are defined; the following ranges are reserved for each Four types are defined; the following ranges are reserved for each
of these types:</t> of these types:</t>
<dl indent="10" newline="false" spacing="normal" pn="section-10.2.3-2"
<t><list style="symbols"> >
<t>Message validation and processing errors: 0-31</t> <dt pn="section-10.2.3-2.1">0-31:</dt>
<dd pn="section-10.2.3-2.2">Message validation and processing errors
<t>Client-side errors: 32-63</t> </dd>
<dt pn="section-10.2.3-2.3">32-63:</dt>
<t>Transport Converter-side errors: 64-95</t> <dd pn="section-10.2.3-2.4">Client-side errors</dd>
<dt pn="section-10.2.3-2.5">64-95:</dt>
<t>Errors caused by destination server: 96-127</t> <dd pn="section-10.2.3-2.6">Transport Converter-side errors</dd>
</list></t> <dt pn="section-10.2.3-2.7">96-127:</dt>
<dd pn="section-10.2.3-2.8">Errors caused by destination Server</dd>
<t>The procedure for assigning values from this sub-registry is as </dl>
<t pn="section-10.2.3-3">The procedures for assigning values from this
subregistry are as
follows:</t> follows:</t>
<dl spacing="normal" indent="10" newline="false" pn="section-10.2.3-4"
<t><list style="symbols"> >
<t>0-127: Values in this range are assigned via IETF Review.</t> <dt pn="section-10.2.3-4.1">0-127:</dt>
<dd pn="section-10.2.3-4.2">IETF Review</dd>
<t>128-191: Values in this range are assigned via Specification <dt pn="section-10.2.3-4.3">128-191:</dt>
Required.</t> <dd pn="section-10.2.3-4.4">Specification Required</dd>
<dt pn="section-10.2.3-4.5">192-255:</dt>
<t>192-255: Values in this range are reserved for Private <dd pn="section-10.2.3-4.6">Private Use</dd>
Use.</t> </dl>
</list></t> <t pn="section-10.2.3-5">The initial values of the registry
<t>The initial values to be assigned at the creation of the registry
are as follows:</t> are as follows:</t>
<table anchor="tab-error-summary" align="center" pn="table-5">
<figure anchor="tab-error-summary" <name slugifiedName="name-initial-convert-error-codes">Initial Conve
title="Initial Convert Error Codes"> rt Error Codes</name>
<artwork><![CDATA[ <thead>
+-------+-----------------------------------+-----------+ <tr>
| Error | Description | Reference | <th align="left" colspan="1" rowspan="1">Error</th>
+-------+-----------------------------------+-----------+ <th align="left" colspan="1" rowspan="1">Description</th>
| 0 | Unsupported Version | THISRFC | <th align="left" colspan="1" rowspan="1">Reference</th>
| 1 | Malformed Message | THISRFC | </tr>
| 2 | Unsupported Message | THISRFC | </thead>
| 3 | Missing Cookie | THISRFC | <tbody>
| 32 | Not Authorized | THISRFC | <tr>
| 33 | Unsupported TCP Option | THISRFC | <td align="left" colspan="1" rowspan="1">0</td>
| 64 | Resource Exceeded | THISRFC | <td align="left" colspan="1" rowspan="1">Unsupported Version</td
| 65 | Network Failure | THISRFC | >
| 96 | Connection Reset | THISRFC | <td align="left" colspan="1" rowspan="1">RFC 8803</td>
| 97 | Destination Unreachable | THISRFC | </tr>
+-------+-----------------------------------+-----------+ <tr>
]]></artwork> <td align="left" colspan="1" rowspan="1">1</td>
</figure> <td align="left" colspan="1" rowspan="1">Malformed Message</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">Unsupported Message</td
>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">Missing Cookie</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">32</td>
<td align="left" colspan="1" rowspan="1">Not Authorized</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">33</td>
<td align="left" colspan="1" rowspan="1">Unsupported TCP Option<
/td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">64</td>
<td align="left" colspan="1" rowspan="1">Resource Exceeded</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">65</td>
<td align="left" colspan="1" rowspan="1">Network Failure</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">96</td>
<td align="left" colspan="1" rowspan="1">Connection Reset</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">97</td>
<td align="left" colspan="1" rowspan="1">Destination Unreachable
</td>
<td align="left" colspan="1" rowspan="1">RFC 8803</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.boucadair-tcpm-dhc-converter" to="DHC-CONVERTE
<reference anchor="RFC0793" R"/>
target="https://www.rfc-editor.org/info/rfc793"> <displayreference target="I-D.olteanu-intarea-socks-6" to="INTAREA-SOCKS"/>
<front> <displayreference target="I-D.boucadair-mptcp-plain-mode" to="MPTCP-PLAIN"/>
<title>Transmission Control Protocol</title> <displayreference target="I-D.peirens-mptcp-transparent" to="MPTCP-TRANSPARE
NT"/>
<author fullname="J. Postel" initials="J." surname="Postel"> <displayreference target="I-D.arkko-arch-low-latency" to="LOW-LATENCY"/>
<organization></organization> <displayreference target="I-D.boucadair-opsawg-tcpm-converter" to="TCPM-CONV
</author> ERTER"/>
<references pn="section-11">
<date month="September" year="1981" /> <name slugifiedName="name-references">References</name>
</front> <references pn="section-11.1">
<name slugifiedName="name-normative-references">Normative References</na
<seriesInfo name="STD" value="7" /> me>
<reference anchor="RFC0793" target="https://www.rfc-editor.org/info/rfc7
<seriesInfo name="RFC" value="793" /> 93" quoteTitle="true" derivedAnchor="RFC0793">
<front>
<seriesInfo name="DOI" value="10.17487/RFC0793" /> <title>Transmission Control Protocol</title>
</reference> <author initials="J." surname="Postel" fullname="J. Postel">
<organization showOnFrontPage="true"/>
<reference anchor="RFC4291" </author>
target="https://www.rfc-editor.org/info/rfc4291"> <date year="1981" month="September"/>
<front> </front>
<title>IP Version 6 Addressing Architecture</title> <seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="793"/>
<author fullname="R. Hinden" initials="R." surname="Hinden"> <seriesInfo name="DOI" value="10.17487/RFC0793"/>
<organization></organization> </reference>
</author> <reference anchor="RFC2018" target="https://www.rfc-editor.org/info/rfc2
018" quoteTitle="true" derivedAnchor="RFC2018">
<author fullname="S. Deering" initials="S." surname="Deering"> <front>
<organization></organization> <title>TCP Selective Acknowledgment Options</title>
</author> <author initials="M." surname="Mathis" fullname="M. Mathis">
<organization showOnFrontPage="true"/>
<date month="February" year="2006" /> </author>
<author initials="J." surname="Mahdavi" fullname="J. Mahdavi">
<abstract> <organization showOnFrontPage="true"/>
<t>This specification defines the addressing architecture of the </author>
IP Version 6 (IPv6) protocol. The document includes the IPv6 <author initials="S." surname="Floyd" fullname="S. Floyd">
addressing model, text representations of IPv6 addresses, <organization showOnFrontPage="true"/>
definition of IPv6 unicast addresses, anycast addresses, and </author>
multicast addresses, and an IPv6 node's required addresses.</t> <author initials="A." surname="Romanow" fullname="A. Romanow">
<organization showOnFrontPage="true"/>
<t>This document obsoletes RFC 3513, "IP Version 6 Addressing </author>
Architecture". [STANDARDS-TRACK]</t> <date year="1996" month="October"/>
</abstract> <abstract>
</front> <t>This memo proposes an implementation of SACK and discusses its
performance and related issues. [STANDARDS-TRACK]</t>
<seriesInfo name="RFC" value="4291" /> </abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC4291" /> <seriesInfo name="RFC" value="2018"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC2018"/>
</reference>
<reference anchor="RFC6824" <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
target="https://www.rfc-editor.org/info/rfc6824"> 119" quoteTitle="true" derivedAnchor="RFC2119">
<front> <front>
<title>TCP Extensions for Multipath Operation with Multiple <title>Key words for use in RFCs to Indicate Requirement Levels</tit
Addresses</title> le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<author fullname="A. Ford" initials="A." surname="Ford"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <date year="1997" month="March"/>
<abstract>
<author fullname="C. Raiciu" initials="C." surname="Raiciu"> <t>In many standards track documents several words are used to sig
<organization></organization> nify the requirements in the specification. These words are often capitalized.
</author> This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
<author fullname="M. Handley" initials="M." surname="Handley"> Community, and requests discussion and suggestions for improvements.</t>
<organization></organization> </abstract>
</author> </front>
<seriesInfo name="BCP" value="14"/>
<author fullname="O. Bonaventure" initials="O." <seriesInfo name="RFC" value="2119"/>
surname="Bonaventure"> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
<organization></organization> </reference>
</author> <reference anchor="RFC2827" target="https://www.rfc-editor.org/info/rfc2
827" quoteTitle="true" derivedAnchor="RFC2827">
<date month="January" year="2013" /> <front>
<title>Network Ingress Filtering: Defeating Denial of Service Attack
<abstract> s which employ IP Source Address Spoofing</title>
<t>TCP/IP communication is currently restricted to a single path <author initials="P." surname="Ferguson" fullname="P. Ferguson">
per connection, yet multiple paths often exist between peers. The <organization showOnFrontPage="true"/>
simultaneous use of these multiple paths for a TCP/IP session </author>
would improve resource usage within the network and, thus, improve <author initials="D." surname="Senie" fullname="D. Senie">
user experience through higher throughput and improved resilience <organization showOnFrontPage="true"/>
to network failure.</t> </author>
<date year="2000" month="May"/>
<t>Multipath TCP provides the ability to simultaneously use <abstract>
multiple paths between peers. This document presents a set of <t>This paper discusses a simple, effective, and straightforward m
extensions to traditional TCP to support multipath operation. The ethod for using ingress traffic filtering to prohibit DoS (Denial of Service) at
protocol offers the same type of service to applications as TCP tacks which use forged IP addresses to be propagated from 'behind' an Internet S
(i.e., reliable bytestream), and it provides the components ervice Provider's (ISP) aggregation point. This document specifies an Internet
necessary to establish and use multiple TCP flows across Best Current Practices for the Internet Community, and requests discussion and s
potentially disjoint paths. This document defines an Experimental uggestions for improvements.</t>
Protocol for the Internet community.</t> </abstract>
</abstract> </front>
</front> <seriesInfo name="BCP" value="38"/>
<seriesInfo name="RFC" value="2827"/>
<seriesInfo name="RFC" value="6824" /> <seriesInfo name="DOI" value="10.17487/RFC2827"/>
</reference>
<seriesInfo name="DOI" value="10.17487/RFC6824" /> <reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4
</reference> 291" quoteTitle="true" derivedAnchor="RFC4291">
<front>
<reference anchor="RFC7413" <title>IP Version 6 Addressing Architecture</title>
target="https://www.rfc-editor.org/info/rfc7413"> <author initials="R." surname="Hinden" fullname="R. Hinden">
<front> <organization showOnFrontPage="true"/>
<title>TCP Fast Open</title> </author>
<author initials="S." surname="Deering" fullname="S. Deering">
<author fullname="Y. Cheng" initials="Y." surname="Cheng"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <date year="2006" month="February"/>
<abstract>
<author fullname="J. Chu" initials="J." surname="Chu"> <t>This specification defines the addressing architecture of the I
<organization></organization> P Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, t
</author> ext representations of IPv6 addresses, definition of IPv6 unicast addresses, any
cast addresses, and multicast addresses, and an IPv6 node's required addresses.<
<author fullname="S. Radhakrishnan" initials="S." /t>
surname="Radhakrishnan"> <t>This document obsoletes RFC 3513, "IP Version 6 Addressing Arch
<organization></organization> itecture". [STANDARDS-TRACK]</t>
</author> </abstract>
</front>
<author fullname="A. Jain" initials="A." surname="Jain"> <seriesInfo name="RFC" value="4291"/>
<organization></organization> <seriesInfo name="DOI" value="10.17487/RFC4291"/>
</author> </reference>
<reference anchor="RFC4787" target="https://www.rfc-editor.org/info/rfc4
<date month="December" year="2014" /> 787" quoteTitle="true" derivedAnchor="RFC4787">
<front>
<abstract> <title>Network Address Translation (NAT) Behavioral Requirements for
<t>This document describes an experimental TCP mechanism called Unicast UDP</title>
TCP Fast Open (TFO). TFO allows data to be carried in the SYN and <author initials="F." surname="Audet" fullname="F. Audet" role="edit
SYN-ACK packets and consumed by the receiving end during the or">
initial connection handshake, and saves up to one full round-trip <organization showOnFrontPage="true"/>
time (RTT) compared to the standard TCP, which requires a </author>
three-way handshake (3WHS) to complete before data can be <author initials="C." surname="Jennings" fullname="C. Jennings">
exchanged. However, TFO deviates from the standard TCP semantics, <organization showOnFrontPage="true"/>
since the data in the SYN could be replayed to an application in </author>
some rare circumstances. Applications should not use TFO unless <date year="2007" month="January"/>
they can tolerate this issue, as detailed in the Applicability <abstract>
section.</t> <t>This document defines basic terminology for describing differen
</abstract> t types of Network Address Translation (NAT) behavior when handling Unicast UDP
</front> and also defines a set of requirements that would allow many applications, such
as multimedia communications or online gaming, to work consistently. Developing
<seriesInfo name="RFC" value="7413" /> NATs that meet this set of requirements will greatly increase the likelihood th
at these applications will function properly. This document specifies an Intern
<seriesInfo name="DOI" value="10.17487/RFC7413" /> et Best Current Practices for the Internet Community, and requests discussion an
</reference> d suggestions for improvements.</t>
</abstract>
<reference anchor="RFC4987" </front>
target="https://www.rfc-editor.org/info/rfc4987"> <seriesInfo name="BCP" value="127"/>
<front> <seriesInfo name="RFC" value="4787"/>
<title>TCP SYN Flooding Attacks and Common Mitigations</title> <seriesInfo name="DOI" value="10.17487/RFC4787"/>
</reference>
<author fullname="W. Eddy" initials="W." surname="Eddy"> <reference anchor="RFC4987" target="https://www.rfc-editor.org/info/rfc4
<organization></organization> 987" quoteTitle="true" derivedAnchor="RFC4987">
</author> <front>
<title>TCP SYN Flooding Attacks and Common Mitigations</title>
<date month="August" year="2007" /> <author initials="W." surname="Eddy" fullname="W. Eddy">
<organization showOnFrontPage="true"/>
<abstract> </author>
<t>This document describes TCP SYN flooding attacks, which have <date year="2007" month="August"/>
been well-known to the community for several years. Various <abstract>
countermeasures against these attacks, and the trade-offs of each, <t>This document describes TCP SYN flooding attacks, which have be
are described. This document archives explanations of the attack en well-known to the community for several years. Various countermeasures again
and common defense techniques for the benefit of TCP implementers st these attacks, and the trade-offs of each, are described. This document arch
and administrators of TCP servers or networks, but does not make ives explanations of the attack and common defense techniques for the benefit of
any standards-level recommendations. This memo provides TCP implementers and administrators of TCP servers or networks, but does not ma
information for the Internet community.</t> ke any standards-level recommendations. This memo provides information for the
</abstract> Internet community.</t>
</front> </abstract>
</front>
<seriesInfo name="RFC" value="4987" /> <seriesInfo name="RFC" value="4987"/>
<seriesInfo name="DOI" value="10.17487/RFC4987"/>
<seriesInfo name="DOI" value="10.17487/RFC4987" /> </reference>
</reference> <reference anchor="RFC5925" target="https://www.rfc-editor.org/info/rfc5
925" quoteTitle="true" derivedAnchor="RFC5925">
<reference anchor="RFC2119" <front>
target="https://www.rfc-editor.org/info/rfc2119"> <title>The TCP Authentication Option</title>
<front> <author initials="J." surname="Touch" fullname="J. Touch">
<title>Key words for use in RFCs to Indicate Requirement <organization showOnFrontPage="true"/>
Levels</title> </author>
<author initials="A." surname="Mankin" fullname="A. Mankin">
<author fullname="S. Bradner" initials="S." surname="Bradner"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <author initials="R." surname="Bonica" fullname="R. Bonica">
<organization showOnFrontPage="true"/>
<date month="March" year="1997" /> </author>
<date year="2010" month="June"/>
<abstract> <abstract>
<t>In many standards track documents several words are used to <t>This document specifies the TCP Authentication Option (TCP-AO),
signify the requirements in the specification. These words are which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO spe
often capitalized. This document defines these words as they cifies the use of stronger Message Authentication Codes (MACs), protects against
should be interpreted in IETF documents. This document specifies replays even for long-lived TCP connections, and provides more details on the a
an Internet Best Current Practices for the Internet Community, and ssociation of security with TCP connections than TCP MD5. TCP-AO is compatible
requests discussion and suggestions for improvements.</t> with either a static Master Key Tuple (MKT) configuration or an external, out-of
</abstract> -band MKT management mechanism; in either case, TCP-AO also protects connections
</front> when using the same MKT across repeated instances of a connection, using traffi
c keys derived from the MKT, and coordinates MKT changes between endpoints. The
<seriesInfo name="BCP" value="14" /> result is intended to support current infrastructure uses of TCP MD5, such as t
o protect long-lived connections (as used, e.g., in BGP and LDP), and to support
<seriesInfo name="RFC" value="2119" /> 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
<seriesInfo name="DOI" value="10.17487/RFC2119" /> are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fu
</reference> lly compatible with the proposed requirements for the replacement of TCP MD5. [
STANDARDS-TRACK]</t>
<reference anchor="RFC8174" </abstract>
target="https://www.rfc-editor.org/info/rfc8174"> </front>
<front> <seriesInfo name="RFC" value="5925"/>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key <seriesInfo name="DOI" value="10.17487/RFC5925"/>
Words</title> </reference>
<reference anchor="RFC6888" target="https://www.rfc-editor.org/info/rfc6
<author fullname="B. Leiba" initials="B." surname="Leiba"> 888" quoteTitle="true" derivedAnchor="RFC6888">
<organization></organization> <front>
</author> <title>Common Requirements for Carrier-Grade NATs (CGNs)</title>
<author initials="S." surname="Perreault" fullname="S. Perreault" ro
<date month="May" year="2017" /> le="editor">
<organization showOnFrontPage="true"/>
<abstract> </author>
<t>RFC 2119 specifies common key words that may be used in <author initials="I." surname="Yamagata" fullname="I. Yamagata">
protocol specifications. This document aims to reduce the <organization showOnFrontPage="true"/>
ambiguity by clarifying that only UPPERCASE usage of the key words </author>
have the defined special meanings.</t> <author initials="S." surname="Miyakawa" fullname="S. Miyakawa">
</abstract> <organization showOnFrontPage="true"/>
</front> </author>
<author initials="A." surname="Nakagawa" fullname="A. Nakagawa">
<seriesInfo name="BCP" value="14" /> <organization showOnFrontPage="true"/>
</author>
<seriesInfo name="RFC" value="8174" /> <author initials="H." surname="Ashida" fullname="H. Ashida">
<organization showOnFrontPage="true"/>
<seriesInfo name="DOI" value="10.17487/RFC8174" /> </author>
</reference> <date year="2013" month="April"/>
<abstract>
<reference anchor="RFC5925" <t>This document defines common requirements for Carrier-Grade NAT
target="https://www.rfc-editor.org/info/rfc5925"> s (CGNs). It updates RFC 4787.</t>
<front> </abstract>
<title>The TCP Authentication Option</title> </front>
<seriesInfo name="BCP" value="127"/>
<author fullname="J. Touch" initials="J." surname="Touch"> <seriesInfo name="RFC" value="6888"/>
<organization></organization> <seriesInfo name="DOI" value="10.17487/RFC6888"/>
</author> </reference>
<reference anchor="RFC6890" target="https://www.rfc-editor.org/info/rfc6
<author fullname="A. Mankin" initials="A." surname="Mankin"> 890" quoteTitle="true" derivedAnchor="RFC6890">
<organization></organization> <front>
</author> <title>Special-Purpose IP Address Registries</title>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<author fullname="R. Bonica" initials="R." surname="Bonica"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <author initials="L." surname="Vegoda" fullname="L. Vegoda">
<organization showOnFrontPage="true"/>
<date month="June" year="2010" /> </author>
<author initials="R." surname="Bonica" fullname="R. Bonica" role="ed
<abstract> itor">
<t>This document specifies the TCP Authentication Option (TCP-AO), <organization showOnFrontPage="true"/>
which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP </author>
MD5). TCP-AO specifies the use of stronger Message Authentication <author initials="B." surname="Haberman" fullname="B. Haberman">
Codes (MACs), protects against replays even for long-lived TCP <organization showOnFrontPage="true"/>
connections, and provides more details on the association of </author>
security with TCP connections than TCP MD5. TCP-AO is compatible <date year="2013" month="April"/>
with either a static Master Key Tuple (MKT) configuration or an <abstract>
external, out-of-band MKT management mechanism; in either case, <t>This memo reiterates the assignment of an IPv4 address block (1
TCP-AO also protects connections when using the same MKT across 92.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 S
repeated instances of a connection, using traffic keys derived pecial-Purpose Address Registries. Upon restructuring, the aforementioned regis
from the MKT, and coordinates MKT changes between endpoints. The tries will record all special-purpose address blocks, maintaining a common set o
result is intended to support current infrastructure uses of TCP f information regarding each address block.</t>
MD5, such as to protect long-lived connections (as used, e.g., in </abstract>
BGP and LDP), and to support a larger set of MACs with minimal </front>
other system and operational changes. TCP-AO uses a different <seriesInfo name="BCP" value="153"/>
option identifier than TCP MD5, even though TCP-AO and TCP MD5 are <seriesInfo name="RFC" value="6890"/>
never permitted to be used simultaneously. TCP-AO supports IPv6, <seriesInfo name="DOI" value="10.17487/RFC6890"/>
and is fully compatible with the proposed requirements for the </reference>
replacement of TCP MD5. [STANDARDS-TRACK]</t> <reference anchor="RFC7323" target="https://www.rfc-editor.org/info/rfc7
</abstract> 323" quoteTitle="true" derivedAnchor="RFC7323">
</front> <front>
<title>TCP Extensions for High Performance</title>
<seriesInfo name="RFC" value="5925" /> <author initials="D." surname="Borman" fullname="D. Borman">
<organization showOnFrontPage="true"/>
<seriesInfo name="DOI" value="10.17487/RFC5925" /> </author>
</reference> <author initials="B." surname="Braden" fullname="B. Braden">
<organization showOnFrontPage="true"/>
<reference anchor="RFC8126" </author>
target="https://www.rfc-editor.org/info/rfc8126"> <author initials="V." surname="Jacobson" fullname="V. Jacobson">
<front> <organization showOnFrontPage="true"/>
<title>Guidelines for Writing an IANA Considerations Section in </author>
RFCs</title> <author initials="R." surname="Scheffenegger" fullname="R. Scheffene
gger" role="editor">
<author fullname="M. Cotton" initials="M." surname="Cotton"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <date year="2014" month="September"/>
<abstract>
<author fullname="B. Leiba" initials="B." surname="Leiba"> <t>This document specifies a set of TCP extensions to improve perf
<organization></organization> ormance over paths with a large bandwidth * delay product and to provide reliabl
</author> e operation over very high-speed paths. It defines the TCP Window Scale (WS) op
tion and the TCP Timestamps (TS) option and their semantics. The Window Scale o
<author fullname="T. Narten" initials="T." surname="Narten"> ption is used to support larger receive windows, while the Timestamps option can
<organization></organization> be used for at least two distinct mechanisms, Protection Against Wrapped Sequen
</author> ces (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herei
n.</t>
<date month="June" year="2017" /> <t>This document obsoletes RFC 1323 and describes changes from it.
</t>
<abstract> </abstract>
<t>Many protocols make use of points of extensibility that use </front>
constants to identify various protocol parameters. To ensure that <seriesInfo name="RFC" value="7323"/>
the values in these fields do not have conflicting uses and to <seriesInfo name="DOI" value="10.17487/RFC7323"/>
promote interoperability, their allocations are often coordinated </reference>
by a central record keeper. For IETF protocols, that role is <reference anchor="RFC7413" target="https://www.rfc-editor.org/info/rfc7
filled by the Internet Assigned Numbers Authority (IANA).</t> 413" quoteTitle="true" derivedAnchor="RFC7413">
<front>
<t>To make assignments in a given registry prudently, guidance <title>TCP Fast Open</title>
describing the conditions under which new values should be <author initials="Y." surname="Cheng" fullname="Y. Cheng">
assigned, as well as when and how modifications to existing values <organization showOnFrontPage="true"/>
can be made, is needed. This document defines a framework for the </author>
documentation of these guidelines by specification authors, in <author initials="J." surname="Chu" fullname="J. Chu">
order to assure that the provided guidance for the IANA <organization showOnFrontPage="true"/>
Considerations is clear and addresses the various issues that are </author>
likely in the operation of a registry.</t> <author initials="S." surname="Radhakrishnan" fullname="S. Radhakris
hnan">
<t>This is the third edition of this document; it obsoletes RFC <organization showOnFrontPage="true"/>
5226.</t> </author>
</abstract> <author initials="A." surname="Jain" fullname="A. Jain">
</front> <organization showOnFrontPage="true"/>
</author>
<seriesInfo name="BCP" value="26" /> <date year="2014" month="December"/>
<abstract>
<seriesInfo name="RFC" value="8126" /> <t>This document describes an experimental TCP mechanism called TC
P Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
<seriesInfo name="DOI" value="10.17487/RFC8126" /> and consumed by the receiving end during the initial connection handshake, and
</reference> saves up to one full round-trip time (RTT) compared to the standard TCP, which r
equires a three-way handshake (3WHS) to complete before data can be exchanged.
<reference anchor="RFC6890" However, TFO deviates from the standard TCP semantics, since the data in the SYN
target="https://www.rfc-editor.org/info/rfc6890"> could be replayed to an application in some rare circumstances. Applications s
<front> hould not use TFO unless they can tolerate this issue, as detailed in the Applic
<title>Special-Purpose IP Address Registries</title> ability section.</t>
</abstract>
<author fullname="M. Cotton" initials="M." surname="Cotton"> </front>
<organization></organization> <seriesInfo name="RFC" value="7413"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC7413"/>
</reference>
<author fullname="L. Vegoda" initials="L." surname="Vegoda"> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
<organization></organization> 126" quoteTitle="true" derivedAnchor="RFC8126">
</author> <front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
<author fullname="R. Bonica" initials="R." role="editor" </title>
surname="Bonica"> <author initials="M." surname="Cotton" fullname="M. Cotton">
<organization></organization> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<author fullname="B. Haberman" initials="B." surname="Haberman"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
<date month="April" year="2013" /> </author>
<date year="2017" month="June"/>
<abstract> <abstract>
<t>This memo reiterates the assignment of an IPv4 address block <t>Many protocols make use of points of extensibility that use con
(192.0.0.0/24) to IANA. It also instructs IANA to restructure its stants to identify various protocol parameters. To ensure that the values in th
IPv4 and IPv6 Special-Purpose Address Registries. Upon ese fields do not have conflicting uses and to promote interoperability, their a
restructuring, the aforementioned registries will record all llocations are often coordinated by a central record keeper. For IETF protocols
special-purpose address blocks, maintaining a common set of , that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
information regarding each address block.</t> <t>To make assignments in a given registry prudently, guidance des
</abstract> cribing the conditions under which new values should be assigned, as well as whe
</front> n and how modifications to existing values can be made, is needed. This documen
t defines a framework for the documentation of these guidelines by specification
<seriesInfo name="BCP" value="153" /> authors, in order to assure that the provided guidance for the IANA Considerati
ons is clear and addresses the various issues that are likely in the operation o
<seriesInfo name="RFC" value="6890" /> f a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
<seriesInfo name="DOI" value="10.17487/RFC6890" /> 26.</t>
</reference> </abstract>
</front>
<reference anchor="RFC6888" <seriesInfo name="BCP" value="26"/>
target="https://www.rfc-editor.org/info/rfc6888"> <seriesInfo name="RFC" value="8126"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC8126"/>
<title>Common Requirements for Carrier-Grade NATs (CGNs)</title> </reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
<author fullname="S. Perreault" initials="S." role="editor" 174" quoteTitle="true" derivedAnchor="RFC8174">
surname="Perreault"> <front>
<organization></organization> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
</author> tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<author fullname="I. Yamagata" initials="I." surname="Yamagata"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <date year="2017" month="May"/>
<abstract>
<author fullname="S. Miyakawa" initials="S." surname="Miyakawa"> <t>RFC 2119 specifies common key words that may be used in protoco
<organization></organization> l specifications. This document aims to reduce the ambiguity by clarifying tha
</author> t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
<author fullname="A. Nakagawa" initials="A." surname="Nakagawa"> </front>
<organization></organization> <seriesInfo name="BCP" value="14"/>
</author> <seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
<author fullname="H. Ashida" initials="H." surname="Ashida"> </reference>
<organization></organization> <reference anchor="RFC8684" target="https://www.rfc-editor.org/info/rfc8
</author> 684" quoteTitle="true" derivedAnchor="RFC8684">
<front>
<date month="April" year="2013" /> <title>TCP Extensions for Multipath Operation with Multiple Addresse
s</title>
<abstract> <author initials="A." surname="Ford" fullname="A. Ford">
<t>This document defines common requirements for Carrier-Grade <organization showOnFrontPage="true"/>
NATs (CGNs). It updates RFC 4787.</t> </author>
</abstract> <author initials="C." surname="Raiciu" fullname="C. Raiciu">
</front> <organization showOnFrontPage="true"/>
</author>
<seriesInfo name="BCP" value="127" /> <author initials="M." surname="Handley" fullname="M. Handley">
<organization showOnFrontPage="true"/>
<seriesInfo name="RFC" value="6888" /> </author>
<author initials="O." surname="Bonaventure" fullname="O. Bonaventure
<seriesInfo name="DOI" value="10.17487/RFC6888" /> ">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="RFC4787" <author initials="C." surname="Paasch" fullname="C. Paasch">
target="https://www.rfc-editor.org/info/rfc4787"> <organization showOnFrontPage="true"/>
<front> </author>
<title>Network Address Translation (NAT) Behavioral Requirements for <date year="2020" month="March"/>
Unicast UDP</title> <abstract>
<t>TCP/IP communication is currently restricted to a single path p
<author fullname="F. Audet" initials="F." role="editor" er connection, yet multiple paths often exist between peers. The simultaneous us
surname="Audet"> e of these multiple paths for a TCP/IP session would improve resource usage with
<organization></organization> in the network and thus improve user experience through higher throughput and im
</author> proved resilience to network failure.</t>
<t>Multipath TCP provides the ability to simultaneously use multip
<author fullname="C. Jennings" initials="C." surname="Jennings"> le paths between peers. This document presents a set of extensions to traditiona
<organization></organization> l TCP to support multipath operation. The protocol offers the same type of servi
</author> ce to applications as TCP (i.e., a reliable bytestream), and it provides the com
ponents necessary to establish and use multiple TCP flows across potentially dis
<date month="January" year="2007" /> joint paths.</t>
<t>This document specifies v1 of Multipath TCP, obsoleting v0 as s
<abstract> pecified in RFC 6824, through clarifications and modifications primarily driven
<t>This document defines basic terminology for describing by deployment experience.</t>
different types of Network Address Translation (NAT) behavior when </abstract>
handling Unicast UDP and also defines a set of requirements that </front>
would allow many applications, such as multimedia communications <seriesInfo name="RFC" value="8684"/>
or online gaming, to work consistently. Developing NATs that meet <seriesInfo name="DOI" value="10.17487/RFC8684"/>
this set of requirements will greatly increase the likelihood that </reference>
these applications will function properly. This document specifies </references>
an Internet Best Current Practices for the Internet Community, and <references pn="section-11.2">
requests discussion and suggestions for improvements.</t> <name slugifiedName="name-informative-references">Informative References
</abstract> </name>
</front> <reference anchor="ANRW17" quoteTitle="true" derivedAnchor="ANRW17">
<front>
<seriesInfo name="BCP" value="127" /> <title>Tracking transport-layer evolution with PATHspider</title>
<author initials="B." surname="Trammell">
<seriesInfo name="RFC" value="4787" /> <organization showOnFrontPage="true"/>
</author>
<seriesInfo name="DOI" value="10.17487/RFC4787" /> <author initials="M." surname="Kuehlewind">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="RFC7323" <author initials="P." surname="De Vaere">
target="https://www.rfc-editor.org/info/rfc7323"> <organization showOnFrontPage="true"/>
<front> </author>
<title>TCP Extensions for High Performance</title> <author initials="I." surname="Learmonth">
<organization showOnFrontPage="true"/>
<author fullname="D. Borman" initials="D." surname="Borman"> </author>
<organization></organization> <author initials="G." surname="Fairhurst">
</author> <organization showOnFrontPage="true"/>
</author>
<author fullname="B. Braden" initials="B." surname="Braden"> <date month="July" year="2017"/>
<organization></organization> </front>
</author> <refcontent>Applied Networking Research Workshop 2017 (ANRW17)</refcon
tent>
<author fullname="V. Jacobson" initials="V." surname="Jacobson"> </reference>
<organization></organization> <reference anchor="I-D.boucadair-tcpm-dhc-converter" quoteTitle="true" t
</author> arget="https://tools.ietf.org/html/draft-boucadair-tcpm-dhc-converter-03" derive
dAnchor="DHC-CONVERTER">
<author fullname="R. Scheffenegger" initials="R." role="editor" <front>
surname="Scheffenegger"> <title>DHCP Options for 0-RTT TCP Converters</title>
<organization></organization> <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair
</author> ">
<organization showOnFrontPage="true"/>
<date month="September" year="2014" /> </author>
<author initials="C" surname="Jacquenet" fullname="Christian Jacquen
<abstract> et">
<t>This document specifies a set of TCP extensions to improve <organization showOnFrontPage="true"/>
performance over paths with a large bandwidth * delay product and </author>
to provide reliable operation over very high-speed paths. It <author initials="T" surname="Reddy.K" fullname="Tirumaleswar Reddy.
defines the TCP Window Scale (WS) option and the TCP Timestamps K">
(TS) option and their semantics. The Window Scale option is used <organization showOnFrontPage="true"/>
to support larger receive windows, while the Timestamps option can </author>
be used for at least two distinct mechanisms, Protection Against <date month="October" day="7" year="2019"/>
Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), <abstract>
that are also described herein.</t> <t>Because of the lack of important TCP extensions, e.g., Multipat
h TCP support at the server side, some service providers now consider a network-
<t>This document obsoletes RFC 1323 and describes changes from assisted model that relies upon the activation of a dedicated function called Tr
it.</t> ansport Converters. For example, network-assisted Multipath TCP deployment mode
</abstract> ls are designed to facilitate the adoption of Multipath TCP for the establishmen
</front> t of multi-path communications without making any assumption about the support o
f Multipath TCP by the remote servers. Transport Converters located in the netw
<seriesInfo name="RFC" value="7323" /> ork are responsible for establishing multi-path communications on behalf of endp
oints, thereby taking advantage of Multipath TCP capabilities to achieve differe
<seriesInfo name="DOI" value="10.17487/RFC7323" /> nt goals that include (but are not limited to) optimization of resource usage (e
</reference> .g., bandwidth aggregation), of resiliency (e.g., primary/backup communication p
aths), and traffic offload management. This document focuses on the explicit de
<reference anchor="RFC2018" ployment scheme where the identity of the Transport Converters is explicitly con
target="https://www.rfc-editor.org/info/rfc2018"> figured on connected hosts. This document specifies DHCP (IPv4 and IPv6) option
<front> s to configure hosts with Converters parameters.</t>
<title>TCP Selective Acknowledgment Options</title> </abstract>
</front>
<author fullname="M. Mathis" initials="M." surname="Mathis"> <seriesInfo name="Internet-Draft" value="draft-boucadair-tcpm-dhc-conv
<organization></organization> erter-03"/>
</author> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-b
oucadair-tcpm-dhc-converter-03.txt"/>
<author fullname="J. Mahdavi" initials="J." surname="Mahdavi"> <refcontent>Work in Progress</refcontent>
<organization></organization> </reference>
</author> <reference anchor="Fukuda2011" quoteTitle="true" derivedAnchor="Fukuda20
11">
<author fullname="S. Floyd" initials="S." surname="Floyd"> <front>
<organization></organization> <title>An Analysis of Longitudinal TCP Passive Measurements (Short P
</author> aper)</title>
<author initials="K." surname="Fukuda">
<author fullname="A. Romanow" initials="A." surname="Romanow"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <date year="2011"/>
</front>
<date month="October" year="1996" /> <refcontent>Traffic Monitoring and Analysis</refcontent>
<refcontent>TMA 2011</refcontent>
<abstract> <refcontent>Lecture Notes in Computer Science, vol. 6613</refcontent>
<t>This memo proposes an implementation of SACK and discusses its </reference>
performance and related issues. [STANDARDS-TRACK]</t> <reference anchor="HOT-MIDDLEBOX13" target="https://inl.info.ucl.ac.be/p
</abstract> ublications/multipath-middlebox" quoteTitle="true" derivedAnchor="HOT-MIDDLEBOX1
</front> 3">
<front>
<seriesInfo name="RFC" value="2018" /> <title>Multipath in the Middle(Box)</title>
<author initials="G." surname="Detal">
<seriesInfo name="DOI" value="10.17487/RFC2018" /> <organization showOnFrontPage="true"/>
</reference> </author>
<author initials="C." surname="Paasch">
<reference anchor="RFC2827" <organization showOnFrontPage="true"/>
target="https://www.rfc-editor.org/info/rfc2827"> </author>
<front> <author initials="O." surname="Bonaventure">
<title>Network Ingress Filtering: Defeating Denial of Service <organization showOnFrontPage="true"/>
Attacks which employ IP Source Address Spoofing</title> </author>
<date month="December" year="2013"/>
<author fullname="P. Ferguson" initials="P." surname="Ferguson"> </front>
<organization></organization> <seriesInfo name="DOI" value="10.1145/2535828.2535829"/>
</author> <refcontent>HotMiddlebox'13</refcontent>
</reference>
<author fullname="D. Senie" initials="D." surname="Senie"> <reference anchor="IANA-CONVERT" target="https://www.iana.org/assignment
<organization></organization> s/tcp-convert-protocol-parameters" quoteTitle="true" derivedAnchor="IANA-CONVERT
</author> ">
<front>
<date month="May" year="2000" /> <title>TCP Convert Protocol (Convert) Parameters</title>
<author>
<abstract> <organization showOnFrontPage="true">IANA</organization>
<t>This paper discusses a simple, effective, and straightforward </author>
method for using ingress traffic filtering to prohibit DoS (Denial </front>
of Service) attacks which use forged IP addresses to be propagated </reference>
from 'behind' an Internet Service Provider's (ISP) aggregation <reference anchor="IETFJ16" quoteTitle="true" derivedAnchor="IETFJ16">
point. This document specifies an Internet Best Current Practices <front>
for the Internet Community, and requests discussion and <title>Multipath TCP Deployments</title>
suggestions for improvements.</t> <author initials="O." surname="Bonaventure">
</abstract> <organization showOnFrontPage="true"/>
</front> </author>
<author initials="S." surname="Seo">
<seriesInfo name="BCP" value="38" /> <organization showOnFrontPage="true"/>
</author>
<seriesInfo name="RFC" value="2827" /> <date month="November" year="2016"/>
</front>
<seriesInfo name="DOI" value="10.17487/RFC2827" /> <refcontent>IETF Journal</refcontent>
</reference> <refcontent>Vol. 12, Issue 2</refcontent>
</references> </reference>
<reference anchor="IMC11" quoteTitle="true" target="https://doi.org/10.1
<references title="Informative References"> 145/2068816.2068834" derivedAnchor="IMC11">
<?rfc include='reference.RFC.5461'?> <front>
<title>Is it still possible to extend TCP?</title>
<?rfc include='reference.RFC.6731'?> <author initials="K." surname="Honda">
<organization showOnFrontPage="true"/>
<reference anchor="RFC6978" </author>
target="https://www.rfc-editor.org/info/rfc6978"> <author initials="Y." surname="Nishida">
<front> <organization showOnFrontPage="true"/>
<title>A TCP Authentication Option Extension for NAT </author>
Traversal</title> <author initials="C." surname="Raiciu">
<organization showOnFrontPage="true"/>
<author fullname="J. Touch" initials="J." surname="Touch"> </author>
<organization></organization> <author initials="A." surname="Greenhalgh">
</author> <organization showOnFrontPage="true"/>
</author>
<date month="July" year="2013" /> <author initials="M." surname="Handley">
<organization showOnFrontPage="true"/>
<abstract> </author>
<t>This document describes an extension to the TCP Authentication <author initials="T." surname="Hideyuki">
Option (TCP-AO) to support its use over connections that pass <organization showOnFrontPage="true"/>
through Network Address Translators and/or Network Address and </author>
Port Translators (NATs/NAPTs). This extension changes the data <date month="November" year="2011"/>
used to compute traffic keys, but it does not alter TCP-AO's </front>
packet processing or key generation algorithms.</t> <seriesInfo name="DOI" value="10.1145/2068816.2068834"/>
</abstract> <refcontent>Proceedings of the 2011 ACM SIGCOMM conference on
</front> Internet measurement conference
</refcontent>
<seriesInfo name="RFC" value="6978" /> </reference>
<reference anchor="I-D.olteanu-intarea-socks-6" quoteTitle="true" target
<seriesInfo name="DOI" value="10.17487/RFC6978" /> ="https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-10" derivedAnchor="I
</reference> NTAREA-SOCKS">
<front>
<reference anchor="RFC2782" <title>SOCKS Protocol Version 6</title>
target="https://www.rfc-editor.org/info/rfc2782"> <author initials="V" surname="Olteanu" fullname="Vladimir Olteanu">
<front> <organization showOnFrontPage="true"/>
<title>A DNS RR for specifying the location of services (DNS </author>
SRV)</title> <author initials="D" surname="Niculescu" fullname="Dragos Niculescu"
>
<author fullname="A. Gulbrandsen" initials="A." <organization showOnFrontPage="true"/>
surname="Gulbrandsen"> </author>
<organization></organization> <date month="July" day="13" year="2020"/>
</author> <abstract>
<t>The SOCKS protocol is used primarily to proxy TCP connections t
<author fullname="P. Vixie" initials="P." surname="Vixie"> o arbitrary destinations via the use of a proxy server. Under the latest versio
<organization></organization> n of the protocol (version 5), it takes 2 RTTs (or 3, if authentication is used)
</author> before data can flow between the client and the server. This memo proposes SOC
KS version 6, which reduces the number of RTTs used, takes full advantage of TCP
<author fullname="L. Esibov" initials="L." surname="Esibov"> Fast Open, and adds support for 0-RTT authentication.</t>
<organization></organization> </abstract>
</author> </front>
<seriesInfo name="Internet-Draft" value="draft-olteanu-intarea-socks-6
<date month="February" year="2000" /> -10"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-o
<abstract> lteanu-intarea-socks-6-10.txt"/>
<t>This document describes a DNS RR which specifies the location <refcontent>Work in Progress</refcontent>
of the server(s) for a specific protocol and domain. </reference>
[STANDARDS-TRACK]</t> <reference anchor="I-D.arkko-arch-low-latency" quoteTitle="true" target=
</abstract> "https://tools.ietf.org/html/draft-arkko-arch-low-latency-02" derivedAnchor="LOW
</front> -LATENCY">
<front>
<seriesInfo name="RFC" value="2782" /> <title>Low Latency Applications and the Internet Architecture</title
>
<seriesInfo name="DOI" value="10.17487/RFC2782" /> <author initials="J" surname="Arkko" fullname="Jari Arkko">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="RFC4279" <author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
target="https://www.rfc-editor.org/info/rfc4279"> <organization showOnFrontPage="true"/>
<front> </author>
<title>Pre-Shared Key Ciphersuites for Transport Layer Security <date month="October" day="30" year="2017"/>
(TLS)</title> <abstract>
<t>Some recent Internet technology developments relate to improvem
<author fullname="P. Eronen" initials="P." role="editor" ents in communications latency. For instance, improvements in radio communicati
surname="Eronen"> ons or the recent work in IETF transport, security, and web protocols. There ar
<organization></organization> e also potential applications where latency would play a more significant role t
</author> han it has traditionally been in the Internet communications. Modern networking
systems offer many tools for building low-latency networks, from highly optimis
<author fullname="H. Tschofenig" initials="H." role="editor" ed individual protocol components to software controlled, virtualised and tailor
surname="Tschofenig"> ed network functions. This memo views the developments from a system viewpoint,
<organization></organization> and considers the potential future stresses that the strive for low-latency sup
</author> port for applications may bring.</t>
</abstract>
<date month="December" year="2005" /> </front>
<seriesInfo name="Internet-Draft" value="draft-arkko-arch-low-latency-
<abstract> 02"/>
<t>This document specifies three sets of new ciphersuites for the <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-a
Transport Layer Security (TLS) protocol to support authentication rkko-arch-low-latency-02.txt"/>
based on pre-shared keys (PSKs). These pre-shared keys are <refcontent>Work in Progress</refcontent>
symmetric keys, shared in advance among the communicating parties. </reference>
The first set of ciphersuites uses only symmetric key operations <reference anchor="I-D.boucadair-mptcp-plain-mode" quoteTitle="true" tar
for authentication. The second set uses a Diffie-Hellman exchange get="https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10" derivedAnc
authenticated with a pre-shared key, and the third set combines hor="MPTCP-PLAIN">
public key authentication of the server with pre-shared key <front>
authentication of the client. [STANDARDS-TRACK]</t> <title>Extensions for Network-Assisted MPTCP Deployment Models</titl
</abstract> e>
</front> <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair
">
<seriesInfo name="RFC" value="4279" /> <organization showOnFrontPage="true"/>
</author>
<seriesInfo name="DOI" value="10.17487/RFC4279" /> <author initials="C" surname="Jacquenet" fullname="Christian Jacquen
</reference> et">
<organization showOnFrontPage="true"/>
<reference anchor="RFC7250" </author>
target="https://www.rfc-editor.org/info/rfc7250"> <author initials="O" surname="Bonaventure" fullname="Olivier Bonaven
<front> ture">
<title>Using Raw Public Keys in Transport Layer Security (TLS) and <organization showOnFrontPage="true"/>
Datagram Transport Layer Security (DTLS)</title> </author>
<author initials="D" surname="Behaghel" fullname="Denis Behaghel">
<author fullname="P. Wouters" initials="P." role="editor" <organization showOnFrontPage="true"/>
surname="Wouters"> </author>
<organization></organization> <author initials="S" surname="Secci" fullname="Stefano Secci">
</author> <organization showOnFrontPage="true"/>
</author>
<author fullname="H. Tschofenig" initials="H." role="editor" <author initials="W" surname="Henderickx" fullname="Wim Henderickx">
surname="Tschofenig"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <author initials="R" surname="Skog" fullname="Robert Skog">
<organization showOnFrontPage="true"/>
<author fullname="J. Gilmore" initials="J." surname="Gilmore"> </author>
<organization></organization> <author initials="S" surname="Vinapamula" fullname="Suresh Vinapamul
</author> a">
<organization showOnFrontPage="true"/>
<author fullname="S. Weiler" initials="S." surname="Weiler"> </author>
<organization></organization> <author initials="S" surname="Seo" fullname="SungHoon Seo">
</author> <organization showOnFrontPage="true"/>
</author>
<author fullname="T. Kivinen" initials="T." surname="Kivinen"> <author initials="W" surname="Cloetens" fullname="Wouter Cloetens">
<organization></organization> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="U" surname="Meyer" fullname="Ullrich Meyer">
<date month="June" year="2014" /> <organization showOnFrontPage="true"/>
</author>
<abstract> <author initials="L" surname="Contreras" fullname="Luis Contreras">
<t>This document specifies a new certificate type and two TLS <organization showOnFrontPage="true"/>
extensions for exchanging raw public keys in Transport Layer </author>
Security (TLS) and Datagram Transport Layer Security (DTLS). The <author initials="B" surname="Peirens" fullname="Bart Peirens">
new certificate type allows raw public keys to be used for <organization showOnFrontPage="true"/>
authentication.</t> </author>
</abstract> <date month="March" year="2017"/>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-boucadair-mptcp-plain-m
<seriesInfo name="RFC" value="7250" /> ode-10"/>
<refcontent>Work in Progress</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC7250" /> </reference>
</reference> <reference anchor="I-D.peirens-mptcp-transparent" quoteTitle="true" targ
et="https://tools.ietf.org/html/draft-peirens-mptcp-transparent-00" derivedAncho
<reference anchor="RFC1812" r="MPTCP-TRANSPARENT">
target="https://www.rfc-editor.org/info/rfc1812"> <front>
<front> <title>Link bonding with transparent Multipath TCP</title>
<title>Requirements for IP Version 4 Routers</title> <author initials="B" surname="Peirens" fullname="Bart Peirens">
<organization showOnFrontPage="true"/>
<author fullname="F. Baker" initials="F." role="editor" </author>
surname="Baker"> <author initials="G" surname="Detal" fullname="Gregory Detal">
<organization></organization> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="S" surname="Barre" fullname="Sebastien Barre">
<date month="June" year="1995" /> <organization showOnFrontPage="true"/>
</author>
<abstract> <author initials="O" surname="Bonaventure" fullname="Olivier Bonaven
<t>This memo defines and discusses requirements for devices that ture">
perform the network layer forwarding function of the Internet <organization showOnFrontPage="true"/>
protocol suite. [STANDARDS-TRACK]</t> </author>
</abstract> <date month="July" day="8" year="2016"/>
</front> <abstract>
<t>This document describes the utilisation of the transparent Mult
<seriesInfo name="RFC" value="1812" /> ipath TCP mode to enable network operators to provide link bonding services in h
ybrid access networks.</t>
<seriesInfo name="DOI" value="10.17487/RFC1812" /> </abstract>
</reference> </front>
<seriesInfo name="Internet-Draft" value="draft-peirens-mptcp-transpare
<reference anchor="RFC1919" nt-00"/>
target="https://www.rfc-editor.org/info/rfc1919"> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-p
<front> eirens-mptcp-transparent-00.txt"/>
<title>Classical versus Transparent IP Proxies</title> <refcontent>Work in Progress</refcontent>
</reference>
<author fullname="M. Chatel" initials="M." surname="Chatel"> <reference anchor="RFC1812" target="https://www.rfc-editor.org/info/rfc1
<organization></organization> 812" quoteTitle="true" derivedAnchor="RFC1812">
</author> <front>
<title>Requirements for IP Version 4 Routers</title>
<date month="March" year="1996" /> <author initials="F." surname="Baker" fullname="F. Baker" role="edit
or">
<abstract> <organization showOnFrontPage="true"/>
<t>This document explains "classical" and "transparent" proxy </author>
techniques and attempts to provide rules to help determine when <date year="1995" month="June"/>
each proxy system may be used without causing problems. This memo <abstract>
provides information for the Internet community. This memo does <t>This memo defines and discusses requirements for devices that p
not specify an Internet standard of any kind.</t> erform the network layer forwarding function of the Internet protocol suite. [ST
</abstract> ANDARDS-TRACK]</t>
</front> </abstract>
</front>
<seriesInfo name="RFC" value="1919" /> <seriesInfo name="RFC" value="1812"/>
<seriesInfo name="DOI" value="10.17487/RFC1812"/>
<seriesInfo name="DOI" value="10.17487/RFC1919" /> </reference>
</reference> <reference anchor="RFC1919" target="https://www.rfc-editor.org/info/rfc1
919" quoteTitle="true" derivedAnchor="RFC1919">
<reference anchor="RFC1928" <front>
target="https://www.rfc-editor.org/info/rfc1928"> <title>Classical versus Transparent IP Proxies</title>
<front> <author initials="M." surname="Chatel" fullname="M. Chatel">
<title>SOCKS Protocol Version 5</title> <organization showOnFrontPage="true"/>
</author>
<author fullname="M. Leech" initials="M." surname="Leech"> <date year="1996" month="March"/>
<organization></organization> <abstract>
</author> <t>This document explains "classical" and "transparent" proxy tech
niques and attempts to provide rules to help determine when each proxy system ma
<author fullname="M. Ganis" initials="M." surname="Ganis"> y be used without causing problems. This memo provides information for the Inte
<organization></organization> rnet community. This memo does not specify an Internet standard of any kind.</t
</author> >
</abstract>
<author fullname="Y. Lee" initials="Y." surname="Lee"> </front>
<organization></organization> <seriesInfo name="RFC" value="1919"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC1919"/>
</reference>
<author fullname="R. Kuris" initials="R." surname="Kuris"> <reference anchor="RFC1928" target="https://www.rfc-editor.org/info/rfc1
<organization></organization> 928" quoteTitle="true" derivedAnchor="RFC1928">
</author> <front>
<title>SOCKS Protocol Version 5</title>
<author fullname="D. Koblas" initials="D." surname="Koblas"> <author initials="M." surname="Leech" fullname="M. Leech">
<organization></organization> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M." surname="Ganis" fullname="M. Ganis">
<author fullname="L. Jones" initials="L." surname="Jones"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <author initials="Y." surname="Lee" fullname="Y. Lee">
<organization showOnFrontPage="true"/>
<date month="March" year="1996" /> </author>
<author initials="R." surname="Kuris" fullname="R. Kuris">
<abstract> <organization showOnFrontPage="true"/>
<t>This memo describes a protocol that is an evolution of the </author>
previous version of the protocol, version 4 [1]. This new protocol <author initials="D." surname="Koblas" fullname="D. Koblas">
stems from active discussions and prototype implementations. <organization showOnFrontPage="true"/>
[STANDARDS-TRACK]</t> </author>
</abstract> <author initials="L." surname="Jones" fullname="L. Jones">
</front> <organization showOnFrontPage="true"/>
</author>
<seriesInfo name="RFC" value="1928" /> <date year="1996" month="March"/>
<abstract>
<seriesInfo name="DOI" value="10.17487/RFC1928" /> <t>This memo describes a protocol that is an evolution of the prev
</reference> ious version of the protocol, version 4 [1]. This new protocol stems from active
discussions and prototype implementations. [STANDARDS-TRACK]</t>
<reference anchor="RFC3135" </abstract>
target="https://www.rfc-editor.org/info/rfc3135"> </front>
<front> <seriesInfo name="RFC" value="1928"/>
<title>Performance Enhancing Proxies Intended to Mitigate <seriesInfo name="DOI" value="10.17487/RFC1928"/>
Link-Related Degradations</title> </reference>
<reference anchor="RFC2782" target="https://www.rfc-editor.org/info/rfc2
<author fullname="J. Border" initials="J." surname="Border"> 782" quoteTitle="true" derivedAnchor="RFC2782">
<organization></organization> <front>
</author> <title>A DNS RR for specifying the location of services (DNS SRV)</t
itle>
<author fullname="M. Kojo" initials="M." surname="Kojo"> <author initials="A." surname="Gulbrandsen" fullname="A. Gulbrandsen
<organization></organization> ">
</author> <organization showOnFrontPage="true"/>
</author>
<author fullname="J. Griner" initials="J." surname="Griner"> <author initials="P." surname="Vixie" fullname="P. Vixie">
<organization></organization> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="L." surname="Esibov" fullname="L. Esibov">
<author fullname="G. Montenegro" initials="G." surname="Montenegro"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <date year="2000" month="February"/>
<abstract>
<author fullname="Z. Shelby" initials="Z." surname="Shelby"> <t>This document describes a DNS RR which specifies the location o
<organization></organization> f the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t>
</author> </abstract>
</front>
<date month="June" year="2001" /> <seriesInfo name="RFC" value="2782"/>
<seriesInfo name="DOI" value="10.17487/RFC2782"/>
<abstract> </reference>
<t>This document is a survey of Performance Enhancing Proxies <reference anchor="RFC3135" target="https://www.rfc-editor.org/info/rfc3
(PEPs) often employed to improve degraded TCP performance caused 135" quoteTitle="true" derivedAnchor="RFC3135">
by characteristics of specific link environments, for example, in <front>
satellite, wireless WAN, and wireless LAN environments. This memo <title>Performance Enhancing Proxies Intended to Mitigate Link-Relat
provides information for the Internet community.</t> ed Degradations</title>
</abstract> <author initials="J." surname="Border" fullname="J. Border">
</front> <organization showOnFrontPage="true"/>
</author>
<seriesInfo name="RFC" value="3135" /> <author initials="M." surname="Kojo" fullname="M. Kojo">
<organization showOnFrontPage="true"/>
<seriesInfo name="DOI" value="10.17487/RFC3135" /> </author>
</reference> <author initials="J." surname="Griner" fullname="J. Griner">
<organization showOnFrontPage="true"/>
<reference anchor="RFC7414" </author>
target="https://www.rfc-editor.org/info/rfc7414"> <author initials="G." surname="Montenegro" fullname="G. Montenegro">
<front> <organization showOnFrontPage="true"/>
<title>A Roadmap for Transmission Control Protocol (TCP) </author>
Specification Documents</title> <author initials="Z." surname="Shelby" fullname="Z. Shelby">
<organization showOnFrontPage="true"/>
<author fullname="M. Duke" initials="M." surname="Duke"> </author>
<organization></organization> <date year="2001" month="June"/>
</author> <abstract>
<t>This document is a survey of Performance Enhancing Proxies (PEP
<author fullname="R. Braden" initials="R." surname="Braden"> s) often employed to improve degraded TCP performance caused by characteristics
<organization></organization> of specific link environments, for example, in satellite, wireless WAN, and wire
</author> less LAN environments. This memo provides information for the Internet communit
y.</t>
<author fullname="W. Eddy" initials="W." surname="Eddy"> </abstract>
<organization></organization> </front>
</author> <seriesInfo name="RFC" value="3135"/>
<seriesInfo name="DOI" value="10.17487/RFC3135"/>
<author fullname="E. Blanton" initials="E." surname="Blanton"> </reference>
<organization></organization> <reference anchor="RFC4279" target="https://www.rfc-editor.org/info/rfc4
</author> 279" quoteTitle="true" derivedAnchor="RFC4279">
<front>
<author fullname="A. Zimmermann" initials="A." surname="Zimmermann"> <title>Pre-Shared Key Ciphersuites for Transport Layer Security (TLS
<organization></organization> )</title>
</author> <author initials="P." surname="Eronen" fullname="P. Eronen" role="ed
itor">
<date month="February" year="2015" /> <organization showOnFrontPage="true"/>
</author>
<abstract> <author initials="H." surname="Tschofenig" fullname="H. Tschofenig"
<t>This document contains a roadmap to the Request for Comments role="editor">
(RFC) documents relating to the Internet's Transmission Control <organization showOnFrontPage="true"/>
Protocol (TCP). This roadmap provides a brief summary of the </author>
documents defining TCP and various TCP extensions that have <date year="2005" month="December"/>
accumulated in the RFC series. This serves as a guide and quick <abstract>
reference for both TCP implementers and other parties who desire <t>This document specifies three sets of new ciphersuites for the
information contained in the TCP-related RFCs.</t> Transport Layer Security (TLS) protocol to support authentication based on pre-s
hared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance
<t>This document obsoletes RFC 4614.</t> among the communicating parties. The first set of ciphersuites uses only symmet
</abstract> ric key operations for authentication. The second set uses a Diffie-Hellman exch
</front> ange 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.
<seriesInfo name="RFC" value="7414" /> [STANDARDS-TRACK]</t>
</abstract>
<seriesInfo name="DOI" value="10.17487/RFC7414" /> </front>
</reference> <seriesInfo name="RFC" value="4279"/>
<seriesInfo name="DOI" value="10.17487/RFC4279"/>
<reference anchor="RFC6887" </reference>
target="https://www.rfc-editor.org/info/rfc6887"> <reference anchor="RFC5461" target="https://www.rfc-editor.org/info/rfc5
<front> 461" quoteTitle="true" derivedAnchor="RFC5461">
<title>Port Control Protocol (PCP)</title> <front>
<title>TCP's Reaction to Soft Errors</title>
<author fullname="D. Wing" initials="D." role="editor" <author initials="F." surname="Gont" fullname="F. Gont">
surname="Wing"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <date year="2009" month="February"/>
<abstract>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"> <t>This document describes a non-standard, but widely implemented,
<organization></organization> modification to TCP's handling of ICMP soft error messages that rejects pending
</author> connection-requests when those error messages are received. This behavior redu
ces the likelihood of long delays between connection-establishment attempts that
<author fullname="M. Boucadair" initials="M." surname="Boucadair"> may arise in a number of scenarios, including one in which dual-stack nodes tha
<organization></organization> t have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 envir
</author> onments. This memo provides information for the Internet community.</t>
</abstract>
<author fullname="R. Penno" initials="R." surname="Penno"> </front>
<organization></organization> <seriesInfo name="RFC" value="5461"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC5461"/>
</reference>
<author fullname="P. Selkirk" initials="P." surname="Selkirk"> <reference anchor="RFC6269" target="https://www.rfc-editor.org/info/rfc6
<organization></organization> 269" quoteTitle="true" derivedAnchor="RFC6269">
</author> <front>
<title>Issues with IP Address Sharing</title>
<date month="April" year="2013" /> <author initials="M." surname="Ford" fullname="M. Ford" role="editor
">
<abstract> <organization showOnFrontPage="true"/>
<t>The Port Control Protocol allows an IPv6 or IPv4 host to </author>
control how incoming IPv6 or IPv4 packets are translated and <author initials="M." surname="Boucadair" fullname="M. Boucadair">
forwarded by a Network Address Translator (NAT) or simple <organization showOnFrontPage="true"/>
firewall, and also allows a host to optimize its outgoing NAT </author>
keepalive messages.</t> <author initials="A." surname="Durand" fullname="A. Durand">
</abstract> <organization showOnFrontPage="true"/>
</front> </author>
<author initials="P." surname="Levis" fullname="P. Levis">
<seriesInfo name="RFC" value="6887" /> <organization showOnFrontPage="true"/>
</author>
<seriesInfo name="DOI" value="10.17487/RFC6887" /> <author initials="P." surname="Roberts" fullname="P. Roberts">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="RFC6928" <date year="2011" month="June"/>
target="https://www.rfc-editor.org/info/rfc6928"> <abstract>
<front> <t>The completion of IPv4 address allocations from IANA and the Re
<title>Increasing TCP's Initial Window</title> gional Internet Registries (RIRs) is causing service providers around the world
to question how they will continue providing IPv4 connectivity service to their
<author fullname="J. Chu" initials="J." surname="Chu"> subscribers when there are no longer sufficient IPv4 addresses to allocate them
<organization></organization> one per subscriber. Several possible solutions to this problem are now emerging
</author> 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 sh
<author fullname="N. Dukkipati" initials="N." surname="Dukkipati"> aring approaches. Such issues include application failures, additional service
<organization></organization> monitoring complexity, new security vulnerabilities, and so on. Solution-specif
</author> ic discussions are out of scope.</t>
<t>Deploying IPv6 is the only perennial way to ease pressure on th
<author fullname="Y. Cheng" initials="Y." surname="Cheng"> e public IPv4 address pool without the need for address sharing mechanisms that
<organization></organization> give rise to the issues identified herein. This document is not an Internet St
</author> andards Track specification; it is published for informational purposes.</t>
</abstract>
<author fullname="M. Mathis" initials="M." surname="Mathis"> </front>
<organization></organization> <seriesInfo name="RFC" value="6269"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC6269"/>
</reference>
<date month="April" year="2013" /> <reference anchor="RFC6296" target="https://www.rfc-editor.org/info/rfc6
296" quoteTitle="true" derivedAnchor="RFC6296">
<abstract> <front>
<t>This document proposes an experiment to increase the permitted <title>IPv6-to-IPv6 Network Prefix Translation</title>
TCP initial window (IW) from between 2 and 4 segments, as <author initials="M." surname="Wasserman" fullname="M. Wasserman">
specified in RFC 3390, to 10 segments with a fallback to the <organization showOnFrontPage="true"/>
existing recommendation when performance issues are detected. It </author>
discusses the motivation behind the increase, the advantages and <author initials="F." surname="Baker" fullname="F. Baker">
disadvantages of the higher initial window, and presents results <organization showOnFrontPage="true"/>
from several large-scale experiments showing that the higher </author>
initial window improves the overall performance of many web <date year="2011" month="June"/>
services without resulting in a congestion collapse. The document <abstract>
closes with a discussion of usage and deployment for further <t>This document describes a stateless, transport-agnostic IPv6-to
experimental purposes recommended by the IETF TCP Maintenance and -IPv6 Network Prefix Translation (NPTv6) function that provides the address-inde
Minor Extensions (TCPM) working group.</t> pendence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 re
</abstract> lationship between addresses in the "inside" and "outside" prefixes, preserving
</front> end-to-end reachability at the network layer. This document defines an Experime
ntal Protocol for the Internet community.</t>
<seriesInfo name="RFC" value="6928" /> </abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC6928" /> <seriesInfo name="RFC" value="6296"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC6296"/>
</reference>
<reference anchor="RFC8041" <reference anchor="RFC6731" target="https://www.rfc-editor.org/info/rfc6
target="https://www.rfc-editor.org/info/rfc8041"> 731" quoteTitle="true" derivedAnchor="RFC6731">
<front> <front>
<title>Use Cases and Operational Experience with Multipath <title>Improved Recursive DNS Server Selection for Multi-Interfaced
TCP</title> Nodes</title>
<author initials="T." surname="Savolainen" fullname="T. Savolainen">
<author fullname="O. Bonaventure" initials="O." <organization showOnFrontPage="true"/>
surname="Bonaventure"> </author>
<organization></organization> <author initials="J." surname="Kato" fullname="J. Kato">
</author> <organization showOnFrontPage="true"/>
</author>
<author fullname="C. Paasch" initials="C." surname="Paasch"> <author initials="T." surname="Lemon" fullname="T. Lemon">
<organization></organization> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2012" month="December"/>
<author fullname="G. Detal" initials="G." surname="Detal"> <abstract>
<organization></organization> <t>A multi-interfaced node is connected to multiple networks, some
</author> of which might be utilizing private DNS namespaces. A node commonly receives r
ecursive DNS server configuration information from all connected networks. Some
<date month="January" year="2017" /> of the recursive DNS servers might have information about namespaces other serv
ers do not have. When a multi-interfaced node needs to utilize DNS, the node ha
<abstract> s to choose which of the recursive DNS servers to use. This document describes
<t>This document discusses both use cases and operational DHCPv4 and DHCPv6 options that can be used to configure nodes with information r
experience with Multipath TCP (MPTCP) in real networks. It lists equired to perform informed recursive DNS server selection decisions. [STANDARD
several prominent use cases where Multipath TCP has been S-TRACK]</t>
considered and is being used. It also gives insight to some </abstract>
heuristics and decisions that have helped to realize these use </front>
cases and suggests possible improvements.</t> <seriesInfo name="RFC" value="6731"/>
</abstract> <seriesInfo name="DOI" value="10.17487/RFC6731"/>
</front> </reference>
<reference anchor="RFC6887" target="https://www.rfc-editor.org/info/rfc6
<seriesInfo name="RFC" value="8041" /> 887" quoteTitle="true" derivedAnchor="RFC6887">
<front>
<seriesInfo name="DOI" value="10.17487/RFC8041" /> <title>Port Control Protocol (PCP)</title>
</reference> <author initials="D." surname="Wing" fullname="D. Wing" role="editor
">
<reference anchor="RFC8305" <organization showOnFrontPage="true"/>
target="https://www.rfc-editor.org/info/rfc8305"> </author>
<front> <author initials="S." surname="Cheshire" fullname="S. Cheshire">
<title>Happy Eyeballs Version 2: Better Connectivity Using <organization showOnFrontPage="true"/>
Concurrency</title> </author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<author fullname="D. Schinazi" initials="D." surname="Schinazi"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <author initials="R." surname="Penno" fullname="R. Penno">
<organization showOnFrontPage="true"/>
<author fullname="T. Pauly" initials="T." surname="Pauly"> </author>
<organization></organization> <author initials="P." surname="Selkirk" fullname="P. Selkirk">
</author> <organization showOnFrontPage="true"/>
</author>
<date month="December" year="2017" /> <date year="2013" month="April"/>
<abstract>
<abstract> <t>The Port Control Protocol allows an IPv6 or IPv4 host to contro
<t>Many communication protocols operating over the modern Internet l how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Ad
use hostnames. These often resolve to multiple IP addresses, each dress Translator (NAT) or simple firewall, and also allows a host to optimize it
of which may have different performance and connectivity s outgoing NAT keepalive messages.</t>
characteristics. Since specific addresses or address families </abstract>
(IPv4 or IPv6) may be blocked, broken, or sub-optimal on a </front>
network, clients that attempt multiple connections in parallel <seriesInfo name="RFC" value="6887"/>
have a chance of establishing a connection more quickly. This <seriesInfo name="DOI" value="10.17487/RFC6887"/>
document specifies requirements for algorithms that reduce this </reference>
user-visible delay and provides an example algorithm, referred to <reference anchor="RFC6928" target="https://www.rfc-editor.org/info/rfc6
as "Happy Eyeballs". This document obsoletes the original 928" quoteTitle="true" derivedAnchor="RFC6928">
algorithm description in RFC 6555.</t> <front>
</abstract> <title>Increasing TCP's Initial Window</title>
</front> <author initials="J." surname="Chu" fullname="J. Chu">
<organization showOnFrontPage="true"/>
<seriesInfo name="RFC" value="8305" /> </author>
<author initials="N." surname="Dukkipati" fullname="N. Dukkipati">
<seriesInfo name="DOI" value="10.17487/RFC8305" /> <organization showOnFrontPage="true"/>
</reference> </author>
<author initials="Y." surname="Cheng" fullname="Y. Cheng">
<reference anchor="RFC8446" <organization showOnFrontPage="true"/>
target="https://www.rfc-editor.org/info/rfc8446"> </author>
<front> <author initials="M." surname="Mathis" fullname="M. Mathis">
<title>The Transport Layer Security (TLS) Protocol Version <organization showOnFrontPage="true"/>
1.3</title> </author>
<date year="2013" month="April"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"> <abstract>
<organization></organization> <t>This document proposes an experiment to increase the permitted
</author> 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
<date month="August" year="2018" /> issues are detected. It discusses the motivation behind the increase, the advan
tages and disadvantages of the higher initial window, and presents results from
<abstract> several large-scale experiments showing that the higher initial window improves
<t>This document specifies version 1.3 of the Transport Layer the overall performance of many web services without resulting in a congestion c
Security (TLS) protocol. TLS allows client/server applications to ollapse. The document closes with a discussion of usage and deployment for furt
communicate over the Internet in a way that is designed to prevent her experimental purposes recommended by the IETF TCP Maintenance and Minor Exte
eavesdropping, tampering, and message forgery.</t> nsions (TCPM) working group.</t>
</abstract>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs </front>
5077, 5246, and 6961. This document also specifies new <seriesInfo name="RFC" value="6928"/>
requirements for TLS 1.2 implementations.</t> <seriesInfo name="DOI" value="10.17487/RFC6928"/>
</abstract> </reference>
</front> <reference anchor="RFC6978" target="https://www.rfc-editor.org/info/rfc6
978" quoteTitle="true" derivedAnchor="RFC6978">
<seriesInfo name="RFC" value="8446" /> <front>
<title>A TCP Authentication Option Extension for NAT Traversal</titl
<seriesInfo name="DOI" value="10.17487/RFC8446" /> e>
</reference> <author initials="J." surname="Touch" fullname="J. Touch">
<organization showOnFrontPage="true"/>
<reference anchor="RFC6269" </author>
target="https://www.rfc-editor.org/info/rfc6269"> <date year="2013" month="July"/>
<front> <abstract>
<title>Issues with IP Address Sharing</title> <t>This document describes an extension to the TCP Authentication
Option (TCP-AO) to support its use over connections that pass through Network Ad
<author fullname="M. Ford" initials="M." role="editor" dress Translators and/or Network Address and Port Translators (NATs/NAPTs). Th
surname="Ford"> is extension changes the data used to compute traffic keys, but it does not alt
<organization></organization> er TCP-AO's packet processing or key generation algorithms.</t>
</author> </abstract>
</front>
<author fullname="M. Boucadair" initials="M." surname="Boucadair"> <seriesInfo name="RFC" value="6978"/>
<organization></organization> <seriesInfo name="DOI" value="10.17487/RFC6978"/>
</author> </reference>
<reference anchor="RFC7250" target="https://www.rfc-editor.org/info/rfc7
<author fullname="A. Durand" initials="A." surname="Durand"> 250" quoteTitle="true" derivedAnchor="RFC7250">
<organization></organization> <front>
</author> <title>Using Raw Public Keys in Transport Layer Security (TLS) and D
atagram Transport Layer Security (DTLS)</title>
<author fullname="P. Levis" initials="P." surname="Levis"> <author initials="P." surname="Wouters" fullname="P. Wouters" role="
<organization></organization> editor">
</author> <organization showOnFrontPage="true"/>
</author>
<author fullname="P. Roberts" initials="P." surname="Roberts"> <author initials="H." surname="Tschofenig" fullname="H. Tschofenig"
<organization></organization> role="editor">
</author> <organization showOnFrontPage="true"/>
</author>
<date month="June" year="2011" /> <author initials="J." surname="Gilmore" fullname="J. Gilmore">
<organization showOnFrontPage="true"/>
<abstract> </author>
<t>The completion of IPv4 address allocations from IANA and the <author initials="S." surname="Weiler" fullname="S. Weiler">
Regional Internet Registries (RIRs) is causing service providers <organization showOnFrontPage="true"/>
around the world to question how they will continue providing IPv4 </author>
connectivity service to their subscribers when there are no longer <author initials="T." surname="Kivinen" fullname="T. Kivinen">
sufficient IPv4 addresses to allocate them one per subscriber. <organization showOnFrontPage="true"/>
Several possible solutions to this problem are now emerging based </author>
around the idea of shared IPv4 addressing. These solutions give <date year="2014" month="June"/>
rise to a number of issues, and this memo identifies those common <abstract>
to all such address sharing approaches. Such issues include <t>This document specifies a new certificate type and two TLS exte
application failures, additional service monitoring complexity, nsions for exchanging raw public keys in Transport Layer Security (TLS) and Data
new security vulnerabilities, and so on. Solution-specific gram Transport Layer Security (DTLS). The new certificate type allows raw publi
discussions are out of scope.</t> c keys to be used for authentication.</t>
</abstract>
<t>Deploying IPv6 is the only perennial way to ease pressure on </front>
the public IPv4 address pool without the need for address sharing <seriesInfo name="RFC" value="7250"/>
mechanisms that give rise to the issues identified herein. This <seriesInfo name="DOI" value="10.17487/RFC7250"/>
document is not an Internet Standards Track specification; it is </reference>
published for informational purposes.</t> <reference anchor="RFC7414" target="https://www.rfc-editor.org/info/rfc7
</abstract> 414" quoteTitle="true" derivedAnchor="RFC7414">
</front> <front>
<title>A Roadmap for Transmission Control Protocol (TCP) Specificati
<seriesInfo name="RFC" value="6269" /> on Documents</title>
<author initials="M." surname="Duke" fullname="M. Duke">
<seriesInfo name="DOI" value="10.17487/RFC6269" /> <organization showOnFrontPage="true"/>
</reference> </author>
<author initials="R." surname="Braden" fullname="R. Braden">
<reference anchor="RFC6296" <organization showOnFrontPage="true"/>
target="https://www.rfc-editor.org/info/rfc6296"> </author>
<front> <author initials="W." surname="Eddy" fullname="W. Eddy">
<title>IPv6-to-IPv6 Network Prefix Translation</title> <organization showOnFrontPage="true"/>
</author>
<author fullname="M. Wasserman" initials="M." surname="Wasserman"> <author initials="E." surname="Blanton" fullname="E. Blanton">
<organization></organization> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="A." surname="Zimmermann" fullname="A. Zimmermann">
<author fullname="F. Baker" initials="F." surname="Baker"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <date year="2015" month="February"/>
<abstract>
<date month="June" year="2011" /> <t>This document contains a roadmap to the Request for Comments (R
FC) documents relating to the Internet's Transmission Control Protocol (TCP). T
<abstract> his roadmap provides a brief summary of the documents defining TCP and various T
<t>This document describes a stateless, transport-agnostic CP extensions that have accumulated in the RFC series. This serves as a guide a
IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that nd quick reference for both TCP implementers and other parties who desire inform
provides the address-independence benefit associated with ation contained in the TCP-related RFCs.</t>
IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between <t>This document obsoletes RFC 4614.</t>
addresses in the "inside" and "outside" prefixes, preserving </abstract>
end-to-end reachability at the network layer. This document </front>
defines an Experimental Protocol for the Internet community.</t> <seriesInfo name="RFC" value="7414"/>
</abstract> <seriesInfo name="DOI" value="10.17487/RFC7414"/>
</front> </reference>
<reference anchor="RFC8041" target="https://www.rfc-editor.org/info/rfc8
<seriesInfo name="RFC" value="6296" /> 041" quoteTitle="true" derivedAnchor="RFC8041">
<front>
<seriesInfo name="DOI" value="10.17487/RFC6296" /> <title>Use Cases and Operational Experience with Multipath TCP</titl
</reference> e>
<author initials="O." surname="Bonaventure" fullname="O. Bonaventure
<reference anchor="I-D.boucadair-tcpm-dhc-converter"> ">
<front> <organization showOnFrontPage="true"/>
<title>DHCP Options for 0-RTT TCP Converters</title> </author>
<author initials="C." surname="Paasch" fullname="C. Paasch">
<author fullname="Mohamed Boucadair" initials="M" <organization showOnFrontPage="true"/>
surname="Boucadair"> </author>
<organization></organization> <author initials="G." surname="Detal" fullname="G. Detal">
</author> <organization showOnFrontPage="true"/>
</author>
<author fullname="Christian Jacquenet" initials="C" <date year="2017" month="January"/>
surname="Jacquenet"> <abstract>
<organization></organization> <t>This document discusses both use cases and operational experien
</author> ce 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
<author fullname="Tirumaleswar Reddy.K" initials="T" insight to some heuristics and decisions that have helped to realize these use c
surname="Reddy.K"> ases and suggests possible improvements.</t>
<organization></organization> </abstract>
</author> </front>
<seriesInfo name="RFC" value="8041"/>
<date day="7" month="October" year="2019" /> <seriesInfo name="DOI" value="10.17487/RFC8041"/>
</reference>
<abstract> <reference anchor="RFC8305" target="https://www.rfc-editor.org/info/rfc8
<t>Because of the lack of important TCP extensions, e.g., 305" quoteTitle="true" derivedAnchor="RFC8305">
Multipath TCP support at the server side, some service providers <front>
now consider a network-assisted model that relies upon the <title>Happy Eyeballs Version 2: Better Connectivity Using Concurren
activation of a dedicated function called Transport Converters. cy</title>
For example, network-assisted Multipath TCP deployment models are <author initials="D." surname="Schinazi" fullname="D. Schinazi">
designed to facilitate the adoption of Multipath TCP for the <organization showOnFrontPage="true"/>
establishment of multi-path communications without making any </author>
assumption about the support of Multipath TCP by the remote <author initials="T." surname="Pauly" fullname="T. Pauly">
servers. Transport Converters located in the network are <organization showOnFrontPage="true"/>
responsible for establishing multi-path communications on behalf </author>
of endpoints, thereby taking advantage of Multipath TCP <date year="2017" month="December"/>
capabilities to achieve different goals that include (but are not <abstract>
limited to) optimization of resource usage (e.g., bandwidth <t>Many communication protocols operating over the modern Internet
aggregation), of resiliency (e.g., primary/backup communication use hostnames. These often resolve to multiple IP addresses, each of which may
paths), and traffic offload management. This document focuses on have different performance and connectivity characteristics. Since specific ad
the explicit deployment scheme where the identity of the Transport dresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optima
Converters is explicitly configured on connected hosts. This l on a network, clients that attempt multiple connections in parallel have a cha
document specifies DHCP (IPv4 and IPv6) options to configure hosts nce of establishing a connection more quickly. This document specifies requirem
with Converters parameters.</t> ents for algorithms that reduce this user-visible delay and provides an example
</abstract> algorithm, referred to as "Happy Eyeballs". This document obsoletes the origina
</front> l algorithm description in RFC 6555.</t>
</abstract>
<seriesInfo name="Internet-Draft" </front>
value="draft-boucadair-tcpm-dhc-converter-03" /> <seriesInfo name="RFC" value="8305"/>
<seriesInfo name="DOI" value="10.17487/RFC8305"/>
<format target="http://www.ietf.org/internet-drafts/draft-boucadair-tcpm </reference>
-dhc-converter-03.txt" <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
type="TXT" /> 446" quoteTitle="true" derivedAnchor="RFC8446">
</reference> <front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
<reference anchor="RFC8548" e>
target="https://www.rfc-editor.org/info/rfc8548"> <author initials="E." surname="Rescorla" fullname="E. Rescorla">
<front> <organization showOnFrontPage="true"/>
<title>Cryptographic Protection of TCP Streams (tcpcrypt)</title> </author>
<date year="2018" month="August"/>
<author fullname="A. Bittau" initials="A." surname="Bittau"> <abstract>
<organization></organization> <t>This document specifies version 1.3 of the Transport Layer Secu
</author> rity (TLS) protocol. TLS allows client/server applications to communicate over
the Internet in a way that is designed to prevent eavesdropping, tampering, and
<author fullname="D. Giffin" initials="D." surname="Giffin"> message forgery.</t>
<organization></organization> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
</author> 77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
mplementations.</t>
<author fullname="M. Handley" initials="M." surname="Handley"> </abstract>
<organization></organization> </front>
</author> <seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
<author fullname="D. Mazieres" initials="D." surname="Mazieres"> </reference>
<organization></organization> <reference anchor="RFC8548" target="https://www.rfc-editor.org/info/rfc8
</author> 548" quoteTitle="true" derivedAnchor="RFC8548">
<front>
<author fullname="Q. Slack" initials="Q." surname="Slack"> <title>Cryptographic Protection of TCP Streams (tcpcrypt)</title>
<organization></organization> <author initials="A." surname="Bittau" fullname="A. Bittau">
</author> <organization showOnFrontPage="true"/>
</author>
<author fullname="E. Smith" initials="E." surname="Smith"> <author initials="D." surname="Giffin" fullname="D. Giffin">
<organization></organization> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M." surname="Handley" fullname="M. Handley">
<date month="May" year="2019" /> <organization showOnFrontPage="true"/>
</author>
<abstract> <author initials="D." surname="Mazieres" fullname="D. Mazieres">
<t>This document specifies "tcpcrypt", a TCP encryption protocol <organization showOnFrontPage="true"/>
designed for use in conjunction with the TCP Encryption </author>
Negotiation Option (TCP-ENO). Tcpcrypt coexists with middleboxes <author initials="Q." surname="Slack" fullname="Q. Slack">
by tolerating resegmentation, NATs, and other manipulations of the <organization showOnFrontPage="true"/>
TCP header. The protocol is self-contained and specifically </author>
tailored to TCP implementations, which often reside in kernels or <author initials="E." surname="Smith" fullname="E. Smith">
other environments in which large external software dependencies <organization showOnFrontPage="true"/>
can be undesirable. Because the size of TCP options is limited, </author>
the protocol requires one additional one-way message latency to <date year="2019" month="May"/>
perform key exchange before application data can be transmitted. <abstract>
However, the extra latency can be avoided between two hosts that <t>This document specifies "tcpcrypt", a TCP encryption protocol d
have recently established a previous tcpcrypt connection.</t> esigned for use in conjunction with the TCP Encryption Negotiation Option (TCP-E
</abstract> NO). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and
</front> other manipulations of the TCP header. The protocol is self-contained and spec
ifically tailored to TCP implementations, which often reside in kernels or other
<seriesInfo name="RFC" value="8548" /> environments in which large external software dependencies can be undesirable.
Because the size of TCP options is limited, the protocol requires one additional
<seriesInfo name="DOI" value="10.17487/RFC8548" /> one-way message latency to perform key exchange before application data can be
</reference> transmitted. However, the extra latency can be avoided between two hosts that h
ave recently established a previous tcpcrypt connection.</t>
<reference anchor="I-D.olteanu-intarea-socks-6"> </abstract>
<front> </front>
<title>SOCKS Protocol Version 6</title> <seriesInfo name="RFC" value="8548"/>
<seriesInfo name="DOI" value="10.17487/RFC8548"/>
<author fullname="Vladimir Olteanu" initials="V" surname="Olteanu"> </reference>
<organization></organization> <reference anchor="I-D.boucadair-opsawg-tcpm-converter" quoteTitle="true
</author> " target="https://tools.ietf.org/html/draft-boucadair-opsawg-tcpm-converter-01"
derivedAnchor="TCPM-CONVERTER">
<author fullname="Dragos Niculescu" initials="D" surname="Niculescu"> <front>
<organization></organization> <title>RADIUS Extensions for 0-RTT TCP Converters</title>
</author> <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair
">
<date day="4" month="November" year="2019" /> <organization showOnFrontPage="true"/>
</author>
<abstract> <author initials="C" surname="Jacquenet" fullname="Christian Jacquen
<t>The SOCKS protocol is used primarily to proxy TCP connections et">
to arbitrary destinations via the use of a proxy server. Under the <organization showOnFrontPage="true"/>
latest version of the protocol (version 5), it takes 2 RTTs (or 3, </author>
if authentication is used) before data can flow between the client <date month="February" day="28" year="2020"/>
and the server. This memo proposes SOCKS version 6, which reduces <abstract>
the number of RTTs used, takes full advantage of TCP Fast Open, <t>Because of the lack of important TCP extensions, e.g., Multipat
and adds support for 0-RTT authentication.</t> h TCP support at the server side, some service providers now consider a network-
</abstract> assisted model that relies upon the activation of a dedicated function called Tr
</front> ansport Converters. For example, network-assisted Multipath TCP deployment mode
ls are designed to facilitate the adoption of Multipath TCP for the establishmen
<seriesInfo name="Internet-Draft" t of multi-path communications without making any assumption about the support o
value="draft-olteanu-intarea-socks-6-08" /> f Multipath TCP by the remote servers. Transport Converters located in the netw
ork are responsible for establishing multi-path communications on behalf of endp
<format target="http://www.ietf.org/internet-drafts/draft-olteanu-intare oints, thereby taking advantage of Multipath TCP capabilities to achieve differe
a-socks-6-08.txt" nt goals that include (but are not limited to) optimization of resource usage (e
type="TXT" /> .g., bandwidth aggregation), of resiliency (e.g., primary/backup communication p
</reference> aths), and traffic offload management. This document specifies a new Remote Aut
hentication Dial-In User Service (RADIUS) attributes that carry the IP addresses
<reference anchor="I-D.boucadair-mptcp-plain-mode"> that will be returned to authorized users to reach one or multiple Converters.<
<front> /t>
<title>Extensions for Network-Assisted MPTCP Deployment </abstract>
Models</title> </front>
<seriesInfo name="Internet-Draft" value="draft-boucadair-opsawg-tcpm-c
<author fullname="Mohamed Boucadair" initials="M" onverter-01"/>
surname="Boucadair"> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-b
<organization></organization> oucadair-opsawg-tcpm-converter-01.txt"/>
</author> <refcontent>Work in Progress</refcontent>
</reference>
<author fullname="Christian Jacquenet" initials="C" <reference anchor="TS23501" target="https://www.3gpp.org/ftp/Specs/archi
surname="Jacquenet"> ve/23_series/23.501/" quoteTitle="true" derivedAnchor="TS23501">
<organization></organization> <front>
</author> <title>Technical Specification Group Services and System Aspects; Sy
stem architecture for the 5G System; Stage 2 (Release 16)</title>
<author fullname="Olivier Bonaventure" initials="O" <author>
surname="Bonaventure"> <organization showOnFrontPage="true">3GPP (3rd Generation Partners
<organization></organization> hip Project)</organization>
</author> </author>
<date year="2019"/>
<author fullname="Denis Behaghel" initials="D" surname="Behaghel"> </front>
<organization></organization> </reference>
</author> </references>
<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-mptc
p-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" />
<format target="http://www.ietf.org/internet-drafts/draft-arkko-arch-low
-latency-02.txt"
type="TXT" />
</reference>
<reference anchor="I-D.boucadair-radext-tcpm-converter">
<front>
<title>RADIUS Extensions 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>
<date day="15" month="April" year="2019" />
<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-rade
xt-tcpm-converter-02.txt"
type="TXT" />
</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 for the 5G System; Stage 2 (Release 16)</title>
<author initials="."
surname="3GPP (3rd Generation Partnership Project)">
<organization></organization>
</author>
<date 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>
</author>
<date year="2011" />
</front>
<seriesInfo name="Traffic Monitoring and Analysis. TMA 2011. Lecture Not
es in Computer Science, vol 6613."
value="" />
</reference>
<reference anchor="ANRW17">
<front>
<title>Tracking transport-layer evolution with PATHspider</title>
<author initials="B." surname="Trammell">
<organization></organization>
</author>
<author initials="M." surname="Kuehlewind">
<organization></organization>
</author>
<author initials="P." surname="De Vaere">
<organization></organization>
</author>
<author initials="I." surname="Learmonth">
<organization></organization>
</author>
<author initials="G." surname="Fairhurst">
<organization></organization>
</author>
<date month="July" year="2017" />
</front>
<seriesInfo name="Applied Networking Research Workshop 2017 (ANRW17)"
value="" />
</reference>
<reference anchor="IMC11">
<front>
<title>Is it still possible to extend TCP?</title>
<author initials="K." surname="Honda">
<organization></organization>
</author>
<author initials="Y." surname="Nishida">
<organization></organization>
</author>
<author initials="C." surname="Raiciu">
<organization></organization>
</author>
<author initials="A." surname="Greenhalgh">
<organization></organization>
</author>
<author initials="M." surname="Handley">
<organization></organization>
</author>
<author initials="T." surname="Hideyuki">
<organization></organization>
</author>
<date year="2011" />
</front>
<seriesInfo name="Proceedings of the 2011 ACM SIGCOMM conference on Inte
rnet measurement conference"
value="" />
</reference>
<reference anchor="IETFJ16">
<front>
<title>Multipath TCP Deployment</title>
<author initials="O." surname="Bonaventure">
<organization></organization>
</author>
<author initials="S." surname="Seo">
<organization></organization>
</author>
<date year="n.d." />
</front>
<seriesInfo name="IETF Journal, Fall 2016" value="" />
</reference>
<reference anchor="HotMiddlebox13b"
target="http://inl.info.ucl.ac.be/publications/multipath-middle
box">
<front>
<title>Multipath in the Middle(Box)</title>
<author initials="G." surname="Detal">
<organization></organization>
</author>
<author initials="C." surname="Paasch">
<organization></organization>
</author>
<author initials="O." surname="Bonaventure">
<organization></organization>
</author>
<date month="December" year="2013" />
</front>
<seriesInfo name="HotMiddlebox'13" value="" />
</reference>
</references> </references>
<section anchor="sec-api" numbered="true" toc="include" removeInRFC="false"
<section anchor="sec-api" pn="section-appendix.a">
title="Example Socket API Changes to Support the 0-RTT Convert Prot <name slugifiedName="name-example-socket-api-changes-">Example Socket API
ocol"> Changes to Support the 0-RTT TCP Convert Protocol</name>
<section anchor="active-open-client-side" <section anchor="active-open-client-side" numbered="true" toc="include" re
title="Active Open (Client Side)"> moveInRFC="false" pn="section-a.1">
<t>On the client side, the support of the 0-RTT Converter protocol <name slugifiedName="name-active-open-client-side">Active Open (Client S
does not require any other changes than those identified in Appendix A ide)</name>
of <xref target="RFC7413"></xref>. Those modifications are already <t pn="section-a.1-1">On the Client side, the support of the 0-RTT Conve
supported by multiple TCP stacks.</t> rter protocol
does not require any other changes than those identified in <xref target
<t>As an example, on Linux, a client can send the 0-RTT Convert ="RFC7413" sectionFormat="of" section="A" format="default" derivedLink="https://
rfc-editor.org/rfc/rfc7413#appendix-A" derivedContent="RFC7413"/>. Those modific
ations
are already supported by multiple TCP stacks.</t>
<t pn="section-a.1-2">As an example, on Linux, a Client can send the 0-R
TT Convert
message inside a SYN by using sendto with the MSG_FASTOPEN flag as message inside a SYN by using sendto with the MSG_FASTOPEN flag as
shown in the example below:</t> shown in the example below:</t>
<artwork name="" type="" align="left" alt="" pn="section-a.1-3">
<figure>
<artwork><![CDATA[
s = socket(AF_INET, SOCK_STREAM, 0); s = socket(AF_INET, SOCK_STREAM, 0);
sendto(s, buffer, buffer_len, MSG_FASTOPEN, sendto(s, buffer, buffer_len, MSG_FASTOPEN,
(struct sockaddr *) &server_addr, addr_len); (struct sockaddr *) &amp;server_addr, addr_len);
]]></artwork> </artwork>
</figure> <t pn="section-a.1-4">The Client side of the Linux TFO can be used in tw
o different
<t>The client side of the Linux TCP TFO can be used in two different
modes depending on the host configuration (sysctl tcp_fastopen modes depending on the host configuration (sysctl tcp_fastopen
variable):</t> variable):</t>
<dl newline="false" spacing="normal" pn="section-a.1-5">
<t><list style="symbols"> <dt pn="section-a.1-5.1">0x1:</dt>
<t>0x1: (client) enables sending data in the opening SYN on the <dd pn="section-a.1-5.2">(client) enables sending data in the opening
client.</t> SYN on the
Client.</dd>
<t>0x4: (client) send data in the opening SYN regardless of cookie <dt pn="section-a.1-5.3">0x4:</dt>
availability and without a cookie option.</t> <dd pn="section-a.1-5.4">(client) enables sending data in the opening
</list></t> SYN regardless of cookie
availability and without a cookie option.</dd>
<t>By setting this configuration variable to 0x5, a Linux client using </dl>
<t pn="section-a.1-6">By setting this configuration variable to 0x5, a L
inux Client using
the above code would send data inside the SYN without using a TFO the above code would send data inside the SYN without using a TFO
option.</t> option.</t>
</section> </section>
<section anchor="passive-open-converter-side" numbered="true" toc="include
<section anchor="passive-open-converter-side" " removeInRFC="false" pn="section-a.2">
title="Passive Open (Converter Side)"> <name slugifiedName="name-passive-open-converter-side">Passive Open (Con
<t>The Converter needs to enable the reception of data inside the SYN verter Side)</name>
<t pn="section-a.2-1">The Converter needs to enable the reception of dat
a inside the SYN
independently of the utilization of the TFO option. This implies that independently of the utilization of the TFO option. This implies that
the Transport Converter application cannot rely on the TFO cookies to the Transport Converter application cannot rely on the Fast Open Cookies to
validate the reachability of the IP address that sent the SYN. It must 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 rely on other techniques, such as the Cookie TLV described in this
document, to verify this reachability.</t> document, to verify this reachability.</t>
<t pn="section-a.2-2"><xref target="RFC7413" format="default" sectionFor
<t><xref target="RFC7413"></xref> suggested the utilization of a mat="of" derivedContent="RFC7413"/> suggested the utilization of a
TCP_FASTOPEN socket option the enable the reception of SYNs containing TCP_FASTOPEN socket option to enable the reception of SYNs containing
data. Later, Appendix A of <xref target="RFC7413"></xref>, data. Later, <xref target="RFC7413" sectionFormat="of" section="A" forma
t="default" derivedLink="https://rfc-editor.org/rfc/rfc7413#appendix-A" derivedC
ontent="RFC7413"/>
mentioned:</t> mentioned:</t>
<blockquote pn="section-a.2-3">
<figure>
<artwork><![CDATA[
Traditionally, accept() returns only after a socket is connected. Traditionally, accept() returns only after a socket is connected.
But, for a Fast Open connection, accept() returns upon receiving But, for a Fast Open connection, accept() returns upon receiving
SYN with a valid Fast Open cookie and data, and the data is available a SYN with a valid Fast Open cookie and data, and the data is
to be read through, e.g., recvmsg(), read(). available to be read through, e.g., recvmsg(), read().
]]></artwork> </blockquote>
</figure> <t pn="section-a.2-4">To support the 0-RTT TCP Convert Protocol, this be
havior should be
<t>To support the 0-RTT Convert Protocol, this behavior should be
modified as follows:</t> modified as follows:</t>
<blockquote pn="section-a.2-5">
<figure>
<artwork><![CDATA[
Traditionally, accept() returns only after a socket is connected. Traditionally, accept() returns only after a socket is connected.
But, for a Fast Open connection, accept() returns upon receiving a 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., SYN with data, and the data is available to be read through, e.g.,
recvmsg(), read(). The application that receives such SYNs with data recvmsg(), read(). The application that receives such SYNs with
must be able to validate the reachability of the source of the SYN data must be able to validate the reachability of the source of
and also deal with replayed SYNs. the SYN and also deal with replayed SYNs.
]]></artwork> </blockquote>
</figure> <t pn="section-a.2-6">The Linux Server side can be configured with the f
ollowing
<t>The Linux server side can be configured with the following
sysctls:</t> sysctls:</t>
<dl spacing="normal" newline="false" pn="section-a.2-7">
<t><list style="symbols"> <dt pn="section-a.2-7.1">0x2:</dt>
<t>0x2: (server) enables the server support, i.e., allowing data <dd pn="section-a.2-7.2">(server) enables the Server support, i.e., al
lowing data
in a SYN packet to be accepted and passed to the application in a SYN packet to be accepted and passed to the application
before 3-way handshake finishes.</t> before a 3-way handshake finishes.</dd>
<dt pn="section-a.2-7.3">0x200:</dt>
<t>0x200: (server) accept data-in-SYN w/o any cookie option <dd pn="section-a.2-7.4">(server) accepts data-in-SYN w/o any cookie o
present.</t> ption
</list></t> present.</dd>
</dl>
<t>However, this configuration is system-wide. This is convenient for <t pn="section-a.2-8">However, this configuration is system wide. This i
s convenient for
typical Transport Converter deployments where no other applications typical Transport Converter deployments where no other applications
relying on TFO are collocated on the same device.</t> relying on TFO are collocated on the same device.</t>
<t pn="section-a.2-9">Recently, the TCP_FASTOPEN_NO_COOKIE socket option
<t>Recently, the TCP_FASTOPEN_NO_COOKIE socket option has been added has been added
to provide the same behavior on a per socket basis. This enables a to provide the same behavior on a per-socket basis. This enables a
single host to support both servers that require the TFO cookie and single host to support both Servers that require the Fast Open Cookie an
servers that do not use it.</t> d
Servers that do not use it.</t>
</section> </section>
</section> </section>
<section anchor="acknowledgments" numbered="false" toc="include" removeInRFC
<section anchor="acknowledgments" numbered="no" title="Acknowledgments"> ="false" pn="section-appendix.b">
<t>Although they could disagree with the contents of the document, we <name slugifiedName="name-acknowledgments">Acknowledgments</name>
would like to thank Joe Touch and Juliusz Chroboczek whose comments on <t pn="section-appendix.b-1">Although they could disagree with the content
the MPTCP mailing list have forced us to reconsider the design of the s of the document, we
solution several times.</t> would like to thank <contact fullname="Joe Touch"/> and <contact fullname=
"Juliusz Chroboczek"/>, whose comments on the MPTCP mailing list have forc
<t>We would like to thank Raphael Bauduin, Stefano Secci, Anandatirtha ed us to
Nandugudi and Gregory Vander Schueren for their help in preparing this reconsider the design of the solution several times.</t>
document. Nandini Ganesh provided valuable feedback about the handling <t pn="section-appendix.b-2">We would like to thank <contact fullname="Rap
of TFO and the error codes. Yuchung Cheng and Praveen Balasubramanian hael Bauduin"/>,
helped to clarify the discussion on supplying data in SYNs. Phil Eardley <contact fullname="Stefano Secci"/>, <contact fullname="Anandatirtha
and Michael Scharf's helped to clarify different parts of the text. Nandugudi"/>, and <contact fullname="Gregory Vander Schueren"/> for their help
Thanks to Eric Vyncke, Roman Danyliw, Benjamin Kaduk, and Alexey in preparing this
Melnikov for the IESG review, and Christian Huitema for the security document. <contact fullname="Nandini Ganesh"/> provided valuable feedback
directorate review.</t> about the handling
of TFO and the error codes. <contact fullname="Yuchung Cheng"/> and
<t>Many thanks to Mirja Kuehlewind for the detailed AD review.</t> <contact fullname="Praveen Balasubramanian"/>
helped to clarify the discussion on supplying data in SYNs. <contact fulln
<t>This document builds upon earlier documents that proposed various ame="Phil Eardley"/>
forms of Multipath TCP proxies <xref and <contact fullname="Michael Scharf"/> helped to clarify different parts
target="I-D.boucadair-mptcp-plain-mode" />, <xref of the text.
target="I-D.peirens-mptcp-transparent" /> and <xref Thanks to <contact fullname="Éric Vyncke"/>, <contact fullname="Roman
target="HotMiddlebox13b" />.</t> Danyliw"/>, <contact fullname="Benjamin Kaduk"/>, and <contact fullname="Alexe
y Melnikov"/> for the IESG review, and <contact fullname="Christian Huitem
<t>From <xref target="I-D.boucadair-mptcp-plain-mode" />:</t> a"/> for the Security
Directorate review.</t>
<t>Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi <t pn="section-appendix.b-3">Many thanks to <contact fullname="Mirja Kühle
Nishida, and Christoph Paasch for their valuable comments.</t> wind"/> for the detailed AD review.</t>
<t pn="section-appendix.b-4">This document builds upon earlier documents t
<t>Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and hat proposed various
Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos forms of Multipath TCP proxies: <xref target="I-D.boucadair-mptcp-plain-mo
Aires).</t> de" format="default" sectionFormat="of" derivedContent="MPTCP-PLAIN"/>, <xref ta
rget="I-D.peirens-mptcp-transparent" format="default" sectionFormat="of" derived
<t>Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and Content="MPTCP-TRANSPARENT"/>, and <xref target="HOT-MIDDLEBOX13" format="defaul
Xavier Grall for their inputs.</t> t" sectionFormat="of" derivedContent="HOT-MIDDLEBOX13"/>.</t>
<t pn="section-appendix.b-5">From <xref target="I-D.boucadair-mptcp-plain-
<t>Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas mode" format="default" sectionFormat="of" derivedContent="MPTCP-PLAIN"/>:</t>
Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves <t pn="section-appendix.b-6">Many thanks to <contact fullname="Chi Dung Ph
Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun ung"/>, <contact fullname="Mingui Zhang"/>, <contact fullname="Rao Shoaib"/>, <c
Srinivasan, and Raghavendra Mallya for the discussion.</t> ontact fullname="Yoshifumi Nishida"/>, and <contact fullname="Christoph Pa
asch"/> for their valuable comments.</t>
<t pn="section-appendix.b-7">Thanks to <contact fullname="Ian Farrer"/>, <
contact fullname="Mikael Abrahamsson"/>, <contact fullname="Alan Ford"/>,
<contact fullname="Dan Wing"/>, and <contact fullname="Sri Gundavelli"/> f
or the fruitful
discussions at IETF 95 (Buenos Aires).</t>
<t pn="section-appendix.b-8">Special thanks to <contact fullname="Pierrick
Seite"/>, <contact fullname="Yannick Le Goff"/>, <contact fullname="Fred Klamm"
/>, and
<contact fullname="Xavier Grall"/> for their input.</t>
<t pn="section-appendix.b-9">Thanks also to <contact fullname="Olaf Schleu
sing"/>, <contact fullname="Martin Gysi"/>, <contact fullname="Thomas Zasowski"/
>,
<contact fullname="Andreas Burkhard"/>, <contact fullname="Silka Sim
men"/>, <contact fullname="Sandro Berger"/>, <contact fullname="Michael Melloul"
/>,
<contact fullname="Jean-Yves Flahaut"/>, <contact fullname="Adrien D
esportes"/>, <contact fullname="Gregory Detal"/>, <contact fullname="Benjamin Da
vid"/>,
<contact fullname="Arun Srinivasan"/>, and <contact fullname="Raghav
endra Mallya"/> for their input.</t>
</section> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f
<section anchor="contributors" numbered="no" title="Contributors"> alse" pn="section-appendix.c">
<t>Bart Peirens contributed to an early version of the document.</t> <name slugifiedName="name-contributors">Contributors</name>
<t pn="section-appendix.c-1"><contact fullname="Bart Peirens"/> contribute
<t>As noted above, this document builds on two previous documents.</t> d to an early draft version of this document.</t>
<t pn="section-appendix.c-2">As noted above, this document builds on two p
<t>The authors of <xref target="I-D.boucadair-mptcp-plain-mode" /> revious documents.</t>
<t pn="section-appendix.c-3">The authors of <xref target="I-D.boucadair-mp
tcp-plain-mode" format="default" sectionFormat="of" derivedContent="MPTCP-PLAIN"
/>
were:</t> were:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-appendix.c-4">
<t> <li pn="section-appendix.c-4.1">
<list style="symbols"> <t pn="section-appendix.c-4.1.1"><contact fullname="Mohamed Boucadair"
<t>Mohamed Boucadair</t> /></t>
</li>
<t>Christian Jacquenet</t> <li pn="section-appendix.c-4.2">
<t pn="section-appendix.c-4.2.1"><contact fullname="Christian Jacquene
<t>Olivier Bonaventure</t> t"/></t>
</li>
<t>Denis Behaghel</t> <li pn="section-appendix.c-4.3">
<t pn="section-appendix.c-4.3.1"><contact fullname="Olivier Bonaventur
<t>Stefano Secci</t> e"/></t>
</li>
<t>Wim Henderickx</t> <li pn="section-appendix.c-4.4">
<t pn="section-appendix.c-4.4.1"><contact fullname="Denis Behaghel"/><
<t>Robert Skog</t> /t>
</li>
<t>Suresh Vinapamula</t> <li pn="section-appendix.c-4.5">
<t pn="section-appendix.c-4.5.1"><contact fullname="Stefano Secci"/></
<t>SungHoon Seo</t> t>
</li>
<t>Wouter Cloetens</t> <li pn="section-appendix.c-4.6">
<t pn="section-appendix.c-4.6.1"><contact fullname="Wim Henderickx"/><
<t>Ullrich Meyer</t> /t>
</li>
<t>Luis M. Contreras</t> <li pn="section-appendix.c-4.7">
<t pn="section-appendix.c-4.7.1"><contact fullname="Robert Skog"/></t>
<t>Bart Peirens</t> </li>
</list> <li pn="section-appendix.c-4.8">
</t> <t pn="section-appendix.c-4.8.1"><contact fullname="Suresh Vinapamula"
/></t>
<t>The authors of <xref target="I-D.peirens-mptcp-transparent" /> </li>
<li pn="section-appendix.c-4.9">
<t pn="section-appendix.c-4.9.1"><contact fullname="SungHoon Seo"/></t
>
</li>
<li pn="section-appendix.c-4.10">
<t pn="section-appendix.c-4.10.1"><contact fullname="Wouter Cloetens"/
></t>
</li>
<li pn="section-appendix.c-4.11">
<t pn="section-appendix.c-4.11.1"><contact fullname="Ullrich Meyer"/><
/t>
</li>
<li pn="section-appendix.c-4.12">
<t pn="section-appendix.c-4.12.1"><contact fullname="Luis M. Contreras
"/></t>
</li>
<li pn="section-appendix.c-4.13">
<t pn="section-appendix.c-4.13.1"><contact fullname="Bart Peirens"/></
t>
</li>
</ul>
<t pn="section-appendix.c-5">The authors of <xref target="I-D.peirens-mptc
p-transparent" format="default" sectionFormat="of" derivedContent="MPTCP-TRANSPA
RENT"/>
were:</t> were:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-appendix.c-6">
<t> <li pn="section-appendix.c-6.1">
<list style="symbols"> <t pn="section-appendix.c-6.1.1"><contact fullname="Bart Peirens"/></t
<t>Bart Peirens</t> >
</li>
<t>Gregory Detal</t> <li pn="section-appendix.c-6.2">
<t pn="section-appendix.c-6.2.1"><contact fullname="Gregory Detal"/></
<t>Sebastien Barre</t> t>
</li>
<t>Olivier Bonaventure</t> <li pn="section-appendix.c-6.3">
</list> <t pn="section-appendix.c-6.3.1"><contact fullname="Sebastien Barre"/>
</t> </t>
</li>
<li pn="section-appendix.c-6.4">
<t pn="section-appendix.c-6.4.1"><contact fullname="Olivier Bonaventur
e"/></t>
</li>
</ul>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.d">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Olivier Bonaventure" initials="O." role="editor" surname
="Bonaventure">
<organization showOnFrontPage="true">Tessares</organization>
<address>
<postal>
<street>Avenue Jean Monnet 1</street>
<city>B-1348 Louvain-la-Neuve</city>
<region/>
<code/>
<country>Belgium</country>
</postal>
<email>Olivier.Bonaventure@tessares.net</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." role="editor" surname="
Boucadair">
<organization showOnFrontPage="true">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 showOnFrontPage="true">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 showOnFrontPage="true">Korea Telecom</organization>
<address>
<postal>
<street>151 Taebong-ro</street>
<city>Seocho-gu, Seoul, 06763</city>
<region/>
<code/>
<country>Republic of Korea</country>
</postal>
<email>sh.seo@kt.com</email>
</address>
</author>
<author fullname="Benjamin Hesmans" initials="B." surname="Hesmans">
<organization showOnFrontPage="true">Tessares</organization>
<address>
<postal>
<street>Avenue Jean Monnet 1</street>
<city>B-1348 Louvain-la-Neuve</city>
<region/>
<code/>
<country>Belgium</country>
</postal>
<email>Benjamin.Hesmans@tessares.net</email>
</address>
</author>
</section> </section>
</back> </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> </rfc>
 End of changes. 349 change blocks. 
3840 lines changed or deleted 3994 lines changed or added

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