UDP-Encapsulated Transport Protocols
draft-denis-udp-transport-00

Status of This Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 5, 2009.

Abstract

This memo defines modified formats for conveyance of TCP and SCTP packets within UDP datagrams, to ease traversal of network address translators.

1.  Introduction

The widespread deployment of network address and port translators (NATs) across the Internet constitutes a major impediment to the transmission of end-to-end traffic, especially when both ends of a communication channel are located behind (distinct) NATs.

NATs are typically designed in such a manner, that the connection-oriented transport protocols, such as TCP, will only operate if:

• the passive end of the connection is not hindered by a NAT (i.e. NATs can only be on the active end side),
• any NAT on the path must explicitly support the transport protocol used (in practice, only TCP is commonly supported).

Several experiments have consistently showed that, when both sides of a communication channel are behind NATs, the transmission of UDP datagrams gives a much higher success rate.

This memo proposes modified packet formatting rules for use of the TCP and SCTP transport protocols through UDP datagram flows, with optimizations to avoid having to shrink the maximum segment sizes, nor require the use of IP-level packet fragmentation.

2.  Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Applicability statement

UDP encapsulation is not backward compatible with normal TCP and SCTP implementations. They also require application-layer changes, though any affected applications would likely not operate at all without such modifications.

Futhermore, middleboxes typically implement short binding expiration timers for UDP flows (commonly 30 seconds to a few minutes). As a consequence, it is necessary to send keep-alive packets in both direction rather frequently. That precludes the use of UDP encapsulation in scenarios where the sending of frequent keep-alive is not acceptable (e.g. battery-powered device with a cellular access network).

Because of these major limitations, the proposed mechanism SHOULD only be used when normal packet formats would not work, such as in NAT-to-NAT scenarios.

4.  Packet formats

4.1.  Encapsulated TCP

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 |       |C|E|A|P|R|S|F|                               |
|1| Offset|  Res. |W|C|C|S|S|Y|I|            Window             |
| |       |       |R|E|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The UDP-encapsulated TCP format is defined as follow:

Source, Destination Ports:

TCP/UDP source and destination port numbers.

Length:

Length in octets of the datagram, including this entire header and the data.

Checksum:

UDP checksum (as specified in [RFC0768] (Postel, J., “User Datagram Protocol,” August 1980.)).

1:

Bit always set to 1, to differentiate STUN/UDP datagrams from TCP frames.

Data Offset:

TCP Data Offset, the number of 32-bits words from Source Port (included) to data (excluded). MUST be at least 5.

Other fields:

The other have the same semantics as with the TCP protocol (see [RFC0793] (Postel, J., “Transmission Control Protocol,” September 1981.)).

Note that the URG bit and the Urgent pointer field are suppressed. Support for TCP urgent data is left for further study.

The TCP checksum is removed, the UDP checksum provides the same level of protection.

4.2.  Encapsulated SCTP

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 Number        |     Destination Port Number   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |            Checksum           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|                     Verification Tag                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source, Destination Port Numbers:

UDP/SCTP source and destination port numbers.

Length:

Length in octets of the datagram, including this entire header and the data.

Checksum:

UDP checksum (as specified in [RFC0768] (Postel, J., “User Datagram Protocol,” August 1980.)).

1:

Bit always set to 1, to differentiate STUN/UDP datagrams from encapsulated SCTP packets.

Verification Tag:

31 lower order bits of the SCTP verification tag defined in [RFC4960] (Stewart, R., “Stream Control Transmission Protocol,” September 2007.).

5.  Usage with STUN

The above packet formats are defined such that the first bit of UDP payload data is always set to 1. This allows for sending STUN packets multiplexed through the same UDP flow as either a UDP-encapsulated TCP or SCTP session. Indeed STUN packets always have their first bit set to 0, as per [I‑D.ietf‑behave‑rfc3489bis] (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for (NAT) (STUN),” July 2008.).

5.1.  Usage with ICE

Because of this, it is possible to establish a UDP-encapsulated TCP or SCTP flow using Interactive Connection Establishment [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) as for any other ICE-negotiated UDP flow. In that case, STUN packets are first exchanged to probe end-to-end connectivity, and mutually authenticate endpoints. Once a flow is successfully established, UDP-encapsulated TCP or SCTP packets can be exchanged, in accordance with the respective transport protocol state machines.

For this to work, both endpoints need to exchange their ICE candidate out-of-band, such as with SIP[RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) or XMPP[RFC3920] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.). TBD: in case SDP conveys the ICE parameters, a new media protocol or attribute will be required.

5.2.  Keep-alives packets

This multiplexing scheme also allow sending and receiving of ICE keepalive packets, which may be required to refresh binding timers on NATs and other middleboxes on the data path. It should be noted that UDP flows are commonly associated with rather short bindings timeouts (30 seconds to a few minutes). Therefore, keep-alives packets may need to be sent frequently.

In principle, TCP keep-alive packets could also be used to refresh NAT bindings. However, the typical TCP keep-alive period is way too long. For instance, at the time of writing, the GNU/Linux operating system will send TCP keep-alives only after 2 hours of TCP session inactivity (assuming keep-alives are enabled for the session).

6.  Alternative solutions

This non-normative section documents other potential solutions to establishing TCP and SCTP sessions through a UDP flow.

6.1.  Tunneling IP over UDP

The Teredo protocol[RFC4380] (Huitema, C., “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs),” February 2006.) allows encapsulating IP (version 6) packets into UDP/IPv4 datagrams. This potentially allows the use of any IP-based transport protocol between two NATted IPv4 hosts, provided that the operating system and applications support IPv6 (proper IPv6 connectivity is however not required).

Each Teredo client is automatically provisioned with its own unique IPv6 address, which can be used as the rendez-vous mechanism, thus no application-layer rendez-vous protocol are needed. For this to work, clients must maintain a live UDP flow binding with their Teredo server, however.

The Teredo protocol provides a fixed per-packet overhead of 48 bytes: 8 bytes for the UDP header and 40 bytes for the IPv6 header. In its current state, Teredo limits the packet MTU to 1280 bytes (the minimum IPv6 MTU), in order to avoid fragmentation. For TCP, this translates to a maximum segment size of 1220 bytes.

6.2.  Tunneling transport header over UDP

Another option would involve encapsulating the unmodified transport protocol header into a UDP packet. draft-tuexen-sctp-udp-encaps and draft-phelan-dccp-natencap were example of this.

7.  Security Considerations

TBD.

8.  IANA Considerations

This document raises no IANA considerations.

9.  References

9.1. Normative References

9.2. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.