Tom,
On 18 Feb 2008, at 18:35, Phelan, Tom wrote:
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.
For the TLS case, the application wants to do something different if
the security is enabled. I'm not sure that's the case for native vs.
encapsulated DCCP, so the parallel doesn't follow.
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.
I was envisaging the DCCP-over-UDP tunnel being invisible to the SDP
layer, but maybe that won't work.
--
Colin Perkins
http://csperkins.org/
