# Practical numbers for IPv6 allocations

[ I normally don't say this, but please reply to the list only, thanks. ]

I've been a member of the "let's not assume the IPv6 space is
infinite" school from day 1, even though I feel like I have a pretty
solid grasp of the math. Others have alluded to some of the reasons
concepts that the address space is not actually flat (i.e., it's going
to be carved up and handed out to RIRs, LIRs, companies, individuals,
etc.) and that both the people making the requests and the people
doing the allocations have a WIDE (pardon the pun) variety of
motivations, not all of which are centered around the greater good.

I'm also concerned that the two main pillars of what I semi-jokingly
refer to as the "profligate" school of IPv6 allocation actually
conflict with one another (even if they both had valid major premises,
which I don't think they do). On the one hand people say, "The address
space is so huge, we should allocate and assign with a 50-100 year
time horizon" and on the other they say, "The address space is so
huge, even if we screw up 2000::/3 we have 7 more bites at the apple."
I DO believe that the space is large enough to make allocation
policies with a long time horizon, but relying on "trying again" if we
screw up the first time has a lot of costs that are currently
undefined, and should not be assumed to be trivial. It also ignores
the fact that if we reduce the pool of /3s because we do something
stupid with the first one we allocate from it reduces our
opportunities to do "cool things" with the other 7 that we haven't
even thought of yet.

In regards to the first of the "profligate" arguments, the idea that
we can do anything now that will actually have even a 25 year horizon
is naively optimistic at best. It ignores the day-to-day realities of
corporate mergers and acquisitions, residential customers changing
residences and/or ISPs, the need for PI space, etc. IPv6 is not a "set
it and forget it" tool any more than IPv4 is because a lot of the same
realities apply to it.

You also have to keep in mind that even if we could come up with a
theoretically "perfect" address allocation scheme at minimum the
existing space is going to be carved up 5 ways for each of the RIRs to
implement. (When I was at IANA I actually proposed dividing it along
the 8 /6 boundaries, which is sort of what has happened subsequently
if you notice the allocations at 2400::/12 to APNIC, 2800::/12 to
LACNIC and 2c00::/12 to AfriNIC.)

Since it's not germane to NANOG I will avoid rehashing the "why RA and
64-bit host IDs were bad ideas from the start" argument.

In the following I'm assuming that you're familiar with the fact that
staying on the 4-byte boundaries makes sense because it makes reverse
DNS delegation easier. It also makes the math easier.

As a practical matter we're "stuck" with /64 as the smallest possible
network we can reliably assign. A /60 contains 16 /64s, which
personally I think is more than enough for a residential customer,
even taking a "long view" into consideration. The last time I looked
into this there were several ISPs in Japan who were assigning /60s to
their residential users with good success. OTOH, a /56 contains 256
/64s, which is way WAY more than enough for a residential user. The
idea that a residential user needs a full /48 (65,536 /64s) is absurd.
OTOH, assigning a /48 to even a fairly large commercial customer is
perfectly reasonable. This would give them 256 /56 networks (which
would in turn have 256 /64 networks) which should be plenty to handle
the problems of multiple campuses with multiple subnets, etc.

So let's assume that we'll take /56 as the standard unit of assignment
to residential customers, and /48 as the standard unit of assignment
to commercial customers. A /32 has 65,536 /48s in it. If your business
was focused mainly on commercial customers that's not a very big pool.
you'd have 16,777,216 /56s to work with. That's enough for even a very
large regional ISP. One could also easily imagine a model where out of
a /32 you carve out one /34 for /56 assignments (4,194,304) and use
the other 3/4ths of the space for /48s (49,152).

A really large ("national" or even "global") ISP would obviously need
more space if they were going to intelligently divide up addresses on
a regional basis. A /28 would have 16 /32s which should be enough for
even a "very large" ISP, but let's really make sure that we cover the
bases and go /24 (256 /32s). Even if you assume splitting that address
space in half, that's 2.147483e+09 (approximately 2,147,483,000) /56s,
and 8,388,608 /48s.

There are roughly 2,097,152 /24s in 2000::/3 (I say "roughly" because
I'm ignoring space that's already been carved out, like 6to4, etc.),
or 262,144 /24s per /6, or 67,108,864 /32s per /6. Which means that
yes, we really do have "a lot" of space to work with. I also think it
means that even with "a lot" of space there is no point in wasting it
with foolish allocation policies that give out way more space than is
realistically necessary just "because we can."

I've ignored PI space up till now but I think it's reasonable for
there to be a midpoint for PI somewhere between /48 and /32.
Personally I think that a /40 has a nice sound to it. That's 256 /48
networks. I don't see any reason why the RIRs couldn't also agree to a
/36, which would be 4,096 /48s. Even I don't see any reason why they
should mess around with numbers like /41 or /43.

To get back to the question that started the original thread, if I
were the one who was requesting an IPv6 allocation I would use the
following formula:

1 /56 per # of residential customers expected in 10 years

I realize that this is quite long, so if you've gotten this far,
congratulations! I hope it was useful.

Doug

Well said Doug.

-G

Keep in mind that not all 'fairly large enterprises' are willing to
sit at a single ISP, they may have diverse offices on diverse network
provider connections. They may want the easy of saying: 'All my
address blocks are in 1.2.0.0/16' and not understand (or like) that
they now have to deal with wierd routing and addressing problems
because they can't get a /32 and break it up into /48's all over
space they'd get from ISP /48 PA assignments.

the enterprise world has changed quite a bit from IPNG's early days...
Someone who runs a large Enterprise with global office locations and
who's actually deploying ipv6 internally/externally ought to give a
presentation at NANOG and/or IETF.

I don't disagree with the math I snipped, I do appreciate you laying
it out, and I don't think that there are a super large number of folks
in the scenario I layed out above. I've seen quite a few at previous
employers though...

-Chris

FWIW - I don't believe the two arguments are in opposition/conflict ... But
totally agree with your end result of "/56s and /48s, with add'l bits held
in reserve" ...

/TJ

Doug Barton wrote:

[ I normally don't say this, but please reply to the list only, thanks.
]

I've been a member of the "let's not assume the IPv6 space is
infinite" school from day 1, even though I feel like I have a pretty
solid grasp of the math. Others have alluded to some of the reasons
concepts that the address space is not actually flat (i.e., it's going
to be carved up and handed out to RIRs, LIRs, companies, individuals,
etc.) and that both the people making the requests and the people
doing the allocations have a WIDE (pardon the pun) variety of
motivations, not all of which are centered around the greater good.

I'm also concerned that the two main pillars of what I semi-jokingly
refer to as the "profligate" school of IPv6 allocation actually
conflict with one another (even if they both had valid major premises,
which I don't think they do). On the one hand people say, "The address
space is so huge, we should allocate and assign with a 50-100 year
time horizon" and on the other they say, "The address space is so
huge, even if we screw up 2000::/3 we have 7 more bites at the apple."
I DO believe that the space is large enough to make allocation
policies with a long time horizon, but relying on "trying again" if we
screw up the first time has a lot of costs that are currently
undefined, and should not be assumed to be trivial.

I agree with the point about undefined costs, but the biggest one that is
easy to see is that 100-300 years from now when someone thinks about moving
on to the second /3, this entire discussion will have been lost and there
will be an embedded-for-generations expectation that the model is cast in
stone for all of the /3's.

It also ignores
the fact that if we reduce the pool of /3s because we do something
stupid with the first one we allocate from it reduces our
opportunities to do "cool things" with the other 7 that we haven't
even thought of yet.

way to allocate space, using only 1/16 the total space to achieve a /48
globally on a 6m grid. Other ideas will emerge, so you are correct that we
can't assume we have 8 shots at this, but if the first pass is really bad
the second will be so draconian in restrictions that you will never get to
the third.

In regards to the first of the "profligate" arguments, the idea that
we can do anything now that will actually have even a 25 year horizon
is naively optimistic at best. It ignores the day-to-day realities of
corporate mergers and acquisitions, residential customers changing
residences and/or ISPs, the need for PI space, etc. IPv6 is not a "set
it and forget it" tool any more than IPv4 is because a lot of the same
realities apply to it.

Well mostly. It is not set & forget, but a lot of the day-to-day in IPv4 is
wrapped up in managing subnet sizes to 'avoid waste'. In an IPv6 environment
the only concern is the total number of subnets needed to meet
routing/access policy, avoiding the nonsense of continually shifting the
subnet size to align with the number of endpoints over time.

You also have to keep in mind that even if we could come up with a
theoretically "perfect" address allocation scheme at minimum the
existing space is going to be carved up 5 ways for each of the RIRs to
implement. (When I was at IANA I actually proposed dividing it along
the 8 /6 boundaries, which is sort of what has happened subsequently
if you notice the allocations at 2400::/12 to APNIC, 2800::/12 to
LACNIC and 2c00::/12 to AfriNIC.)

Since it's not germane to NANOG I will avoid rehashing the "why RA and
64-bit host IDs were bad ideas from the start" argument.

People need to get over it... the original design was 64 bits for both hosts
and routing exceeding the design goal by >10^3, then routing wanted more so
it was given the whole 64 bits. The fact that 64 more bits was added is not
routing's concern, but the IPv4-conservation mindset can't seem to let it go
despite having >10^6 more space to work with than the target. It could have
been 32 bits (resulting in a 96 bit address), but given that 64 bit
processors were expected to be widespread, it makes no sense to use less
than that.

In the following I'm assuming that you're familiar with the fact that
staying on the 4-byte boundaries makes sense because it makes reverse
DNS delegation easier. It also makes the math easier.

I assume you meant 4-bit.
^^^

As a practical matter we're "stuck" with /64 as the smallest possible
network we can reliably assign. A /60 contains 16 /64s, which
personally I think is more than enough for a residential customer,
even taking a "long view" into consideration.

Stop looking backward. To achieve the home network of the last millennium a
small number of subnets was appropriate. Constraining the world to that
through allocation is a self-fulfilling way to force people that need more
than that to develop/deploy hacks to work around the braindead practice.

The last time I looked
into this there were several ISPs in Japan who were assigning /60s to
their residential users with good success. OTOH, a /56 contains 256
/64s, which is way WAY more than enough for a residential user. The
idea that a residential user needs a full /48 (65,536 /64s) is absurd.

A consumer is not a professional network operator and can't do 'well
managed' subnet structures the way that this community would. To allow a
plug-n-play consumer network, a fair amount of 'waste' is required.

OTOH, assigning a /48 to even a fairly large commercial customer is
perfectly reasonable. This would give them 256 /56 networks (which
would in turn have 256 /64 networks) which should be plenty to handle
the problems of multiple campuses with multiple subnets, etc.

So let's assume that we'll take /56 as the standard unit of assignment
to residential customers, and /48 as the standard unit of assignment
to commercial customers. A /32 has 65,536 /48s in it. If your business
was focused mainly on commercial customers that's not a very big pool.

A /32 is a starter-kit for a new ISP with no customers, so this argument is
a continuation of the bogus 'denial' mindset used to avoid deployments. A
real ISP should be documenting the number of customers they have * /48, then
add in normal hierarchy loss and get a 'REAL BLOCK'.

you'd have 16,777,216 /56s to work with. That's enough for even a very
large regional ISP. One could also easily imagine a model where out of
a /32 you carve out one /34 for /56 assignments (4,194,304) and use
the other 3/4ths of the space for /48s (49,152).

A really large ("national" or even "global") ISP would obviously need
more space if they were going to intelligently divide up addresses on
a regional basis. A /28 would have 16 /32s which should be enough for
even a "very large" ISP, but let's really make sure that we cover the
bases and go /24 (256 /32s). Even if you assume splitting that address
space in half, that's 2.147483e+09 (approximately 2,147,483,000) /56s,
and 8,388,608 /48s.

There are roughly 2,097,152 /24s in 2000::/3 (I say "roughly" because
I'm ignoring space that's already been carved out, like 6to4, etc.),
or 262,144 /24s per /6, or 67,108,864 /32s per /6. Which means that
yes, we really do have "a lot" of space to work with. I also think it
means that even with "a lot" of space there is no point in wasting it
with foolish allocation policies that give out way more space than is
realistically necessary just "because we can."

I agree we should not be foolish, but that includes not partitioning the
space into a bunch of discontiguous blocks just 'because that is how we did
IPv4'. From a big picture perspective we have already avoided 'waste' by
agreeing to limitations on how much a new ISP gets and using a justification
process for those that need more. The fact that end customers are not
required to do the same level of justification (until they get really
large), is avoiding waste in terms of process. The lack of tight control at
the edge allows for innovation, which in turn drives the whole system
forward.

I've ignored PI space up till now but I think it's reasonable for
there to be a midpoint for PI somewhere between /48 and /32.
Personally I think that a /40 has a nice sound to it. That's 256 /48
networks. I don't see any reason why the RIRs couldn't also agree to a
/36, which would be 4,096 /48s. Even I don't see any reason why they
should mess around with numbers like /41 or /43.

I personally agree, but we have a structure in place, and it has to have
something to do to justify its continued existence.

To get back to the question that started the original thread, if I
were the one who was requesting an IPv6 allocation I would use the
following formula:

1 /56 per # of residential customers expected in 10 years
+
1 /48 per # of business customers expected in 10 years

I would make that /48 & /44

Then assuming your current numbers are roughly 1/16th of what you hope
they'll be in 10 years; when actually handing out addresses I'd give
out the first /60 from each /56 to the residential customers. That way
if you need to you can go back and chop up those /56s.

BS ... go back and get the larger block that supports the current customer
base. The argument you present here says that an ISP gets one & only one
shot at an allocation. The only way the approach of growing the request to
match the customer base will ever be a problem is if every person on the
planet individually subscribed to every service provider, but even that
nonsense would work up to 32k providers globally.

I'd also start
off handing out the first /48 out of every /44 to my commercial
customers. That way they will have room to expand painlessly. This is
sort of a bastardized version of the "sparse allocation" model that
the RIRs have promoted. (Obviously the 1/16th number was chosen for
convenience, but hopefully you get the idea of what I'm going for
here.)

I realize that this is quite long, so if you've gotten this far,
congratulations! I hope it was useful.

As people emerge from denial they need this type of lengthy and well
reasoned line of thought, even though I disagree with some of the details.

Tony

Tony Hain wrote:

Doug Barton wrote:

In the following I'm assuming that you're familiar with the fact that
staying on the 4-byte boundaries makes sense because it makes reverse
DNS delegation easier. It also makes the math easier.

I assume you meant 4-bit.

Grrr, I hate when I do that. I spent quite a bit of time on this post,
and the one time I remembered that I needed to go back and
double-check what I wrote there I wasn't at the keyboard. Thanks for
keeping me honest.

There was one other thing you wrote that I wanted to clarify, you
indicated that I was arguing for ISPs to only get one shot at an IPv6
allocation. Since my post was already really long I chose to leave out
the bit about how (TMK, which could be outdated) the RIRs are
reserving a bit or two for their allocations to ISPs so going back and
expanding should be an easy thing to do. On a personal note, I hope
that we DO need to expand IPv6 allocations to ISPs as this thing
finally gets deployed.

I'm not responding to the rest of your post because you and I have
already had those discussions in person on more than one occasion and
I know I'm not going to change your mind. I do think it's extremely
gracious of you to say that my post was "well reasoned" though.

Thanks to the others who had nice things to say as well.

Regards,

Doug

My understanding is that the RIRs are doing sparse allocation, as opposed to reserving a few bits. I could be wrong.

Last I heard, with the exception of APNIC and contrary to what they indicated they'd do prior to IANA allocating the /12s, you are indeed wrong. I'd be happy to hear things have changed.

Regards,
-drc

Sigh. Seem to have troubles posting coherent English to the Nanog list recently. The "they" in the above sentence references the RIRs except for APNIC (last I heard).

Regards,
-drc

My understanding is that the RIRs are doing sparse allocation, as opposed to reserving a few bits. I could be wrong.

Last I heard, with the exception of APNIC and contrary to what they indicated they'd do prior to IANA allocating the /12s, you are indeed wrong. I'd be happy to hear things have changed.

Only APNIC is doing "bisection" style assignments today:

20091001|apnic|AU|ipv6|2402:c00::|32|allocated
20091001|apnic|SG|ipv6|2402:400::|32|allocated
20091005|apnic|JP|ipv6|2402:1400::|32|allocated
20091006|apnic|NZ|ipv6|2402:1c00::|32|allocated

20090930|arin|US|ipv6|2607:fd70::|32|allocated
20090930|arin|CA|ipv6|2607:fd78::|32|allocated
20091001|arin|US|ipv6|2607:fd80::|32|allocated
20091006|arin|US|ipv6|2607:fd88::|32|allocated

20091005|ripencc|RU|ipv6|2a00:1440::|32|allocated
20091005|ripencc|SI|ipv6|2a00:1448::|32|allocated
20091005|ripencc|IE|ipv6|2a00:1450::|32|allocated
20091005|ripencc|BE|ipv6|2a00:1458::|32|allocated

20090709|lacnic|PY|ipv6|2800:3a0::|32|allocated
20090714|lacnic|CL|ipv6|2800:3b0::|32|allocated
20090807|lacnic|GY|ipv6|2800:3c0::|32|allocated
20090903|lacnic|AR|ipv6|2800:3d0::|32|allocated

20090708|afrinic|GH|ipv6|2001:43c0::|32|allocated
20090729|afrinic|EG|ipv6|2001:43c8::|32|allocated
20090813|afrinic|KE|ipv6|2001:43d0::|32|allocated
20090909|afrinic|ZA|ipv6|2001:43d8::|32|allocated

- Kevin