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
