Section 19. IANA Considerations

IANA has assigned IP Protocol Number 33 to DCCP.
   DCCP introduces eight sets of numbers whose values should be
   allocated by IANA.  We refer to allocation policies, such as
   Standards Action, outlined in [RFC2434], and most registries reserve
   some values for experimental and testing use [RFC3692].  In addition,
   DCCP requires that the IANA Port Numbers registry be opened for DCCP
   port registrations; Section 19.9 describes how.  The IANA should feel
   free to contact the DCCP Expert Reviewer with questions on any
   registry, regardless of the registry policy, for clarification or if
   there is a problem with a request.
19.1.  Packet Types Registry
   Each entry in the DCCP Packet Types registry contains a packet type,
   which is a number in the range 0-15; a packet type name, such as
   DCCP-Request; and a reference to the RFC defining the packet type.
   The registry is initially populated using the values in Table 1
   (Section 5.1).  This document allocates packet types 0-9, and packet
   type 14 is permanently reserved for experimental and testing use.
   Packet types 10-13 and 15 are currently reserved and should be
   allocated with the Standards Action policy, which requires IESG
   review and approval and standards-track IETF RFC publication.
19.2.  Reset Codes Registry
   Each entry in the DCCP Reset Codes registry contains a Reset Code,
   which is a number in the range 0-255; a short description of the
   Reset Code, such as "No Connection"; and a reference to the RFC
   defining the Reset Code.  The registry is initially populated using
   the values in Table 2 (Section 5.6).  This document allocates Reset
   Codes 0-11, and Reset Codes 120-126 are permanently reserved for
   experimental and testing use.  Reset Codes 12-119 and 127 are
   currently reserved and should be allocated with the IETF Consensus
   policy, requiring an IETF RFC publication (standards track or not)
   with IESG review and approval.  Reset Codes 128-255 are permanently
   reserved for CCID-specific registries; each CCID Profile document
   describes how the corresponding registry is managed.
19.3.  Option Types Registry
   Each entry in the DCCP option types registry contains an option type,
   which is a number in the range 0-255; the name of the option, such as
   "Slow Receiver"; and a reference to the RFC defining the option type.
   The registry is initially populated using the values in Table 3
   (Section 5.8).  This document allocates option types 0-2 and 32-44,
   and option types 31 and 120-126 are permanently reserved for
   experimental and testing use.  Option types 3-30, 45-119, and 127 are
   currently reserved and should be allocated with the IETF Consensus
   policy, requiring an IETF RFC publication (standards track or not)
   with IESG review and approval.  Option types 128-255 are permanently
   reserved for CCID-specific registries; each CCID Profile document
   describes how the corresponding registry is managed.
19.4.  Feature Numbers Registry
   Each entry in the DCCP feature numbers registry contains a feature
   number, which is a number in the range 0-255; the name of the
   feature, such as "ECN Incapable"; and a reference to the RFC defining
   the feature number.  The registry is initially populated using the
   values in Table 4 (Section 6).  This document allocates feature
   numbers 0-9, and feature numbers 120-126 are permanently reserved for
   experimental and testing use.  Feature numbers 10-119 and 127 are
   currently reserved and should be allocated with the IETF Consensus
   policy, requiring an IETF RFC publication (standards track or not)
   with IESG review and approval.  Feature numbers 128-255 are
   permanently reserved for CCID-specific registries; each CCID Profile
   document describes how the corresponding registry is managed.
19.5.  Congestion Control Identifiers Registry
   Each entry in the DCCP Congestion Control Identifiers (CCIDs)
   registry contains a CCID, which is a number in the range 0-255; the
   name of the CCID, such as "TCP-like Congestion Control"; and a
   reference to the RFC defining the CCID.  The registry is initially
   populated using the values in Table 5 (Section 10).  CCIDs 2 and 3
   are allocated by concurrently published profiles, and CCIDs 248-254
   are permanently reserved for experimental and testing use.  CCIDs 0,
   1, 4-247, and 255 are currently reserved and should be allocated with
   the IETF Consensus policy, requiring an IETF RFC publication
   (standards track or not) with IESG review and approval.
19.6.  Ack Vector States Registry
   Each entry in the DCCP Ack Vector States registry contains an Ack
   Vector State, which is a number in the range 0-3; the name of the
   State, such as "Received ECN Marked"; and a reference to the RFC
   defining the State.  The registry is initially populated using the
   values in Table 6 (Section 11.4).  This document allocates States 0,
   1, and 3.  State 2 is currently reserved and should be allocated with
   the Standards Action policy, which requires IESG review and approval
   and standards-track IETF RFC publication.
19.7.  Drop Codes Registry
   Each entry in the DCCP Drop Codes registry contains a Data Dropped
   Drop Code, which is a number in the range 0-7; the name of the Drop
   Code, such as "Application Not Listening"; and a reference to the RFC
   defining the Drop Code.  The registry is initially populated using
   the values in Table 7 (Section 11.7).  This document allocates Drop
   Codes 0-3 and 7.  Drop Codes 4-6 are currently reserved, and should
   be allocated with the Standards Action policy, which requires IESG
   review and approval and standards-track IETF RFC publication.
19.8.  Service Codes Registry
   Each entry in the Service Codes registry contains a Service Code,
   which is a number in the range 0-4294967294; a short English
   description of the intended service; and an optional reference to an
   RFC or other publicly available specification defining the Service
   Code.  The registry should list the Service Code's numeric value as a
   decimal number.  When the Service Code may be represented in "SC:"
   format according to the rules in Section 8.1.2, the registry should
   also show the corresponding ASCII interpretation of the Service Code
   minus the "SC:" prefix.  Thus, the number 1717858426 would
   additionally appear as "fdpz".  Service Codes are not DCCP-specific.
   Service Code 0 is permanently reserved (it represents the absence of
   a meaningful Service Code), and Service Codes 1056964608-1073741823
   (high byte ASCII "?") are reserved for Private Use.  Note that
   4294967295 is not a valid Service Code.  Most of the remaining
   Service Codes are allocated First Come First Served, with no RFC
   publication required; exceptions are listed in Section 8.1.2.  This
   document allocates a single Service Code, 1145656131 ("DISC").  This
   corresponds to the discard service, which discards all data sent to
   the service and sends no data in reply.
19.9.  Port Numbers Registry
   DCCP services may use contact port numbers to provide service to
   unknown callers, as in TCP and UDP.  IANA is therefore requested to
   open the existing Port Numbers registry for DCCP using the following
   rules, which we intend to mesh well with existing Port Numbers
   registration procedures.
   Port numbers are divided into three ranges.  The Well Known Ports are
   those from 0 through 1023, the Registered Ports are those from 1024
   through 49151, and the Dynamic and/or Private Ports are those from
   49152 through 65535.  Well Known and Registered Ports are intended
   for use by server applications that desire a default contact point on
   a system.  On most systems, Well Known Ports can only be used by
   system (or root) processes or by programs executed by privileged
   users, while Registered Ports can be used by ordinary user processes
   or programs executed by ordinary users.  Dynamic and/or Private Ports
   are intended for temporary use, including client-side ports, out-of-
   band negotiated ports, and application testing prior to registration
   of a dedicated port; they MUST NOT be registered.
   The Port Numbers registry should accept registrations for DCCP ports
   in the Well Known Ports and Registered Ports ranges.  Well Known and
   Registered Ports SHOULD NOT be used without registration.  Although
   in some cases -- such as porting an application from UDP to DCCP --
   it may seem natural to use a DCCP port before registration completes,
   we emphasize that IANA will not guarantee registration of particular
   Well Known and Registered Ports.  Registrations should be requested
   as early as possible.
   Each port registration SHALL include the following information:
   o  A short port name, consisting entirely of letters (A-Z and a-z),
      digits (0-9), and punctuation characters from "-_+./*" (not
      including the quotes).
   o  The port number that is requested to be registered.
   o  A short English phrase describing the port's purpose.  This MUST
      include one or more space-separated textual Service Code
      descriptors naming the port's corresponding Service Codes (see
      Section 8.1.2).
   o  Name and contact information for the person or entity performing
      the registration, and possibly a reference to a document defining
      the port's use.  Registrations coming from IETF working groups
      need only name the working group, but indicating a contact person
      is recommended.
   Registrants are encouraged to follow these guidelines when submitting
   a registration.
   o  A port name SHOULD NOT be registered for more than one DCCP port
      number.
   o  A port name registered for UDP MAY be registered for DCCP as well.
      Any such registration SHOULD use the same port number as the
      existing UDP registration.
   o  Concrete intent to use a port SHOULD precede port registration.
      For example, existing UDP ports SHOULD NOT be registered in
      advance of any intent to use those ports for DCCP.
   o  A port name generally associated with TCP and/or SCTP SHOULD NOT
      be registered for DCCP, since that port name implies reliable
      transport.  For example, we discourage registration of any "http"
      port for DCCP.  However, if such a registration makes sense (that
      is, if there is concrete intent to use such a port), the DCCP
      registration SHOULD use the same port number as the existing
      registration.
   o  Multiple DCCP registrations for the same port number are allowed
      as long as the registrations' Service Codes do not overlap.
   This document registers the following port.  (This should be
   considered a model registration.)
   discard    9/dccp    Discard SC:DISC
   # IETF dccp WG, Eddie Kohler <kohler@cs.ucla.edu>, [RFC4340]
   The discard service, which accepts DCCP connections on port 9,
   discards all incoming application data and sends no data in response.
   Thus, DCCP's discard port is analogous to TCP's discard port, and
   might be used to check the health of a DCCP stack.