Mark Smith wrote:
On Tue, 27 Apr 2010 14:29:50 -0400 Dave Israel <davei@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