On Wed, 20 Oct 2010 19:50:06 -0700 Matthew Kaufman <matthew@matthew.at> wrote:
On 10/20/2010 7:27 PM, Mark Smith wrote:
* Stream Control Transport Protocol, first spec'd in 2000 (couldn't be deployed widely in IPv4 because of NATs)
"because of NATs" s/b "because certain parties refused to acknowledge that encapsulation of SCTP in UDP would have operational advantages sufficient to outweigh the disadvantages".
SCTP only gets you 90% of the way there, but it is a lot closer than today's TCP is.
Which is why there is also work going on at the network layer, both on the end-hosts via HIP or Shim6, and in the network, such as LISP. Ultimately, this is a hard problem to solve. There is no easy solution, otherwise it'd already exist, and have existed at least 10 years ago - as that is at least how long people have been working on trying to solve it. As there is no easy and perfect solution, then we need to accept that we're going to have to make trade offs to be able to get closer to solving it. In other words, a better solution, even if it isn't perfect, is better. The question is what trade offs are acceptable to make? We know and have experienced the many drawbacks of NAT, including such things as restricting deployment of new and better transport protocols like SCTP, DCCP, and maybe multipath TCP if the NAT boxes inspect and drop unknown TCP options, and forcing the nature of Internet applications to be client-server, even when a peer-to-peer application communications architecture would be far more reliable, scalable and secure. As NAT ultimately was about conserving address space, and IPv6 solves that problem, it is worth exploring other options that weren't possible with IPv4 and/or IPv4 NAT. Regards, Mark.