Hi Dan, The SRV thing seems like a good way to go about finding out whether to use DCCP-RAW or DCCP-NAT, especially considering that we haven't defined anything about SRV records for DCCP yet. Do we need to do something about this in the DCCP-NAT draft? Tom P. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Tuesday, February 19, 2008 1:44 PM > To: 'Colin Perkins'; Phelan, Tom > Cc: ''dccp' working group' > Subject: RE: DCCP-over-UDP [was draft-phelan-dccp-natencap-00.txt] > > > I essentially agree with all your arguments below. There's a > > clear short term benefit to having a UDP encapsulation for > > DCCP to ease NAT traversal. This is the incremental > > deployment argument from draft-iab-protocol-success, and also > > the argument made in draft-rosenberg-internet-waist-hourglass. > > > > There's also a significant, long-term, architectural penalty > > from encouraging the two existing transport protocols (TCP > > and UDP) to become the new waist of the Internet. We don't > > want to tunnel DCCP over UDP: it's extra overhead, and it > > complicates firewalls, debugging, and so on. > > If DCCP-over-UDP is pervasive, firewalls (and IDS/IPS) will > have to understand DCCP-over-UDP as well as DCCP itself. > > > Long term, we > > should encourage NAT vendors to support new transport > > protocols, and build native support for DCCP, SCTP, UDP-lite, etc. > > I agree. > > But first there needs to be a market pull for new protocols, > and allowing the new protocol to run over UDP until there is > a sufficiently large market driver to cause those vendors to > build those products seems important. > > > Call me an ivory tower academic if you like (although, > > reflecting the Glasgow style, our ivory tower is made of > > stone <http://www.gla.ac.uk/media/media_20554_en.jpg> ), but > > I'm not yet convinced we should give up all semblance of > > architectural purity... > > I'm not a stone tower academic, and even I agree with the > argument. > > DCCP has an initiation handshake. It seems effective, to me, > to define SRV records that are something like this: > > _foobar._dccp SRV 0 0 1234 server.example.com. > _foobar._dccp-udp SRV 0 0 1234 server.example.com. > > and protocol foobar then tries both a native DCCP handshake > (to DCCP port 1234) and a DCCP-over-UDP handshake (to UDP > port 1234). We could do the native DCCP first and try > DCCP-over-UDP 100ms (or whatever you like) later. > > This provides the incremental deployment we need (with > dccp-udp) and provides an easy path to real DCCP deployment > (where the UDP encapsulation is not necessary because there > are no meddling on-path IPv4 NATs). > > Would this be feasible? > > -d
