Practical numbers for IPv6 allocations

Tue Oct 6 12:00:57 UTC 2009

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

On Mon, Oct 5, 2009 at 11:39 PM, Doug Barton <dougb at dougbarton.us> 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. 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.
> 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'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
> +
> 1 /48 per # of business customers expected in 10 years
>
> 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. 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.
>
>
> Doug
>
> --
>
> Food for thought is no substitute for the real thing.
>                -- Walt Kelly, "Potluck Pogo"
>
>
>

-- 
/TJ