Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

[Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>]

On Wed, 28 Apr 2010 08:44:41 -0700
Matthew Kaufman <matthew () matthew at> wrote:

> 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.

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