[ppml] Policy Proposal: 2007-12 IPv4 Countdown Policy Proposal

Rich Emmings rich at nic.umass.edu
Wed Mar 21 16:44:09 EDT 2007

I'm jotting this off quickly.

My first reading of the proposal before it was re-petitioned, was that it's 
adaption would be more likely to cause a run on the bank right after 
adoption, speeding exhaustion, not holding it up.

Driving a car off a tall cliff is general a bad idea; not doing is the alternative.

I might investigate voluntary recovery of unused numbers as a better first 
step.  Email postage is still cheap, and most people probably haven't been 
personally asked.

ARIN maintains a registry of unique numbers for those who require 
uniqueness; there is no requirement the numbers show up in the routing table.
For those that gloom about the size of the global routing table, this could 
be construed to be a good thing.

I have a list of 10 /8's which are not seen in the global tables.  I might 
ask those folks first, what they'd be willing to do.  Larger, order /16's 
might be the next order of business.  ARIN records not updated in 10 or 12 years.

As I understand it, there some action taking towards cleaning out the swamp 
at one point, by trading for address space.  /8 holders (ala Stanford) might 
be able to trade down.

I'd not force the issue until I'd see what asking did.

Renumbering consumes the resources (time, money, etc) of the enitity.  It 
might be worth offering up some IPv6 space in lieu of, and outside of the 
current allocation minimums -- Any size of IPv4 smaller than what you have + 
an IPv6 block, might be a not unreasonable offer. Some people might be able 
to take advantage of this, others won't be able to.

A co-worker & his wife ran around the house one day checking the seat 
cushions and change jars, and came up with $600 in loose change. Maybe 
there's no loose change out there in IPv4 Land, but has any one asked anyone 
to check under the cushions.

Or maybe we're unwilling to try and use a collaborative approach, and should 
instead adopt the Atilia the Hun method.  But I'd rather not.


Specific criticisms:

If we're heading for a disaster, we shouldn't be waiting for "A-Date" or 
"D-Date" whatever the psuedo-math formula was.  If the exhaustion models[2] 
are accurate, rewrite the policy around specific dates, since the models 
already predict them.

Gimme a specific date, if you want me to move staff and management, not some 
arbitrary future trigger event that can be ignored.

Even with that, I'd still oppose it on the basis of a belief, it will have the opposite behavior.


Note 1:  RFC1925 Controls, especially 2(4).
Note 2:  IPv4 Exhaustion assumptions are using the wrong smoothed curve.  It'll be a logistic ("S") curve, not exponential.

On Wed, 21 Mar 2007, Ted Mittelstaedt wrote:

>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>> Rich Emmings
>> Sent: Wednesday, March 21, 2007 7:35 AM
>> To: ppml at arin.net
>> Subject: Re: [ppml] Policy Proposal: 2007-12 IPv4 Countdown Policy
>> Proposal
>> I can't add to the discussion, without repeating points raised,
>> other than to say "opposed" as written.
> If you are going to go on record opposing, then what exactly is the
> alternative that you do support?
> Ted

More information about the ARIN-PPML mailing list