[ 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
