I think Section 4.10 (2008-5) is working as planed. https://www.arin.net/policy/proposals/2008_5.html
The IPv4 free pool is now out and we still have a /10 for those that need some IPv4 for IPv6 deployments. At least that much is a success. We would be far worse off without the /10.
Our community couldn't agree on reserving the whole last /8 like some of other RIRs did. A /10 isn't enough for the same kind of last /8 policy that the other RIRs have, that is everyone gets a /22 or something like that. It's really too late to change that now.
However, we need to think hard about the current policy and if the details are correct now that the IPv4 free pool is gone and we actually need to make use of it. I would love to hear experiences using and/or suggestions to improve section 4.10. But, with only a /10 I'm going to be very leery of suggestions for use of the 4.10 reservation that are not directly tied to IPv6 deployment requirements.
If you want IPv4 for IPv4 sake there are transfers and the waiting list, and the waiting list isn't a reliable source of addresses, so that really only leaves transfers.
thanks On 10/20/15 20:20 , Scott Leibrand wrote:
Personally I think we'll have a much better idea in a few months how well the v6 deployment /10 has worked. Up until now, it's been easier to get (larger) general free pool allocations than space from the /10. Now that the free pool is exhausted, I expect to see every new entrant applying for a block under 4.10, so we should very rapidly get some data on how easy it is for them to get something useful. Based on that experience and data, I would be quite willing to consider a policy change, but up until now I think we've been seeing exactly what we should've expected to see. -Scott On Tue, Oct 20, 2015 at 1:00 PM, Martin Hannigan <[email protected] <mailto:[email protected]>> wrote: Hi Karl, Just throwing it out there. My personal opinion is that the v6 deployment /10 is a failure and an economic limiter for new entrants and could be rethought. Best, -M< On Oct 20, 2015, at 20:12, Karl Brumund <[email protected] <mailto:[email protected]>> wrote:Martin, I'm unsure what the problem is that you're trying to solve. I'm guessing it's `let anybody new get a /24` so they have a chance for some v4 space. Or maybe its have ARIN be the same as other regions (though I'd say the transfer process is a bigger fish for that). You mentioned 'reasonable and fair'. Could you elaborate a bit, as I think I'm not caffinated enough to follow. Thanks! ...karl On Tue, Oct 20, 2015 at 2:03 PM, Martin Hannigan <[email protected] <mailto:[email protected]>> wrote: That was 2014. It is now near 2016. Then, we were not exhausted. Now, we are. Here's the RIPE policy bits https://www.ripe.net/publications/docs/ripe-649 Here's the ARIN policy: https://www.arin.net/policy/nrpm.html (Section 4.10) A brief summary. The RIPE policy is liberal in that every LIR (new or old) gets a /22. The ARIN policy is restrictive and digs into the same old noise around needs and transfer. We _could_ narrow this to new entrants (which does pose an antitrust question). We _could_ also direct that incoming IANA bits be redirected to new entrants as well up to the equivalent of a /8 to be parallel to other regions, but I'm not sure we need a limit although. We _could_ limit the size of the allocation to no longer shorter than a /24. Best, -M< On Tue, Oct 20, 2015 at 5:38 PM, Andrew Dul <[email protected] <mailto:[email protected]>> wrote: The ARIN community previously considered these ideas under 2014-16, but changing the /10 to something other than transition never had sufficient support for the AC to move it forward. https://www.arin.net/policy/proposals/2014_16.html .Andrew On Oct 20, 2015, at 5:35 PM, Morizot Timothy S <[email protected] <mailto:[email protected]>> wrote:Thanks for the clarifications. In that context, assuming a new entrant is deploying IPv6, wouldn't the current policy allow them to request allocations to support that deployment. It specifically mentions needs like dual-stacked nameservers and various IPv4 life extension solutions. If a new entrant *isn't* deploying IPv6 from the start, do we really want to support them with a free pool allocation? For any needs beyond those described in the policy, there's the transfer market. I don't know that I have particularly strong feelings either way, but if we're going to reserve any general use pool at all rather than simply handing it all out to meet current need, I think it's better to tie it to demonstrated IPv6 deployment. Scott -----Original Message----- From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Spears, Christopher M. Sent: Tuesday, October 20, 2015 10:21 AM To: Hadenfeldt, Andrew C Cc: [email protected] <mailto:[email protected]> Subject: Re: [arin-ppml] Transition /10 NRPM 4.10 [1] dedicated /10 for IPv6 "transition".. I tossed a similar idea around with some folks at ARIN36. Use this /10 to allocate a /24 per **new** Org, and steer subsequent transactions to transfers. That would ensure IPv4 for ~16K **new** entrants in the coming years.. [1] https://www.arin.net/policy/nrpm.html#four10 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected] <mailto:[email protected]>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] <mailto:[email protected]> if you experience any issues._______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected] <mailto:[email protected]>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] <mailto:[email protected]> if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected] <mailto:[email protected]>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] <mailto:[email protected]> if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected] <mailto:[email protected]>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] <mailto:[email protected]> if you experience any issues._______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected] <mailto:[email protected]>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] <mailto:[email protected]> if you experience any issues. _______________________________________________ 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.
-- ================================================ David Farmer Email: [email protected] Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ _______________________________________________ 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.
