Lars Eggert wrote:
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
>
I'd for one would be interested in understanding if DCCP/IP/UDP/IP were
a suitable alternative.
DCCP/UDP/IP raises architectural issues that I'd really prefer to avoid:
That is, I'd really rather not spend the next years avoiding
side-effects that result from encapsulating DCCP in UDP sometimes and
DCCP in IP other times - each with their own benefits/problems.
Gorry
