IPv6 Default Allocation - What size allocation are you giving out

Thu Oct 9 16:01:45 UTC 2014

On Oct 9, 2014, at 7:22 AM, Daniel Corbe <corbe at corbe.net> wrote:

> 
> Mark Andrews <marka at isc.org> writes:
> 
>> In message <54366AB9.3040504 at gmail.com>, Paige Thompson writes:
>>> makes more sense to hand out /48s imho. theres only a mere 65k /48s per
>>> /32 (or something like that), though.
>> 
>> A /32 is the minimum allocation to a ISP.  If you have more customers
>> or will have more customers request a bigger block from the RIRs.
>> 
>> Mark
> 
> Has anyone successfully gotten a RIR to assign anything bigger than a
> /32?  I seem to recall in recent history someone tried to obtain a /31
> through ARIN and got smacked down.  

I think I answered this before you asked it, but yes,easily on multiple
occasions. The largest two allocations I have worked on were /24s, but I’m sure
those are not ARIN’s largest allocations.

> Even if you're assigning a /56 to every end user, that's still on the
> order of 16 million allocations.  I can't imagine anyone but the truly
> behemoth access network operators being able to justify a larger
> allocation with a straight face.

You should, however, be assigning a /48 to every end user and that’s only
65,536 allocations.

Further, you want to be able to aggregate at least one level in your network,
so you may not be able to get anything close to 100% efficiency in that
distribution.

ARIN policy, for example, defines what is known as a Provider Allocation
Unit (PAU).

Your PAU is the smallest allocation you give to your customers, so if you’re
giving out /64s, then your PAU becomes /64. If you’re giving out /56s, then
your PAU is /56. As such, you’re better off to give /48s to everyone because
that sets your PAU at /48. 

All of your utilization is measured in terms of PAUs.

You then pick an aggregation level in your network to use as your “serving center”
definition. It could be the POP, or some higher level of aggregation containing
multiple POPs.

Look at the number of end sites served by the largest of those “serving centers”
and round that up to a power of 16 (a nibble boundary, e.g. 16, 256, 4096, 65536)
such that the number of end sites is not more than 75% of the chosen poser of 16.

Then take the number of “serving centers” you expect to have in ~5 years (though
the exact forward looking time is not actually specified in policy) and round that
up to a nibble boundary as well.

That is the size of allocation you can get from ARIN.

So, for example, if you have 800,000 end-sites served from your largest POP and
you have 400 POPs, then, 800,000 would be rounded up to 16,777,216 (24 bits)
and your 400 POPs would be rounded up to 4096 (12 bits) so you would end up
needing 36 bits. If your PAU is /48, you would apply for and receive a /12.

Obviously this is an unusually large example.

At a more realistic large ISP scale, let’s say you’ve got 5,000,000 subscribers in
your largest serving center, but only 25 serving centers.

This would, again, round up to 16,777,216 (24 bits) subscribers per serving center.
But your 25 serving centers would round up to 256 (8 bits). That’s 32 bits, so instead
of a /12, you’d get a /16.

I hope that clarifies things for people.

Owen