[arin-ppml] IPv4 Depletion as an ARIN policy concern
tedm at ipinc.net
Mon Nov 2 20:16:38 EST 2009
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>
>>> 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
> 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
More information about the ARIN-PPML