The Datagram Congestion Control Protocol (DCCP) Service Codes
updated by
- rfc-6335 — Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
updates
- rfc-4340 — Datagram Congestion Control Protocol (DCCP)
Extracted elements (27)
A 32-bit Service Code was chosen instead of a 32-bit port space because overhead was a concern for low-rate applications; placing the value only in the DCCP-Request packet adds no per-packet overhead to the data flow while still giving middleboxes and endpoints enough information to identify the intended service.
An early DCCP design used the Service Code as the sole socket identifier at the server, eliminating traditional ports entirely. This was abandoned because it prevented two server instances for the same service on one host and raised concerns about compatibility with NATs and other middleboxes that understand port-based demultiplexing.
The 16-bit port space is too small for trivial, unregulated allocation; applications collide on unregistered ports and port-based firewalls incentivize disguising traffic. The 32-bit Service Code space is large enough that every application can obtain a unique value easily, decoupling service identification from demultiplexing.
Methods that signal destination port numbers, such as SDP, require an extension to also carry DCCP Service Codes. Existing SDP usage does not convey Service Code information without such an extension.
A client application MUST associate every DCCP connection (and hence every DCCP active socket) with a single Service Code value; this value is used in the corresponding DCCP-Request packet.
A DCCP implementation MUST disallow two server applications from using the same Service Code bound to the same server port simultaneously, since there would be no way to direct a new connection to the correct application.
A middlebox that does not modify the intended application (e.g., NATs and firewalls) MUST NOT change the Service Code.
A middlebox that intends to differentiate applications SHOULD test the Service Code in addition to the destination or source port of a DCCP-Request or DCCP-Response packet.
An implementation SHOULD allow more than one Service Code to be associated with a passive server port, enabling multiple applications or multiple versions of an application to listen on the same port differentiated by Service Code. It SHOULD also provide a method to inform the server of the Service Code selected by an active connection.
Applications SHOULD NOT use a Service Code of zero. Application writers needing a temporary value SHOULD choose a value from the private range; applications intended for Internet deployment are encouraged to request an IANA-assigned Service Code.
Each Registered DCCP port MUST be associated with at least one pre-defined Service Code.
Endpoints MUST associate a Service Code with every DCCP socket, both actively and passively opened. The application generally supplies this Service Code.
If the server port is not associated with the requested Service Code, the server SHOULD reject the request with a DCCP-Reset using Reset Code 8 ('Bad Service Code'), but MAY use 'Connection Refused' instead.
Implementations MUST NOT accept a DCCP-Request carrying the invalid Service Code value 4294967295 (0xFFFFFFFF), and SHOULD NOT allow applications to bind to this value.
New versions of applications/protocols that include version negotiation SHOULD continue to use the same Service Code. They MAY allocate a new Service Code if significant new capabilities warrant it; if that new code is associated with a Well Known or Registered port, the DCCP Ports registry MUST be updated.
When a DCCP-Request arrives for a destination port not bound to any server, the host MUST reject the connection by issuing a DCCP-Reset with Reset Code 'Connection Refused'. A host MAY also use Reset Code 'Too Busy'.
A DCCP Service Code is a 4-byte (32-bit) value included in DCCP-Request and DCCP-Response packets that identifies the application-level service to which a client wishes to connect. It is carried only in those two packet types (and potentially new packet types), adding no overhead to the data flow.
A Service Code of zero is permanently reserved and represents the absence of a meaningful Service Code. RFC 4340 permits applications to be associated with it, but RFC 5595 discourages this use.
An optional hash method derives a Dynamic port from a Service Code: s_port = ((sc[0]<<7)^(sc[1]<<5)^(sc[2]<<3)^sc[3]) | 0xC000, with a special case avoiding 0xFFFF. This allows client and server to agree on a port without out-of-band signalling.
Private Service Codes occupy the decimal range 1056964608–1073741823 (32-bit values whose high-order byte equals 63, the ASCII character '?'). They are not centrally allocated and need not follow the ASCII representability requirement.
The Service Code value 4294967295 (0xFFFFFFFF) is defined as 'invalid', providing a special 4-byte sentinel that implementations can use to indicate 'no valid Service Code'. DCCP-Requests carrying this value must be rejected.
IANA maintains the DCCP Port Numbers registry for Well Known (0–1023) and Registered (1024–49151) ports. Each Registered DCCP port must be associated with at least one predefined Service Code; the registry records these associations.
IANA maintains the DCCP Service Codes registry, originally defined in RFC 4340. RFC 5595 does not change the allocation procedures but clarifies that a published RFC is not required to apply for a Service Code; a specification is required only for codes using the restricted ASCII character subset.
A server that responds with a 'Bad Service Code' reset immediately confirms or denies that a particular service is present, which may assist port scanning and reconnaissance. Care is needed when interpreting Service Code-to-service mappings, as a service may use multiple codes or a private code may shadow an IANA-assigned one.
Because Service Codes allow multiple applications to safely share a single server port, port number reuse in DCCP may be more common than in TCP/UDP. Security policies and middlebox rules that rely solely on port numbers may therefore be less effective.
IPsec (all modes) protects the integrity of the DCCP header, including the Service Code. ESP additionally encrypts the Service Code, hiding it from middleboxes. IKEv2 does not currently specify a method to use Service Codes in IPsec security-association setup; firewall and IPsec policies should not rely solely on ports or Service Codes to identify a service.
The Service Code is a 4-byte field represented in one of three forms: a decimal number (canonical), a 4-character ASCII string, or an 8-digit hexadecimal number. All IANA-assigned Service Codes must be representable using a subset of the ASCII character set.