This is definitely an interesting way of ensuring players are solving their own long term problem as well as short term, which can generally be seen as good for the community as well IMO.
The one challenge you will face to this proposal is that not all products and services are created equal. As an ISP in Canada that sells Wireless and Wireline solutions to all markets (Business, Consumer, Partner) we have seen that each case has a different propensity for IPv6 adoption, and certainly a broad mix in whether IPv6 solves the IPv4 depletion problem. For instance, a Consumer Wireless service is fairly predictable in its requirements for connectivity, which means it could be serviced with an IPv6 only connection, with NAT64/DNS64 and 464XLAT for instance. The same cannot be said of an Enterprise client's Internet and WAN services. They will run dual-stack undoubtedly for a long time. In terms more generally applicable at Google, I imagine the same could be said of cloud services across Business and Consumer markets. My point is simply that drivers and implications are different across these markets. In general, I would agree that we all want to see IPv6 adoption across the board regardless of its efficacy to solve the problem of IPv4 address depletion. Just want to throw these thoughts to the community for consideration of policies to the effect Jason has proposed. mw On July 12, 2013 at 09:37 AM Jason Schiller <[email protected]> wrote: > Certainly ARIN has prevented an organization from getting additional space > if their currently held space is under utilized (even if it is legacy space). > > ARIN certainly has used a slow start model, rather than giving potentially > overly large allocations / assignments when there is not a good foundation > of a year's worth of growth to justify the size block requested. > > These two practices help to sustain IPv4. > > The application need based justification to transfers is an attempt > to continue these sustainable practices. > > It sounds like whatever concerns people have about the depletion > of the free pool, can also be applied to the depletion of sufficiently > large blocks of IPv4 available at a reasonable / affordable price on > the transfer market. > > The only way I see out of this is if there is more that enough supply > for everyone to purchase all the addresses they need to sustain > their growth until there is wide spread IPv6 adoption. > > One way to encourage this is to require real IPv6 deployment along > with IPv4 transfers. Say require 10% of the customer base to be IPv6 > capable prior to approving a transfer, and require a plan to get 40% > of the customer base IPv6 capable in one year, and 80% in two years. > > Choose whatever numbers seem right for the community 1%, 30%, 70%? > > ___Jason > > > On Thu, Jul 11, 2013 at 3:48 PM, Mike Burns <[email protected]> wrote: > > We already have a reclamation process; see NRPM 12 and the enabling > language in the RSA. ARIN hasn't used it much/any to date except in > cases of suspected fraud, which IMHO is a dereliction of its duty, but > it _has_ been used. Therefore, any proposal to "begin" using it would > be moot. > Hi Stephen, > > A boogeyman. > ARIN will revoke if you don't pay your bill, though. > I have asked on this list for any evidence of ARIN ever revoking addresses > for utilization and was met by crickets. > Hard to reconcile with a principle which demands conservation of all > addresses. > > > Regards, > Mike > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|[email protected]|571-266-0006 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
