[arin-ppml] IPv4 Depletion as an ARIN policy concern

[Ted Mittelstaedt]

Owen DeLong wrote:
> 
> On Nov 2, 2009, at 3:41 PM, William Herrin wrote:
> 
>> On Mon, Nov 2, 2009 at 12:54 PM, Kevin Kargel <kkargel at polartel.com> 
>> wrote:
>>> NAT started out as a kludgy local workaround and will always pretty 
>>> much be
>>> a local workaround.
>>
>> NAT started out as an improvement on SOCKS that allowed most
>> applications to work unmodified. Understand why folks wanted the
>> latter and you'll understand why they want the former.
>>
> I don't buy this...
> 

Neither do I.

> SI started out as  an improvement on SOCKS that allowed most
> applications to work unmodified. I can understand why folks wanted
> this, having run some SOCKS gateways and having worked with
> the guys at NEC that originally developed SOCKS.
> 
> NAT was a kludge added to SI which allowed you to pack more
> addresses behind fewer addresses (or one address) by, essentially
> doing a statistical multiplexing of IP address+protocol+port number
> into a single 49 bit field which was dynamically assigned by the
> gateway.
> 
> NAT restored the need to do application-specific weirdness to many
> applications which did not need such modifications for SI.
> 
> If you look at it from this perspective, considering all the dysfunction
> created by overloading end system identifier semantics with network
> locator semantics (an error which was, unfortunately, preserved in
> IPv6), then, you can begin to see why further overloading is not
> necessarily a good thing.
> 

As I recall - having setup my then-employer behind a roll-your-own
NAT on FreeBSD (using the kernel patches available then) back in 1997,
the biggest advantage of NAT at the time was because so much stuff was 
statically assigned in the corporate network.  It wasn't so much the 
typing of the IP addresses into the clients.  It was because so many 
APPLICATIONS used statics.

I STILL to this day see this - as an example, take the Rosetta
foreign language learning software.  To this very day when you setup
a Rosetta client in a network with a floating license server, the client 
configuration software demands you key in the IP address of the license 
server during the setup of the client. (on the OSX clients at least) 
They use flexlm for that, by the way.

The problem as I see it is that a tremendously significant number of 
corporate software application developers don't know squat about 
networking.  They may know how to write a network application but their 
knowledge of it's interface to the network is restricted to the OS APIs 
and they often will take shortcuts - such as not allowing for a user to 
fill in a name, then doing a DNS query for it - if they think they can 
get away with them.

I fully expect that some of these boneheads will be expecting the users 
to key in the entire 128 bit address when they are finally forced to 
write in IPv6 compatibility.

NATs allowed me to statically assign an IP number to a server then I 
knew that years later I wouldn't have to renumber it and find all of the 
clients that had it hard-coded, just because I decided to switch ISPs

Otherwise, NATs in a corporate environment are a royal PIA.  Most 
everyone uses 192.168.1.x or 192.168.0.x because that's the default 
address on their router, and then when you try to setup a VPN from 
company to company (which happens a lot more than you think) you have 
trouble.  I had a customer of the ISP call me the other day and complain 
about this - she was a consultant who worked out of her home and she was 
trying to VPN into 3 different clients of hers at once - all 3 running 
192.168.1.x  She tends to duplicate templates and such across clients 
and now she has to disconnect from one and connect to another then 
disconnect from that one and connect to the first again just to copy 
over a template file.  Really stupid, drives up her time, drives up 
their bills.

Ted