[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]

Versions: 00

Internet Engineering Task Force                        R. Denis-Courmont
Internet-Draft                                                     Nokia
Intended status: Experimental                              July 04, 2008
Expires: January 5, 2009

                  UDP-Encapsulated Transport Protocols

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

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


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

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-

Denis-Courmont           Expires January 5, 2009                [Page 1]

Internet-Draft               UDP Transports                    July 2008

   oriented transport protocols, such as TCP, will only operate if:

   o  the passive end of the connection is not hindered by a NAT (i.e.
      NATs can only be on the active end side),

   o  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",
   document are to be interpreted as described in [RFC2119].

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

   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

Denis-Courmont           Expires January 5, 2009                [Page 2]

Internet-Draft               UDP Transports                    July 2008

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                              |

                        UDP-encapsulated TCP header

   The UDP-encapsulated TCP format is defined as follow:

   Source, Destination Ports:  TCP/UDP source and destination port

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

   Checksum:  UDP checksum (as specified in [RFC0768]).

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

   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]).

   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.

Denis-Courmont           Expires January 5, 2009                [Page 3]

Internet-Draft               UDP Transports                    July 2008

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                        |

                    UDP-encapsulated SCTP common header

   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]).

   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].

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].

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] 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

   For this to work, both endpoints need to exchange their ICE candidate

Denis-Courmont           Expires January 5, 2009                [Page 4]

Internet-Draft               UDP Transports                    July 2008

   out-of-band, such as with SIP[RFC3261] or XMPP[RFC3920].  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] 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

Denis-Courmont           Expires January 5, 2009                [Page 5]

Internet-Draft               UDP Transports                    July 2008

   draft-phelan-dccp-natencap were example of this.

7.  Security Considerations


8.  IANA Considerations

   This document raises no IANA considerations.

9.  References

9.1.  Normative References

   [RFC0768]                     Postel, J., "User Datagram Protocol",
                                 STD 6, RFC 768, August 1980.

   [RFC0793]                     Postel, J., "Transmission Control
                                 Protocol", STD 7, RFC 793,
                                 September 1981.

   [RFC2119]                     Bradner, S., "Key words for use in RFCs
                                 to Indicate Requirement Levels",
                                 BCP 14, RFC 2119, March 1997.

   [RFC4960]                     Stewart, R., "Stream Control
                                 Transmission Protocol", RFC 4960,
                                 September 2007.

9.2.  Informative References

   [I-D.ietf-behave-rfc3489bis]  Rosenberg, J., Mahy, R., Matthews, P.,
                                 and D. Wing, "Session Traversal
                                 Utilities for (NAT) (STUN)",
                                 draft-ietf-behave-rfc3489bis-16 (work
                                 in progress), July 2008.

   [I-D.ietf-mmusic-ice]         Rosenberg, J., "Interactive
                                 Connectivity Establishment (ICE): A
                                 Protocol for Network Address
                                 Translator (NAT) Traversal for Offer/
                                 Answer Protocols",
                                 draft-ietf-mmusic-ice-19 (work in
                                 progress), October 2007.

   [RFC3261]                     Rosenberg, J., Schulzrinne, H.,
                                 Camarillo, G., Johnston, A., Peterson,
                                 J., Sparks, R., Handley, M., and E.

Denis-Courmont           Expires January 5, 2009                [Page 6]

Internet-Draft               UDP Transports                    July 2008

                                 Schooler, "SIP: Session Initiation
                                 Protocol", RFC 3261, June 2002.

   [RFC3920]                     Saint-Andre, P., Ed., "Extensible
                                 Messaging and Presence Protocol (XMPP):
                                 Core", RFC 3920, October 2004.

   [RFC4380]                     Huitema, C., "Teredo: Tunneling IPv6
                                 over UDP through Network Address
                                 Translations (NATs)", RFC 4380,
                                 February 2006.

Author's Address

   Remi Denis-Courmont
   Nokia Corporation
   P.O. Box 407
   NOKIA GROUP  00045

   Phone: +358 50 487 6315
   EMail: remi.denis-courmont@nokia.com

Denis-Courmont           Expires January 5, 2009                [Page 7]

Internet-Draft               UDP Transports                    July 2008

Full Copyright Statement

   Copyright (C) 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

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

   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

Denis-Courmont           Expires January 5, 2009                [Page 8]

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/