IPv6 Default Allocation - What size allocation are you giving out

Thu Oct 9 17:35:55 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

Speaking for myself, I did review that doc, and had some confusion about allocating /64 to Resi-Subscribers.

However the broader discussion seems to evolved into a /48 vs  /56  discussion, and looks like there is a decent compelling case being made for /48 and not to bother with /56's ...

:)

Faisal Imtiaz
Snappy Internet & Telecom

----- Original Message -----
> From: "Richard Hicks" <richard.hicks at gmail.com>
> To: nanog at nanog.org
> Sent: Thursday, October 9, 2014 12:29:21 PM
> Subject: Re: IPv6 Default Allocation - What size allocation are you giving out
> 
> 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
> >
> >
> >
>