Hi Colin, On the second issue in your e-mail, whether the NAT traversal mode of DCCP should be transparent to applications or not: There were a few issues that drove me towards application visibility.
I felt that applications would want to know directly that NAT traversal mode was available or not and that it would be used or not. This is similar to why I perceive TLS is more popular with apps than IPsec. Apps could migrate to IPsec without making changes, yet they seem to prefer TLS. There are perhaps many reasons for this, but I think one of them is because TLS gives them more visible and direct control over what's going on. Perhaps this thinking doesn't apply here -- if NAT traversal mode were widely available in DCCP implementations and the negotiation to choose a mode was efficient then apps wouldn't care. But my initial take was that the added complexity and the likely time involved in settling on an encapsulation (if your first guess was wrong) were enough disadvantages to argue for the no-negotiation approach. Another issue with automatic negotiation is that apps that used another signaling protocol to rendezvous (such as SIP/SDP) would need to carry info for all encaps, even when they knew they needed only one (they'd need to carry the UDP port of the DCCP-NAT service, plus the DCCP port). How big an issue this is, since we're at the very early stages of defining any of these protocols, is debatable. The case isn't absolute though, so I'm perfectly willing to listen to counterarguments. Tom P. > -----Original Message----- > From: Colin Perkins [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 17, 2008 9:57 AM > To: Phelan, Tom > Cc: Ian McDonald; 'dccp' working group > Subject: Re: [dccp] 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/ >
