[dccp] RFC - DCCP and NAT

[Ian McDonald <imcdnzl at gmail.com>]

Folks,

As you would have read yesterday we got DCCP going over the Internet.

The only real obstacle that we found in this is that checksums were
incorrect because I was transmitting from a PC behind a NAT based ADSL
firewall/router and that the DCCP header checksum involves the source
IP address and destination address.

We temporarily disabled header checksum to get the connection working
and in all other ways the data flowed across the Internet.

This tells me that the main obstacle to DCCP adoption from a network
viewpoint (as opposed to an application viewpoint) is the end points.
Apart from the end points we went through 18 hops fine.

Now I believe that we can solve this in one of two ways:
1) Any endbox that does NAT to DCCP must be aware and alter header
checksums as done for TCP and UDP today
2) We alter the protocol to explicitly recognise NAT

Option 1 is better from a purist point of view and is cleaner. However
if we want DCCP to be successful I think pragmatically this will not
work. If we take a look at a number of papers on the web we can see
VERY slow uptake of new features. People don't like spending money or
effort fixing things they see as not broke. If we wait for end boxes
to be modified then DCCP will roll out as rapidly as IPv6.

What I propose therefore is option 2.

I've been thinking about how to achieve this and below are my
thoughts. These are totally open for debate about implementation
methods as I have only seriously thought about this for about an hour.

What I propose is that we create a couple of new options to say that I
am transmitting from a NAT box (let's call this Notify NAT) and also
for the other end to relay back what your public IP address is (let's
call this NAT to Public). The Notify NAT option would include it's
private IP address.

How I would see this working is that on the request packet initially
if a box knew it was using NAT (could be based on Private IP address
or O/S flag) then it would send the Notify NAT option. As the Request
packet is the very first packet we would modify the checksum routine
on request packets to check first if there is a Notify NAT option. If
there is then it would take the private IP address from the Notify NAT
option and store this in the socket being setup and use this for the
psuedo header as per section 9 of the spec going forward INSTEAD of
the public IP address. The NAT to public option would be appended to
the Response packet so that when the packets arrived back into the
NATed box we could fix the checksums in a similar fashion.

This deals with the most common case - a home/business PC with NAT
connecting to a server  with public.

There is also the case of the server being behind a NAT connection. In
this case the server would send Notify NAT on the response packet. It
does not need to receive a NAT to public option back because there is
enough information by that already (a NAT box must have already
directed the traffic to the right machine).

It is trivial now to follow this through with both boxes being on
NATed connections and you will see the flow as initatior sends Request
with Notify NAT, server sends Notfiy NAT and NAT to public options on
the response packets.

I would really appreciate people's comments on this as I believe it
would speed the adoption of DCCP exponentially.

Regards,

Ian McDonald
WAND Network Research group
http://wand.net.nz/