RE: Practical numbers for IPv6 allocations

["Tony Hain" <alh-ietf () tndh net>]

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
> why I have concerns about this, but they mostly revolve around the
> 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.

www.tndh.net/~tony/ietf/draft-hain-ipv6-geo-addr-00.txt shows a different
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'.

> OTOH if your business was focused primarily on residential customers
> 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