idnits 2.17.1 draft-ietf-tsvwg-natsupp-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC0793], [RFC4960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2012) is 4209 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: 'RFC4895' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'RFC6096' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tsvwg-sctp-udp-encaps' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC5735' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'RFC6083' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'RFC6458' is defined on line 487, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (Obsoleted by RFC 9260) == Outdated reference: A later version (-14) exists of draft-ietf-tsvwg-sctp-udp-encaps-04 -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-06 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Adara Networks 4 Intended status: Standards Track M. Tuexen 5 Expires: April 12, 2013 I. Ruengeler 6 Muenster Univ. of Appl. Sciences 7 October 9, 2012 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 for Endpoints 11 draft-ietf-tsvwg-natsupp-03.txt 13 Abstract 15 Stream Control Transmission Protocol [RFC4960] provides a reliable 16 communications channel between two end-hosts in many ways similar to 17 TCP [RFC0793]. With the widespread deployment of Network Address 18 Translators (NAT), specialized code has been added to NAT for TCP 19 that allows multiple hosts to reside behind a NAT and yet use only a 20 single globally unique IPv4 address, even when two hosts (behind a 21 NAT) choose the same port numbers for their connection. This 22 additional code is sometimes classified as Network Address and Port 23 Translation (NAPT). To date, specialized code for SCTP has not yet 24 been added to most NATs so that only pure NAT is available. The end 25 result of this is that only one SCTP capable host can be behind a 26 NAT. 28 This document describes the protocol extensions required for the SCTP 29 endpoints to help NAT's provide similar features of NAPT in the 30 single-point and multi-point traversal scenario. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 12, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Problem Space Overview . . . . . . . . . . . . . . . . . . . . 5 70 5. Handling of Internal Port Number and Verification Tag 71 Collisions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 6. Handling of Missing State . . . . . . . . . . . . . . . . . . 7 73 7. Multi Point Traversal Considerations . . . . . . . . . . . . . 8 74 8. Handling of Internal Port Number Collisions . . . . . . . . . 8 75 9. SCTP Socket API Considerations . . . . . . . . . . . . . . . . 10 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 13.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 Stream Control Transmission Protocol [RFC4960] provides a reliable 87 communications channel between two end-hosts in many ways similar to 88 TCP [RFC0793]. With the widespread deployment of Network Address 89 Translators (NAT), specialized code has been added to NAT for TCP 90 that allows multiple hosts to reside behind a NAT and yet use only a 91 single globally unique IPv4 address, even when two hosts (behind a 92 NAT) choose the same port numbers for their connection. This 93 additional code is sometimes classified as Network Address and Port 94 Translation (NAPT). To date, specialized code for SCTP has not yet 95 been added to most NATs so that only true NAT is available. The end 96 result of this is that only one SCTP capable host can be behind a 97 NAT. 99 This document describes an SCTP specific chunks and procedures to 100 help NAT's provide similar features of NAPT in the single point and 101 multi-point traversal scenario. An SCTP implementation supporting 102 this extension will follow these procedures to assure that in both 103 single homed and multi-homed cases a NAT will maintain the proper 104 state without needing to change port numbers. 106 A NAT will need to follow these procedures for generating appropriate 107 SCTP packet formats. NAT's should refer to [I-D.ietf-behave-sctpnat] 108 for the BCP in using these formats. 110 When considering this feature it is possible to have multiple levels 111 of support. At each level, the Internal Host, External Host and NAT 112 may or may not support the features described in this document. The 113 following table illustrates the results of the various combinations 114 of support and if communications can occur between two endpoints. 116 +---------------+------------+---------------+---------------+ 117 | Internal Host | NAT | External Host | Communication | 118 +---------------+------------+---------------+---------------+ 119 | Support | Support | Support | Yes | 120 | Support | Support | No Support | Limited | 121 | Support | No Support | Support | None | 122 | Support | No Support | No Support | None | 123 | No Support | Support | Support | Limited | 124 | No Support | Support | No Support | Limited | 125 | No Support | No Support | Support | None | 126 | No Support | No Support | No Support | None | 127 +---------------+------------+---------------+---------------+ 129 Table 1: Communication possibilities 131 From the table we can see that when a NAT does not support the 132 extension no communication can occur. This is for the most part the 133 current situation i.e. SCTP packets sent externally from behind a 134 NAT are discarded by the NAT. In some cases, where the NAT supports 135 the feature but one of the two external hosts does not support the 136 feature communication may occur but in a limited way. For example 137 only one host may be able to have a connection when a collision case 138 occurs. 140 2. Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 3. Terminology 148 This document uses the following terms, which are depicted in 149 Figure 1. 151 Private-Address (Priv-Addr): The private address that is known to 152 the internal host. 154 Internal-Port (Int-Port): The port number that is in use by the host 155 holding the Private-Address. 157 Internal-VTag (Int-VTag): The Verification Tag that the internal 158 host has chosen for its communication. The VTag is a unique 32- 159 bit tag that must accompany any incoming SCTP packet for this 160 association to the Private-Address. 162 External-Address (Ext-Addr): The address that an internal host is 163 attempting to contact. 165 External-Port (Ext-Port): The port number of the peer process at the 166 External-Address. 168 External-VTag (Ext-VTag): The Verification Tag that the host holding 169 the External-Address has chosen for its communication. The VTag 170 is a unique 32-bit tag that must accompany any incoming SCTP 171 packet for this association to the External-Address. 173 Public-Address (Pub-Addr): The public address assigned to the NAT 174 box which it uses as a source address when sending packets towards 175 the External-Address. 177 Internal Network | External Network 178 | 179 Private | Public External 180 +---------+ Address | Address /--\/--\ Address +---------+ 181 | SCTP | +-----+ / \ | SCTP | 182 |end point|=========| NAT |=======| Internet |==========|end point| 183 | A | +-----+ \ / | B | 184 +---------+ Internal | \--/\--/ External+---------+ 185 Internal Port | Port External 186 VTag | VTag 188 Figure 1: Basic network setup 190 4. Problem Space Overview 192 When an SCTP endpoint is behind a NAT which supports 193 [I-D.ietf-behave-sctpnat] a number of problems may arise as it tries 194 to communicate with its peer: 196 o More than one server behind a NAT may pick the same VTag and 197 source port when talking to the same peer server. This creates a 198 situation where the NAT will not be able to tell the two 199 associations apart. This situation is discussed in Section 5. 201 o When an SCTP endpoint is a server and talking with multiple peers 202 and the peers are behind the same NAT, to the server the two 203 endpoints cannot be distinguished. This case is discussed in 204 Section 8. 206 o A NAT could at one point during a conversation restart causing all 207 of its state to be lost. This problem and its solution is 208 discussed in Section 6. 210 o An SCTP endpoint may be behind two NAT's giving it redundancy. 211 The method to set up this scenario is discussed in Section 7. 213 Each of these solutions requires additional chunks and parameters, 214 defined in this document, and possibly modified handling procedures 215 from those specified in [RFC4960]. 217 5. Handling of Internal Port Number and Verification Tag Collisions 219 Consider the case where two hosts in the Private-Address space want 220 to set up an SCTP association with the same server running on the 221 same host in the Internet. This means that the External-Port and the 222 External-Address are the same. If they both choose the same 223 Internal-Port and Internal-VTag, the NAT box cannot distinguish 224 incoming packets anymore. But this is very unlikely. The Internal- 225 VTags are chosen at random and if the Internal-Ports are also chosen 226 from the ephemeral port range at random this gives a 46-bit random 227 number which has to match. In the TCP like NAPT case the NAT box can 228 control the 16-bit Natted Port. 230 However, in this unlikely event the NAT box MUST respond to the INIT 231 chunk by sending an ABORT chunk with the M-bit set. The M-bit is a 232 new bit defined by this document to express to SCTP that the source 233 of this packet is a "middle" box, not the peer SCTP endpoint. The 234 source address of the packet containing the ABORT chunk MUST be the 235 destination address of the SCTP packet containing the INIT chunk. 237 The sender of the packet containing the INIT chunk, upon reception of 238 an ABORT with M-bit set SHOULD reinitiate the association setup 239 procedure after choosing a new initiate tag. These procedures SHOULD 240 be followed only if the appropriate error cause code for colliding 241 NAT table state is included AND the association is in the COOKIE-WAIT 242 state (i.e. it is awaiting a INIT-ACK). If the endpoint is in any 243 other state an SCTP endpoint SHOULD NOT respond. 245 The ABORT chunk defined in [RFC4960] is therefore extended by using 246 the following format: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type = 6 | Reserved |M|T| Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 \ \ 254 / zero or more Error Causes / 255 \ \ 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 The following error cause with cause code 0x00B0 (Colliding NAT table 259 entry) MUST be included in the ABORT chunk: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Cause Code = 0x00B0 | Cause Length = Variable | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 \ INIT chunk / 267 / \ 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 6. Handling of Missing State 272 If the NAT box receives a packet for which the lookup procedure does 273 not find an entry in the NAT table, a packet containing an ERROR 274 packet is sent back with the M-bit set. The source address of the 275 packet containing the ERROR chunk MUST be the destination address of 276 the incoming SCTP packet. The verification tag is reflected. 278 The ERROR chunk defined in [RFC4960] is therefore extended by using 279 the following format: 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type = 9 | Reserved |M|T| Length | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 \ \ 287 / zero or more Error Causes / 288 \ \ 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 The following error cause with cause code 0x00B1 (Missing NAT table 292 entry) SHOULD be included in the ERROR chunk: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Cause Code = 0x00B1 | Cause Length = Variable | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 \ Incoming Packet / 300 / \ 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Upon reception by an SCTP end-point with this ERROR chunk the 304 receiver SHOULD take the following actions: 306 o Validate the verification tag is reflected by looking at the VTag 307 that would have been included in the outgoing packet. 309 o Validate that the peer of the SCTP association supports the 310 dynamic address extension, if it does not discard the incoming 311 ERROR chunk. 313 o Generate a new ASCONF chunk as defined below including both sets 314 of VTags so that the NAT may recover the appropriate state. The 315 procedures for generating an ASCONF chunk can be found in 316 [RFC5061]. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Parameter Type = 0xC008 | Parameter Length = 16 | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | ASCONF-Request Correlation ID | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Internal Verification Tag | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | External Verification Tag | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 If the NAT box receives a packet for which it has no NAT table entry 331 and the packet contains an ASCONF chunk with a VTAG parameter, the 332 NAT box MUST update its NAT table according to the verification tags 333 in the VTAG parameter. 335 The peer SCTP endpoint receiving such an ASCONF chunk SHOULD either 336 add the address and respond with an acknowledgment, if the address is 337 new to the association (following all procedures defined in 338 [RFC5061]). Or, if the address is already part of the association, 339 the SCTP endpoint MUST NOT respond with an error, but instead should 340 respond with an ASCONF-ACK chunk acknowledging the address but take 341 no action (since the address is already in the association). 343 7. Multi Point Traversal Considerations 345 If a multi-homed SCTP end-point behind a NAT connects to a peer, it 346 SHOULD first set up the association single-homed with only one 347 address causing the first NAT to populate its state. Then it SHOULD 348 add each IP address using ASCONF chunks sent via their respective 349 NATs. The address to add is the wildcard address and the lookup 350 address SHOULD also contain the VTAG parameter pair illustrated 351 above. 353 8. Handling of Internal Port Number Collisions 355 When two SCTP hosts are behind a NAT and using the recommendations in 356 [I-D.ietf-behave-sctpnat] it is possible that two SCTP hosts in the 357 Private-Address space will want to set up an SCTP association with 358 the same server running on the same host in the Internet. For the 359 NAT appropriate tracking may be performed by assuring that the VTags 360 are unique between the two hosts as defined in 361 [I-D.ietf-behave-sctpnat]. But for the external SCTP server on the 362 internet this means that the External-Port and the External-Address 363 are the same. If they both have chosen the same Internal-Port the 364 server cannot distinguish both associations based on the address and 365 port numbers. For the server it looks like the association is being 366 restarted. To overcome this limitation the client sends a 367 DISABLE_RESTART parameter in the INIT-chunk which is defined as 368 follows: 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type = 0xC007 | Length = 4 | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 When the server receives this parameter it MUST do the following: 378 o Include in the INIT-ACK a DISABLE_RESTART parameter to inform the 379 client that it will support the feature. 381 o Disable the restart procedures defined in [RFC4960] for this 382 association. 384 Servers that support this feature will need to be capable of 385 maintaining multiple connections to what appears to be the same peer 386 (behind the NAT) differentiated only by the VTags. 388 The NAT, when processing the INIT-ACK, should note in its internal 389 table that the external server supports the DISABLE_RESTART 390 extension. This note is used when establishing future associations 391 (i.e. when processing an INIT from an internal host) to decide if the 392 connection should be allowed. The NAT MUST do the following when 393 processing an INIT: 395 o If the INIT is destined to an external address and port for which 396 the NAT has no outbound connection, allow the INIT creating an 397 internal mapping table. 399 o If the INIT matches the external address and port of an already 400 existing connection, validate that the external server supports 401 the DISABLE_RESTART feature. If it does allow the INIT to be 402 forwarded. 404 o If the external server does not support the DISABLE_RESTART 405 extension the NAT MUST send an ABORT with the M-bit set. 407 The following error cause with cause code 0x00B2 (Duplicate Local 408 Port with DISABLE_RESTART not Supported) MUST be included in the 409 ABORT chunk: 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Cause Code = 0x00B2 | Cause Length = Variable | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 \ INIT chunk / 417 / \ 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 9. SCTP Socket API Considerations 422 TBD 424 10. IANA Considerations 426 M-Bit for ABORT and ERROR chunk (0x02). 428 Error cause Colliding NAT table entry, (0x00B1). 430 Error cause Duplicate Local Port with DISABLE_RESTART not Supported, 431 (0x00B2). 433 Disable restart parameter (0xC007). 435 ASCONF Parameter (0xC008). 437 11. Security Considerations 439 TBD 441 12. Acknowledgments 443 The authors wish to thank Jason But, Bryan Ford, David Hayes, Alfred 444 Hines, Henning Peters, Timo Voelker, Dan Wing, and Qiaobing Xie for 445 their invaluable comments. 447 13. References 449 13.1. Normative References 451 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 452 RFC 793, September 1981. 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, March 1997. 457 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 458 "Authenticated Chunks for the Stream Control Transmission 459 Protocol (SCTP)", RFC 4895, August 2007. 461 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 462 RFC 4960, September 2007. 464 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 465 Kozuka, "Stream Control Transmission Protocol (SCTP) 466 Dynamic Address Reconfiguration", RFC 5061, 467 September 2007. 469 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 470 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 471 January 2011. 473 [I-D.ietf-tsvwg-sctp-udp-encaps] 474 Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP 475 Packets", draft-ietf-tsvwg-sctp-udp-encaps-04 (work in 476 progress), July 2012. 478 13.2. Informative References 480 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 481 BCP 153, RFC 5735, January 2010. 483 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 484 Transport Layer Security (DTLS) for Stream Control 485 Transmission Protocol (SCTP)", RFC 6083, January 2011. 487 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 488 Yasevich, "Sockets API Extensions for the Stream Control 489 Transmission Protocol (SCTP)", RFC 6458, December 2011. 491 [I-D.ietf-behave-sctpnat] 492 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 493 Transmission Protocol (SCTP) Network Address Translation", 494 draft-ietf-behave-sctpnat-06 (work in progress), 495 March 2012. 497 Authors' Addresses 499 Randall R. Stewart 500 Adara Networks 501 Chapin, SC 29036 502 USA 504 Email: randall@lakerest.net 506 Michael Tuexen 507 Muenster University of Applied Sciences 508 Stegerwaldstrasse 39 509 48565 Steinfurt 510 DE 512 Email: tuexen@fh-muenster.de 514 Irene Ruengeler 515 Muenster University of Applied Sciences 516 Stegerwaldstrasse 39 517 48565 Steinfurt 518 DE 520 Email: i.ruengeler@fh-muenster.de