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