IPv6 Default Allocation - What size allocation are you giving out

Richard Hicks richard.hicks at gmail.com
Thu Oct 9 16:29:21 UTC 2014


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 at delong.com> wrote:

>
> 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
>
>
>



More information about the NANOG mailing list