idnits 2.17.1 draft-ietf-tsvwg-natsupp-21.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(6): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. 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 (1 November 2020) is 1271 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 493, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1944, 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 (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. R. Stewart 3 Internet-Draft Netflix, Inc. 4 Intended status: Standards Track M. Tüxen 5 Expires: 5 May 2021 I. Rüngeler 6 Münster Univ. of Appl. Sciences 7 1 November 2020 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 Support 11 draft-ietf-tsvwg-natsupp-21 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 functions for TCP that allows multiple hosts to 20 reside behind a NAT function and yet share a single IPv4 address, 21 even when two hosts (behind a NAT function) choose the same port 22 numbers for their connection. This additional code is sometimes 23 classified as Network Address and Port Translation (NAPT). 25 This document describes the protocol extensions needed for the SCTP 26 endpoints and the mechanisms for NAT functions necessary to provide 27 similar features of NAPT in the single point and multipoint traversal 28 scenario. 30 Finally, a YANG module for SCTP NAT is defined. 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 https://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 5 May 2021. 49 Copyright Notice 51 Copyright (c) 2020 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 (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Motivation and Overview . . . . . . . . . . . . . . . . . . . 6 69 4.1. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . 6 70 4.1.1. Single Point Traversal . . . . . . . . . . . . . . . 7 71 4.1.2. Multipoint Traversal . . . . . . . . . . . . . . . . 7 72 4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 8 73 4.3. The SCTP-Specific Variant of NAT . . . . . . . . . . . . 8 74 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 13 75 5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 13 76 5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 13 77 5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 14 78 5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 14 79 5.2.1. VTag and Port Number Collision Error Cause . . . . . 14 80 5.2.2. Missing State Error Cause . . . . . . . . . . . . . . 15 81 5.2.3. Port Number Collision Error Cause . . . . . . . . . . 15 82 5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 16 83 5.3.1. Disable Restart Parameter . . . . . . . . . . . . . . 16 84 5.3.2. VTags Parameter . . . . . . . . . . . . . . . . . . . 17 85 6. Procedures for SCTP Endpoints and NAT Functions . . . . . . . 18 86 6.1. Association Setup Considerations for Endpoints . . . . . 19 87 6.2. Handling of Internal Port Number and Verification Tag 88 Collisions . . . . . . . . . . . . . . . . . . . . . . . 19 89 6.2.1. NAT Function Considerations . . . . . . . . . . . . . 19 90 6.2.2. Endpoint Considerations . . . . . . . . . . . . . . . 20 91 6.3. Handling of Internal Port Number Collisions . . . . . . . 20 92 6.3.1. NAT Function Considerations . . . . . . . . . . . . . 20 93 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 94 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21 95 6.4.1. NAT Function Considerations . . . . . . . . . . . . . 22 96 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 22 98 6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 24 99 6.6. Multi Point Traversal Considerations for Endpoints . . . 24 100 7. Various Examples of NAT Traversals . . . . . . . . . . . . . 24 101 7.1. Single-homed Client to Single-homed Server . . . . . . . 24 102 7.2. Single-homed Client to Multi-homed Server . . . . . . . . 27 103 7.3. Multihomed Client and Server . . . . . . . . . . . . . . 29 104 7.4. NAT Function Loses Its State . . . . . . . . . . . . . . 32 105 7.5. Peer-to-Peer Communications . . . . . . . . . . . . . . . 34 106 8. SCTP NAT YANG Module . . . . . . . . . . . . . . . . . . . . 39 107 8.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 39 108 8.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 40 109 9. Socket API Considerations . . . . . . . . . . . . . . . . . . 42 110 9.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) . . . 43 111 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 112 10.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 43 113 10.2. Three New Error Causes . . . . . . . . . . . . . . . . . 45 114 10.3. Two New Chunk Parameter Types . . . . . . . . . . . . . 46 115 10.4. One New URI . . . . . . . . . . . . . . . . . . . . . . 46 116 10.5. One New YANG Module . . . . . . . . . . . . . . . . . . 46 117 11. Security Considerations . . . . . . . . . . . . . . . . . . . 46 118 12. Normative References . . . . . . . . . . . . . . . . . . . . 47 119 13. Informative References . . . . . . . . . . . . . . . . . . . 49 120 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 51 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 123 1. Introduction 125 Stream Control Transmission Protocol (SCTP) [RFC4960] provides a 126 reliable communications channel between two end-hosts in many ways 127 similar to TCP [RFC0793]. With the widespread deployment of Network 128 Address Translators (NAT), specialized code has been added to NAT 129 functions for TCP that allows multiple hosts to reside behind a NAT 130 function using private-use addresses (see [RFC6890]) and yet share a 131 single IPv4 address, even when two hosts (behind a NAT function) 132 choose the same port numbers for their connection. This additional 133 code is sometimes classified as Network Address and Port Translation 134 (NAPT). Please note that this document focuses on the case where the 135 NAT function maps a single or multiple internal addresses to a single 136 external address and vice versa. 138 To date, specialized code for SCTP has not yet been added to most NAT 139 functions so that only a translation of IP addresses is supported. 140 The end result of this is that only one SCTP-capable host can 141 successfully operate behind such a NAT function and this host can 142 only be single-homed. The only alternative for supporting legacy NAT 143 functions is to use UDP encapsulation as specified in [RFC6951]. 145 The NAT function in the document refers to NAPT functions described 146 in Section 2.2 of [RFC3022], NAT64 [RFC6146], or DS-Lite AFTR 147 [RFC6333]. 149 This document specifies procedures allowing a NAT function to support 150 SCTP by providing similar features to those provided by a NAPT for 151 TCP (see [RFC5382] and [RFC7857]), UDP (see [RFC4787] and [RFC7857]), 152 and ICMP (see [RFC5508] and [RFC7857]). This document also specifies 153 a set of data formats for SCTP packets and a set of SCTP endpoint 154 procedures to support NAT traversal. An SCTP implementation 155 supporting these procedures can assure that in both single-homed and 156 multi-homed cases a NAT function will maintain the appropriate state 157 without the NAT function needing to change port numbers. 159 It is possible and desirable to make these changes for a number of 160 reasons: 162 * It is desirable for SCTP internal end-hosts on multiple platforms 163 to be able to share a NAT function's external IP address in the 164 same way that a TCP session can use a NAT function. 166 * If a NAT function does not need to change any data within an SCTP 167 packet, it will reduce the processing burden of NAT'ing SCTP by 168 not needing to execute the CRC32c checksum used by SCTP. 170 * Not having to touch the IP payload makes the processing of ICMP 171 messages by NAT functions easier. 173 An SCTP-aware NAT function will need to follow these procedures for 174 generating appropriate SCTP packet formats. 176 When considering SCTP-aware NAT it is possible to have multiple 177 levels of support. At each level, the Internal Host, Remote Host, 178 and NAT function does or does not support the procedures described in 179 this document. The following table illustrates the results of the 180 various combinations of support and if communications can occur 181 between two endpoints. 183 +===============+==============+=============+===============+ 184 | Internal Host | NAT Function | Remote Host | Communication | 185 +===============+==============+=============+===============+ 186 | Support | Support | Support | Yes | 187 +---------------+--------------+-------------+---------------+ 188 | Support | Support | No Support | Limited | 189 +---------------+--------------+-------------+---------------+ 190 | Support | No Support | Support | None | 191 +---------------+--------------+-------------+---------------+ 192 | Support | No Support | No Support | None | 193 +---------------+--------------+-------------+---------------+ 194 | No Support | Support | Support | Limited | 195 +---------------+--------------+-------------+---------------+ 196 | No Support | Support | No Support | Limited | 197 +---------------+--------------+-------------+---------------+ 198 | No Support | No Support | Support | None | 199 +---------------+--------------+-------------+---------------+ 200 | No Support | No Support | No Support | None | 201 +---------------+--------------+-------------+---------------+ 203 Table 1: Communication possibilities 205 From the table it can be seen that when a NAT function does not 206 support SCTP-aware NAT no communication can occur. This assumes that 207 the NAT function does not handle SCTP packets at all and all SCTP 208 packets sent from behind a NAT function are discarded by the NAT 209 function. In some cases, where the NAT function supports SCTP-aware 210 NAT but one of the two hosts does not support the feature, 211 communication possibly occurs but in a limited way. For example only 212 one host can have a connection when a collision case occurs. 214 2. Conventions 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in BCP 219 14 [RFC2119] [RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 3. Terminology 224 This document uses the following terms, which are depicted in 225 Figure 1. Familiarity with the terminology used in [RFC4960] and 226 [RFC5061] is assumed. 228 Internal-Address (Int-Addr) 229 An internal address that is known to the internal host. 231 Internal-Port (Int-Port) 232 The port number that is in use by the host holding the Internal- 233 Address. 235 Internal-VTag (Int-VTag) 236 The SCTP Verification Tag (VTag) (see Section 3.1 of [RFC4960]) 237 that the internal host has chosen for an association. The VTag is 238 a unique 32-bit tag that accompanies any incoming SCTP packet for 239 this association to the Internal-Address. 241 Remote-Address (Rem-Addr) 242 The address that an internal host is attempting to contact. 244 Remote-Port (Rem-Port) 245 The port number used by the host holding the Remote-Address. 247 Remote-VTag (Rem-VTag) 248 The Verification Tag (VTag) (see Section 3.1 of [RFC4960]) that 249 the host holding the Remote-Address has chosen for an association. 250 The VTag is a unique 32-bit tag that accompanies any outgoing SCTP 251 packet for this association to the Remote-Address. 253 External-Address (Ext-Addr) 254 An external address assigned to the NAT function, that it uses as 255 a source address when sending packets towards a Remote-Address. 257 Internal Network | External Network 258 | 259 Internal | External Remote 260 Address | Address /--\/--\ Address 261 +--------+ +-----+ / \ +--------+ 262 | Host A |=========| NAT |=======| Network |==========| Host B | 263 +--------+ +-----+ \ / +--------+ 264 Internal | \--/\--/ Remote 265 Internal Port | Port Remote 266 VTag | VTag 268 Figure 1: Basic Network Setup 270 4. Motivation and Overview 272 4.1. SCTP NAT Traversal Scenarios 274 This section defines the notion of single and multipoint NAT 275 traversal. 277 4.1.1. Single Point Traversal 279 In this case, all packets in the SCTP association go through a single 280 NAT function, as shown in Figure 2. 282 Internal Network | External Network 283 | 284 | /--\/--\ 285 +--------+ +-----+ / \ +--------+ 286 | Host A |=========| NAT |========= | Network | ========| Host B | 287 +--------+ +-----+ \ / +--------+ 288 | \--/\--/ 289 | 291 Figure 2: Single NAT Function Scenario 293 A variation of this case is shown in Figure 3, i.e., multiple NAT 294 functions in the forwarding path between two endpoints. 296 Internal | External : Internal | External 297 | : | 298 | : | /--\/--\ 299 +--------+ +-----+ : +-----+ / \ +--------+ 300 | Host A |==| NAT |=======:=======| NAT |==| Network |==| Host B | 301 +--------+ +-----+ : +-----+ \ / +--------+ 302 | : | \--/\--/ 303 | : | 305 Figure 3: Serial NAT Functions Scenario 307 Although one of the main benefits of SCTP multi-homing is redundant 308 paths, in the single point traversal scenario the NAT function 309 represents a single point of failure in the path of the SCTP multi- 310 homed association. However, the rest of the path can still benefit 311 from path diversity provided by SCTP multi-homing. 313 The two SCTP endpoints in this case can be either single-homed or 314 multi-homed. However, the important thing is that the NAT function 315 in this case sees all the packets of the SCTP association. 317 4.1.2. Multipoint Traversal 319 This case involves multiple NAT functions and each NAT function only 320 sees some of the packets in the SCTP association. An example is 321 shown in Figure 4. 323 Internal | External 324 +------+ /---\/---\ 325 /=======|NAT A |=========\ / \ 326 +--------+ / +------+ \/ \ +--------+ 327 | Host A |/ | | Network |===| Host B | 328 +--------+\ | \ / +--------+ 329 \ +------+ / \ / 330 \=======|NAT B |=========/ \---\/---/ 331 +------+ 332 | 334 Figure 4: Parallel NAT Functions Scenario 336 This case does not apply to a single-homed SCTP association (i.e., 337 both endpoints in the association use only one IP address). The 338 advantage here is that the existence of multiple NAT traversal points 339 can preserve the path diversity of a multi-homed association for the 340 entire path. This in turn can improve the robustness of the 341 communication. 343 4.2. Limitations of Classical NAPT for SCTP 345 Using classical NAPT possibly results in changing one of the SCTP 346 port numbers during the processing which requires the recomputation 347 of the transport layer checksum by the NAPT function. Whereas for 348 UDP and TCP this can be done very efficiently, for SCTP the checksum 349 (CRC32c) over the entire packet needs to be recomputed (see 350 Appendix B of [RFC4960] for details of the CRC32c computation). This 351 would considerably add to the NAT computational burden, however 352 hardware support can mitigate this in some implementations. 354 An SCTP endpoint can have multiple addresses but only has a single 355 port number to use. To make multipoint traversal work, all the NAT 356 functions involved need to recognize the packets they see as 357 belonging to the same SCTP association and perform port number 358 translation in a consistent way. One possible way of doing this is 359 to use a pre-defined table of port numbers and addresses configured 360 within each NAT function. Other mechanisms could make use of NAT to 361 NAT communication. Such mechanisms have not been deployed on a wide 362 scale base and thus are not a preferred solution. Therefore an SCTP 363 variant of NAT function has been developed (see Section 4.3). 365 4.3. The SCTP-Specific Variant of NAT 367 In this section it is allowed that there are multiple SCTP capable 368 hosts behind a NAT function that share one External-Address. 369 Furthermore, this section focuses on the single point traversal 370 scenario (see Section 4.1.1). 372 The modification of outgoing SCTP packets sent from an internal host 373 is simple: the source address of the packets has to be replaced with 374 the External-Address. It might also be necessary to establish some 375 state in the NAT function to later handle incoming packets. 377 Typically, the NAT function has to maintain a NAT binding table of 378 Internal-VTag, Internal-Port, Remote-VTag, Remote-Port, Internal- 379 Address, and whether the restart procedure is disabled or not. An 380 entry in that NAT binding table is called a NAT-State control block. 381 The function Create() obtains the just mentioned parameters and 382 returns a NAT-State control block. A NAT function MAY allow creating 383 NAT-State control blocks via a management interface. 385 For SCTP packets coming from the external realm of the NAT function 386 the destination address of the packets has to be replaced with the 387 Internal-Address of the host to which the packet has to be delivered, 388 if a NAT state entry is found. The lookup of the Internal-Address is 389 based on the Remote-VTag, Remote-Port, Internal-VTag and the 390 Internal-Port. 392 The entries in the NAT binding table need to fulfill some uniqueness 393 conditions. There can not be more than one entry NAT binding table 394 with the same pair of Internal-Port and Remote-Port. This rule can 395 be relaxed, if all NAT binding table entries with the same Internal- 396 Port and Remote-Port have the support for the restart procedure 397 disabled (see Section 5.3.1). In this case there can not be no more 398 than one entry with the same Internal-Port, Remote-Port and Remote- 399 VTag and no more than one NAT binding table entry with the same 400 Internal-Port, Remote-Port, and Int-VTag. 402 The processing of outgoing SCTP packets containing an INIT chunk is 403 described in the following figure. The scenario shown is valid for 404 all message flows in this section. 406 /--\/--\ 407 +--------+ +-----+ / \ +--------+ 408 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 409 +--------+ +-----+ \ / +--------+ 410 \--/\---/ 412 INIT[Initiate-Tag] 413 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 414 Rem-VTag=0 416 Create(Initiate-Tag, Int-Port, 0, Rem-Port, Int-Addr, 417 IsRestartDisabled) 418 Returns(NAT-State control block) 420 Translate To: 422 INIT[Initiate-Tag] 423 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 424 Rem-VTag=0 426 Normally a NAT binding table entry will be created. 428 However, it is possible that there is already a NAT binding table 429 entry with the same Remote-Port, Internal-Port, and Internal-VTag but 430 different Internal-Address and the restart procedure is disabled. In 431 this case the packet containing the INIT chunk MUST be dropped by the 432 NAT and a packet containing an ABORT chunk SHOULD be sent to the SCTP 433 host that originated the packet with the M bit set and 'VTag and Port 434 Number Collision' error cause (see Section 5.1.1 for the format). 435 The source address of the packet containing the ABORT chunk MUST be 436 the destination address of the packet containing the INIT chunk. 438 If an outgoing SCTP packet contains an INIT or ASCONF chunk and a 439 matching NAT binding table entry is found, the packet is processed as 440 a normal outgoing packet. 442 It is also possible that a NAT binding table entry with the same 443 Remote-Port and Internal-Port exists without an Internal-VTag 444 conflict but there exists a NAT binding table entry with the same 445 port numbers but a different Internal-Address and the restart 446 procedure is not disabled. In such a case the packet containing the 447 INIT chunk MUST be dropped by the NAT function and a packet 448 containing an ABORT chunk SHOULD be sent to the SCTP host that 449 originated the packet with the M bit set and 'Port Number Collision' 450 error cause (see Section 5.1.1 for the format). 452 The processing of outgoing SCTP packets containing no INIT chunks is 453 described in the following figure. 455 /--\/--\ 456 +--------+ +-----+ / \ +--------+ 457 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 458 +--------+ +-----+ \ / +--------+ 459 \--/\---/ 461 Int-Addr:Int-Port ------> Rem-Addr:Rem-Port 462 Rem-VTag 464 Translate To: 466 Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port 467 Rem-VTag 469 The processing of incoming SCTP packets containing an INIT ACK chunk 470 is described in the following figure. The Lookup() function getting 471 as input the Internal-VTag, Internal-Port, Remote-VTag, and Remote- 472 Port, returns the corresponding entry of the NAT binding table and 473 updates the Remote-VTag by substituting it with the value of the 474 Initiate-Tag of the INIT ACK chunk. The wildcard character signifies 475 that the parameter's value is not considered in the Lookup() function 476 or changed in the Update() function, respectively. 478 /--\/--\ 479 +--------+ +-----+ / \ +--------+ 480 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 481 +--------+ +-----+ \ / +--------+ 482 \--/\---/ 484 INIT ACK[Initiate-Tag] 485 Ext-Addr:Int-Port <---- Rem-Addr:Rem-Port 486 Int-VTag 488 Lookup(Int-VTag, Int-Port, *, Rem-Port) 489 Update(*, *, Initiate-Tag, *) 491 Returns(NAT-State control block containing Int-Addr) 493 INIT ACK[Initiate-Tag] 494 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 495 Int-VTag 497 In the case where the Lookup function fails because it does not find 498 an entry, the SCTP packet is dropped. If it succeeds, the Update 499 routine inserts the Remote-VTag (the Initiate-Tag of the INIT ACK 500 chunk) in the NAT-State control block. 502 The processing of incoming SCTP packets containing an ABORT or 503 SHUTDOWN COMPLETE chunk with the T bit set is illustrated in the 504 following figure. 506 /--\/--\ 507 +--------+ +-----+ / \ +--------+ 508 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 509 +--------+ +-----+ \ / +--------+ 510 \--/\---/ 512 Ext-Addr:Int-Port <------ Rem-Addr:Rem-Port 513 Rem-VTag 515 Lookup(*, Int-Port, Rem-VTag, Rem-Port) 517 Returns(NAT-State control block containing Int-Addr) 519 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 520 Rem-VTag 522 For an incoming packet containing an INIT chunk a table lookup is 523 made only based on the addresses and port numbers. If an entry with 524 a Remote-VTag of zero is found, it is considered a match and the 525 Remote-VTag is updated. If an entry with a non-matching Remote-VTag 526 is found or no entry is found, the incoming packet is silently 527 dropped. If an entry with a matching Remote-VTag is found, the 528 incoming packet is forwarded. This allows the handling of INIT 529 collision through NAT functions. 531 The processing of other incoming SCTP packets is described in the 532 following figure. 534 /--\/--\ 535 +--------+ +-----+ / \ +--------+ 536 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 537 +--------+ +-----+ \ / +--------+ 538 \--/\---/ 540 Ext-Addr:Int-Port <------ Rem-Addr:Rem-Port 541 Int-VTag 543 Lookup(Int-VTag, Int-Port, *, Rem-Port) 545 Returns(NAT-State control block containing Internal-Address) 547 Int-Addr:Int-Port <------ Rem-Addr:Rem-Port 548 Int-VTag 550 5. Data Formats 552 This section defines the formats used to support NAT traversal. 553 Section 5.1 and Section 5.2 describe chunks and error causes sent by 554 NAT functions and received by SCTP endpoints. Section 5.3 describes 555 parameters sent by SCTP endpoints and used by NAT functions and SCTP 556 endpoints. 558 5.1. Modified Chunks 560 This section presents existing chunks defined in [RFC4960] for which 561 additional flags are specified by this document. 563 5.1.1. Extended ABORT Chunk 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type = 6 | Reserved |M|T| Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 \ \ 571 / zero or more Error Causes / 572 \ \ 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 The ABORT chunk is extended to add the new 'M bit'. The M bit 576 indicates to the receiver of the ABORT chunk that the chunk was not 577 generated by the peer SCTP endpoint, but instead by a middle box 578 (e.g., NAT). 580 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 582 5.1.2. Extended ERROR Chunk 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type = 9 | Reserved |M|T| Length | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 \ \ 590 / zero or more Error Causes / 591 \ \ 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 The ERROR chunk defined in [RFC4960] is extended to add the new 'M 595 bit'. The M bit indicates to the receiver of the ERROR chunk that 596 the chunk was not generated by the peer SCTP endpoint, but instead by 597 a middle box. 599 [NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.] 601 5.2. New Error Causes 603 This section defines the new error causes added by this document. 605 5.2.1. VTag and Port Number Collision Error Cause 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Cause Code = 0x00B0 | Cause Length = Variable | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 \ Chunk / 613 / \ 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Cause Code: 2 bytes (unsigned integer) 617 This field holds the IANA defined cause code for the 'VTag and 618 Port Number Collision' Error Cause. IANA is requested to assign 619 the value 0x00B0 for this cause code. 621 Cause Length: 2 bytes (unsigned integer) 622 This field holds the length in bytes of the error cause. The 623 value MUST be the length of the Cause-Specific Information plus 4. 625 Chunk: variable length 626 The Cause-Specific Information is filled with the chunk that 627 caused this error. This can be an INIT, INIT ACK, or ASCONF 628 chunk. Note that if the entire chunk will not fit in the ERROR 629 chunk or ABORT chunk being sent then the bytes that do not fit are 630 truncated. 632 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 633 IANA.] 635 5.2.2. Missing State Error Cause 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Cause Code = 0x00B1 | Cause Length = Variable | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 \ Original Packet / 643 / \ 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Cause Code: 2 bytes (unsigned integer) 647 This field holds the IANA defined cause code for the 'Missing 648 State' Error Cause. IANA is requested to assign the value 0x00B1 649 for this cause code. 651 Cause Length: 2 bytes (unsigned integer) 652 This field holds the length in bytes of the error cause. The 653 value MUST be the length of the Cause-Specific Information plus 4. 655 Original Packet: variable length 656 The Cause-Specific Information is filled with the IPv4 or IPv6 657 packet that caused this error. The IPv4 or IPv6 header MUST be 658 included. Note that if the packet will not fit in the ERROR chunk 659 or ABORT chunk being sent then the bytes that do not fit are 660 truncated. 662 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 663 IANA.] 665 5.2.3. Port Number Collision Error Cause 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Cause Code = 0x00B2 | Cause Length = Variable | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 \ Chunk / 672 / \ 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 Cause Code: 2 bytes (unsigned integer) 676 This field holds the IANA defined cause code for the 'Port Number 677 Collision' Error Cause. IANA is requested to assign the value 678 0x00B2 for this cause code. 680 Cause Length: 2 bytes (unsigned integer) 681 This field holds the length in bytes of the error cause. The 682 value MUST be the length of the Cause-Specific Information plus 4. 684 Chunk: variable length 685 The Cause-Specific Information is filled with the chunk that 686 caused this error. This can be an INIT, INIT ACK, or ASCONF 687 chunk. Note that if the entire chunk will not fit in the ERROR 688 chunk or ABORT chunk being sent then the bytes that do not fit are 689 truncated. 691 [NOTE to RFC-Editor: Assignment of cause code to be confirmed by 692 IANA.] 694 5.3. New Parameters 696 This section defines new parameters and their valid appearance 697 defined by this document. 699 5.3.1. Disable Restart Parameter 701 This parameter is used to indicate that the restart procedure is 702 requested to be disabled. Both endpoints of an association MUST 703 include this parameter in the INIT chunk and INIT ACK chunk when 704 establishing an association and MUST include it in the ASCONF chunk 705 when adding an address to successfully disable the restart procedure. 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Type = 0xC007 | Length = 4 | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Parameter Type: 2 bytes (unsigned integer) 714 This field holds the IANA defined parameter type for the Disable 715 Restart Parameter. IANA is requested to assign the value 0xC007 716 for this parameter type. 718 Parameter Length: 2 bytes (unsigned integer) 719 This field holds the length in bytes of the parameter. The value 720 MUST be 4. 722 [NOTE to RFC-Editor: Assignment of parameter type to be confirmed by 723 IANA.] 725 This parameter MAY appear in INIT, INIT ACK and ASCONF chunks and 726 MUST NOT appear in any other chunk. 728 5.3.2. VTags Parameter 730 This parameter is used to help a NAT function to recover from state 731 loss. 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Parameter Type = 0xC008 | Parameter Length = 16 | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | ASCONF-Request Correlation ID | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Internal Verification Tag | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Remote Verification Tag | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Parameter Type: 2 bytes (unsigned integer) 746 This field holds the IANA defined parameter type for the VTags 747 Parameter. IANA is requested to assign the value 0xC008 for this 748 parameter type. 750 Parameter Length: 2 bytes (unsigned integer) 751 This field holds the length in bytes of the parameter. The value 752 MUST be 16. 754 ASCONF-Request Correlation ID: 4 bytes (unsigned integer) 755 This is an opaque integer assigned by the sender to identify each 756 request parameter. The receiver of the ASCONF Chunk will copy 757 this 32-bit value into the ASCONF Response Correlation ID field of 758 the ASCONF ACK response parameter. The sender of the packet 759 containing the ASCONF chunk can use this same value in the ASCONF 760 ACK chunk to find which request the response is for. Note that 761 the receiver MUST NOT change this 32-bit value. 763 Internal Verification Tag: 4 bytes (unsigned integer) 764 The Verification Tag that the internal host has chosen for the 765 association. The Verification Tag is a unique 32-bit tag that 766 accompanies any incoming SCTP packet for this association to the 767 Internal-Address. 769 Remote Verification Tag: 4 bytes (unsigned integer) 770 The Verification Tag that the host holding the Remote-Address has 771 chosen for the association. The VTag is a unique 32-bit tag that 772 accompanies any outgoing SCTP packet for this association to the 773 Remote-Address. 775 [NOTE to RFC-Editor: Assignment of parameter type to be confirmed by 776 IANA.] 778 This parameter MAY appear in ASCONF chunks and MUST NOT appear in any 779 other chunk. 781 6. Procedures for SCTP Endpoints and NAT Functions 783 If an SCTP endpoint is behind an SCTP-aware NAT, a number of problems 784 can arise as it tries to communicate with its peers: 786 * IP addresses can not be included in the SCTP packet. This is 787 discussed in Section 6.1. 789 * More than one host behind a NAT function could select the same 790 VTag and source port number when communicating with the same peer 791 server. This creates a situation where the NAT function will not 792 be able to tell the two associations apart. This situation is 793 discussed in Section 6.2. 795 * If an SCTP endpoint is a server communicating with multiple peers 796 and the peers are behind the same NAT function, then the these 797 peers cannot be distinguished by the server. This case is 798 discussed in Section 6.3. 800 * A restart of a NAT function during a conversation could cause a 801 loss of its state. This problem and its solution is discussed in 802 Section 6.4. 804 * NAT functions need to deal with SCTP packets being fragmented at 805 the IP layer. This is discussed in Section 6.5. 807 * An SCTP endpoint can be behind two NAT functions in parallel 808 providing redundancy. The method to set up this scenario is 809 discussed in Section 6.6. 811 The mechanisms to solve these problems require additional chunks and 812 parameters, defined in this document, and modified handling 813 procedures from those specified in [RFC4960] as described below. 815 6.1. Association Setup Considerations for Endpoints 817 The association setup procedure defined in [RFC4960] allows multi- 818 homed SCTP endpoints to exchange its IP-addresses by using IPv4 or 819 IPv6 address parameters in the INIT and INIT ACK chunks. However, 820 this does not work when NAT functions are present. 822 Every association setup from a host behind a NAT function MUST NOT 823 use multiple internal addresses. The INIT chunk MUST NOT contain an 824 IPv4 Address parameter, IPv6 Address parameter, or Supported Address 825 Types parameter. The INIT ACK chunk MUST NOT contain any IPv4 826 Address parameter or IPv6 Address parameter using non-global 827 addresses. The INIT chunk and the INIT ACK chunk MUST NOT contain 828 any Host Name parameters. 830 If the association is intended to be finally multi-homed, the 831 procedure in Section 6.6 MUST be used. 833 The INIT and INIT ACK chunk SHOULD contain the Disable Restart 834 parameter defined in Section 5.3.1. 836 6.2. Handling of Internal Port Number and Verification Tag Collisions 838 Consider the case where two hosts in the Internal-Address space want 839 to set up an SCTP association with the same service provided by some 840 remote hosts. This means that the Remote-Port is the same. If they 841 both choose the same Internal-Port and Internal-VTag, the NAT 842 function cannot distinguish between incoming packets anymore. 843 However, this is unlikely. The Internal-VTags are chosen at random 844 and if the Internal-Ports are also chosen from the ephemeral port 845 range at random (see [RFC6056]) this gives a 46-bit random number 846 that has to match. 848 The same can happen with the Remote-VTag when a packet containing an 849 INIT ACK chunk or an ASCONF chunk is processed by the NAT function. 851 6.2.1. NAT Function Considerations 853 If the NAT function detects a collision of internal port numbers and 854 verification tags, it SHOULD send a packet containing an ABORT chunk 855 with the M bit set if the collision is triggered by a packet 856 containing an INIT or INIT ACK chunk. If such a collision is 857 triggered by a packet containing an ASCONF chunk, it SHOULD send a 858 packet containing an ERROR chunk with the M bit. The M bit is a new 859 bit defined by this document to express to SCTP that the source of 860 this packet is a "middle" box, not the peer SCTP endpoint (see 861 Section 5.1.1). If a packet containing an INIT ACK chunk triggers 862 the collision, the corresponding packet containing the ABORT chunk 863 MUST contain the same source and destination address and port numbers 864 as the packet containing the INIT ACK chunk. If a packet containing 865 an INIT chunk or an ASCONF chunk, the source and destination address 866 and port numbers MUST be swapped. 868 The sender of the packet containing an ERROR or ABORT chunk MUST 869 include the error cause with cause code 'VTag and Port Number 870 Collision' (see Section 5.2.1). 872 6.2.2. Endpoint Considerations 874 The sender of the packet containing the INIT chunk or the receiver of 875 a packet containing the INIT ACK chunk, upon reception of a packet 876 containing an ABORT chunk with M bit set and the appropriate error 877 cause code for colliding NAT binding table state is included, SHOULD 878 reinitiate the association setup procedure after choosing a new 879 initiate tag, if the association is in COOKIE-WAIT state. In any 880 other state, the SCTP endpoint MUST NOT respond. 882 The sender of the packet containing the ASCONF chunk, upon reception 883 of a packet containing an ERROR chunk with M bit set, MUST stop 884 adding the path to the association. 886 6.3. Handling of Internal Port Number Collisions 888 When two SCTP hosts are behind an SCTP-aware NAT it is possible that 889 two SCTP hosts in the Internal-Address space will want to set up an 890 SCTP association with the same server running on the same remote 891 host. If the two hosts choose the same internal port, this is 892 considered an internal port number collision. 894 For the NAT function, appropriate tracking can be performed by 895 assuring that the VTags are unique between the two hosts. 897 6.3.1. NAT Function Considerations 899 The NAT function, when processing the packet containing the INIT ACK 900 chunk, SHOULD note in its NAT binding table if the association 901 supports the disable restart extension. This note is used when 902 establishing future associations (i.e. when processing a packet 903 containing an INIT chunk from an internal host) to decide if the 904 connection can be allowed. The NAT function does the following when 905 processing a packet containing an INIT chunk: 907 * If the packet containing the INIT chunk is originating from an 908 internal port to a remote port for which the NAT function has no 909 matching NAT binding table entry, it MUST allow the packet 910 containing the INIT chunk creating an NAT binding table entry. 912 * If the packet containing the INIT chunk matches an existing NAT 913 binding table entry, it MUST validate that the disable restart 914 feature is supported and, if it does, allow the packet containing 915 the INIT chunk to be forwarded. 917 * If the disable restart feature is not supported, the NAT function 918 SHOULD send a packet containing an ABORT chunk with the M bit set. 920 The 'Port Number Collision' error cause (see Section 5.2.3) MUST be 921 included in the ABORT chunk sent in response to the packet containing 922 an INIT chunk. 924 If the collision is triggered by a packet containing an ASCONF chunk, 925 a packet containing an ERROR chunk with the 'Port Number Collision' 926 error cause SHOULD be sent in response to the packet containing the 927 ASCONF chunk. 929 6.3.2. Endpoint Considerations 931 For the remote SCTP server this means that the Remote-Port and the 932 Remote-Address are the same. If they both have chosen the same 933 Internal-Port the server cannot distinguish between both associations 934 based on the address and port numbers. For the server it looks like 935 the association is being restarted. To overcome this limitation the 936 client sends a Disable Restart parameter in the INIT chunk. 938 When the server receives this parameter it does the following: 940 * It MUST include a Disable Restart parameter in the INIT ACK to 941 inform the client that it will support the feature. 943 * It MUST disable the restart procedures defined in [RFC4960] for 944 this association. 946 Servers that support this feature will need to be capable of 947 maintaining multiple connections to what appears to be the same peer 948 (behind the NAT function) differentiated only by the VTags. 950 6.4. Handling of Missing State 951 6.4.1. NAT Function Considerations 953 If the NAT function receives a packet from the internal network for 954 which the lookup procedure does not find an entry in the NAT binding 955 table, a packet containing an ERROR chunk SHOULD be sent back with 956 the M bit set. The source address of the packet containing the ERROR 957 chunk MUST be the destination address of the packet received from the 958 internal network. The verification tag is reflected and the T bit is 959 set. Such a packet containing an ERROR chunk SHOULD NOT be sent if 960 the received packet contains an ASCONF chunk with the VTags parameter 961 or an ABORT, SHUTDOWN COMPLETE or INIT ACK chunk. A packet 962 containing an ERROR chunk MUST NOT be sent if the received packet 963 contains an ERROR chunk with the M bit set. In any case, the packet 964 SHOULD NOT be forwarded to the remote address. 966 If the NAT function receives a packet from the internal network for 967 which it has no NAT binding table entry and the packet contains an 968 ASCONF chunk with the VTags parameter, the NAT function MUST update 969 its NAT binding table according to the verification tags in the VTags 970 parameter and, if present, the Disable Restart parameter. 972 When sending a packet containing an ERROR chunk, the error cause 973 'Missing State' (see Section 5.2.2) MUST be included and the M bit of 974 the ERROR chunk MUST be set (see Section 5.1.2). 976 6.4.2. Endpoint Considerations 978 Upon reception of this packet containing the ERROR chunk by an SCTP 979 endpoint the receiver takes the following actions: 981 * It SHOULD validate that the verification tag is reflected by 982 looking at the VTag that would have been included in an outgoing 983 packet. If the validation fails, discard the received packet 984 containing the ERROR chunk. 986 * It SHOULD validate that the peer of the SCTP association supports 987 the dynamic address extension. If the validation fails, discard 988 the received packet containing the ERROR chunk. 990 * It SHOULD generate a packet containing a new ASCONF chunk 991 containing the VTags parameter (see Section 5.3.2) and the Disable 992 Restart parameter (see Section 5.3.1) if the association is using 993 the disable restart feature. By processing this packet the NAT 994 function can recover the appropriate state. The procedures for 995 generating an ASCONF chunk can be found in [RFC5061]. 997 The peer SCTP endpoint receiving such a packet containing an ASCONF 998 chunk SHOULD add the address and respond with an acknowledgment if 999 the address is new to the association (following all procedures 1000 defined in [RFC5061]). If the address is already part of the 1001 association, the SCTP endpoint MUST NOT respond with an error, but 1002 instead SHOULD respond with a packet containing an ASCONF ACK chunk 1003 acknowledging the address and take no action (since the address is 1004 already in the association). 1006 Note that it is possible that upon receiving a packet containing an 1007 ASCONF chunk containing the VTags parameter the NAT function will 1008 realize that it has an 'Internal Port Number and Verification Tag 1009 collision'. In such a case the NAT function SHOULD send a packet 1010 containing an ERROR chunk with the error cause code set to 'VTag and 1011 Port Number Collision' (see Section 5.2.1). 1013 If an SCTP endpoint receives a packet containing an ERROR chunk with 1014 'Internal Port Number and Verification Tag collision' as the error 1015 cause and the packet in the Error Chunk contains an ASCONF with the 1016 VTags parameter, careful examination of the association is necessary. 1017 The endpoint does the following: 1019 * It MUST validate that the verification tag is reflected by looking 1020 at the VTag that would have been included in the outgoing packet. 1021 If the validation fails, it MUST discard the packet. 1023 * It MUST validate that the peer of the SCTP association supports 1024 the dynamic address extension. If the peer does not support this 1025 extension, it MUST discard the received packet containing the 1026 ERROR chunk. 1028 * If the association is attempting to add an address (i.e. following 1029 the procedures in Section 6.6) then the endpoint MUST NOT consider 1030 the address part of the association and SHOULD make no further 1031 attempt to add the address (i.e. cancel any ASCONF timers and 1032 remove any record of the path), since the NAT function has a VTag 1033 collision and the association cannot easily create a new VTag (as 1034 it would if the error occurred when sending a packet containing an 1035 INIT chunk). 1037 * If the endpoint has no other path, i.e. the procedure was executed 1038 due to missing a state in the NAT function, then the endpoint MUST 1039 abort the association. This would occur only if the local NAT 1040 function restarted and accepted a new association before 1041 attempting to repair the missing state (Note that this is no 1042 different than what happens to all TCP connections when a NAT 1043 function looses its state). 1045 6.5. Handling of Fragmented SCTP Packets by NAT Functions 1047 SCTP minimizes the use of IP-level fragmentation. However, it can 1048 happen that using IP-level fragmentation is needed to continue an 1049 SCTP association. For example, if the path MTU is reduced and there 1050 are still some DATA chunk in flight, which require packets larger 1051 than the new path MTU. If IP-level fragmentation can not be used, 1052 the SCTP association will be terminated in a non-graceful way. 1054 Therefore, a NAT function MUST be able to handle IP-level fragmented 1055 SCTP packets. The fragments MAY arrive in any order. 1057 When an SCTP packet can not be forwarded by the NAT function due to 1058 MTU issues and the IP header forbids fragmentation, the NAT MUST send 1059 back a "Fragmentation needed and DF set" ICMPv4 or PTB ICMPv6 message 1060 to the internal host. This allows for a faster recovery from this 1061 packet drop. 1063 6.6. Multi Point Traversal Considerations for Endpoints 1065 If a multi-homed SCTP endpoint behind a NAT function connects to a 1066 peer, it MUST first set up the association single-homed with only one 1067 address causing the first NAT function to populate its state. Then 1068 it SHOULD add each IP address using packets containing ASCONF chunks 1069 sent via their respective NAT functions. The address used in the Add 1070 IP address parameter is the wildcard address (0.0.0.0 or ::0) and the 1071 address parameter in the ASCONF chunk SHOULD also contain the VTags 1072 parameter and optionally the Disable Restart parameter. 1074 7. Various Examples of NAT Traversals 1076 Please note that this section is informational only. 1078 The addresses being used in the following examples are IPv4 addresses 1079 for private-use networks and for documentation as specified in 1080 [RFC6890]. However, the method described here is not limited to this 1081 NAT44 case. 1083 The NAT binding table entries shown in the following examples do not 1084 include the flag indicating whether the restart procedure is 1085 supported or not. This flag is not relevant for these examples. 1087 7.1. Single-homed Client to Single-homed Server 1089 The internal client starts the association with the remote server via 1090 a four-way-handshake. Host A starts by sending a packet containing 1091 an INIT chunk. 1093 /--\/--\ 1094 +--------+ +-----+ / \ +--------+ 1095 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 1096 +--------+ +-----+ \ / +--------+ 1097 \--/\---/ 1098 +---------+--------+----------+--------+-----------+ 1099 NAT | Int | Int | Rem | Rem | Int | 1100 | VTag | Port | VTag | Port | Addr | 1101 +---------+--------+----------+--------+-----------+ 1103 INIT[Initiate-Tag = 1234] 1104 10.0.0.1:1 ------> 203.0.113.1:2 1105 Rem-VTtag = 0 1107 A NAT binding tabled entry is created, the source address is 1108 substituted and the packet is sent on: 1110 NAT function creates entry: 1111 +---------+--------+----------+--------+-----------+ 1112 NAT | Int | Int | Rem | Rem | Int | 1113 | VTag | Port | VTag | Port | Addr | 1114 +---------+--------+----------+--------+-----------+ 1115 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1116 +---------+--------+----------+--------+-----------+ 1118 INIT[Initiate-Tag = 1234] 1119 192.0.2.1:1 ------------------------> 203.0.113.1:2 1120 Rem-VTtag = 0 1122 Host B receives the packet containing an INIT chunk and sends a 1123 packet containing an INIT ACK chunk with the NAT's Remote-address as 1124 destination address. 1126 /--\/--\ 1127 +--------+ +-----+ / \ +--------+ 1128 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 1129 +--------+ +-----+ \ / +--------+ 1130 \--/\---/ 1132 INIT ACK[Initiate-Tag = 5678] 1133 192.0.2.1:1 <----------------------- 203.0.113.1:2 1134 Int-VTag = 1234 1136 NAT function updates entry: 1137 +---------+--------+----------+--------+-----------+ 1138 NAT | Int | Int | Rem | Rem | Int | 1139 | VTag | Port | VTag | Port | Addr | 1140 +---------+--------+----------+--------+-----------+ 1141 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1142 +---------+--------+----------+--------+-----------+ 1144 INIT ACK[Initiate-Tag = 5678] 1145 10.0.0.1:1 <------ 203.0.113.1:2 1146 Int-VTag = 1234 1148 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1149 ACK. 1151 /--\/--\ 1152 +--------+ +-----+ / \ +--------+ 1153 | Host A | <------> | NAT | <------> | Network | <------> | Host B | 1154 +--------+ +-----+ \ / +--------+ 1155 \--/\---/ 1157 COOKIE ECHO 1158 10.0.0.1:1 ------> 203.0.113.1:2 1159 Rem-VTag = 5678 1161 COOKIE ECHO 1162 192.0.2.1:1 -----------------------> 203.0.113.1:2 1163 Rem-VTag = 5678 1165 COOKIE ACK 1166 192.0.2.1:1 <----------------------- 203.0.113.1:2 1167 Int-VTag = 1234 1169 COOKIE ACK 1170 10.0.0.1:1 <------ 203.0.113.1:2 1171 Int-VTag = 1234 1173 7.2. Single-homed Client to Multi-homed Server 1175 The internal client is single-homed whereas the remote server is 1176 multi-homed. The client (Host A) sends a packet containing an INIT 1177 chunk like in the single-homed case. 1179 +--------+ 1180 /--\/--\ /-|Router 1| \ 1181 +------+ +-----+ / \ / +--------+ \ +------+ 1182 | Host | <-----> | NAT | <-> | Network | == =| Host | 1183 | A | +-----+ \ / \ +--------+ / | B | 1184 +------+ \--/\--/ \-|Router 2|-/ +------+ 1185 +--------+ 1187 +---------+--------+----------+--------+-----------+ 1188 NAT | Int | Int | Rem | Rem | Int | 1189 | VTag | Port | VTag | Port | Addr | 1190 +---------+--------+----------+--------+-----------+ 1192 INIT[Initiate-Tag = 1234] 1193 10.0.0.1:1 ---> 203.0.113.1:2 1194 Rem-VTag = 0 1196 NAT function creates entry: 1198 +---------+--------+----------+--------+-----------+ 1199 NAT | Int | Int | Rem | Rem | Int | 1200 | VTag | Port | VTag | Port | Addr | 1201 +---------+--------+----------+--------+-----------+ 1202 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1203 +---------+--------+----------+--------+-----------+ 1205 INIT[Initiate-Tag = 1234] 1206 192.0.2.1:1 --------------------------> 203.0.113.1:2 1207 Rem-VTag = 0 1209 The server (Host B) includes its two addresses in the INIT ACK chunk. 1211 +--------+ 1212 /--\/--\ /-|Router 1| \ 1213 +------+ +-----+ / \ / +--------+ \ +------+ 1214 | Host | <-----> | NAT | <-> | Network | == =| Host | 1215 | A | +-----+ \ / \ +--------+ / | B | 1216 +------+ \--/\--/ \-|Router 2|-/ +------+ 1217 +--------+ 1219 INIT ACK[Initiate-tag = 5678, IP-Addr = 203.0.113.129] 1220 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1221 Int-VTag = 1234 1223 The NAT function does not need to change the NAT binding table for 1224 the second address: 1226 +---------+--------+----------+--------+-----------+ 1227 NAT | Int | Int | Rem | Rem | Int | 1228 | VTag | Port | VTag | Port | Addr | 1229 +---------+--------+----------+--------+-----------+ 1230 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1231 +---------+--------+----------+--------+-----------+ 1233 INIT ACK[Initiate-Tag = 5678] 1234 10.0.0.1:1 <--- 203.0.113.1:2 1235 Int-VTag = 1234 1237 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1238 ACK. 1240 +--------+ 1241 /--\/--\ /-|Router 1| \ 1242 +------+ +-----+ / \ / +--------+ \ +------+ 1243 | Host | <-----> | NAT | <-> | Network | == =| Host | 1244 | A | +-----+ \ / \ +--------+ / | B | 1245 +------+ \--/\--/ \-|Router 2|-/ +------+ 1246 +--------+ 1248 COOKIE ECHO 1249 10.0.0.1:1 ---> 203.0.113.1:2 1250 Rem-VTag = 5678 1252 COOKIE ECHO 1253 192.0.2.1:1 --------------------------> 203.0.113.1:2 1254 Rem-VTag = 5678 1256 COOKIE ACK 1257 192.0.2.1:1 <-------------------------- 203.0.113.1:2 1258 Int-VTag = 1234 1260 COOKIE ACK 1261 10.0.0.1:1 <--- 203.0.113.1:2 1262 Int-VTag = 1234 1264 7.3. Multihomed Client and Server 1266 The client (Host A) sends a packet containing an INIT chunk to the 1267 server (Host B), but does not include the second address. 1269 +-------+ 1270 /--| NAT 1 |--\ /--\/--\ 1271 +------+ / +-------+ \ / \ +--------+ 1272 | Host |=== ====| Network |====| Host B | 1273 | A | \ +-------+ / \ / +--------+ 1274 +------+ \--| NAT 2 |--/ \--/\--/ 1275 +-------+ 1277 +---------+--------+----------+--------+-----------+ 1278 NAT 1 | Int | Int | Rem | Rem | Int | 1279 | VTag | Port | VTag | Port | Addr | 1280 +---------+--------+----------+--------+-----------+ 1282 INIT[Initiate-Tag = 1234] 1283 10.0.0.1:1 --------> 203.0.113.1:2 1284 Rem-VTag = 0 1286 NAT function 1 creates entry: 1288 +---------+--------+----------+--------+-----------+ 1289 NAT 1 | Int | Int | Rem | Rem | Int | 1290 | VTag | Port | VTag | Port | Addr | 1291 +---------+--------+----------+--------+-----------+ 1292 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1293 +---------+--------+----------+--------+-----------+ 1295 INIT[Initiate-Tag = 1234] 1296 192.0.2.1:1 ---------------------> 203.0.113.1:2 1297 Rem-VTag = 0 1299 Host B includes its second address in the INIT ACK. 1301 +-------+ 1302 /--------| NAT 1 |--------\ /--\/--\ 1303 +------+ / +-------+ \ / \ +--------+ 1304 | Host |=== ====| Network |===| Host B | 1305 | A | \ +-------+ / \ / +--------+ 1306 +------+ \--------| NAT 2 |--------/ \--/\--/ 1307 +-------+ 1309 INIT ACK[Initiate-Tag = 5678, IP-Addr = 203.0.113.129] 1310 192.0.2.1:1 <----------------------- 203.0.113.1:2 1311 Int-VTag = 1234 1313 NAT function 1 does not need to update the NAT binding table for the 1314 second address: 1316 +---------+--------+----------+--------+-----------+ 1317 NAT 1 | Int | Int | Rem | Rem | Int | 1318 | VTag | Port | VTag | Port | Addr | 1319 +---------+--------+----------+--------+-----------+ 1320 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1321 +---------+--------+----------+--------+-----------+ 1323 INIT ACK[Initiate-Tag = 5678] 1324 10.0.0.1:1 <-------- 203.0.113.1:2 1325 Int-VTag = 1234 1327 The handshake finishes with a COOKIE ECHO acknowledged by a COOKIE 1328 ACK. 1330 +-------+ 1331 /--------| NAT 1 |--------\ /--\/--\ 1332 +------+ / +-------+ \ / \ +--------+ 1333 | Host |=== ====| Network |===| Host B | 1334 | A | \ +-------+ / \ / +--------+ 1335 +------+ \--------| NAT 2 |--------/ \--/\--/ 1336 +-------+ 1338 COOKIE ECHO 1339 10.0.0.1:1 --------> 203.0.113.1:2 1340 Rem-VTag = 5678 1342 COOKIE ECHO 1343 192.0.2.1:1 ------------------> 203.0.113.1:2 1344 Rem-VTag = 5678 1346 COOKIE ACK 1347 192.0.2.1:1 <------------------ 203.0.113.1:2 1348 Int-VTag = 1234 1350 COOKIE ACK 1351 10.0.0.1:1 <------- 203.0.113.1:2 1352 Int-VTag = 1234 1354 Host A announces its second address in an ASCONF chunk. The address 1355 parameter contains a wildcard address (0.0.0.0 or ::0) to indicate 1356 that the source address has to be be added. The address parameter 1357 within the ASCONF chunk will also contain the pair of VTags (remote 1358 and internal) so that the NAT function can populate its NAT binding 1359 table entry completely with this single packet. 1361 +-------+ 1362 /--------| NAT 1 |--------\ /--\/--\ 1363 +------+ / +-------+ \ / \ +--------+ 1364 | Host |=== ====| Network |===| Host B | 1365 | A | \ +-------+ / \ / +--------+ 1366 +------+ \--------| NAT 2 |--------/ \--/\--/ 1367 +-------+ 1369 ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Rem-VTag = 5678] 1370 10.1.0.1:1 --------> 203.0.113.129:2 1371 Rem-VTag = 5678 1373 NAT function 2 creates a complete entry: 1375 +---------+--------+----------+--------+-----------+ 1376 NAT 2 | Int | Int | Rem | Rem | Int | 1377 | VTag | Port | VTag | Port | Addr | 1378 +---------+--------+----------+--------+-----------+ 1379 | 1234 | 1 | 5678 | 2 | 10.1.0.1 | 1380 +---------+--------+----------+--------+-----------+ 1382 ASCONF [ADD-IP, Int-VTag=1234, Rem-VTag = 5678] 1383 192.0.2.129:1 -------------------> 203.0.113.129:2 1384 Rem-VTag = 5678 1386 ASCONF ACK 1387 192.0.2.129:1 <------------------- 203.0.113.129:2 1388 Int-VTag = 1234 1390 ASCONF ACK 1391 10.1.0.1:1 <----- 203.0.113.129:2 1392 Int-VTag = 1234 1394 7.4. NAT Function Loses Its State 1396 Association is already established between Host A and Host B, when 1397 the NAT function loses its state and obtains a new external address. 1398 Host A sends a DATA chunk to Host B. 1400 /--\/--\ 1401 +--------+ +-----+ / \ +--------+ 1402 | Host A | <----------> | NAT | <----> | Network | <----> | Host B | 1403 +--------+ +-----+ \ / +--------+ 1404 \--/\--/ 1406 +---------+--------+----------+--------+-----------+ 1407 NAT | Int | Int | Rem | Rem | Int | 1408 | VTag | Port | VTag | Port | Addr | 1409 +---------+--------+----------+--------+-----------+ 1411 DATA 1412 10.0.0.1:1 ----------> 203.0.113.1:2 1413 Rem-VTag = 5678 1415 The NAT function cannot find an entry in the NAT binding table for 1416 the association. It sends a packet containing an ERROR chunk with 1417 the M bit set and the cause "NAT state missing". 1419 /--\/--\ 1420 +--------+ +-----+ / \ +--------+ 1421 | Host A | <----------> | NAT | <----> | Network | <----> | Host B | 1422 +--------+ +-----+ \ / +--------+ 1423 \--/\--/ 1425 ERROR [M bit, NAT state missing] 1426 10.0.0.1:1 <---------- 203.0.113.1:2 1427 Rem-VTag = 5678 1429 On reception of the packet containing the ERROR chunk, Host A sends a 1430 packet containing an ASCONF chunk indicating that the former 1431 information has to be deleted and the source address of the actual 1432 packet added. 1434 /--\/--\ 1435 +--------+ +-----+ / \ +--------+ 1436 | Host A | <----------> | NAT | <----> | Network | <----> | Host B | 1437 +--------+ +-----+ \ / +--------+ 1438 \--/\--/ 1440 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Rem-VTag = 5678] 1441 10.0.0.1:1 ----------> 203.0.113.129:2 1442 Rem-VTag = 5678 1444 +---------+--------+----------+--------+-----------+ 1445 NAT | Int | Int | Rem | Rem | Int | 1446 | VTag | Port | VTag | Port | Addr | 1447 +---------+--------+----------+--------+-----------+ 1448 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1449 +---------+--------+----------+--------+-----------+ 1451 ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Rem-VTag = 5678] 1452 192.0.2.2:1 -----------------> 203.0.113.129:2 1453 Rem-VTag = 5678 1455 Host B adds the new source address to this association and deletes 1456 all other addresses from this association. 1458 /--\/--\ 1459 +--------+ +-----+ / \ +--------+ 1460 | Host A | <----------> | NAT | <----> | Network | <----> | Host B | 1461 +--------+ +-----+ \ / +--------+ 1462 \--/\--/ 1464 ASCONF ACK 1465 192.0.2.2:1 <----------------- 203.0.113.129:2 1466 Int-VTag = 1234 1468 ASCONF ACK 1469 10.1.0.1:1 <---------- 203.0.113.129:2 1470 Int-VTag = 1234 1472 DATA 1473 10.0.0.1:1 ----------> 203.0.113.1:2 1474 Rem-VTag = 5678 1475 DATA 1476 192.0.2.2:1 -----------------> 203.0.113.129:2 1477 Rem-VTag = 5678 1479 7.5. Peer-to-Peer Communications 1481 If two hosts, each of them behind a NAT function, want to communicate 1482 with each other, they have to get knowledge of the peer's external 1483 address. This can be achieved with a so-called rendezvous server. 1484 Afterwards the destination addresses are external, and the 1485 association is set up with the help of the INIT collision. The NAT 1486 functions create their entries according to their internal peer's 1487 point of view. Therefore, NAT function A's Internal-VTag and 1488 Internal-Port are NAT function B's Remote-VTag and Remote-Port, 1489 respectively. The naming (internal/remote) of the verification tag 1490 in the packet flow is done from the sending host's point of view. 1492 Internal | External External | Internal 1493 | | 1494 | /--\/---\ | 1495 +--------+ +-------+ / \ +-------+ +--------+ 1496 | Host A |<--->| NAT A |<-->| Network |<-->| NAT B |<--->| Host B | 1497 +--------+ +-------+ \ / +-------+ +--------+ 1498 | \--/\---/ | 1500 NAT Binding Tables 1501 +---------+--------+----------+--------+-----------+ 1502 NAT A | Int | Int | Rem | Rem | Int | 1503 | VTag | Port | VTag | Port | Addr | 1504 +---------+--------+----------+--------+-----------+ 1506 +---------+--------+----------+--------+-----------+ 1507 NAT B | Int | Int | Rem | Rem | Int | 1508 | v-tag | port | v-tag | port | Addr | 1509 +---------+--------+----------+--------+-----------+ 1511 INIT[Initiate-Tag = 1234] 1512 10.0.0.1:1 --> 203.0.113.1:2 1513 Rem-VTag = 0 1515 NAT function A creates entry: 1517 +---------+--------+----------+--------+-----------+ 1518 NAT A | Int | Int | Rem | Rem | Int | 1519 | VTag | Port | VTag | Port | Addr | 1520 +---------+--------+----------+--------+-----------+ 1521 | 1234 | 1 | 0 | 2 | 10.0.0.1 | 1522 +---------+--------+----------+--------+-----------+ 1524 INIT[Initiate-Tag = 1234] 1525 192.0.2.1:1 ----------------> 203.0.113.1:2 1526 Rem-VTag = 0 1528 NAT function B processes the packet containing the INIT chunk, but 1529 cannot find an entry. The SCTP packet is silently discarded and 1530 leaves the NAT binding table of NAT function B unchanged. 1532 +---------+--------+----------+--------+-----------+ 1533 NAT B | Int | Int | Rem | Rem | Int | 1534 | VTag | Port | VTag | Port | Addr | 1535 +---------+--------+----------+--------+-----------+ 1537 Now Host B sends a packet containing an INIT chunk, which is 1538 processed by NAT function B. Its parameters are used to create an 1539 entry. 1541 Internal | External External | Internal 1542 | | 1543 | /--\/---\ | 1544 +--------+ +-------+ / \ +-------+ +--------+ 1545 | Host A |<--->| NAT A |<-->| Network |<-->| NAT B |<--->| Host B | 1546 +--------+ +-------+ \ / +-------+ +--------+ 1547 | \--/\---/ | 1549 INIT[Initiate-Tag = 5678] 1550 192.0.2.1:1 <-- 10.1.0.1:2 1551 Rem-VTag = 0 1553 +---------+--------+----------+--------+-----------+ 1554 NAT B | Int | Int | Rem | Rem | Int | 1555 | VTag | Port | VTag | Port | Addr | 1556 +---------+--------+----------+--------+-----------+ 1557 | 5678 | 2 | 0 | 1 | 10.1.0.1 | 1558 +---------+--------+----------+--------+-----------+ 1560 INIT[Initiate-Tag = 5678] 1561 192.0.2.1:1 <--------------- 203.0.113.1:2 1562 Rem-VTag = 0 1564 NAT function A processes the packet containing the INIT chunk. As 1565 the outgoing packet containing an INIT chunk of Host A has already 1566 created an entry, the entry is found and updated: 1568 Internal | External External | Internal 1569 | | 1570 | /--\/---\ | 1571 +--------+ +-------+ / \ +-------+ +--------+ 1572 | Host A |<--->| NAT A |<-->| Network |<-->| NAT B |<--->| Host B | 1573 +--------+ +-------+ \ / +-------+ +--------+ 1574 | \--/\---/ | 1576 VTag != Int-VTag, but Rem-VTag == 0, find entry. 1577 +---------+--------+----------+--------+-----------+ 1578 NAT A | Int | Int | Rem | Rem | Int | 1579 | VTag | Port | VTag | Port | Addr | 1580 +---------+--------+----------+--------+-----------+ 1581 | 1234 | 1 | 5678 | 2 | 10.0.0.1 | 1582 +---------+--------+----------+--------+-----------+ 1584 INIT[Initiate-tag = 5678] 1585 10.0.0.1:1 <-- 203.0.113.1:2 1586 Rem-VTag = 0 1588 Host A sends a packet containing an INIT ACK chunk, which can pass 1589 through NAT function B: 1591 Internal | External External | Internal 1592 | | 1593 | /--\/---\ | 1594 +--------+ +-------+ / \ +-------+ +--------+ 1595 | Host A |<--->| NAT A |<-->| Network |<-->| NAT B |<--->| Host B | 1596 +--------+ +-------+ \ / +-------+ +--------+ 1597 | \--/\---/ | 1599 INIT ACK[Initiate-Tag = 1234] 1600 10.0.0.1:1 --> 203.0.113.1:2 1601 Rem-VTag = 5678 1603 INIT ACK[Initiate-Tag = 1234] 1604 192.0.2.1:1 ----------------> 203.0.113.1:2 1605 Rem-VTag = 5678 1607 NAT function B updates entry: 1609 +---------+--------+----------+--------+-----------+ 1610 NAT B | Int | Int | Rem | Rem | Int | 1611 | VTag | Port | VTag | Port | Addr | 1612 +---------+--------+----------+--------+-----------+ 1613 | 5678 | 2 | 1234 | 1 | 10.1.0.1 | 1614 +---------+--------+----------+--------+-----------+ 1616 INIT ACK[Initiate-Tag = 1234] 1617 192.0.2.1:1 --> 10.1.0.1:2 1618 Rem-VTag = 5678 1620 The lookup for COOKIE ECHO and COOKIE ACK is successful. 1622 Internal | External External | Internal 1623 | | 1624 | /--\/---\ | 1625 +--------+ +-------+ / \ +-------+ +--------+ 1626 | Host A |<--->| NAT A |<-->| Network |<-->| NAT B |<--->| Host B | 1627 +--------+ +-------+ \ / +-------+ +--------+ 1628 | \--/\---/ | 1630 COOKIE ECHO 1631 192.0.2.1:1 <-- 10.1.0.1:2 1632 Rem-VTag = 1234 1634 COOKIE ECHO 1635 192.0.2.1:1 <------------- 203.0.113.1:2 1636 Rem-VTag = 1234 1638 COOKIE ECHO 1639 10.0.0.1:1 <-- 203.0.113.1:2 1640 Rem-VTag = 1234 1642 COOKIE ACK 1643 10.0.0.1:1 --> 203.0.113.1:2 1644 Rem-VTag = 5678 1646 COOKIE ACK 1647 192.0.2.1:1 ----------------> 203.0.113.1:2 1648 Rem-VTag = 5678 1650 COOKIE ACK 1651 192.0.2.1:1 --> 10.1.0.1:2 1652 Rem-VTag = 5678 1654 8. SCTP NAT YANG Module 1656 This section defines a YANG module for SCTP NAT. 1658 The terminology for describing YANG data models is defined in 1659 [RFC7950]. The meaning of the symbols in tree diagrams is defined in 1660 [RFC8340]. 1662 8.1. Tree Structure 1664 This module augments NAT YANG module [RFC8512] with SCTP specifics. 1665 The module supports both classical SCTP NAT (that is, rewrite port 1666 numbers) and SCTP-specific variant where the ports numbers are not 1667 altered. The YANG "feature" is used to indicate whether SCTP- 1668 specific variant is supported. 1670 The tree structure of the SCTP NAT YANG module is provided below: 1672 module: ietf-nat-sctp 1673 augment /nat:nat/nat:instances/nat:instance 1674 /nat:policy/nat:timers: 1675 +--rw sctp-timeout? uint32 1676 augment /nat:nat/nat:instances/nat:instance 1677 /nat:mapping-table/nat:mapping-entry: 1678 +--rw int-VTag? uint32 {sctp-nat}? 1679 +--rw rem-VTag? uint32 {sctp-nat}? 1681 Concretely, the SCTP NAT YANG module augments the NAT YANG module 1682 (policy, in particular) with the following: 1684 * The sctp-timeout is used to control the SCTP inactivity timeout. 1685 That is, the time an SCTP mapping will stay active without SCTP 1686 packets traversing the NAT. This timeout can be set only for 1687 SCTP. Hence, "/nat:nat/nat:instances/nat:instance/nat:policy/ 1688 nat:transport-protocols/nat:protocol-id" MUST be set to '132' 1689 (SCTP). 1691 In addition, the SCTP NAT YANG module augments the mapping entry with 1692 the following parameters defined in Section 3. These parameters 1693 apply only for SCTP NAT mapping entries (i.e., 1694 "/nat/instances/instance/mapping-table/mapping-entry/transport- 1695 protocol" MUST be set to '132'); 1697 * The Internal Verification Tag (Int-VTag) 1699 * The Remote Verification Tag (Rem-VTag) 1701 8.2. YANG Module 1703 file "ietf-nat-sctp@2020-11-02.yang" 1704 module ietf-nat-sctp { 1705 yang-version 1.1; 1706 namespace "urn:ietf:params:xml:ns:yang:ietf-nat-sctp"; 1707 prefix nat-sctp; 1709 import ietf-nat { 1710 prefix nat; 1711 reference 1712 "RFC 8512: A YANG Module for Network Address Translation 1713 (NAT) and Network Prefix Translation (NPT)"; 1714 } 1716 organization 1717 "IETF TSVWG Working Group"; 1719 contact 1720 "WG Web: 1721 WG List: 1723 Author: Mohamed Boucadair 1724 "; 1725 description 1726 "This module augments NAT YANG module with Stream Control 1727 Transmission Protocol (SCTP) specifics. The extension supports 1728 both a classical SCTP NAT (that is, rewrite port numbers) 1729 and a, SCTP-specific variant where the ports numbers are 1730 not altered. 1732 Copyright (c) 2020 IETF Trust and the persons identified as 1733 authors of the code. All rights reserved. 1735 Redistribution and use in source and binary forms, with or 1736 without modification, is permitted pursuant to, and subject 1737 to the license terms contained in, the Simplified BSD License 1738 set forth in Section 4.c of the IETF Trust's Legal Provisions 1739 Relating to IETF Documents 1740 (http://trustee.ietf.org/license-info). 1742 This version of this YANG module is part of RFC XXXX; see 1743 the RFC itself for full legal notices."; 1745 revision 2019-11-18 { 1746 description 1747 "Initial revision."; 1748 reference 1749 "RFC XXXX: Stream Control Transmission Protocol (SCTP) 1750 Network Address Translation Support"; 1751 } 1753 feature sctp-nat { 1754 description 1755 "This feature means that SCTP-specific variant of NAT 1756 is supported. That is, avoid rewriting port numbers."; 1757 reference 1758 "Section 4.3 of RFC XXXX."; 1759 } 1761 augment "/nat:nat/nat:instances/nat:instance" 1762 + "/nat:policy/nat:timers" { 1763 when "/nat:nat/nat:instances/nat:instance" 1764 + "/nat:policy/nat:transport-protocols" 1765 + "/nat:protocol-id = 132"; 1766 description 1767 "Extends NAT policy with a timeout for SCTP mapping 1768 entries."; 1770 leaf sctp-timeout { 1771 type uint32; 1772 units "seconds"; 1773 description 1774 "SCTP inactivity timeout. That is, the time an SCTP 1775 mapping entry will stay active without packets 1776 traversing the NAT."; 1777 } 1778 } 1780 augment "/nat:nat/nat:instances/nat:instance" 1781 + "/nat:mapping-table/nat:mapping-entry" { 1782 when "nat:transport-protocol = 132"; 1783 if-feature "sctp-nat"; 1784 description 1785 "Extends the mapping entry with SCTP specifics."; 1787 leaf int-VTag { 1788 type uint32; 1789 description 1790 "The Internal Verification Tag that the internal 1791 host has chosen for this communication."; 1792 } 1793 leaf rem-VTag { 1794 type uint32; 1795 description 1796 "The Remote Verification Tag that the remote 1797 peer has chosen for this communication."; 1798 } 1799 } 1800 } 1801 1803 9. Socket API Considerations 1805 This section describes how the socket API defined in [RFC6458] is 1806 extended to provide a way for the application to control NAT 1807 friendliness. 1809 Please note that this section is informational only. 1811 A socket API implementation based on [RFC6458] is extended by 1812 supporting one new read/write socket option. 1814 9.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) 1816 This socket option uses the option_level IPPROTO_SCTP and the 1817 option_name SCTP_NAT_FRIENDLY. It can be used to enable/disable the 1818 NAT friendliness for future associations and retrieve the value for 1819 future and specific ones. 1821 struct sctp_assoc_value { 1822 sctp_assoc_t assoc_id; 1823 uint32_t assoc_value; 1824 }; 1826 assoc_id 1827 This parameter is ignored for one-to-one style sockets. For one- 1828 to-many style sockets the application can fill in an association 1829 identifier or SCTP_FUTURE_ASSOC for this query. It is an error to 1830 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 1832 assoc_value 1833 A non-zero value indicates a NAT-friendly mode. 1835 10. IANA Considerations 1837 [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number 1838 you assign this document.] 1840 [NOTE to RFC-Editor: The requested values for the chunk type and the 1841 chunk parameter types are tentative and to be confirmed by IANA.] 1843 This document (RFCXXXX) is the reference for all registrations 1844 described in this section. The requested changes are described 1845 below. 1847 10.1. New Chunk Flags for Two Existing Chunk Types 1849 As defined in [RFC6096] two chunk flags have to be assigned by IANA 1850 for the ERROR chunk. The requested value for the T bit is 0x01 and 1851 for the M bit is 0x02. 1853 This requires an update of the "ERROR Chunk Flags" registry for SCTP: 1855 ERROR Chunk Flags 1856 +==================+=================+===========+ 1857 | Chunk Flag Value | Chunk Flag Name | Reference | 1858 +==================+=================+===========+ 1859 | 0x01 | T bit | [RFCXXXX] | 1860 +------------------+-----------------+-----------+ 1861 | 0x02 | M bit | [RFCXXXX] | 1862 +------------------+-----------------+-----------+ 1863 | 0x04 | Unassigned | | 1864 +------------------+-----------------+-----------+ 1865 | 0x08 | Unassigned | | 1866 +------------------+-----------------+-----------+ 1867 | 0x10 | Unassigned | | 1868 +------------------+-----------------+-----------+ 1869 | 0x20 | Unassigned | | 1870 +------------------+-----------------+-----------+ 1871 | 0x40 | Unassigned | | 1872 +------------------+-----------------+-----------+ 1873 | 0x80 | Unassigned | | 1874 +------------------+-----------------+-----------+ 1876 Table 2 1878 As defined in [RFC6096] one chunk flag has to be assigned by IANA for 1879 the ABORT chunk. The requested value of the M bit is 0x02. 1881 This requires an update of the "ABORT Chunk Flags" registry for SCTP: 1883 ABORT Chunk Flags 1884 +==================+=================+===========+ 1885 | Chunk Flag Value | Chunk Flag Name | Reference | 1886 +==================+=================+===========+ 1887 | 0x01 | T bit | [RFC4960] | 1888 +------------------+-----------------+-----------+ 1889 | 0x02 | M bit | [RFCXXXX] | 1890 +------------------+-----------------+-----------+ 1891 | 0x04 | Unassigned | | 1892 +------------------+-----------------+-----------+ 1893 | 0x08 | Unassigned | | 1894 +------------------+-----------------+-----------+ 1895 | 0x10 | Unassigned | | 1896 +------------------+-----------------+-----------+ 1897 | 0x20 | Unassigned | | 1898 +------------------+-----------------+-----------+ 1899 | 0x40 | Unassigned | | 1900 +------------------+-----------------+-----------+ 1901 | 0x80 | Unassigned | | 1902 +------------------+-----------------+-----------+ 1904 Table 3 1906 10.2. Three New Error Causes 1908 Three error causes have to be assigned by IANA. It is requested to 1909 use the values given below. 1911 This requires three additional lines in the "Error Cause Codes" 1912 registry for SCTP: 1914 Error Cause Codes 1916 +=======+================================+===========+ 1917 | Value | Cause Code | Reference | 1918 +=======+================================+===========+ 1919 | 176 | VTag and Port Number Collision | [RFCXXXX] | 1920 +-------+--------------------------------+-----------+ 1921 | 177 | Missing State | [RFCXXXX] | 1922 +-------+--------------------------------+-----------+ 1923 | 178 | Port Number Collision | [RFCXXXX] | 1924 +-------+--------------------------------+-----------+ 1926 Table 4 1928 10.3. Two New Chunk Parameter Types 1930 Two chunk parameter types have to be assigned by IANA. IANA is 1931 requested to assign these values from the pool of parameters with the 1932 upper two bits set to '11' and to use the values given below. 1934 This requires two additional lines in the "Chunk Parameter Types" 1935 registry for SCTP: 1937 Chunk Parameter Types 1939 +==========+==========================+===========+ 1940 | ID Value | Chunk Parameter Type | Reference | 1941 +==========+==========================+===========+ 1942 | 49159 | Disable Restart (0xC007) | [RFCXXXX] | 1943 +----------+--------------------------+-----------+ 1944 | 49160 | VTags (0xC008) | [RFCXXXX] | 1945 +----------+--------------------------+-----------+ 1947 Table 5 1949 10.4. One New URI 1951 An URI in the "ns" subregistry within the "IETF XML" registry has to 1952 be assigned by IANA ([RFC3688]): 1954 URI: urn:ietf:params:xml:ns:yang:ietf-nat-sctp 1955 Registrant Contact: The IESG. 1956 XML: N/A; the requested URI is an XML namespace. 1958 10.5. One New YANG Module 1960 An YANG module in the "YANG Module Names" subregistry within the 1961 "YANG Parameters" registry has to be assigned by IANA ([RFC6020]): 1963 Name: ietf-nat-sctp 1964 Namespace: urn:ietf:params:xml:ns:yang:ietf-nat-sctp 1965 Maintained by IANA: N 1966 Prefix: nat-sctp 1967 Reference: RFCXXXX 1969 11. Security Considerations 1971 State maintenance within a NAT function is always a subject of 1972 possible Denial Of Service attacks. This document recommends that at 1973 a minimum a NAT function runs a timer on any SCTP state so that old 1974 association state can be cleaned up. 1976 Generic issues related to address sharing are discussed in [RFC6269] 1977 and apply to SCTP as well. 1979 For SCTP endpoints not disabling the restart procedure, this document 1980 does not add any additional security considerations to the ones given 1981 in [RFC4960], [RFC4895], and [RFC5061]. 1983 SCTP endpoints disabling the restart procedure, need to monitor the 1984 status of all associations to mitigate resource exhaustion attacks by 1985 establishing a lot of associations sharing the same IP addresses and 1986 port numbers. 1988 In any case, SCTP is protected by the verification tags and the usage 1989 of [RFC4895] against off-path attackers. 1991 For IP-level fragmentation and reassembly related issues see 1992 [RFC4963]. 1994 The YANG module specified in this document defines a schema for data 1995 that is designed to be accessed via network management protocols such 1996 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1997 is the secure transport layer, and the mandatory-to-implement secure 1998 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1999 is HTTPS, and the mandatory-to-implement secure transport is TLS 2000 [RFC8446]. 2002 The Network Configuration Access Control Model (NACM) [RFC8341] 2003 provides the means to restrict access for particular NETCONF or 2004 RESTCONF users to a preconfigured subset of all available NETCONF or 2005 RESTCONF protocol operations and content. 2007 All data nodes defined in the YANG module that can be created, 2008 modified, and deleted (i.e., config true, which is the default) are 2009 considered sensitive. Write operations (e.g., edit-config) applied 2010 to these data nodes without proper protection can negatively affect 2011 network operations. An attacker who is able to access the SCTP NAT 2012 function can undertake various attacks, such as: 2014 * Setting a low timeout for SCTP mapping entries to cause failures 2015 to deliver incoming SCTP packets. 2017 * Instantiating mapping entries to cause NAT collision. 2019 12. Normative References 2021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2022 Requirement Levels", BCP 14, RFC 2119, 2023 DOI 10.17487/RFC2119, March 1997, 2024 . 2026 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2027 DOI 10.17487/RFC3688, January 2004, 2028 . 2030 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 2031 "Authenticated Chunks for the Stream Control Transmission 2032 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2033 2007, . 2035 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2036 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2037 . 2039 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 2040 Kozuka, "Stream Control Transmission Protocol (SCTP) 2041 Dynamic Address Reconfiguration", RFC 5061, 2042 DOI 10.17487/RFC5061, September 2007, 2043 . 2045 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2046 the Network Configuration Protocol (NETCONF)", RFC 6020, 2047 DOI 10.17487/RFC6020, October 2010, 2048 . 2050 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 2051 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 2052 DOI 10.17487/RFC6096, January 2011, 2053 . 2055 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2056 and A. Bierman, Ed., "Network Configuration Protocol 2057 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2058 . 2060 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2061 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2062 . 2064 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2065 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2066 . 2068 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2069 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2070 May 2017, . 2072 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2073 Access Control Model", STD 91, RFC 8341, 2074 DOI 10.17487/RFC8341, March 2018, 2075 . 2077 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2078 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2079 . 2081 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 2082 Vinapamula, S., and Q. Wu, "A YANG Module for Network 2083 Address Translation (NAT) and Network Prefix Translation 2084 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 2085 . 2087 13. Informative References 2089 [DOI_10.1145_1496091.1496095] 2090 Hayes, D., But, J., and G. Armitage, "Issues with network 2091 address translation for SCTP", ACM SIGCOMM Computer 2092 Communication Review Vol. 39, pp. 23-33, 2093 DOI 10.1145/1496091.1496095, December 2008, 2094 . 2096 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2097 RFC 793, DOI 10.17487/RFC0793, September 1981, 2098 . 2100 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2101 Address Translator (Traditional NAT)", RFC 3022, 2102 DOI 10.17487/RFC3022, January 2001, 2103 . 2105 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 2106 Translation (NAT) Behavioral Requirements for Unicast 2107 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2108 2007, . 2110 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2111 Errors at High Data Rates", RFC 4963, 2112 DOI 10.17487/RFC4963, July 2007, 2113 . 2115 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 2116 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 2117 RFC 5382, DOI 10.17487/RFC5382, October 2008, 2118 . 2120 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 2121 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 2122 DOI 10.17487/RFC5508, April 2009, 2123 . 2125 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 2126 Protocol Port Randomization", BCP 156, RFC 6056, 2127 DOI 10.17487/RFC6056, January 2011, 2128 . 2130 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2131 NAT64: Network Address and Protocol Translation from IPv6 2132 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 2133 April 2011, . 2135 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 2136 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 2137 DOI 10.17487/RFC6269, June 2011, 2138 . 2140 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 2141 Stack Lite Broadband Deployments Following IPv4 2142 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 2143 . 2145 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 2146 Yasevich, "Sockets API Extensions for the Stream Control 2147 Transmission Protocol (SCTP)", RFC 6458, 2148 DOI 10.17487/RFC6458, December 2011, 2149 . 2151 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 2152 "Special-Purpose IP Address Registries", BCP 153, 2153 RFC 6890, DOI 10.17487/RFC6890, April 2013, 2154 . 2156 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 2157 Control Transmission Protocol (SCTP) Packets for End-Host 2158 to End-Host Communication", RFC 6951, 2159 DOI 10.17487/RFC6951, May 2013, 2160 . 2162 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2163 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2164 . 2166 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 2167 S., and K. Naito, "Updates to Network Address Translation 2168 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 2169 DOI 10.17487/RFC7857, April 2016, 2170 . 2172 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2173 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2174 . 2176 Acknowledgments 2178 The authors wish to thank Mohamed Boucadair, Gorry Fairhurst, Bryan 2179 Ford, David Hayes, Alfred Hines, Karen E. E. Nielsen, Henning Peters, 2180 Maksim Proshin, Timo Völker, Dan Wing, and Qiaobing Xie for their 2181 invaluable comments. 2183 In addition, the authors wish to thank David Hayes, Jason But, and 2184 Grenville Armitage, the authors of [DOI_10.1145_1496091.1496095], for 2185 their suggestions. 2187 The authors also wish to thank Mohamed Boucadair for contributing the 2188 text related to the YANG module. 2190 Authors' Addresses 2192 Randall R. Stewart 2193 Netflix, Inc. 2194 Chapin, SC 29036 2195 United States of America 2197 Email: randall@lakerest.net 2199 Michael Tüxen 2200 Münster University of Applied Sciences 2201 Stegerwaldstrasse 39 2202 48565 Steinfurt 2203 Germany 2205 Email: tuexen@fh-muenster.de 2206 Irene Rüngeler 2207 Münster University of Applied Sciences 2208 Stegerwaldstrasse 39 2209 48565 Steinfurt 2210 Germany 2212 Email: i.ruengeler@fh-muenster.de