idnits 2.17.1 draft-ietf-tsvwg-natsupp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC0793], [RFC4960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 28 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 37 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2015) is 3348 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 444, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1628, 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: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Netflix, Inc. 4 Intended status: Standards Track M. Tuexen 5 Expires: August 29, 2015 I. Ruengeler 6 Muenster Univ. of Appl. Sciences 7 February 25, 2015 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 Support 11 draft-ietf-tsvwg-natsupp-07.txt 13 Abstract 15 Stream Control Transmission Protocol [RFC4960] provides a reliable 16 communications channel between two end-hosts in many ways similar to 17 TCP [RFC0793]. With the widespread deployment of Network Address 18 Translators (NAT), specialized code has been added to NAT for TCP 19 that allows multiple hosts to reside behind a NAT and yet use only a 20 single globally unique IPv4 address, even when two hosts (behind a 21 NAT) choose the same port numbers for their connection. This 22 additional code is sometimes classified as Network Address and Port 23 Translation (NAPT). To date, specialized code for SCTP has not yet 24 been added to most NATs so that only pure NAT is available. The end 25 result of this is that only one SCTP capable host can be behind a 26 NAT. 28 This document describes the protocol extensions required for the SCTP 29 endpoints to help NATs provide similar features of NAPT in the 30 single-point and multi-point traversal scenario. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 29, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . 6 71 4.1.1. Single Point Traversal . . . . . . . . . . . . . . . 6 72 4.1.2. Multi Point Traversal . . . . . . . . . . . . . . . . 7 73 4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 7 74 4.3. The SCTP Specific Variant of NAT . . . . . . . . . . . . 8 75 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 12 77 5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 12 78 5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 12 79 5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 13 80 5.2.1. VTag and Port Number Collision Error Cause . . . . . 13 81 5.2.2. Missing State Error Cause . . . . . . . . . . . . . . 13 82 5.2.3. Port Number Collision Error Cause . . . . . . . . . . 14 83 5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 14 84 5.3.1. Disable Restart Parameter . . . . . . . . . . . . . . 14 85 5.3.2. VTags Parameter . . . . . . . . . . . . . . . . . . . 15 86 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 88 6.2. Association Setup Considerations . . . . . . . . . . . . 17 89 6.3. Handling of Internal Port Number and Verification Tag 90 Collisions . . . . . . . . . . . . . . . . . . . . . . . 17 91 6.4. Handling of Internal Port Number Collisions . . . . . . . 18 92 6.5. Handling of Missing State . . . . . . . . . . . . . . . . 19 93 6.6. Handling of Fragmented SCTP Packets . . . . . . . . . . . 21 94 6.7. Multi-Point Traversal Considerations . . . . . . . . . . 21 95 7. Various Examples of NAT Traversals . . . . . . . . . . . . . 21 96 7.1. Single-homed Client to Single-homed Server . . . . . . . 21 97 7.2. Single-homed Client to Multi-homed Server . . . . . . . . 23 98 7.3. Multihomed Client and Server . . . . . . . . . . . . . . 26 99 7.4. NAT Loses Its State . . . . . . . . . . . . . . . . . . . 30 100 7.5. Peer-to-Peer Communication . . . . . . . . . . . . . . . 32 101 8. Socket API Considerations . . . . . . . . . . . . . . . . . . 37 102 8.1. Get or Set the NAT Friendliness 103 (SCTP_NAT_FRIENDLY) . . . . . . . . . . . . . . . . . . . 38 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 105 9.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 38 106 9.2. Three New Error Causes . . . . . . . . . . . . . . . . . 39 107 9.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 40 108 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40 109 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 41 112 12.2. Informative References . . . . . . . . . . . . . . . . . 41 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 115 1. Introduction 117 Stream Control Transmission Protocol [RFC4960] provides a reliable 118 communications channel between two end-hosts in many ways similar to 119 TCP [RFC0793]. With the widespread deployment of Network Address 120 Translators (NAT), specialized code has been added to NAT for TCP 121 that allows multiple hosts to reside behind a NAT using private 122 addresses (see [RFC6890]) and yet use only a single globally unique 123 IPv4 address, even when two hosts (behind a NAT) choose the same port 124 numbers for their connection. This additional code is sometimes 125 classified as Network Address and Port Translation (NAPT). To date, 126 specialized code for SCTP has not yet been added to most NATs so that 127 only true NAT is available. The end result of this is that only one 128 SCTP capable host can be behind a NAT. 130 This document describes an SCTP specific variant NAT and specific 131 packets and procedures to help NATs provide similar features of NAPT 132 in the single-point and multi-point traversal scenario. An SCTP 133 implementation supporting this extension will follow these procedures 134 to assure that in both single-homed and multi-homed cases a NAT will 135 maintain the proper state without needing to change port numbers. 137 The authors feel it is possible and desirable to make these changes 138 for a number of reasons: 140 o It is desirable for SCTP internal end-hosts on multiple platforms 141 to be able to share a NAT's public IP address, much as TCP does 142 today. 144 o If a NAT does not need to change any data within an SCTP packet it 145 will reduce the processing burden of NAT'ing SCTP by NOT needing 146 to execute the CRC32c checksum required by SCTP. 148 o Not having to touch the IP payload makes the processing of ICMP 149 messages in NATs easier. 151 An SCTP-aware NAT will need to follow these procedures for generating 152 appropriate SCTP packet formats. 154 When considering this feature it is possible to have multiple levels 155 of support. At each level, the Internal Host, External Host and NAT 156 may or may not support the features described in this document. The 157 following table illustrates the results of the various combinations 158 of support and if communications can occur between two endpoints. 160 +---------------+------------+---------------+---------------+ 161 | Internal Host | NAT | External Host | Communication | 162 +---------------+------------+---------------+---------------+ 163 | Support | Support | Support | Yes | 164 | Support | Support | No Support | Limited | 165 | Support | No Support | Support | None | 166 | Support | No Support | No Support | None | 167 | No Support | Support | Support | Limited | 168 | No Support | Support | No Support | Limited | 169 | No Support | No Support | Support | None | 170 | No Support | No Support | No Support | None | 171 +---------------+------------+---------------+---------------+ 173 Table 1: Communication possibilities 175 From the table we can see that when a NAT does not support the 176 extension no communication can occur. This is because for the most 177 part of the current situation i. e. SCTP packets sent externally 178 from behind a NAT are discarded by the NAT. In some cases, where the 179 NAT supports the feature but one of the two external hosts does not 180 support the feature, communication may occur but in a limited way. 181 For example only one host may be able to have a connection when a 182 collision case occurs. 184 2. Conventions 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 3. Terminology 192 This document uses the following terms, which are depicted in 193 Figure 1. 195 Private-Address (Priv-Addr): The private address that is known to 196 the internal host. 198 Internal-Port (Int-Port): The port number that is in use by the host 199 holding the Private-Address. 201 Internal-VTag (Int-VTag): The Verification Tag that the internal 202 host has chosen for its communication. The VTag is a unique 203 32-bit tag that must accompany any incoming SCTP packet for this 204 association to the Private-Address. 206 External-Address (Ext-Addr): The address that an internal host is 207 attempting to contact. 209 External-Port (Ext-Port): The port number of the peer process at the 210 External-Address. 212 External-VTag (Ext-VTag): The Verification Tag that the host holding 213 the External-Address has chosen for its communication. The VTag 214 is a unique 32-bit tag that must accompany any incoming SCTP 215 packet for this association to the External-Address. 217 Public-Address (Pub-Addr): The public address assigned to the NAT 218 box which it uses as a source address when sending packets towards 219 the External-Address. 221 Internal Network | External Network 222 | 223 Private | Public External 224 +---------+ Address | Address /--\/--\ Address +---------+ 225 | SCTP | +-----+ / \ | SCTP | 226 |end point|=========| NAT |=======| Internet |==========|end point| 227 | A | +-----+ \ / | B | 228 +---------+ Internal | \--/\--/ External+---------+ 229 Internal Port | Port External 230 VTag | VTag 232 Figure 1: Basic network setup 234 4. Motivation 236 4.1. SCTP NAT Traversal Scenarios 238 This section defines the notion of single and multi-point NAT 239 traversal. 241 4.1.1. Single Point Traversal 243 In this case, all packets in the SCTP association go through a single 244 NAT, as shown below: 246 Internal Network | External Network 247 | 248 +---------+ | /--\/--\ +---------+ 249 | SCTP | +-----+ / \ | SCTP | 250 |end point|=========| NAT |========= | Internet | ========|end point| 251 | A | +-----+ \ / | B | 252 +---------+ | \--/\--/ +---------+ 253 | 255 Single NAT scenario 257 A variation of this case is shown below, i.e., multiple NATs in a 258 single path: 260 Internal | External : Internal | External 261 | : | 262 +---------+ | : | /--\/--\ +---------+ 263 | SCTP | +-----+ : +-----+ / \ | SCTP | 264 |end point|==| NAT |=======:=======| NAT |==| Internet |==|end point| 265 | A | +-----+ : +-----+ \ / | B | 266 +---------+ | : | \--/\--/ +---------+ 267 | : | 269 Serial NATs scenario 271 In this single point traversal scenario, we must acknowledge that 272 while one of the main benefits of SCTP multi-homing is redundant 273 paths, the NAT function represents a single point of failure in the 274 path of the SCTP multi-home association. However, the rest of the 275 path may still benefit from path diversity provided by SCTP multi- 276 homing. 278 The two SCTP endpoints in this case can be either single-homed or 279 multi-homed. However, the important thing is that the NAT (or NATs) 280 in this case sees all the packets of the SCTP association. 282 4.1.2. Multi Point Traversal 284 This case involves multiple NATs and each NAT only sees some of the 285 packets in the SCTP association. An example is shown below: 287 Internal | External 288 +------+ /---\/---\ 289 +---------+ /=======|NAT A |=========\ / \ +---------+ 290 | SCTP | / +------+ \/ \ | SCTP | 291 |end point|/ ... | Internet |===|end point| 292 | A |\ \ / | B | 293 +---------+ \ +------+ / \ / +---------+ 294 \=======|NAT B |=========/ \---\/---/ 295 +------+ 296 | 298 Parallel NATs scenario 300 This case does NOT apply to a single-homed SCTP association (i.e., 301 BOTH endpoints in the association use only one IP address). The 302 advantage here is that the existence of multiple NAT traversal points 303 can preserve the path diversity of a multi-homed association for the 304 entire path. This in turn can improve the robustness of the 305 communication. 307 4.2. Limitations of Classical NAPT for SCTP 309 Using classical NAPT may result in changing one of the SCTP port 310 numbers during the processing which requires the recomputation of the 311 transport layer checksum. Whereas for UDP and TCP this can be done 312 very efficiently, for SCTP the checksum (CRC32c) over the entire 313 packet needs to be recomputed. This would add considerable to the 314 NAT computational burden, however hardware support may mitigate this 315 in some implementations. 317 An SCTP endpoint may have multiple addresses but only has a single 318 port number. To make multipoint traversal work, all the NATs 319 involved must recognize the packets they see as belonging to the same 320 SCTP association and perform port number translation in a consistent 321 way. One possible way of doing this is to use pre-defined table of 322 ports and addresses configured within each NAT. Other mechanisms 323 could make use of NAT to NAT communication. Such mechanisms are 324 considered by the authors not to be deployable on a wide scale base 325 and thus not a recommended solution. Therefore the SCTP variant of 326 NAT has been developed. 328 4.3. The SCTP Specific Variant of NAT 330 In this section we assume that we have multiple SCTP capable hosts 331 behind a NAT which has one Public-Address. Furthermore we are 332 focusing in this section on the single point traversal scenario. 334 The modification of SCTP packets sent to the public Internet is easy. 335 The source address of the packet has to be replaced with the Public- 336 Address. It may also be necessary to establish some state in the NAT 337 box to handle incoming packets, which is discussed later. 339 For SCTP packets coming from the public Internet the destination 340 address of the packets has to be replaced with the Private-Address of 341 the host the packet has to be delivered to. The lookup of the 342 Private-Address is based on the External-VTag, External-Port, 343 External-Address, Internal-VTag and the Internal-Port. 345 For the SCTP NAT processing the NAT box has to maintain a table of 346 Internal-VTag, Internal-Port, Private-Address, External-VTag, 347 External-Port and whether the restart procedure is disabled or not. 348 An entry in that table is called a NAT state control block. The 349 function Create() obtains the just mentioned parameters and returns a 350 NAT-State control block. 352 The entries in this table fulfill some uniqueness conditions. There 353 must not be more than one entry with the same pair of Internal-Port 354 and External-Port. This rule can be relaxed, if all entries with the 355 same Internal-Port and External-Port have the support for the restart 356 procedure enabled. In this case there must be no more than one entry 357 with the same Internal-Port, External-Port and Ext-VTag and no more 358 than one entry with the same Internal-Port, External-Port and Int- 359 VTag. 361 The processing of outgoing SCTP packets containing an INIT-chunk is 362 described in the following figure. The scenario shown is valid for 363 all message flows in this section. 365 /--\/--\ 366 +--------+ +-----+ / \ +--------+ 367 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 368 +--------+ +-----+ \ / +--------+ 369 \--/\---/ 371 INIT[Initiate-Tag] 372 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 373 Ext-VTag=0 375 Create(Initiate-Tag, Int-Port, Priv-Addr, 0) 376 Returns(NAT-State control block) 378 Translate To: 380 INIT[Initiate-Tag] 381 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 382 Ext-VTag=0 384 It should be noted that normally a NAT control block will be created. 385 However, it is possible that there is already a NAT control block 386 with the same External-Address, External-Port, Internal-Port, and 387 Internal-VTag but different Private-Address. In this case the INIT 388 SHOULD be dropped by the NAT and an ABORT SHOULD be sent back to the 389 SCTP host with the M-Bit set and an appropriate error cause (see 390 Section 5.1.1 for the format). The source address of the packet 391 containing the ABORT chunk MUST be the destination address of the 392 packet containing the INIT chunk. 394 It is also possible that a connection to External-Address and 395 External-Port exists without an Internal-VTag conflict but the 396 External-Address does not support the DISABLE_RESTART feature (noted 397 in the NAT control block when the prior connection was established). 398 In such a case the INIT SHOULD be dropped by the NAT and an ABORT 399 SHOULD be sent back to the SCTP host with the M-Bit set and an 400 appropriate error cause (see Section 5.1.1 for the format). 402 The processing of outgoing SCTP packets containing no INIT-chunk is 403 described in the following figure. 405 /--\/--\ 406 +--------+ +-----+ / \ +--------+ 407 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 408 +--------+ +-----+ \ / +--------+ 409 \--/\---/ 411 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port 412 Ext-VTag 414 Translate To: 416 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port 417 Ext-VTag 419 The processing of incoming SCTP packets containing INIT-ACK chunks is 420 described in the following figure. The Lookup() function getting as 421 input the Internal-VTag, Internal-Port, External-VTag (=0), External- 422 Port, and External-Address, returns the corresponding entry of the 423 NAT table and updates the External-VTag by substituting it with the 424 value of the Initiate-Tag of the INIT-ACK chunk. The wildcard 425 character signifies that the parameter's value is not considered in 426 the Lookup() function or changed in the Update() function, 427 respectively. 429 /--\/--\ 430 +--------+ +-----+ / \ +--------+ 431 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 432 +--------+ +-----+ \ / +--------+ 433 \--/\---/ 435 INIT-ACK[Initiate-Tag] 436 Pub-Addr:Int-Port <---- Ext-Addr:Ext-Port 437 Int-VTag 439 Lookup(Int-VTag, Int-Port, *, 0, Ext-Port) 440 Update(*, *, *, Initiate-Tag, *) 442 Returns(NAT-State control block containing Private-Address) 444 INIT-ACK[Initiate-Tag] 445 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 446 Int-VTag 448 In the case Lookup fails, the SCTP packet is dropped. The Update 449 routine inserts the External-VTag (the Initiate-Tag of the INIT-ACK 450 chunk) in the NAT state control block. 452 The processing of incoming SCTP packets containing an ABORT or 453 SHUTDOWN-COMPLETE chunk with the T-Bit set is described in the 454 following figure. 456 /--\/--\ 457 +--------+ +-----+ / \ +--------+ 458 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 459 +--------+ +-----+ \ / +--------+ 460 \--/\---/ 462 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 463 Ext-VTag 465 Lookup(0, Int-Port, *, Ext-VTag, Ext-Port) 467 Returns(NAT-State control block containing Private-Address) 469 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 470 Ext-VTag 472 The processing of other incoming SCTP packets is described in the 473 following figure. 475 /--\/--\ 476 +--------+ +-----+ / \ +--------+ 477 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 478 +--------+ +-----+ \ / +--------+ 479 \--/\---/ 481 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port 482 Int-VTag 484 Lookup(Int-VTag, Int-Port, *, *, Ext-Port) 486 Returns(NAT-State control block containing Local-Address) 488 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port 489 Int-VTag 491 For an incoming packet containing an INIT-chunk a table lookup is 492 made only based on the addresses and port numbers. If an entry with 493 an External-VTag of zero is found, it is considered a match and the 494 External-VTag is updated. 496 This allows the handling of INIT-collision through NAT. 498 5. Data Formats 500 5.1. Modified Chunks 502 This section presents existing chunks defined in [RFC4960] that are 503 modified by this document. 505 5.1.1. Extended ABORT Chunk 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Type = 6 | Reserved |M|T| Length | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 \ \ 513 / zero or more Error Causes / 514 \ \ 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 The ABORT chunk is extended to add the new 'M-bit'. The M-bit 518 indicates to the receiver of the ABORT chunk that the chunk was not 519 generated by the peer SCTP endpoint, but instead by a middle box. 521 5.1.2. Extended ERROR Chunk 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type = 9 | Reserved |M|T| Length | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 \ \ 529 / zero or more Error Causes / 530 \ \ 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 The ERROR chunk defined in [RFC4960] is extended to add the new 534 'M-bit'. The M-bit indicates to the receiver of the ERROR chunk that 535 the chunk was not generated by the peer SCTP endpoint, but instead by 536 a middle box. 538 5.2. New Error Causes 540 This section defines the new error causes added by this document. 542 5.2.1. VTag and Port Number Collision Error Cause 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Cause Code = 0x00B0 | Cause Length = Variable | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 \ Chunk / 550 / \ 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Cause Code: 2 bytes (unsigned integer) 554 This field holds the IANA defined cause code for the VTag and Port 555 Number Collision Error Cause. The suggested value of this field 556 for IANA is 0x00B0. 558 Cause Length: 2 bytes (unsigned integer) 559 This field holds the length in bytes of the error cause. The 560 value MUST be the length of the Cause-Specific Information plus 4. 562 Chunk: variable length 563 The Cause-Specific Information is filled with the chunk that 564 caused this error. This can be an INIT, INIT-ACK, or ASCONF 565 chunk. Note that if the entire chunk will not fit in the ERROR 566 chunk or ABORT chunk being sent then the bytes that do not fit are 567 truncated. 569 5.2.2. Missing State Error Cause 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Cause Code = 0x00B1 | Cause Length = Variable | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 \ Incoming Packet / 577 / \ 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Cause Code: 2 bytes (unsigned integer) 581 This field holds the IANA defined cause code for the Missing State 582 Error Cause. The suggested value of this field for IANA is 583 0x00B1. 585 Cause Length: 2 bytes (unsigned integer) 586 This field holds the length in bytes of the error cause. The 587 value MUST be the length of the Cause-Specific Information plus 4. 589 Incoming Packet: variable length 590 The Cause-Specific Information is filled with the IPv4 or IPv6 591 packet that caused this error. The IPv4 or IPv6 header MUST be 592 included. Note that if the packet will not fit in the ERROR chunk 593 or ABORT chunk being sent then the bytes that do not fit are 594 truncated. 596 5.2.3. Port Number Collision Error Cause 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Cause Code = 0x00B2 | Cause Length = Variable | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 \ chunk / 604 / \ 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Cause Code: 2 bytes (unsigned integer) 608 This field holds the IANA defined cause code for the Port Number 609 Collision Error Cause. The suggested value of this field for IANA 610 is 0x00B2. 612 Cause Length: 2 bytes (unsigned integer) 613 This field holds the length in bytes of the error cause. The 614 value MUST be the length of the Cause-Specific Information plus 4. 616 Chunk: variable length 617 The Cause-Specific Information is filled with the chunk that 618 caused this error. This can be an INIT, INIT-ACK, or ASCONF 619 chunk. Note that if the entire chunk will not fit in the ERROR 620 chunk or ABORT chunk being sent then the bytes that do not fit are 621 truncated. 623 5.3. New Parameters 625 This section defines new parameters and their valid appearance 626 defined by this document. 628 5.3.1. Disable Restart Parameter 630 This parameter is used to indicate that the RESTART procedure is 631 requested to be disabled. Both endpoints of an association MUST 632 include this parameter in the INIT chunk and INIT-ACK chunk when 633 establishing an association and MUST include it in the ASCONF chunk 634 when adding an address to successfully disable the restart procedure. 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Type = 0xC007 | Length = 4 | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Parameter Type: 2 bytes (unsigned integer) 643 This field holds the IANA defined parameter type for the Disable 644 Restart Parameter. The suggested value of this field for IANA is 645 0xC007. 647 Parameter Length: 2 bytes (unsigned integer) 648 This field holds the length in bytes of the parameter. The value 649 MUST be 4. 651 This parameter MAY appear in INIT, INIT-ACK and ASCONF chunks and 652 MUST NOT appear in any other chunk. 654 5.3.2. VTags Parameter 656 This parameter is used to help a NAT recover from state loss. 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Parameter Type = 0xC008 | Parameter Length = 16 | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | ASCONF-Request Correlation ID | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Internal Verification Tag | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | External Verification Tag | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Parameter Type: 2 bytes (unsigned integer) 671 This field holds the IANA defined parameter type for the VTags 672 Parameter. The suggested value of this field for IANA is 0xC008. 674 Parameter Length: 2 bytes (unsigned integer) 675 This field holds the length in bytes of the parameter. The value 676 MUST be 16. 678 ASCONF-Request Correlation ID: 4 bytes (unsigned integer) 679 This is an opaque integer assigned by the sender to identify each 680 request parameter. The receiver of the ASCONF Chunk will copy 681 this 32-bit value into the ASCONF Response Correlation ID field of 682 the ASCONF-ACK response parameter. The sender of the ASCONF can 683 use this same value in the ASCONF-ACK to find which request the 684 response is for. Note that the receiver MUST NOT change this 685 32-bit value. 687 Internal Verification Tag: 4 bytes (unsigned integer) 688 The Verification Tag that the internal host has chosen for its 689 communication. The Verification Tag is a unique 32-bit tag that 690 must accompany any incoming SCTP packet for this association to 691 the Private-Address. 693 External Verification Tag: 4 bytes (unsigned integer) The 694 Verification Tag that the host holding the External-Address has 695 chosen for its communication. The VTag is a unique 32-bit tag 696 that must accompany any incoming SCTP packet for this association 697 to the External-Address. 699 This parameter MAY appear in ASCONF chunks and MUST NOT appear in any 700 other chunk. 702 6. Procedures 704 6.1. Overview 706 When an SCTP endpoint is behind an SCTP-aware NAT a number of 707 problems may arise as it tries to communicate with its peer: 709 o More than one host behind a NAT may pick the same VTag and source 710 port when talking to the same peer server. This creates a 711 situation where the NAT will not be able to tell the two 712 associations apart. This situation is discussed in Section 6.3. 714 o When an SCTP endpoint is a server communicating with multiple 715 peers and the peers are behind the same NAT, then the two 716 endpoints cannot be distinguished by the server. This case is 717 discussed in Section 6.4. 719 o A restart of a NAT during a conversation could cause a loss of its 720 state. This problem and its solution is discussed in Section 6.5. 722 o An SCTP endpoint may be behind two NATs providing redundancy. The 723 method to set up this scenario is discussed in Section 6.7. 725 Each of these mechanisms requires additional chunks and parameters, 726 defined in this document, and possibly modified handling procedures 727 from those specified in [RFC4960] fdafdfafdafdafdafdafdasf. 729 6.2. Association Setup Considerations 731 Every association MUST initially be set up single-homed. There MUST 732 NOT be any IPv4 Address parameter, IPv6 Address parameter, or 733 Supported Address Types parameter in the INIT-chunk. The INIT-ACK 734 chunk MUST NOT contain any IPv4 Address parameter or IPv6 Address 735 parameter. 737 If the association should finally be multi-homed, the procedure in 738 Section 6.7 MUST be used. 740 The INIT and INIT-ACK chunk SHOULD contain the Disable Restart 741 parameter defined in Section 5.3.1. 743 6.3. Handling of Internal Port Number and Verification Tag Collisions 745 Consider the case where two hosts in the Private-Address space want 746 to set up an SCTP association with the same server running on the 747 same host in the Internet. This means that the External-Port and the 748 External-Address are the same. If they both choose the same 749 Internal-Port and Internal-VTag, the NAT box cannot distinguish 750 between incoming packets anymore. But this is very unlikely. The 751 Internal-VTags are chosen at random and if the Internal-Ports are 752 also chosen from the ephemeral port range at random this gives a 753 46-bit random number which has to match. In the TCP like NAPT case 754 the NAT box can control the 16-bit Natted Port and therefor avoid 755 collisions deterministically. 757 The same can happen when an INIT-ACK chunk or an ASCONF chunk is 758 processed by the NAT. 760 However, in this unlikely event the NAT box MUST send an ABORT chunk 761 with the M-bit set if the collision is triggered by an INIT or INIT- 762 ACK chunk or send an ERROR chunk with the M-bit set if the collision 763 is triggered by an ASCONF chunk. The M-bit is a new bit defined by 764 this document to express to SCTP that the source of this packet is a 765 "middle" box, not the peer SCTP endpoint (see Section 5.1.1). If a 766 packet containing an INIT-ACK chunk triggers the collision, the 767 corresponding packet containing the ABORT chunk MUST contain the same 768 source and destination address and port numbers as the packet 769 containing the INIT-ACK chunk. In the other two cases, the source 770 and destination address and port numbers MUST be swapped. 772 The sender of the packet containing the INIT chunk or the receiver of 773 the INIT-ACK chunk, upon reception of an ABORT chunk with M-bit set, 774 SHOULD reinitiate the association setup procedure after choosing a 775 new initiate tag. These procedures SHOULD be followed only if the 776 appropriate error cause code for colliding NAT table state is 777 included AND the association is in the COOKIE-WAIT state (i. e. it is 778 awaiting an INIT-ACK). If the endpoint is in any other state an SCTP 779 endpoint SHOULD NOT respond. 781 The sender of the ASCONF chunk, upon reception of an ERROR chunk with 782 M-bit set, MUST stop adding the path to the association. 784 The sender of the ERROR or ABORT chunk MUST include the error cause 785 with cause code 'VTag and Port Number Collision' (see Section 5.2.1). 787 6.4. Handling of Internal Port Number Collisions 789 When two SCTP hosts are behind an SCTP-aware NAT it is possible that 790 two SCTP hosts in the Private-Address space will want to set up an 791 SCTP association with the same server running on the same host in the 792 Internet. For the NAT appropriate tracking may be performed by 793 assuring that the VTags are unique between the two hosts. But for 794 the external SCTP server on the internet this means that the 795 External-Port and the External-Address are the same. If they both 796 have chosen the same Internal-Port the server cannot distinguish 797 between both associations based on the address and port numbers. For 798 the server it looks like the association is being restarted. To 799 overcome this limitation the client sends a Disable Restart parameter 800 in the INIT-chunk. 802 When the server receives this parameter it MUST do the following: 804 o Include a Disable Restart parameter in the INIT-ACK to inform the 805 client that it will support the feature. 807 o Disable the restart procedures defined in [RFC4960] for this 808 association. 810 Servers that support this feature will need to be capable of 811 maintaining multiple connections to what appears to be the same peer 812 (behind the NAT) differentiated only by the VTags. 814 The NAT, when processing the INIT-ACK, should note in its internal 815 table that the association supports the Disable Restart extension. 816 This note is used when establishing future associations (i. e. when 817 processing an INIT from an internal host) to decide if the connection 818 should be allowed. The NAT MUST do the following when processing an 819 INIT: 821 o If the INIT is destined to an external address and port for which 822 the NAT has no outbound connection, allow the INIT creating an 823 internal mapping table. 825 o If the INIT matches the external address and port of an already 826 existing connection, validate that the external server supports 827 the Disable Restart feature, if it does allow the INIT to be 828 forwarded. 830 o If the external server does not support the Disable Restart 831 extension the NAT MUST send an ABORT with the M-bit set. 833 The 'Port Number Collision' error cause (see Section 5.2.3) MUST be 834 included in the ABORT chunk. 836 If the collision is triggered by an ASCONF chunk, a packet containing 837 an ERROR chunk with the 'Port Number Collision' error cause MUST be 838 sent back. 840 6.5. Handling of Missing State 842 If the NAT box receives a packet from the internal network for which 843 the lookup procedure does not find an entry in the NAT table, a 844 packet containing an ERROR chunk is sent back with the M-bit set. 845 The source address of the packet containing the ERROR chunk MUST be 846 the destination address of the incoming SCTP packet. The 847 verification tag is reflected and the T-bit is set. Please note that 848 such a packet containing an ERROR chunk SHOULD NOT be sent if the 849 received packet contains an ABORT, SHUTDOWN-COMPLETE or INIT-ACK 850 chunk. An ERROR chunk MUST NOT be sent if the received packet 851 contains an ERROR chunk with the M-bit set. 853 When sending the ERROR chunk, the new error cause Missing state (see 854 Section 5.2.2) MUST be included and the new M-bit of the ERROR chunk 855 MUST be set (see Section 5.1.2). 857 Upon reception of this ERROR chunk by an SCTP endpoint the receiver 858 SHOULD take the following actions: 860 o Validate that the verification tag is reflected by looking at the 861 VTag that would have been included in the outgoing packet. 863 o Validate that the peer of the SCTP association supports the 864 dynamic address extension, if it does not discard the incoming 865 ERROR chunk. 867 o Generate a new ASCONF chunk containing the VTags parameter (see 868 Section 5.3.2) and the Disable Restart parameter if the 869 association is using the disabled restart feature. By processing 870 this packet the NAT can recover the appropriate state. The 871 procedures for generating an ASCONF chunk can be found in 872 [RFC5061]. 874 If the NAT box receives a packet for which it has no NAT table entry 875 and the packet contains an ASCONF chunk with the VTags parameter, the 876 NAT box MUST update its NAT table according to the verification tags 877 in the VTags parameter and the optional Disable Restart parameter. 879 The peer SCTP endpoint receiving such an ASCONF chunk SHOULD either 880 add the address and respond with an acknowledgment, if the address is 881 new to the association (following all procedures defined in 882 [RFC5061]). Or, if the address is already part of the association, 883 the SCTP endpoint MUST NOT respond with an error, but instead should 884 respond with an ASCONF-ACK chunk acknowledging the address but take 885 no action (since the address is already in the association). 887 Note that it is possible that upon receiving an ASCONF chunk 888 containing the VTags parameter the NAT will realize that it has an 889 'Internal Port Number and Verification Tag collision'. In such a 890 case the NAT MUST send an ERROR chunk with the error cause code set 891 to 'VTag and Port Number Collision' (see Section 5.2.1). 893 If an SCTP endpoint receives an ERROR with 'Internal Port Number and 894 Verification Tag collision' as the error cause and the packet in the 895 Error Chunk contains an ASCONF with the VTags parameter, careful 896 examination of the association is required. The endpoint MUST do the 897 following: 899 o Validate that the verification tag is reflected by looking at the 900 VTag that would have been included in the outgoing packet. 902 o Validate that the peer of the SCTP association supports the 903 dynamic address extension, if it does not discard the incoming 904 ERROR chunk. 906 o If the association is attempting to add an address (i. e. 907 following the procedures in Section 6.7) then the endpoint MUST- 908 NOT consider the address part of the association and SHOULD make 909 no further attempt to add the address (i. e. cancel any ASCONF 910 timers and remove any record of the path), since the NAT has a 911 VTag collision and the association cannot easily create a new VTag 912 (as it would if the error occurred when sending an INIT). 914 o If the endpoint has no other path, i. e. the procedure was 915 executed due to missing a state in the NAT, then the endpoint MUST 916 abort the association. This would occur only if the local NAT 917 restarted and accepted a new association before attempting to 918 repair the missing state (Note that this is no different than what 919 happens to all TCP connections when a NAT looses its state). 921 6.6. Handling of Fragmented SCTP Packets 923 A NAT box MUST support IP reassembly of received fragmented SCTP 924 packets. The fragments may arrive in any order. 926 When an SCTP packet has to be fragmented by the NAT box and the IP 927 header forbids fragmentation a corresponding ICMP packet SHOULD be 928 sent. 930 6.7. Multi-Point Traversal Considerations 932 If a multi-homed SCTP endpoint behind a NAT connects to a peer, it 933 SHOULD first set up the association single-homed with only one 934 address causing the first NAT to populate its state. Then it SHOULD 935 add each IP address using ASCONF chunks sent via their respective 936 NATs. The address to add is the wildcard address and the lookup 937 address SHOULD also contain the VTags parameter and optionally the 938 Disable Restart parameter as illustrated above. 940 7. Various Examples of NAT Traversals 942 7.1. Single-homed Client to Single-homed Server 944 The internal client starts the association with the external server 945 via a four-way-handshake. Host A starts by sending an INIT chunk. 947 /--\/--\ 948 +--------+ +-----+ / \ +--------+ 949 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 950 +--------+ +-----+ \ / +--------+ 951 \--/\---/ 952 +---------+--------+-----------+----------+--------+ 953 NAT | Int | Int | Priv | Ext | Ext | 954 | VTag | Port | Addr | VTag | Port | 955 +---------+--------+--- -------+----------+--------+ 957 INIT[Initiate-Tag = 1234] 958 10.0.0.1:1 ------> 100.0.0.1:2 959 Ext-VTtag = 0 961 A NAT entry is created, the source address is substituted and the 962 packet is sent on: 964 NAT creates entry: 965 +---------+--------+-----------+----------+--------+ 966 NAT | Int | Int | Priv | Ext | Ext | 967 | VTag | Port | Addr | VTag | Port | 968 +---------+--------+-----------+----------+--------+ 969 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 970 +---------+--------+-----------+----------+--------+ 972 INIT[Initiate-Tag = 1234] 973 101.0.0.1:1 --------------------------> 100.0.0.1:2 974 Ext-VTtag = 0 976 Host B receives the INIT and sends an INIT-ACK with the NAT's 977 external address as destination address. 979 /--\/--\ 980 +--------+ +-----+ / \ +--------+ 981 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 982 +--------+ +-----+ \ / +--------+ 983 \--/\---/ 985 INIT-ACK[Initiate-Tag = 5678] 986 101.0.0.1:1 <------------------------- 100.0.0.1:2 987 Int-VTag = 1234 989 NAT updates entry: 990 +---------+--------+-----------+----------+--------+ 991 NAT | Int | Int | Priv | Ext | Ext | 992 | VTag | Port | Addr | VTag | Port | 993 +---------+--------+-----------+----------+--------+ 994 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 995 +---------+--------+-----------+----------+--------+ 997 INIT-ACK[Initiate-Tag = 5678] 998 10.0.0.1:1 <------ 100.0.0.1:2 999 Int-VTag = 1234 1001 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 1002 ACK. 1004 /--\/--\ 1005 +--------+ +-----+ / \ +--------+ 1006 | Host A | <------> | NAT | <------> | Internet | <------> | Host B | 1007 +--------+ +-----+ \ / +--------+ 1008 \--/\---/ 1010 COOKIE-ECHO 1011 10.0.0.1:1 ------> 100.0.0.1:2 1012 Ext-VTag = 5678 1014 COOKIE-ECHO 1015 101.0.0.1:1 -------------------------> 100.0.0.1:2 1016 Ext-VTag = 5678 1018 COOKIE-ACK 1019 101.0.0.1:1 <------------------------- 100.0.0.1:2 1020 Int-VTag = 1234 1022 COOKIE-ACK 1023 10.0.0.1:1 <------ 100.0.0.1:2 1024 Int-VTag = 1234 1026 7.2. Single-homed Client to Multi-homed Server 1028 The internal client is single-homed whereas the external server is 1029 multi-homed. The client (Host A) sends an INIT like in the single- 1030 homed case. 1032 +--------+ 1033 /--\/--\ /-|Router 1| \ 1034 +------+ +-----+ / \ / +--------+ \ +------+ 1035 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1036 | A | +-----+ \ / \ +--------+ / | B | 1037 +------+ \--/\--/ \-|Router 2|-/ +------+ 1038 +--------+ 1040 +---------+--------+-----------+----------+--------+ 1041 NAT | Int | Int | Priv | Ext | Ext | 1042 | VTag | Port | Addr | VTag | Port | 1043 +---------+--------+-----------+----------+--------+ 1045 INIT[Initiate-Tag = 1234] 1046 10.0.0.1:1 ---> 100.0.0.1:2 1047 Ext-VTag = 0 1049 NAT creates entry: 1051 +---------+--------+-----------+----------+--------+ 1052 NAT | Int | Int | Priv | Ext | Ext | 1053 | VTag | Port | Addr | VTag | Port | 1054 +---------+--------+-----------+----------+--------+ 1055 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 1056 +---------+--------+-----------+----------+--------+ 1058 INIT[Initiate-Tag = 1234] 1059 101.0.0.1:1 ----------------------------> 100.0.0.1:2 1060 Ext-VTag = 0 1062 The server (Host B) includes its two addresses in the INIT-ACK chunk, 1063 which results in two NAT entries. 1065 +--------+ 1066 /--\/--\ /-|Router 1| \ 1067 +------+ +-----+ / \ / +--------+ \ +------+ 1068 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1069 | A | +-----+ \ / \ +--------+ / | B | 1070 +------+ \--/\--/ \-|Router 2|-/ +------+ 1071 +--------+ 1073 INIT-ACK[Initiate-tag = 5678, IP-Addr = 100.1.0.1] 1074 101.0.0.1:1 <---------------------------- 100.0.0.1:2 1075 Int-VTag = 1234 1077 NAT does need to change the table for second address: 1079 +---------+--------+-----------+----------+--------+ 1080 NAT | Int | Int | Priv | Ext | Ext | 1081 | VTag | Port | Addr | VTag | Port | 1082 +---------+--------+-----------+----------+--------+ 1083 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 1084 +---------+--------+-----------+----------+--------+ 1086 INIT-ACK[Initiate-Tag = 5678] 1087 10.0.0.1:1 <--- 100.0.0.1:2 1088 Int-VTag = 1234 1090 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 1091 ACK. 1093 +--------+ 1094 /--\/--\ /-|Router 1| \ 1095 +------+ +-----+ / \ / +--------+ \ +------+ 1096 | Host | <-----> | NAT | <-> | Internet | == =| Host | 1097 | A | +-----+ \ / \ +--------+ / | B | 1098 +------+ \--/\--/ \-|Router 2|-/ +------+ 1099 +--------+ 1101 COOKIE-ECHO 1102 10.0.0.1:1 ---> 100.0.0.1:2 1103 ExtVTag = 5678 1105 COOKIE-ECHO 1106 101.0.0.1:1 ----------------------------> 100.0.0.1:2 1107 Ext-VTag = 5678 1109 COOKIE-ACK 1110 101.0.0.1:1 <---------------------------- 100.0.0.1:2 1111 Int-VTag = 1234 1113 COOKIE-ACK 1114 10.0.0.1:1 <--- 100.0.0.1:2 1115 Int-VTag = 1234 1117 7.3. Multihomed Client and Server 1119 The client (Host A) sends an INIT to the server (Host B), but does 1120 not include the second address. 1122 +-------+ 1123 /--| NAT 1 |--\ /--\/--\ 1124 +------+ / +-------+ \ / \ +--------+ 1125 | Host |=== ====| Internet |====| Host B | 1126 | A | \ +-------+ / \ / +--------+ 1127 +------+ \--| NAT 2 |--/ \--/\--/ 1128 +-------+ 1130 +---------+--------+-----------+----------+--------+ 1131 NAT 1 | Int | Int | Priv | Ext | Ext | 1132 | VTag | Port | Addr | VTag | Port | 1133 +---------+--------+--- -------+----------+--------+ 1135 INIT[Initiate-Tag = 1234] 1136 10.0.0.1:1 --------> 100.0.0.1:2 1137 Ext-VTag = 0 1139 NAT 1 creates entry: 1141 +---------+--------+-----------+----------+--------+ 1142 NAT 1 | Int | Int | Priv | Ext | Ext | 1143 | VTag | Port | Addr | VTag | Port | 1144 +---------+--------+-----------+----------+--------+ 1145 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 1146 +---------+--------+-----------+----------+--------+ 1148 INIT[Initiate-Tag = 1234] 1149 101.0.0.1:1 -----------------------> 100.0.0.1:2 1150 ExtVTag = 0 1152 Host B includes its second address in the INIT-ACK, which results in 1153 two NAT entries in NAT 1. 1155 +-------+ 1156 /--------| NAT 1 |--------\ /--\/--\ 1157 +------+ / +-------+ \ / \ +--------+ 1158 | Host |=== ====| Internet |===| Host B | 1159 | A | \ +-------+ / \ / +--------+ 1160 +------+ \--------| NAT 2 |--------/ \--/\--/ 1161 +-------+ 1163 INIT-ACK[Initiate-Tag = 5678, IP-Addr = 100.1.0.1] 1164 101.0.0.1:1 <------------------------- 100.0.0.1:2 1165 Int-VTag = 1234 1167 NAT 1 does not need to update the table for second address: 1169 +---------+--------+-----------+----------+--------+ 1170 NAT 1 | Int | Int | Priv | Ext | Ext | 1171 | VTag | Port | Addr | VTag | Port | 1172 +---------+--------+-----------+----------+--------+ 1173 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 1174 +---------+--------+-----------+----------+--------+ 1176 INIT-ACK[Initiate-Tag = 5678] 1177 10.0.0.1:1 <---------100.0.0.1:2 1178 Int-VTag = 1234 1180 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE- 1181 ACK. 1183 +-------+ 1184 /--------| NAT 1 |--------\ /--\/--\ 1185 +------+ / +-------+ \ / \ +--------+ 1186 | Host |=== ====| Internet |===| Host B | 1187 | A | \ +-------+ / \ / +--------+ 1188 +------+ \--------| NAT 2 |--------/ \--/\--/ 1189 +-------+ 1191 COOKIE-ECHO 1192 10.0.0.1:1 --------> 100.0.0.1:2 1193 Ext-VTag = 5678 1195 COOKIE-ECHO 1196 101.0.0.1:1 --------------------> 100.0.0.1:2 1197 Ext-VTag = 5678 1199 COOKIE-ACK 1200 101.0.0.1:1 <-------------------- 100.0.0.1:2 1201 Int-VTag = 1234 1203 COOKIE-ACK 1204 10.0.0.1:1 <------- 100.0.0.1:2 1205 Int-VTag = 1234 1207 Host A announces its second address in an ASCONF chunk. The address 1208 parameter contains an undefined address (0) to indicate that the 1209 source address should be added. The lookup address parameter within 1210 the ASCONF chunk will also contain the pair of VTags (external and 1211 internal) so that the NAT may populate its table completely with this 1212 single packet. 1214 +-------+ 1215 /--------| NAT 1 |--------\ /--\/--\ 1216 +------+ / +-------+ \ / \ +--------+ 1217 | Host |=== ====| Internet |===| Host B | 1218 | A | \ +-------+ / \ / +--------+ 1219 +------+ \--------| NAT 2 |--------/ \--/\--/ 1220 +-------+ 1222 ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Ext-VTag = 5678] 1223 10.1.0.1:1 --------> 100.1.0.1:2 1224 Ext-VTag = 5678 1226 NAT 2 creates complete entry: 1228 +---------+--------+-----------+----------+--------+ 1229 NAT 2 | Int | Int | Priv | Ext | Ext | 1230 | VTag | Port | Addr | VTag | Port | 1231 +---------+--------+-----------+----------+--------+ 1232 | 1234 | 1 | 10.1.0.1 | 5678 | 2 | 1233 +---------+--------+-----------+----------+--------+ 1235 ASCONF [ADD-IP,Int-VTag=1234, Ext-VTag = 5678] 1236 101.1.0.1:1 -----------------------> 100.1.0.1:2 1237 Ext-VTag = 5678 1239 ASCONF-ACK 1240 101.1.0.1:1 <----------------------- 100.1.0.1:2 1241 Int-VTag = 1234 1243 ASCONF-ACK 1244 10.1.0.1:1 <----- 100.1.0.1:2 1245 Int-VTag = 1234 1247 7.4. NAT Loses Its State 1249 Association is already established between Host A and Host B, when 1250 the NAT loses its state and obtains a new public address. Host A 1251 sends a DATA chunk to Host B. 1253 /--\/--\ 1254 +--------+ +-----+ / \ +--------+ 1255 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1256 +--------+ +-----+ \ / +--------+ 1257 \--/\--/ 1259 +---------+--------+-----------+----------+--------+ 1260 NAT | Int | Int | Priv | Ext | Ext | 1261 | VTag | Port | Addr | VTag | Port | 1262 +---------+--------+-----------+----------+--------+ 1263 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 1264 +---------+--------+-----------+----------+--------+ 1266 DATA 1267 10.0.0.1:1 ----------> 100.0.0.1:2 1268 Ext-VTag = 5678 1270 The NAT box cannot find entry for the association. It sends ERROR 1271 message with the M-Bit set and the cause "NAT state missing". 1273 /--\/--\ 1274 +--------+ +-----+ / \ +--------+ 1275 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1276 +--------+ +-----+ \ / +--------+ 1277 \--/\--/ 1279 ERROR [M-Bit, NAT state missing] 1280 10.0.0.1:1 <---------- 100.0.0.1:2 1281 Ext-VTag = 5678 1283 On reception of the ERROR message, Host A sends an ASCONF chunk 1284 indicating that the former information has to be deleted and the 1285 source address of the actual packet added. 1287 /--\/--\ 1288 +--------+ +-----+ / \ +--------+ 1289 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1290 +--------+ +-----+ \ / +--------+ 1291 \--/\--/ 1293 ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] 1294 10.0.0.1:1 ----------> 100.1.0.1:2 1295 Ext-VTag = 5678 1297 +---------+--------+-----------+----------+--------+ 1298 NAT | Int | Int | Priv | Ext | Ext | 1299 | VTag | Port | Addr | VTag | Port | 1300 +---------+--------+-----------+----------+--------+ 1301 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 1302 +---------+--------+-----------+----------+--------+ 1304 ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] 1305 102.1.0.1:1 ---------------------> 100.1.0.1:2 1306 Ext-VTag = 5678 1308 Host B adds the new source address and deletes all former entries. 1310 /--\/--\ 1311 +--------+ +-----+ / \ +--------+ 1312 | Host A | <----------> | NAT | <----> | Internet | <----> | Host B | 1313 +--------+ +-----+ \ / +--------+ 1314 \--/\--/ 1316 ASCONF-ACK 1317 102.1.0.1:1 <--------------------- 100.1.0.1:2 1318 Int-VTag = 1234 1320 ASCONF-ACK 1321 10.1.0.1:1 <---------- 100.1.0.1:2 1322 Int-VTag = 1234 1324 DATA 1325 10.0.0.1:1 ----------> 100.0.0.1:2 1326 Ext-VTag = 5678 1327 DATA 1328 102.1.0.1:1 ---------------------> 100.1.0.1:2 1329 Ext-VTag = 5678 1331 7.5. Peer-to-Peer Communication 1333 If two hosts are behind NATs, they have to get knowledge of the 1334 peer's public address. This can be achieved with a so-called 1335 rendezvous server. Afterwards the destination addresses are public, 1336 and the association is set up with the help of the INIT collision. 1337 The NAT boxes create their entries according to their internal peer's 1338 point of view. Therefore, NAT A's Internal-VTag and Internal-Port 1339 are NAT B's External-VTag and External-Port, respectively. The 1340 naming of the verification tag in the packet flow is done from the 1341 sending peer's point of view. 1343 Internal | External External | Internal 1344 | | 1345 | /--\/---\ | 1346 +--------+ +-------+ / \ +-------+ +--------+ 1347 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1348 +--------+ +-------+ \ / +-------+ +--------+ 1349 | \--/\---/ | 1351 NAT-Tables 1352 +---------+--------+-----------+----------+--------+ 1353 NAT A | Int | Int | Priv | Ext | Ext | 1354 | VTag | Port | Addr | VTag | Port | 1355 +---------+--------+--- -------+----------+--------+ 1357 +---------+--------+-----------+----------+--------+ 1358 NAT B | Int | Int | Priv | Ext | Ext | 1359 | v-tag | port | addr | v-tag | port | 1360 +---------+--------+--- -------+----------+--------+ 1362 INIT[Initiate-Tag = 1234] 1363 10.0.0.1:1 --> 100.0.0.1:2 1364 Ext-VTag = 0 1366 NAT A creates entry: 1368 +---------+--------+-----------+----------+--------+ 1369 NAT A | Int | Int | Priv | Ext | Ext | 1370 | VTag | Port | Addr | VTag | Port | 1371 +---------+--------+-----------+----------+--------+ 1372 | 1234 | 1 | 10.0.0.1 | 0 | 2 | 1373 +---------+--------+-----------+----------+--------+ 1375 INIT[Initiate-Tag = 1234] 1376 101.0.0.1:1 ----------------> 100.0.0.1:2 1377 Ext-VTag = 0 1379 NAT B processes INIT, but cannot find an entry. The SCTP packet is 1380 silently discarded and leaves the NAT table of NAT B unchanged. 1382 +---------+--------+-----------+----------+--------+ 1383 NAT B | Int | Int | Priv | Ext | Ext | 1384 | VTag | Port | Addr | VTag | Port | 1385 +---------+--------+-----------+----------+--------+ 1387 Now Host B sends INIT, which is processed by NAT B. Its parameters 1388 are used to create an entry. 1390 Internal | External External | Internal 1391 | | 1392 | /--\/---\ | 1393 +--------+ +-------+ / \ +-------+ +--------+ 1394 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1395 +--------+ +-------+ \ / +-------+ +--------+ 1396 | \--/\---/ | 1398 INIT[Initiate-Tag = 5678] 1399 101.0.0.1:1 <-- 10.1.0.1:2 1400 Ext-VTag = 0 1402 +---------+--------+-----------+----------+--------+ 1403 NAT B | Int | Int | Priv | Ext | Ext | 1404 | VTag | Port | Addr | VTag | Port | 1405 +---------+--------+-----------+----------+--------+ 1406 | 5678 | 2 | 10.1.0.1 | 0 | 1 | 1407 +---------+--------+-----------+----------+--------+ 1409 INIT[Initiate-Tag = 5678] 1410 101.0.0.1:1 <--------------- 100.0.0.1:2 1411 Ext-VTag = 0 1413 NAT A processes INIT. As the outgoing INIT of Host A has already 1414 created an entry, the entry is found and updated: 1416 Internal | External External | Internal 1417 | | 1418 | /--\/---\ | 1419 +--------+ +-------+ / \ +-------+ +--------+ 1420 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1421 +--------+ +-------+ \ / +-------+ +--------+ 1422 | \--/\---/ | 1424 VTag != Int-VTag, but Ext-VTag == 0, find entry. 1425 +---------+--------+-----------+----------+--------+ 1426 NAT A | Int | Int | Priv | Ext | Ext | 1427 | VTag | Port | Addr | VTag | Port | 1428 +---------+--------+-----------+----------+--------+ 1429 | 1234 | 1 | 10.0.0.1 | 5678 | 2 | 1430 +---------+--------+-----------+----------+--------+ 1432 INIT[Initiate-tag = 5678] 1433 10.0.0.1:1 <-- 100.0.0.1:2 1434 Ext-VTag = 0 1436 Host A send INIT-ACK, which can pass through NAT B: 1438 Internal | External External | Internal 1439 | | 1440 | /--\/---\ | 1441 +--------+ +-------+ / \ +-------+ +--------+ 1442 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1443 +--------+ +-------+ \ / +-------+ +--------+ 1444 | \--/\---/ | 1446 INIT-ACK[Initiate-Tag = 1234] 1447 10.0.0.1:1 -->; 100.0.0.1:2 1448 Ext-VTag = 5678 1450 INIT-ACK[Initiate-Tag = 1234] 1451 101.0.0.1:1 ----------------> 100.0.0.1:2 1452 Ext-VTag = 5678 1454 NAT B updates entry: 1456 +---------+--------+-----------+----------+--------+ 1457 NAT B | Int | Int | Priv | Ext | Ext | 1458 | VTag | Port | Addr | VTag | Port | 1459 +---------+--------+-----------+----------+--------+ 1460 | 5678 | 2 | 10.1.0.1 | 1234 | 1 | 1461 +---------+--------+-----------+----------+--------+ 1463 INIT-ACK[Initiate-Tag = 1234] 1464 101.0.0.1:1 --> 10.1.0.1:2 1465 Ext-VTag = 5678 1467 The lookup for COOKIE-ECHO and COOKIE-ACK is successful. 1469 Internal | External External | Internal 1470 | | 1471 | /--\/---\ | 1472 +--------+ +-------+ / \ +-------+ +--------+ 1473 | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | 1474 +--------+ +-------+ \ / +-------+ +--------+ 1475 | \--/\---/ | 1477 COOKIE-ECHO 1478 101.0.0.1:1 <-- 10.1.0.1:2 1479 Ext-VTag = 1234 1481 COOKIE-ECHO 1482 101.0.0.1:1 <------------- 100.0.0.1:2 1483 Ext-VTag = 1234 1485 COOKIE-ECHO 1486 10.0.0.1:1 <-- 100.0.0.1:2 1487 Ext-VTag = 1234 1489 COOKIE-ACK 1490 10.0.0.1:1 --> 100.0.0.1:2 1491 Ext-VTag = 5678 1493 COOKIE-ACK 1494 101.0.0.1:1 ----------------> 100.0.0.1:2 1495 Ext-VTag = 5678 1497 COOKIE-ACK 1498 101.0.0.1:1 --> 10.1.0.1:2 1499 Ext-VTag = 5678 1501 8. Socket API Considerations 1503 This section describes how the socket API defined in [RFC6458] is 1504 extended to provide a way for the application to control NAT 1505 friendliness. 1507 Please note that this section is informational only. 1509 A socket API implementation based on [RFC6458] is extended by 1510 supporting one new read/write socket option. 1512 8.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) 1514 This socket option uses the option_level IPPROTO_SCTP and the 1515 option_name SCTP_NAT_FRIENDLY. It can be used to enable/disable the 1516 NAT friendliness for future associations and retrieve the value for 1517 future and specific ones. 1519 struct sctp_assoc_value { 1520 sctp_assoc_t assoc_id; 1521 uint32_t assoc_value; 1522 }; 1524 assoc_id: This parameter is ignored for one-to-one style sockets. 1525 For one-to-many style sockets the application may fill in an 1526 association identifier or SCTP_FUTURE_ASSOC for this query. It is 1527 an error to use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 1529 assoc_value: A non-zero value indicates a NAT-friendly mode. 1531 9. IANA Considerations 1533 [NOTE to RFC-Editor: 1535 "RFCXXXX" is to be replaced by the RFC number you assign this 1536 document. 1538 ] 1540 [NOTE to RFC-Editor: 1542 The suggested values for the chunk type and the chunk parameter 1543 types are tentative and to be confirmed by IANA. 1545 ] 1547 This document (RFCXXXX) is the reference for all registrations 1548 described in this section. The suggested changes are described 1549 below. 1551 9.1. New Chunk Flags for Two Existing Chunk Types 1553 As defined in [RFC6096] two chunk flags have to be assigned by IANA 1554 for the ERROR chunk. The suggested value for the T bit is 0x01 and 1555 for the M bit is 0x02. 1557 This requires an update of the "ERROR Chunk Flags" registry for SCTP: 1559 ERROR Chunk Flags 1561 +------------------+-----------------+-----------+ 1562 | Chunk Flag Value | Chunk Flag Name | Reference | 1563 +------------------+-----------------+-----------+ 1564 | 0x01 | T bit | [RFCXXXX] | 1565 | 0x02 | M bit | [RFCXXXX] | 1566 | 0x04 | Unassigned | | 1567 | 0x08 | Unassigned | | 1568 | 0x10 | Unassigned | | 1569 | 0x20 | Unassigned | | 1570 | 0x40 | Unassigned | | 1571 | 0x80 | Unassigned | | 1572 +------------------+-----------------+-----------+ 1574 As defined in [RFC6096] one chunk flag has to be assigned by IANA for 1575 the ABORT chunk. The suggested value of the M bit is 0x02. 1577 This requires an update of the "ABORT Chunk Flags" registry for SCTP: 1579 ABORT Chunk Flags 1581 +------------------+-----------------+-----------+ 1582 | Chunk Flag Value | Chunk Flag Name | Reference | 1583 +------------------+-----------------+-----------+ 1584 | 0x01 | T bit | [RFC4960] | 1585 | 0x02 | M bit | [RFCXXXX] | 1586 | 0x04 | Unassigned | | 1587 | 0x08 | Unassigned | | 1588 | 0x10 | Unassigned | | 1589 | 0x20 | Unassigned | | 1590 | 0x40 | Unassigned | | 1591 | 0x80 | Unassigned | | 1592 +------------------+-----------------+-----------+ 1594 9.2. Three New Error Causes 1596 Three error causes have to be assigned by IANA. It is suggested to 1597 use the values given below. 1599 This requires three additional lines in the "Error Cause Codes" 1600 registry for SCTP: 1602 Error Cause Codes 1604 +-------+--------------------------------+-----------+ 1605 | Value | Cause Code | Reference | 1606 +-------+--------------------------------+-----------+ 1607 | 176 | VTag and Port Number Collision | [RFCXXXX] | 1608 | 177 | Missing State | [RFCXXXX] | 1609 | 178 | Port Number Collision | [RFCXXXX] | 1610 +-------+--------------------------------+-----------+ 1612 9.3. Two New Chunk Parameter Types 1614 Two chunk parameter types have to be assigned by IANA. It is 1615 suggested to use the values given below. IANA should assign these 1616 values from the pool of parameters with the upper two bits set to 1617 '11'. 1619 This requires two additional lines in the "Chunk Parameter Types" 1620 registry for SCTP: 1622 Chunk Parameter Types 1624 +----------+--------------------------+-----------+ 1625 | ID Value | Chunk Parameter Type | Reference | 1626 +----------+--------------------------+-----------+ 1627 | 49159 | Disable Restart (0xC007) | [RFCXXXX] | 1628 | 49160 | VTags (0xC008) | [RFCXXXX] | 1629 +----------+--------------------------+-----------+ 1631 10. Security Considerations 1633 State maintenance within a NAT is always a subject of possible Denial 1634 Of Service attacks. This document recommends that at a minimum a NAT 1635 runs a timer on any SCTP state so that old association state can be 1636 cleaned up. 1638 For SCTP end-points, this document does not add any additional 1639 security considerations to the ones given in [RFC4960], [RFC4895], 1640 and [RFC5061]. 1642 11. Acknowledgments 1644 The authors wish to thank Jason But, Bryan Ford, David Hayes, Alfred 1645 Hines, Henning Peters, Timo Voelker, Dan Wing, and Qiaobing Xie for 1646 their invaluable comments. 1648 12. References 1650 12.1. Normative References 1652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1653 Requirement Levels", BCP 14, RFC 2119, March 1997. 1655 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1656 "Authenticated Chunks for the Stream Control Transmission 1657 Protocol (SCTP)", RFC 4895, August 2007. 1659 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 1660 4960, September 2007. 1662 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1663 Kozuka, "Stream Control Transmission Protocol (SCTP) 1664 Dynamic Address Reconfiguration", RFC 5061, September 1665 2007. 1667 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 1668 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 1669 January 2011. 1671 12.2. Informative References 1673 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1674 793, September 1981. 1676 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1677 Yasevich, "Sockets API Extensions for the Stream Control 1678 Transmission Protocol (SCTP)", RFC 6458, December 2011. 1680 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 1681 "Special-Purpose IP Address Registries", BCP 153, RFC 1682 6890, April 2013. 1684 Authors' Addresses 1686 Randall R. Stewart 1687 Netflix, Inc. 1688 Chapin, SC 29036 1689 US 1691 Email: randall@lakerest.net 1692 Michael Tuexen 1693 Muenster University of Applied Sciences 1694 Stegerwaldstrasse 39 1695 48565 Steinfurt 1696 DE 1698 Email: tuexen@fh-muenster.de 1700 Irene Ruengeler 1701 Muenster University of Applied Sciences 1702 Stegerwaldstrasse 39 1703 48565 Steinfurt 1704 DE 1706 Email: i.ruengeler@fh-muenster.de