idnits 2.17.1 draft-tuexen-sctp-udp-encaps-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors 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 11, 2011) is 4673 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0791' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC4821' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC4895' is defined on line 290, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-05 == Outdated reference: A later version (-23) exists of draft-ietf-tsvwg-natsupp-01 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 Internet-Draft Muenster Univ. of Appl. Sciences 4 Intended status: Standards Track R. Stewart 5 Expires: January 12, 2012 Adara Networks 6 July 11, 2011 8 UDP Encapsulation of SCTP Packets 9 draft-tuexen-sctp-udp-encaps-07.txt 11 Abstract 13 This document describes a simple method of encapsulating SCTP Packets 14 into UDP packets and its limitations. This allows the usage of SCTP 15 in networks with legacy NAT not supporting SCTP. It can also be used 16 to implement SCTP on hosts without directly accessing the IP-layer, 17 for example implementing it as part of the application without 18 requiring special privileges. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 12, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Portable SCTP Implementations . . . . . . . . . . . . . . . 3 58 3.2. Legacy NAT traversal . . . . . . . . . . . . . . . . . . . 4 59 4. SCTP over UDP . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Architectural Considerations . . . . . . . . . . . . . . . 4 61 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.3. Encapsulation Procedure . . . . . . . . . . . . . . . . . . 5 63 4.4. Decapsulation Procedure . . . . . . . . . . . . . . . . . . 5 64 4.5. ICMP considerations . . . . . . . . . . . . . . . . . . . . 6 65 4.6. Path MTU considerations . . . . . . . . . . . . . . . . . . 6 66 4.7. Handling of Embedded IP-addresses . . . . . . . . . . . . . 6 67 4.8. ECN considerations . . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 This document describes a simple method of encapsulating SCTP packets 79 into UDP packets. SCTP is defined in [RFC4960]. There are two main 80 reasons for this: 82 o Allow SCTP traffic to pass legacy NATs, which do not provide 83 native SCTP support as specified in [I-D.ietf-behave-sctpnat] and 84 [I-D.ietf-tsvwg-natsupp]. 86 o Allow SCTP to be implemented on hosts which do not provide direct 87 access to the IP-layer. In particular, applications can use their 88 own SCTP implementation if the operating system does not provide 89 one. 91 2. Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Use Cases 99 This section discusses two important use cases for encapsulating SCTP 100 into UDP. 102 3.1. Portable SCTP Implementations 104 Some operating systems support SCTP natively. For other operating 105 systems implementations are available, but require special privileges 106 to install and/or use them. In some cases no kernel implementation 107 might be available at all. When proving an SCTP implementation as 108 part of a user process, most operating systems require special 109 privileges to access the IP layer directly. 111 Using UDP encapsulation makes it possible to provide an SCTP 112 implementation as part of a user process which does not require any 113 special privileges. 115 A crucial point for implementing SCTP in userland is controlling the 116 source address of outgoing packets. This is not an issue when using 117 all available addresses. However, this is not the case when also 118 using the address management required for NAT traversal described in 119 Section 4.7. 121 3.2. Legacy NAT traversal 123 Using UDP encapsulation allows an SCTP communication traversing 124 legacy NATs not supporting SCTP as described in 125 [I-D.ietf-behave-sctpnat] and [I-D.ietf-tsvwg-natsupp]. It is 126 important to realize that for single homed associations it is only 127 necessary that no IP addresses are listen in the INIT- and INIT-ACK 128 chunks. Dynamic address reconfiguration to change the single address 129 has to make use of wildcard addresses as described in [RFC5061]. 131 For multi-homed SCTP association the address management as described 132 in Section 4.7 MUST be performed. 134 4. SCTP over UDP 136 4.1. Architectural Considerations 138 An SCTP implementation supporting UDP encapsulation MUST store a UDP 139 encapsulation port per destination address for each SCTP association. 141 4.2. Packet Format 143 To encapsulate an SCTP packet, a UDP header header as defined in 144 [RFC0768] is inserted between the IP header and the SCTP common 145 header. 147 Figure 1 shows the packet format of an encapsulated SCTP packet when 148 IPv4 is used. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | IPv4 Header | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | UDP Header | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | SCTP Common Header | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | SCTP Chunk #1 | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | ... | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | SCTP Chunk #n | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 1 168 The packet format for an encapsulated SCTP packet when using IPv6 is 169 shown in Figure 2. Please note the the number m of IPv6 extension 170 headers can be 0. 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | IPv6 Base Header | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | IPv6 Extension Header #1 | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | ... | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | IPv6 Extension Header #m | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | UDP Header | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | SCTP Common Header | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | SCTP Chunk #1 | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | ... | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | SCTP Chunk #n | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 2 196 The UDP checksum MUST NOT be zero. 198 4.3. Encapsulation Procedure 200 When inserting the UDP header, the source port is 9899, the 201 destination port is the one stored for the destination address the 202 packet is sent to or 9899 if not destination address is stored. 204 The length of the UDP packet is the length of the SCTP packet plus 205 the size of the UDP header. 207 The checksum MUST be computed. 209 4.4. Decapsulation Procedure 211 When an encapsulated packet is received, the UDP header is removed. 212 Then a lookup is performed to find the association the received SCTP 213 packet belongs to. The UDP source port is stored as the 214 encapsulation port of the SCTP destination address the received SCTP 215 packet is sent from. 217 4.5. ICMP considerations 219 When receiving ICMP or ICMPv6 response packet, there might not be 220 enough bytes in the payload to identify the SCTP association which 221 the SCTP packet triggering the ICMP or ICMPv6 packet belongs to. If 222 a received ICMP or ICMPv6 packet can to be related to a specific SCTP 223 association, it MUST be discarded silently. 225 4.6. Path MTU considerations 227 If an SCTP endpoint starts to encapsulate the packets of a path, it 228 MUST decrease the path MTU of that path by the size of an UDP header. 229 If it stops encapsulating them, the path MTU MUST be increased by the 230 size of an UDP header. 232 When performing path MTU discovery as described in [RFC4820] it MUST 233 take into account that it cannot rely on the feedback provided by 234 ICMP or ICMPv6 due to the limitation laid out in Section 4.5. 236 4.7. Handling of Embedded IP-addresses 238 When using UDP encapsulation is used for legacy NAT traversal, IP 239 address that might be translated MUST NOT be put into any SCTP 240 packet. 242 This means that an SCTP association is setup singled homed and the 243 protocol extension [RFC5061] is used to add multiple address. Only 244 wildcard addresses are put into the SCTP packet. 246 When addresses are changed during the lifetime of the association 247 [RFC5061] MUST be used with wildcard addresses only. 249 4.8. ECN considerations 251 TBD 253 5. IANA Considerations 255 This document does not require any actions from IANA. 257 6. Security Considerations 259 Encapsulating SCTP into UDP does not add any additional security 260 considerations to the ones given in [RFC4960] and [RFC5061]. 262 7. Acknowledgments 264 The authors wish to thank Irene Ruengeler for her invaluable 265 comments. 267 8. References 269 8.1. Normative References 271 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 272 August 1980. 274 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 275 September 1981. 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, March 1997. 280 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 281 (IPv6) Specification", RFC 2460, December 1998. 283 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 284 Parameter for the Stream Control Transmission Protocol 285 (SCTP)", RFC 4820, March 2007. 287 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 288 Discovery", RFC 4821, March 2007. 290 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 291 "Authenticated Chunks for the Stream Control Transmission 292 Protocol (SCTP)", RFC 4895, August 2007. 294 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 295 RFC 4960, September 2007. 297 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 298 Kozuka, "Stream Control Transmission Protocol (SCTP) 299 Dynamic Address Reconfiguration", RFC 5061, 300 September 2007. 302 8.2. Informative References 304 [I-D.ietf-behave-sctpnat] 305 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 306 Transmission Protocol (SCTP) Network Address Translation", 307 draft-ietf-behave-sctpnat-05 (work in progress), 308 June 2011. 310 [I-D.ietf-tsvwg-natsupp] 311 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 312 Transmission Protocol (SCTP) Network Address Translation 313 Support", draft-ietf-tsvwg-natsupp-01 (work in progress), 314 June 2011. 316 Authors' Addresses 318 Michael Tuexen 319 Muenster University of Applied Sciences 320 Stegerwaldstr. 39 321 48565 Steinfurt 322 DE 324 Email: tuexen@fh-muenster.de 326 Randall R. Stewart 327 Adara Networks 328 Chapin, SC 29036 329 USA 331 Email: randall@lakerest.net