[arin-discuss] use of 128.66.0.0/16 not clear

Robert E. Seastrom rs at seastrom.com
Wed Sep 23 14:33:22 EDT 2009


Michael Hasse <mhasse at itwerx.net> writes:

> Or simply a usage audit of legacy /8s owned by such as duPont, Eli
> Lily, Ford, Merck et al.  There's more than a few /8s out there that
> are likely pretty sparsely implemented.  Not to mention ones that have
> been rolled into other orgs, e.g. ranges originally assigned to DEC,
> CSC and others.  (How many /8s does a non-ISP need anyway?  Hope I'm
> not speaking out of turn here...)

Even if your premise is correct is it worth the work?

Having worked in multiple organizations that did no NAT whatsoever and
being intimately familiar with the advantage of having globally unique
addresses everywhere and having organization's firewalls only
determine reachability policy, I have to conclude that in the absence
of a shortage-based constraint, there is no reason that the
organizations you list above *wouldn't* have globally unique addresses
on the desktop.  This is particularly true when one is doing a lot of
EDI and interconnection with partner networks...  look at the list of
companies with /8s and you may see a pattern there.

I suspect we're orders of magnitude apart in terms of what you and I
would expect to see in terms of host population on globally unique
addresses, and certainly not neatly placed such that all but a sliver
of the network could be removed without a huge renumbering effort...

Anyway, I'm not trying to be flippant here with my original question.
Each /8 equivalent that we manage to claw back, if returned to the
free pool (which is not a foregone conclusion but bear with me here)
staves off free pool exhaustion by 24 days, more or less.

If we manage to push off the exhaustion date by five or six months,
what have we accomplished?  Would that effort not have been better
spent on advancing the cause of IPv6, or developing interoperability
standards for carrier-grade NAT, or whatever your vision for salvation
in a post-IPv4-runout world is?

-r




More information about the ARIN-discuss mailing list