DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal
updates
Extracted elements (32)
DCCP-UDP eliminates the DCCP-level checksum and relies solely on the UDP checksum because NAT/NAPT traversal methods are unaware that DCCP is encapsulated and will not update the inner DCCP checksum after translating addresses. The UDP checksum covers the entire encapsulated DCCP datagram, providing equivalent protection.
DCCP-UDP inserts a UDP header between the IP header and the DCCP packet; this is not a tunneling approach. The IP addresses of communicating end systems are carried in the IP header without embedding additional IP addresses, allowing NAT/NAPT to translate addresses normally.
A single DCCP Service Code registry and DCCP port registration apply to all combinations of encapsulation (DCCP-STD and DCCP-UDP) and IP version. Applications SHOULD NOT register different Service Codes or ports for different encapsulations.
DCCP-UDP supports the syntax of partial checksums and negotiation of the Minimum Checksum Coverage feature, but the UDP checksum always covers the entire DCCP datagram and the DCCP checksum is ignored. Applications enabling partial checksums will receive a service functionally identical to full DCCP checksum coverage.
Minimal ICMP error messages for UDP only identify UDP source and destination ports, not the encapsulated DCCP ports. A DCCP-UDP endpoint supporting multiple DCCP connections over the same UDP 4-tuple may be unable to associate an ICMP message with a unique DCCP-UDP connection.
A DCCP-UDP client SHOULD ensure each DCCP connection maps to a single DCCP-UDP connection by using a distinct UDP source port per DCCP connection, so that UDP-based flow identifiers differ whenever DCCP-based flow identifiers differ.
A DCCP-UDP endpoint SHOULD follow DCCP-STD (RFC 4340 Section 12) procedures for ECN: set ECN in IP headers of outgoing packets, examine ECN fields of incoming packets, and relay markings to the DCCP module. Implementations not supporting ECN MUST follow RFC 4340 Section 12.1.
A DCCP-UDP implementation MUST implement exactly one of two demultiplexing methods: (1) accept only one active 6-tuple per UDP 4-tuple and send DCCP-Reset code 12 on conflict, or (2) support multiple DCCP connections per UDP 4-tuple by tracking each 6-tuple, discarding unmatched packets if resources are exhausted.
A DCCP-UDP server MUST demultiplex a DCCP-UDP flow using both UDP source and destination port numbers and the encapsulated DCCP ports, uniquely identifying an active DCCP connection by the 6-tuple: <source IP, source UDP port, source DCCP port, dest IP, dest UDP port, dest DCCP port>.
A received DCCP-UDP packet MUST be dropped if: (1) the UDP Length field is less than 20 bytes, (2) the UDP Checksum is invalid, or (3) the UDP Length field is less than the full UDP+DCCP header length or greater than the total packet length.
Applications that define signalling methods for DCCP MUST define how the encapsulation is chosen and MUST allow either encapsulation to be signalled. Where both DCCP-STD and DCCP-UDP are supported, DCCP-STD SHOULD be preferred.
DCCP-UDP endpoints SHOULD forward ICMP messages relating to a UDP packet carrying DCCP-UDP to the DCCP module, potentially translating the ICMP payload. Precautions similar to those in RFC 5927 (ICMP attacks against TCP) are desirable before forwarding.
DCCP-UDP implementations MUST follow DCCP-STD (RFC 4340 Section 14) for PMTUD, including processing ICMP Destination Unreachable 'Datagram Too Big' messages. The UDP encapsulation overhead reduces the Maximum Packet Size available at the DCCP level.
If a DCCP-UDP endpoint forwards a specific network-layer option to the DCCP module, it MUST also forward all subsequent packets with that option. Consistent forwarding is essential for correct operation of many end-to-end options.
If the 'a=rtcp-mux' attribute is not present in an SDP negotiation using RTP over DCCP-UDP, the second demultiplexing method (supporting multiple DCCP connections per UDP 4-tuple) MUST be implemented; otherwise the RTCP DCCP connection will be rejected. Using 'a=rtcp-mux' is RECOMMENDED with RTP over DCCP-UDP.
On transmission, the DCCP Checksum field SHOULD be set to zero. On receipt, the DCCP Checksum field MUST be ignored. The function of the DCCP Checksum is performed by the UDP Checksum field.
The encapsulation of a higher-layer protocol within DCCP MUST be the same for both DCCP-STD and DCCP-UDP; this document does not update existing encapsulations such as DTLS over DCCP (RFC 5238) or RTP over DCCP (RFC 5762).
The UDP checksum MUST NOT be zero for a UDP packet that carries DCCP-UDP. If the received UDP Checksum field is zero, the packet MUST be dropped.
When using DCCP-UDP, DCCP ports MUST NOT be included in the SDP 'm=' line. Instead, the DCCP port MUST be signalled via the new 'a=dccp-port:' media-level SDP attribute. The 'a=dccp-port:' attribute MUST be included when the DCCP-UDP protocol identifiers are used.
DCCP Reset Code 12 ('Encapsulated Port Reuse') is sent when a DCCP-UDP server cannot accept a new DCCP connection due to UDP 4-tuple conflict. Data byte 1 carries the DCCP Packet Type; data bytes 2 and 3 carry the encapsulated UDP source port in network order.
Five SDP proto field values are defined for DCCP-UDP: 'UDP/DCCP', 'UDP/DCCP/RTP/AVP', 'UDP/DCCP/RTP/SAVP', 'UDP/DCCP/RTP/AVPF', and 'UDP/DCCP/RTP/SAVPF'. The port in the 'm=' line indicates the UDP port used for DCCP-UDP encapsulation.
UDP port 6511 is the IANA-assigned default listening UDP port for a DCCP-UDP server. It is allocated for use by the transport service rather than a specific application, enabling a system-wide DCCP-UDP daemon to multiplex multiple DCCP applications over the same port.
IANA allocated the 'dccp-port' SDP media-level attribute (long form: 'Encapsulated DCCP Port') for signalling encapsulated DCCP port numbers when using DCCP-UDP encapsulation.
IANA allocated UDP port 6511 for the DCCP-UDP service, designated for use by the transport service rather than a specific application.
IANA assigned DCCP Reset Code 12 ('Encapsulated Port Reuse') in the DCCP Reset Codes Registry, applicable to all DCCP congestion control IDs, with defined semantics for its three data bytes.
DCCP-UDP may allow DCCP applications to bypass firewall rules by appearing as UDP traffic. A firewall implementing this specification could inspect the encapsulated DCCP header to filter on inner DCCP header fields, but full control requires firewall enhancements per RFC 4340 and RFC 5595.
DTLS may be applied in two ways with DCCP-UDP: (1) per DCCP connection as with native DCCP, leaving the UDP transport header unprotected; or (2) at the UDP encapsulation layer, protecting all DCCP headers from inspection or modification by middleboxes and eliminating per-connection DTLS handshakes.
Processing of ICMP messages received for DCCP-UDP packets and their translation for use by DCCP introduces risk; precautions analogous to RFC 5927 (ICMP attacks against TCP) are desirable before a DCCP-UDP endpoint acts on received ICMP messages.
A DCCP connection becomes 'active' following transmission of a DCCP-Request and becomes 'inactive' after sending a DCCP-Close. Active connections are tracked as 6-tuples for demultiplexing; inactive connections release the 6-tuple association.
A DCCP-UDP packet consists of: variable-length IP header (IPv4 or IPv6), 8-byte UDP header, 12- or 16-byte DCCP Generic Header, variable-length type-specific fields, variable-length DCCP options, and variable-length application data area.
The DCCP Generic Header takes two forms: long sequence numbers (48-bit sequence number, 16 bytes total) with X=1, and short sequence numbers (24-bit sequence number, 12 bytes total) with X=0. Both include Source Port, Dest Port, Data Offset, CCVal, CsCov, and Checksum fields as defined in RFC 4340.
The UDP header for DCCP-UDP carries Source Port and Destination Port (16 bits each) identifying UDP listeners, a 16-bit Length field covering UDP header plus payload, and a 16-bit Checksum over the network-layer pseudoheader and UDP packet. The UDP port values do not identify the DCCP source and destination ports.