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 17 ¶ | 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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |