One document matched: draft-ietf-dccp-udpencap-00.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd'>
<rfc ipr='trust200902' docName='draft-ietf-dccp-udpencap-00' category='exp'>
<?rfc toc="yes"?> <!-- generate a table of contents -->
<?rfc symrefs="yes"?> <!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?> <!-- alphabetize the references -->
<?rfc compact="yes" ?> <!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?> <!-- but keep a blank line between list items -->
<front>
<title abbrev='DCCP-NAT Encapsulation'>
Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-NAT)
</title>
<author initials='T.' surname='Phelan' fullname='Tom Phelan'>
<organization abbrev='Sonus'>
Sonus Networks
</organization>
<address>
<postal>
<street>7 Technology Dr.</street>
<city>Westford</city> <region>MA</region>
<code>01886</code>
<country>US</country>
</postal>
<phone>+1 978 614 8456</phone>
<email>tphelan@sonusnet.com</email>
</address>
</author>
<date month='February' year='2010' />
<area>Transport</area>
<workgroup>Datagram Congestion Control Protocol</workgroup>
<abstract>
<t>This document specifies an alternative encapsulation of the Datagram
Congestion Control Protocol (DCCP), referred to as DCCP-NAT. This
encapsulation will allow DCCP to be carried through the current generation
of Network Address Translation (NAT) middleboxes without modification of
those middleboxes.</t>
</abstract>
</front>
<middle>
<section toc='include' title='Introduction'>
<t>The Datagram Congestion Control Protocol (DCCP), specified in
<xref target="RFC4340" />, is
a transport-layer protocol that provides upper layers with the capability of
using unreliable but congestion controlled flows. According to
<xref target="RFC4340" />,
DCCP packets are directly encapsulated in IPv4 or IPv6 packets.</t>
<t>In order for the <xref target="RFC4340" />
encapsulation to pass through Network Address
Translation (NAT) devices, these devices must be updated to recognize and
properly modify DCCP. This is the long-term objective for DCCP, and work is
underway to specify the necessary operations.</t>
<t>However, in the short term it would be useful to have an encapsulation for
DCCP that would be compatible with NAT devices conforming to
<xref target="RFC4787" />. This
document specifies that encapsulation, which is referred to as DCCP-NAT. For
convenience, the
<xref target="RFC4340" /> encapsulation is referred to as DCCP-STD.</t>
<t>The DCCP-NAT encapsulation specified here supports all of the features
contained in DCCP-STD. However, support of partial checksums and ECN might be
impractical for some implementations. Those implementations MAY choose to not
support one or both of these features.</t>
</section>
<section toc='include' title='Terminology'>
<t>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 <xref target="RFC2119" />.</t>
</section>
<section toc='include' title='DCCP-NAT'>
<t>The basic approach here is to insert a UDP
(<xref target="RFC0768" />) "shim" layer between
the IP header and a DCCP packet with a modified generic header (modified to
eliminate redundancies between UDP and DCCP). Note that this is not strictly
a tunneling approach. The IP addresses of the communicating end systems are
carried in the IP header (which could be modified by NAT devices) and there are
no other IP addresses embedded.</t>
<t>Devices offering or using DCCP services via DCCP-NAT encapsulation listen on
a UDP port (default port awaiting IANA action) for incoming packets and pass
received packets along to the DCCP protocol. DCCP implementations MAY allow
services to be simultaneously offered over any or all combinations of DCCP-STD
and DCCP-NAT encapsulations with IPv4 and IPv6.</t>
<t>The basic format of a DCCP-NAT packet is:</t>
<figure><artwork>
+-----------------------------------+
| IP Header (IPv4 or IPv6) | Variable length
+-----------------------------------+
| UDP Header | 8 bytes
+-----------------------------------+
| DCCP-NAT Generic Header | 12 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)
+-----------------------------------+
</artwork></figure>
<section toc='include' title='UDP Header'>
<t>The format of the UDP header is taken from <xref target="RFC0768" />:</t>
<figure><artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<t>For DCCP-NAT, the fields are interpreted as follows:</t>
<t>Source and Dest(ination) Ports: 16 bits each</t>
<list style='empty'>
<t>These fields identify the UDP ports on which the source and destination
(respectively) of the packet are listening for incoming DCCP-NAT packets
(normally both are the default port to be assigned by IANA). Note that
they do not identify the DCCP source and destination ports.</t>
</list>
<t>Length: 16 bits</t>
<list stye='empty'>
<t>This field is the length of the portion of the UDP datagram, including
the UDP header and the payload (which for DCCP-NAT is the DCCP-NAT
datagram) that is covered by the UDP Checksum.</t>
</list>
<t>Checksum: 16 bits</t>
<list style='empty'>
<t>This field is the Internet checksum of a network-layer pseudoheader and
Length bytes of the UDP packet.</t>
</list>
</section>
<section toc='include' title='DCCP-NAT Generic Header'>
<t>Unlike the DCCP-STD generic header, the DCCP-NAT generic header takes
only one form; it does not support short sequence numbers. Its format is
as follows:</t>
<figure><artwork>
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 | Type | Sequence Number (high bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sequence Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<t>All DCCP-NAT generic header fields function as specified in
[RFC4340].</t>
</section>
<section toc='include' title='DCCP-NAT Checksum Procedures'>
<t>For DCCP-NAT, the functions of the DCCP-STD generic header fields
Checksum and CsCov are performed by the UDP Checksum and Length fields.</t>
<t>If the UDP Length field is less than 20 (UDP Header length and minimum
DCCP-NAT header length), the packet MUST be dropped.</t>
<t>If the UDP Checksum field, computed using standard UDP methods except
including only UDP Length bytes of the UDP packet, is invalid, the packet
MUST be dropped.</t>
<t>If the UDP Length field in a received packet is less than the length of
the UDP header plus the entire DCCP-NAT header (including the generic
header and type-specific fields and options, if present), or 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, that packet MUST be dropped.</t>
<section toc='include' title='Minimum Checksum Coverage Feature'>
<t>The Minimum Checksum Coverage Feature lets a DCCP endpoint determine
whether its peer is willing to accept packets with partial checksum
coverage. It takes values from 0 to 15. For DCCP-NAT the feature
values are interpreted as follows:</t>
<list style='symbols'>
<t>Minimum Checksum Coverage = 0, the peer will not accept packets
with partial checksum. If the UDP Length field is less than the
length of the entire UDP packet, then the packet has unacceptable
Checksum Coverage, as defined in DCCP-STD section 9.2.1.</t>
<t>Minimum Checksum Coverage > 0, the peer will accept packets with
partial checksum. If the UDP Length field is less than the size of
the UDP Header (8 bytes) plus the size of the DCCP-NAT header
(including type-specific fields and options) plus (Minimum Checksum
Coverage - 1)*4, then the packet has unacceptable Checksum
Coverage.</t>
</list>
<t>As defined in DCCP-STD section 9.2.1, peers MAY refuse to process
packets with unacceptable Checksum Coverage.</t>
<t>It might be impractical for an implementation to set the UDP Length
field to less than the full length in outgoing packets or to receive
incoming packets with UDP Length less than the full length (e.g.,
user-space implementations using the socket interface). These
implementations MAY choose to not support Minimum Checksum Coverage
values other than 0. Implementations that make this choice MUST always
answer a "Change R(Minimum Checksum Coverage, any value)" with a
"Confirm L(Minimum Checksum Coverage, 0)". These implementations MAY
choose to drop packets with UDP Length less than the full packet length,
rather invoke the procedures of DCCP-STD section 9.2.1.</t>
</section>
</section>
<section toc='include' title='Explicit Congestion Notification'>
<t>DCCP-NAT implementations SHOULD follow the procedures of DCCP-STD section
12 by setting the ECN fields in the IP Headers of outgoing packets and
examining the values received in the ECN fields of incoming packets.</t>
<t>However, some implementations might find it impractical to set or receive
the ECN fields (e.g., user-space implementations using the socket
interface). These implementations MUST follow the procedures in DCCP-STD
section 12.1 for implementations that are not ECN capable.</t>
</section>
<section toc='include' title='Path Maximum Transmission Unit Discovery'>
<t>DCCP-NAT implementations should follow DCCP-STD section 14 with regard to
maximum packet size and Path Maximum Transmission Unit Discovery (PMTUD).</t>
</section>
<section toc='include' title='Other DCCP Headers and Options'>
<t>All type-specific DCCP headers are as in DCCP-STD, except that the short
sequence number version of the acknowledgement header is not supported. All
option and feature encodings are as in DCCP-STD.</t>
</section>
<section toc='include' title='Service Codes and the DCCP Port Registry'>
<t>There is one Service Code registry and one DCCP port registry and they
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 MUST NOT be used by other
applications. An application SHOULD NOT register different Service Codes
for different combinations of encapsulation and IP version.</t>
<t>Similarly, a 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
port, although the port will remain registered for those combinations.
Applications SHOULD NOT register different ports just for the purpose of
using different encapsulation combinations. Since the port registry
supports multiple applications registering the same port (as long as the
Service Codes are different), other applications MAY register on the same
port, but those registrations are also applicable to all combinations of
encapsulation and IP version.</t>
</section>
</section>
<section toc='include' title='DCCP-NAT and Higher-Layer Protocols'>
<t>In general, the encapsulation of a higher-layer protocol within DCCP SHOULD
be the same in both DCCP-STD and DCCP-NAT. At this time, encapsulations of DTLS
over DCCP, defined in
<xref target="RFC5238" /> and RTP over DCCP, defined in
<xref target="I-D.ietf-dccp-rtp" />, have
been already defined. The encapsulations of those protocols in DCCP-NAT SHALL
be the same as specified in those documents.</t>
<t>Higher-layer protocols that require different encapsulations for different
DCCP modes MUST justify the reasons for the difference and MUST specify the
encapsulations for both DCCP-STD and DCCP-NAT. If a document does not specify
different encapsulations for DCCP-STD and DCCP-NAT, the specified encapsulation
SHALL apply to both DCCP-STD and DCCP-NAT.</t>
</section>
<section toc='include' title='Signaling the Use of DCCP-NAT'>
<t>Applications often signal transport connection parameters through outside
means, such as the Session Description Protocol (SDP). Applications that define
such methods for DCCP MUST define how the DCCP encapsulation is chosen, and MUST
allow either type of encapsulation to be signaled.</t>
<section toc='include' title='SDP for RTP over DCCP' anchor='sdp'>
<t><xref target="I-D.ietf-dccp-rtp" />
defines SDP extensions for signaling RTP over DCCP connections.
Since it predates this document, it does not define a method for determining
the DCCP encapsulation type. This document updates
<xref target="I-D.ietf-dccp-rtp" /> to add a method
for determining the DCCP encapsulation type.</t>
<t>A new SDP attribute "dccp-encap" is defined for signaling the DCCP
encapsulation according to the following ABNF <xref target="RFC5234" />:</t>
<figure><artwork>
dccp-encap-attr = %x61 "=dccp-in-udp" [":" udp-port-num]
udp-port-num = *DIGIT
</artwork></figure>
<t>where *DIGIT is as defined in <xref target="RFC5234" />.</t>
<t>The presence of "a=dccp-in-udp" in an SDP offer indicates that the offerer
is listening for DCCP-NAT connections on the indicated UDP port (if udp-port-num
is included) or on the IANA allocated port for the DCCP-NAT service if no port
is included.</t>
<t>The absence of "a=dccp-in-udp" in an SDP offer indicates that the offerer is
listening for DCCP-STD connections. The presence of "a=dccp-in-udp" conveys no
information about whether or not the offerer is listening for DCCP-STD
connections.</t>
<t>For example (adapted from examples in
<xref target="I-D.ietf-dccp-rtp" />):</t>
<t>An offerer at 192.0.2.47 signals its availability for an H.261 video session,
using RTP/AVP over DCCP with service code "RTPV" (using the hexadecimal encoding
of the service code in the SDP). RTP and RTCP packets are multiplexed onto a
single DCCP connection and DCCP-NAT encapsulation is supported:</t>
<figure><artwork>
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 5004 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x52545056
a=setup:passive
a=connection:new
a=dccp-in-udp
</artwork></figure>
<t>An answerer at 192.0.2.128 receives this offer and responds with the
following answer:</t>
<figure><artwork>
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 9 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC:RTPV
a=setup:active
a=connection:new
a=dccp-in-udp
</artwork></figure>
<t>The end point at 192.0.2.128 then initiates a DCCP-NAT connection to UDP port
to-be-allocated and DCCP port 5004 at 192.0.2.47. DCCP port 5004 is used for both
the RTP and RTCP data, and port 5005 is unused. The textual encoding of
the service code is used in the answer, and represents the same service
code as in the offer.</t>
</section>
</section>
<section toc='include' title='Security Considerations'>
<t>DCCP-NAT provides all of the security risk-mitigation measures present in
DCCP-STD, and also all of the security risks, except those associated with short
sequence numbers (since DCCP-NAT does not support that feature).</t>
<t>The purpose of DCCP-NAT is to allow DCCP to pass through NAT devices, and
therefore it exposes DCCP to the risks associated with passing through NAT
devices. It does not create any new risks with regard to NAT devices.</t>
<t>DCCP-NAT may also allow DCCP applications to pass through existing firewall
devices, if the administrators of the devices so choose. The option is a
binary one however; either allow all DCCP applications or allow none. Proper
control of DCCP application-by-application will require enhancements to
firewalls.</t>
</section>
<section toc='include' title='IANA Considerations'>
<t>A port allocation request will be placed with IANA for the dccp-nat service
port in UDP.</t>
<t>The following new SDP attribute ("att-field") is to be registered:</t>
<list style='empty'>
<t>Contact name: Tom Phelan <tphelan@sonusnet.com></t>
<t>Attribute name: dccp-in-udp</t>
<t>Long-form attribute name in English: DCCP in UDP Encapsulation</t>
<t>Type of attribute: Media level</t>
<t>Subject to charset attribute? No</t>
<t>Purpose of the attribute: See this document section <xref target="sdp" /></t>
<t>Allowed attribute values: See this document section <xref target="sdp" /></t>
</list>
</section>
</middle>
<back>
<references>
<?rfc sortrefs="yes"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.4340.xml"?>
<?rfc include="reference.RFC.0768.xml"?>
<?rfc include="reference.RFC.4787.xml"?>
<?rfc include="reference.RFC.5238.xml"?>
<?rfc include="reference.RFC.5234.xml"?>
<?rfc include="reference.I-D.ietf-dccp-rtp.xml"?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 22:11:09 |