Diff: rfc8803xml2.original.xml

	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" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
	<?rfc toc="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
	<?rfc sortrefs="yes"?>	category="exp" consensus="true" docName="draft-ietf-tcpm-converters-19"
	<?rfc symrefs="yes"?>	number="8803" ipr="trust200902" obsoletes="" updates="" xml:lang="en"
	<rfc category="exp" docName="draft-ietf-tcpm-converters-19" ipr="trust200902">	tocInclude="true" sortRefs="true" symRefs="true" version="3">

	<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"/>


	<author fullname="Olivier Bonaventure" initials="O." role="editor"	<author fullname="Olivier Bonaventure" initials="O." role="editor" surname="
	surname="Bonaventure">	Bonaventure">
	<organization>Tessares</organization>	<organization>Tessares</organization>


	<address>	<address>

		<postal>
		<street>Avenue Jean Monnet 1</street>
		<city>B-1348 Louvain-la-Neuve</city>
		<region></region>
		<code></code>
		<country>Belgium</country>
		</postal>
	<email>Olivier.Bonaventure@tessares.net</email>	<email>Olivier.Bonaventure@tessares.net</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Mohamed Boucadair" initials="M." role="editor"	<author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Bo
	surname="Boucadair">	ucadair">
	<organization>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>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>Korea Telecom</organization>


	<address>	<address>

		<postal>
		<street>151 Taebong-ro</street>
		<city>Seocho-gu, Seoul, 06763</city>
		<region></region>
		<code></code>
		<country>Republic of Korea</country>
		</postal>
	<email>sh.seo@kt.com</email>	<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>Tessares</organization>


	<address>	<address>

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


	<date day="21" month="March" year="2020" />	<date month="July" 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>	<abstract>
	<t>This document specifies an application proxy, called Transport	<t>This document specifies an application proxy, called 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>This protocol provides 0-RTT (Zero Round-Trip Time) conversion	<t>This protocol provides 0-RTT (Zero Round-Trip Time) 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>This specification assumes an explicit model, where the Transport	<t>This specification assumes an explicit model, where 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>
	</front>	</front>


	<middle>	<middle>

	<section anchor="intro" title="Introduction">	<section anchor="intro" numbered="true" toc="default">
	<section anchor="pb" title="The Problem">	<name>Introduction</name>
		<section anchor="pb" numbered="true" toc="default">
		<name>The Problem</name>
	<t>Transport protocols like TCP evolve regularly <xref	<t>Transport protocols like TCP evolve regularly <xref

	target="RFC7414"></xref>. TCP has been improved in different ways.	target="RFC7414" format="default"/>. TCP has been improved in
	Some improvements such as changing the initial window size <xref	different ways. Some improvements such as changing the initial window
	target="RFC6928"></xref> or modifying the congestion control scheme	size <xref target="RFC6928" format="default"/> or modifying the
	can be applied independently on clients and servers. Other	congestion control scheme can be applied independently on Clients and
	improvements such as Selective Acknowledgments <xref	Servers. Other improvements such as Selective Acknowledgments <xref
	target="RFC2018"></xref> or large windows <xref	target="RFC2018" format="default"/> or large windows <xref
	target="RFC7323"></xref> require a new TCP option or to change the	target="RFC7323" format="default"/> require a new TCP option or
	semantics of some fields in the TCP header. These modifications must	changing the semantics of some fields in the TCP header. These
	be deployed on both clients and servers to be actually used on the	modifications must be deployed on both Clients and Servers to be
	Internet. Experience with the latter class of TCP extensions reveals	actually used on the Internet. Experience with the latter class of TCP
	that their deployment can require many years. Fukuda reports in <xref	extensions reveals that their deployment can require many
	target="Fukuda2011"></xref> results of a decade of measurements	years. Fukuda reports in <xref target="Fukuda2011" format="default"/>
	showing the deployment of Selective Acknowledgments, Window Scale, and	results of a decade of measurements showing the deployment of
	TCP Timestamps. <xref target="ANRW17"></xref> describes measurements	Selective Acknowledgments, Window Scale, and TCP Timestamps. <xref
	showing that TCP Fast Open (TFO) <xref target="RFC7413"></xref> is	target="ANRW17" format="default"/> describes measurements showing that
	still not widely deployed.</t>	TCP Fast Open (TFO) <xref target="RFC7413" format="default"/> is still
		not widely deployed.</t>
		<t>There are some situations where the transport stack used on Clients
		(or Servers) can be upgraded at a faster pace than the transport stack
		running on Servers (or Clients).


	<t>There are some situations where the transport stack used on clients	In those situations, Clients (or Servers) would typically want to benefit
	(or servers) can be upgraded at a faster pace than the transport stack	from the features of an improved transport protocol even if the Servers (or
	running on servers (or clients). In those situations, clients would	Clients) have not yet been upgraded.
	typically want to benefit from the features of an improved transport
	protocol even if the servers have not yet been upgraded and
	conversely. Some assistance from the network to make use of these
	features is valuable. For example, Performance Enhancing Proxies <xref
	target="RFC3135"></xref>, and other service functions have been
	deployed as solutions to improve TCP performance over links with
	specific characteristics.</t>


	<t>Recent examples of TCP extensions include Multipath TCP (MPTCP)	Some assistance from the network to make use of these features is
	<xref target="RFC6824"></xref> or TCPINC <xref	valuable. For example, Performance Enhancing Proxies <xref target="RFC3135"
	target="RFC8548"></xref>. Those extensions provide features that are	format="default"/> and other service functions have been deployed as solutions
	interesting for clients such as wireless devices. With Multipath TCP,	to improve TCP performance over links with specific characteristics.</t>
	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>Recent examples of TCP extensions include Multipath TCP (MPTCP)
		<xref target="RFC8684" format="default"/> or tcpcrypt <xref target="RFC8
		548" format="default"/>. 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>More recently, 5G bonding experimentation has been conducted into	<t>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"/>.</t>
	</section>	</section>


	<section anchor="network-assisted-connections-the-rationale"	<section anchor="network-assisted-connections-the-rationale" numbered="tru
	title="Network-Assisted Connections: The Rationale">	e" toc="default">
	<t>This document specifies an application proxy, called Transport	<name>Network-Assisted Connections: The Rationale</name>
		<t>This document specifies an application proxy called 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>The Convert Protocol provides Zero Round-Trip Time (0-RTT)	<t>The Convert Protocol provides Zero Round-Trip Time (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>The Transport Converter adheres to the main steps drawn in <xref
	<t>The Transport Converter adheres to the main steps drawn in Section	target="RFC1919" sectionFormat="of" section="3"/>. In particular, a
	3 of <xref target="RFC1919"></xref>. In particular, a Transport	Transport Converter achieves the following:</t>
	Converter achieves the following:</t>	<ul spacing="normal">
		<li>Listening for Client sessions;</li>
	<t><list style="symbols">	<li>Receiving the address of the Server from the Client;</li>
	<t>Listen for client sessions;</t>	<li>Setting up a session to the Server;</li>
		<li>Relaying control messages and data between the Client and the
	<t>Receive from a client the address of the server;</t>	Server;</li>
		<li>Performing access controls according to local policies.</li>
	<t>Setup a session to the server;</t>	</ul>

	<t>Relay control messages and data between the client and the
	server;</t>

	<t>Perform access controls according to local policies.</t>
	</list></t>

	<t>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>The Convert Protocol is a generic mechanism to provide 0-RTT	<t>The Convert Protocol is a generic mechanism to provide 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>This document does not assume that all the traffic is eligible for
	<t>This document does not assume that all the traffic is eligible to
	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>This document assumes an explicit model in which a Client is
	<t>This document assumes an explicit model in which a 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"/>). Configuration
	means are outside the scope of this document.</t>	means are outside the scope of this document.</t>


	<t>The use of a Transport Converter means that there is no end-to-end	<t>The use of a Transport Converter means that there 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"/>. Some of thes
	may not be applicable, for example, a Transport Converter can inform a	e problems
	client by means of Network Failure (65) or Destination Unreachable	may not be applicable. For example, a Transport Converter can inform a
	(97) error messages (<xref target="sec-error"></xref>) that it	Client by means of Network Failure (65) or Destination Unreachable
	encounters a failure problem; the client can react accordingly. An	(97) error messages (<xref target="sec-error" format="default"/>) that i
		t
		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>This document is organized as follows. First, <xref	<t>
	target="sec-socks"></xref> provides a brief overview of the	This document is organized as follows:
	differences between the well-known SOCKS protocol and the 0-RTT	</t>
	Convert protocol. <xref target="sec-arch"></xref> provides a brief	<ul empty="true">
	explanation of the operation of Transport Converters. Then, <xref	<li>
	target="sec-protocol"></xref> describes the Convert Protocol. <xref	<xref target="sec-socks"/> 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> <xref target="sec-arch"/> provides a brief explanation of the operati
	middleboxes, while <xref target="sec-security"></xref> focuses on the	on of Transport
	security considerations. <xref target="sec-api"></xref> describes how	Converters. </li>
	a TCP stack would need to support the protocol described in this	<li>
	document.</t>	<xref target="sample-examples"/> includes a set of sample examples to illus
	</section>	trate the overall
		behavior.
		</li>
		<li>
		<xref target="sec-protocol"/> describes the Convert Protocol.
		</li>
		<li> <xref target="sec-tcpoptions"/> discusses how Transport Converters can
		be used to support
		different TCP extensions. </li>
		<li>
		<xref target="sec-middleboxes"/> then discusses the interactions with middl
		eboxes.
		</li>
		<li> <xref target="sec-security"/> focuses on security considerations. </li
		>
		<li> <xref target="sec-api"/> describes how a TCP stack would need to suppo
		rt the
		protocol described in this document.
		</li>
		</ul>


	<section title="Applicability Scope">	</section>
	<t>0-RTT TCP Convert Protocol specified in this document MUST be used	<section numbered="true" toc="default">
		<name>Applicability Scope</name>
		<t>The 0-RTT TCP Convert Protocol specified in this document <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>Future deployment of Transport Converters by third parties
	<t>Future deployment of Transport Converters by third parties MUST	<bcp14>MUST</bcp14> adhere to the mutual authentication requirements
	adhere to the mutual authentication requirements in <xref	in <xref target="authorization" format="default"/> to prevent
	target="authorization"></xref> to prevent illegitimate traffic	illegitimate traffic interception (<xref target="traffic-theft"
	interception (<xref target="traffic-theft"></xref>), in	format="default"/>) in particular.</t>
	particular.</t>
	</section>	</section>
	</section>	</section>


	<section anchor="sec-socks" title="Differences with SOCKSv5">	<section anchor="conventions-and-definitions" numbered="true" toc="default">
	<t>Several IETF protocols provide proxy services; the closest to the	<name>Conventions and Definitions</name>
	0-RTT Convert protocol being the SOCKSv5 protocol <xref
	target="RFC1928"></xref>. This protocol is already used to deploy	<t>
	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>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>


		</section>

		<section anchor="sec-socks" numbered="true" toc="default">
		<name>Differences with SOCKSv5</name>
		<t>Several IETF protocols provide proxy services, the closest to the
		0-RTT TCP Convert Protocol being the SOCKSv5 protocol <xref target="RFC192
		8"
		format="default"/>. This protocol is already used to deploy Multipath
		TCP in some cellular networks (<xref target="RFC8041" sectionFormat="of"
		section="2.2"/>).</t>
	<t>A SOCKS Client creates a connection to a SOCKS Proxy, exchanges	<t>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"/>.</t>
		<figure anchor="fig-socks5">
	<figure anchor="fig-socks5"	<name>Establishment of a TCP Connection through a SOCKS Proxy without Au
	title="Establishment of a TCP Connection through a SOCKS Proxy Wit	thentication</name>
	hout Authentication">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork><![CDATA[
	Client SOCKS Proxy Server	Client SOCKS Proxy Server
	\| \| \|	\| \| \|
	\| --------------------> \| \|	\| --------------------> \| \|
	\| SYN \| \|	\| SYN \| \|
	\| <-------------------- \| \|	\| <-------------------- \| \|
	\| SYN+ACK \| \|	\| SYN+ACK \| \|
	\| --------------------> \| \|	\| --------------------> \| \|
	\| ACK \| \|	\| ACK \| \|
	\| \| \|	\| \| \|
	\| --------------------> \| \|	\| --------------------> \| \|

	skipping to change at line 320 ¶	skipping to change at line 342 ¶
	\| Data1 \| \|	\| Data1 \| \|
	\| \| --------------------> \|	\| \| --------------------> \|
	\| \| Data1 \|	\| \| Data1 \|
	\| \| <-------------------- \|	\| \| <-------------------- \|
	\| \| Data2 \|	\| \| Data2 \|
	\| <-------------------- \| \|	\| <-------------------- \| \|
	\| Data2 \| \|	\| Data2 \| \|
	...	...
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<t>When SOCKS is used, an "end-to-end" connection between a Client and a	<t>When SOCKS is used, an "end-to-end" connection between a Client and a
	Server becomes a sequence of two TCP connections that are glued together	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>The Convert Protocol is also used on TCP proxies that relay data	<t>The Convert Protocol is also used on TCP proxies that 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-D.arkko-arch-low-latency"></xref>. A recently proposed	target="I-D.arkko-arch-low-latency" format="default"/>. A recently
	extension to SOCKS leverages the TCP Fast Open (TFO) option <xref	proposed extension to SOCKS leverages the TCP Fast Open (TFO) option
	target="I-D.olteanu-intarea-socks-6"></xref> to reduce this delay.</t>	<xref target="I-D.olteanu-intarea-socks-6" format="default"/> to reduce
		this delay.</t>
	<t>A second difference is that the Convert Protocol explicitly takes the	<t>A second difference is that the Convert Protocol explicitly 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

	target="RFC1928"></xref> nor the proposed SOCKSv6 <xref	target="RFC1928" format="default"/> nor the proposed SOCKSv6 <xref
	target="I-D.olteanu-intarea-socks-6"></xref> provide such a feature.</t>	target="I-D.olteanu-intarea-socks-6" format="default"/> provide such a
		feature.</t>
	<t>A third difference is that a Transport Converter will only confirm	<t>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"/>.</t>
		<t>A fourth difference is that the 0-RTT TCP Convert Protocol only allows
	<t>A fourth difference is that the 0-RTT Convert protocol 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"/>. However, that design
	adopted because it induces both an extra load and increased delays on	was not adopted because it induces both an extra load and increased
	the Transport Converter to handle and manage DNS resolution requests.	delays on the Transport Converter to handle and manage DNS resolution
	Note that the name resolution at the Converter may fail (e.g., private	requests. Note that the name resolution at the Converter may fail
	names discussed in Section 2.1 of <xref target="RFC6731"></xref>) or may	(e.g., private names discussed in <xref target="RFC6731"
	not match the one that would be returned by a Client's resolution	sectionFormat="of" section="2.1"/>) or may not match the one that would
	library (e.g., Section 2.2 of <xref target="RFC6731"></xref>).</t>	be returned by a Client's resolution library (e.g., <xref
	</section>	target="RFC6731" sectionFormat="of" section="2.2"/>).</t>

	<section anchor="conventions-and-definitions"
	title="Conventions and Definitions">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP 14
	<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and
	only when, they appear in all capitals, as shown here.</t>
	</section>	</section>


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

		<ul spacing="normal">
	<t><list style="symbols">	<li>Clients</li>
	<t>Clients;</t>	<li>Transport Converters</li>
		<li>Servers</li>
	<t>Transport Converters;</t>	</ul>

	<t>Servers.</t>
	</list></t>

	<t>A Transport Converter is a network function that proxies all data	<t>A Transport Converter is a network function that proxies 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"/>). Thus, the Tran
	Converter, thus, maintains state that associates one upstream	sport
		Converter maintains state that associates one upstream
	connection to a corresponding downstream connection.</t>	connection to a corresponding downstream connection.</t>


	<t>A connection can be initiated from both sides of the Transport	<t>A connection can be initiated from both sides of the Transport
	Converter (External realm, Internal realm).</t>	Converter (External realm, Internal realm).</t>

		<figure anchor="figtc">
	<figure anchor="figtc"	<name>A Transport Converter Proxies Data between Pairs of TCP Connecti
	title="A Transport Converter Proxies Data between Pairs of TCP C	ons</name>
	onnections">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork><![CDATA[
	\|	\|
	:	:
	\|	\|
	+------------+	+------------+
	Client <- upstream ->\| Transport \|<- downstream -> Server	Client <- upstream ->\| Transport \|<- downstream -> Server
	connection \| Converter \| connection	connection \| Converter \| connection
	+------------+	+------------+
	\|	\|
	Internal realm : External realm	Internal realm : External realm
	\|	\|

	skipping to change at line 418 ¶	skipping to change at line 425 ¶
	\|	\|
	+------------+	+------------+
	Client <- upstream ->\| Transport \|<- downstream -> Server	Client <- upstream ->\| Transport \|<- downstream -> Server
	connection \| Converter \| connection	connection \| Converter \| connection
	+------------+	+------------+
	\|	\|
	Internal realm : External realm	Internal realm : External realm
	\|	\|
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<t>"Client" refers to a software instance embedded on a host that can	<t>"Client" refers to a software instance embedded on 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>A Transport Converter can be embedded in a standalone device or be	<t>A Transport Converter can be embedded in a standalone 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>The architecture assumes that new software will be installed on the	<t>The architecture assumes that new software will be 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>A Client is configured, through means that are outside the scope of	<t>A Client is configured, through means that are outside the scope of

	this document, with the names and/or the addresses of one or more	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>One of the benefits of this design is that different transport	<t>One of the benefits of this design is that different 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>The architecture does not mandate anything on the Server side.</t>	<t>The architecture does not mandate anything on the Server side.</t>


	<t>Similar to SOCKS, the architecture does not interfere with	<t>Similar to SOCKS, the architecture does not interfere with

	end-to-end TLS connections <xref target="RFC8446"></xref> between the	end-to-end TLS connections <xref target="RFC8446" format="default"/> bet
	Client and the Server (<xref target="figtls"></xref>). In other words,	ween the
		Client and the Server (<xref target="figtls" format="default"/>). In oth
		er 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">
	<figure anchor="figtls"	<name>End-to-end TLS via a Transport Converter</name>
	title="End-to-end TLS via a Transport Converter">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork><![CDATA[
	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>

	skipping to change at line 468 ¶	skipping to change at line 467 ¶
	\| 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>It is out of scope of this document to elaborate on specific	<t>It is out of scope of this document to elaborate 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"
	target="RFC8446"></xref> is safe under replay and (2) specification of	sectionFormat="of" section="2.3"/> is safe under replay and (2)
	a profile for its use (Section E.5 of <xref target="RFC8446"></xref>)	specification of a profile for its use (<xref target="RFC8446"
	are out of scope.</t>	sectionFormat="of" section="E.5"/>) are out of scope.</t>
	</section>	</section>

		<section anchor="sec-to" numbered="true" toc="default">
	<section anchor="sec-to" title="Theory of Operation">	<name>Theory of Operation</name>
	<t>At a high level, the objective of the Transport Converter is to	<t>At a high level, the objective of the Transport Converter is to
	allow the use a specific extension, e.g., Multipath TCP, on a subset	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"/> 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">
	<figure anchor="fig-highlevel"	<name>An Example of 0-RTT Network-Assisted Outgoing MPTCP Connection</
	title="An Example of 0-RTT Network-Assisted Outgoing MPTCP Conne	name>
	ction">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork><![CDATA[
	Client Transport Server	Client Transport Server
	\| Converter \|	\| Converter \|
	\| \| \|	\| \| \|
	\|==================>\|--------------------->\|	\|==================>\|--------------------->\|
	\| \| \|	\| \| \|
	\|<==================\|<---------------------\|	\|<==================\|<---------------------\|
	\| \| \|	\| \| \|
	Multipath TCP packets TCP packets	Multipath TCP packets TCP packets
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	skipping to change at line 502 ¶	skipping to change at line 499 ¶
	Client Transport Server	Client Transport Server
	\| Converter \|	\| Converter \|
	\| \| \|	\| \| \|
	\|==================>\|--------------------->\|	\|==================>\|--------------------->\|
	\| \| \|	\| \| \|
	\|<==================\|<---------------------\|	\|<==================\|<---------------------\|
	\| \| \|	\| \| \|
	Multipath TCP packets TCP packets	Multipath TCP packets TCP packets
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<t>The packets belonging to a connection established through a	<t>The packets belonging to a connection established 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>When establishing a connection, the Client can, depending on local	<t>When establishing a connection, the Client can, depending 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>The Client places the destination address and port number of the	<t>The Client places the destination address and port number of the
	Server in the payload of the SYN sent to the Transport Converter to	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">
	<t><list style="symbols">	<li>The upstream connection is the one between the Client and the
	<t>the upstream connection is the one between the Client and the	Transport Converter.</li>
	Transport Converter.</t>	<li>The downstream connection is the one between the Transport
		Converter and the Server.</li>
	<t>the downstream connection is the one between the Transport	</ul>
	Converter and the Server.</t>
	</list></t>

	<t>Any user data received by the Transport Converter over the upstream	<t>Any user data received by the Transport Converter 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><xref target="fig-estab" format="default"/> illustrates the establish
	<t><xref target="fig-estab"></xref> illustrates the establishment of	ment 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><t>
		Note: The information shown between brackets in <xref
		target="fig-estab" format="default"/> (and other figures in the
		document) refers to Convert Protocol messages described in <xref
		target="sec-protocol" format="default"/>.</t></aside>


	<t><list style="symbols">	<figure anchor="fig-estab">
	<t>Note: The information shown between brackets in <xref	<name>Establishment of an Outgoing TCP Connection through a Transport
	target="fig-estab"></xref> (and other figures in the document)	Converter</name>
	refers to Convert Protocol messages described in <xref	<artwork name="" type="" align="left" alt=""><![CDATA[
	target="sec-protocol"></xref>.</t>
	</list></t>

	<figure anchor="fig-estab"
	title="Establishment of an Outgoing TCP Connection Through a Tra
	nsport Converter">
	<artwork><![CDATA[
	Transport	Transport
	Client Converter Server	Client Converter Server
	\| \| \|	\| \| \|
	\|SYN [->Server:port]\| SYN \|	\|SYN [->Server:port]\| SYN \|
	\|------------------>\|--------------------->\|	\|------------------>\|--------------------->\|
	\|<------------------\|<---------------------\|	\|<------------------\|<---------------------\|
	\| SYN+ACK [ ] \| SYN+ACK \|	\| SYN+ACK [ ] \| SYN+ACK \|
	\| ... \| ... \|	\| ... \| ... \|
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	skipping to change at line 575 ¶	skipping to change at line 562 ¶
	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>The connection can also be established from the Internet towards a	<t>The connection can also be established from the Internet towards a

	Client via a Transport Converter (<xref target="fig-estab2"></xref>).	Client via a Transport Converter (<xref target="fig-estab2"
	This is typically the case when the Client hosts an application server	format="default"/>). This is typically the case when the Client hosts
	that listens to a specific port number. When the Converter receives an	an application Server that listens to a specific port number. When the
	incoming SYN from a remote host, it checks if it can provide the	Converter receives an incoming SYN from a remote host, it checks if it
	conversion service for the destination IP address and destination port	can provide the conversion service for the destination IP address and
	number of that SYN. The Transport Converter receives this SYN because	destination port number of that SYN. The Transport Converter receives
	it is, for example, on the path between the remote host and the Client	this SYN because it is, for example, on the path between the remote
	or it provides address sharing service for the Client (Section 2 of	host and the Client or it provides address-sharing service for the
	<xref target="RFC6269"></xref>). If the check fails, the packet is	Client (<xref target="RFC6269" sectionFormat="of" section="2"/>). If
	silently ignored by the Converter. If the check is successful, the	the check fails, the packet is silently ignored by the Converter. If
	Converter tries to initiate a TCP connection towards the Client from	the check is successful, the Converter tries to initiate a TCP
	its own address and using its configured TCP options. In the SYN that	connection towards the Client from its own address and using its
	corresponds to this connection attempt, the Transport Convert inserts	configured TCP options. In the SYN that corresponds to this connection
	a TLV message that indicates the source address and port number of the	attempt, the Transport Convert inserts a TLV message that indicates
	remote host. A transport session entry is created by the Converter for	the source address and port number of the remote host. A transport
	this connection. SYN+ACK and ACK will be then exchanged between the	session entry is created by the Converter for this connection. SYN+ACK
	Client, the Converter, and remote host to confirm the establishment of	and ACK will then be exchanged between the Client, the Converter, and
	the connection. The Converter uses the transport session entry to	remote host to confirm the establishment of the connection. The
	proxy packets belonging to the connection.</t>	Converter uses the transport session entry to proxy packets belonging
		to the connection.</t>
	<figure anchor="fig-estab2"	<figure anchor="fig-estab2">
	title="Establishment of an Incoming TCP Connection Through a Tra	<name>Establishment of an Incoming TCP Connection through a Transport
	nsport Converter">	Converter</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	Transport Remote	Transport Remote
	Client Converter Host (RH)	Client Converter Host (RH)
	\| \| \|	\| \| \|
	\|SYN [<-RH IP@:port]\| SYN \|	\|SYN [<-RH IP@:port]\| SYN \|
	\|<------------------\|<---------------------\|	\|<------------------\|<---------------------\|
	\|------------------>\|--------------------->\|	\|------------------>\|--------------------->\|
	\| SYN+ACK [ ] \| SYN+ACK \|	\| SYN+ACK [ ] \| SYN+ACK \|
	\| ... \| ... \|	\| ... \| ... \|

	]]></artwork>	]]></artwork>
	</figure>	</figure>

		<t>Standard TCP (<xref target="RFC0793" format="default" section="3.4"/>
	<t>Standard TCP (<xref target="RFC0793"></xref>, Section 3.4) allows a	) 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"/> and thus, removes the con straint 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>As discussed in <xref target="RFC7413" format="default"/>, such
	<t>As discussed in <xref target="RFC7413"></xref>, such change to TCP	change to TCP semantics raises two issues. First, duplicate SYNs can
	semantic raises two issues. First, duplicate SYNs can cause problems	cause problems for applications that rely on TCP; whether or not a
	for applications that rely on TCP; whether or not a given application	given application is affected depends on the details of that
	is affected dependes on the details of that application protocol.	application protocol. Second, TCP suffers from SYN flooding attacks
	Second, TCP suffers from SYN flooding attacks <xref	<xref target="RFC4987" format="default"/>. TFO solves these two
	target="RFC4987"></xref>. TFO solves these two problems for	problems for applications that can tolerate replays by using the TCP
	applications that can tolerate replays by using the TCP Fast Open	Fast Open option that includes a cookie. However, the utilization of
	option that includes a cookie. However, the utilization of this option	this option consumes space in the limited TCP header. Furthermore,
	consumes space in the limited TCP header. Furthermore, there are	there are situations, as noted in <xref target="RFC7413"
	situations, as noted in Section 7.3 of <xref target="RFC7413"></xref>	sectionFormat="of" section="7.3"/>, where it is possible to accept the
	where it is possible to accept the payload of SYN packets without	payload of SYN packets without creating additional security risks such
	creating additional security risks such as a network where addresses	as a network where addresses cannot be spoofed and the Transport
	cannot be spoofed and the Transport Converter only serves a set of	Converter only serves a set of hosts that are identified by these
	hosts that are identified by these addresses.</t>	addresses.</t>

	<t>For these reasons, this specification does not mandate the use of	<t>For these reasons, this specification does not mandate 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"/>.</t>

	<t>If the downstream (or upstream) connection fails for some reason	<t>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"/>) 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"/>.</t>

	<t>The same reasoning applies when the upstream connection ends with	<t>The same reasoning applies when the upstream connection 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="default">
	<section anchor="sec-dbb"	<name>Data Processing at the Transport Converter</name>
	title="Data Processing at the Transport Converter">	<t>As mentioned in <xref target="sec-to" format="default"/>, the Transpo
	<t>As mentioned in <xref target="sec-to"></xref>, the Transport	rt
	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>The control messages, discussed in <xref	<t>The control messages (i.e., the Convert messages discussed in <xref t
	target="sec-protocol"></xref>, establish state (called, transport	arget="sec-protocol"
	session entry) in the Transport Converter that will enable it to proxy	format="default"/>) establish state (called transport session entry)
	between the two TCP connections.</t>	in the Transport Converter that will enable it to proxy between the
		two TCP connections.</t>
	<t>The Transport Converter uses the transport session entry to proxy	<t>The Transport Converter uses the transport session 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"/>.</t>
		<figure anchor="fig-dbt">
	<figure anchor="fig-dbt" title="An Example of Transport Session Entry">	<name>An Example of Transport Session Entry</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	(C,c) <--> (T,t), (S,s), Lifetime	(C,c) <--> (T,t), (S,s), Lifetime


	Where:
	* C and c are the source IP address and source port number
	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>	]]></artwork>


	</figure>	</figure>


	<t>Clients send packets bound to connections eligible to the	<t> Where:</t>

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

		<t>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-protocol"></xref>. User data can be included in SYN or	target="sec-protocol" format="default"/>. User data can be included in
	non-SYN messages. User data is unambiguously distinguished from	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"
	These Convert TLVs are destined to the Transport Convert and are,	format="default"/>). These Convert TLVs are destined to the Transport
	thus, removed by the Transport Converter when proxying between the two	Convert and are, thus, removed by the Transport Converter when
	connections.</t>	proxying between the two connections.</t>

	<t>Upon receipt of a packet that belongs to an existing connection	<t>Upon receipt of a packet that belongs to an existing connection

	between a Client and the Transport Converter the Converter proxies the	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"/>, the Transport Converter proxi
	data received from (C, c) downstream using (T,t) as source transport	es the
		data received from (C,&wj;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>A similar process happens for data sent from the Server. The	<t>A similar process happens for data sent from the Server. The
	Converter acts as a TCP proxy and sends the data to the Client relying	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>When Multipath TCP is used between the Client and the Transport	<t>When Multipath TCP is used between the Client and 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>A Transport Converter may operate in address preservation mode	<t>A Transport Converter may operate in address preservation 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"/> for more details. Which
	by a Transport Converter is deployment-specific. If address sharing	behavior to use by a Transport Converter is deployment specific. If
	mode is enabled, the Transport Converter MUST adhere to REQ-2 of <xref	address-sharing mode is enabled, the Transport Converter
	target="RFC6888"></xref> which implies a default "IP address pooling"	<bcp14>MUST</bcp14> adhere to REQ-2 of <xref target="RFC6888"
	behavior of "Paired" (as defined in Section 4.1 of <xref	format="default"/>, which implies a default "IP address pooling"
	target="RFC4787"></xref>) MUST be supported. This behavior is meant to	behavior of "Paired" (as defined in <xref target="RFC4787"
	avoid breaking applications that depend on the source address	sectionFormat="of" section="4.1"/>) <bcp14>MUST</bcp14> be
	remaining constant.</t>	supported. This behavior is meant to avoid breaking applications that
		depend on the source address remaining constant.</t>
	</section>	</section>


	<section anchor="sec-add"	<section anchor="sec-add" numbered="true" toc="default">
	title="Address Preservation vs. Address Sharing">	<name>Address Preservation vs. Address Sharing</name>
	<t>The Transport Converter is provided with instructions about the	<t>The Transport Converter is provided with instructions about the

	behavior to adopt with regards to the processing of source addresses	behavior to adopt with regard to the processing of source addresses
	of outgoing packets. The following sub-sections discusses two	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="default">
	<section anchor="sec-addp" title="Address Preservation">	<name>Address Preservation</name>
	<t>In this model, the visible source IP address of a packet proxied	<t>In this model, the visible source IP address of a packet proxied
	by a Transport Converter to a Server is an IP address of the end	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>For Multipath TCP, the Transport Converter preserves the source	<t>For Multipath TCP, the Transport Converter preserves 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"/>.</
		t>
	<figure anchor="fig-addp" title="Example of Address Preservation">	<figure anchor="fig-addp">
	<artwork><![CDATA[	<name>Example of Address Preservation</name>
	Transport	<artwork name="" type="" align="left" alt=""><![CDATA[
	Client Converter Server	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 [->S:port]------->\|-------SYN------->\|
	\|\| \| \|	\|\| \| \|
	\|\|dst:C1 src:Tc\|dst:C1 src:S\|	\|\|dst:C1 src:Tc\|dst:C1 src:S\|
	\|<---------SYN/ACK------------\|<-----SYN/ACK-----\|	\|<---------SYN/ACK------------\|<-----SYN/ACK-----\|
	\|\| \| \|	\|\| \| \|
	\|src:C1 dst:Tc\|src:C1 dst:S\|	\|src:C1 dst:Tc\|src:C1 dst:S\|
	\|------------ACK------------->\|-------ACK------->\|	\|------------ACK------------->\|-------ACK------->\|
	\| \| \|	\| \| \|
	\|src:C2 ... dst:Tc\| ... \|	\|src:C2 ... dst:Tc\| ... \|
	\|\|<-----Secondary Subflow---->\|src:C1 dst:S\|	\|\|<-----Secondary Subflow---->\|src:C1 dst:S\|
	\|\| \|-------data------>\|	\|\| \|-------data------>\|
	\| .. \| ... \|	\| .. \| ... \|

	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>The Transport Converter must be on the forwarding path of	<t>The Transport Converter must be on the forwarding 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="default">
	<section anchor="sec-adds" title="Address/Prefix Sharing">	<name>Address/Prefix Sharing</name>
	<t>A pool of global IPv4 addresses is provisioned to the Transport	<t>A pool of global IPv4 addresses is provisioned to the Transport

	Converter along with possible instructions about the address sharing	Converter along with possible instructions about the address-sharing
	ratio to apply (see Appendix B of <xref target="RFC6269"></xref>).	ratio to apply (see <xref target="RFC6269"
	An address is thus shared among multiple clients.</t>	sectionFormat="of" section="B"/>).
		An address is thus shared among multiple Clients.</t>
	<t>Likewise, rewriting the source IPv6 prefix <xref	<t>Likewise, rewriting the source IPv6 prefix <xref target="RFC6296" f
	target="RFC6296"></xref> may be used to ease redirection of incoming	ormat="default"/> 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>Adequate forwarding policies are enforced so that traffic	<t>Adequate forwarding policies are enforced so that traffic

	destined to an address of such pool is intercepted by the	destined to an address of such a pool is intercepted by the
	appropriate Transport Converter. Unlike <xref	appropriate Transport Converter. Unlike <xref target="sec-addp"
	target="sec-addp"></xref>, the Transport Converter drops incoming	format="default"/>, the Transport Converter drops incoming packets
	packets which do not match an active transport session entry.</t>	that do not match an active transport session entry.</t>
		<t>An example is shown in <xref target="fig-adds" format="default"/>.<
	<t>An example is shown in <xref target="fig-adds"></xref>.</t>	/t>
		<figure anchor="fig-adds">
	<figure anchor="fig-adds" title="Address Sharing">	<name>Address Sharing</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	Transport	Transport
	Client Converter Server	Client Converter Server


	@:C @:Tc\|Te @:S	@:C @:Tc\|Te @:S
	\| \| \|	\| \| \|
	\|src:C dst:Tc\|src:Te dst:S\|	\|src:C dst:Tc\|src:Te dst:S\|
	\|-------SYN [->S:port]------->\|-------SYN------->\|	\|-------SYN [->S:port]------->\|-------SYN------->\|
	\| \| \|	\| \| \|
	\|dst:C src:Tc\|dst:Te src:S\|	\|dst:C src:Tc\|dst:Te src:S\|
	\|<---------SYN/ACK------------\|<-----SYN/ACK-----\|	\|<---------SYN/ACK------------\|<-----SYN/ACK-----\|
	\| \| \|	\| \| \|
	\|src:C dst:Tc\|src:Te dst:S\|	\|src:C dst:Tc\|src:Te dst:S\|
	\|------------ACK------------->\|-------ACK------->\|	\|------------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="default">
	<section anchor="sample-examples" title="Sample Examples">	<name>Sample Examples</name>
	<section anchor="outgoing-converter-assisted-multipath-tcp-connections"	<section anchor="outgoing-converter-assisted-multipath-tcp-connections" nu
	title="Outgoing Converter-Assisted Multipath TCP Connections">	mbered="true" toc="default">
		<name>Outgoing Converter-Assisted Multipath TCP Connections</name>
	<t>As an example, let us consider how the Convert Protocol can help	<t>As an example, let us consider how the Convert Protocol can help
	the deployment of Multipath TCP. We assume that both the Client and	the 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>As a reminder, a Multipath TCP connection is created by placing the	<t>As a reminder, a Multipath TCP connection is created by placing the
	MP_CAPABLE (MPC) option in the SYN sent by the Client.</t>	MP_CAPABLE (MPC) option in the SYN sent by the Client.</t>

		<t><xref target="fig-mpestab" format="default"/> describes the operation
	<t><xref target="fig-mpestab"></xref> describes the operation of the	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">
	<figure anchor="fig-mpestab"	<name>Establishment of a Multipath TCP Connection through a
	title="Establishment of a Multipath TCP Connection through a Tra	Transport Converter towards a Server That Does Not support Multipath
	nsport Converter towards a Server that does not support Multipath TCP">	TCP</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	Transport	Transport
	Client Converter Server	Client Converter Server
	\|SYN, MPC \| \|	\|SYN, MPC \| \|
	\|[->Server:port] \| SYN, MPC \|	\|[->Server:port] \| SYN, MPC \|
	\|------------------>\|--------------------->\|	\|------------------>\|--------------------->\|
	\|<------------------\|<---------------------\|	\|<------------------\|<---------------------\|
	\| SYN+ACK,MPC [.] \| SYN+ACK \|	\| SYN+ACK,MPC [.] \| SYN+ACK \|
	\|------------------>\|--------------------->\|	\|------------------>\|--------------------->\|
	\| ACK, MPC \| ACK \|	\| ACK, MPC \| ACK \|
	\| ... \| ... \|	\| ... \| ... \|

	skipping to change at line 887 ¶	skipping to change at line 862 ¶
	\|SYN, MPC \| \|	\|SYN, MPC \| \|
	\|[->Server:port] \| SYN, MPC \|	\|[->Server:port] \| SYN, MPC \|
	\|------------------>\|--------------------->\|	\|------------------>\|--------------------->\|
	\|<------------------\|<---------------------\|	\|<------------------\|<---------------------\|
	\| SYN+ACK,MPC [.] \| SYN+ACK \|	\| SYN+ACK,MPC [.] \| SYN+ACK \|
	\|------------------>\|--------------------->\|	\|------------------>\|--------------------->\|
	\| ACK, MPC \| ACK \|	\| ACK, MPC \| ACK \|
	\| ... \| ... \|	\| ... \| ... \|
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<t>The Client tries to initiate a Multipath TCP connection by sending	<t>The Client tries to initiate a Multipath TCP connection 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"/>). 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>Note that, if the TCP connection is reset for some reason, the	<t>Note that, if the TCP connection is reset for some 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><xref target="fig-mpestabok" format="default"/> considers a Server th
	<t><xref target="fig-mpestabok"></xref> considers a Server that	at
	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">
	<figure anchor="fig-mpestabok"	<name>Establishment of a Multipath TCP Connection through a
	title="Establishment of a Multipath TCP Connection through a Con	Converter towards an MPTCP-Capable Server</name>
	verter towards an MPTCP-capable Server">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork><![CDATA[
	Transport	Transport
	Client Converter Server	Client Converter Server
	\|SYN, MPC \| \|	\|SYN, MPC \| \|
	\|[->Server:port] \| SYN, MPC \|	\|[->Server:port] \| SYN, MPC \|
	\|------------------>\|--------------------->\|	\|------------------>\|--------------------->\|
	\|<------------------\|<---------------------\|	\|<------------------\|<---------------------\|
	\|SYN+ACK, MPC \| SYN+ACK, MPC \|	\|SYN+ACK, MPC \| SYN+ACK, MPC \|
	\|[MPC supported] \| \|	\|[MPC supported] \| \|
	\|------------------>\|--------------------->\|	\|------------------>\|--------------------->\|
	\| 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="default">
	title="Incoming Converter-Assisted Multipath TCP Connection">	<name>Incoming Converter-Assisted Multipath TCP Connection</name>
	<t>An example of an incoming Converter-assisted Multipath TCP	<t>An example of an incoming Converter-assisted Multipath TCP

	connection is depicted in <xref target="fig-inestab"></xref>. In order	connection is depicted in <xref target="fig-inestab"
	to support incoming connections from remote hosts, the Client may use	format="default"/>. In order to support incoming connections from
	PCP <xref target="RFC6887"></xref> to instruct the Transport Converter	remote hosts, the Client may use the Port Control Protocol (PCP) <xref
	to create dynamic mappings. Those mappings will be used by the	target="RFC6887" format="default"/> to instruct the Transport
	Transport Converter to intercept an incoming TCP connection destined	Converter to create dynamic mappings. Those mappings will be used by
	to the Client and convert it into a Multipath TCP connection.</t>	the Transport Converter to intercept an incoming TCP connection
		destined to the Client and convert it into a Multipath TCP
		connection.</t>

	<t>Typically, the Client sends a PCP request to the Converter asking	<t>Typically, the Client sends a PCP request to the Converter asking

	to create an explicit TCP mapping for (internal IP address, internal	to create an explicit TCP mapping for the internal IP address and
	port number). The Converter accepts the request by creating a TCP	internal port number. The Converter accepts the request by creating a
	mapping (internal IP address, internal port number, external IP	TCP mapping for the internal IP address, internal port number,
	address, external port number). The external IP address, external port	external IP address, and external port number. The external IP
	number, and assigned lifetime are returned back the Client in the PCP	address, external port number, and assigned lifetime are returned back
	response. The external IP address and external port number will be	to the Client in the PCP response. The external IP address and
	then advertised by the Client (or the user) using an out-of-band	external port number will then be advertised by the Client (or the
	mechanism so that remote hosts can initiate TCP connections to the	user) using an out-of-band mechanism so that remote hosts can initiate
	Client via the Converter. Note that the external and internal	TCP connections to the Client via the Converter. Note that the
	information may be the same.</t>	external and internal information may be the same.</t>

	<t>Then, when the Converter receives an incoming SYN, it checks its	<t>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">
	<figure anchor="fig-inestab"	<name>Establishment of an Incoming Multipath TCP Connection through a
	title="Establishment of an Incoming Multipath TCP Connection thr	Transport Converter</name>
	ough a Transport Converter">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork><![CDATA[
	Transport Remote	Transport Remote
	Client Converter Host	Client Converter Host
	\| \| \|	\| \| \|
	\|<--------------------\|<-------------------\|	\|<--------------------\|<-------------------\|
	\|SYN, MPC \| SYN \|	\|SYN, MPC \| SYN \|
	\|[Remote Host:port] \| \|	\|[Remote Host:port] \| \|
	\|-------------------->\|------------------->\|	\|-------------------->\|------------------->\|
	\| SYN+ACK, MPC \| SYN+ACK \|	\| SYN+ACK, MPC \| SYN+ACK \|
	\|<--------------------\|<-------------------\|	\|<--------------------\|<-------------------\|
	\| ACK, MPC \| ACK \|	\| ACK, MPC \| ACK \|

	skipping to change at line 989 ¶	skipping to change at line 959 ¶
	\|<--------------------\|<-------------------\|	\|<--------------------\|<-------------------\|
	\|SYN, MPC \| SYN \|	\|SYN, MPC \| SYN \|
	\|[Remote Host:port] \| \|	\|[Remote Host:port] \| \|
	\|-------------------->\|------------------->\|	\|-------------------->\|------------------->\|
	\| SYN+ACK, MPC \| SYN+ACK \|	\| SYN+ACK, MPC \| SYN+ACK \|
	\|<--------------------\|<-------------------\|	\|<--------------------\|<-------------------\|
	\| ACK, MPC \| ACK \|	\| ACK, MPC \| ACK \|
	\| ... \| ... \|	\| ... \| ... \|
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<t>It is out of scope of this document to define specific Convert TLVs	<t>It is out of scope of this document to define specific 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="default">
	<section anchor="sec-protocol" title="The Convert Protocol (Convert)">	<name>The Convert Protocol (Convert)</name>
	<t>This section defines the Convert Protocol (Convert, for short)	<t>This section defines the Convert Protocol (Convert, for 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>The Transport Converter listens on a specific TCP port number for	<t>The Transport Converter listens on a specific TCP port 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>Convert messages may appear only in SYN, SYN+ACK, or ACK.</t>	<t>Convert messages may appear only in SYN, SYN+ACK, or ACK.</t>

		<t>Convert messages <bcp14>MUST</bcp14> be included as the first bytes
	<t>Convert messages MUST be included as the first bytes of the	of the bytestream. All Convert messages start with a fixed header that
	bytestream. All Convert messages starts with a 32 bits long fixed header	is 32 bits long (<xref target="sec-header" format="default"/>) followed
	(<xref target="sec-header"></xref>) followed by one or more Convert TLVs	by one or more Convert TLVs (Type, Length, Value) (<xref
	(Type, Length, Value) (<xref target="sec-tlv"></xref>).</t>	target="sec-tlv" format="default"/>).</t>
		<t>If the initial SYN message contains user data in its payload (e.g., see
	<t>If the initial SYN message contains user data in its payload (e.g.,	<xref target="RFC7413" format="default"/>), that data <bcp14>MUST</bcp14>
	<xref target="RFC7413"></xref>), that data MUST be placed right after	be placed right after
	the Convert TLVs when generating the SYN.</t>	the Convert TLVs when generating the SYN.</t>


	<t>The protocol can be extended by defining new TLVs or bumping the	<t>The protocol can be extended by defining new TLVs or bumping the
	version number if a different message format is needed. If a future	version 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" /> (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>


	<t><list style="symbols">	<aside>
	<t>Implementation note 1: Several implementers expressed concerns	<t>Implementation note 1: Several implementers expressed 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
	TFO cookie inside the TCP options, which consumes precious space in	target="RFC7413"/>, there are different ways to protect from such
	the extended TCP header, the Convert Protocol supports the	attacks. Instead of using a Fast Open Cookie inside the TCP options, whi
	utilization of a Cookie that is placed in the SYN payload. This	ch
	provides the same level of protection as a TFO Cookie in	consumes precious space in the extended TCP header, the Convert
	environments were such protection is required.</t>	Protocol supports the utilization of a Cookie that is placed in the
		SYN payload. This provides the same level of protection as a Fast Open
	<t>Implementation note 2: Error messages are not included in RST but	Cookie in environments were such protection is required.</t>
		<t>Implementation note 2: Error messages are not included in RST but
	sent in the bytestream. Implementers have indicated that processing	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="default">
	<section anchor="sec-header" title="The Convert Fixed Header">	<name>The Convert Fixed Header</name>
	<t>The Convert Protocol uses a 32 bits long fixed header that is sent	<t>The Convert Protocol uses a fixed header that is 32 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>The Client and the Transport Converter <bcp14>MUST</bcp14> send the f
	<t>The Client and the Transport Converter MUST send the fixed-sized	ixed-sized
	header, shown in <xref target="fig-header"></xref>, as the first four	header, shown in <xref target="fig-header" format="default"/>, as the fi
		rst four
	bytes of the bytestream.</t>	bytes of the bytestream.</t>

		<figure anchor="fig-header">
	<figure anchor="fig-header" title="The Convert Fixed Header">	<name>The Convert Fixed Header</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	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>The version is encoded as an 8-bit unsigned integer value. This
	<t>The Version is encoded as an 8 bits unsigned integer 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>

		<t>
		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>The Total Length is the number of 32 bits word, including the	<t>The Total Length is the number of 32-bit words, including 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>The Magic Number field <bcp14>MUST</bcp14> be set to 0x2263. This
	to this document. This field is meant to further strengthen the	field is meant to further strengthen the protocol to unambiguously
	protocol to unambiguously distinguish any data supplied by an	distinguish any data supplied by an application from Convert TLVs. </t>
	application from Convert TLVs. <list style="symbols">
	<t>Note to the RFC Editor: Please replace "the RFC number to be
	assigned to this document" with the hex representation of the RFC
	number assigned to this document.</t>
	</list></t>


	<t>The Total Length field unambiguously marks the number of 32 bits	<t>The Total Length field unambiguously marks the number of 32-bit
	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="default">
	<section anchor="sec-tlv" title="Convert TLVs">	<name>Convert TLVs</name>
	<section anchor="generic-convert-tlv-format"	<section anchor="generic-convert-tlv-format" numbered="true" toc="defaul
	title="Generic Convert TLV Format">	t">
		<name>Generic Convert TLV Format</name>
	<t>The Convert Protocol uses variable length messages that are	<t>The Convert Protocol uses variable length messages that are

	encoded using the generic TLV format depicted in <xref	encoded using the generic TLV format depicted in <xref target="fi-gene
	target="fi-generictlv"></xref>.</t>	rictlv" format="default"/>.</t>

	<t>The length of all TLVs used by the Convert Protocol is always a	<t>The length of all TLVs used by the Convert Protocol is always a

	multiple of four bytes. All TLVs are aligned on 32 bits boundaries.	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">
	<figure anchor="fi-generictlv" title="Convert Generic TLV Format">	<name>Convert Generic TLV Format</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	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>The Length field covers Type, Length, and Value fields. It is	<t>The Length field covers Type, Length, and Value 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>A given TLV <bcp14>MUST</bcp14> only appear once on a connection. I
	<t>A given TLV MUST only appear once on a connection. If a Client	f 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"	"default">
	title="Summary of Supported Convert TLVs">	<name>Summary of Supported Convert TLVs</name>
	<t>This document specifies the following Convert TLVs:</t>	<t>This document specifies the following Convert TLVs:</t>


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

	<t>Type 0x0 is a reserved value. If a Client receives a TLV of type	<t>Type 0x0 is a reserved value. If a Client receives a TLV of type

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

	<t>The Client can request the establishment of connections to	<t>The Client can request the establishment of connections to

	servers by using the Connect TLV (<xref	Servers by using the Connect TLV (<xref target="sec-connect"
	target="sec-connect"></xref>). If the connection can be established	format="default"/>). If the connection can be established with the
	with the final server, the Transport Converter replies with the	final Server, the Transport Converter replies with the Extended TCP
	Extended TCP Header TLV (<xref target="sec-ext-header"></xref>). If	Header TLV (<xref target="sec-ext-header" format="default"/>). If
	not, the Transport Converter MUST return an Error TLV (<xref	not, the Transport Converter <bcp14>MUST</bcp14> return an Error TLV
	target="sec-error"></xref>) and then closes the connection. The	(<xref target="sec-error" format="default"/>) and then close the
	Transport Converter MUST NOT send an RST immediately after the	connection. The Transport Converter <bcp14>MUST NOT</bcp14> send an
	detection of an error to let the Error TLV reach the Client. As	RST immediately after the detection of an error to let the Error TLV
	explained later, the Client will anyway send an RST upon reception	reach the Client. As explained later, the Client will send an RST
	of the Error TLV.</t>	regardless upon reception of the Error TLV.</t>
	</section>	</section>

		<section anchor="sec-bootstrap-tlv" numbered="true" toc="default">
	<section anchor="sec-bootstrap-tlv" title="The Info TLV">	<name>The Info TLV</name>
	<t>The Info TLV (<xref target="fig-bootstrap"></xref>) is an	<t>The Info TLV (<xref target="fig-bootstrap" format="default"/>) is
	optional TLV which can be sent by a Client to request the TCP	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

	target="sec-supported"></xref>.</t>	target="sec-supported" format="default"/>.</t>
		<figure anchor="fig-bootstrap">
	<figure anchor="fig-bootstrap" title="The Info TLV">	<name>The Info TLV</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	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="default">
	<section anchor="sec-supported" title="Supported TCP Extensions TLV">	<name>Supported TCP Extensions TLV</name>
	<t>The Supported TCP Extensions TLV (<xref	<t>The Supported TCP Extensions TLV (<xref target="fig-supported"
	target="fig-supported"></xref>) is used by a Transport Converter to	format="default"/>) is used by a Transport Converter to announce the
	announce the TCP options for which it provides a conversion service.	TCP options for which it provides a conversion service. A Transport
	A Transport Converter SHOULD include in this list the TCP options	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>Each supported TCP option is encoded with its TCP option Kind	<t>Each supported TCP option is encoded with its 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"/>. The Unassig
		ned 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">
	<figure anchor="fig-supported"	<name>The Supported TCP Extensions TLV</name>
	title="The Supported TCP Extensions TLV">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork><![CDATA[
	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>TCP option Kinds 1 and 2 defined in <xref target="RFC0793"
	<t>TCP option Kinds 1 and 2 defined in <xref	format="default"/> are supported by all TCP implementations and
	target="RFC0793"></xref> are supported by all TCP implementations	thus, <bcp14>MUST NOT</bcp14> appear in this list.</t>
	and thus MUST NOT appear in this list.</t>

	<t>The list of Supported TCP Extensions is padded with 0 to end on a	<t>The list of Supported TCP Extensions is padded with 0 to end on a

	32 bits boundary.</t>	32-bit boundary.</t>

	<t>For example, if the Transport Converter supports Multipath TCP,	<t>For example, if the Transport Converter supports 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="default">
	<section anchor="sec-connect" title="Connect TLV">	<name>Connect TLV</name>
	<t>The Connect TLV (<xref target="fig-connect"></xref>) is used to	<t>The Connect TLV (<xref target="fig-connect" format="default"/>) 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>The Remote Peer Port and Remote Peer IP Address fields
	<t>The 'Remote Peer Port' and 'Remote Peer IP Address' 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>The Remote Peer IP Address MUST be encoded as an IPv6 address.
	IPv4 addresses MUST be encoded using the IPv4-Mapped IPv6 Address
	format defined in <xref target="RFC4291"></xref>. Further, Remote
	Peer IP address field MUST NOT include multicast, broadcast, and
	host loopback addresses <xref target="RFC6890"></xref>. If a
	Converter receives a Connect TLVs with such invalid addresses, it
	MUST reply with a Malformed Message Error TLV and close the
	associated TCP connection.</t>


		<t>The Remote Peer IP Address <bcp14>MUST</bcp14> be encoded as an
		IPv6 address. IPv4 addresses <bcp14>MUST</bcp14> be encoded using
		the IPv4-mapped IPv6 address format defined in <xref
		target="RFC4291" format="default"/>. Further, the Remote Peer IP
		Address field <bcp14>MUST NOT</bcp14> include multicast, broadcast,
		or host loopback addresses <xref target="RFC6890"
		format="default"/>. If a Converter receives a Connect TLV with such
		invalid addresses, it <bcp14>MUST</bcp14> reply with a Malformed
		Message Error TLV and close the associated TCP connection.</t>
	<t>We distinguish two types of Connect TLV based on their length:	<t>We distinguish two types of Connect TLV based on their length:
	(1) the Base Connect TLV has a length set to 5 (i.e., 20 bytes) and	(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"></xref>), (2) the Extended Connect TLV spans	target="fig-connect" format="default"/>), and (2) the Extended Connect
	more than 20 bytes and also includes the optional 'TCP Options'	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"/>). 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">
		<name>The Base Connect TLV</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	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">
	<figure anchor="fig-econnect" title="The Extended Connect TLV">	<name>The Extended Connect TLV</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	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>The TCP Options field is a variable length field that carries a
	<t>The 'TCP Options' field is a variable length field that carries a	list of TCP option fields (<xref target="fig-tcpopt"
	list of TCP option fields (<xref target="fig-tcpopt"></xref>). Each	format="default"/>). Each TCP option field is encoded as a block of
	TCP option field is encoded as a block of 2+n bytes where the first	2+n bytes where the first byte is the TCP option Kind and the second
	byte is the TCP option Kind and the second byte is the length of the	byte is the length of the TCP option as specified in <xref
	TCP option as specified in <xref target="RFC0793"></xref>. The	target="RFC0793" format="default"/>. The minimum value for the TCP
	minimum value for the TCP option Length is 2. The TCP options that	option Length is 2. The TCP options that do not include a length
	do not include a length sub-field, i.e., option types 0 (EOL) and 1	sub-field, i.e., option types 0 (EOL) and 1 (NOP) defined in <xref
	(NOP) defined in <xref target="RFC0793"></xref> MUST NOT be placed	target="RFC0793" format="default"/> <bcp14>MUST NOT</bcp14> be
	inside the TCP options field of the Connect TLV. The optional Value	placed inside the TCP options field of the Connect TLV. The optional
	field contains the variable-length part of the TCP option. A length	Value field contains the variable-length part of the TCP option. A
	of two indicates the absence of the Value field. The TCP options	length of 2 indicates the absence of the Value field. The TCP
	field always ends on a 32 bits boundary after being padded with	options field always ends on a 32-bit boundary after being padded
	zeros.</t>	with zeros.</t>
		<figure anchor="fig-tcpopt">
	<figure anchor="fig-tcpopt" title="The TCP Options Field">	<name>The TCP Options Field</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	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>

	skipping to change at line 1328 ¶	skipping to change at line 1313 ¶
	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>Upon reception of a Base Connect TLV, and absent any policy	<t>Upon reception of a Base Connect TLV, and absent 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>Upon reception of an Extended Connect TLV, a Transport Converter	<t>Upon reception of an Extended Connect TLV, a 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"/>). If the abov
	conditions, a Transport Converter MUST attempt to establish a	e 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"/> for
	a detailed discussion of the different types of TCP options.</t>	a detailed discussion of the different types of TCP options.</t>


	<t>The Transport Converter may refuse a Connect TLV request for	<t>The Transport Converter may refuse a Connect 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"/>). In order to prev
	denial-of-service attacks, error messages sent to a Client SHOULD be	ent
		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="default">
	<section anchor="sec-ext-header" title="Extended TCP Header TLV">	<name>Extended TCP Header TLV</name>
	<t>The Extended TCP Header TLV (<xref	<t>The Extended TCP Header TLV (<xref target="fig-tcpheader"
	target="fig-tcpheader"></xref>) is used by the Transport Converter	format="default"/>) is used by the Transport Converter to return to
	to return to the Client the TCP options that were returned by the	the Client the TCP options that were returned by the Server in the
	Server in the SYN+ACK packet. A Transport Converter MUST return this	SYN+ACK packet. A Transport Converter <bcp14>MUST</bcp14> return
	TLV if the Client sent an Extended Connect TLV and the connection	this TLV if the Client sent an Extended Connect TLV and the
	was accepted by the server. </t>	connection was accepted by the Server. </t>
		<figure anchor="fig-tcpheader">
	<figure anchor="fig-tcpheader" title="The Extended TCP Header TLV">	<name>The Extended TCP Header TLV</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	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>

	skipping to change at line 1384 ¶	skipping to change at line 1366 ¶
	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>The Returned Extended TCP header field is a copy of the TCP	<t>The Returned Extended TCP header field is a copy of the TCP
	Options that were included in the SYN+ACK received by the Transport	Options that were included in the SYN+ACK received by the Transport
	Converter.</t>	Converter.</t>

		<t>The Unassigned field <bcp14>MUST</bcp14> be set to zero by the send
	<t>The Unassigned field MUST be set to zero by the sender and	er and
	ignored by the receiver.</t>	ignored by the receiver.</t>
	</section>	</section>

		<section anchor="sec-cookie-tlv" numbered="true" toc="default">
	<section anchor="sec-cookie-tlv" title="The Cookie TLV">	<name>The Cookie TLV</name>
	<t>The Cookie TLV (<xref target="fig-cookie"></xref>) is an optional	<t>The Cookie TLV (<xref target="fig-cookie" format="default"/>) is
	TLV which is similar to the TCP Fast Open Cookie <xref	an optional TLV that is similar to the TCP Fast Open Cookie <xref
	target="RFC7413"></xref>. A Transport Converter may want to verify	target="RFC7413" format="default"/>. A Transport Converter may want
	that a Client can receive the packets that it sends to prevent	to verify that a Client can receive the packets that it sends to
	attacks from spoofed addresses. This verification can be done by	prevent attacks from spoofed addresses. This verification can be
	using a Cookie that is bound to, for example, the IP address(es) of	done by using a Cookie that is bound to, for example, the IP
	the Client. This Cookie can be configured on the Client by means	address(es) of the Client. This Cookie can be configured on the
	that are outside of this document or provided by the Transport	Client by means that are outside of this document or provided by the
	Converter.</t>	Transport Converter.</t>

	<t>A Transport Converter that has been configured to use the	<t>A Transport Converter that has been configured to use the

	optional Cookie TLV MUST verify the presence of this TLV in the	optional Cookie TLV <bcp14>MUST</bcp14> verify the presence of this
	payload of the received SYN. If this TLV is present, the Transport	TLV in the payload of the received SYN. If this TLV is present, the
	Converter MUST validate the Cookie by means similar to those in	Transport Converter <bcp14>MUST</bcp14> validate the Cookie by means
	Section 4.1.2 of <xref target="RFC7413"></xref> (i.e.,	similar to those in <xref target="RFC7413" sectionFormat="of"
	IsCookieValid). If the Cookie is valid, the connection establishment	section="4.1.2"/> (i.e., IsCookieValid). If the Cookie is valid, the
	procedure can continue. Otherwise, the Transport Converter MUST	connection establishment procedure can continue. Otherwise, the
	return an Error TLV set to "Not Authorized" and close the	Transport Converter <bcp14>MUST</bcp14> return an Error TLV set to
	connection.</t>	"Not Authorized" and close the connection.</t>

	<t>If the received SYN did not contain a Cookie TLV, and cookie	<t>If the received SYN did not contain a Cookie TLV, and cookie

	validation is required, the Transport Converter MAY compute a 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>The format of the Cookie TLV is shown in <xref target="fig-cookie"
	<t>The format of the Cookie TLV is shown in <xref	format="default"/>.</t>
	target="fig-cookie"></xref>.</t>	<figure anchor="fig-cookie">
		<name>The Cookie TLV</name>
	<figure anchor="fig-cookie" title="The Cookie TLV">	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork><![CDATA[
	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="default">
	<section anchor="sec-error" title="Error TLV">	<name>Error TLV</name>
	<t>The Error TLV (<xref target="fig-error"></xref>) is meant to	<t>The Error TLV (<xref target="fig-error" format="default"/>) is mean
		t 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>An Error TLV can be included in the SYN+ACK or an ACK.</t>	<t>An Error TLV can be included in the SYN+ACK or an ACK.</t>

		<figure anchor="fig-error">
	<figure anchor="fig-error" title="The Error TLV">	<name>The Error TLV</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	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>Different types of errors can occur while processing Convert	<t>Different types of errors can occur while processing 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">
	<t><list style="symbols">	<dt>Message validation and processing errors (0-31 range):</dt>
	<t>Message validation and processing errors (0-31 range):	<dd>Returned upon reception of an invalid message (including valid
	returned upon reception of an invalid message (including valid	messages but with invalid or unknown TLVs).</dd>
	messages but with invalid or unknown TLVs).</t>	<dt>Client-side errors (32-63 range):</dt><dd>The Client sent a requ
		est
	<t>Client-side errors (32-63 range): 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>Converter-side errors (64-95 range):</dt><dd> Problems encounter
	<t>Converter-side errors (64-95 range): problems encountered on	ed 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>Errors caused by the destination Server (96-127 range):</dt><dd>
	<t>Errors caused by the destination server (96-127 range): the	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>The following error codes are defined in this document:</t>	<t>The following error codes are defined in this document:</t>

		<dl spacing="normal" newline="true">
	<t><list style="symbols">	<dt>Unsupported Version (0):</dt><dd><t>The version number indicated
	<t>Unsupported Version (0): The version number indicated in the	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> This error code <bcp14>MUST</bcp14> be generated by a
	having a version number that it does not support. <vspace	peer (e.g., Transport Converter) when it receives a request
	blankLines="1" /> The value field MUST be set to the version	having a version number that it does not support. </t>
		<t> The Value field <bcp14>MUST</bcp14> be 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> 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>Malformed Message (1):</dt><dd><t>This error code is sent to
	address. <vspace blankLines="1" /> To ease troubleshooting, the	indicate that a message received from a peer cannot be
	value field MUST echo the received message using the format	successfully parsed and validated. </t>
	depicted in <xref target="shift"></xref>. This format allows to	<t> Typically, this error code is sent by the Transport
	keep the original alignment of the message that triggered the	Converter if it receives a Connect TLV enclosing a multicast,
	error. <figure anchor="shift"	broadcast, or loopback IP address. </t>
	title="Error TLV to ease Message Correlation">	<t> To ease troubleshooting, the Value field <bcp14>MUST</bcp14>
	<artwork><![CDATA[	echo the received message using the format depicted in <xref
		target="shift" format="default"/>. This format allows keeping
		the original alignment of the message that triggered the
		error. </t>
		<figure anchor="shift">
		<name>Error TLV to Ease Message Correlation</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	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>Unsupported Message (2):</dt><dd><t>This error code is sent to i
	that a message type received from a Client is not supported.	ndicate
	<vspace blankLines="1" /> To ease troubleshooting, the value	that a message type received from a Client is not supported.</t>
	field MUST echo the received message using the format shown in	<t> To ease troubleshooting, the Value field <bcp14>MUST</bcp14>
	<xref target="shift"></xref>.</t>	echo the received message using the format shown in <xref
		target="shift" format="default"/>.</t>
		</dd>


	<t>Missing Cookie (3): If a Transport Converter requires the	<dt>Missing Cookie (3):</dt><dd><t>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> A Client that receives this error code
	include it in subsequent Convert messages sent to that Transport	<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>Not Authorized (32):</dt><dd><t>This error code indicates that t
		he
	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> 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>Unsupported TCP Option (33):</dt><dd><t>A TCP option that the Cl
		ient
	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> 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>Resource Exceeded (64):</dt><dd><t>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> This error <bcp14>MUST</bcp14> be sent
	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>Network Failure (65):</dt><dd><t>This error indicates that the T
		ransport
	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> 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>Connection Reset (96):</dt><dd>This error indicates that the fin
	destination responded with an RST segment. The Value field MUST	al
	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>Destination Unreachable (97):</dt><dd><t>This error indicates th
		at 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>As a reminder, TCP implementations are 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><xref target="tab-error-types" format="default"/> summarizes the di
		fferent
	error codes.</t>	error codes.</t>


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

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


	<section anchor="sec-tcpoptions"	<section anchor="sec-tcpoptions" numbered="true" toc="default">
	title="Compatibility of Specific TCP Options with the Conversion Se	<name>Compatibility of Specific TCP Options with the Conversion Service</n
	rvice">	ame>
	<t>In this section, we discuss how several deployed standard track TCP	<t>In this section, we discuss how several deployed Standards 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="default">
	<section anchor="base-tcp-options" title="Base TCP Options">	<name>Base TCP Options</name>
	<t>Three TCP options were initially defined in <xref	<t>Three TCP options were initially defined in <xref target="RFC0793"
	target="RFC0793"></xref>: End-of-Option List (Kind=0), No-Operation	format="default"/>: End-of-Option List (Kind=0), No-Operation (Kind=1),
	(Kind=1) and Maximum Segment Size (Kind=2). The first two options are	and Maximum Segment Size (Kind=2). The first two options are mainly
	mainly used to pad the TCP header. There is no reason for a client to	used to pad the TCP header. There is no reason for a Client to request
	request a Transport Converter to specifically send these options	a Transport Converter to specifically send these options towards the
	towards the final destination.</t>	final destination.</t>

	<t>The Maximum Segment Size option (Kind=2) is used by a host to	<t>The Maximum Segment Size option (Kind=2) is used by a host to
	indicate the largest segment that it can receive over each connection.	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>A Transport Converter <bcp14>MUST</bcp14> ignore options with Kind=0,
	they appear in a Connect TLV. It MUST NOT announce them in a Supported	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" title="Window Scale (WS)">	<section anchor="window-scale-ws" numbered="true" toc="default">
		<name>Window Scale (WS)</name>
	<t>The Window Scale (WS) option (Kind=3) is defined in <xref	<t>The Window Scale (WS) option (Kind=3) is defined in <xref

	target="RFC7323"></xref>. As for the MSS option, the window scale	target="RFC7323" format="default"/>. As for the MSS option, the window
	factor that is used for a connection strongly depends on the TCP stack	scale factor that is used for a connection strongly depends on the TCP
	that handles the connection. When a Transport Converter opens a TCP	stack that handles the connection. When a Transport Converter opens a
	connection towards a remote server on behalf of a Client, it SHOULD	TCP connection towards a remote Server on behalf of a Client, it
	use a WS option with a scaling factor that corresponds to the	<bcp14>SHOULD</bcp14> use a WS option with a scaling factor that
	configuration of its stack. A local configuration MAY allow for WS	corresponds to the configuration of its stack. A local configuration
	option in the proxied message to be function of the scaling factor of	<bcp14>MAY</bcp14> allow for a WS option in the proxied message to be
	the incoming connection.</t>	a function of the scaling factor of the incoming connection.</t>
		<t>From a deployment viewpoint, there is no benefit in enabling a
	<t>There is no benefit from a deployment viewpoint in 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.

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


	<section anchor="selective-acknowledgments"	<section anchor="selective-acknowledgments" numbered="true" toc="default">
	title="Selective Acknowledgments">	<name>Selective Acknowledgments</name>
	<t>Two distinct TCP options were defined to support selective	<t>Two distinct TCP options were defined to support Selective
	acknowledgments in <xref target="RFC2018"></xref>. This first one,	Acknowledgment (SACK) in <xref target="RFC2018" format="default"/>. This
	SACK Permitted (Kind=4), is used to negotiate the utilization of	first one,
	selective acknowledgments during the three-way handshake. The second	SACK-Permitted (Kind=4), is used to negotiate the utilization of
	one, SACK (Kind=5), carries the selective acknowledgments inside	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>The SACK-Permitted option (Kind=4) <bcp14>MAY</bcp14> be advertised b
	<t>The SACK Permitted option (Kind=4) MAY be advertised by a Transport	y 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>The SACK option (Kind=5) cannot be used during the three-way	<t>The SACK option (Kind=5) cannot be used during the 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="default">
	<section anchor="timestamp" title="Timestamp">	<name>Timestamp</name>
	<t>The Timestamp option <xref target="RFC7323"></xref> can be used	<t>The Timestamp option <xref target="RFC7323" format="default"/> 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>A Transport Converter <bcp14>MAY</bcp14> advertise the Timestamp opti
	<t>A Transport Converter MAY advertise the Timestamp option (Kind=8)	on (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="default">
	<section anchor="multipath-tcp" title="Multipath TCP">	<name>Multipath TCP</name>
	<t>The Multipath TCP options are defined in <xref	<t>The Multipath TCP options are defined in <xref target="RFC8684"
	target="RFC6824"></xref>. <xref target="RFC6824"></xref> defines one	format="default"/>, which 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"/>. 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>A Transport Converter that supports Multipath TCP conversion
	<t>A Transport Converter which supports Multipath TCP conversion	service <bcp14>MUST</bcp14> advertise the Multipath TCP option (Kind=30)
	service MUST advertise the Multipath TCP option (Kind=30) in the	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="default">
	<section anchor="tcp-fast-open" title="TCP Fast Open">	<name>TCP Fast Open</name>
	<t>The TCP Fast Open cookie option (Kind=34) is defined in <xref	<t>The TCP Fast Open Cookie option (Kind=34) is defined in <xref target=
	target="RFC7413"></xref>. There are two different usages of this	"RFC7413" format="default"/>. 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>A Transport Converter <bcp14>MAY</bcp14> advertise the TCP Fast Open
	<t>A Transport Converter MAY advertise the TCP Fast Open cookie option	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>If such a Transport Converter receives a Connect TLV with the TCP	<t>If such a Transport Converter receives a Connect TLV 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="RFC7413"></xref>. This SYN-ACK may contain a Fast Open option	target="RFC7413" sectionFormat="of" section="4.1.2"/>. This SYN-ACK
	with a cookie. Upon receipt of the SYN-ACK by the Converter, it relays	may contain a Fast Open option with a cookie. Upon receipt of the
	Fast Open option with the cookie to the Client.</t>	SYN-ACK by the Converter, it relays the Fast Open option with the cookie
		to the Client.</t>
	<t>If such a Transport Converter receives a Connect TLV with the TCP	<t>If such a Transport Converter receives a Connect TLV with the TCP

	Fast Open cookie option that contains a cookie, it MUST copy the TCP	Fast Open Cookie option that contains a cookie, it <bcp14>MUST</bcp14> c
	Fast Open cookie option in the SYN sent to the remote server.</t>	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="default">
	<section anchor="tcp-ao" title="TCP-AO">	<name>TCP-AO</name>
	<t>TCP-AO <xref target="RFC5925"></xref> provides a technique to	<t>The TCP Authentication Option (TCP-AO) <xref target="RFC5925"
	authenticate all the packets exchanged over a TCP connection. Given	format="default"/> provides a technique to authenticate all the
	the nature of this extension, it is unlikely that the applications	packets exchanged over a TCP connection. Given the nature of this
	that require their packets to be authenticated end-to-end would want	extension, it is unlikely that the applications that require their
	their connections to pass through a converter. For this reason, we do	packets to be authenticated end to end would want their connections to
	not recommend the support of the TCP-AO option by Transport	pass through a converter. For this reason, we do not recommend the
	Converters. The only use cases where it could make sense to combine	support of the TCP-AO by Transport Converters. The only use
	TCP-AO and the solution in this document are those where the	cases where it could make sense to combine TCP-AO and the solution in
	TCP-AO-NAT extension <xref target="RFC6978"></xref> is in use.</t>	this document are those where the TCP-AO-NAT extension <xref
		target="RFC6978" format="default"/> is in use.</t>
	<t>A Transport Converter MUST NOT advertise the TCP-AO option	<t>A Transport Converter <bcp14>MUST NOT</bcp14> advertise 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="default">
	<section anchor="sec-middleboxes" title="Interactions with Middleboxes">	<name>Interactions with Middleboxes</name>
	<t>The Convert Protocol is designed to be used in networks that do not	<t>The Convert Protocol is designed to be used in networks 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>Nevertheless, and in order to allow for a robust service, this	<t>Nevertheless, and in order to allow for a robust service, 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>Internet measurements <xref target="IMC11" format="default"/> have show
	<t>Internet measurements <xref target="IMC11"></xref> have shown that	n 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>Consider a middlebox that removes the SYN payload. The Client can	<t>Consider a middlebox that removes the SYN payload. The 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>Consider now a middlebox that drops SYN/ACKs with a payload. The	<t>Consider now a middlebox that drops SYN/ACKs with a payload. The
	Client won't be able to establish a connection via the Transport	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>As explained in <xref target="RFC7413" format="default"/>, some
	<t>As explained in <xref target="RFC7413"></xref>, some CGNs (Carrier	Carrier Grade NATs (CGNs) can affect the operation of TFO if they assign
	Grade NATs) can affect the operation of TFO if they assign different IP	different IP addresses to the same end host. Such CGNs could affect the
	addresses to the same end host. Such CGNs could affect the operation of	operation of the cookie validation used by the Convert Protocol. As a
	the cookie validation used by the Convert Protocol. As a reminder CGNs,	reminder, CGNs that are enabled on the path between a Client and a Transpo
	enabled on the path between a Client and a Transport Converter, must	rt
	adhere to the address preservation defined in <xref	Converter must adhere to the address preservation defined in <xref
	target="RFC6888"></xref>. See also the discussion in Section 7.1 of	target="RFC6888" format="default"/>. See also the discussion in <xref
	<xref target="RFC7413"></xref>.</t>	target="RFC7413" sectionFormat="of" section="7.1"/>.</t>
	</section>	</section>

		<section anchor="sec-security" numbered="true" toc="default">
	<section anchor="sec-security" title="Security Considerations">	<name>Security Considerations</name>
	<t>An implementation MUST check that the Convert TLVs are properly	<t>An implementation <bcp14>MUST</bcp14> check that the Convert TLVs are p
		roperly
	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"/>).</t>

	<t>Additional security considerations are discussed in the following	<t>Additional security considerations are discussed in the following

	sub-sections.</t>	subsections.</t>
		<section anchor="privacy-ingress-filtering" numbered="true" toc="default">
	<section anchor="privacy-ingress-filtering"	<name>Privacy & Ingress Filtering</name>
	title="Privacy & Ingress Filtering">
	<t>The Transport Converter may have access to privacy-related	<t>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>Given its function and location in the network, a Transport	<t>Given its function and location in the network, a 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"/>).</t>
	<t>Furthermore, ingress filtering policies MUST be enforced at the
	network boundaries <xref target="RFC2827"></xref>.</t>


		<t>Furthermore, ingress filtering policies <bcp14>MUST</bcp14> be enforc
		ed at the
		network boundaries <xref target="RFC2827" format="default"/>.</t>
	<t>This document assumes that all network attachments are managed by	<t>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="default">
	<section anchor="authorization"	<name>Authentication and Authorization Considerations</name>
	title="Authentication and Authorization Considerations">	<t>The Convert Protocol is <bcp14>RECOMMENDED</bcp14> for use in a manag
	<t>The Convert Protocol is RECOMMENDED to be used in a managed network	ed 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>One possibility for mutual authentication is to use TLS to perform	<t>One possibility for mutual authentication is to use 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"></xref> or raw public key based client authentication	target="RFC4279" format="default"/>, or raw public key-based Client
	<xref target="RFC7250"></xref> to secure this connection. If the	authentication <xref target="RFC7250" format="default"/> to secure
	authentication succeeds, the Converter returns a cookie to the Client.	this connection. If the authentication succeeds, the Converter returns
	Subsequent Connect messages will be authorized as a function of the	a cookie to the Client. Subsequent Connect messages will be
	content of the Cookie TLV. An attacker from within the network between	authorized as a function of the content of the Cookie TLV. An attacker
	a Client and a Transport Converter may intercept the Cookie and use it	from within the network between a Client and a Transport Converter may
	to be granted access to the conversion service. Such attack is only	intercept the Cookie and use it to be granted access to the conversion
	possible if the attacker spoofs the IP address of the Client and the	service. Such an attack is only possible if the attacker spoofs the IP
	network does not filter packets with source spoofed IP addresses. </t>	address of the Client and the network does not filter packets with
		source-spoofed IP addresses. </t>
	<t>The operator that manages the various network attachments	<t>The operator that manages the various network attachments
	(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">
	<t><list style="symbols">	<li>The network provider may enforce a policy based on the
	<t>The network provider may enforce a policy based 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>The network provider may enforce a policy based upon Access
	<t>The network provider may enforce a policy based 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"/>. This 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>A device that embeds a Transport Converter may also host a
	<t>A device that embeds a Transport Converter may also host a	RADIUS Client that will solicit a AAA Server to check whether or
	RADIUS client that will solicit an AAA server to check whether	not connections received from a given source IP address are
	connections received from a given source IP address are authorized	authorized <xref target="I-D.boucadair-opsawg-tcpm-converter"
	or not <xref	format="default"/>.</li>
	target="I-D.boucadair-radext-tcpm-converter"></xref>.</t>	</ul>
	</list></t>

	<t>A first safeguard against the misuse of Transport Converter	<t>A first safeguard against the misuse of Transport 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>In deployments where network-assisted connections are not allowed	<t>In deployments where network-assisted connections 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"
	target="fig-hairp"></xref>.</t>	format="default"/>).</t>
		<figure anchor="fig-hairp">
	<figure anchor="fig-hairp" title="Hairpinning Example">	<name>Hairpinning Example</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	<===Network Provider===>	<===Network Provider===>

	+----+ from X1:x1 to X2':x2' +-----+ X1':x1'	+----+ from X1:x1 to X2':x2' +-----+ X1':x1'
	\| C1 \|>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---	\| C1 \|>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---
	+----+ \| 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 \|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---	\| C2 \|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---
	+----+ +-----+	+----+ +-----+
	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="default">
	<section anchor="denial-of-service" title="Denial of Service">	<name>Denial of Service</name>
	<t>Another possible risk is the amplification attacks since a	<t>Another possible risk is amplification attacks, since a Transport
	Transport Converter sends a SYN towards a remote Server upon reception	Converter sends a SYN towards a remote Server upon reception of a SYN
	of a SYN from a Client. This could lead to amplification attacks if	from a Client. This could lead to amplification attacks if the SYN
	the SYN sent by the Transport Converter were larger than the SYN	sent by the Transport Converter were larger than the SYN received from
	received from the Client or if the Transport Converter retransmits the	the Client, or if the Transport Converter retransmits the SYN. To
	SYN. To mitigate such attacks, the Transport Converter SHOULD rate	mitigate such attacks, the Transport Converter <bcp14>SHOULD</bcp14>
	limit the number of pending requests for a given Client. It SHOULD	rate-limit the number of pending requests for a given Client. It
	also avoid sending to remote Servers SYNs that are significantly	<bcp14>SHOULD</bcp14> also avoid sending SYNs that are significantly
	longer than the SYN received from the Client. Finally, the Transport	longer than the SYN received from the Client, to remote
	Converter SHOULD only retransmit a SYN to a Server after having	Servers. Finally, the Transport Converter <bcp14>SHOULD</bcp14> only
	received a retransmitted SYN from the corresponding Client. Means to	retransmit a SYN to a Server after having received a retransmitted SYN
	protect against SYN flooding attacks should also be enabled (e.g.,	from the corresponding Client. Means to protect against SYN flooding
	Section 3 of <xref target="RFC4987"></xref>).</t>	attacks should also be enabled (e.g., <xref target="RFC4987"
		sectionFormat="of" section="3"/>).</t>
	<t>Attacks from within the network between a Client and a Transport	<t>Attacks from within the network between a Client and 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" title="Traffic Theft">	<section anchor="traffic-theft" numbered="true" toc="default">
		<name>Traffic Theft</name>
	<t>Traffic theft is a risk if an illegitimate Converter is inserted in	<t>Traffic theft is a risk if an illegitimate Converter 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="default">
	<section title="Logging">	<name>Logging</name>
	<t>If the Converter is configured to behave in the address sharing	<t>If the Converter is configured to behave in the address-sharing
	mode (<xref target="sec-adds"></xref>), the logging recommendations	mode (<xref target="sec-adds" format="default"/>), the logging recommend
	discussed in Section 4 of <xref target="RFC6888"></xref> need to be	ations
	considered. Security-related issues encountered in address sharing	discussed in <xref target="RFC6888" sectionFormat="of" section="4"/> nee
	environments are documented in Section 13 of <xref	d to be
	target="RFC6269"></xref>.</t>	considered. Security-related issues encountered in address-sharing
		environments are documented in <xref target="RFC6269"
		sectionFormat="of" section="13"/>.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="sec-iana" numbered="true" toc="default">
		<name>IANA Considerations</name>


	<section anchor="sec-iana" title="IANA Considerations">	<section anchor="sec-service" numbered="true" toc="default">
	<t>Note to the RFC Editor: Please replace "THISRFC" in the following	<name>Convert Service Name</name>
	sub-sections with the RFC number to be assigned to this document.</t>	<t>IANA has assigned a
		service name for the Convert Protocol from the "Service Name and
	<section anchor="sec-service" title="Convert Service Name">	Transport Protocol Port Number Registry" available at
	<t>IANA is requested to assign a service name for the Convert Protocol	<<eref target="https://www.iana.org/assignments/service-names-port-nu
	from the "Service Name and Transport Protocol Port Number Registry"	mbers"/>>.</t>
	available at
	https://www.iana.org/assignments/service-names-port-numbers/service-name
	s-port-numbers.xhtml.</t>


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


	<t>Clients may use this service name to fed the procedure defined in	<t>Clients may use this service name to feed the procedure defined in
	<xref target="RFC2782"></xref> to discover the IP address(es) and the	<xref target="RFC2782" format="default"/> 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="default">
	title="The Convert Protocol (Convert) Parameters">	<name>The Convert Protocol (Convert) Parameters</name>
	<t>IANA is requested to create a new "The TCP Convert Protocol	<t>IANA has created a new "TCP Convert Protocol
	(Convert) Parameters" registry.</t>	(Convert) Parameters" registry.</t>

		<t>The following subsections detail new registries within the "Convert
	<t>The following subsections detail new registries within "The Convert
	Protocol (Convert) Parameters" registry.</t>	Protocol (Convert) Parameters" registry.</t>

		<t>The designated expert is expected to ascertain the existence of
	<t>The Designated Expert is expected to ascertain the existence of	suitable documentation as described in <xref
	suitable documentation as described in Section 4.6 of <xref	target="RFC8126" sectionFormat="of" section="4.6"/> and to verify that th
	target="RFC8126"></xref> and to verify that the document is	e document is
	permanently and publicly available. The Designated Expert is also	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>Also, criteria that should be applied by the designated 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="default">
		<name>Convert Versions</name>
		<t>IANA has created the "Convert Versions" subregistry.
		New values are assigned via IETF Review (<xref target="RFC8126"
		sectionFormat="of" section="4.8"/>).</t>
		<t>The initial values of the registry
	are as follows:</t>	are as follows:</t>


	<figure anchor="ver" title="Current Convert Versions">	<table anchor="ver">
	<artwork><![CDATA[ +---------+--------------------------------------	<name>Current Convert Versions</name>
	+-------------+	<thead>
	\| Version \| Description \| Reference \|	<tr>
	+---------+--------------------------------------+-------------+	<th>Version</th>
	\| 0 \| Reserved \| THISRFC \|	<th>Description</th>
	\| 1 \| Assigned \| THISRFC \|	<th>Reference</th>
	+---------+--------------------------------------+-------------+	</tr>
	]]></artwork>	</thead>
	</figure>	<tbody>
	</section>	<tr>
		<td>0</td>
	<section anchor="convert-tlvs" title="Convert TLVs">	<td>Reserved</td>
	<t>IANA is requested to create the "Convert TLVs" sub-registry. The	<td>RFC 8803</td>
	procedure for assigning values from this registry is as follows:</t>	</tr>
		<tr>
	<t><list style="symbols">	<td>1</td>
	<t>The values in the range 1-127 can be assigned via IETF	<td>Assigned</td>
	Review.</t>	<td>RFC 8803</td>
		</tr>
	<t>The values in the range 128-191 can be assigned via	</tbody>
	Specification Required.</t>	</table>

	<t>The values in the range 192-255 are reserved for Private
	Use.</t>
	</list></t>


	<t>The initial values to be assigned at the creation of the registry	</section>
		<section anchor="convert-tlvs" numbered="true" toc="default">
		<name>Convert TLVs</name>
		<t>IANA has created the "Convert TLVs" subregistry. The
		procedures for assigning values from this registry are as follows:</t>
		<dl indent="10">
		<dt>1-127:</dt><dd>IETF Review</dd>
		<dt>128-191:</dt><dd>Specification Required</dd>
		<dt>192-255:</dt><dd>Private Use</dd>
		</dl>
		<t>The initial values of the registry
	are as follows:</t>	are as follows:</t>


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


	<section anchor="convert-error-messages"	</section>
	title="Convert Error Messages">	<section anchor="convert-error-messages" numbered="true" toc="default">
	<t>IANA is requested to create the "Convert Errors" sub-registry.	<name>Convert Error Messages</name>
		<t>IANA has created the "Convert Errors" subregistry.
	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">
	<t><list style="symbols">	<dt>0-31:</dt><dd>Message validation and processing errors</dd>
	<t>Message validation and processing errors: 0-31</t>	<dt>32-63:</dt><dd>Client-side errors</dd>
		<dt>64-95:</dt><dd>Transport Converter-side errors</dd>
	<t>Client-side errors: 32-63</t>	<dt>96-127:</dt><dd>Errors caused by destination Server</dd>
		</dl>
	<t>Transport Converter-side errors: 64-95</t>	<t>The procedures for assigning values from this subregistry are as

	<t>Errors caused by destination server: 96-127</t>
	</list></t>

	<t>The procedure for assigning values from this sub-registry is as
	follows:</t>	follows:</t>

		<dl spacing="normal" indent="10">
	<t><list style="symbols">	<dt>0-127:</dt><dd>IETF Review</dd>
	<t>0-127: Values in this range are assigned via IETF Review.</t>	<dt>128-191:</dt><dd>Specification Required</dd>
		<dt>192-255:</dt><dd>Private Use</dd>
	<t>128-191: Values in this range are assigned via Specification	</dl>
	Required.</t>	<t>The initial values of the registry

	<t>192-255: Values in this range are reserved for Private
	Use.</t>
	</list></t>

	<t>The initial values to be assigned at the creation of the registry
	are as follows:</t>	are as follows:</t>


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

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


	<back>	<back>

	<references title="Normative References">
	<reference anchor="RFC0793"
	target="https://www.rfc-editor.org/info/rfc793">
	<front>
	<title>Transmission Control Protocol</title>

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

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

	<seriesInfo name="STD" value="7" />

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	<reference anchor="RFC2119"
	target="https://www.rfc-editor.org/info/rfc2119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement
	Levels</title>

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

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

	<abstract>
	<t>In many standards track documents several words are used to
	signify the requirements in the specification. These words are
	often capitalized. This document defines these words as they
	should be interpreted in IETF documents. This document specifies
	an Internet Best Current Practices for the Internet Community, and
	requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>

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

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

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

	<reference anchor="RFC8174"
	target="https://www.rfc-editor.org/info/rfc8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
	Words</title>

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

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

	<abstract>
	<t>RFC 2119 specifies common key words that may be used in
	protocol specifications. This document aims to reduce the
	ambiguity by clarifying that only UPPERCASE usage of the key words
	have the defined special meanings.</t>
	</abstract>
	</front>

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

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

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

	<reference anchor="RFC5925"
	target="https://www.rfc-editor.org/info/rfc5925">
	<front>
	<title>The TCP Authentication Option</title>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	<abstract>
	<t>This document defines basic terminology for describing
	different types of Network Address Translation (NAT) behavior when
	handling Unicast UDP and also defines a set of requirements that
	would allow many applications, such as multimedia communications
	or online gaming, to work consistently. Developing NATs that meet
	this set of requirements will greatly increase the likelihood that
	these applications will function properly. This document specifies
	an Internet Best Current Practices for the Internet Community, and
	requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>

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

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

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

	<reference anchor="RFC7323"
	target="https://www.rfc-editor.org/info/rfc7323">
	<front>
	<title>TCP Extensions for High Performance</title>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	<abstract>
	<t>This paper discusses a simple, effective, and straightforward
	method for using ingress traffic filtering to prohibit DoS (Denial
	of Service) attacks which use forged IP addresses to be propagated
	from 'behind' an Internet Service Provider's (ISP) aggregation
	point. This document specifies an Internet Best Current Practices
	for the Internet Community, and requests discussion and
	suggestions for improvements.</t>
	</abstract>
	</front>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	<abstract>
	<t>This memo describes a protocol that is an evolution of the
	previous version of the protocol, version 4 [1]. This new protocol
	stems from active discussions and prototype implementations.
	[STANDARDS-TRACK]</t>
	</abstract>
	</front>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


	<author fullname="A. Durand" initials="A." surname="Durand">	<displayreference target="I-D.boucadair-tcpm-dhc-converter" to="DHC-CONVERTER"/>
	<organization></organization>	<displayreference target="I-D.olteanu-intarea-socks-6" to="INTAREA-SOCKS"/>
	</author>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	<format target="http://www.ietf.org/internet-drafts/draft-boucadair-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">	<displayreference target="I-D.boucadair-mptcp-plain-mode" to="MPTCP-PLAIN"/>
	<organization></organization>
	</author>


	<author fullname="Sebastien Barre" initials="S" surname="Barre">	<displayreference target="I-D.peirens-mptcp-transparent" to="MPTCP-TRANSPARENT"/
	<organization></organization>	>
	</author>	<displayreference target="I-D.arkko-arch-low-latency" to="LOW-LATENCY"/>
		<displayreference target="I-D.boucadair-opsawg-tcpm-converter" to="TCPM-CONVERTE
		R"/>


	<author fullname="Olivier Bonaventure" initials="O"	<references>
	surname="Bonaventure">	<name>References</name>
	<organization></organization>	<references>
	</author>	<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.0793.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4291.xml"/>


	<date day="8" month="July" year="2016" />	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8684.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7413.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4987.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5925.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8126.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6890.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6888.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4787.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7323.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2018.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2827.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5461.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6731.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6978.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2782.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4279.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7250.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.1812.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.1919.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.1928.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3135.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7414.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6887.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6928.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8041.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8305.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8446.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6269.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6296.xml"/>


	<abstract>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
	<t>This document describes the utilisation of the transparent	I-D.boucadair-tcpm-dhc-converter.xml"/>
	Multipath TCP mode to enable network operators to provide link	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	bonding services in hybrid access networks.</t>	FC.8548.xml"/>
	</abstract>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
	</front>	rence.I-D.olteanu-intarea-socks-6.xml"/>


	<seriesInfo name="Internet-Draft"	<reference anchor='I-D.boucadair-mptcp-plain-mode'>
	value="draft-peirens-mptcp-transparent-00" />


	<format target="http://www.ietf.org/internet-drafts/draft-peirens-mptcp-	<front>
	transparent-00.txt"	<title>Extensions for Network-Assisted MPTCP Deployment Models</title>
	type="TXT" />
	</reference>


	<reference anchor="I-D.arkko-arch-low-latency">	<author initials='M' surname='Boucadair' fullname='Mohamed Boucadair'> <organ
	<front>	ization />
	<title>Low Latency Applications and the Internet	</author>
	Architecture</title>


	<author fullname="Jari Arkko" initials="J" surname="Arkko">	<author initials='C' surname='Jacquenet' fullname='Christian Jacquenet'> <org
	<organization></organization>	anization />
	</author>	</author>


	<author fullname="Jeff Tantsura" initials="J" surname="Tantsura">	<author initials='O' surname='Bonaventure' fullname='Olivier Bonaventure'> <o
	<organization></organization>	rganization />
	</author>	</author>


	<date day="30" month="October" year="2017" />	<author initials='D' surname='Behaghel' fullname='Denis Behaghel'> <organizat
		ion />
		</author>


	<abstract>	<author initials='S' surname='Secci' fullname='Stefano Secci'> <organization
	<t>Some recent Internet technology developments relate to	/>
	improvements in communications latency. For instance, improvements	</author>
	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"	<author initials='W' surname='Henderickx' fullname='Wim Henderickx'> <organiz
	value="draft-arkko-arch-low-latency-02" />	ation />
		</author>


	<format target="http://www.ietf.org/internet-drafts/draft-arkko-arch-low	<author initials='R' surname='Skog' fullname='Robert Skog'> <organization />
	-latency-02.txt"	</author>
	type="TXT" />
	</reference>


	<reference anchor="I-D.boucadair-radext-tcpm-converter">	<author initials='S' surname='Vinapamula' fullname='Suresh Vinapamula'> <orga
	<front>	nization />
	<title>RADIUS Extensions for 0-RTT TCP Converters</title>	</author>


	<author fullname="Mohamed Boucadair" initials="M"	<author initials='S' surname='Seo' fullname='SungHoon Seo'> <organization />
	surname="Boucadair">	</author>
	<organization></organization>
	</author>


	<author fullname="Christian Jacquenet" initials="C"	<author initials='W' surname='Cloetens' fullname='Wouter Cloetens'> <organiza
	surname="Jacquenet">	tion />
	<organization></organization>	</author>
	</author>


	<date day="15" month="April" year="2019" />	<author initials='U' surname='Meyer' fullname='Ullrich Meyer'> <organization
		/>
		</author>


	<abstract>	<author initials='L' surname='Contreras' fullname='Luis Contreras'> <organizat
	<t>Because of the lack of Multipath TCP (MPTCP) support at the	ion />
	server side, some service providers now consider a	</author>
	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"	<author initials='B' surname='Peirens' fullname='Bart Peirens'> <organization /
	value="draft-boucadair-radext-tcpm-converter-02" />	>
		</author>


	<format target="http://www.ietf.org/internet-drafts/draft-boucadair-rade	<date month='March' year='2017' />
	xt-tcpm-converter-02.txt"	</front>
	type="TXT" />	<seriesInfo name='Internet-Draft' value='draft-boucadair-mptcp-plain-mode-10' />
	</reference>	</reference>


	<reference anchor="TS23501"	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
	target="https://www.3gpp.org/ftp/Specs/archive/23_series/23.501	rence.I-D.peirens-mptcp-transparent.xml"/>
	/">	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
	<front>	rence.I-D.arkko-arch-low-latency.xml"/>
	<title>Technical Specification Group Services and System Aspects;	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
	System Architecture for the 5G System; Stage 2 (Release 16)</title>	rence.I-D.boucadair-opsawg-tcpm-converter.xml"/>


	<author initials="."	<reference anchor="IANA-CONVERT" target="https://www.iana.org/assignments/tcp-co
	surname="3GPP (3rd Generation Partnership Project)">	nvert-protocol-parameters/tcp-convert-protocol-parameters.xhtml">
	<organization></organization>	<front>
	</author>	<title>TCP Convert Protocol (Convert) Parameters
		</title>
		<author>
		<organization>IANA
		</organization>
		</author>
		</front>
		</reference>


	<date year="2019" />	<reference anchor="TS23501" target="https://www.3gpp.org/ftp/Specs/archi
	</front>	ve/23_series/23.501/">
	</reference>	<front>
		<title>Technical Specification Group Services and System Aspects;
		System architecture for the 5G System; Stage 2 (Release 16)</title>
		<author>
		<organization>3GPP (3rd Generation Partnership Project)
		</organization>
		</author>
		<date year="2019"/>
		</front>
		</reference>


	<reference anchor="Fukuda2011">	<reference anchor="Fukuda2011">
	<front>	<front>
	<title>An Analysis of Longitudinal TCP Passive Measurements (Short	<title>An Analysis of Longitudinal TCP Passive Measurements (Short
	Paper)</title>	Paper)</title>

		<author initials="K." surname="Fukuda">
		<organization/>
		</author>
		<date year="2011"/>
		</front>


	<author initials="K." surname="Fukuda">	<refcontent>Traffic Monitoring and Analysis</refcontent>
	<organization></organization>	<refcontent>TMA 2011</refcontent>
	</author>	<refcontent>Lecture Notes in Computer Science, vol. 6613</refcontent>
		</reference>
	<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">	<reference anchor="ANRW17">
	<organization></organization>	<front>
	</author>	<title>Tracking transport-layer evolution with PATHspider</title>
		<author initials="B." surname="Trammell">
		<organization/>
		</author>
		<author initials="M." surname="Kuehlewind">
		<organization/>
		</author>
		<author initials="P." surname="De Vaere">
		<organization/>
		</author>
		<author initials="I." surname="Learmonth">
		<organization/>
		</author>
		<author initials="G." surname="Fairhurst">
		<organization/>
		</author>
		<date month="July" year="2017"/>
		</front>
		<refcontent>Applied Networking Research Workshop 2017 (ANRW17)</refcontent>
		</reference>


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


	<author initials="O." surname="Bonaventure">	<reference anchor="IETFJ16">
	<organization></organization>	<front>
	</author>	<title>Multipath TCP Deployments</title>


	<date month="December" year="2013" />	<author initials="O." surname="Bonaventure">
	</front>	<organization/>
		</author>
		<author initials="S." surname="Seo">
		<organization/>
		</author>
		<date month="November" year="2016"></date>
		</front>
		<refcontent>IETF Journal</refcontent>
		<refcontent>Vol. 12, Issue 2</refcontent>
		</reference>


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


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


	<figure>	<artwork name="" type="" align="left" alt=""><![CDATA[
	<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 *) &server_addr, addr_len);
	]]></artwork>	]]></artwork>

	</figure>


	<t>The client side of the Linux TCP TFO can be used in two different	<t>The Client side of the Linux 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>
		<dt>0x1:</dt><dd>(client) enables sending data in the opening SYN on t
		he
		Client.</dd>
		<dt>0x4:</dt><dd>(client) enables sending data in the opening SYN rega
		rdless of cookie
		availability and without a cookie option.</dd>
		</dl>


	<t><list style="symbols">	<t>By setting this configuration variable to 0x5, a Linux Client using
	<t>0x1: (client) enables sending data in the opening SYN on the
	client.</t>

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

	<t>By setting this configuration variable to 0x5, a Linux 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="default
	<section anchor="passive-open-converter-side"	">
	title="Passive Open (Converter Side)">	<name>Passive Open (Converter Side)</name>
	<t>The Converter needs to enable the reception of data inside the SYN	<t>The Converter needs to enable the reception of data 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><xref target="RFC7413" format="default"/> suggested the utilization o
	<t><xref target="RFC7413"></xref> suggested the utilization of a	f 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"/>
	mentioned:</t>	mentioned:</t>


	<figure>	<blockquote>
	<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>To support the 0-RTT TCP Convert Protocol, this behavior should be

	<t>To support the 0-RTT Convert Protocol, this behavior should be
	modified as follows:</t>	modified as follows:</t>

		<blockquote>
	<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>The Linux Server side can be configured with the following

	<t>The Linux server side can be configured with the following
	sysctls:</t>	sysctls:</t>

		<dl spacing="normal">
	<t><list style="symbols">	<dt>0x2:</dt><dd>(server) enables the Server support, i.e., allowing d
	<t>0x2: (server) enables the server support, i.e., allowing data	ata
	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>0x200:</dt><dd>(server) accepts data-in-SYN w/o any cookie option
	<t>0x200: (server) accept data-in-SYN w/o any cookie option	present.</dd>
	present.</t>	</dl>
	</list></t>	<t>However, this configuration is system wide. This is convenient for

	<t>However, this configuration is system-wide. This is 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>Recently, the TCP_FASTOPEN_NO_COOKIE socket option has been added	<t>Recently, the TCP_FASTOPEN_NO_COOKIE socket option 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="default">
	<section anchor="acknowledgments" numbered="no" title="Acknowledgments">	<name>Acknowledgments</name>
	<t>Although they could disagree with the contents of the document, we	<t>Although they could disagree with the contents of the document, we

	would like to thank Joe Touch and Juliusz Chroboczek whose comments on	would like to thank <contact fullname="Joe Touch"/> and <contact fullname=
	the MPTCP mailing list have forced us to reconsider the design of the	"Juliusz
	solution several times.</t>	Chroboczek"/>, whose comments on the MPTCP mailing list have forced us to
		reconsider the design of the solution several times.</t>
	<t>We would like to thank Raphael Bauduin, Stefano Secci, Anandatirtha	<t>We would like to thank <contact fullname="Raphael Bauduin"/>,
	Nandugudi and Gregory Vander Schueren for their help in preparing this	<contact fullname="Stefano Secci"/>, <contact fullname="Anandatirtha
	document. Nandini Ganesh provided valuable feedback about the handling	Nandugudi"/>, and <contact fullname="Gregory Vander Schueren"/> for their
	of TFO and the error codes. Yuchung Cheng and Praveen Balasubramanian	help in preparing this
	helped to clarify the discussion on supplying data in SYNs. Phil Eardley	document. <contact fullname="Nandini Ganesh"/> provided valuable feedback
	and Michael Scharf's helped to clarify different parts of the text.	about the handling
	Thanks to Eric Vyncke, Roman Danyliw, Benjamin Kaduk, and Alexey	of TFO and the error codes. <contact fullname="Yuchung Cheng"/> and
	Melnikov for the IESG review, and Christian Huitema for the security	<contact fullname="Praveen Balasubramanian"/>
	directorate review.</t>	helped to clarify the discussion on supplying data in SYNs. <contact fulln
		ame="Phil Eardley"/>
	<t>Many thanks to Mirja Kuehlewind for the detailed AD review.</t>	and <contact fullname="Michael Scharf"/> helped to clarify different parts
		of the text.
		Thanks to <contact fullname="Éric Vyncke"/>, <contact fullname="Roman
		Danyliw"/>, <contact fullname="Benjamin Kaduk"/>, and <contact fullname="A
		lexey
		Melnikov"/> for the IESG review, and <contact fullname="Christian Huitema"
		/> for the Security
		Directorate review.</t>
		<t>Many thanks to <contact fullname="Mirja Kühlewind"/> for the detailed A
		D review.</t>
	<t>This document builds upon earlier documents that proposed various	<t>This document builds upon earlier documents that proposed various

	forms of Multipath TCP proxies <xref	forms of Multipath TCP proxies: <xref
	target="I-D.boucadair-mptcp-plain-mode" />, <xref	target="I-D.boucadair-mptcp-plain-mode" format="default"/>, <xref
	target="I-D.peirens-mptcp-transparent" /> and <xref	target="I-D.peirens-mptcp-transparent" format="default"/>, and <xref
	target="HotMiddlebox13b" />.</t>	target="HOT-MIDDLEBOX13" format="default"/>.</t>
		<t>From <xref target="I-D.boucadair-mptcp-plain-mode" format="default"/>:<
	<t>From <xref target="I-D.boucadair-mptcp-plain-mode" />:</t>	/t>
		<t>Many thanks to <contact fullname="Chi Dung Phung"/>, <contact
	<t>Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi	fullname="Mingui Zhang"/>, <contact fullname="Rao Shoaib"/>, <contact full
	Nishida, and Christoph Paasch for their valuable comments.</t>	name="Yoshifumi
		Nishida"/>, and <contact fullname="Christoph Paasch"/> for their valuable
	<t>Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and	comments.</t>
	Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos	<t>Thanks to <contact fullname="Ian Farrer"/>, <contact fullname="Mikael
	Aires).</t>	Abrahamsson"/>, <contact fullname="Alan Ford"/>, <contact fullname="Dan
		Wing"/>, and <contact fullname="Sri Gundavelli"/> for the fruitful
	<t>Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and	discussions at IETF 95 (Buenos Aires).</t>
	Xavier Grall for their inputs.</t>	<t>Special thanks to <contact fullname="Pierrick Seite"/>, <contact
		fullname="Yannick Le Goff"/>, <contact fullname="Fred Klamm"/>, and
	<t>Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas	<contact fullname="Xavier Grall"/> for their input.</t>
	Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves	<t>Thanks also to <contact fullname="Olaf Schleusing"/>, <contact
	Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun	fullname="Martin Gysi"/>, <contact fullname="Thomas Zasowski"/>,
	Srinivasan, and Raghavendra Mallya for the discussion.</t>	<contact fullname="Andreas
		Burkhard"/>, <contact fullname="Silka Simmen"/>, <contact
		fullname="Sandro Berger"/>, <contact fullname="Michael Melloul"/>,
		<contact fullname="Jean-Yves
		Flahaut"/>, <contact fullname="Adrien Desportes"/>, <contact
		fullname="Gregory Detal"/>, <contact fullname="Benjamin David"/>,
		<contact fullname="Arun
		Srinivasan"/>, and <contact fullname="Raghavendra Mallya"/> for their inpu
		t.</t>
	</section>	</section>


	<section anchor="contributors" numbered="no" title="Contributors">	<section anchor="contributors" numbered="false" toc="default">
	<t>Bart Peirens contributed to an early version of the document.</t>	<name>Contributors</name>
		<t><contact fullname="Bart Peirens"/> contributed to an early draft versio
		n of this document.</t>
	<t>As noted above, this document builds on two previous documents.</t>	<t>As noted above, this document builds on two previous documents.</t>

		<t>The authors of <xref target="I-D.boucadair-mptcp-plain-mode" format="de
	<t>The authors of <xref target="I-D.boucadair-mptcp-plain-mode" />	fault"/>
	were:</t>	were:</t>

		<ul spacing="normal">
	<t>	<li><t><contact fullname="Mohamed Boucadair"/></t></li>
	<list style="symbols">	<li><t><contact fullname="Christian Jacquenet"/></t></li>
	<t>Mohamed Boucadair</t>	<li><t><contact fullname="Olivier Bonaventure"/></t></li>
		<li><t><contact fullname="Denis Behaghel"/></t></li>
	<t>Christian Jacquenet</t>	<li><t><contact fullname="Stefano Secci"/></t></li>
		<li><t><contact fullname="Wim Henderickx"/></t></li>
	<t>Olivier Bonaventure</t>	<li><t><contact fullname="Robert Skog"/></t></li>
		<li><t><contact fullname="Suresh Vinapamula"/></t></li>
	<t>Denis Behaghel</t>	<li><t><contact fullname="SungHoon Seo"/></t></li>
		<li><t><contact fullname="Wouter Cloetens"/></t></li>
	<t>Stefano Secci</t>	<li><t><contact fullname="Ullrich Meyer"/></t></li>
		<li><t><contact fullname="Luis M. Contreras"/></t></li>
	<t>Wim Henderickx</t>	<li><t><contact fullname="Bart Peirens"/></t></li>
		</ul>
	<t>Robert Skog</t>	<t>The authors of <xref target="I-D.peirens-mptcp-transparent" format="def
		ault"/>
	<t>Suresh Vinapamula</t>

	<t>SungHoon Seo</t>

	<t>Wouter Cloetens</t>

	<t>Ullrich Meyer</t>

	<t>Luis M. Contreras</t>

	<t>Bart Peirens</t>
	</list>
	</t>

	<t>The authors of <xref target="I-D.peirens-mptcp-transparent" />
	were:</t>	were:</t>

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

	<t>Sebastien Barre</t>

	<t>Olivier Bonaventure</t>
	</list>
	</t>
	</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. 386 change blocks.
	3582 lines changed or deleted	1771 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/