dccp

Overview ¶

Package dccp decodes DCCP (Datagram Congestion Control Protocol) packets per RFC 4340. DCCP is the niche fourth IP transport — alongside TCP (reliable streams), UDP (unreliable datagrams), and SCTP (reliable streams + multihoming) — designed for applications that want UDP- style unreliable delivery *plus* TCP-style congestion control. The intended use cases are real-time media (voice, video), interactive games, and any traffic where dropping a packet is preferable to retransmitting a stale one.

Operationally, DCCP saw limited deployment compared to the other three transports but remains the IP protocol number 33 wire format that operators occasionally see in:

• **WebRTC SCTP-over-DTLS-over-UDP fallbacks** (when DTLS-SCTP isn't available) where some implementations used DCCP as the lower-overhead transport.
• **Embedded game-server protocols** at smaller publishers that don't want to roll their own congestion control.
• **IETF reference implementations** in research / lab environments studying congestion-control variants (DCCP's CCID negotiation cleanly exposes TCP-like vs TCP-friendly Rate Control as plug-in modules).

Wrap-vs-native judgement

Native. RFC 4340 is fully public. DCCP has a tight
12- or 16-byte fixed header (short vs extended
sequence number; X-bit dispatch) followed by a per-
type body and an optional Options walker. No crypto
at the parse layer.

What this package covers

• **Generic header** (RFC 4340 §5.1, 12 or 16 bytes depending on X bit):

• bytes 0-1: Source Port.

• bytes 2-3: Destination Port.

• byte 4: **Data Offset** (in 4-byte words from the start of the DCCP header to the start of the application data; minimum 3 for short header, 4 for extended).

• byte 5: 4-bit **CCVal** (Congestion Control Value; per-CCID semantics) + 4-bit **CsCov** (Checksum Coverage; 0 = full packet, N = first N×4 bytes of application data).

• bytes 6-7: Checksum (uint16 BE; Internet checksum over pseudo-header + DCCP header + selected application data per CsCov).

• byte 8: 3-bit Res (reserved) + 4-bit **Type** + 1-bit **X** (Extended Sequence Numbers — 0 = short 24-bit, 1 = extended 48-bit).

• For **X=0** (short header): byte 9 reserved + bytes 10-11 reserved + bytes 9-11 = 24-bit Sequence Number. Wait — actually X=0 layout is bytes 9 = 1 reserved + bytes 10-11+ for low Sequence — let me re-check RFC §5.1 fig 1.

• For **X=1** (extended header): byte 9 reserved + bytes 10-15 = 48-bit Sequence Number.

  Actually per RFC 4340 §5.1 Figure 1: ``` 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Dest Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Offset | CCVal | CsCov | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | Type |X| | . +-+-+-+-+-+-+-+-+ Sequence Number (high 16 bits when X=1) . | . . . . Sequence Number (low 24 bits when X=0; . . low 32 bits when X=1) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ```

  Short header (X=0, 12 bytes): byte 9 + bytes 10-11 = 24-bit Sequence Number. Extended header (X=1, 16 bytes): byte 9 reserved + bytes 10-15 = 48-bit Sequence Number.

• **10-entry packet type name table** (RFC 4340 §5.1): 0 DCCP-Request / 1 DCCP-Response / 2 DCCP-Data / 3 DCCP-Ack / 4 DCCP-DataAck / 5 DCCP-CloseReq / 6 DCCP-Close / 7 DCCP-Reset / 8 DCCP-Sync / 9 DCCP-SyncAck.

• **Request / Response body** (Types 0 + 1): when present, the first 4 bytes after the generic header are the **Service Code** (a per-application identifier the receiver uses to demultiplex incoming connections — analogous to UDP/TCP destination port + application). Plus an Acknowledgement Number subheader for Response.

• **Ack-family bodies** (Types 3, 4, 5, 8, 9): 8-byte **Acknowledgement Subheader** — 16-bit Reserved + 48-bit Acknowledgement Number.

• **Reset body** (Type 7): 8-byte Acknowledgement Subheader + 1-byte **Reset Code** + 1-byte Data1 + 1-byte Data2 + 1-byte Data3. **12-entry Reset Code name table** (RFC 4340 §5.6): 0 Unspecified / 1 Closed / 2 Aborted / 3 No Connection / 4 Packet Error / 5 Option Error / 6 Mandatory Error / 7 Connection Refused / 8 Bad Service Code / 9 Too Busy / 10 Bad Init Cookie / 11 Aggression Penalty.

• **Data / Close / CloseReq** bodies have no additional fields beyond the generic header.

What this package does NOT cover (deliberately out of scope)

• IP framing — feed DCCP bytes after the IPv4 / IPv6 header strip. DCCP runs as IP protocol 33.

• Options walker — DCCP has a rich set of Options (Mandatory, NDP Count, Ack Vector, Elapsed Time, Timestamp, Timestamp Echo, Slow Receiver, CCID- specific) that live after the per-type body up to Data Offset; surfaced as raw hex; per-option decoders are future work.

• Per-CCID semantics — DCCP supports pluggable Congestion Control IDs (CCID 2 = TCP-like, CCID 3 = TCP-Friendly Rate Control, CCID 4 = TFRC for Small Packets). The CCVal nibble surfaces as raw; per-CCID decoders are out of scope.

• Checksum verification — the Internet-checksum over the IP pseudo-header + DCCP header + CsCov bytes is surfaced as hex but not re-computed.

• DCCP state-machine reasoning — connection setup (Request/Response/Ack three-way handshake), teardown (CloseReq/Close/Reset), Sync recovery, and CCID negotiation are all higher-level analysis.