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:csp@xxxxxxxxxxxxx] > Sent: Sunday, February 17, 2008 9:57 AM > To: Phelan, Tom > Cc: Ian McDonald; 'dccp' working group > Subject: Re: 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/ >
