idnits 2.17.1 draft-ietf-tsvwg-natsupp-15.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 : ---------------------------------------------------------------------------- == There are 36 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2019) is 1620 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) == Missing Reference: 'Initiate-Tag' is mentioned on line 461, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1735, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Netflix, Inc. 4 Intended status: Standards Track M. Tuexen 5 Expires: May 20, 2020 I. Ruengeler 6 Muenster Univ. of Appl. Sciences 7 November 17, 2019 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 Support 11 draft-ietf-tsvwg-natsupp-15 13 Abstract 15 The Stream Control Transmission Protocol (SCTP) provides a reliable 16 communications channel between two end-hosts in many ways similar to 17 the Transmission Control Protocol (TCP). With the widespread 18 deployment of Network Address Translators (NAT), specialized code has 19 been added to NAT for TCP that allows multiple hosts to reside behind 20 a NAT and yet use only a single globally unique IPv4 address, even 21 when two hosts (behind a NAT) choose the same port numbers for their 22 connection. This additional code is sometimes classified as Network 23 Address and Port Translation (NAPT). 25 This document describes the protocol extensions required for the SCTP 26 endpoints and the mechanisms for NAT devices necessary to provide 27 similar features of NAPT in the single point and multi point 28 traversal scenario. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 20, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . 6 69 4.1.1. Single Point Traversal . . . . . . . . . . . . . . . 6 70 4.1.2. Multi Point Traversal . . . . . . . . . . . . . . . . 7 71 4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 8 72 4.3. The SCTP-Specific Variant of NAT . . . . . . . . . . . . 8 73 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 12 75 5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 12 76 5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 13 77 5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 13 78 5.2.1. VTag and Port Number Collision Error Cause . . . . . 14 79 5.2.2. Missing State Error Cause . . . . . . . . . . . . . . 14 80 5.2.3. Port Number Collision Error Cause . . . . . . . . . . 15 81 5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 16 82 5.3.1. Disable Restart Parameter . . . . . . . . . . . . . . 16 83 5.3.2. VTags Parameter . . . . . . . . . . . . . . . . . . . 16 84 6. Procedures for SCTP Endpoints and NAT Devices . . . . . . . . 18 85 6.1. Association Setup Considerations for Endpoints . . . . . 18 86 6.2. Handling of Internal Port Number and Verification Tag 87 Collisions . . . . . . . . . . . . . . . . . . . . . . . 19 88 6.2.1. NAT Device Considerations . . . . . . . . . . . . . . 19 89 6.2.2. Endpoint Considerations . . . . . . . . . . . . . . . 19 90 6.3. Handling of Internal Port Number Collisions . . . . . . . 20 91 6.3.1. NAT Device Considerations . . . . . . . . . . . . . . 20 92 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 93 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21 94 6.4.1. NAT Device Considerations . . . . . . . . . . . . . . 21 95 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 22 96 6.5. Handling of Fragmented SCTP Packets by NAT Devices . . . 23 97 6.6. Multi Point Traversal Considerations for Endpoints . . . 23 98 7. Various Examples of NAT Traversals . . . . . . . . . . . . . 23 99 7.1. Single-homed Client to Single-homed Server . . . . . . . 24 100 7.2. Single-homed Client to Multi-homed Server . . . . . . . . 26 101 7.3. Multihomed Client and Server . . . . . . . . . . . . . . 29 102 7.4. NAT Loses Its State . . . . . . . . . . . . . . . . . . . 33 103 7.5. Peer-to-Peer Communication . . . . . . . . . . . . . . . 35 104 8. Socket API Considerations . . . . . . . . . . . . . . . . . . 40 105 8.1. Get or Set the NAT Friendliness 106 (SCTP_NAT_FRIENDLY) . . . . . . . . . . . . . . . . . . . 41 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 108 9.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 41 109 9.2. Three New Error Causes . . . . . . . . . . . . . . . . . 42 110 9.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 43 111 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 112 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 114 12.1. Normative References . . . . . . . . . . . . . . . . . . 44 115 12.2. Informative References . . . . . . . . . . . . . . . . . 44 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 118 1. Introduction 120 Stream Control Transmission Protocol [RFC4960] provides a reliable 121 communications channel between two end-hosts in many ways similar to 122 TCP [RFC0793]. With the widespread deployment of Network Address 123 Translators (NAT), specialized code has been added to NAT for TCP 124 that allows multiple hosts to reside behind a NAT using private 125 addresses (see [RFC6890]) and yet use only a single globally unique 126 IPv4 address, even when two hosts (behind a NAT) choose the same port 127 numbers for their connection. This additional code is sometimes 128 classified as Network Address and Port Translation (NAPT). Please 129 note that this document focuses on the case where the NAT maps a 130 single or multiple private addresses to a single public address and 131 vice versa. To date, specialized code for SCTP has not yet been 132 added to most NAT devices so that only a translation of IP addresses 133 is supported. The end result of this is that only one SCTP-capable 134 host can successfully operate behind such a NAT and this host can 135 only be single-homed. The only alternative for supporting legacy NAT 136 devices is to use UDP encapsulation as specified in [RFC6951]. 138 This document specifies procedures allowing a NAT to support SCTP by 139 providing similar features to those provided by a NAPT for TCP and 140 other supported protocols. The document also specifies a set of data 141 formats for SCTP packets and a set of SCTP endpoint procedures to 142 support NAT traversal. An SCTP implementation supporting these 143 procedures can assure that in both single-homed and multi-homed cases 144 a NAT will maintain the appropriate state without the NAT needing to 145 change port numbers. 147 It is possible and desirable to make these changes for a number of 148 reasons: 150 o It is desirable for SCTP internal end-hosts on multiple platforms 151 to be able to share a NAT's public IP address in the same way that 152 a TCP session can use a NAT. 154 o If a NAT does not need to change any data within an SCTP packet it 155 will reduce the processing burden of NAT'ing SCTP by NOT needing 156 to execute the CRC32c checksum required by SCTP. 158 o Not having to touch the IP payload makes the processing of ICMP 159 messages in NAT devices easier. 161 An SCTP-aware NAT will need to follow these procedures for generating 162 appropriate SCTP packet formats. 164 When considering this feature it is possible to have multiple levels 165 of support. At each level, the Internal Host, External Host and NAT 166 may or may not support the features described in this document. The 167 following table illustrates the results of the various combinations 168 of support and if communications can occur between two endpoints. 170 +---------------+------------+---------------+---------------+ 171 | Internal Host | NAT Device | External Host | Communication | 172 +---------------+------------+---------------+---------------+ 173 | Support | Support | Support | Yes | 174 | Support | Support | No Support | Limited | 175 | Support | No Support | Support | None | 176 | Support | No Support | No Support | None | 177 | No Support | Support | Support | Limited | 178 | No Support | Support | No Support | Limited | 179 | No Support | No Support | Support | None | 180 | No Support | No Support | No Support | None | 181 +---------------+------------+---------------+---------------+ 183 Table 1: Communication possibilities 185 From the table it can be seen that when a NAT device does not support 186 the extension no communication can occur. This assumes that the NAT 187 device does not handle SCTP packets at all and all SCTP packets sent 188 externally from behind a NAT device are discarded by the NAT. In 189 some cases, where the NAT device supports the feature but one of the 190 two hosts does not support the feature, communication may occur but 191 in a limited way. For example only one host may be able to have a 192 connection when a collision case occurs. 194 2. Conventions 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 198 "OPTIONAL" in this document are to be interpreted as described in BCP 199 14 [RFC2119] [RFC8174] when, and only when, they appear in all 200 capitals, as shown here. 202 3. Terminology 204 This document uses the following terms, which are depicted in 205 Figure 1. Familiarity with the terminology used in [RFC4960] and 206 [RFC5061] is assumed. 208 Private-Address (Priv-Addr): The private address that is known to 209 the internal host. 211 Internal-Port (Int-Port): The port number that is in use by the host 212 holding the Private-Address. 214 Internal-VTag (Int-VTag): The SCTP Verification Tag (VTag) (see 215 Section 3.1 of [RFC4960]) that the internal host has chosen for 216 its communication. The VTag is a unique 32-bit tag that must 217 accompany any incoming SCTP packet for this association to the 218 Private-Address. 220 External-Address (Ext-Addr): The address that an internal host is 221 attempting to contact. 223 External-Port (Ext-Port): The port number of the peer process at the 224 External-Address. 226 External-VTag (Ext-VTag): The Verification Tag that the host holding 227 the External-Address has chosen for its communication. The VTag 228 is a unique 32-bit tag that must accompany any incoming SCTP 229 packet for this association to the External-Address. 231 Public-Address (Pub-Addr): The public address assigned to the NAT 232 device that it uses as a source address when sending packets 233 towards the External-Address. 235 Internal Network | External Network 236 | 237 Private | Public External 238 +--------+ Address | Address /--\/--\ Address +--------+ 239 | SCTP | +-----+ / \ | SCTP | 240 |endpoint|=========| NAT |=======| Internet |==========|endpoint| 241 | A | +-----+ \ / | B | 242 +--------+ Internal | \--/\--/ External+--------+ 243 Internal Port | Port External 244 VTag | VTag 246 Figure 1: Basic network setup 248 4. Motivation 250 4.1. SCTP NAT Traversal Scenarios 252 This section defines the notion of single and multi point NAT 253 traversal. 255 4.1.1. Single Point Traversal 257 In this case, all packets in the SCTP association go through a single 258 NAT, as shown below: 260 Internal Network | External Network 261 | 262 +--------+ | /--\/--\ +--------+ 263 | SCTP | +-----+ / \ | SCTP | 264 |endpoint|=========| NAT |========= | Internet | ========|endpoint| 265 | A | +-----+ \ / | B | 266 +--------+ | \--/\--/ +--------+ 267 | 269 Single NAT scenario 271 A variation of this case is shown below, i.e., multiple NAT devices 272 in a single path: 274 Internal | External : Internal | External 275 | : | 276 +--------+ | : | /--\/--\ +--------+ 277 | SCTP | +-----+ : +-----+ / \ | SCTP | 278 |endpoint|==| NAT |=======:=======| NAT |==| Internet |==|endpoint| 279 | A | +-----+ : +-----+ \ / | B | 280 +--------+ | : | \--/\--/ +--------+ 281 | : | 283 Serial NAT Devices scenario 285 Although one of the main benefits of SCTP multi-homing is redundant 286 paths, in the single point traversal scenario the NAT function 287 represents a single point of failure in the path of the SCTP multi- 288 homed association. However, the rest of the path may still benefit 289 from path diversity provided by SCTP multi-homing. 291 The two SCTP endpoints in this case can be either single-homed or 292 multi-homed. However, the important thing is that the NAT device (or 293 NAT devices) in this case sees all the packets of the SCTP 294 association. 296 4.1.2. Multi Point Traversal 298 This case involves multiple NAT devices and each NAT device only sees 299 some of the packets in the SCTP association. An example is shown 300 below: 302 Internal | External 303 +------+ /---\/---\ 304 +--------+ /=======|NAT A |=========\ / \ +--------+ 305 | SCTP | / +------+ \/ \ | SCTP | 306 |endpoint|/ ... | Internet |===|endpoint| 307 | A |\ \ / | B | 308 +--------+ \ +------+ / \ / +--------+ 309 \=======|NAT B |=========/ \---\/---/ 310 +------+ 311 | 313 Parallel NAT devices scenario 315 This case does NOT apply to a single-homed SCTP association (i.e., 316 BOTH endpoints in the association use only one IP address). The 317 advantage here is that the existence of multiple NAT traversal points 318 can preserve the path diversity of a multi-homed association for the 319 entire path. This in turn can improve the robustness of the 320 communication. 322 4.2. Limitations of Classical NAPT for SCTP 324 Using classical NAPT may result in changing one of the SCTP port 325 numbers during the processing which requires the recomputation of the 326 transport layer checksum by the NAPT device. Whereas for UDP and TCP 327 this can be done very efficiently, for SCTP the checksum (CRC32c) 328 over the entire packet needs to be recomputed. See Appendix B of 329 [RFC4960] for details of the CRC32c computation. This would 330 considerably add to the NAT computational burden, however hardware 331 support may mitigate this in some implementations. 333 An SCTP endpoint may have multiple addresses but only has a single 334 port number. To make multipoint traversal work, all the NAT devices 335 involved must recognize the packets they see as belonging to the same 336 SCTP association and perform port number translation in a consistent 337 way. One possible way of doing this is to use a pre-defined table of 338 ports and addresses configured within each NAT. Other mechanisms 339 could make use of NAT to NAT communication. Such mechanisms have not 340 been deployabled on a wide scale base and thus are not a recommended 341 solution. Therefore the SCTP variant of NAT has been developed. 343 4.3. The SCTP-Specific Variant of NAT 345 In this section it is allowed that there are multiple SCTP capable 346 hosts behind a NAT that has one Public-Address. Furthermore this 347 section focuses on the single point traversal scenario. 349 The modification of SCTP packets sent to the public Internet is 350 simple: the source address of the packet has to be replaced with the 351 Public-Address. It may also be necessary to establish some state in 352 the NAT device to later handle incoming packets. 354 For the SCTP NAT processing the NAT device has to maintain a NAT 355 binding table of Internal-VTag, Internal-Port, External-VTag, 356 External-Port, Private-Address, and whether the restart procedure is 357 disabled or not. An entry in that NAT binding table is called a NAT 358 state control block. The function Create() obtains the just 359 mentioned parameters and returns a NAT-State control block. 361 For SCTP packets coming from the public Internet the destination 362 address of the packets has to be replaced with the Private-Address of 363 the host the packet has to be delivered to. The lookup of the 364 Private-Address is based on the External-VTag, External-Port, 365 Internal-VTag and the Internal-Port. 367 The entries in the NAT binding table need to fulfill some uniqueness 368 conditions. There must not be more than one entry NAT binding table 369 with the same pair of Internal-Port and External-Port. This rule can 370 be relaxed, if all NAT binding table entries with the same Internal- 371 Port and External-Port have the support for the restart procedure 372 enabled. In this case there must be no more than one entry with the 373 same Internal-Port, External-Port and Ext-VTag and no more than one 374 NAT binding table entry with the same Internal-Port, External-Port 375 and Int-VTag. 377 The processing of outgoing SCTP packets containing an INIT chunk is 378 described in the following figure. The scenario shown is valid for 379 all message flows in this section. 381 /--\/--\ 382 +--------+ +-----+ / \ +--------+ 383 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 384 +--------+ +-----+ \ / +--------+ 385 \--/\---/ 387 INIT[Initiate-Tag] 388 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 389 Ext-VTag=0 391 Create(Initiate-Tag, Int-Port, 0, Ext-Port, Priv-Addr, 392 RestartSupported) 393 Returns(NAT-State control block) 395 Translate To: 397 INIT[Initiate-Tag] 398 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 399 Ext-VTag=0 401 Normally a NAT binding table entry will be created. 403 However, it is possible that there is already a NAT binding table 404 entry with the same External-Port, Internal-Port, and Internal-VTag 405 but different Private-Address. In this case the INIT MUST be dropped 406 by the NAT and an ABORT MUST be sent back to the SCTP host with the 407 M-Bit set and an appropriate error cause (see Section 5.1.1 for the 408 format). The source address of the packet containing the ABORT chunk 409 MUST be the destination address of the packet containing the INIT 410 chunk. 412 It is also possible that a connection to External-Address and 413 External-Port exists without an Internal-VTag conflict but there 414 exists a NAT binding table entry with the same port numbers but a 415 different Private-Address. In such a case the INIT MUST be dropped 416 by the NAT and an ABORT SHOULD be sent back to the SCTP host with the 417 M-Bit set and an appropriate error cause (see Section 5.1.1 for the 418 format). 420 The processing of outgoing SCTP packets containing no INIT chunks is 421 described in the following figure. 423 /--\/--\ 424 +--------+ +-----+ / \ +--------+ 425 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 426 +--------+ +-----+ \ / +--------+ 427 \--/\---/ 429 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 430 Ext-VTag 432 Translate To: 434 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 435 Ext-VTag 437 The processing of incoming SCTP packets containing an INIT ACK chunk 438 is described in the following figure. The Lookup() function getting 439 as input the Internal-VTag, Internal-Port, External-VTag, and 440 External-Port, returns the corresponding entry of the NAT binding 441 table and updates the External-VTag by substituting it with the value 442 of the Initiate-Tag of the INIT ACK chunk. The wildcard character 443 signifies that the parameter's value is not considered in the 444 Lookup() function or changed in the Update() function, respectively. 446 /--\/--\ 447 +--------+ +-----+ / \ +--------+ 448 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 449 +--------+ +-----+ \ / +--------+ 450 \--/\---/ 452 INIT ACK[Initiate-Tag] 453 Pub-Addr:Int-Port <---- Ext-Addr:Ext-Port 454 Int-VTag 456 Lookup(Int-VTag, Int-Port, *, Ext-Port) 457 Update(*, *, Initiate-Tag, *) 459 Returns(NAT-State control block containing Priv-Addr) 461 INIT ACK[Initiate-Tag] 462 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 463 Int-VTag 465 In the case Lookup fails, the SCTP packet is dropped. If it 466 succeeds, the Update routine inserts the External-VTag (the Initiate- 467 Tag of the INIT ACK chunk) in the NAT state control block. 469 The processing of incoming SCTP packets containing an ABORT or 470 SHUTDOWN COMPLETE chunk with the T-Bit set is described in the 471 following figure. 473 /--\/--\ 474 +--------+ +-----+ / \ +--------+ 475 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 476 +--------+ +-----+ \ / +--------+ 477 \--/\---/ 479 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 480 Ext-VTag 482 Lookup(*, Int-Port, Ext-VTag, Ext-Port) 484 Returns(NAT-State control block containing Priv-Addr) 486 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 487 Ext-VTag 489 For an incoming packet containing an INIT chunk a table lookup is 490 made only based on the addresses and port numbers. If an entry with 491 an External-VTag of zero is found, it is considered a match and the 492 External-VTag is updated. This allows the handling of INIT collision 493 through NAT. 495 The processing of other incoming SCTP packets is described in the 496 following figure. 498 /--\/--\ 499 +--------+ +-----+ / \ +--------+ 500 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 501 +--------+ +-----+ \ / +--------+ 502 \--/\---/ 504 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 505 Int-VTag 507 Lookup(Int-VTag, Int-Port, *, Ext-Port) 509 Returns(NAT-State control block containing Private-Address) 511 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 512 Int-VTag 514 5. Data Formats 516 This section defines the formats used to support NAT traversal. 517 Section 5.1 and Section 5.2 describe chunks and error causes sent by 518 NAT devices and received by SCTP endpoints. Section 5.3 describes 519 parameters sent by SCTP endpoints and used by NAT devices and SCTP 520 endpoints. 522 5.1. Modified Chunks 524 This section presents existing chunks defined in [RFC4960] that are 525 modified by this document. 527 5.1.1. Extended ABORT Chunk 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Type = 6 | Reserved |M|T| Length | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 \ \ 534 / zero or more Error Causes / 535 \ \ 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 The ABORT chunk is extended to add the new 'M-bit'. The M-bit 539 indicates to the receiver of the ABORT chunk that the chunk was not 540 generated by the peer SCTP endpoint, but instead by a middle box. 542 [NOTE to RFC-Editor: 544 Assignment of M-bit to be confirmed by IANA. 546 ] 548 5.1.2. Extended ERROR Chunk 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Type = 9 | Reserved |M|T| Length | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 \ \ 556 / zero or more Error Causes / 557 \ \ 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 The ERROR chunk defined in [RFC4960] is extended to add the new 561 'M-bit'. The M-bit indicates to the receiver of the ERROR chunk that 562 the chunk was not generated by the peer SCTP endpoint, but instead by 563 a middle box. 565 [NOTE to RFC-Editor: 567 Assignment of M-bit to be confirmed by IANA. 569 ] 571 5.2. New Error Causes 573 This section defines the new error causes added by this document. 575 5.2.1. VTag and Port Number Collision Error Cause 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Cause Code = 0x00B0 | Cause Length = Variable | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 \ Chunk / 583 / \ 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Cause Code: 2 bytes (unsigned integer) 587 This field holds the IANA defined cause code for the 'VTag and 588 Port Number Collision' Error Cause. IANA is requested to assign 589 the value 0x00B0 for this cause code. 591 Cause Length: 2 bytes (unsigned integer) 592 This field holds the length in bytes of the error cause. The 593 value MUST be the length of the Cause-Specific Information plus 4. 595 Chunk: variable length 596 The Cause-Specific Information is filled with the chunk that 597 caused this error. This can be an INIT, INIT ACK, or ASCONF 598 chunk. Note that if the entire chunk will not fit in the ERROR 599 chunk or ABORT chunk being sent then the bytes that do not fit are 600 truncated. 602 [NOTE to RFC-Editor: 604 Assignment of cause code to be confirmed by IANA. 606 ] 608 5.2.2. Missing State Error Cause 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Cause Code = 0x00B1 | Cause Length = Variable | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 \ Incoming Packet / 616 / \ 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 Cause Code: 2 bytes (unsigned integer) 620 This field holds the IANA defined cause code for the 'Missing 621 State' Error Cause. IANA is requested to assign the value 0x00B1 622 for this cause code. 624 Cause Length: 2 bytes (unsigned integer) 625 This field holds the length in bytes of the error cause. The 626 value MUST be the length of the Cause-Specific Information plus 4. 628 Incoming Packet: variable length 629 The Cause-Specific Information is filled with the IPv4 or IPv6 630 packet that caused this error. The IPv4 or IPv6 header MUST be 631 included. Note that if the packet will not fit in the ERROR chunk 632 or ABORT chunk being sent then the bytes that do not fit are 633 truncated. 635 [NOTE to RFC-Editor: 637 Assignment of cause code to be confirmed by IANA. 639 ] 641 5.2.3. Port Number Collision Error Cause 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Cause Code = 0x00B2 | Cause Length = Variable | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 \ Chunk / 649 / \ 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 Cause Code: 2 bytes (unsigned integer) 653 This field holds the IANA defined cause code for the 'Port Number 654 Collision' Error Cause. IANA is requested to assign the value 655 0x00B2 for this cause code. 657 Cause Length: 2 bytes (unsigned integer) 658 This field holds the length in bytes of the error cause. The 659 value MUST be the length of the Cause-Specific Information plus 4. 661 Chunk: variable length 662 The Cause-Specific Information is filled with the chunk that 663 caused this error. This can be an INIT, INIT ACK, or ASCONF 664 chunk. Note that if the entire chunk will not fit in the ERROR 665 chunk or ABORT chunk being sent then the bytes that do not fit are 666 truncated. 668 [NOTE to RFC-Editor: 670 Assignment of cause code to be confirmed by IANA. 672 ] 674 5.3. New Parameters 676 This section defines new parameters and their valid appearance 677 defined by this document. 679 5.3.1. Disable Restart Parameter 681 This parameter is used to indicate that the restart procedure is 682 requested to be disabled. Both endpoints of an association MUST 683 include this parameter in the INIT chunk and INIT ACK chunk when 684 establishing an association and MUST include it in the ASCONF chunk 685 when adding an address to successfully disable the restart procedure. 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Type = 0xC007 | Length = 4 | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Parameter Type: 2 bytes (unsigned integer) 694 This field holds the IANA defined parameter type for the Disable 695 Restart Parameter. IANA is requested to assign the value 0xC007 696 for this parameter type. 698 Parameter Length: 2 bytes (unsigned integer) 699 This field holds the length in bytes of the parameter. The value 700 MUST be 4. 702 [NOTE to RFC-Editor: 704 Assignment of parameter type to be confirmed by IANA. 706 ] 708 This parameter MAY appear in INIT, INIT ACK and ASCONF chunks and 709 MUST NOT appear in any other chunk. 711 5.3.2. VTags Parameter 713 This parameter is used to help a NAT recover from state loss. 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Parameter Type = 0xC008 | Parameter Length = 16 | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | ASCONF-Request Correlation ID | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Internal Verification Tag | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | External Verification Tag | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 Parameter Type: 2 bytes (unsigned integer) 728 This field holds the IANA defined parameter type for the VTags 729 Parameter. IANA is requested to assign the value 0xC008 for this 730 parameter type. 732 Parameter Length: 2 bytes (unsigned integer) 733 This field holds the length in bytes of the parameter. The value 734 MUST be 16. 736 ASCONF-Request Correlation ID: 4 bytes (unsigned integer) 737 This is an opaque integer assigned by the sender to identify each 738 request parameter. The receiver of the ASCONF Chunk will copy 739 this 32-bit value into the ASCONF Response Correlation ID field of 740 the ASCONF ACK response parameter. The sender of the ASCONF can 741 use this same value in the ASCONF ACK to find which request the 742 response is for. Note that the receiver MUST NOT change this 743 32-bit value. 745 Internal Verification Tag: 4 bytes (unsigned integer) 746 The Verification Tag that the internal host has chosen for its 747 communication. The Verification Tag is a unique 32-bit tag that 748 must accompany any incoming SCTP packet for this association to 749 the Private-Address. 751 External Verification Tag: 4 bytes (unsigned integer) The 752 Verification Tag that the host holding the External-Address has 753 chosen for its communication. The VTag is a unique 32-bit tag 754 that must accompany any incoming SCTP packet for this association 755 to the External-Address. 757 [NOTE to RFC-Editor: 759 Assignment of parameter type to be confirmed by IANA. 761 ] 762 This parameter MAY appear in ASCONF chunks and MUST NOT appear in any 763 other chunk. 765 6. Procedures for SCTP Endpoints and NAT Devices 767 When an SCTP endpoint is behind an SCTP-aware NAT a number of 768 problems may arise as it tries to communicate with its peer: 770 o IP addresses can not not be included in the SCTP packet. This is 771 discussed in Section 6.1. 773 o More than one host behind a NAT device could select the same VTag 774 and source port when talking to the same peer server. This 775 creates a situation where the NAT will not be able to tell the two 776 associations apart. This situation is discussed in Section 6.2. 778 o When an SCTP endpoint is a server communicating with multiple 779 peers and the peers are behind the same NAT, then the two 780 endpoints cannot be distinguished by the server. This case is 781 discussed in Section 6.3. 783 o A restart of a NAT during a conversation could cause a loss of its 784 state. This problem and its solution is discussed in Section 6.4. 786 o NAT devices need to deal with SCTP packets being fragmented at the 787 IP layer. This is discussed in Section 6.5. 789 o An SCTP endpoint may be behind two NAT devices providing 790 redundancy. The method to set up this scenario is discussed in 791 Section 6.6. 793 Each of these mechanisms requires additional chunks and parameters, 794 defined in this document, and possibly modified handling procedures 795 from those specified in [RFC4960]. 797 6.1. Association Setup Considerations for Endpoints 799 The association setup procedure defined in [RFC4960] allows multi- 800 homed SCTP endpoints to exchange its IP-addresses by using IPv4 or 801 IPv6 address parameters in the INIT and INIT ACK chunks. However, 802 this doesn't work when NAT devices are present. 804 Every association setup from a host behind a NAT MUST NOT use 805 multiple private addresses. There MUST NOT be any IPv4 Address 806 parameter, IPv6 Address parameter, or Supported Address Types 807 parameter in the INIT chunk. The INIT ACK chunk MUST NOT contain any 808 IPv4 Address parameter or IPv6 Address parameter using non-global 809 addresses. The INIT chunk and the INIT ACK chunk MUST NOT contain 810 any Host Name parameters. 812 If the association should finally be multi-homed, the procedure in 813 Section 6.6 MUST be used. 815 The INIT and INIT ACK chunk SHOULD contain the Disable Restart 816 parameter defined in Section 5.3.1. 818 6.2. Handling of Internal Port Number and Verification Tag Collisions 820 Consider the case where two hosts in the Private-Address space want 821 to set up an SCTP association with the same service provided by some 822 hosts in the Internet. This means that the External-Port is the 823 same. If they both choose the same Internal-Port and Internal-VTag, 824 the NAT device cannot distinguish between incoming packets anymore. 825 But this is very unlikely. The Internal-VTags are chosen at random 826 and if the Internal-Ports are also chosen from the ephemeral port 827 range at random this gives a 46-bit random number that has to match. 828 A NAPT device can control the 16-bit Natted Port and therefore avoid 829 collisions deterministically. 831 The same can happen with the External-VTag when an INIT ACK chunk or 832 an ASCONF chunk is processed by the NAT. 834 6.2.1. NAT Device Considerations 836 If the NAT device detects a collision of internal port numbers and 837 verification tags, it MUST send an ABORT chunk with the M-bit set if 838 the collision is triggered by an INIT or INIT ACK chunk. If such a 839 collision is triggered by an ASCONF chunk, it MUST send an ERROR 840 chunk with the M-bit. The M-bit is a new bit defined by this 841 document to express to SCTP that the source of this packet is a 842 "middle" box, not the peer SCTP endpoint (see Section 5.1.1). If a 843 packet containing an INIT ACK chunk triggers the collision, the 844 corresponding packet containing the ABORT chunk MUST contain the same 845 source and destination address and port numbers as the packet 846 containing the INIT ACK chunk. In the other two cases, the source 847 and destination address and port numbers MUST be swapped. 849 The sender of the ERROR or ABORT chunk MUST include the error cause 850 with cause code 'VTag and Port Number Collision' (see Section 5.2.1). 852 6.2.2. Endpoint Considerations 854 The sender of the packet containing the INIT chunk or the receiver of 855 the INIT ACK chunk, upon reception of an ABORT chunk with M-bit set 856 and the appropriate error cause code for colliding NAT binding table 857 state is included, SHOULD reinitiate the association setup procedure 858 after choosing a new initiate tag, if the association is in COOKIE- 859 WAIT state. In any other state, the SCTP endpoint MUST NOT respond. 861 The sender of the ASCONF chunk, upon reception of an ERROR chunk with 862 M-bit set, MUST stop adding the path to the association. 864 6.3. Handling of Internal Port Number Collisions 866 When two SCTP hosts are behind an SCTP-aware NAT it is possible that 867 two SCTP hosts in the Private-Address space will want to set up an 868 SCTP association with the same server running on the same host in the 869 Internet. If the two hosts choose the same internal port, this is 870 considered an internal port number collision. 872 For the NAT, appropriate tracking may be performed by assuring that 873 the VTags are unique between the two hosts. 875 6.3.1. NAT Device Considerations 877 The NAT, when processing the INIT ACK, should note in its NAT binding 878 table that the association supports the disable restart extension. 879 This note is used when establishing future associations (i.e. when 880 processing an INIT from an internal host) to decide if the connection 881 should be allowed. The NAT device does the following when processing 882 an INIT: 884 o If the INIT is originating from an internal port to an external 885 port for which the NAT device has no matching NAT binding table 886 entry, it MUST allow the INIT creating an NAT binding table entry. 888 o If the INIT matches an existing NAT binding table entry, it MUST 889 validate that the disable restart feature is supported and, if it 890 does, allow the INIT to be forwarded. 892 o If the disable restart feature is not supported, the NAT device 893 MUST send an ABORT with the M-bit set. 895 The 'Port Number Collision' error cause (see Section 5.2.3) MUST be 896 included in the ABORT chunk sent in response to the INIT chunk. 898 If the collision is triggered by an ASCONF chunk, a packet containing 899 an ERROR chunk with the 'Port Number Collision' error cause MUST be 900 sent in response to the ASCONF chunk. 902 6.3.2. Endpoint Considerations 904 For the external SCTP server on the Internet this means that the 905 External-Port and the External-Address are the same. If they both 906 have chosen the same Internal-Port the server cannot distinguish 907 between both associations based on the address and port numbers. For 908 the server it looks like the association is being restarted. To 909 overcome this limitation the client sends a Disable Restart parameter 910 in the INIT chunk. 912 When the server receives this parameter it does the following: 914 o It MUST include a Disable Restart parameter in the INIT ACK to 915 inform the client that it will support the feature. 917 o It MUST disable the restart procedures defined in [RFC4960] for 918 this association. 920 Servers that support this feature will need to be capable of 921 maintaining multiple connections to what appears to be the same peer 922 (behind the NAT) differentiated only by the VTags. 924 6.4. Handling of Missing State 926 6.4.1. NAT Device Considerations 928 If the NAT device receives a packet from the internal network for 929 which the lookup procedure does not find an entry in the NAT binding 930 table, a packet containing an ERROR chunk is sent back with the M-bit 931 set. The source address of the packet containing the ERROR chunk 932 MUST be the destination address of the incoming SCTP packet. The 933 verification tag is reflected and the T-bit is set. Such a packet 934 containing an ERROR chunk SHOULD NOT be sent if the received packet 935 contains an ABORT, SHUTDOWN COMPLETE or INIT ACK chunk. An ERROR 936 chunk MUST NOT be sent if the received packet contains an ERROR chunk 937 with the M-bit set. In any case, the packet SHOULD NOT be forwarded 938 to the external address. 940 When sending the ERROR chunk, the error cause 'Missing State' (see 941 Section 5.2.2) MUST be included and the M-bit of the ERROR chunk MUST 942 be set (see Section 5.1.2). 944 If the NAT device receives a packet for which it has no NAT binding 945 table entry and the packet contains an ASCONF chunk with the VTags 946 parameter, the NAT device MUST update its NAT binding table according 947 to the verification tags in the VTags parameter and the optional 948 Disable Restart parameter. 950 6.4.2. Endpoint Considerations 952 Upon reception of this ERROR chunk by an SCTP endpoint the receiver 953 takes the following actions: 955 o It SHOULD validate that the verification tag is reflected by 956 looking at the VTag that would have been included in the outgoing 957 packet. If the validation fails, discard the incoming ERROR 958 chunk. 960 o It SHOULD validate that the peer of the SCTP association supports 961 the dynamic address extension. If the validation fails, discard 962 the incoming ERROR chunk. 964 o It SHOULD generate a new ASCONF chunk containing the VTags 965 parameter (see Section 5.3.2) and the Disable Restart parameter 966 (see Section 5.3.1) if the association is using the disable 967 restart feature. By processing this packet the NAT device can 968 recover the appropriate state. The procedures for generating an 969 ASCONF chunk can be found in [RFC5061]. 971 The peer SCTP endpoint receiving such an ASCONF chunk SHOULD either 972 add the address and respond with an acknowledgment, if the address is 973 new to the association (following all procedures defined in 974 [RFC5061]). Or, if the address is already part of the association, 975 the SCTP endpoint MUST NOT respond with an error, but instead SHOULD 976 respond with an ASCONF ACK chunk acknowledging the address and take 977 no action (since the address is already in the association). 979 Note that it is possible that upon receiving an ASCONF chunk 980 containing the VTags parameter the NAT will realize that it has an 981 'Internal Port Number and Verification Tag collision'. In such a 982 case the NAT MUST send an ERROR chunk with the error cause code set 983 to 'VTag and Port Number Collision' (see Section 5.2.1). 985 If an SCTP endpoint receives an ERROR with 'Internal Port Number and 986 Verification Tag collision' as the error cause and the packet in the 987 Error Chunk contains an ASCONF with the VTags parameter, careful 988 examination of the association is required. The endpoint does the 989 following: 991 o It MUST validate that the verification tag is reflected by looking 992 at the VTag that would have been included in the outgoing packet. 993 If the validation fails, it MUST discard the packet. 995 o It MUST validate that the peer of the SCTP association supports 996 the dynamic address extension. If the peer does not support it, 997 the NAT Device MUST discard the incoming ERROR chunk. 999 o If the association is attempting to add an address (i.e. following 1000 the procedures in Section 6.6) then the endpoint MUST NOT consider 1001 the address part of the association and SHOULD make no further 1002 attempt to add the address (i.e. cancel any ASCONF timers and 1003 remove any record of the path), since the NAT devie has a VTag 1004 collision and the association cannot easily create a new VTag (as 1005 it would if the error occurred when sending an INIT). 1007 o If the endpoint has no other path, i.e. the procedure was executed 1008 due to missing a state in the NAT device, then the endpoint MUST 1009 abort the association. This would occur only if the local NAT 1010 device restarted and accepted a new association before attempting 1011 to repair the missing state (Note that this is no different than 1012 what happens to all TCP connections when a NAT device looses its 1013 state). 1015 6.5. Handling of Fragmented SCTP Packets by NAT Devices 1017 A NAT device MUST support IP reassembly of received fragmented SCTP 1018 packets. The fragments may arrive in any order. 1020 When an SCTP packet has to be fragmented by the NAT device and the IP 1021 header forbids fragmentation a corresponding ICMP packet SHOULD be 1022 sent. 1024 6.6. Multi Point Traversal Considerations for Endpoints 1026 If a multi-homed SCTP endpoint behind a NAT connects to a peer, it 1027 MUST first set up the association single-homed with only one address 1028 causing the first NAT to populate its state. Then it SHOULD add each 1029 IP address using ASCONF chunks sent via their respective NAT devices. 1030 The address to add is the wildcard address and the lookup address 1031 SHOULD also contain the VTags parameter and optionally the Disable 1032 Restart parameter. 1034 7. Various Examples of NAT Traversals 1036 Please note that this section is informational only. 1038 The addresses being used in the following examples are IPv4 addresses 1039 for private-use networks and for documentation as specified in 1040 [RFC6890]. However, the method described here is not limited to this 1041 NAT44 case. 1043 The NAT binding table entries shown in the following examples do not 1044 include the flag indicating whether the restart procedure is 1045 supported or not. This flag is not relevant for these examples. 1047 7.1. Single-homed Client to Single-homed Server 1049 The internal client starts the association with the external server 1050 via a four-way-handshake. Host A starts by sending an INIT chunk. 1052 /--\/--\ 1053 +--------+ +-----+ / \ +--------+ 1054 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1055 +--------+ +-----+ \ / +--------+ 1056 \--/\---/ 1057 +---------+--------+----------+--------+-----------+ 1058 NAT | Int | Int | Ext | Ext | Priv | 1059 | VTag | Port | VTag | Port | Addr | 1060 +---------+--------+----------+--------+-----------+ 1062 INIT[Initiate-Tag = 1234] 1063 10.0.0.1:1 ------> 203.0.113.1:2 1064 Ext-VTtag = 0 1066 A NAT binding tabled entry is created, the source address is 1067 substituted and the packet is sent on: 1069 NAT creates entry: 1070 +---------+--------+----------+--------+-----------+ 1071 NAT | Int | Int | Ext | Ext | Priv | 1072 | VTag | Port | VTag | Port | Addr | 1073 +---------+--------+----------+--------+-----------+ 1074 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1075 +---------+--------+----------+--------+-----------+ 1077 INIT[Initiate-Tag = 1234] 1078 192.0.2.1:1 ------------------------> 203.0.113.1:2 1079 Ext-VTtag = 0 1081 Host B receives the INIT and sends an INIT ACK with the NAT's 1082 external address as destination address. 1084 /--\/--\ 1085 +--------+ +-----+ / \ +--------+ 1086 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1087 +--------+ +-----+ \ / +--------+ 1088 \--/\---/ 1090 INIT ACK[Initiate-Tag = 5678] 1091 192.0.2.1:1 <----------------------- 203.0.113.1:2 1092 Int-VTag = 1234 1094 NAT updates entry: 1095 +---------+--------+----------+--------+-----------+ 1096 NAT | Int | Int | Ext | Ext | Priv | 1097 | VTag | Port | VTag | Port | Addr | 1098 +---------+--------+----------+--------+-----------+ 1099 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1100 +---------+--------+----------+--------+-----------+ 1102 INIT ACK[Initiate-Tag = 5678] 1103 10.0.0.1:1 <------ 203.0.113.1:2 1104 Int-VTag = 1234 1106 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1107 ACK. 1109 /--\/--\ 1110 +--------+ +-----+ / \ +--------+ 1111 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1112 +--------+ +-----+ \ / +--------+ 1113 \--/\---/ 1115 COOKIE ECHO 1116 10.0.0.1:1 ------> 203.0.113.1:2 1117 Ext-VTag = 5678 1119 COOKIE ECHO 1120 192.0.2.1:1 -----------------------> 203.0.113.1:2 1121 Ext-VTag = 5678 1123 COOKIE ACK 1124 192.0.2.1:1 <----------------------- 203.0.113.1:2 1125 Int-VTag = 1234 1127 COOKIE ACK 1128 10.0.0.1:1 <------ 203.0.113.1:2 1129 Int-VTag = 1234 1131 7.2. Single-homed Client to Multi-homed Server 1133 The internal client is single-homed whereas the external server is 1134 multi-homed. The client (Host A) sends an INIT like in the single- 1135 homed case. 1137 +--------+ 1138 /--\/--\ /-|Router 1| \ 1139 +------+ +-----+ / \ / +--------+ \ +------+ 1140 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1141 | A | +-----+ \ / \ +--------+ / | B | 1142 +------+ \--/\--/ \-|Router 2|-/ +------+ 1143 +--------+ 1145 +---------+--------+----------+--------+-----------+ 1146 NAT | Int | Int | Ext | Ext | Priv | 1147 | VTag | Port | VTag | Port | Addr | 1148 +---------+--------+----------+--------+-----------+ 1150 INIT[Initiate-Tag = 1234] 1151 10.0.0.1:1 ---> 203.0.113.1:2 1152 Ext-VTag = 0 1154 NAT creates entry: 1156 +---------+--------+----------+--------+-----------+ 1157 NAT | Int | Int | Ext | Ext | Priv | 1158 | VTag | Port | VTag | Port | Addr | 1159 +---------+--------+----------+--------+-----------+ 1160 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1161 +---------+--------+----------+--------+-----------+ 1163 INIT[Initiate-Tag = 1234] 1164 192.0.2.1:1 --------------------------> 203.0.113.1:2 1165 Ext-VTag = 0 1167 The server (Host B) includes its two addresses in the INIT ACK chunk. 1169 +--------+ 1170 /--\/--\ /-|Router 1| \ 1171 +------+ +-----+ / \ / +--------+ \ +------+ 1172 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1173 | A | +-----+ \ / \ +--------+ / | B | 1174 +------+ \--/\--/ \-|Router 2|-/ +------+ 1175 +--------+ 1177 INIT ACK[Initiate-tag = 5678, IP-Addr = 203.0.113.129] 1178 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1179 Int-VTag = 1234 1181 NAT does not need to change the NAT binding table for the second 1182 address: 1184 +---------+--------+----------+--------+-----------+ 1185 NAT | Int | Int | Ext | Ext | Priv | 1186 | VTag | Port | VTag | Port | Addr | 1187 +---------+--------+----------+--------+-----------+ 1188 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1189 +---------+--------+----------+--------+-----------+ 1191 INIT ACK[Initiate-Tag = 5678] 1192 10.0.0.1:1 <--- 203.0.113.1:2 1193 Int-VTag = 1234 1195 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1196 ACK. 1198 +--------+ 1199 /--\/--\ /-|Router 1| \ 1200 +------+ +-----+ / \ / +--------+ \ +------+ 1201 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1202 | A | +-----+ \ / \ +--------+ / | B | 1203 +------+ \--/\--/ \-|Router 2|-/ +------+ 1204 +--------+ 1206 COOKIE ECHO 1207 10.0.0.1:1 ---> 203.0.113.1:2 1208 ExtVTag = 5678 1210 COOKIE ECHO 1211 192.0.2.1:1 --------------------------> 203.0.113.1:2 1212 Ext-VTag = 5678 1214 COOKIE ACK 1215 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1216 Int-VTag = 1234 1218 COOKIE ACK 1219 10.0.0.1:1 <--- 203.0.113.1:2 1220 Int-VTag = 1234 1222 7.3. Multihomed Client and Server 1224 The client (Host A) sends an INIT to the server (Host B), but does 1225 not include the second address. 1227 +-------+ 1228 /--| NAT 1 |--\ /--\/--\ 1229 +------+ / +-------+ \ / \ +--------+ 1230 | Host |=== ====| Internet |====| Host B | 1231 | A | \ +-------+ / \ / +--------+ 1232 +------+ \--| NAT 2 |--/ \--/\--/ 1233 +-------+ 1235 +---------+--------+----------+--------+-----------+ 1236 NAT 1 | Int | Int | Ext | Ext | Priv | 1237 | VTag | Port | VTag | Port | Addr | 1238 +---------+--------+----------+--------+-----------+ 1240 INIT[Initiate-Tag = 1234] 1241 10.0.0.1:1 --------> 203.0.113.1:2 1242 Ext-VTag = 0 1244 NAT 1 creates entry: 1246 +---------+--------+----------+--------+-----------+ 1247 NAT 1 | Int | Int | Ext | Ext | Priv | 1248 | VTag | Port | VTag | Port | Addr | 1249 +---------+--------+----------+--------+-----------+ 1250 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1251 +---------+--------+----------+--------+-----------+ 1253 INIT[Initiate-Tag = 1234] 1254 192.0.2.1:1 ---------------------> 203.0.113.1:2 1255 ExtVTag = 0 1257 Host B includes its second address in the INIT ACK. 1259 +-------+ 1260 /--------| NAT 1 |--------\ /--\/--\ 1261 +------+ / +-------+ \ / \ +--------+ 1262 | Host |=== ====| Internet |===| Host B | 1263 | A | \ +-------+ / \ / +--------+ 1264 +------+ \--------| NAT 2 |--------/ \--/\--/ 1265 +-------+ 1267 INIT ACK[Initiate-Tag = 5678, IP-Addr = 203.0.113.129] 1268 192.0.2.1:1 <----------------------- 203.0.113.1:2 1269 Int-VTag = 1234 1271 NAT 1 does not need to update the NAT binding table for the second 1272 address: 1274 +---------+--------+----------+--------+-----------+ 1275 NAT 1 | Int | Int | Ext | Ext | Priv | 1276 | VTag | Port | VTag | Port | Addr | 1277 +---------+--------+----------+--------+-----------+ 1278 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1279 +---------+--------+----------+--------+-----------+ 1281 INIT ACK[Initiate-Tag = 5678] 1282 10.0.0.1:1 <-------- 203.0.113.1:2 1283 Int-VTag = 1234 1285 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1286 ACK. 1288 +-------+ 1289 /--------| NAT 1 |--------\ /--\/--\ 1290 +------+ / +-------+ \ / \ +--------+ 1291 | Host |=== ====| Internet |===| Host B | 1292 | A | \ +-------+ / \ / +--------+ 1293 +------+ \--------| NAT 2 |--------/ \--/\--/ 1294 +-------+ 1296 COOKIE ECHO 1297 10.0.0.1:1 --------> 203.0.113.1:2 1298 Ext-VTag = 5678 1300 COOKIE ECHO 1301 192.0.2.1:1 ------------------> 203.0.113.1:2 1302 Ext-VTag = 5678 1304 COOKIE ACK 1305 192.0.2.1:1 <------------------ 203.0.113.1:2 1306 Int-VTag = 1234 1308 COOKIE ACK 1309 10.0.0.1:1 <------- 203.0.113.1:2 1310 Int-VTag = 1234 1312 Host A announces its second address in an ASCONF chunk. The address 1313 parameter contains an undefined address (0) to indicate that the 1314 source address should be added. The lookup address parameter within 1315 the ASCONF chunk will also contain the pair of VTags (external and 1316 internal) so that the NAT may populate its NAT binding table entry 1317 completely with this single packet. 1319 +-------+ 1320 /--------| NAT 1 |--------\ /--\/--\ 1321 +------+ / +-------+ \ / \ +--------+ 1322 | Host |=== ====| Internet |===| Host B | 1323 | A | \ +-------+ / \ / +--------+ 1324 +------+ \--------| NAT 2 |--------/ \--/\--/ 1325 +-------+ 1327 ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Ext-VTag = 5678] 1328 10.1.0.1:1 --------> 203.0.113.129:2 1329 Ext-VTag = 5678 1331 NAT 2 creates a complete entry: 1333 +---------+--------+----------+--------+-----------+ 1334 NAT 2 | Int | Int | Ext | Ext | Priv | 1335 | VTag | Port | VTag | Port | Addr | 1336 +---------+--------+----------+--------+-----------+ 1337 | 1234 | 1 | 5678 | 2 | 10.1.0.1 | 1338 +---------+--------+----------+--------+-----------+ 1340 ASCONF [ADD-IP, Int-VTag=1234, Ext-VTag = 5678] 1341 192.0.2.129:1 ---------------------> 203.0.113.129:2 1342 Ext-VTag = 5678 1344 ASCONF ACK 1345 192.0.2.129:1 <--------------------- 203.0.113.129:2 1346 Int-VTag = 1234 1348 ASCONF ACK 1349 10.1.0.1:1 <----- 203.0.113.129:2 1350 Int-VTag = 1234 1352 7.4. NAT Loses Its State 1354 Association is already established between Host A and Host B, when 1355 the NAT loses its state and obtains a new public address. Host A 1356 sends a DATA chunk to Host B. 1358 /--\/--\ 1359 +--------+ +-----+ / \ +--------+ 1360 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1361 +--------+ +-----+ \ / +--------+ 1362 \--/\--/ 1364 +---------+--------+----------+--------+-----------+ 1365 NAT | Int | Int | Ext | Ext | Priv | 1366 | VTag | Port | VTag | Port | Addr | 1367 +---------+--------+----------+--------+-----------+ 1369 DATA 1370 10.0.0.1:1 ----------> 203.0.113.1:2 1371 Ext-VTag = 5678 1373 The NAT device cannot find an entry in the NAT binding table for the 1374 association. It sends ERROR an message with the M-Bit set and the 1375 cause "NAT state missing". 1377 /--\/--\ 1378 +--------+ +-----+ / \ +--------+ 1379 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1380 +--------+ +-----+ \ / +--------+ 1381 \--/\--/ 1383 ERROR [M-Bit, NAT state missing] 1384 10.0.0.1:1 <---------- 203.0.113.1:2 1385 Ext-VTag = 5678 1387 On reception of the ERROR message, Host A sends an ASCONF chunk 1388 indicating that the former information has to be deleted and the 1389 source address of the actual packet added. 1391 /--\/--\ 1392 +--------+ +-----+ / \ +--------+ 1393 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1394 +--------+ +-----+ \ / +--------+ 1395 \--/\--/ 1397 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Ext-VTag = 5678] 1398 10.0.0.1:1 ----------> 203.0.113.129:2 1399 Ext-VTag = 5678 1401 +---------+--------+----------+--------+-----------+ 1402 NAT | Int | Int | Ext | Ext | Priv | 1403 | VTag | Port | VTag | Port | Addr | 1404 +---------+--------+----------+--------+-----------+ 1405 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1406 +---------+--------+----------+--------+-----------+ 1408 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Ext-VTag = 5678] 1409 192.0.2.2:1 -------------------> 203.0.113.129:2 1410 Ext-VTag = 5678 1412 Host B adds the new source address to this association and deletes 1413 all other addresses from this association. 1415 /--\/--\ 1416 +--------+ +-----+ / \ +--------+ 1417 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1418 +--------+ +-----+ \ / +--------+ 1419 \--/\--/ 1421 ASCONF ACK 1422 192.0.2.2:1 <------------------- 203.0.113.129:2 1423 Int-VTag = 1234 1425 ASCONF ACK 1426 10.1.0.1:1 <---------- 203.0.113.129:2 1427 Int-VTag = 1234 1429 DATA 1430 10.0.0.1:1 ----------> 203.0.113.1:2 1431 Ext-VTag = 5678 1432 DATA 1433 192.0.2.2:1 -------------------> 203.0.113.129:2 1434 Ext-VTag = 5678 1436 7.5. Peer-to-Peer Communication 1438 If two hosts are behind NAT devices and want to communicate with each 1439 other, they have to get knowledge of the peer's public address. This 1440 can be achieved with a so-called rendezvous server. Afterwards the 1441 destination addresses are public, and the association is set up with 1442 the help of the INIT collision. The NAT devices create their entries 1443 according to their internal peer's point of view. Therefore, NAT A's 1444 Internal-VTag and Internal-Port are NAT B's External-VTag and 1445 External-Port, respectively. The naming (internal/external) of the 1446 verification tag in the packet flow is done from the sending host's 1447 point of view. 1449 Internal | External External | Internal 1450 | | 1451 | /--\/---\ | 1452 +--------+ +-------+ / \ +-------+ +--------+ 1453 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1454 +--------+ +-------+ \ / +-------+ +--------+ 1455 | \--/\---/ | 1457 NAT Binding Tables 1458 +---------+--------+----------+--------+-----------+ 1459 NAT A | Int | Int | Ext | Ext | Priv | 1460 | VTag | Port | VTag | Port | Addr | 1461 +---------+--------+----------+--------+-----------+ 1463 +---------+--------+----------+--------+-----------+ 1464 NAT B | Int | Int | Ext | Ext | Priv | 1465 | v-tag | port | v-tag | port | Addr | 1466 +---------+--------+----------+--------+-----------+ 1468 INIT[Initiate-Tag = 1234] 1469 10.0.0.1:1 --> 203.0.113.1:2 1470 Ext-VTag = 0 1472 NAT A creates entry: 1474 +---------+--------+----------+--------+-----------+ 1475 NAT A | Int | Int | Ext | Ext | Priv | 1476 | VTag | Port | VTag | Port | Addr | 1477 +---------+--------+----------+--------+-----------+ 1478 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1479 +---------+--------+----------+--------+-----------+ 1481 INIT[Initiate-Tag = 1234] 1482 192.0.2.1:1 ----------------> 203.0.113.1:2 1483 Ext-VTag = 0 1485 NAT B processes INIT, but cannot find an entry. The SCTP packet is 1486 silently discarded and leaves the NAT binding table of NAT B 1487 unchanged. 1489 +---------+--------+----------+--------+-----------+ 1490 NAT B | Int | Int | Ext | Ext | Priv | 1491 | VTag | Port | VTag | Port | Addr | 1492 +---------+--------+----------+--------+-----------+ 1494 Now Host B sends INIT, which is processed by NAT B. Its parameters 1495 are used to create an entry. 1497 Internal | External External | Internal 1498 | | 1499 | /--\/---\ | 1500 +--------+ +-------+ / \ +-------+ +--------+ 1501 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1502 +--------+ +-------+ \ / +-------+ +--------+ 1503 | \--/\---/ | 1505 INIT[Initiate-Tag = 5678] 1506 192.0.2.1:1 <-- 10.1.0.1:2 1507 Ext-VTag = 0 1509 +---------+--------+-----------+----------+--------+ 1510 NAT B | Int | Int | Priv | Ext | Ext | 1511 | VTag | Port | Addr | VTag | Port | 1512 +---------+--------+-----------+----------+--------+ 1513 | 5678 | 2 | 10.1.0.1 | 0 | 1 | 1514 +---------+--------+-----------+----------+--------+ 1516 INIT[Initiate-Tag = 5678] 1517 192.0.2.1:1 <--------------- 203.0.113.1:2 1518 Ext-VTag = 0 1520 NAT A processes INIT. As the outgoing INIT of Host A has already 1521 created an entry, the entry is found and updated: 1523 Internal | External External | Internal 1524 | | 1525 | /--\/---\ | 1526 +--------+ +-------+ / \ +-------+ +--------+ 1527 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1528 +--------+ +-------+ \ / +-------+ +--------+ 1529 | \--/\---/ | 1531 VTag != Int-VTag, but Ext-VTag == 0, find entry. 1532 +---------+--------+----------+--------+-----------+ 1533 NAT A | Int | Int | Ext | Ext | Priv | 1534 | VTag | Port | VTag | Port | Addr | 1535 +---------+--------+----------+--------+-----------+ 1536 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1537 +---------+--------+----------+--------+-----------+ 1539 INIT[Initiate-tag = 5678] 1540 10.0.0.1:1 <-- 203.0.113.1:2 1541 Ext-VTag = 0 1543 Host A sends INIT ACK, which can pass through NAT B: 1545 Internal | External External | Internal 1546 | | 1547 | /--\/---\ | 1548 +--------+ +-------+ / \ +-------+ +--------+ 1549 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1550 +--------+ +-------+ \ / +-------+ +--------+ 1551 | \--/\---/ | 1553 INIT ACK[Initiate-Tag = 1234] 1554 10.0.0.1:1 --> 203.0.113.1:2 1555 Ext-VTag = 5678 1557 INIT ACK[Initiate-Tag = 1234] 1558 192.0.2.1:1 ----------------> 203.0.113.1:2 1559 Ext-VTag = 5678 1561 NAT B updates entry: 1563 +---------+--------+----------+--------+-----------+ 1564 NAT B | Int | Int | Ext | Ext | Priv | 1565 | VTag | Port | VTag | Port | Addr | 1566 +---------+--------+----------+--------+-----------+ 1567 | 5678 | 2 | 1234 | 1 | 10.1.0.1 | 1568 +---------+--------+----------+--------+-----------+ 1570 INIT ACK[Initiate-Tag = 1234] 1571 192.0.2.1:1 --> 10.1.0.1:2 1572 Ext-VTag = 5678 1574 The lookup for COOKIE ECHO and COOKIE ACK is successful. 1576 Internal | External External | Internal 1577 | | 1578 | /--\/---\ | 1579 +--------+ +-------+ / \ +-------+ +--------+ 1580 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1581 +--------+ +-------+ \ / +-------+ +--------+ 1582 | \--/\---/ | 1584 COOKIE ECHO 1585 192.0.2.1:1 <-- 10.1.0.1:2 1586 Ext-VTag = 1234 1588 COOKIE ECHO 1589 192.0.2.1:1 <------------- 203.0.113.1:2 1590 Ext-VTag = 1234 1592 COOKIE ECHO 1593 10.0.0.1:1 <-- 203.0.113.1:2 1594 Ext-VTag = 1234 1596 COOKIE ACK 1597 10.0.0.1:1 --> 203.0.113.1:2 1598 Ext-VTag = 5678 1600 COOKIE ACK 1601 192.0.2.1:1 ----------------> 203.0.113.1:2 1602 Ext-VTag = 5678 1604 COOKIE ACK 1605 192.0.2.1:1 --> 10.1.0.1:2 1606 Ext-VTag = 5678 1608 8. Socket API Considerations 1610 This section describes how the socket API defined in [RFC6458] is 1611 extended to provide a way for the application to control NAT 1612 friendliness. 1614 Please note that this section is informational only. 1616 A socket API implementation based on [RFC6458] is extended by 1617 supporting one new read/write socket option. 1619 8.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) 1621 This socket option uses the option_level IPPROTO_SCTP and the 1622 option_name SCTP_NAT_FRIENDLY. It can be used to enable/disable the 1623 NAT friendliness for future associations and retrieve the value for 1624 future and specific ones. 1626 struct sctp_assoc_value { 1627 sctp_assoc_t assoc_id; 1628 uint32_t assoc_value; 1629 }; 1631 assoc_id: This parameter is ignored for one-to-one style sockets. 1632 For one-to-many style sockets the application may fill in an 1633 association identifier or SCTP_FUTURE_ASSOC for this query. It is 1634 an error to use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 1636 assoc_value: A non-zero value indicates a NAT-friendly mode. 1638 9. IANA Considerations 1640 [NOTE to RFC-Editor: 1642 "RFCXXXX" is to be replaced by the RFC number you assign this 1643 document. 1645 ] 1647 [NOTE to RFC-Editor: 1649 The requested values for the chunk type and the chunk parameter 1650 types are tentative and to be confirmed by IANA. 1652 ] 1654 This document (RFCXXXX) is the reference for all registrations 1655 described in this section. The requested changes are described 1656 below. 1658 9.1. New Chunk Flags for Two Existing Chunk Types 1660 As defined in [RFC6096] two chunk flags have to be assigned by IANA 1661 for the ERROR chunk. The requested value for the T bit is 0x01 and 1662 for the M bit is 0x02. 1664 This requires an update of the "ERROR Chunk Flags" registry for SCTP: 1666 ERROR Chunk Flags 1668 +------------------+-----------------+-----------+ 1669 | Chunk Flag Value | Chunk Flag Name | Reference | 1670 +------------------+-----------------+-----------+ 1671 | 0x01 | T bit | [RFCXXXX] | 1672 | 0x02 | M bit | [RFCXXXX] | 1673 | 0x04 | Unassigned | | 1674 | 0x08 | Unassigned | | 1675 | 0x10 | Unassigned | | 1676 | 0x20 | Unassigned | | 1677 | 0x40 | Unassigned | | 1678 | 0x80 | Unassigned | | 1679 +------------------+-----------------+-----------+ 1681 As defined in [RFC6096] one chunk flag has to be assigned by IANA for 1682 the ABORT chunk. The requested value of the M bit is 0x02. 1684 This requires an update of the "ABORT Chunk Flags" registry for SCTP: 1686 ABORT Chunk Flags 1688 +------------------+-----------------+-----------+ 1689 | Chunk Flag Value | Chunk Flag Name | Reference | 1690 +------------------+-----------------+-----------+ 1691 | 0x01 | T bit | [RFC4960] | 1692 | 0x02 | M bit | [RFCXXXX] | 1693 | 0x04 | Unassigned | | 1694 | 0x08 | Unassigned | | 1695 | 0x10 | Unassigned | | 1696 | 0x20 | Unassigned | | 1697 | 0x40 | Unassigned | | 1698 | 0x80 | Unassigned | | 1699 +------------------+-----------------+-----------+ 1701 9.2. Three New Error Causes 1703 Three error causes have to be assigned by IANA. It is requested to 1704 use the values given below. 1706 This requires three additional lines in the "Error Cause Codes" 1707 registry for SCTP: 1709 Error Cause Codes 1711 +-------+--------------------------------+-----------+ 1712 | Value | Cause Code | Reference | 1713 +-------+--------------------------------+-----------+ 1714 | 176 | VTag and Port Number Collision | [RFCXXXX] | 1715 | 177 | Missing State | [RFCXXXX] | 1716 | 178 | Port Number Collision | [RFCXXXX] | 1717 +-------+--------------------------------+-----------+ 1719 9.3. Two New Chunk Parameter Types 1721 Two chunk parameter types have to be assigned by IANA. It is 1722 requested to use the values given below. IANA should assign these 1723 values from the pool of parameters with the upper two bits set to 1724 '11'. 1726 This requires two additional lines in the "Chunk Parameter Types" 1727 registry for SCTP: 1729 Chunk Parameter Types 1731 +----------+--------------------------+-----------+ 1732 | ID Value | Chunk Parameter Type | Reference | 1733 +----------+--------------------------+-----------+ 1734 | 49159 | Disable Restart (0xC007) | [RFCXXXX] | 1735 | 49160 | VTags (0xC008) | [RFCXXXX] | 1736 +----------+--------------------------+-----------+ 1738 10. Security Considerations 1740 State maintenance within a NAT is always a subject of possible Denial 1741 Of Service attacks. This document recommends that at a minimum a NAT 1742 runs a timer on any SCTP state so that old association state can be 1743 cleaned up. 1745 For SCTP endpoints, this document does not add any additional 1746 security considerations to the ones given in [RFC4960], [RFC4895], 1747 and [RFC5061]. In particular, SCTP is protected by the verification 1748 tags and the usage of [RFC4895] against off-path attackers. 1750 11. Acknowledgments 1752 The authors wish to thank Gorry Fairhurst, Bryan Ford, David Hayes, 1753 Alfred Hines, Karen E. E. Nielsen, Henning Peters, Maksim Proshin, 1754 Timo Voelker, Dan Wing, and Qiaobing Xie for their invaluable 1755 comments. 1757 In addition, the authors wish to thank David Hayes, Jason But, and 1758 Grenville Armitage, the authors of [DOI_10.1145_1496091.1496095], for 1759 their suggestions. 1761 12. References 1763 12.1. Normative References 1765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1766 Requirement Levels", BCP 14, RFC 2119, 1767 DOI 10.17487/RFC2119, March 1997, 1768 . 1770 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1771 "Authenticated Chunks for the Stream Control Transmission 1772 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 1773 2007, . 1775 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1776 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1777 . 1779 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1780 Kozuka, "Stream Control Transmission Protocol (SCTP) 1781 Dynamic Address Reconfiguration", RFC 5061, 1782 DOI 10.17487/RFC5061, September 2007, 1783 . 1785 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 1786 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 1787 DOI 10.17487/RFC6096, January 2011, 1788 . 1790 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1791 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1792 May 2017, . 1794 12.2. Informative References 1796 [DOI_10.1145_1496091.1496095] 1797 Hayes, D., But, J., and G. Armitage, "Issues with network 1798 address translation for SCTP", ACM SIGCOMM Computer 1799 Communication Review Vol. 39, pp. 23, 1800 DOI 10.1145/1496091.1496095, December 2008. 1802 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1803 RFC 793, DOI 10.17487/RFC0793, September 1981, 1804 . 1806 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1807 Yasevich, "Sockets API Extensions for the Stream Control 1808 Transmission Protocol (SCTP)", RFC 6458, 1809 DOI 10.17487/RFC6458, December 2011, 1810 . 1812 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1813 "Special-Purpose IP Address Registries", BCP 153, 1814 RFC 6890, DOI 10.17487/RFC6890, April 2013, 1815 . 1817 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1818 Control Transmission Protocol (SCTP) Packets for End-Host 1819 to End-Host Communication", RFC 6951, 1820 DOI 10.17487/RFC6951, May 2013, 1821 . 1823 Authors' Addresses 1825 Randall R. Stewart 1826 Netflix, Inc. 1827 Chapin, SC 29036 1828 US 1830 Email: randall@lakerest.net 1832 Michael Tuexen 1833 Muenster University of Applied Sciences 1834 Stegerwaldstrasse 39 1835 48565 Steinfurt 1836 DE 1838 Email: tuexen@fh-muenster.de 1840 Irene Ruengeler 1841 Muenster University of Applied Sciences 1842 Stegerwaldstrasse 39 1843 48565 Steinfurt 1844 DE 1846 Email: i.ruengeler@fh-muenster.de