[arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix Size
farmer at umn.edu
Wed Jun 10 21:38:26 EDT 2009
On 10 Jun 2009 Pete Templin wrote:
> Scott Leibrand wrote:
> > Pete Templin wrote:
> >> I'm simply not following your suggestion of the numbers, which
> >> includes looking at the spreadsheet you've provided. I'll base my
> >> discussions on the one quarter (1/4) ratio since that's what's
> >> written into the Policy Proposal.
> >> Case study #1: ARIN has a /13 of space, also known as 524,288
> >> addresses. Four large-enough requests happen to be at the head of
> >> the line, and based on the one-quarter ratio they're eligible for a
> >> /15 of space per request. Each request is issued a /15, also known
> >> as 131,072 addresses. These 524,288 addresses in four allocations
> >> would wipe out the pool, not the 24 allocations that you present
> >> above.
> > If ARIN has a /13 of space, the first large-enough request to come
> > in could get a /15 based on a 1/4 ratio. That would take ARIN's
> > space down to /14+/15, meaning that the second large-enough request
> > could get a /16. That leaves /14+/15+16, which means the next few
> > also get a /16. Once the /14 gets broken up, leaving /15+16, then
> > the next few requests can only get /17, until the /15 gets broken
> > up, at which point it goes to /18, etc. etc. until you get to the
> > minimum allocation size.
Yes that is the intended sequence. I found a different problem in my spread
sheet, I'm reworking it, once I update it the same URL should work.
> OK, now I understand the intentions. That said, the first paragraph
> of the proposed policy needs a complete re-write, or at least the
> first sentence: "When ARIN receives its last /8, by IANA implementing
> section 10.4.2.2, a maximum allocation and assignment size will be put
> into effect." This needs to be completely redone to reflect the
> dynamic nature of the ideas you're batting around. Ideas like
> "sliding scale", "dynamic allocation/assignment size", etc. come to
I thought that was clear from the second sentence "one quarter (1/4) of the
total unrestricted IPv4 resources available to ARIN for allocation or
assignment AT THE TIME". But, I'm happy to clarify it, sometimes you just
need someone else to read it, especially someone who wasn't part of the 20
or so emails that lead up to its creation.
"When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a
proportionally decreasing maximum allocation and assignment size will be
put into effect. The maximum allocation or assignment will be the next whole
CIDR prefix less than or equal to one quarter (1/4) of the total unrestricted
IPv4 resources available to ARIN at the time of each allocation or
assignment, but no longer than the applicable minimum allocation or
assignment. All other allocation and assignment rules, requirements, or
procedures apply in addition."
Does that rewrite of the first paragraph better communicate the intent?
If you think that is good, I'll submit that and some other grammar fixes.
> That said, I think this policy proposal leads to a
> highly-unpredictable run-out model at a micro (i.e. per-request) level
> - there would be essentially no way to predict how much of an
> assignment/allocation a requester might get unless there was a public
> status board, reports (rumors?) on mailing lists (yesterday I got a
> /X!!!), etc. It's predictable run-out at a macro level, but quite
> unpredictable at a micro level.
Realize most requests are for the smaller blocks, so most people won't have
this unpredictability until the very end. What ever our run out looks like ARIN
will probably need some kind of real-time status of what is left.
It boils down to there will be unpredictability no matter what, this proposal,
trades some additional unpredictability in the size block you will get for more
predictability in the availability of a block at all. While trying to avoid rationing
as much as possible, and ensuring there is some minimal dispersion of the
But I agree it creates uncertainty in the size block that is available when you
make a request, and that troubles me, but it was clear from the discussion in
San Antonio that people really didn't like rationing. 2009-2 which basically
gave everyone a /20 when ARIN got down to /9 didn't go over well. With that
proposal there was good certainty on the size of the blocks and the
availability of blocks, but it rationed. Whereas this proposal doesn't ration,
has some certainty of availability of blocks, but creates uncertainty in the size
blocks available at any moment, other than it will be going down.
A possible middle ground could to, create set of ranges of resources
available to ARIN with associated maximum allocation or assignment size. A
hybrid between 2009-2 and this proposal.
Just throwing out an idea here;
ARIN has less than a /8, but more than /11, the max is /12
ARIN has less than a /11, but more than /15, the max is /16
ARIN has less than a /15, but more than /20, the max is /20
This third option has good certainty on the size of the blocks, expect near the
boundaries, and the availability of blocks, however it would necessitate some
Is this a better option? I'd be willing to start over with something more like
David Farmer Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota Phone: 612-626-0815
2218 University Ave SE Cell: 612-812-9952
Minneapolis, MN 55414-3029 FAX: 612-626-1818
More information about the ARIN-PPML