[dccp] New revision of The DCCP Service Code
Dear all, I've just posted a new revision of the Service Codes draft. This version contains the result of some discussion on the IANA procedures and some editorial work to prepare this for a WGLC. I'd appreciate inputs from those interested in the IANA procedures to help determine if the text reflects the new procedures intended for DCCP - this change should ideally track the changes proposed for UDP, TCP, etc - but also needs to clarify some of the things presented in RFC 4340. I hope the draft will appear soon, Best wishes, Gorry (as a document author)
[dccp] I-D Action:draft-ietf-dccp-simul-open-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Datagram Congestion Control Protocol Working Group of the IETF. Title : DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal Author(s) : G. Fairhurst, G. Renker Filename: draft-ietf-dccp-simul-open-00.txt Pages : 25 Date: 2008-02-18 This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update assists DCCP applications which need to communicate through one or more middleboxes (e.g. Network Address Translators or firewalls), where establishing necessary middlebox state requires peering endpoints to initiate communication in a near-simultaneous manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dccp-simul-open-00.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-ietf-dccp-simul-open-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-ietf-dccp-simul-open-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-dccp-simul-open-00.txt
Re: [dccp] draft-phelan-dccp-natencap-00.txt
Hi Colin, So there are two independent threads to your comment below -- one, is what DCCP-NAT is trying to achieve worthwhile? And two, what's the best way to go about it? On the first issue, I'd love to hear your detailed thinking. What got me thinking seriously about the need for DCCP-NAT was draft-iab-protocol-success. One of the factors for initial success that it points out is incremental deployment. DCCP-RAW doesn't have that. For DCCP-RAW to be useable in the general Internet, it requires entities that have nothing to gain from DCCP deployment to make changes (the NAT vendors). Some people argue that there are some market pressures that could pull the NAT vendors to support DCCP, but I see these scenarios as having slim chance of success. It didn't seem to me to be too difficult to define a UDP-encapsulation for DCCP that would be supported by NATs, and the potential benefit of that support seems much greater than the effort to me. Some of these benefits seem very near-term to me. For example, it's currently very difficult for me (and most other people too, I think) to offer a DCCP demo application that can be accessed by a large public. I have no easy access to a host outside of a NAT on which I can run arbitrary code. On the other hand, I have no problem finding hosts behind NATs on which I can do absolutely anything I desire. So with DCCP-NAT it's much easier to expand the group of people experimenting with DCCP and also expand the opportunities for interactions among the various groups. Of course just having DCCP-NAT will hardly be the one thing that breaks DCCP into wild (or even initial) success, but I do believe it will make early experimentation easier and will be necessary (but not sufficient) for eventual initial success. As far as the second issue, I'll put that in another e-mail. Tom P. -Original Message- From: Colin Perkins [mailto:[EMAIL PROTECTED] Sent: Sunday, February 17, 2008 9:57 AM To: Phelan, Tom Cc: Ian McDonald; 'dccp' working group Subject: Re: [dccp] draft-phelan-dccp-natencap-00.txt Hi, On 14 Feb 2008, at 20:13, Phelan, Tom wrote: It's definitely my intention that DCCP-NAT happens in the end nodes. It isn't intended to be some middlebox intercepting a DCCP stream and converting it. The end nodes originate the packets with DCCP-NAT encapsulation. I'll try to make that more clear in the next revision. Nice to hear about NAT for DCCP(-RAW) in Linux. To expand a bit on the above paragraph, I wouldn't expect DCCP-NAT in Linux to be implemented below the DCCP layer as I imagine NAT for DCCP is. In my view, the encapsulation to use (NAT, RAW, IPv4, IPv6) is chosen by the application and implemented (mostly) within the DCCP layer. Allowing the application to choose runs into connectivity problems when some applications support the UDP encapsulation, and some do not. If we're going to define a UDP encapsulation - and it's not at all clear to me that such a thing is a good idea - then I'd recommend that we do so in a way that it can be done by the DCCP stack, transparently to the applications, with a well-defined order for trying native vs. encapsulated connection requests. -- Colin Perkins http://csperkins.org/
Re: [dccp] draft-phelan-dccp-natencap-00.txt
Hi Colin, On the second issue in your e-mail, whether the NAT traversal mode of DCCP should be transparent to applications or not: There were a few issues that drove me towards application visibility. I felt that applications would want to know directly that NAT traversal mode was available or not and that it would be used or not. This is similar to why I perceive TLS is more popular with apps than IPsec. Apps could migrate to IPsec without making changes, yet they seem to prefer TLS. There are perhaps many reasons for this, but I think one of them is because TLS gives them more visible and direct control over what's going on. Perhaps this thinking doesn't apply here -- if NAT traversal mode were widely available in DCCP implementations and the negotiation to choose a mode was efficient then apps wouldn't care. But my initial take was that the added complexity and the likely time involved in settling on an encapsulation (if your first guess was wrong) were enough disadvantages to argue for the no-negotiation approach. Another issue with automatic negotiation is that apps that used another signaling protocol to rendezvous (such as SIP/SDP) would need to carry info for all encaps, even when they knew they needed only one (they'd need to carry the UDP port of the DCCP-NAT service, plus the DCCP port). How big an issue this is, since we're at the very early stages of defining any of these protocols, is debatable. The case isn't absolute though, so I'm perfectly willing to listen to counterarguments. Tom P. -Original Message- From: Colin Perkins [mailto:[EMAIL PROTECTED] Sent: Sunday, February 17, 2008 9:57 AM To: Phelan, Tom Cc: Ian McDonald; 'dccp' working group Subject: Re: [dccp] draft-phelan-dccp-natencap-00.txt Hi, On 14 Feb 2008, at 20:13, Phelan, Tom wrote: It's definitely my intention that DCCP-NAT happens in the end nodes. It isn't intended to be some middlebox intercepting a DCCP stream and converting it. The end nodes originate the packets with DCCP-NAT encapsulation. I'll try to make that more clear in the next revision. Nice to hear about NAT for DCCP(-RAW) in Linux. To expand a bit on the above paragraph, I wouldn't expect DCCP-NAT in Linux to be implemented below the DCCP layer as I imagine NAT for DCCP is. In my view, the encapsulation to use (NAT, RAW, IPv4, IPv6) is chosen by the application and implemented (mostly) within the DCCP layer. Allowing the application to choose runs into connectivity problems when some applications support the UDP encapsulation, and some do not. If we're going to define a UDP encapsulation - and it's not at all clear to me that such a thing is a good idea - then I'd recommend that we do so in a way that it can be done by the DCCP stack, transparently to the applications, with a well-defined order for trying native vs. encapsulated connection requests. -- Colin Perkins http://csperkins.org/
