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