RFC 6773
DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal
DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal ✨
okay bestie, this is RFC 6773 🎀. It's a Standards Track doc from the IETF (Internet Engineering Task Force), dated November 2012, and its ISSN is 2070-1721. It updates RFC 4340 and RFC 5762 💅. There's no Obsoletes line, so it doesn't replace anything. The authors are T. Phelan from Sonus, G. Fairhurst from the University of Aberdeen, and C. Perkins from the University of Glasgow 🧚.
Abstract 💖
so this doc describes a different way to wrap DCCP, called DCCP-UDP 🦋. The wrapping lets DCCP get through the current generation of Network Address Translation (NAT) middleboxes without changing those boxes at all 🔥. It also updates the SDP info for DCCP that RFC 5762 defined, so the encapsulation type can be conveyed. main character energy 👑
Status of This Memo 📜
this is an Internet Standards Track document. It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 🌸
for the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6773 ✨
Copyright Notice 🌈
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read them carefully, because they explain your rights and restrictions with respect to this document 🫶
Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. Don't skip this part bestie 💀
Table of Contents 🧾
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DCCP-UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. The UDP Header . . . . . . . . . . . . . . . . . . . . . . 5
3.2. The DCCP Generic Header . . . . . . . . . . . . . . . . . 5
3.3. DCCP-UDP Checksum Procedures . . . . . . . . . . . . . . . 6
3.3.1. Partial Checksums and the Minimum Checksum
Coverage Feature . . . . . . . . . . . . . . . . . . . 7
3.4. Network-Layer Options . . . . . . . . . . . . . . . . . . 8
3.5. Explicit Congestion Notification . . . . . . . . . . . . . 8
3.6. ICMP Handling for Messages Relating to DCCP-UDP . . . . . 8
3.7. Path Maximum Transmission Unit Discovery . . . . . . . . . 9
3.8. Usage of the UDP Port by DCCP-UDP . . . . . . . . . . . . 9
3.9. Service Codes and the DCCP Port Registry . . . . . . . . . 11
4. DCCP-UDP and Higher-Layer Protocols . . . . . . . . . . . . . 11
5.1. Protocol Identification . . . . . . . . . . . . . . . . . 12
5.2. Signalling Encapsulated DCCP Ports . . . . . . . . . . . . 13
5.3. Connection Management . . . . . . . . . . . . . . . . . . 14
5.4. Negotiating the DCCP-UDP Encapsulation versus Native
DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.5. Example of SDP Use . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. UDP Port Allocation . . . . . . . . . . . . . . . . . . . 17
7.2. DCCP Reset . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. SDP Attribute Allocation . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 181. Introduction ✨
okay so the Datagram Congestion Control Protocol (DCCP) [RFC4340] is a transport-layer protocol that gives upper layers the ability to use non-reliable, congestion-controlled flows 💅. The current DCCP spec [RFC4340] defines a direct native encapsulation in IPv4 or IPv6 packets 🌸
DCCP support has been specified for devices that use Network Address Translation (NAT) or Network Address and Port Translation (NAPT) [RFC5597]. ngl though, there's a huge installed base of NAT/NAPT devices that don't support [RFC5597] 💀. So it's really useful to have a DCCP encapsulation that works with that installed base, meaning devices that support [RFC4787] but not [RFC5597] 🙈. This doc specifies that encapsulation, and it's called DCCP-UDP. For convenience, the standard DCCP encapsulation [RFC4340] (including [RFC5596] as required) is called DCCP-STD 🎀
the DCCP-UDP encapsulation can also act as a transition mechanism, so devices that already support UDP but don't natively support DCCP yet can get DCCP support 🦋. It also lets the DCCP transport be implemented inside an application using DCCP-UDP ✨
this doc also updates the SDP spec for DCCP [RFC5762] so it can convey the encapsulation type. In this respect only, it updates the method in [RFC5762] 🫶
the DCCP-UDP encapsulation supports all of the features in DCCP-STD, but its functionality for partial checksums is limited 🧚
Network optimisations for DCCP-STP and UDP may need to be updated so they can take advantage of DCCP-UDP. Adding an extra UDP protocol header can complicate or even prevent equipment along the network path from inspecting DCCP header fields. That's a problem when multiple DCCP connections share the same UDP 4-tuple 😭. Examples of who gets affected: routers that want to identify DCCP ports to do Equal-Cost Multi-Path (ECMP) routing, network devices that inspect DCCP ports to inform load-sharing across multiple links, firewalls that inspect DCCP ports and service codes to apply access rules, and media gateways that inspect SDP information to figure out transport and session characteristics, etc. 💅
2. Terminology 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥
3. DCCP-UDP 🦋
the basic approach is to insert a UDP [RFC0768] header between the IP header and the DCCP packet 💖. Note that this is not a tunneling approach. The IP addresses of the communicating end systems are carried in the IP header, and the method doesn't embed any additional IP addresses 🧚
the method is designed to keep working when a device that implements NAT/NAPT changes those addresses 👑. A NAT translates the IP addresses, which affects the transport-layer checksum. A NAPT device may also translate the port values (usually the source port) 🌸. In both cases, the outer transport header that holds these values has to be updated by the NAT/NAPT ✨
a device offering or using DCCP services through DCCP-UDP listens on a UDP port (the default is port 6511), or it can bind to a specified port using out-of-band signalling, like the Session Description Protocol (SDP) 🎀. The DCCP-UDP server accepts incoming packets over the UDP transport and hands the received packets to the DCCP protocol module after removing the UDP encapsulation 💅
a DCCP implementation endpoint can provide services over any or all combinations of DCCP-STD and/or DCCP-UDP encapsulations with IPv4 and/or IPv6 at the same time 🫶
the basic format of a DCCP-UDP packet looks like this:
+-----------------------------------+
| IP Header (IPv4 or IPv6) | Variable length
+-----------------------------------+
| UDP Header | 8 bytes
+-----------------------------------+
| DCCP Generic Header | 12 or 16 bytes
+-----------------------------------+
| Additional (type-specific) Fields | Variable length (could be 0)
+-----------------------------------+
| DCCP Options | Variable length (could be 0)
+-----------------------------------+
| Application Data Area | Variable length (could be 0)
+-----------------------------------+Section 3.8 covers how UDP ports get used. That includes running a DCCP-UDP encapsulation service as a daemon that listens on a well-known port, which lets different DCCP applications be multiplexed over the same port 🌈
3.1. The UDP Header 🎀
the format of the UDP header is specified in [RFC0768]:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+for DCCP-UDP, the fields get interpreted like this 🧁
Source and Dest(ination) Ports: 16 bits each 🦋
these fields identify the UDP ports on which the source and destination (respectively) of the packet are listening for incoming DCCP-UDP packets. The UDP port values do not identify the DCCP source and destination ports. So don't mix them up, bestie 🙈
Length: 16 bits 💖
this field is the length of the UDP datagram, including the UDP header and the payload (for DCCP-UDP, the payload is a DCCP-UDP datagram) ✨
Checksum: 16 bits 🔥
this field is the Internet checksum of a network-layer pseudoheader and Length bytes of the UDP packet [RFC0768]. The UDP checksum MUST NOT be zero for a UDP packet that carries DCCP-UDP. Iconic rule, no notes 👑
3.2. The DCCP Generic Header ✨
okay so the DCCP Generic Header [RFC4340] comes in two flavours 🎀 one with long sequence numbers (48 bits) and one with short sequence numbers (24 bits). bestie look at these diagrams, they're so clean 😭
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X| | .
| Res | Type |=| Reserved | Sequence Number (high bits) .
| | |1| | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Generic DCCP Header with Long Sequence Numbers [RFC4340]
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X| |
| Res | Type |=| Sequence Number (low bits) |
| | |0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Generic DCCP Header with Short Sequence Numbers [RFC4340]every generic header field, except the Checksum field, means what [RFC4340] says it means, as updated by [RFC5596] 🧚 the checksum is the odd one out, so keep an eye on it in the next bit 👀
Section 3.8 explains how a DCCP-UDP implementation handles UDP and DCCP ports 🦋
3.3. DCCP-UDP Checksum Procedures
okay so DCCP-UDP uses a checksum at the UDP level and just skips the DCCP checksum entirely 💅 the reason is that today's NAT/NAPT traversal methods were built for UDP, so they usually don't know whether DCCP is being tunnelled inside, and they don't update the inner checksum in the DCCP header. standard DCCP wants the DCCP header fields protected, so the extra work of computing the UDP checksum is totally justified ✨
also, UDP NAT traversal doesn't support partial checksums 🙈 partial checksums are still allowed end-to-end inside the encapsulated DCCP datagram, but the links along the path treat everything as plain UDP packets, so they can't turn on any special partial checksum processing.
DCCP-UDP doesn't change how UDP works 🌸 here's how it uses UDP:
For DCCP-UDP, the job of the DCCP Checksum field is done by the UDP Checksum field. When sending, the DCCP Checksum field SHOULD be set to zero. When receiving, the DCCP Checksum field MUST be ignored.
the UDP checksum MUST NOT be zero for a UDP packet sent using DCCP-UDP. if a received UDP Checksum field is zero, the packet MUST be dropped 🙅♀️
if the UDP Length field of a received packet is less than 20 (the UDP header length plus the minimum DCCP-UDP header length), the packet MUST be dropped.
if the UDP Checksum field is invalid when computed with standard UDP methods, the received packet MUST be dropped 💀
if the UDP Length field in a received packet is less than the UDP header plus the whole DCCP-UDP header (generic header, type-specific fields and options included, if present), or if the UDP Length field is bigger than the packet from the start of the UDP header to the end of the packet, the packet MUST be dropped. no exceptions, periodt 💖
3.3.1. Partial Checksums and the Minimum Checksum Coverage Feature
this document requires the UDP checksum to be turned on when using DCCP-UDP 🫶 it covers the entire encapsulated DCCP datagram, so you get full coverage no matter what
DCCP-UDP supports the syntax of partial checksums 🧁 it also supports negotiating the Minimum Checksum Coverage feature and setting the CsCov field. BUT the UDP Checksum field in DCCP-UDP always covers the whole DCCP datagram, and the DCCP checksum gets ignored on receipt. so an application that switches on the partial checksums feature in the DCCP module ends up with a service that works exactly like full DCCP checksum coverage 🎀 it's also the service the application would have gotten on a network path that didn't do any optimised processing for DCCP partial checksums. main character energy, honestly 👑
3.4. Network-Layer Options
a DCCP-UDP implementation MAY transfer network-layer options meant for DCCP into the network-layer header of the encapsulating UDP packet 🦋
a DCCP-UDP endpoint that receives IP options for the encapsulating UDP packet MAY pass them up to the DCCP protocol module. but if the endpoint forwards a specific network-layer option to the DCCP module, it MUST also forward every subsequent packet carrying that option 🔥 consistent forwarding is essential for end-to-end options to work properly, no cap
3.5. Explicit Congestion Notification
a DCCP-UDP endpoint SHOULD follow the DCCP-STD procedures in [RFC4340], Section 12 🌈 that means setting the Explicit Congestion Notification (ECN) bits in the IP headers of outgoing packets, checking the ECN values on incoming IP packets, and relaying any packet markings to the DCCP module ✨
implementations that don't support ECN MUST follow the DCCP-STD procedures in [RFC4340], Section 12.1 for implementations that aren't ECN capable 🫠
3.6. ICMP Handling for Messages Relating to DCCP-UDP
so ICMP messages need to get demultiplexed by the receiving endpoint 🧚 to make that work, part of the original packet that caused the message gets included in the payload of the ICMP error message. the receiver can use that to match the ICMP error to the transport protocol instance that triggered it. when DCCP-UDP is used, the error message and the payload of the ICMP error message are about the UDP transport 💜
DCCP-UDP endpoints SHOULD forward ICMP messages about a UDP packet carrying DCCP-UDP to the DCCP module 💅 this might mean translating the payload of the ICMP message into a form the DCCP stack recognises. [RFC5927] describes precautions that are worth taking before TCP acts on an ICMP message, and similar precautions are worth taking before DCCP-UDP forwards to the DCCP module ⭐
the minimal-length ICMP error message generated when processing a UDP datagram only identifies the UDP source port and UDP destination port 😭 it doesn't carry enough info to figure out the encapsulated DCCP port values. so a DCCP-UDP endpoint that supports multiple DCCP connections over the same pair of UDP ports (see Section 3.8) might not be able to match an ICMP message to one unique DCCP-UDP connection. rough, but that's the reality 🙈
3.7. Path Maximum Transmission Unit Discovery
DCCP-UDP implementations MUST follow DCCP-STD [RFC4340], Section 14 for working out the maximum packet size and for using Path Maximum Transmission Unit Discovery (PMTUD) 🍓 this means processing ICMP Destination Unreachable messages with the code that says an unfragmentable packet was too big to forward (a "Datagram Too Big" message), as defined in RFC 4340.
encapsulation adds extra datagram overhead, and that shrinks the Maximum Packet Size (MPS) at the DCCP level 🥲
3.8. Usage of the UDP Port by DCCP-UDP 🎀
okay so a DCCP-UDP server (aka an endpoint that starts out passive because it wants to receive DCCP-Request packets [RFC4340] over DCCP-UDP) listens for connections on one or more UDP ports. UDP port number 6511 has been allocated as the default listening UDP port for a DCCP-UDP server. Some NAT/NAPT setups may need a non-default listening port, so keep that in mind 🌸
The whole point of this IANA-assigned port is to let the operating system or a framework catch DCCP-UDP datagrams and hand them off to the DCCP module 💅 That's how you get a system-wide DCCP-UDP daemon serving multiple DCCP apps, or a DCCP-UDP server chilling behind a firewall. Iconic behavior honestly 👑
An application-specific implementation SHOULD use an ephemeral port and advertise it using outside means, like SDP ✨ This method of implementation SHOULD NOT use the IANA-assigned port to listen for incoming DCCP-UDP packets. Don't be that app 🙈
A DCCP-UDP client gives UDP source and destination ports, plus DCCP source and destination ports, at connection initiation time. A client SHOULD ensure that each DCCP connection maps to a single DCCP-UDP connection by setting the UDP source port 🦋 Picking a distinct UDP source port for every distinct DCCP connection means the UDP-based flow identifiers differ whenever the DCCP-based ones do. So two connections with different <source IP address, source DCCP port, destination IP address, destination DCCP port> DCCP 4-tuples will end up with different <source IP address, source UDP port, destination IP address, destination UDP port> UDP 4-tuples. Main character energy, fr fr 💖
A DCCP-UDP server SHOULD accept datagrams from any UDP source port. Now here's the tea: the same DCCP source port number could get used by two endpoints that are each behind a NAPT 😭 So a DCCP-UDP server MUST demultiplex a DCCP-UDP flow using both the UDP source and destination port numbers AND the encapsulated DCCP ports. That's what makes an active DCCP connection uniquely identified by the 6-tuple <source IP address, source UDP port, source DCCP port, destination IP address, destination UDP port, destination DCCP port>. (Quick reminder that the active state of a DCCP connection is defined right here in Section 3.8: a DCCP connection becomes active after a DCCP-Request is sent, and becomes inactive after it sends a DCCP-Close 🧚)
Demultiplexing at a DCCP-UDP endpoint happens in two stages, and it's giving very organized 🍓
- In the first stage, DCCP-UDP packets get demultiplexed using the UDP 4-tuple:
<source IP address, source UDP port, destination IP address, destination UDP port>. - In the second stage, a receiving endpoint MUST ensure that two independent DCCP connections multiplexed onto the same UDP 4-tuple are NOT associated with the same connection in the DCCP module. So the endpoint needs to keep state for the set of active DCCP-UDP endpoints using each combination of a UDP 4-tuple:
<source IP address, source UDP port, destination IP address, destination UDP port>. There are two DCCP endpoint methods, and a DCCP-UDP implementation MUST implement exactly one of them 🔥- The DCCP server may accept only one active 6-tuple at a time for a given UDP 4-tuple. With this method, DCCP-UDP packets that don't match an active 6-tuple MUST NOT be passed to the DCCP module, and the DCCP Server SHOULD send a DCCP-Reset with Reset Code 12, "Encapsulated Port Reuse". An endpoint that gets a DCCP-Reset with this reset code clears its connection state, but it MAY immediately try again using a different 4-tuple. This is the protection bit: if the same UDP 4-tuple gets reused by multiple DCCP connections, only one DCCP connection gets established at a time 💅
- The DCCP server may support multiple DCCP connections over the same UDP 4-tuple. With this method, the endpoint MUST associate each 6-tuple with a single DCCP connection. If an endpoint can't demultiplex the 6-tuple (say, because of internal resource limits), it MUST discard DCCP-UDP packets that don't match an active 6-tuple instead of forwarding them to the DCCP module. The DCCP endpoint MAY send a DCCP-Reset with Reset Code 12, "Encapsulated Port Reuse", which says the connection has been closed but may be retried using a different UDP 4-tuple 🦋
3.9. Service Codes and the DCCP Port Registry ✨
okay this section is all about how DCCP Service Codes work with DCCP-UDP and how server ports get registered 🎀 It's not trying to change how Service Codes or server ports get allocated in the first place, so no drama there 🌈
There's one Service Code registry and one DCCP port registration, and they apply to every combination of encapsulation and IP version 💖 A DCCP Service Code says "this is an app using DCCP," no matter which encapsulation or IP version is in play. An app can skip some combinations of encapsulation and IP version, but its Service Code stays registered for those combos anyway, and the Service Code must not be used by other applications 🙈 An application should not register different Service Codes for different combinations of encapsulation and IP version. [RFC5595] has more info on DCCP Service Codes if you're curious 🧚
A DCCP port registration works the same way: it covers every combination of encapsulation and IP version 🫶 Again, an app can choose not to support some of those combos on its registered DCCP port, but the port stays registered for them. Applications should not register different DCCP ports just to use different encapsulation combinations. Keep it simple, bestie 💜
4. DCCP-UDP and Higher-Layer Protocols 🌈
Okay so the encapsulation of a higher-layer protocol inside DCCP MUST be the same for both DCCP-STD and DCCP-UDP 💅 Encapsulating Datagram Transport Layer Security (DTLS) over DCCP is defined in [RFC5238], and RTP over DCCP is defined in [RFC5762]. This document therefore does not update those encapsulations when you're using DCCP-UDP. No notes, they're just vibing as-is ✨
5. Signalling the Use of DCCP-UDP 📣
Applications often signal transport connection parameters through outside means, like SDP 🌸 Applications that define those methods for DCCP MUST define how the DCCP encapsulation gets chosen, and they MUST allow either encapsulation to be signalled. When DCCP-STD and DCCP-UDP are both supported, DCCP-STD SHOULD be preferred 👑
The Session Description Protocol (SDP) [RFC4566] and the offer/answer model [RFC3264] can negotiate DCCP sessions, and [RFC5762] defines SDP extensions for signalling an RTP session running over DCCP connections. BUT since [RFC5762] came out before this document, it doesn't define a way to signal that DCCP-UDP encapsulation should be used 🙈 So this section updates [RFC5762] to describe how SDP can signal RTP sessions running over the DCCP-UDP encapsulation. It's giving glow-up energy 🦋
The new SDP support in this section is expected to be super useful when the offering party is on the public Internet, or in the same private addressing realm as the answering party. In that case, the DCCP-UDP server has a public address. The client might have a public address too, or it might be behind a NAT/NAPT. This scenario has the potential to be a seriously important use case 😭 Some other NAT/NAPT topologies might make the advertised port unreachable through the NAT/NAPT, so watch out for that 💀
5.1. Protocol Identification 🧚
SDP uses a media ("m=") line to convey the details of the media format and the transport protocol being used. The ABNF syntax [RFC5234] of a media line for DCCP looks like this (from [RFC4566]):
media-field = %x6d "=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLFThe proto field tells you the transport protocol used for the media, and the port tells you which transport port the media gets sent to, following [RFC5762]. This document defines five proto field values that indicate media carried over DCCP-UDP encapsulation 🎀
UDP/DCCP
UDP/DCCP/RTP/AVP
UDP/DCCP/RTP/SAVP
UDP/DCCP/RTP/AVPF
UDP/DCCP/RTP/SAVPF"UDP/DCCP" is similar to the "DCCP" protocol identifier defined in [RFC5762]. It means the DCCP transport protocol is encapsulated in UDP, but it says nothing about the upper-layer protocol 💖
"UDP/DCCP/RTP/AVP" refers to RTP using the RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551], running over DCCP-UDP encapsulation 🎶
"UDP/DCCP/RTP/SAVP" refers to RTP using the Secure Real-time Transport Protocol [RFC3711], running over DCCP-UDP encapsulation 🔐
"UDP/DCCP/RTP/AVPF" refers to RTP using the Extended RTP Profile for RTCP-based Feedback [RFC4585], running over DCCP-UDP encapsulation 💅
"UDP/DCCP/RTP/SAVPF" refers to RTP using the Extended Secure RTP Profile for RTCP-based Feedback [RFC5124], running over DCCP-UDP encapsulation ✨
The fmt value in the "m=" line gets used as described in [RFC5762] 🌸
The port number in the "m=" line is the UDP port used for the DCCP-UDP encapsulation service. The DCCP port number MUST be sent using an associated "a=dccp-port:" attribute, as described in Section 5.2 💜 And the use of ports with DCCP-UDP encapsulation is described further in Section 3.8 🦋
5.2. Signalling Encapsulated DCCP Ports 🫶
When you're using DCCP-UDP, the UDP port used for the encapsulation gets signalled in the SDP "m=" line. The DCCP ports MUST NOT be included in the "m=" line. Instead they get signalled with a brand-new SDP attribute called "dccp-port", defined by this ABNF:
dccp-port-attr = %x61 "=dccp-port:" dccp-port
dccp-port = 1*DIGITDIGIT is as defined in [RFC5234]. This is a media-level attribute that is not subject to the charset attribute 🍓 The "a=dccp-port:" attribute MUST be included whenever the protocol identifiers from Section 5.1 are used 🔥 And again, the use of ports with DCCP-UDP encapsulation is described further in Section 3.8 🧚
Now for how the signalled port works, depending on what else is going on:
- If the "a=rtcp:" attribute [RFC3605] is used, then the signalled port is the DCCP port used for RTCP.
- If the "a=rtcp-mux" attribute [RFC5761] is negotiated, then RTP and RTCP get multiplexed onto a single DCCP port. Otherwise, separate DCCP ports are used for RTP and RTCP [RFC5762]. NOTE: In each case, only a single UDP port is used for the DCCP-UDP encapsulation.
- If the "a=rtcp-mux" attribute is not present, then the second of the two demultiplexing methods described in Section 3.8 MUST be implemented. Otherwise, the second DCCP connection for the RTCP flow gets rejected 😭 For this reason, using "a=rtcp-mux" is RECOMMENDED when you're using RTP over DCCP-UDP 💖
Real talk: if you skip "a=rtcp-mux", you NEED that second demultiplexing method or your RTCP connection gets bounced. Don't let that happen to you bestie 💀
5.3. Connection Management 💅
The "a=setup:" attribute is used in a manner compatible with [RFC5762], Section 5.3, to indicate which of the DCCP-UDP endpoints should initiate the DCCP-UDP connection establishment 🎀
5.4. Negotiating the DCCP-UDP Encapsulation versus Native DCCP 🎀
okay so bestie, an endpoint that can do both native DCCP and the DCCP-UDP encapsulation can say so in an SDP offer 💅 That lets the answering party pick native DCCP whenever it can, and fall back to DCCP-UDP if it can't ✨
one way to set this up is to put candidates for both DCCP-UDP and native DCCP into an Interactive Connectivity Establishment (ICE) [RFC5245] exchange 🦋 DCCP is connection-oriented, so these candidates need to be encoded into ICE in a way that's analogous to the TCP candidates defined in [RFC6544] 🧚 Active and passive candidates could work for both native DCCP and DCCP-UDP, and so could DCCP simultaneous-open candidates [RFC5596] 🌸 When picking local preference values, it might make sense to favour DCCP-UDP over native DCCP when fast connection setup matters most 🫶 It might also make sense to prioritise native DCCP when low overhead is the goal. The reasoning is that DCCP-UDP is more likely to get through legacy NAT, but it has higher overhead 😭 The details of encoding this into ICE are left for future study 🔮
ICE is a good fit for picking basic DCCP-UDP versus DCCP-STD, but it may not be the right tool for negotiating different RTP profiles with each transport encapsulation 🤔 The SDP Capability Negotiation framework [RFC5939] may be more suitable here. Section 3.7 of RFC 5939 explains how to provide attributes and transport protocols as capabilities and negotiate them with that framework 💖 How exactly SDP Capability Negotiation gets used with DCCP is also left for future study 🍓
5.5. Example of SDP Use 💜
okay here's a sample SDP offer where an app says it supports DCCP-UDP 👀
v=0
o=alice 1129377363 1 IN IP4 192.0.2.47
s=-
c=IN IP4 192.0.2.47
t=0 0
m=video 50234 UDP/DCCP/RTP/AVP 99
a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x52545056
a=dccp-port:5004
a=rtcp:5005
a=setup:passive
a=connection:newthe answering party at 192.0.2.128 gets this offer and replies with this answer 🎀
v=0
o=bob 1129377364 1 IN IP4 192.0.2.128
s=-
c=IN IP4 192.0.2.128
t=0 0
m=video 40123 UDP/DCCP/RTP/AVP 99
a=rtpmap:99 h261/90000
a=dccp-service-code:SC:RTPV
a=dccp-port:9
a=setup:active
a=connection:newnotice that the "m=" line in the answer carries the UDP port number of the encapsulation service ✨ The DCCP service code is set to "RTPV", signalled with the "a=dccp-service-code" attribute [RFC5762] 🌈 The "a=dccp-port:" attribute in the answer is set to 9 (the discard port), which is the usual move for an active connection-oriented endpoint 🙈
then the answering party tries to set up a DCCP-UDP connection to the offering party. The connection request uses an ephemeral DCCP source port and DCCP destination port 5004. The UDP packet wrapping that request has UDP source port 40123 and UDP destination port 50234 💅
6. Security Considerations 🚨
okay this part is seriously important, bestie 😭🔥 DCCP-UDP gets every security risk-mitigation measure that DCCP-STD has, but it also gets every security risk 💀 It doesn't keep any extra state at the encapsulation layer, though 🫶
the tunnel encapsulation recommends processing ICMP messages received for packets sent using DCCP-UDP and translating them so DCCP can use them 👀 [RFC5927] describes precautions that are desirable before TCP acts on receipt of ICMP messages. Similar precautions are desirable for endpoints processing ICMP for DCCP-UDP 🛡️ The whole point of DCCP-UDP is to let DCCP pass through NAT/NAPT devices, so it exposes DCCP to the risks that come with passing through NAT devices. It doesn't create any new risks with regard to NAT/NAPT devices 💖
DCCP-UDP may also let DCCP applications pass through existing firewall devices using rules for UDP, if the admins of those devices choose to allow it 🧱 A simple setup may either allow all DCCP applications or allow none 🙅♀️
a firewall that interprets this specification could inspect the encapsulated DCCP header and filter based on the inner DCCP header information 🔍 Full control of DCCP connections by applications will need firewall enhancements, as discussed in [RFC4340] and related RFCs (e.g., [RFC5595]) 🧚
Datagram Transport Layer Security (DTLS) provides mechanisms that can protect the encapsulated DCCP packets 🔐 DTLS may be used in two ways:
- Individual DCCP connections may be protected in the same way that DTLS is used with native DCCP [RFC5595]. This does not encrypt the UDP transport header added by DCCP-UDP. 🦋
- This specification also permits the use of DTLS with the UDP transport that encapsulates DCCP packets. When DTLS is used at the encapsulation layer, this protects the DCCP headers. This prevents the headers from being inspected or updated by network middleboxes (such as firewalls and NAPT). It also eliminates the need for a separate DTLS handshake for each DCCP connection. 👑
7. IANA Considerations 🌸
IANA has made the allocations described in the following sections 🎀
7.1. UDP Port Allocation 🔌
IANA has allocated a UDP port (6511) for the DCCP-UDP service. This port is allocated for use by a transport service rather than an application. In this case, the name of the transport should explicitly appear in the registry. Use of this port is defined in Section 3.8
7.2. DCCP Reset 🔁
IANA has assigned a new DCCP reset code (12) in the DCCP Reset Codes Registry, with the short description "Encapsulated Port Reuse". This code applies to all DCCP congestion control IDs. Use of this reset code is defined in Section 3.8. Section 5.6 of [RFC4340] defines three "Data" bytes that get carried by a DCCP Reset. For this reset code, they're defined like this:
- Data byte 1: The DCCP Packet Type of the DCCP datagram that resulted in the error message.
- Data bytes 2 & 3: The encapsulated UDP source port from the DCCP-UDP datagram that triggered the ICMP message, in network order.
7.3. SDP Attribute Allocation 📝
IANA has allocated the following new SDP attribute ("att-field"):
Contact name: DCCP Working Group
Attribute name: dccp-port
Long-form attribute name in English: Encapsulated DCCP Port
Type of attribute: Media level only
Subject to charset attribute? No
Purpose of the attribute: See this document, Section 5.1
Allowed attribute values: See this document, Section 5.18. Acknowledgments 🫶
This document was produced by the DCCP WG. The following individuals contributed during the working group last call: Andrew Lentvorski, Lloyd Wood, Pasi Sarolahti, Gerrit Renker, Eddie Kohler, and Dan Wing. Thank you, legends 🧚✨
9. References 📚
9.1. Normative References 💜
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605,
October 2003.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", RFC 5762, April 2010.9.2. Informative References 🦋
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)",
RFC 5238, May 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol
(DCCP) Service Codes", RFC 5595, September 2009.
[RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol
(DCCP) Simultaneous-Open Technique to Facilitate NAT/
Middlebox Traversal", RFC 5596, September 2009.
[RFC5597] Denis-Courmont, R., "Network Address Translation (NAT)
Behavioral Requirements for the Datagram Congestion
Control Protocol", BCP 150, RFC 5597, September 2009.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 2010.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. B. Roach,
"TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012.Authors' Addresses 💌
Tom Phelan
Sonus Networks
7 Technology Dr.
Westford, MA 01886
US
Phone: +1 978 614 8456
EMail: tphelan@sonusnet.com
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen, Scotland AB24 3UE
UK
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
Colin Perkins
University of Glasgow
School of Computing Science
Glasgow, Scotland G12 8QQ
UK
EMail: csp@csperkins.org
URI: http://csperkins.org/📦 where this page comes from
- ietf: rfc6773 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms