Hi Lars, I sympathize with your concern for each transport inventing its own UDP encap solution. However, I don't think that that IP/UDP/IP/DCCP[SCTP][whatever] works well. What is in the inner IP addresses? They're not useful at all. They could start out the same as the outer addresses, but after traversing a NAT they wouldn't make sense to the receiving system. Can we invent a generic transport UDP encapsulation? Maybe, maybe not. I haven't seen that TCP-over-UDP thing. What kind of rationale is there for that? Tom P. > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@xxxxxxxxx] > Sent: Tuesday, February 26, 2008 10:19 AM > To: Phelan, Tom > Cc: 'dccp' working group > Subject: Re: draft-phelan-dccp-natencap-00.txt > > Hi, > > one question we really need to answer is whether we want to go through > the pains of specifying UDP encapsulations for all our transport > protocols. We have on the table: > > * draft-phelan-dccp-natencap for DCCP > * draft-tuexen-sctp-udp-encaps for SCTP > * JDR's recent email on the MMUSIC list for TCP-over-UDP > > All of them need to basically design very similar handshake/signaling > exchanges, they all need a solution for the service identification > issue, etc. This is undesirable. > > If we need to encapsulate something in UDP for the purposes of NAT > traversal, why aren't we encapsulating IP in UDP, on top of which we > can run pretty much anything? Instead of requiring that DCCP stacks > grow support for DCCP-over-UDP, why don't we simply require that DCCP > stacks implement Teredo or something similar? Why are we solving the > NAT traversal problem protocol-by-protocol rather than one time? > > (The still ongoing NAT traversal discussion in HIP - which is building > its own NAT traversal solution - has left me convinced that we should > have pushed harder for the original "just use Teredo" proposal for HIP > NAT traversal. We'd be long done.) > > Lars
