idnits 2.17.1 draft-ietf-tsvwg-natsupp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC0793], [RFC4960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4399 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: 'RFCXXXX' is mentioned on line 579, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-06 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Adara Networks 4 Intended status: Standards Track M. Tuexen 5 Expires: September 13, 2012 I. Ruengeler 6 Muenster Univ. of Appl. Sciences 7 March 12, 2012 9 Stream Control Transmission Protocol (SCTP) Network Address Translation 10 Support 11 draft-ietf-tsvwg-natsupp-02.txt 13 Abstract 15 Stream Control Transmission Protocol [RFC4960] provides a reliable 16 communications channel between two end-hosts in many ways similar to 17 TCP [RFC0793]. With the widespread deployment of Network Address 18 Translators (NAT), specialized code has been added to NAT for TCP 19 that allows multiple hosts to reside behind a NAT and yet use only a 20 single globally unique IPv4 address, even when two hosts (behind a 21 NAT) choose the same port numbers for their connection. This 22 additional code is sometimes classified as Network Address and Port 23 Translation (NAPT). To date, specialized code for SCTP has not yet 24 been added to most NATs so that only pure NAT is available. The end 25 result of this is that only one SCTP capable host can be behind a 26 NAT. 28 This document describes the protocol extensions required for the SCTP 29 endpoints to help NAT's provide similar features of NAPT in the 30 single-point and multi-point traversal scenario. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 13, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Problem Space Overview . . . . . . . . . . . . . . . . . . . . 5 70 5. Association Setup Considerations . . . . . . . . . . . . . . . 5 71 6. Handling of Internal Port Number and Verification Tag 72 Collisions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 7. Handling of Internal Port Number Collisions . . . . . . . . . 7 74 8. Handling of Missing State . . . . . . . . . . . . . . . . . . 9 75 9. Multi Point Traversal Considerations . . . . . . . . . . . . . 11 76 10. Socket API Considerations . . . . . . . . . . . . . . . . . . 11 77 10.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) . . . 11 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 11.1. New Chunk Flags for Two Chunk Types . . . . . . . . . . . 12 80 11.2. Three New Error Causes . . . . . . . . . . . . . . . . . 13 81 11.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 13 82 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 86 14.2. Informative References . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 Stream Control Transmission Protocol [RFC4960] provides a reliable 92 communications channel between two end-hosts in many ways similar to 93 TCP [RFC0793]. With the widespread deployment of Network Address 94 Translators (NAT), specialized code has been added to NAT for TCP 95 that allows multiple hosts to reside behind a NAT using private 96 addresses (see [RFC5735]) and yet use only a single globally unique 97 IPv4 address, even when two hosts (behind a NAT) choose the same port 98 numbers for their connection. This additional code is sometimes 99 classified as Network Address and Port Translation (NAPT). To date, 100 specialized code for SCTP has not yet been added to most NATs so that 101 only true NAT is available. The end result of this is that only one 102 SCTP capable host can be behind a NAT. 104 This document describes an SCTP specific chunks and procedures to 105 help NAT's provide similar features of NAPT in the single point and 106 multi-point traversal scenario. An SCTP implementation supporting 107 this extension will follow these procedures to assure that in both 108 single homed and multi-homed cases a NAT will maintain the proper 109 state without needing to change port numbers. 111 A NAT will need to follow these procedures for generating appropriate 112 SCTP packet formats. NAT's should refer to [I-D.ietf-behave-sctpnat] 113 for the BCP in using these formats. 115 When considering this feature it is possible to have multiple levels 116 of support. At each level, the Internal Host, External Host and NAT 117 may or may not support the features described in this document. The 118 following table illustrates the results of the various combinations 119 of support and if communications can occur between two endpoints. 121 +---------------+------------+---------------+---------------+ 122 | Internal Host | NAT | External Host | Communication | 123 +---------------+------------+---------------+---------------+ 124 | Support | Support | Support | Yes | 125 | Support | Support | No Support | Limited | 126 | Support | No Support | Support | None | 127 | Support | No Support | No Support | None | 128 | No Support | Support | Support | Limited | 129 | No Support | Support | No Support | Limited | 130 | No Support | No Support | Support | None | 131 | No Support | No Support | No Support | None | 132 +---------------+------------+---------------+---------------+ 134 Table 1: Communication possibilities 136 From the table we can see that when a NAT does not support the 137 extension no communication can occur. This is for the most part the 138 current situation i.e. SCTP packets sent externally from behind a 139 NAT are discarded by the NAT. In some cases, where the NAT supports 140 the feature but one of the two external hosts does not support the 141 feature communication may occur but in a limited way. For example 142 only one host may be able to have a connection when a collision case 143 occurs. 145 2. Conventions 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 3. Terminology 153 This document uses the following terms, which are depicted in 154 Figure 1. 156 Private-Address (Priv-Addr): The private address that is known to 157 the internal host. 159 Internal-Port (Int-Port): The port number that is in use by the host 160 holding the Private-Address. 162 Internal-VTag (Int-VTag): The Verification Tag that the internal 163 host has chosen for its communication. The VTag is a unique 32- 164 bit tag that must accompany any incoming SCTP packet for this 165 association to the Private-Address. 167 External-Address (Ext-Addr): The address that an internal host is 168 attempting to contact. 170 External-Port (Ext-Port): The port number of the peer process at the 171 External-Address. 173 External-VTag (Ext-VTag): The Verification Tag that the host holding 174 the External-Address has chosen for its communication. The VTag 175 is a unique 32-bit tag that must accompany any incoming SCTP 176 packet for this association to the External-Address. 178 Public-Address (Pub-Addr): The public address assigned to the NAT 179 box which it uses as a source address when sending packets towards 180 the External-Address. 182 Internal Network | External Network 183 | 184 Private | Public External 185 +---------+ Address | Address /--\/--\ Address +---------+ 186 | SCTP | +-----+ / \ | SCTP | 187 |end point|=========| NAT |=======| Internet |==========|end point| 188 | A | +-----+ \ / | B | 189 +---------+ Internal | \--/\--/ External+---------+ 190 Internal Port | Port External 191 VTag | VTag 193 Figure 1: Basic network setup 195 4. Problem Space Overview 197 When an SCTP endpoint is behind a NAT which supports 198 [I-D.ietf-behave-sctpnat] a number of problems may arise as it tries 199 to communicate with its peer: 201 o More than one server behind a NAT may pick the same VTag and 202 source port when talking to the same peer server. This creates a 203 situation where the NAT will not be able to tell the two 204 associations apart. This situation is discussed in Section 6. 206 o When an SCTP endpoint is a server and talking with multiple peers 207 and the peers are behind the same NAT, to the server the two 208 endpoints cannot be distinguished. This case is discussed in 209 Section 7. 211 o A NAT could at one point during a conversation restart causing all 212 of its state to be lost. This problem and its solution is 213 discussed in Section 8. 215 o An SCTP endpoint may be behind two NAT's giving it redundancy. 216 The method to set up this scenario is discussed in Section 9. 218 Each of these solutions requires additional chunks and parameters, 219 defined in this document, and possibly modified handling procedures 220 from those specified in [RFC4960]. 222 5. Association Setup Considerations 224 Every association MUST initially be set up single-homed. There MUST 225 NOT be any IPv4 Address parameter, IPv6 Address parameter, or 226 Supported Address Types parameter in the INIT-chunk. The INIT-ACK 227 chunk MUST NOT contain any IPv4 Address parameter or IPv6 Address 228 parameter. 230 If the association should finally be multi-homed, the procedure in 231 Section 9 MUST be used. 233 The INIT and INIT-ACK chunk SHOULD contain the Disable Restart 234 parameter defined in Section 7. 236 6. Handling of Internal Port Number and Verification Tag Collisions 238 Consider the case where two hosts in the Private-Address space want 239 to set up an SCTP association with the same server running on the 240 same host in the Internet. This means that the External-Port and the 241 External-Address are the same. If they both choose the same 242 Internal-Port and Internal-VTag, the NAT box cannot distinguish 243 incoming packets anymore. But this is very unlikely. The Internal- 244 VTags are chosen at random and if the Internal-Ports are also chosen 245 from the ephemeral port range at random this gives a 46-bit random 246 number which has to match. In the TCP like NAPT case the NAT box can 247 control the 16-bit Natted Port. 249 The same can happen when the INIT-ACK is processed by the NAT. 251 However, in this unlikely event the NAT box MUST respond to the INIT 252 chunk by sending an ABORT chunk with the M-bit set. The M-bit is a 253 new bit defined by this document to express to SCTP that the source 254 of this packet is a "middle" box, not the peer SCTP endpoint. The 255 source address of the packet containing the ABORT chunk MUST be the 256 destination address of the SCTP packet containing the INIT chunk. 258 The sender of the packet containing the INIT chunk, upon reception of 259 an ABORT with M-bit set SHOULD reinitiate the association setup 260 procedure after choosing a new initiate tag. These procedures SHOULD 261 be followed only if the appropriate error cause code for colliding 262 NAT table state is included AND the association is in the COOKIE-WAIT 263 state (i.e. it is awaiting a INIT-ACK). If the endpoint is in any 264 other state an SCTP endpoint SHOULD NOT respond. 266 The ABORT chunk defined in [RFC4960] is therefore extended by using 267 the following format: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type = 6 | Reserved |M|T| Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 \ \ 275 / zero or more Error Causes / 276 \ \ 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Extended ABORT chunk 281 The following error cause with cause code 0x00B0 (V-tag and Port 282 Number Collision) MUST be included in the ABORT chunk: 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Cause Code = 0x00B0 | Cause Length = Variable | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 \ INIT chunk / 290 / \ 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 V-tag and Port Number Collision error cause 295 FIXME: What to do when this is collision happens when processing an 296 ASCONF chunk? 298 7. Handling of Internal Port Number Collisions 300 When two SCTP hosts are behind a NAT and using the recommendations in 301 [I-D.ietf-behave-sctpnat] it is possible that two SCTP hosts in the 302 Private-Address space will want to set up an SCTP association with 303 the same server running on the same host in the Internet. For the 304 NAT appropriate tracking may be performed by assuring that the VTags 305 are unique between the two hosts as defined in 306 [I-D.ietf-behave-sctpnat]. But for the external SCTP server on the 307 internet this means that the External-Port and the External-Address 308 are the same. If they both have chosen the same Internal-Port the 309 server cannot distinguish both associations based on the address and 310 port numbers. For the server it looks like the association is being 311 restarted. To overcome this limitation the client sends a Disable 312 Restart parameter in the INIT-chunk which is defined as follows: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type = 0xC007 | Length = 4 | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Disable Restart parameter 322 When the server receives this parameter it MUST do the following: 324 o Include in the INIT-ACK a Disable Restart parameter to inform the 325 client that it will support the feature. 327 o Disable the restart procedures defined in [RFC4960] for this 328 association. 330 Servers that support this feature will need to be capable of 331 maintaining multiple connections to what appears to be the same peer 332 (behind the NAT) differentiated only by the VTags. 334 The NAT, when processing the INIT-ACK, should note in its internal 335 table that the association supports the Disable Restart extension. 336 This note is used when establishing future associations (i.e. when 337 processing an INIT from an internal host) to decide if the connection 338 should be allowed. The NAT MUST do the following when processing an 339 INIT: 341 o If the INIT is destined to an external address and port for which 342 the NAT has no outbound connection, allow the INIT creating an 343 internal mapping table. 345 o If the INIT matches the external address and port of an already 346 existing connection, validate that the external server supports 347 the Disable Restart feature. If it does allow the INIT to be 348 forwarded. 350 o If the external server does not support the Disable Restart 351 extension the NAT MUST send an ABORT with the M-bit set. 353 The following error cause with cause code 0x00B2 (Port Number 354 Collision) MUST be included in the ABORT chunk: 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Cause Code = 0x00B2 | Cause Length = Variable | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 \ INIT chunk / 362 / \ 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Port Number Collision error cause 367 8. Handling of Missing State 369 If the NAT box receives a packet from the internal network for which 370 the lookup procedure does not find an entry in the NAT table, a 371 packet containing an ERROR chunk is sent back with the M-bit set. 372 The source address of the packet containing the ERROR chunk MUST be 373 the destination address of the incoming SCTP packet. The 374 verification tag is reflected and the T-bit is set. Please note that 375 such an packet containing an ERROR chunk SHOULD NOT be sent if the 376 received packet contains an ABORT, SHUTDOWN-COMPLETE or INIT-ACK 377 chunk. 379 The ERROR chunk defined in [RFC4960] is therefore extended by using 380 the following format: 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Type = 9 | Reserved |M|T| Length | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 \ \ 388 / zero or more Error Causes / 389 \ \ 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Extended ERROR chunk 394 The following error cause with cause code 0x00B1 (Missing State) 395 SHOULD be included in the ERROR chunk: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Cause Code = 0x00B1 | Cause Length = Variable | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 \ Incoming Packet / 403 / \ 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Missing State error cause 408 Upon reception by an SCTP end-point with this ERROR chunk the 409 receiver SHOULD take the following actions: 411 o Validate the verification tag is reflected by looking at the VTag 412 that would have been included in the outgoing packet. 414 o Validate that the peer of the SCTP association supports the 415 dynamic address extension, if it does not discard the incoming 416 ERROR chunk. 418 o Generate a new ASCONF chunk containing the V-tags parameter as 419 defined in Figure 2 and the Disable Restart parameter if the 420 association is using the disabled restart feature. By processing 421 this packet the NAT can recover the appropriate state. The 422 procedures for generating an ASCONF chunk can be found in 423 [RFC5061]. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Parameter Type = 0xC008 | Parameter Length = 16 | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | ASCONF-Request Correlation ID | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Internal Verification Tag | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | External Verification Tag | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Figure 2: V-tags parameter 439 If the NAT box receives a packet for which it has no NAT table entry 440 and the packet contains an ASCONF chunk with the V-tags parameter, 441 the NAT box MUST update its NAT table according to the verification 442 tags in the V-tags parameter and the optional Disable Restart 443 parameter. 445 The peer SCTP endpoint receiving such an ASCONF chunk SHOULD either 446 add the address and respond with an acknowledgment, if the address is 447 new to the association (following all procedures defined in 448 [RFC5061]). Or, if the address is already part of the association, 449 the SCTP endpoint MUST NOT respond with an error, but instead should 450 respond with an ASCONF-ACK chunk acknowledging the address but take 451 no action (since the address is already in the association). 453 9. Multi Point Traversal Considerations 455 If a multi-homed SCTP end-point behind a NAT connects to a peer, it 456 SHOULD first set up the association single-homed with only one 457 address causing the first NAT to populate its state. Then it SHOULD 458 add each IP address using ASCONF chunks sent via their respective 459 NATs. The address to add is the wildcard address and the lookup 460 address SHOULD also contain the V-tags parameter and optionally the 461 Disable Restart parameter as illustrated above. 463 10. Socket API Considerations 465 This section describes how the socket API defined in [RFC6458] is 466 extended to provide a way for the application to control NAT 467 friendliness. 469 Please note that this section is informational only. 471 A socket API implementation based on [RFC6458] is extended by 472 supporting one new read/write socket option. 474 10.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) 476 This socket option can be used to set the NAT friendliness for future 477 associations and and retrieve the value for future and current ones. 479 struct sctp_assoc_value { 480 sctp_assoc_t assoc_id; 481 uint32_t assoc_value; 482 }; 484 assoc_id: This parameter is ignored for one-to-one style sockets. 485 For one-to-many style sockets the application may fill in an 486 association identifier or SCTP_FUTURE_ASSOC for this query. It is 487 an error to use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 489 assoc_value: A non-zero value indicates a NAT-friendly mode. 491 11. IANA Considerations 493 [NOTE to RFC-Editor: 495 "RFCXXXX" is to be replaced by the RFC number you assign this 496 document. 498 ] 500 [NOTE to RFC-Editor: 502 The suggested values for the chunk type and the chunk parameter 503 types are tentative and to be confirmed by IANA. 505 ] 507 This document (RFCXXXX) is the reference for all registrations 508 described in this section. The suggested changes are described 509 below. 511 11.1. New Chunk Flags for Two Chunk Types 513 As defined in [RFC6096] two chunk flags have to be assigned by IANA 514 for the ERROR chunk. The suggested value for the T bit is 0x01 and 515 for the M bit is 0x02. 517 This requires an update of the "ERROR Chunk Flags" registry for SCTP: 519 ERROR Chunk Flags 521 Chunk Flag Value Chunk Flag Name Reference 522 0x01 T bit [RFCXXXX] 523 0x02 M Bit [RFCXXXX] 524 0x04 Unassigned 525 0x08 Unassigned 526 0x10 Unassigned 527 0x20 Unassigned 528 0x40 Unassigned 529 0x80 Unassigned 531 As defined in [RFC6096] one chunk flag has to be assigned by IANA for 532 the ABORT chunk. The suggested value of the M bit is 0x02. 534 This requires an update of the "ABORT Chunk Flags" registry for SCTP: 536 ABORT Chunk Flags 538 Chunk Flag Value Chunk Flag Name Reference 539 0x01 T bit [RFC4960] 540 0x02 M Bit [RFCXXXX] 541 0x04 Unassigned 542 0x08 Unassigned 543 0x10 Unassigned 544 0x20 Unassigned 545 0x40 Unassigned 546 0x80 Unassigned 548 11.2. Three New Error Causes 550 Three error causes have to be assigned by IANA. It is suggested to 551 use the values given below. 553 This requires three additional lines in the "Error Cause Codes" 554 registry for SCTP: 556 Chunk Parameter Types 558 Value Cause Code Reference 559 -------- ------------------------------------------------ --------- 560 176 V-tag and Port Number Collision [RFCXXXX] 561 177 Missing State [RFCXXXX] 562 178 Port Number Collision [RFCXXXX] 564 11.3. Two New Chunk Parameter Types 566 Two chunk parameter types have to be assigned by IANA. It is 567 suggested to use the values given below. IANA should assign these 568 values from the pool of parameters with the upper two bits set to 569 '11'. 571 This requires two additional lines in the "Chunk Parameter Types" 572 registry for SCTP: 574 Chunk Parameter Types 576 ID Value Chunk Parameter Type Reference 577 -------- ------------------------------------------------ --------- 578 49159 Disable Restart (0xC007) [RFCXXXX] 579 49160 V-tags (0xC008) [RFCXXXX] 581 12. Security Considerations 583 The document does not add any additional security considerations to 584 the ones given in [RFC4960], [RFC4895], and [RFC5061]. 586 13. Acknowledgments 588 The authors wish to thank Jason But, Bryan Ford, David Hayes, Alfred 589 Hines, Henning Peters, Timo Voelker, Dan Wing, and Qiaobing Xie for 590 their invaluable comments. 592 14. References 594 14.1. Normative References 596 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 597 RFC 793, September 1981. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 603 "Authenticated Chunks for the Stream Control Transmission 604 Protocol (SCTP)", RFC 4895, August 2007. 606 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 607 RFC 4960, September 2007. 609 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 610 Kozuka, "Stream Control Transmission Protocol (SCTP) 611 Dynamic Address Reconfiguration", RFC 5061, 612 September 2007. 614 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 615 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 616 January 2011. 618 14.2. Informative References 620 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 621 BCP 153, RFC 5735, January 2010. 623 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 624 Yasevich, "Sockets API Extensions for the Stream Control 625 Transmission Protocol (SCTP)", RFC 6458, December 2011. 627 [I-D.ietf-behave-sctpnat] 628 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 629 Transmission Protocol (SCTP) Network Address Translation", 630 draft-ietf-behave-sctpnat-06 (work in progress), 631 March 2012. 633 Authors' Addresses 635 Randall R. Stewart 636 Adara Networks 637 Chapin, SC 29036 638 US 640 Email: randall@lakerest.net 642 Michael Tuexen 643 Muenster University of Applied Sciences 644 Stegerwaldstrasse 39 645 48565 Steinfurt 646 DE 648 Email: tuexen@fh-muenster.de 650 Irene Ruengeler 651 Muenster University of Applied Sciences 652 Stegerwaldstrasse 39 653 48565 Steinfurt 654 DE 656 Email: i.ruengeler@fh-muenster.de