nanog mailing list archives

Re: IPv6 Default Allocation - What size allocation are you giving out


From: Richard Hicks <richard.hicks () gmail com>
Date: Thu, 9 Oct 2014 09:29:21 -0700

Sixty replies and no one linked to the BCOP?
Is there a reason we are ignoring it?

http://bcop.nanog.org/index.php/IPv6_Subnetting

As we recently discovered ARIN is handing out IPv6
allocations on nibble boundaries.

Either a /32 or /28 for service providers.  A justification and
utilization plan is need to get a /28.  It is also double the cost
per year.


On Thu, Oct 9, 2014 at 9:01 AM, Owen DeLong <owen () delong com> wrote:


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


Mark Andrews <marka () isc org> writes:

In message <54366AB9.3040504 () 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





Current thread: