summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6773.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6773.txt')
-rw-r--r--doc/rfc/rfc6773.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc6773.txt b/doc/rfc/rfc6773.txt
new file mode 100644
index 0000000..5205f2f
--- /dev/null
+++ b/doc/rfc/rfc6773.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) T. Phelan
+Request for Comments: 6773 Sonus
+Updates: 4340, 5762 G. Fairhurst
+Category: Standards Track University of Aberdeen
+ISSN: 2070-1721 C. Perkins
+ University of Glasgow
+ November 2012
+
+
+ DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for
+ NAT Traversal
+
+Abstract
+
+ This document specifies an alternative encapsulation of the Datagram
+ Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This
+ encapsulation allows DCCP to be carried through the current
+ generation of Network Address Translation (NAT) middleboxes without
+ modification of those middleboxes. This document also updates the
+ Session Description Protocol (SDP) information for DCCP defined in
+ RFC 5762.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6773.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Phelan, et al. Standards Track [Page 1]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+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 . . . . . . . . . . . . . . . . . . 18
+
+
+
+
+Phelan, et al. Standards Track [Page 2]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+1. Introduction
+
+ The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a
+ transport-layer protocol that provides upper layers with the ability
+ to use non-reliable congestion-controlled flows. The current
+ specification for DCCP [RFC4340] specifies 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]. However, there is a significant installed base of NAT/
+ NAPT devices that do not support [RFC5597]. It is therefore useful
+ to have an encapsulation for DCCP that is compatible with this
+ installed base of NAT/NAPT devices that support [RFC4787] but do not
+ support [RFC5597]. This document specifies that encapsulation, which
+ is referred to as DCCP-UDP. For convenience, the standard
+ encapsulation for DCCP [RFC4340] (including [RFC5596] as required) is
+ referred to as DCCP-STD.
+
+ The encapsulation described in this document may also be used as a
+ transition mechanism to enable support for DCCP in devices that
+ support UDP but do not yet natively support DCCP. This also allows
+ the DCCP transport to be implemented within an application using
+ DCCP-UDP.
+
+ This document also updates the SDP specification for DCCP [RFC5762]
+ to convey the encapsulation type. In this respect only, it updates
+ the method in [RFC5762].
+
+ The DCCP-UDP encapsulation specified in this document supports all of
+ the features contained in DCCP-STD, but with limited functionality
+ for partial checksums.
+
+ Network optimisations for DCCP-STP and UDP may need to be updated to
+ allow these optimisations to take advantage of DCCP-UDP.
+ Encapsulation with an additional UDP protocol header can complicate
+ or prevent inspection of DCCP header fields by equipment along the
+ network path in the case where multiple DCCP connections share the
+ same UDP 4-tuple, for example, routers that wish to identify DCCP
+ ports to perform Equal-Cost Multi-Path (ECMP) routing, network
+ devices that wish to inspect DCCP ports to inform algorithms for
+ sharing the network load across multiple links, firewalls that wish
+ to inspect DCCP ports and service codes to inform algorithms that
+ implement access rules, media gateways that inspect SDP information
+ to derive characteristics of the transport and session, etc.
+
+
+
+
+
+
+Phelan, et al. Standards Track [Page 3]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+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. The method does not embed additional IP
+ addresses.
+
+ The method is designed to support use when these addresses are
+ modified by a device that implements NAT/NAPT. A NAT translates the
+ IP addresses, which impacts 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 includes these values
+ would need to be updated by the NAT/NAPT.
+
+ A device offering or using DCCP services via DCCP-UDP encapsulation
+ listens on a UDP port (default port, 6511) or may bind to a specified
+ port utilising out-of-band signalling, such as the Session
+ Description Protocol (SDP). The DCCP-UDP server accepts incoming
+ packets over the UDP transport and passes the received packets to the
+ DCCP protocol module, after removing the UDP encapsulation.
+
+ A DCCP implementation endpoint may simultaneously provide services
+ over any or all combinations of DCCP-STD and/or DCCP-UDP
+ encapsulations with IPv4 and/or IPv6.
+
+ The basic format of a DCCP-UDP packet is:
+
+ +-----------------------------------+
+ | 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)
+ +-----------------------------------+
+
+
+
+
+Phelan, et al. Standards Track [Page 4]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+ Section 3.8 describes usage of UDP ports. This includes
+ implementation of a DCCP-UDP encapsulation service as a daemon that
+ listens on a well-known port, allowing multiplexing of different DCCP
+ applications 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 are interpreted as follows:
+
+ 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.
+
+ 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.
+
+3.2. The DCCP Generic Header
+
+ The DCCP Generic Header [RFC4340] takes two forms, one with long
+ sequence numbers (48 bits) and the other with short sequence numbers
+ (24 bits).
+
+
+
+
+
+
+
+Phelan, et al. Standards Track [Page 5]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+ 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]
+
+ All generic header fields, except for the Checksum field, have the
+ meaning specified in [RFC4340], updated by [RFC5596].
+
+ Section 3.8 describes how a DCCP-UDP implementation treats UDP and
+ DCCP ports.
+
+3.3. DCCP-UDP Checksum Procedures
+
+ DCCP-UDP employs a checksum at the UDP level and eliminates the use
+ of the DCCP checksum. This approach was chosen to enable use of
+ current NAT/NATP traversal methods developed for UDP. Such methods
+ will generally be unaware whether DCCP is being encapsulated and
+ hence do not update the inner checksum in the DCCP header. Standard
+ DCCP requires protection of the DCCP header fields; this justifies
+ any processing overhead incurred from calculating the UDP checksum.
+
+
+
+
+
+Phelan, et al. Standards Track [Page 6]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+ In addition, UDP NAT traversal does not support partial checksums.
+ Although this is still permitted end-to-end in the encapsulated DCCP
+ datagram, links along the path will treat these as UDP packets and
+ can not enable special partial checksum processing.
+
+ DCCP-UDP does not update or modify the operation of UDP. The UDP
+ transport protocol is used in the following way:
+
+ For DCCP-UDP, the function of the DCCP Checksum field is performed by
+ the UDP Checksum field. On transmission, the DCCP Checksum field
+ SHOULD be set to zero. On receipt, the DCCP Checksum field MUST be
+ ignored.
+
+ The UDP checksum MUST NOT be zero for a UDP packet that is sent using
+ DCCP-UDP. If the 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 and minimum DCCP-UDP header length), the packet MUST be
+ dropped.
+
+ If the UDP Checksum field, computed using standard UDP methods, is
+ invalid, the received packet MUST be dropped.
+
+ If the UDP Length field in a received packet is less than the length
+ of the UDP header plus the entire DCCP-UDP header (including the
+ generic header and type-specific fields and options, if present) or
+ if the UDP Length field is greater than the length of the packet from
+ the beginning of the UDP header to the end of the packet, the packet
+ MUST be dropped.
+
+3.3.1. Partial Checksums and the Minimum Checksum Coverage Feature
+
+ This document requires the UDP checksum to be enabled when using
+ DCCP-UDP. This checksum provides coverage of the entire encapsulated
+ DCCP datagram.
+
+ DCCP-UDP supports the syntax of partial checksums. It also supports
+ negotiation of the Minimum Checksum Coverage feature and settings of
+ the CsCov field. However, the UDP Checksum field in DCCP-UDP always
+ covers the entire DCCP datagram, and the DCCP checksum is ignored on
+ receipt. An application that enables the partial checksums feature
+ in the DCCP module will therefore experience a service that is
+ functionally identical to using full DCCP checksum coverage. This is
+ also the service that the application would have received if it had
+ used a network path that did not provide optimised processing for
+ DCCP partial checksums.
+
+
+
+
+Phelan, et al. Standards Track [Page 7]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+3.4. Network-Layer Options
+
+ A DCCP-UDP implementation MAY transfer network-layer options intended
+ for DCCP to the network-layer header of the encapsulating UDP packet.
+
+ A DCCP-UDP endpoint that receives IP-options for the encapsulating
+ UDP packet MAY forward these to the DCCP protocol module. If the
+ endpoint forwards a specific network-layer option to the DCCP module,
+ it MUST also forward all subsequent packets with this option.
+ Consistent forwarding is essential for correct operation of many end-
+ to-end options.
+
+3.5. Explicit Congestion Notification
+
+ A DCCP-UDP endpoint SHOULD follow the procedures of DCCP-STD in
+ [RFC4340], Section 12 by setting the Explicit Congestion Notification
+ (ECN) in the IP headers of outgoing packets and examining the values
+ received in the ECN fields of incoming IP packets, relaying any
+ packet markings to the DCCP module.
+
+ Implementations that do not support ECN MUST follow the procedures of
+ DCCP-STD in [RFC4340], Section 12.1 with regard to implementations
+ that are not ECN capable.
+
+3.6. ICMP Handling for Messages Relating to DCCP-UDP
+
+ To allow ICMP messages to be demultiplexed by the receiving endpoint,
+ part of the original packet that resulted in the message is included
+ in the payload of the ICMP error message. The receiving endpoint can
+ therefore use this information to associate the ICMP error with the
+ transport protocol instance that resulted in the ICMP message. When
+ DCCP-UDP is used, the error message and the payload of the ICMP error
+ message relate to the UDP transport.
+
+ DCCP-UDP endpoints SHOULD forward ICMP messages relating to a UDP
+ packet that carries a DCCP-UDP to the DCCP module. This may imply
+ translation of the payload of the ICMP message into a form that is
+ recognised by the DCCP stack. [RFC5927] describes precautions that
+ are desirable before TCP acts on the receipt of an ICMP message.
+ Similar precautions are desirable prior to forwarding by DCCP-UDP to
+ the DCCP module.
+
+ The minimal length ICMP error message generated in response to
+ processing a UDP datagram only identifies the UDP source port and UDP
+ destination port. This ICMP message does not carry sufficient
+ information to discover the encapsulated DCCP Port values. A DCCP-
+
+
+
+
+
+Phelan, et al. Standards Track [Page 8]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+ UDP endpoint that supports multiple DCCP connections over the same
+ pair of UDP ports (see Section 3.8) may not therefore be able to
+ associate an ICMP message with a unique DCCP-UDP connection.
+
+3.7. Path Maximum Transmission Unit Discovery
+
+ DCCP-UDP implementations MUST follow DCCP-STD [RFC4340], Section 14
+ with regard to determining the maximum packet size and the use of
+ Path Maximum Transmission Unit Discovery (PMTUD). This requires the
+ processing of ICMP Destination Unreachable messages with a code that
+ indicates that an unfragmentable packet was too large to be forwarded
+ (a "Datagram Too Big" message), as defined in RFC 4340.
+
+ An effect of encapsulation is to incur additional datagram overhead.
+ This will reduce the Maximum Packet Size (MPS) at the DCCP level.
+
+3.8. Usage of the UDP Port by DCCP-UDP
+
+ A DCCP-UDP server (that is, an initially passive endpoint that wishes
+ 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 topologies may require using a non-default listening
+ port.
+
+ The purpose of this IANA-assigned port is for the operating system or
+ a framework to receive and process DCCP-UDP datagrams for delivery to
+ the DCCP module (e.g., to support a system-wide DCCP-UDP daemon
+ serving multiple DCCP applications or a DCCP-UDP server placed behind
+ a firewall).
+
+ An application-specific implementation SHOULD use an ephemeral port
+ and advertise this port using outside means, e.g., SDP. This method
+ of implementation SHOULD NOT use the IANA-assigned port to listen for
+ incoming DCCP-UDP packets.
+
+ A DCCP-UDP client provides UDP source and destination ports as well
+ as 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. Choosing a
+ distinct UDP source port for each distinct DCCP connection ensures
+ that UDP-based flow identifiers differ whenever DCCP-based flow
+ identifiers differ. Specifically, two connections with different
+ <source IP address, source DCCP port, destination IP address,
+ destination DCCP port> DCCP 4-tuples will have different <source IP
+ address, source UDP port, destination IP address, destination UDP
+ port> UDP 4-tuples.
+
+
+
+
+Phelan, et al. Standards Track [Page 9]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+ A DCCP-UDP server SHOULD accept datagrams from any UDP source port.
+ There is a risk that the same DCCP source port number could be used
+ by two endpoints, each behind a NAPT. A DCCP-UDP server MUST
+ therefore demultiplex a DCCP-UDP flow using both the UDP source and
+ destination port numbers and the encapsulated DCCP ports. This
+ ensures than an active DCCP connection is uniquely identified by the
+ 6-tuple <source IP address, source UDP port, source DCCP port,
+ destination IP address, destination UDP port, destination DCCP port>.
+ (The active state of a DCCP connection is defined in Section 3.8: a
+ DCCP connection becomes active following transmission of a DCCP-
+ Request and becomes inactive after sending a DCCP-Close.)
+
+ This demultiplexing at a DCCP-UDP endpoint occurs in two stages:
+
+ 1. In the first stage, DCCP-UDP packets are demultiplexed using the
+ UDP 4-tuple: <source IP address, source UDP port, destination IP
+ address, destination UDP port>.
+
+ 2. In the second stage, a receiving endpoint MUST ensure that two
+ independent DCCP connections that were multiplexed to the same
+ UDP 4-tuple are not associated with the same connection in the
+ DCCP module. The endpoint therefore 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>. Two DCCP endpoint methods are
+ specified. A DCCP-UDP implementation MUST implement exactly one
+ of these:
+
+ * The DCCP server may accept only one active 6-tuple at any one
+ time for a given UDP 4-tuple. In this method, DCCP-UDP
+ packets that do not 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 receives a DCCP-Reset with this reset code will
+ clear its connection state but MAY immediately try again using
+ a different 4-tuple. This provides protection should the same
+ UDP 4-tuple be re-used by multiple DCCP connections, ensuring
+ that only one DCCP connection is established at one time.
+
+ * The DCCP server may support multiple DCCP connections over the
+ same UDP 4-tuple. In this method, the endpoint MUST then
+ associate each 6-tuple with a single DCCP connection. If an
+ endpoint is unable to demultiplex the 6-tuple (e.g., due to
+ internal resource limits), it MUST discard DCCP-UDP packets
+ that do not match an active 6-tuple instead of forwarding them
+ to the DCCP module. The DCCP endpoint MAY send a DCCP-Reset
+
+
+
+
+
+Phelan, et al. Standards Track [Page 10]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+ with Reset Code 12, "Encapsulated Port Reuse", indicating the
+ connection has been closed but may be retried using a
+ different UDP 4-tuple.
+
+3.9. Service Codes and the DCCP Port Registry
+
+ This section clarifies the usage of DCCP Service Codes and the
+ registration of server ports by DCCP-UDP. The section is not
+ intended to update the procedures for allocating Service Codes or
+ server ports.
+
+ There is one Service Code registry and one DCCP port registration
+ that apply to all combinations of encapsulation and IP version. A
+ DCCP Service Code specifies an application using DCCP regardless of
+ the combination of DCCP encapsulation and IP version. An application
+ may choose not to support some combinations of encapsulation and IP
+ version, but its Service Code will remain registered for those
+ combinations, 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] provides additional information about DCCP Service Codes.
+
+ Similarly, a DCCP port registration is applicable to all combinations
+ of encapsulation and IP version. Again, an application may choose
+ not to support some combinations of encapsulation and IP version on
+ its registered DCCP port, although the port will remain registered
+ for those combinations. Applications should not register different
+ DCCP ports just for the purpose of using different combinations of
+ encapsulation.
+
+4. DCCP-UDP and Higher-Layer Protocols
+
+ The encapsulation of a higher-layer protocol within DCCP MUST be the
+ same for both DCCP-STD and DCCP-UDP. Encapsulation of 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 these encapsulations when using DCCP-UDP.
+
+5. Signalling the Use of DCCP-UDP
+
+ Applications often signal transport connection parameters through
+ outside means, such as SDP. Applications that define such methods
+ for DCCP MUST define how the DCCP encapsulation is chosen and MUST
+ allow either encapsulation to be signalled. Where 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 be used to negotiate DCCP sessions, and [RFC5762]
+
+
+
+Phelan, et al. Standards Track [Page 11]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+ defines SDP extensions for signalling the use of an RTP session
+ running over DCCP connections. However, since [RFC5762] predates
+ this document, it does not define a mechanism for signalling that the
+ DCCP-UDP encapsulation is to be used. This section updates [RFC5762]
+ to describe how SDP can be used to signal RTP sessions running over
+ the DCCP-UDP encapsulation.
+
+ The new SDP support specified in this section is expected to be
+ useful when the offering party is on the public Internet or in the
+ same private addressing realm as the answering party. In this case,
+ the DCCP-UDP server has a public address. The client may either have
+ a public address or be behind a NAT/NAPT. This scenario has the
+ potential to be an important use case. Some other NAT/NAPT
+ topologies may result in the advertised port being unreachable via
+ the NAT/NAPT.
+
+5.1. Protocol Identification
+
+ SDP uses a media ("m=") line to convey details of the media format
+ and transport protocol used. The ABNF syntax [RFC5234] of a media
+ line for DCCP is as follows (from [RFC4566]):
+
+ media-field = %x6d "=" media SP port ["/" integer]
+ SP proto 1*(SP fmt) CRLF
+
+ The proto field denotes the transport protocol used for the media,
+ while the port indicates the transport port to which the media is
+ sent, following [RFC5762]. This document defines the following five
+ values of the proto field to indicate media transported using DCCP-
+ UDP encapsulation:
+
+ UDP/DCCP
+
+ UDP/DCCP/RTP/AVP
+
+ UDP/DCCP/RTP/SAVP
+
+ UDP/DCCP/RTP/AVPF
+
+ UDP/DCCP/RTP/SAVPF
+
+ The "UDP/DCCP" protocol identifier is similar to the "DCCP" protocol
+ identifier defined in [RFC5762] and denotes the DCCP transport
+ protocol encapsulated in UDP, but not its upper-layer protocol.
+
+ The "UDP/DCCP/RTP/AVP" protocol identifier refers to RTP using the
+ RTP Profile for Audio and Video Conferences with Minimal Control
+ [RFC3551] running over the DCCP-UDP encapsulation.
+
+
+
+Phelan, et al. Standards Track [Page 12]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+ The "UDP/DCCP/RTP/SAVP" protocol identifier refers to RTP using the
+ Secure Real-time Transport Protocol [RFC3711] running over the DCCP-
+ UDP encapsulation.
+
+ The "UDP/DCCP/RTP/AVPF" protocol identifier refers to RTP using the
+ Extended RTP Profile for RTCP-based Feedback [RFC4585] running over
+ the DCCP-UDP encapsulation.
+
+ The "UDP/DCCP/RTP/SAVPF" protocol identifier refers to RTP using the
+ Extended Secure RTP Profile for RTCP-based Feedback [RFC5124] running
+ over the DCCP-UDP encapsulation.
+
+ The fmt value in the "m=" line is used as described in [RFC5762].
+
+ The port number specified in the "m=" line indicates the UDP port
+ that is 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.
+
+ The use of ports with DCCP-UDP encapsulation is described further in
+ Section 3.8.
+
+5.2. Signalling Encapsulated DCCP Ports
+
+ When using DCCP-UDP, the UDP port used for the encapsulation is
+ signalled using the SDP "m=" line. The DCCP ports MUST NOT be
+ included in the "m=" line but are instead signalled using a new SDP
+ attribute ("dccp-port") defined according to the following ABNF:
+
+ dccp-port-attr = %x61 "=dccp-port:" dccp-port
+
+ dccp-port = 1*DIGIT
+
+ where DIGIT 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 when the protocol
+ identifiers described in Section 5.1 are used.
+
+ The use of ports with DCCP-UDP encapsulation is described further in
+ Section 3.8.
+
+ o If the "a=rtcp:" attribute [RFC3605] is used, then the signalled
+ port is the DCCP port used for RTCP.
+
+ o If the "a=rtcp-mux" attribute [RFC5761] is negotiated, then RTP
+ and RTCP are multiplexed onto a single DCCP port; otherwise,
+ separate DCCP ports are used for RTP and RTCP [RFC5762].
+
+
+
+
+Phelan, et al. Standards Track [Page 13]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+ NOTE: In each case, only a single UDP port is used for the DCCP-
+ UDP encapsulation.
+
+ o 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 will be rejected. For this reason, using "a=rtcp-mux" is
+ RECOMMENDED when using RTP over DCCP-UDP.
+
+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
+
+ An endpoint that supports both native DCCP and the DCCP-UDP
+ encapsulation may wish to signal support for both options in an SDP
+ offer, allowing the answering party the option of using native DCCP
+ where possible, while falling back to the DCCP-UDP encapsulation
+ otherwise.
+
+ An approach to doing this might be to include candidates for the
+ DCCP-UDP encapsulation and native DCCP into an Interactive
+ Connectivity Establishment (ICE) [RFC5245] exchange. Since DCCP is
+ connection-oriented, these candidates would need to be encoded into
+ ICE in a manner analogous to TCP candidates defined in [RFC6544].
+ Both active and passive candidates could be supported for native DCCP
+ and DCCP-UDP encapsulation, as may DCCP simultaneous-open candidates
+ [RFC5596]. In choosing local preference values, it may make sense to
+ prefer DCCP-UDP over native DCCP in cases where low connection setup
+ time is important and to prioritise native DCCP in cases where low
+ overhead is preferred (on the assumption that DCCP-UDP is more likely
+ to work through legacy NAT but has higher overhead). The details of
+ this encoding into ICE are left for future study.
+
+ While ICE is appropriate for selecting basic use of DCCP-UDP versus
+ DCCP-STD, it may not be appropriate for negotiating different RTP
+ profiles with each transport encapsulation. The SDP Capability
+ Negotiation framework [RFC5939] may be more suitable. Section 3.7 of
+ RFC 5939 specifies how to provide attributes and transport protocols
+ as capabilities and negotiate them using the framework. The details
+ of the use of SDP Capability Negotiation with DCCP are left for
+ future study.
+
+
+
+
+
+
+Phelan, et al. Standards Track [Page 14]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+5.5. Example of SDP Use
+
+ The example below shows an SDP offer, where an application signals
+ support for 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:new
+
+ The answering party at 192.0.2.128 receives this offer and responds
+ with the following 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:new
+
+ Note that the "m=" line in the answer includes the UDP port number of
+ the encapsulation service. The DCCP service code is set to "RTPV",
+ signalled using the "a=dccp-service-code" attribute [RFC5762]. The
+ "a=dccp-port:" attribute in the answer is set to 9 (the discard port)
+ in the usual manner for an active connection-oriented endpoint.
+
+ The answering party will then attempt to establish a DCCP-UDP
+ connection to the offering party. The connection request will use an
+ ephemeral DCCP source port and DCCP destination port 5004. The UDP
+ packet encapsulating that request will have UDP source port 40123 and
+ UDP destination port 50234.
+
+
+
+
+
+
+
+Phelan, et al. Standards Track [Page 15]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+6. Security Considerations
+
+ DCCP-UDP provides all of the security risk-mitigation measures
+ present in DCCP-STD and also all of the security risks. It does not
+ maintain additional state at the encapsulation layer.
+
+ The tunnel encapsulation recommends processing of ICMP messages
+ received for packets sent using DCCP-UDP and translation to allow use
+ by DCCP. [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 purpose of
+ DCCP-UDP is to allow DCCP to pass through NAT/NAPT devices;
+ therefore, it exposes DCCP to the risks associated with passing
+ through NAT devices. It does not create any new risks with regard to
+ NAT/NAPT devices.
+
+ DCCP-UDP may also allow DCCP applications to pass through existing
+ firewall devices using rules for UDP, if the administrators of the
+ devices so choose. A simple use may either allow all DCCP
+ applications or allow none.
+
+ A firewall that interprets this specification could inspect the
+ encapsulated DCCP header to filter based on the inner DCCP header
+ information. Full control of DCCP connections by applications will
+ require enhancements to firewalls, as discussed in [RFC4340] and
+ related RFCs (e.g., [RFC5595]).
+
+ Datagram Transport Layer Security (DTLS) provides mechanisms that can
+ be used to provide security protection for the encapsulated DCCP
+ packets. DTLS may be used in two ways:
+
+ o 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.
+
+ o 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.
+
+
+
+
+
+
+
+
+
+
+Phelan, et al. Standards Track [Page 16]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+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 are carried by a DCCP Reset. For this reset
+ code, these are defined as follows:
+
+ o Data byte 1: The DCCP Packet Type of the DCCP datagram that
+ resulted in the error message.
+
+ o 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.1
+
+
+
+
+
+
+
+Phelan, et al. Standards Track [Page 17]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+8. 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.
+
+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.
+
+
+
+
+
+Phelan, et al. Standards Track [Page 18]
+
+RFC 6773 DCCP-UDP Encapsulation November 2012
+
+
+ [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.
+
+
+
+
+
+
+
+Phelan, et al. Standards Track [Page 19]
+
+RFC 6773 DCCP-UDP Encapsulation November 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/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Phelan, et al. Standards Track [Page 20]
+