> 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
