RFC 6096

Stream Control Transmission Protocol (SCTP) Chunk Flags Registration

πŸ“… published January 2011, from ietf

RFC 6096: Stream Control Transmission Protocol (SCTP) Chunk Flags Registration πŸ’–

Okay bestie, this one is from the IETF (Internet Engineering Task Force) and it's on the Standards Track ✨ It was published in January 2011 (ISSN 2070-1721). It's written by M. Tuexen (Muenster Univ. of Applied Sciences) and R. Stewart (Huawei), and it updates RFC 4960 πŸ¦‹ It's part 1 of 2, so let's get into it πŸŽ€

Abstract 🌸

Okay so this doc is all about how to register chunk flags with the Internet Assigned Numbers Authority (IANA) for SCTP (Stream Control Transmission Protocol) πŸ’… It updates RFC 4960 and also sets up the IANA registry for the contents of the chunk types that are currently defined. It does not change SCTP in any other way, periodt 🫢

Status of This Memo 🧚

This is an Internet Standards Track document πŸ”₯

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 πŸ“š

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6096 πŸ’œ

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved πŸ’–

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please actually read these, bestie, because they describe your rights and restrictions for this document πŸ™ˆ Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ✨

Table of Contents πŸ“

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Updated IETF-Defined Chunk Extension  . . . . . . . . . . . 3
     3.2.  New IETF Chunk Flags Registration . . . . . . . . . . . . . 4
     3.3.  Initial Registrations . . . . . . . . . . . . . . . . . . . 4
       3.3.1.  DATA Chunk Flags  . . . . . . . . . . . . . . . . . . . 4
       3.3.2.  INIT Chunk Flags  . . . . . . . . . . . . . . . . . . . 5
       3.3.3.  INIT ACK Chunk Flags  . . . . . . . . . . . . . . . . . 5
       3.3.4.  SACK Chunk Flags  . . . . . . . . . . . . . . . . . . . 5
       3.3.5.  HEARTBEAT Chunk Flags . . . . . . . . . . . . . . . . . 5
       3.3.6.  HEARTBEAT ACK Chunk Flags . . . . . . . . . . . . . . . 5
       3.3.7.  ABORT Chunk Flags . . . . . . . . . . . . . . . . . . . 5
       3.3.8.  SHUTDOWN Chunk Flags  . . . . . . . . . . . . . . . . . 5
       3.3.9.  SHUTDOWN ACK Chunk Flags  . . . . . . . . . . . . . . . 6
       3.3.10. ERROR Chunk Flags . . . . . . . . . . . . . . . . . . . 6
       3.3.11. COOKIE ECHO Chunk Flags . . . . . . . . . . . . . . . . 6
       3.3.12. COOKIE ACK Chunk Flags  . . . . . . . . . . . . . . . . 6
       3.3.13. ECNE Chunk Flags  . . . . . . . . . . . . . . . . . . . 6
       3.3.14. CWR Chunk Flags . . . . . . . . . . . . . . . . . . . . 6
       3.3.15. SHUTDOWN COMPLETE Chunk Flags . . . . . . . . . . . . . 6
       3.3.16. AUTH Chunk Flags  . . . . . . . . . . . . . . . . . . . 7
       3.3.17. ASCONF ACK Chunk Flags  . . . . . . . . . . . . . . . . 7
       3.3.18. PAD Chunk Flags . . . . . . . . . . . . . . . . . . . . 7
       3.3.19. FORWARD TSN Chunk Flags . . . . . . . . . . . . . . . . 7
       3.3.20. ASCONF Chunk Flags  . . . . . . . . . . . . . . . . . . 7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8

1. Introduction ✨

Okay so [RFC4960] is the one that defines SCTP right now, and it gives a procedure for defining new chunk types πŸ’… The problem is that a bunch of protocol extensions being discussed right now need to define new chunk flags for chunks that already exist, and RFC 4960 doesn't cover that 😭

This document updates RFC 4960 to fix that limitation πŸ¦‹ It defines the procedure for registering chunk flags and specifies the registry entries for the chunk types that already exist. The protocol isn't changed in any other way, so only Section 14.1 of [RFC4960] is affected 🫢

2. Conventions πŸŽ€

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] πŸ’–

3. IANA Considerations 🌸

Section 3.1 gives the updated procedure for SCTP Chunk Type registration, and it replaces Section 14.1 of [RFC4960] πŸ’œ

Section 3.2 gives a brand new procedure for SCTP Chunk Flag registration. A registry entry must be created for each SCTP Chunk Type ✨

Section 3.3 gives the SCTP Chunk Flag registry values for the SCTP Chunk Types specified in [RFC3758], [RFC4820], [RFC4960], [RFC4895], and [RFC5061] 🧚

3.1. Updated IETF-Defined Chunk Extension πŸ“

New chunk type codes get assigned through an IETF Review action, as defined in [RFC5226]. Documentation of a new chunk MUST contain the following information:

a) A long and short name for the new chunk type;

b) A detailed description of the structure of the chunk, which MUST conform to the basic structure defined in Section 3.2 of [RFC4960];

c) A detailed definition and description of intended use of each field within the chunk, including the chunk flags if any. Defined chunk flags will be used as initial entries in the chunk flags table for the new chunk type;

d) A detailed procedural description of the use of the new chunk type within the operation of the protocol.

The last chunk type (255) is reserved for future extension if necessary 🌈

For each new chunk type, IANA creates a registration table for the chunk flags of that type. The procedure for registering particular chunk flags is described in the following Section 3.2 πŸ¦‹

3.2. New IETF Chunk Flags Registration πŸ”₯

New chunk flags get assigned through an RFC required action, as defined in [RFC5226]. Documentation of the chunk flags MUST contain the following information:

a) A name for the new chunk flag;

b) A detailed procedural description of the use of the new chunk flag within the operation of the protocol. It MUST be considered that implementations not supporting the flag will send '0' on transmit and just ignore it on receipt.

IANA selects a chunk flags value. This must be one of 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within the chunk flag values for the specific chunk type πŸ‘‘

3.3. Initial Registrations πŸŽ€

This section lays out the starting values of the chunk flag tables, with one table for each chunk. Most of the tables are empty right now. IANA used these values to create the new registry πŸ’…

3.3.1. DATA Chunk Flags ✨

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+
            | 0x01             | E bit           | [RFC4960] |
            | 0x02             | B bit           | [RFC4960] |
            | 0x04             | U bit           | [RFC4960] |
            +------------------+-----------------+-----------+

3.3.2. INIT Chunk Flags πŸ¦‹

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.3. INIT ACK Chunk Flags 🌸

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.4. SACK Chunk Flags πŸ’œ

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.5. HEARTBEAT Chunk Flags 🧚

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.6. HEARTBEAT ACK Chunk Flags πŸ“

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.7. ABORT Chunk Flags 🌈

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+
            | 0x01             | T bit           | [RFC4960] |
            +------------------+-----------------+-----------+

3.3.8. SHUTDOWN Chunk Flags πŸ”₯

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.9. SHUTDOWN ACK Chunk Flags πŸ‘‘

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.10. ERROR Chunk Flags πŸŽ€

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+
            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+
            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.13. ECNE Chunk Flags πŸ¦‹

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.14. CWR Chunk Flags 🌸

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.15. SHUTDOWN COMPLETE Chunk Flags πŸ’œ

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+
            | 0x01             | T bit           | [RFC4960] |
            +------------------+-----------------+-----------+

3.3.16. AUTH Chunk Flags 🧚

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.17. ASCONF ACK Chunk Flags πŸ“

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.18. PAD Chunk Flags 🌈

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+

3.3.19. FORWARD TSN Chunk Flags πŸ¦‹

Okay so this one's a little plain, bestie, because it has no flags defined yet. The table is just the header row, empty and waiting for its moment πŸ’…

+------------------+-----------------+-----------+
| Chunk Flag Value | Chunk Flag Name | Reference |
+------------------+-----------------+-----------+

3.3.20. ASCONF Chunk Flags πŸŽ€

Same energy here, babe. The ASCONF chunk's flag table is empty too, just the header row sitting pretty ✨

+------------------+-----------------+-----------+
| Chunk Flag Value | Chunk Flag Name | Reference |
+------------------+-----------------+-----------+

4. Security Considerations πŸ”

Okay, security time, and I'm being serious for a sec 🫢 This document doesn't add any new security considerations. Everything you need to think about is already covered in [RFC4960], so go read that one too. No cap, it's the main event for security here πŸ’œ

5. Acknowledgments 🌸

The authors want to give a huge thank-you to Anna Brunstroem, Gorry Fairhurst, Russ Housley, Suresh Krishnan, and Dan Romascanu for their invaluable comments. They're literally the ones who made this doc better, so give them all the love πŸ’–

6. Normative References ✨

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
  • [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007.
  • [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
  • [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
  • [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

Authors' Addresses πŸ’Œ

Michael Tuexen, the Muenster one 🌈:

Michael Tuexen
Muenster University of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
DE

EMail: tuexen@fh-muenster.de

Randall R. Stewart, the Huawei one πŸ’œ:

Randall R. Stewart
Huawei
Chapin, SC  29036
US

EMail: randall@lakerest.net
πŸ“¦ where this page comes from