IPv6 fc00::/7 — Unique local addresses
nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Wed Oct 20 22:18:29 CDT 2010
On Wed, 20 Oct 2010 19:50:06 -0700
Matthew Kaufman <matthew at 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
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
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.
More information about the NANOG