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-----
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
