One document matched: draft-cheshire-tcp-over-udp-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-cheshire-tcp-over-udp-00" ipr="trust200902">
<front>
<title abbrev="TCP-over-UDP">Encapsulation of TCP and other Transport Protocols over UDP</title>
<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
<organization abbrev="Apple">Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>California</region>
<code>95014</code>
<country>USA</country>
</postal>
<phone>+1 408 974 3207</phone>
<email>cheshire@apple.com</email>
</address>
</author>
<author fullname="Josh Graessley" initials="J." surname="Graessley">
<organization abbrev="Apple">Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>California</region>
<code>95014</code>
<country>USA</country>
</postal>
<phone>+1 408 974 5710</phone>
<email>jgraessley@apple.com</email>
</address>
</author>
<author fullname="Rory McGuire" initials="R." surname="McGuire">
<organization abbrev="Apple">Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>California</region>
<code>95014</code>
<country>USA</country>
</postal>
<phone>+1 408 862 3633</phone>
<email>rlpm@apple.com</email>
</address>
</author>
<date day='30' month='June' year='2013'/>
<abstract>
<t>Encapsulation of TCP and other transport protocols over UDP
enables use of UDP-based NAT traversal techniques with other
transport protocols.</t>
</abstract>
</front>
<middle>
<section anchor="terminology" title="Conventions and Terminology Used in this Document">
<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 "Key words for use
in RFCs to Indicate Requirement Levels" <xref target="RFC2119"/>.</t>
</section>
<?rfc needLines="5" ?>
<section anchor="intro" title="Introduction">
<t>To establish direct communication between two devices that are both
behind NAT gateways,
<xref target="RFC5245">Interactive Connectivity Establishment (ICE)</xref>
is used to create the necessary mappings in both NAT gateways.
While, in principle, ICE should work for both TCP and UDP,
recent work has shown that in practice success rates are higher using UDP
<xref target="RFC5128">(about 80% for UDP, compared to 60% for TCP)</xref>.</t>
<t>However, many applications want flow control, congestion
control, reliability, and other properties provided by TCP. Hence
it would be desirable to encapsulate TCP over UDP, to provide the
transport protocol capabilities provided by TCP, combined with the
NAT-traversal capability available with UDP.</t>
<t>Using <xref target="RFC5245">ICE</xref> entails sending and receiving
<xref target="RFC5389">STUN</xref> packets. Therefore it is necessary
for the encapsulation format to support STUN packets and encapsulated
TCP packets sharing the same UDP port.</t>
<t>This document defines a suitable encapsulation of TCP (and other
transport protocols) over UDP.</t>
<t>We anticipate in-kernel implementations of TCP-over-UDP, making use
of the kernel's existing mature TCP code, but user-level implementations
of TCP-over-UDP are also possible, using a high-quality user-space TCP
implementation that provides the necessary congestion control and other
desirable aspects of TCP. This allows applications to use TCP-over-UDP
on operating systems that don't provide TCP-over-UDP.</t>
<t>The performance and congestion control properties of TCP-over-UDP
are exactly the same as traditional TCP. TCP-over-UDP is traditional
TCP using UDP/IP as the datagram transport, instead of just raw IP as
the datagram transport. Existing TCP facilities such as window scaling,
timestamps, selective ack, and TCP header options are supported, as
they are with native TCP. In fact, TCP options are expected to work
more reliably with TCP-over-UDP, because middleboxes will be less able
to easily interfere with such options, modifying them, stripping them,
or dropping packets containing TCP options, as they often do today with
native TCP packets. In particular, Multipath TCP-over-UDP is expected
to work more reliably than native <xref target="RFC6824">Multipath
TCP</xref>, because middleboxes that interfere with use of those TCP
options will be less able to do that when the packets are encapsulated
inside UDP.</t>
<t>Any protocol than can be run over native TCP, including TLS,
can be run over TCP-over-UDP.</t>
<t>NAT gateways typically use shorter timeouts for UDP port mappings
than they do for TCP port mappings. This means that long-lived
TCP-over-UDP connections will need to send more frequent keepalive
packets than native TCP connections. For this reason, native TCP
connections are still preferable for long-lived mostly-idle
connections. For these connections, TCP-over-UDP should be used only
when native TCP fails.</t>
</section>
<?rfc needLines="5" ?>
<section anchor="API" title="Conceptual API">
<t>While the protocol specified in this document could be
implemented in a variety of ways, it is helpful to describe one
possible API model to illustrate the intended functionality. In
this illustrative API, the client application first creates
an "attachable" UDP socket, and then creates an "attached" TCP
socket which shares its UDP port. All TCP packets sent and received
by the "attached" TCP socket are encapsulated inside UDP packets.</t>
<t>Note that the TCP socket conceptually has no associated source
port of its own. The UDP port numbers provide all the necessary
traffic demultiplexing, and fully identify the software endpoint
to which a given UDP packet is directed. No further demultiplexing
at the TCP level is required. Equivalently, the TCP source port
could be thought of as being "UDP port X". Note that TCP using
"UDP port X" as its source port is not that same as a native TCP
connection using "TCP port X" as its source port. For example, a
host with a TCP-over-UDP socket listening for TCP-over-UDP connections
to UDP port 80 will often also have a native TCP socket listening for
native TCP connections to TCP port 80.</t>
</section>
<?rfc needLines="11" ?>
<section anchor="format" title="Packet Format">
<t>The most-significant four bits of the first octet of the UDP payload
determine whether the payload is:</t>
<?rfc subcompact="yes" ?>
<t><list style='symbols'>
<t>0x0-0x3: A raw UDP payload (typically a STUN packet)</t>
<t>0x5-0xF: An encapsulated TCP packet</t>
<t>0x4: Some other transport protocol (e.g., SCTP, DCCP, or even UDP)</t>
</list></t>
<?rfc subcompact="no" ?>
<t>These three packet varieties are described in more detail below.</t>
<section anchor="raw" title="Raw UDP">
<t>When the client makes an API call to transmit a UDP payload
on an "attachable" UDP socket,
where the most-significant four bits of the first octet of the payload are in
the range 0x0-0x3 (as is the case for a <xref target="RFC5389">STUN</xref>
packet, where the most-significant two bits are always zero) the
entire UDP payload is sent-as is, with no modification.</t>
<t>Upon reception of a UDP packet where the most-significant
four bits of the first octet are in the range 0x0-0x3, the
entire payload is delivered to the application's UDP socket
without modification.</t>
<t>This allows a client application to exchange STUN packets
with an unmodified STUN server that knows nothing about this new
encapsulation.</t>
</section>
<?rfc needLines="22" ?>
<section anchor="TCP" title="Encapsulated TCP">
<t>When the client makes an API call to transmit TCP data on an "attached"
TCP socket, encapsulated TCP packets are generated and sent.</t>
<t>For clarity of explanation, this section describes the process
of generating these packets in terms of (i) first generating a
standard TCP packet in the conventional way, and then (ii) performing
a rewriting step to transform it into a TCP-over-UDP packet just
prior to transmission. Upon reception, the inverse rewrite is
performed to transform it back into a conventional TCP packet, which
is then handed to the TCP stack for the usual TCP processing. In this
model the only required change to an existing in-kernal TCP
implementation is that its per-connection data structures need to
include an additional one-bit flag signifying whether this is a
native TCP connection or a TCP-over-UDP connection. This is necessary
to allow TCP port X and TCP-over-UDP port X to coexist simultaneously.</t>
<t>It is likely that, for better efficiency, implementers may choose
to modify their TCP code to generate TCP-over-UDP packets directly,
rather than first generating a standard TCP header and then rewriting
it. Nonetheless, for clarity, the description which follows assumes
that a standard TCP packet has been generated, and describes how such
a packet would be transformed into a TCP-over-UDP packet.</t>
<t>In the IP header, the IP protocol field is changed from 0x06
(TCP) to 0x11 (UDP).</t>
<?rfc needLines="22" ?>
<t>The <xref target="RFC0793">TCP header</xref> is then
rewritten as described below to transform it into a legal
<xref target="RFC0768">UDP header</xref>.
A 20-octet (or more) TCP header is formatted as shown below:</t>
<figure align="left" anchor="TCPheader" title="TCP Header Format">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional) Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<?rfc needLines="18" ?>
<t>This header is rewritten into the encapsulated TCP-over-UDP format
shown below:</t>
<figure align="left" anchor="EncapsTCPheader" title="Encapsulated TCP-over-UDP Header Format">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | | |A|P|R|S|F| |
| Offset| Reserved |0|C|S|S|Y|I| Window |
| | | |K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional) Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<?rfc needLines="3" ?>
<t>The specified TCP source port is replaced by the UDP socket's
source port. If the implementation generates the TCP header
using the UDP port number, then this is a no-op.</t>
<t>The specified destination port is preserved. Note that for
the packet to be interpreted correctly upon reception,
the receiving peer must (obviously) implement TCP-over-UDP
and have it enabled for the receiving UDP socket.</t>
<t>The length is the customary UDP length field, indicating the
number of octets from the start of this header to the end of the payload.
It can be computed from the Total Length and Internet Header Length fields
in the IP header.</t>
<t>The Checksum is the customary UDP Checksum. Note that the checksum
does not have to be recomputed by brute-force; it can be derived using
a simple calculation involving the original TCP Checksum and the fields
modified in the course of this header rewrite.</t>
<t>The header up to this point is now a standard UDP header.</t>
<t>The remainder of the TCP header is re-ordered so that the "Data Offset" line
comes next. Since the minimum legal value for Data Offset is 5,
this yields a UDP payload where the most-significant four bits
of the first octet are necessarily in the range 0x5-0xF.</t>
<t>The Sequence Number and Acknowledgment Number appear next.</t>
<t>The TCP Checksum is omitted, since it is redundant. The
UDP header has its own checksum.</t>
<t>The TCP Urgent Pointer field is omitted. TCP-over-UDP does not
support urgent data. The TCP URG flag MUST NOT be set.</t>
<t>This in-place rewrite converts the 20-octet (or more) TCP header
into a 20-octet (or more) TCP-over-UDP header. Since the header
size is the same, the TCP MSS is unchanged.</t>
<t>Upon reception of a UDP packet where the most-significant
four bits of the first octet are in the range 0x5-0xF, on a UDP port
with TCP-over-UDP enabled, the code performs the inverse of the
transformation described above, and then hands the resulting TCP
packet to the existing TCP implementation for further
processing.</t>
</section>
<?rfc needLines="7" ?>
<section anchor="other" title="Encapsulated UDP and Other Transport Protocols">
<t>When the client makes an API call to transmit a UDP payload
where the most-significant four bits of the first octet are not in
the range 0x0-0x3, an explicit UDP-in-UDP encapsulation is used.
A four-octet header is inserted before the UDP payload:</t>
<figure align="left" anchor="EncapsUDPheader" title="Encapsulated UDP-over-UDP Header Format">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x40 | proto = 0x11 | 0x00 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Upon reception of a UDP packet where the most-significant
four bits of the first octet have the value 0x4, on a UDP port
with TCP-over-UDP enabled, this signifies an encapsulated
transport protocol (other than TCP). The value in the second
octet indicates the encapsulated protocol.</t>
<t>The details of how a given transport protocol is
encapsulated over UDP are defined on a per-protocol basis. In
particular, the complete transport protocol SHOULD NOT be
included in its entirety, since some of the fields are redundant
or unnecessary (as illustrated above for TCP). For protocols that
use 16-bit port numbers, these port number fields SHOULD be
omitted from the encapsulated header, since the necessary demultiplexing
function is performed by the UDP header's port number fields.</t>
<t>In the case of UDP, none of the UDP header fields are
replicated in the encapsulated content, since the outer UDP
header contains all the necessary information to infer the
effective inner UDP header contents (i.e. the source and
destination ports are the same, the length field of the
effective inner UDP header is four octets less than the outer
UDP header's length field, and the checksum is recomputed).
Upon reception of such a packet, the four-octet encapsulation header
is stripped off, and the remaining payload delivered to the application.
For UDP packets where the most-significant four bits of the
first octet are not in the range 0x0-0x3, this results in an
effective MTU reduction of four octets. This is not expected to
cause any significant problems. The primary use of TCP-over-UDP is
expected to be for STUN and TCP sharing a UDP port.</t>
</section>
</section>
<?rfc needLines="5" ?>
<section anchor="iana" title="IANA Considerations">
<t>No IANA actions are required by this document.</t>
</section>
<?rfc needLines="5" ?>
<section anchor="security" title="Security Considerations">
<t>No new security risks occur as a result of using this protocol.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.2119" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5128"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.RFC.6824"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 23:00:32 |