[ppml] Policy Proposal: Global Policy for the Allocation of theRemaining IPv4 Address Space

[Roque Gagliano]

Hi, here are my answers...

> When we hit the IPv4 exhaustion point, some organizations will be unable
> to obtain the IPv4 addresses that they need to continue growing the
> network. This policy propsal brings that point forward so that IPv4
> exhaustion will happen sooner. They propose that 25 /8's be reserved for
> this special endgame. 

25 x /8 is a proposition, we can come out of this discussion with 20, 15
x /8s, etc.

> This means that when we reach T minus 25 /8's,
> some organizations will be unable to obtain the IPv4 addresses that they
> need to continue growing the network.

Not true. At that time the RIR will received their last allocations. If
there are not policies changes at the RIRs, organizations will continue
to receive allocations as usual untill its RIR pool is exhausted.
However, each RIR will be able to have their own "soft landing" policies
or any policies to sub-allocate with this "last allocation".

> 
> Perhaps it will be fewer organizations? Or perhaps it will be more
> because people will not be as far along their IPv6 deplyoment. We know
> that IPv4 exhaustion is not a brick wall because problems will be caused
> by events that happen before total exhaustion. This policy proposal
> plans to make that chaos happen sooner, when we are less prepared to
> deal with it.

How sooner?  10 months? 12 months? that is why this policies helps each
RIR to focus on their communities needs when the central IPv4 pool is
emptying.

> 
> This is a bad, bad policy and we need to soundly reject it.
> 
> --Michael Dillon
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
-- 

------------------------------------------------------------- 
Roque Gagliano ANTEL - URUGUAY 
rgaglian at antel.net.uy 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070723/2706f203/attachment.sig>