Hi Ian, 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. Tom P. > -----Original Message----- > From: Ian McDonald [mailto:ian.mcdonald@xxxxxxxxxxx] > Sent: Thursday, February 14, 2008 2:19 PM > To: Phelan, Tom > Cc: 'dccp' working group > Subject: Re: draft-phelan-dccp-natencap-00.txt > > Tom, > > Looks good overall. A couple of comments. > > In introduction you say: > In order for the [RFC4340] encapsulation to pass through Network > Address Translation (NAT) devices, these devices must be updated to > recognize and properly modify DCCP. This is the long-term objective > for DCCP, and work is underway to specify the necessary operations. > > As regards to work underway there is an implementation in the Linux > kernel to provide NAT/connection tracking for DCCP and it is believed > to work well - basically does the same as UDP/TCP. This has been in > the Linux kernel for sometime now, so may be of some use for this > work. > > I also think the documenent could do with some description of where it > would sit. I logically see this sitting in the end nodes, but this may > or may not be what you intended. The reason I think of end boxes is > because the would know to adjust the length potentially of packets > being sent if payload of DCCP + wrapper is bigger than maximum UDP > frame. However if packets were just dropped this could be put on a > middlebox and Path MTU discovery should sort. Regardless of this a > little discussion could be made around this. > > Regards > > Ian > > > On Fri, Feb 15, 2008 at 7:20 AM, Phelan, Tom <tphelan@xxxxxxxxxxxx> wrote: > > Hi All, > > > > I've submitted draft-phelan-dccp-natencap-00.txt to the draft > > depository. I'm not sure where the notification will go -- it's an > > individual submission and the automatic submission tool didn't give me a > > way to tell it to send notification to dccp. I believe it's in the > > repository now, and it's also available at > > http://www.phelan-4.com/dccp/draft-phelan-dccp-natencap-00.txt. > > > > This draft defines DCCP-NAT, an alternative encapsulation building on a > > UDP shim layer that will allow DCCP applications to interwork with > > current NAT devices. The motivation for this is nicely described in > > Jonathan Rosenberg's new > > draft-rosenberg-internet-waist-hourglass-00.txt. I didn't know this was > > coming, but I think it has a point. > > > > The approach here is different than the one that SCTP is appearing to > > take (draft-tuexen-sctp-udp-encaps-01.txt). That seems to insert a > > couple of bump-in-the-wire encapsulation/decapsulation functions. > > DCCP-NAT specifies a new native encapsulation. > > > > Comments appreciated. > > > > Tom P. > > > > > > -- > Web: http://wand.net.nz/~iam4/ > Blog: http://iansblog.jandi.co.nz
