ietf-corpus

rfc-6096

Stream Control Transmission Protocol (SCTP) Chunk Flags Registration

M. Tuexen, R. Stewart
date2011-01 streamIETF areawit wgtsvwg statusPROPOSED STANDARD pages8 canonicalhttps://www.rfc-editor.org/rfc/rfc6096 doi10.17487/RFC6096
This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream Control Transmission Protocol (SCTP). It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types. It does not change SCTP in any other way. [STANDARDS-TRACK]

obsoleted by

updates

Extracted elements (13)

design-rationale §1

RFC 4960 defined a procedure for new chunk types but provided no mechanism to register new chunk flags for existing chunk types. Several protocol extensions under discussion required exactly this capability, motivating RFC 6096 to fill that gap without otherwise changing SCTP.

sctp, registry

interoperability-note §3.2

When defining a new chunk flag, it must be considered that implementations not supporting that flag will send '0' for it on transmit and simply ignore it on receipt. This backward-compatibility constraint is a required part of all chunk flag documentation.

sctp

normative-requirement §3.2 MUST

Assignment of new chunk flags is done through an RFC Required action. Documentation MUST contain a name for the flag and a detailed procedural description of its use, and MUST consider that implementations not supporting the flag will send '0' on transmit and ignore it on receipt.

sctp, registry

normative-requirement §3.1 MUST

Assignment of new SCTP chunk type codes is done through an IETF Review action. Documentation of a new chunk MUST contain: a long and short name, a detailed structural description conforming to RFC 4960 Section 3.2, a detailed definition of each field including chunk flags, and a detailed procedural description of the chunk's use.

sctp, registry

normative-requirement §3.1 REQUIRED

Chunk type value 255 is reserved for future extension and must not be assigned to any new chunk type.

sctp, registry

normative-requirement §3.1 REQUIRED

For each new chunk type, IANA creates a registration table for that chunk type's flags. Defined chunk flags in the new chunk's documentation will serve as initial entries in that table.

sctp, registry

normative-requirement §3.2 MUST

IANA selects the chunk flag value, which MUST be one of 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80 (i.e., a single-bit value), and MUST be unique within the flag values for the specific chunk type.

sctp, registry

registry §3.3.7

ABORT chunk flags registry (initial values): 0x01 = T bit (RFC 4960). All other flag values are unassigned.

sctp, registry

registry §3.3.1

DATA chunk flags registry (initial values): 0x01 = E bit (RFC 4960), 0x02 = B bit (RFC 4960), 0x04 = U bit (RFC 4960). All other flag values are unassigned.

sctp, registry

registry §3.3

RFC 6096 establishes a per-chunk-type IANA registry for SCTP chunk flags, one registry table per chunk type. Initial registries are created for all chunk types defined in RFC 3758, RFC 4820, RFC 4960, RFC 4895, and RFC 5061.

sctp, registry

registry §3.3.15

SHUTDOWN COMPLETE chunk flags registry (initial values): 0x01 = T bit (RFC 4960). All other flag values are unassigned.

sctp, registry

registry §3.3

The following chunk types have initially empty chunk flags registries (no flags defined at time of RFC 6096 publication): INIT, INIT ACK, SACK, HEARTBEAT, HEARTBEAT ACK, SHUTDOWN, SHUTDOWN ACK, ERROR, COOKIE ECHO, COOKIE ACK, ECNE, CWR, AUTH, ASCONF ACK, PAD, FORWARD TSN, ASCONF.

sctp, registry

security-consideration §4

RFC 6096 does not add any security considerations beyond those already given in RFC 4960. The chunk flags registration procedure is purely administrative and does not alter SCTP's security properties.

sctp, security