On Wed, 28 Apr 2010 08:44:41 -0700 Matthew Kaufman <matt...@matthew.at> wrote:
> 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. > I'm not people are understanding or know the true reality. NAT broke the Internet's architecture, by turning IP from being a peer-to-peer protocol into a master/slave one (think mainframes and dumb terminals). Read RFC1958 if you don't understand what that means, specifically the 'end-to-end' principle part. IPv6's fundamental goal is to restore end-to-end. > 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 >
