draft-ietf-dccp-udpencap-09.txt   draft-ietf-dccp-udpencap-10.txt 
DCCP Working Group T. Phelan DCCP Working Group T. Phelan
Internet-Draft Sonus Internet-Draft Sonus
Intended status: Standards Track G. Fairhurst Intended status: Standards Track G. Fairhurst
Expires: January 14, 2012 University of Aberdeen Expires: September 27, 2012 University of Aberdeen
C. Perkins C. Perkins
University of Glasgow University of Glasgow
July 13, 2011 March 26, 2012
Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT
Traversal (DCCP-UDP) Traversal (DCCP-UDP)
draft-ietf-dccp-udpencap-09 draft-ietf-dccp-udpencap-10
Abstract Abstract
This document specifies an alternative encapsulation of the Datagram This document specifies an alternative encapsulation of the Datagram
Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This
encapsulation allows DCCP to be carried through the current encapsulation allows DCCP to be carried through the current
generation of Network Address Translation (NAT) middleboxes without generation of Network Address Translation (NAT) middleboxes without
modification of those middleboxes. This document also updates the modification of those middleboxes. This document also updates the
SDP information for DCCP defined in RFC 5762. SDP information for DCCP defined in RFC 5762.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2012. This Internet-Draft will expire on September 27, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3.8. Usage of the UDP port by DCCP-UDP . . . . . . . . . . . . 8 3.8. Usage of the UDP port by DCCP-UDP . . . . . . . . . . . . 8
3.9. Service Codes and the DCCP Port Registry . . . . . . . . . 10 3.9. Service Codes and the DCCP Port Registry . . . . . . . . . 10
4. DCCP-UDP and Higher-Layer Protocols . . . . . . . . . . . . . 10 4. DCCP-UDP and Higher-Layer Protocols . . . . . . . . . . . . . 10
5.1. Protocol Identification . . . . . . . . . . . . . . . . . 11 5.1. Protocol Identification . . . . . . . . . . . . . . . . . 11
5.2. Signalling Encapsulated DCCP Ports . . . . . . . . . . . . 12 5.2. Signalling Encapsulated DCCP Ports . . . . . . . . . . . . 12
5.3. Connection Management . . . . . . . . . . . . . . . . . . 13 5.3. Connection Management . . . . . . . . . . . . . . . . . . 13
5.4. Negotiating the DCCP-UDP encapsulation versus native 5.4. Negotiating the DCCP-UDP encapsulation versus native
DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Example of SDP use . . . . . . . . . . . . . . . . . . . . 14 5.5. Example of SDP use . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. UDP Port Allocation . . . . . . . . . . . . . . . . . . . 16 7.1. UDP Port Allocation . . . . . . . . . . . . . . . . . . . 15
7.2. DCCP Reset . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. DCCP Reset . . . . . . . . . . . . . . . . . . . . . . . . 15
7.3. SDP Attribute Allocation . . . . . . . . . . . . . . . . . 17 7.3. SDP Attribute Allocation . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Datagram Congestion Control Protocol (DCCP), specified in The Datagram Congestion Control Protocol (DCCP), specified in
[RFC4340], is a transport-layer protocol that provides upper layers [RFC4340], is a transport-layer protocol that provides upper layers
with the ability to use non-reliable congestion-controlled flows. with the ability to use non-reliable congestion-controlled flows.
The current specification for DCCP [RFC4340] specifies a direct The current specification for DCCP [RFC4340] specifies a direct
encapsulation in IPv4 or IPv6 packets. encapsulation in IPv4 or IPv6 packets.
[RFC5597] specifies how DCCP should be handled by devices that use [RFC5597] specifies how DCCP should be handled by devices that use
skipping to change at page 13, line 36 skipping to change at page 13, line 36
The "a=setup:" attribute is used in a manner compatible with The "a=setup:" attribute is used in a manner compatible with
[RFC5762] Section 5.3 to indicate which of the DCCP-UDP endpoints [RFC5762] Section 5.3 to indicate which of the DCCP-UDP endpoints
should initiate the DCCP-UDP connection establishment. should initiate the DCCP-UDP connection establishment.
5.4. Negotiating the DCCP-UDP encapsulation versus native DCCP 5.4. Negotiating the DCCP-UDP encapsulation versus native DCCP
An endpoint that supports both native DCCP and the DCCP-UDP An endpoint that supports both native DCCP and the DCCP-UDP
encapsulation may wish to signal support for both options in an SDP encapsulation may wish to signal support for both options in an SDP
offer, allowing the answering party the option of using native DCCP offer, allowing the answering party the option of using native DCCP
where possible, while falling back to the DCCP-UDP encapsulation where possible, while falling back to the DCCP-UDP encapsulation
otherwise. One approach to doing this is to include candidates for otherwise.
the DCCP-UDP encapsulation and for native DCCP into an ICE [RFC5245]
exchange.
DCCP candidates (native or encapsulated) are encoded into An approach to doing this might be to include candidates for the
"a=candidate:" lines in a manner similar to TCP candidates [ICE-TCP]. DCCP-UDP encapsulation and native DCCP into an Interactive
However, the transport protocol (i.e., the value of the transport- Connectivity Establishment (ICE) [RFC5245] exchange. Since DCCP is
extension token defined in [RFC5245] Section 15.1) is set to either connection-oriented, these candidates would need to be encoded into
"DCCP" for native DCCP flows or "UDP/DCCP" for DCCP-UDP encapsulated ICE in a manner analogous to TCP candidates defined in [ICE-TCP].
flows. The connection type (active, passive, or simultaneous open) Both active and passive candidates could be supported for native
is encoded using extension attributes in the same way as is done for DCCPx and DCCP-UDP encapsulation, as may DCCP simultaneous
TCP candidates. open[RFC5596]. In choosing local preference values, it may make
sense to 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 offer SHOULD contain active and passive candidates for both The details of this encoding into ICE are left for future study.
native DCCP and DCCP-UDP encapsulation. If [RFC5596] is supported,
then simultaneous open candidates SHOULD be obtained for native DCCP
and the DCCP-UDP encapsulation. Server reflexive and relayed
candidates MAY be obtained if mechanisms exist to establish these
candidates. The direction is encoded into SDP using a new dccptype
extension to the a=candidate attribute, analogous to the tcptype
extension defined in [ICE-TCP]. Native DCCP candidates are host
candidates, and SHOULD have preference value of 126, following
[RFC5245] section 4.1.2. DCCP-UDP candidates SHOULD have preference
set to 75, matching the UDP-tunneled candidate priority defined in
[ICE-TCP] Section 4.2. The direction-pref part of the local-
preference SHOULD be set following Section 4.2 of [ICE-TCP]. It
makes sense to choose local preference values 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).
5.5. Example of SDP use 5.5. Example of SDP use
The example below shows an SDP offer, where an application signals The example below shows an SDP offer, where an application signals
support for both native DCCP and for DCCP-UDP: support for DCCP-UDP:
v=0 v=0
o=alice 1129377363 1 IN IP4 192.0.2.47 o=alice 1129377363 1 IN IP4 192.0.2.47
s=- s=-
c=IN IP4 192.0.2.47 c=IN IP4 192.0.2.47
t=0 0 t=0 0
m=video 50234 UDP/DCCP/RTP/AVP 99 m=video 50234 UDP/DCCP/RTP/AVP 99
a=rtpmap:99 h261/90000 a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x52545056 a=dccp-service-code:SC=x52545056
a=dccp-port:5004 a=dccp-port:5004
a=rtcp:5005 a=rtcp:5005
skipping to change at page 15, line 16 skipping to change at page 15, line 5
signalled using the "a=dccp-service-code" attribute [RFC5762]. The signalled using the "a=dccp-service-code" attribute [RFC5762]. The
"a=dccp-port:" attribute in the answer is set to 9 (the discard port) "a=dccp-port:" attribute in the answer is set to 9 (the discard port)
in the usual manner for an active connection-oriented endpoint. in the usual manner for an active connection-oriented endpoint.
The answering party will then attempt to establish a DCCP-UDP The answering party will then attempt to establish a DCCP-UDP
connection to the offering party. The connection request will use an connection to the offering party. The connection request will use an
ephemeral DCCP source port and DCCP destination port 5004. The UDP ephemeral DCCP source port and DCCP destination port 5004. The UDP
packet encapsulating that request will have UDP source port 40123 and packet encapsulating that request will have UDP source port 40123 and
UDP destination port 50234. UDP destination port 50234.
The example below shows how ICE can be used in an SDP offer:
v=0
o=jdoe 2890844526 IN IP4 10.0.1.1
s=-
c=IN IP4 192.0.2.3
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 UDP/DCCP/RTP/AVP 0
a=dccp-service-code:SC:RTPA
a=dccp-port:5004
a=setup:active
a=connection:new
b=RS:0
b=RR:0
a=candidate:1 1 DCCP <pref> 10.0.1.1 9 typ host dccptype act
a=candidate:2 1 UDP/DCCP <pref> 10.0.1.1 9 typ host dccptype act
XXX NOTE: Reviewer needed to confirm preference encoding XXX
6. Security Considerations 6. Security Considerations
DCCP-UDP provides all of the security risk-mitigation measures DCCP-UDP provides all of the security risk-mitigation measures
present in DCCP-STD, and also all of the security risks. present in DCCP-STD, and also all of the security risks.
The purpose of DCCP-UDP is to allow DCCP to pass through NAT/NAPT The purpose of DCCP-UDP is to allow DCCP to pass through NAT/NAPT
devices, and therefore it exposes DCCP to the risks associated with devices, and therefore it exposes DCCP to the risks associated with
passing through NAT devices. It does not create any new risks with passing through NAT devices. It does not create any new risks with
regard to NAT/NAPT devices. regard to NAT/NAPT devices.
 End of changes. 11 change blocks. 
64 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/