idnits 2.17.1 draft-denis-udp-transport-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 347. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 04, 2008) is 5774 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-16 -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Denis-Courmont 3 Internet-Draft Nokia 4 Intended status: Experimental July 04, 2008 5 Expires: January 5, 2009 7 UDP-Encapsulated Transport Protocols 8 draft-denis-udp-transport-00 10 Status of This Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 5, 2009. 35 Abstract 37 This memo defines modified formats for conveyance of TCP and SCTP 38 packets within UDP datagrams, to ease traversal of network address 39 translators. 41 1. Introduction 43 The widespread deployment of network address and port translators 44 (NATs) across the Internet constitutes a major impediment to the 45 transmission of end-to-end traffic, especially when both ends of a 46 communication channel are located behind (distinct) NATs. 48 NATs are typically designed in such a manner, that the connection- 49 oriented transport protocols, such as TCP, will only operate if: 51 o the passive end of the connection is not hindered by a NAT (i.e. 52 NATs can only be on the active end side), 54 o any NAT on the path must explicitly support the transport protocol 55 used (in practice, only TCP is commonly supported). 57 Several experiments have consistently showed that, when both sides of 58 a communication channel are behind NATs, the transmission of UDP 59 datagrams gives a much higher success rate. 61 This memo proposes modified packet formatting rules for use of the 62 TCP and SCTP transport protocols through UDP datagram flows, with 63 optimizations to avoid having to shrink the maximum segment sizes, 64 nor require the use of IP-level packet fragmentation. 66 2. Definitions 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 3. Applicability statement 74 UDP encapsulation is not backward compatible with normal TCP and SCTP 75 implementations. They also require application-layer changes, though 76 any affected applications would likely not operate at all without 77 such modifications. 79 Futhermore, middleboxes typically implement short binding expiration 80 timers for UDP flows (commonly 30 seconds to a few minutes). As a 81 consequence, it is necessary to send keep-alive packets in both 82 direction rather frequently. That precludes the use of UDP 83 encapsulation in scenarios where the sending of frequent keep-alive 84 is not acceptable (e.g. battery-powered device with a cellular access 85 network). 87 Because of these major limitations, the proposed mechanism SHOULD 88 only be used when normal packet formats would not work, such as in 89 NAT-to-NAT scenarios. 91 4. Packet formats 92 4.1. Encapsulated TCP 94 0 1 2 3 95 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 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Source Port | Destination Port | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Length | Checksum | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | | Data | |C|E|A|P|R|S|F| | 102 |1| Offset| Res. |W|C|C|S|S|Y|I| Window | 103 | | | |R|E|K|H|T|N|N| | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Sequence Number | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Acknowledgment Number | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Options | Padding | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | data | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 UDP-encapsulated TCP header 116 The UDP-encapsulated TCP format is defined as follow: 118 Source, Destination Ports: TCP/UDP source and destination port 119 numbers. 121 Length: Length in octets of the datagram, including this entire 122 header and the data. 124 Checksum: UDP checksum (as specified in [RFC0768]). 126 1: Bit always set to 1, to differentiate STUN/UDP datagrams from TCP 127 frames. 129 Data Offset: TCP Data Offset, the number of 32-bits words from 130 Source Port (included) to data (excluded). MUST be at least 5. 132 Other fields: The other have the same semantics as with the TCP 133 protocol (see [RFC0793]). 135 Note that the URG bit and the Urgent pointer field are suppressed. 136 Support for TCP urgent data is left for further study. 138 The TCP checksum is removed, the UDP checksum provides the same level 139 of protection. 141 4.2. Encapsulated SCTP 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Source Port Number | Destination Port Number | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Length | Checksum | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 |1| Verification Tag | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 UDP-encapsulated SCTP common header 155 Source, Destination Port Numbers: UDP/SCTP source and destination 156 port numbers. 158 Length: Length in octets of the datagram, including this entire 159 header and the data. 161 Checksum: UDP checksum (as specified in [RFC0768]). 163 1: Bit always set to 1, to differentiate STUN/UDP datagrams from 164 encapsulated SCTP packets. 166 Verification Tag: 31 lower order bits of the SCTP verification tag 167 defined in [RFC4960]. 169 5. Usage with STUN 171 The above packet formats are defined such that the first bit of UDP 172 payload data is always set to 1. This allows for sending STUN 173 packets multiplexed through the same UDP flow as either a UDP- 174 encapsulated TCP or SCTP session. Indeed STUN packets always have 175 their first bit set to 0, as per [I-D.ietf-behave-rfc3489bis]. 177 5.1. Usage with ICE 179 Because of this, it is possible to establish a UDP-encapsulated TCP 180 or SCTP flow using Interactive Connection Establishment 181 [I-D.ietf-mmusic-ice] as for any other ICE-negotiated UDP flow. In 182 that case, STUN packets are first exchanged to probe end-to-end 183 connectivity, and mutually authenticate endpoints. Once a flow is 184 successfully established, UDP-encapsulated TCP or SCTP packets can be 185 exchanged, in accordance with the respective transport protocol state 186 machines. 188 For this to work, both endpoints need to exchange their ICE candidate 189 out-of-band, such as with SIP[RFC3261] or XMPP[RFC3920]. TBD: in 190 case SDP conveys the ICE parameters, a new media protocol or 191 attribute will be required. 193 5.2. Keep-alives packets 195 This multiplexing scheme also allow sending and receiving of ICE 196 keepalive packets, which may be required to refresh binding timers on 197 NATs and other middleboxes on the data path. It should be noted that 198 UDP flows are commonly associated with rather short bindings timeouts 199 (30 seconds to a few minutes). Therefore, keep-alives packets may 200 need to be sent frequently. 202 In principle, TCP keep-alive packets could also be used to refresh 203 NAT bindings. However, the typical TCP keep-alive period is way too 204 long. For instance, at the time of writing, the GNU/Linux operating 205 system will send TCP keep-alives only after 2 hours of TCP session 206 inactivity (assuming keep-alives are enabled for the session). 208 6. Alternative solutions 210 This non-normative section documents other potential solutions to 211 establishing TCP and SCTP sessions through a UDP flow. 213 6.1. Tunneling IP over UDP 215 The Teredo protocol[RFC4380] allows encapsulating IP (version 6) 216 packets into UDP/IPv4 datagrams. This potentially allows the use of 217 any IP-based transport protocol between two NATted IPv4 hosts, 218 provided that the operating system and applications support IPv6 219 (proper IPv6 connectivity is however not required). 221 Each Teredo client is automatically provisioned with its own unique 222 IPv6 address, which can be used as the rendez-vous mechanism, thus no 223 application-layer rendez-vous protocol are needed. For this to work, 224 clients must maintain a live UDP flow binding with their Teredo 225 server, however. 227 The Teredo protocol provides a fixed per-packet overhead of 48 bytes: 228 8 bytes for the UDP header and 40 bytes for the IPv6 header. In its 229 current state, Teredo limits the packet MTU to 1280 bytes (the 230 minimum IPv6 MTU), in order to avoid fragmentation. For TCP, this 231 translates to a maximum segment size of 1220 bytes. 233 6.2. Tunneling transport header over UDP 235 Another option would involve encapsulating the unmodified transport 236 protocol header into a UDP packet. draft-tuexen-sctp-udp-encaps and 237 draft-phelan-dccp-natencap were example of this. 239 7. Security Considerations 241 TBD. 243 8. IANA Considerations 245 This document raises no IANA considerations. 247 9. References 249 9.1. Normative References 251 [RFC0768] Postel, J., "User Datagram Protocol", 252 STD 6, RFC 768, August 1980. 254 [RFC0793] Postel, J., "Transmission Control 255 Protocol", STD 7, RFC 793, 256 September 1981. 258 [RFC2119] Bradner, S., "Key words for use in RFCs 259 to Indicate Requirement Levels", 260 BCP 14, RFC 2119, March 1997. 262 [RFC4960] Stewart, R., "Stream Control 263 Transmission Protocol", RFC 4960, 264 September 2007. 266 9.2. Informative References 268 [I-D.ietf-behave-rfc3489bis] Rosenberg, J., Mahy, R., Matthews, P., 269 and D. Wing, "Session Traversal 270 Utilities for (NAT) (STUN)", 271 draft-ietf-behave-rfc3489bis-16 (work 272 in progress), July 2008. 274 [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive 275 Connectivity Establishment (ICE): A 276 Protocol for Network Address 277 Translator (NAT) Traversal for Offer/ 278 Answer Protocols", 279 draft-ietf-mmusic-ice-19 (work in 280 progress), October 2007. 282 [RFC3261] Rosenberg, J., Schulzrinne, H., 283 Camarillo, G., Johnston, A., Peterson, 284 J., Sparks, R., Handley, M., and E. 286 Schooler, "SIP: Session Initiation 287 Protocol", RFC 3261, June 2002. 289 [RFC3920] Saint-Andre, P., Ed., "Extensible 290 Messaging and Presence Protocol (XMPP): 291 Core", RFC 3920, October 2004. 293 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 294 over UDP through Network Address 295 Translations (NATs)", RFC 4380, 296 February 2006. 298 Author's Address 300 Remi Denis-Courmont 301 Nokia Corporation 302 P.O. Box 407 303 NOKIA GROUP 00045 304 FI 306 Phone: +358 50 487 6315 307 EMail: remi.denis-courmont@nokia.com 309 Full Copyright Statement 311 Copyright (C) The IETF Trust (2008). 313 This document is subject to the rights, licenses and restrictions 314 contained in BCP 78, and except as set forth therein, the authors 315 retain all their rights. 317 This document and the information contained herein are provided on an 318 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 319 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 320 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 321 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 322 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 323 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 325 Intellectual Property 327 The IETF takes no position regarding the validity or scope of any 328 Intellectual Property Rights or other rights that might be claimed to 329 pertain to the implementation or use of the technology described in 330 this document or the extent to which any license under such rights 331 might or might not be available; nor does it represent that it has 332 made any independent effort to identify any such rights. Information 333 on the procedures with respect to rights in RFC documents can be 334 found in BCP 78 and BCP 79. 336 Copies of IPR disclosures made to the IETF Secretariat and any 337 assurances of licenses to be made available, or the result of an 338 attempt made to obtain a general license or permission for the use of 339 such proprietary rights by implementers or users of this 340 specification can be obtained from the IETF on-line IPR repository at 341 http://www.ietf.org/ipr. 343 The IETF invites any interested party to bring to its attention any 344 copyrights, patents or patent applications, or other proprietary 345 rights that may cover technology that may be required to implement 346 this standard. Please address the information to the IETF at 347 ietf-ipr@ietf.org.