> 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.hi...@gmail.com> > To: nanog@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 <o...@delong.com> wrote: > > > > > On Oct 9, 2014, at 7:22 AM, Daniel Corbe <co...@corbe.net> wrote: > > > > > > > > Mark Andrews <ma...@isc.org> writes: > > > > > >> In message <54366ab9.3040...@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 > > > > > > >
