[175121] in North American Network Operators' Group
Re: IPv6 Default Allocation - What size allocation are you giving out
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Oct 9 12:04:39 2014
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <ygfh9zdqq56.fsf@corbe.net>
Date: Thu, 9 Oct 2014 09:01:45 -0700
To: Daniel Corbe <corbe@corbe.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>, manning bill <bmanning@isi.edu>
Errors-To: nanog-bounces@nanog.org
On Oct 9, 2014, at 7:22 AM, Daniel Corbe <corbe@corbe.net> wrote:
>=20
> Mark Andrews <marka@isc.org> writes:
>=20
>> 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.
>>=20
>> 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.
>>=20
>> Mark
>=20
> 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. =20
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=92m sure
those are not ARIN=92s 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=92s =
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=92re
giving out /64s, then your PAU becomes /64. If you=92re giving out /56s, =
then
your PAU is /56. As such, you=92re better off to give /48s to everyone =
because
that sets your PAU at /48.=20
All of your utilization is measured in terms of PAUs.
You then pick an aggregation level in your network to use as your =
=93serving center=94
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 =93serving =
centers=94
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 =93serving centers=94 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=92s say you=92ve 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=92s 32 =
bits, so instead
of a /12, you=92d get a /16.
I hope that clarifies things for people.
Owen
