Mark Smith wrote:
On Tue, 27 Apr 2010 14:29:50 -0400
Dave Israel <da...@otd.com> wrote:
On 4/27/2010 1:36 PM, Andy Davidson wrote:
On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:
Did you use Yahoo IM, AIM, or Skype?
Yes, yes, and yes. Works fine.
What about every other service/protocol that users use today,
and might be invented tomorrow ? Do & will they all work with
NAT ?
Sure, I can invent a service/protocol that doesn't work with NAT. While
I am at it, I'll make it not work with IPv4, IPv6, Ethernet, an
architectures using less than 256 bits of memory addressing. I bet
it'll be popular!
One already exists. It's called DCCP, or Datagram Congestion Control
Protocol - it's like UDP with congestion management. It'd be great to
use for Video and Voip, which could then vary the codec parameters to
suit congestion should it occur. Shame NAT has stopped it being widely
deployed.
SCTP could be used to perform peer to peer IM and file transfers, where
the file transfer takes place within the existing SCTP connection,
rather than having to establish a separate connection. Shame NAT has
stopped it being widely deployed.
Mark, I think you made Dave's point perfectly. Sure, history will be
littered with protocols developed after NAT was widespread but whose
designers willfully ignored reality (often committees filled with a
bunch of people who wanted to acknowledge reality and a few strong
voices who want to pretend there's a world without NAT both now and in
the IPv6 future). Many of these won't see wide deployment as a result.
You can add SIP and SDP to the list, as those were designed with an
FTP-like belief that you can know your local address and send it around
in the payload and expect the right thing to happen. (FTP at least had
the excuse that it predated NAT deployment)... though SIP, for some
inexplicable reason, has survived to make it to wide deployment anyway.
Or you can run things like DCCP and SCTP encapsulated in UDP (works just
fine), or design a new protocol that combines the best of DCCP and SCTP
and DTLS and mix in some IP mobility and other features and deploy it to
almost every Internet host (what I did... the protocol is RTMFP and it
is in every copy of Flash Player since version 10.0), or design a new
protocol for your application which does what DCCP and DTLS do only for
your own widely deployed application (as the Skype folks did). All of
these are excellent approaches for having something which *actually
works*, though impefectly as the backlash against NATs in groups such as
the IETF has lead to a big lack of standards around how they should work.
Either applications learn to deal with NAT, in which case they thrive on
both the heavily-NATed still-mostly-IPv4 Internet of the future *or* the
has-NAT mostly-IPv6 Internet of the future (a great way to hedge your
bets if you're writing protocols and applications)... or they don't
learn to deal with NAT, in which case they don't work on todays IPv4
Internet *and* they won't work on the heavily-NATed still-mostly-IPv4
Internet of one possible future *or* the has-NAT mostly-IPv6 Internet of
the future. Those won't be nearly as popular.
And in case you don't have handy a short list of why the IPv6 Internet
will be filled with NAT, I'll give you three items to start with:
1. SOX, HIPPA, and other audit checklist compliance currently requires
NAT for (theoretical) fail-closed and topology hiding. If IPv6 NAT
exists, this requirement may not go away.
2. There will be a requirement for client hosts which have IPv6 SLAAC
implementations that expose their MAC address in the low address bits to
have those bits hidden from the outside Internet.
3. Organizations not large enough to qualify for (or who don't wish to
bother with) PI space will deploy NAT so as to avoid internal
renumbering of things which must have static addresses (Intranet
servers, DNS resolvers, etc.). This is because the IPv6 future where
every LAN is carrying multiple PA addresses to every host wasn't
sufficiently well designed for it to actually work for either the
multihoming case or the interior-network/outside-Internet case.
The good news is that it might be sufficient to do pure NAT and not
NAPT, and it might be possible still to get some good standards around
how these devices should behave... both of which aren't happening for
the IPv4 Internet, unfortunately.
Matthew Kaufman