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

[Leo Bicknell]

In a message written on Wed, Mar 21, 2007 at 12:23:52AM -0500, Stephen Sprunk wrote:
> This has the (unfortunate?) side effect that even if IANA stops giving out 
> /8s to RIRs on a given date, some will likely run out _months_ before 
> others.  LACNIC and AfriNIC don't go through a /8 anywhere near as fast as 
> ARIN does -- and I don't believe we should tease folks in those regions by 
> giving them an /8 and then telling them they can't use most of it just 
> because folks on other continents have a problem.

Others have already raised that we may want to alter the IANA to
RIR policies so they don't have to allocate /8's, and to better allow
all the RIR's to run out around the same time.  I like that concept,
but I'm a bit unsure exactly how to put that into policy.

However, I will say this, if the community wants to alter that
policy now is the time.  It will take all the RIR's passing the
policy for it to be considered by IANA as a global policy.  I believe
the most optimistic time frame for that to happen would be around 2
years.  With the more aggressive predictions of when we run out, we
could need it in 3 years.

> For the record, I support Owen's position.  Not because the end game is 
> pretty, because it obviously isn't, but because it makes no sense to me 
> that, as addresses are returned to (or reclaimed by) ARIN, we wouldn't be 
> able to hand them out again.  I also don't like the idea that folks 
> wouldn't be able to use the trade-in policies, if ARIN happened to have 
> blocks large enough to, for instance, consolidate the announcements of 
> someone who currently has several hundred discontiguous blocks.  Freezing 
> the IPv4 registry on a particular date isn't necessary.  ARIN (and the 
> other RIRs) can still do many useful things even if there's no more "new" 
> space left. And we, as policymakers, can change policy to free up more 
> "used" space for new allocations/assignments if we decide to do so.

I'm so glad you wrote this, because it's an excellent write up of
my biggest issue with this policy.  When we're out of IPv4 space
(either by using all of it, or by putting some in reserve and using
all of the rest) there is still a need for the RIR function on IPv4
space.  End sites will still come and go from ISP's, meaning we
still need to process SWIP's.  ISP's will go bankrupt, fail to pay
under the RSA, and have their space reclaimed.  That should be able
to go back out for re-use as it does today.  One can only assume
there will be increased pressure on transfers, which we need to
take into account.

There really is a four part problem, and this proposal only manages one:

1) How do we get people to take action now so the limits on IPv4 space
  don't have major consequences to the industry.  (i.e. Move to IPv6 now)

2) How do we manage the "run on the bank" as the space runs out.  No
   matter what this will occur, the goal is to make it the least painful.

3) How do we manage the IPv4 space when it is "full".  Do we have to
   alter any of our policies to properly function in that world?

4) How do we make sure the RIR is effective in the new world?  In
   particular I'm concerned about our IPv6 policy keeping up with the
   market if there is an accelerated shift.  We don't have enough
   experience with the existing policy to fine tune it for widespread
   adoption.  It's likely the rate of change will outpace the RIR's policy
   process.

> I agree with you that all of the issues you list are relevant to ARIN but 
> not to this particular proposal.  I would definitely like to see distinct 
> proposals for each of them, and some lively debate around those proposals, 
> which can be done concurrently with this debate.

Absolutely.  I believe we need to make policy in all of these other
areas as well.  While there is some coordination needed, keeping
the discussion focused on one area at a time is likely to lead to
more progress, in my opinion.

I think now is the time for people to start thinking about proposals
for the fall, so they can be socialized at the spring meeting and
posted shortly afterwards.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070321/38d3c2eb/attachment.sig>