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

Wed Apr 28 15:44:41 UTC 2010

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