[arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack

[Leo Bicknell]

In a message written on Tue, Dec 28, 2010 at 10:39:39PM -0500, William Herrin wrote:
> If you want ARIN to show leadership with respect to IPv6 then however
> much they may have missed on the particulars, the prop 125 guys are on
> the right track. They just need to come back at it with an approach
> that's less poorly-conceived bullying and more firmly nudging people
> to take that next baby step in a healthy direction.

Even if Prop125 is tweaked to be "perfect" there is still a timing
issue.  Given where we are in the timeline even if it passes the
emergency process and is implemented fairly quickly by ARIN it will
be in place for well under 12 months of normal IPv4 allocations,
and quite likely less than 6 months.

Rather than provide an incentive to the entire industry to do
something useful it's going to have maximum impact on a small group
of people who happen to be (un)lucky enough to request more IPv4
space during that time.

Some might argue that it will "live on" with the transfer market, but
that really makes no sense to me.  One of the largest arguments in favor
of the transfer market was to provide an out to people who couldn't do
IPv6 for some reason.  Maybe some org would find it cheaper to throw a
million dollars at IPv4 than do IPv6, and the transfer market both gave
them a way to do that and a way for us to show the rest of the community
IPv4 now cost a million dollars.

If Prop125 applies to the transfer market we're throwing IPv6 at the
people we've already self selected that can't do it.  I have a lot of
trouble with that logic.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101229/8b14188f/attachment.sig>