Assigning IPv6 /48's to CPE's?

Mailman List Mirror (Read Only)
1

I see there is a long thread on IPv6 address assignment going, and I
apologize that I did not read all of it, but I still have some unanswered
questions.

The answers to some of this are buried within it.

I believe someone posted the ARIN recommendation that carriers assign out
/64's and /56's, and in a few limited cases, /48.

I can understand corporations getting more than a /64 for their needs, but
certainly this does not mean residential ISP subscribers, right?

That answer, along with detailed information, is within that thread. In an
ideal world, yes, it does mean resi subscribers. Some of us would like to
see that very much, but are simultaneously expecting that something less
optimal will happen.

I can understand the need for /64's because the next 64 bits are for the
client address, but there seems to be this idea that one and only one node
may use a whole /64.

Certainly, if the node is the only one on the subnet.

So in the case of Joe, the residential DSL subscriber
who has 50,000 PCs, TiVo's, microwaves, and nanobots that all need unique
routable IP addresses, what is to stop him from assigning them unique client
ID's (last 64 bits) under the same /64? We can let Joe put in some switches,
and if that isn't enough he should consider upgrading from his $35/month DSL
or $10/month dial up anyway.

I don't think it was ever in doubt that people could stick lots of devices
on a single /64. The question is more one of "under what circumstances
would a site want more than a /64."

One is when you're crossing boundaries between network protocols (Ethernet
to HomeControlNet or whatever). Repeat for Bluetooth or any other
alternative technology.

Many would prefer to see firewalling handled at the L3 boundary between
networks, which is an indication for multiple /64's. While I certainly
agree that this is attractive, and ought to be possible in IPv6, the fact
is that it still represents a disruption of the broadcast domain, and
requires that all firewall-candidate traffic be routed. This could have
an impact to a site that deems a sudden firewall policy change necessary,
such as "my PC #3 just got infected, stop it from talking to local
network but allow it to download virus updates." I believe that there
could (and should) be a natural evolution towards deconstructing the
requirements at which layer these sorts of policies are implemented. I
would very much like to see a layer 2/3 switch that is capable of
implementing a firewall policy /for a port/, and having the onboard
software be sufficiently intelligent that an end-user can deal with his
firewalling switch as an abstract item, without having to understand
the underlying network topology. This could even be generalized into a
useful "general purpose networking" device, that could provide services
such as VPN's.

However, I am certain that there will be situations in which DHCP PD does
not work, and so I expect that most protocol bridges will in fact be able
to support bridging from an already populated IPv6 /64.

My next question is that there is this idea that there will be no NAT in the
IPv6 world. Some companies have old IPv4 only software, some companies have
branch offices using the same software on different networks, and some like
the added security NAT provides.

What "added security" would that be, exactly? Introducing a proper stateful
firewall would give you about the same security, without the penalties of
having to write proxyware for every new protocol that comes along. There
/are/ some differences; a NAT gateway is less likely to fail to firewall in
a catastrophic manner, for example: if it isn't working, network
connectivity vaporizes. A stateful firewall might go away and leave you
with your pants down. However, that doesn't really make NAT a better
technology...

{P,N}AT is a technology that was designed to allow more than one computer
to share {ports, addresses}. This is fundamentally unnecessary in IPv6
because there are plenty of addresses available, and providers are expected
to hand them out like candy.

I would much prefer to see a different security model evolve, where even
residential class equipment gains the ability to do smart firewalling.
Some of that discussion is in the thread you skipped.

There are also serious privacy concerns with having a MAC address within an
IP address. Aside from opening the doors to websites to share information on
specific users, lack of NAT also means the information they have is more
detailed in households where separate residents use different computers. I
can become an IPv4 stranger to websites once a week by deleting cookies,
IPv6 means they can profile exactly what I do over periods of years from
work, home, starbucks, it doesn't matter. I don't see NAT going away any
time soon.

This seems to be an urban myth. Your current average broadband customer
is leased an IP address that may stay active for years at a time. To
imagine that most websites care about "a specific PC behind a NAT gateway"
as opposed to "the small set of users behind this IP address" is a minor
distinction at best - they can still track you, and since most households
only have a single computer, it's best to assume they can already deal with
the more difficult realities of multiple users on a single computer.

Given the ready availability of addresses, it may not be that long before
we start seeing the anti-NAT happen; a single PC that utilizes a vaguely
RFC3041-like strategy, but instead of allocating a single address at a
time, it may allocate a /pool/ of them from the local subnet, and use a
different IPv6 address for each outgoing request. Think of it as
extending the port number field into the lower bits of the address field...
I'm sure someone has a name for this already, but I have no idea what it
is.

Anyways, I suggest you run over and read

http://www.6net.org/publications/standards/draft-vandevelde-v6ops-nap-01.txt

as it is useful foundation material to explain IPv6 strategies and how they
differ from IPv4.

... JG

2

So after reading this thread for a while, it's starting to make sense
that all subnets need to be /64. So it's best to think of IPv6 like
IPX, but with a 64 bit network address. I'm curious where the 64 bits
reserved for interface comes from though. Haven't seen the history
behind that discussed really. Ethernet MACs being 48 bits would seem
like a natural choice, leaving 80 bits for network addressing. This
waste of space seems vaguely familiar to handing out Class A netblocks
20+ years ago. "We'll never run out"... Maybe it's just me though.

Chuck

3

> I see there is a long thread on IPv6 address assignment going, and I
> apologize that I did not read all of it, but I still have some unanswered
> questions.

<snip>

Anyways, I suggest you run over and read

http://www.6net.org/publications/standards/draft-vandevelde-v6ops-nap-01.txt

That ended up, after a number of revisions, being published as RFC4864
- "Local Network Protection for IPv6".

4

The comparison is mistaken. Not without a major fundamental change in
the way ip addresses are used (ridiculous waste of addresses by
end-sites causing them
to require numerous subnets and request additional /48s)

IPv6 provides ample room for growth at end sites, and giving out /32s
or so to ISPs
and telling them to hand out /48s and /56s seems reasonably conservative.
64-bits maximum length network address. It's not much a waste for
every end-user to get a /56

Think of it as IPv4, but instead of everyone having gotten a Class A,
every end site
got on average 0.00000006 of an IPv4 /32 (host address), no matter
how large their site.

1 IPv4 Class A is approximately 0.39% of available IPv4 space
1.67*10^7/(4.29*10^9)

1 IPv6 /48 is approximately 0.00000000000000000000827% of available
IPv6 space.
You need a calculator for that second one :slight_smile:

But assignable space in V6 could be exhausted without end-site IPs running out.

The place where major problems could be run into is deciding how big a
block your ISPs and
LIRs get, or if the registries are entertaining the concept of PI
space for v6.. how large
those blocks are. Does a small ISP ever get such a small block that
they may run out of /48s
to assign?

Does a large ISP ever get such a large block, the RIRs may run out of
ISP blocks to assign?

Both situations would be extremely undesirable.

In the former case, they need multiple blocks, but RIR policy for v6
might not provide a way
for them to get that.... the utilization of additional allocations
also add undesirable complexity
to networks, which is very bad: design of IPv6 is supposed to avoid
such things.

In the latter case... IPv6 IP addresses have not been 'exhausted',
but now, there can now
be no new ISPs or PI allocations; everything having been assigned to
some major provider
who has not given out very many of their /48s yet,

or who is giving out /56s and hording the rest of the address space,
never to be assigned.....

5

The place where major problems could be run into is deciding how big a
block your ISPs and
LIRs get, or if the registries are entertaining the concept of PI
space for v6.. how large

too late NRO policy comparison chart:

http://www.nro.net/documents/nro45.html#3-4-3

Specifically APNIC and ARIN have /48 end-user assignments (PI)
policies in place, RIPE is still discussing this policy as of the last
meeting (if I recall correctly).

those blocks are. Does a small ISP ever get such a small block that
they may run out of /48s
to assign?

Sure, if they mis-plan or over-sell or acquire a competitor... there
are many scenarios that could include this sort of event.

Does a large ISP ever get such a large block, the RIRs may run out of
ISP blocks to assign?

At one point DISA/DoD was looking to get a /10 from <SOME RIR> ... I
don't that went anywhere, or is still under discussion. That'd
certainly make a dent in the available space though, eh?

to networks, which is very bad: design of IPv6 is supposed to avoid
such things.

The initial design requirements/assumptions you mean, most of which
don't apply to today's world?

In the latter case... IPv6 IP addresses have not been 'exhausted',
but now, there can now
be no new ISPs or PI allocations; everything having been assigned to
some major provider
who has not given out very many of their /48s yet,

or who is giving out /56s and hording the rest of the address space,
never to be assigned.....

ah, just like in ipv4 come mid-2010 ? wither ipv8?

-Chris

6

> The place where major problems could be run into is deciding how big a
> block your ISPs and
> LIRs get, or if the registries are entertaining the concept of PI
> space for v6.. how large

too late NRO policy comparison chart:

http://www.nro.net/documents/nro45.html#3-4-3

someone pointed out that the APNIC policy doc at:

http://www.apnic.net/policy/ipv6-address-policy.html

doesn't reflect the end-user PI assignment policy wording that appears
to be in the NRO link, perhaps someone from APNIC could clarify the
current state of affairs for us?

They also pointed out that I missed Afrinic in my listing... NRO
thinks that afrinic also does /48 end-user assignments... fyi.

7

someone pointed out that the APNIC policy doc at:

http://www.apnic.net/policy/ipv6-address-policy.html

doesn't reflect the end-user PI assignment policy wording that appears
to be in the NRO link, perhaps someone from APNIC could clarify the
current state of affairs for us?

that document is pretty clear, i think. assign what is right for you
and the customer. hd is calculated in /56 virtuals. if they need more
than /48, discuss upstream.

randy

8

Some of the comments here have cleared things up a bit.

I suspect we will see NAT doing some 4to6 and 6to4 through migration, but there is little reason to use NAT in place of stateful firewall in the v6 to v6 world.

I think RFC3041 (Privacy Extensions) and RFC4864 (Local Network Protection) answer my question about MAC address privacy. I have to do some research on this, but does anyone know if Vista’s IP stack is RFC3041 compliant today? (I believe OSX is but I don’t know if it is enabled by default)

On to IP address allocation again:

So I was thinking of /64 as “one subnet” consisting of multiple nodes, when in practice a /64 is more like one node.

This does open up some interesting possibilities like using multiple IP addresses within a /64 on a single machine. You could do things on the client side like separating applications into different “security zones” with individual IP addresses, or giving individual users on the system their own IP addresses so you can do user/zone specific firewall policies.

You could have the OS allocate an IP to a local peripheral like a printer that is shared with the local network to prevent creating a potential vulnerability on one of the IP addresses applications are using to connect to the Internet.

This is cool, but it also means that the /64 is the new /32, and /56 is the new /24.

So in cases where it is anticipated that the client will (or eventually will) have more than ~255 devices, a /48 is recommended.

So now it is starting to become clear why people are handing out /48’s to end users.

9
  • /32 for ISPs unless they can justify more
  • /48 for subscribers unless they can justify more
  • /64 when you know for certain that one and only one subnet will ever be required
  • /128 when you know for certain you’re dealing with a single device
  • Sparse allocation so whichever size you choose you can usually increase it by simply changing the prefix length.

So if /64 is “subnet” rather than “node” then the practice of placing one and only one node per subnet is pretty wasteful.

And giving residential users a /48 will leave them with 80 bits for addressing.

Even if the household was using 1,000,000,000,000,000 IP addresses in their home, this would mean that they are still not using 99.9999999% of the IP addresses they have been allocated.

I know the reason for this is becasue they are allocated IP’s based on number of possible subnets, rather than total number of available IP’s, so it would be more fair to say they are allocated 65,536 subnets.

So Acme DSL has been given a /32 from ARIN. Bob their administrator promptly decides it is a good idea to just give each customer a /48 becasue who knows /what/ their needs may be.

This gives Acme Bob enough IP addresses for 2^(48-32) or 65,536 customers assuming bob uses none of these IP addresses for his own equipment and has a single homed network.

If Bob has a multihomed network, he can’t just give one /48 to a customer in NY and the next one to a customer in CA unless he wants to fill up Internet routing tables with /48’s, so he will have to assign large aggregate blocks to each region.

Accommodating for this, Bob is unlikely to plan for more than 30% utilization in any one region, with most being less and some aggregate blocks withheld entirely for growth.

So lets say Acme DSL’s IPv6 deployment places them in the ballpark of 10% utilization (not bad considering end users are wasting 99.99999999999999999999%), this gives them enough blocks for only 6,500 customers.

Take someone like Comcast with ~12 million subscribers.

It would take an IPv6 /24 to get 16.7 million /48’s (2^24). With a net efficiency of 10% they are going to need to be allocated 120 million /48’s. It would take a /21 to give them 2^(48-21) = ~134 million /48’s.

So in short, a /48 to subscribers seems like complete overkill, and a /32 to ISP’s seems completely inadequate (80 vs 16 bits).

I thought one of the goals of IPv6 was to assign ISP’s huge blocks with low utilization so they don’t have push a bunch of individual prefixes out to the worlds routing tables?

It seems to me while being extra super sure we meet goal 1 of making sure NAT is gone for ever (and ever) we fail goal 2 of not allocating a bunch of prefixes to ISP’s that are too small.

10

If Bob has a multihomed network, he can't just give one /48 to a customer in
NY and the next one to a customer in CA unless he wants to fill up Internet
routing tables with /48's, so he will have to assign large aggregate blocks
to each region.

Could you please elaborate on this? Unless Bob is actually breaking the "single AS needs to have common IGP and be connected internally", I don't understand the relevance of your statement above. Just because he's multihomed doesn't mean he can't just announce /32 and then internally handle the routing (of course he should do aggregation though, but perhaps is smaller chunks).

It seems to me while being extra super sure we meet goal 1 of making sure NAT is gone for ever (and ever) we fail goal 2 of not allocating a bunch of prefixes to ISP's that are too small.

Well, if you need a /20 for your business needs, you should request it. Afaik as long as you justify it, it shouldn't be a problem?

But I do agree that /56 should be enough for residential users for quite a while, so let's start there.

11

PS. say for example we would like to meet goal 2 while giving customers /48’s at the same time. We decide a an initial projected utilization of 1% or .1% is more appropriate for Comcast.

In order to give them 1.2 billion /48’s (1% utilization), they would need 2 /18’s.

For 12 billion (0.1% utilization), they would need a /14.
In which case the depletion of IPv6 space starts to seem possible.

Your response might be “Why would an ISP need 0.1% utilization?”
My answer: “Why would a customer need 0.000000000000000000000001% utilization?”

12

Some of the comments here have cleared things up a bit.

I suspect we will see NAT doing some 4to6 and 6to4 through migration, but
there is little reason to use NAT in place of stateful firewall in the v6 to
v6 world.

I think RFC3041 (Privacy Extensions) and RFC4864 (Local Network Protection)
answer my question about MAC address privacy. I have to do some research on
this, but does anyone know if Vista's IP stack is RFC3041 compliant today?
(I believe OSX is but I don't know if it is enabled by default)

On by default in Windows, off by default in Linux (net.ipv6.conf.all.use_tempaddr), OSX and BSD (net.inet6.ip6.use_tempaddr)

On to IP address allocation again:

So I was thinking of /64 as "one subnet" consisting of multiple nodes, when
in practice a /64 is more like one node.

This does open up some interesting possibilities like using multiple IP
addresses within a /64 on a single machine. You could do things on the
client side like separating applications into different "security zones"
with individual IP addresses, or giving individual users on the system their
own IP addresses so you can do user/zone specific firewall policies.

In my opinion /64 is very likely not a one-node configuration. Potentially you can put every computer under the world into /64. I agree the functional/operational separation is easy with /64. Earlier in IPv4 you had to think about the subnet sizes: here you have /64 and you can put as many computer as you like in that subnet!

Introduction of IPv6 support in your network allows rethinking the subnetting, and address allocation to accomodate better your current need.

Best Regards,
   Janos

13

Because announcing more specifics is more granular. Lets say we are both nationally connected and I peer with you in only one location (say CA).

If we both announce only one aggregate block to each other, if I am trying to get to you in NY from NY, we are going to do it through California (not good).

The same scenario happens if we peer on both sides of the country and one of the sessions goes down.

In this case the best path is probably me > someone else > you.

Now instead what I can do is tag my california routes with a “california” bgp community, and export only those specific routes to you there.
This way your traffic to me in NY will not go over this session.

Now unless you want a pile of /48’s handed to you over this session, it is good practice for me to aggregate my routes based on location as best I can.

14

Now instead what I can do is tag my california routes with a
"california" bgp community, and export only those specific routes to
you there. This way your traffic to me in NY will not go over this
session.

dunno about the community in which you peer. but the big kids have
pretty much insisted on consistent announcements at all peerings unless
negotiated otherwise.

randy

15

So if /64 is "subnet" rather than "node" then the practice of
placing one and only one node per subnet is pretty wasteful.

In an IPv6 network, a /64 is the subnet prefix of a single
broadcast domain, i.e. a single unbridged Ethernet segment.
Within this subnet, there are many /128s which represent
interfaces connected to the broadcast domain. These /128's
are not "nodes" in the common sense of the term, i.e. they
are not "boxes" or "devices". In some case, a device will
only have a single interface connected to the broadcast
domain, but ot could have more than one. If the device
is a virtualization host, as is increasingly common, then
it will have many virtual interfaces connected to the
broadcast domain, each of which will have a /128 assigned
to it.

And giving residential users a /48 will leave them with 80
bits for addressing.

No, it gives them 16 bits for subnetting. Everybody gets
64 bits for addressing because everybody (except oddballs
and enevelope pushers) uses a /64 subnet size. Since 64
bits are more than anyone could ever possibly need for
addressing and 16 bits is more than an end site could ever
possibly need for subnetting, the /48 is an ideal allocation
size. The whole point of IPv6 is to get rid of scarcity
and parsimony in network architecture. If you aren't giving
people more addresses than they need, then you aren't
following the fundamental IPv6 model.

Note that it is NOT wasteful to give people more addresses
than they need. It allows things like the ULA random subnet
selection algorithm to function with minimal probability of
collision.

I know the reason for this is becasue they are allocated IP's
based on number of possible subnets, rather than total number
of available IP's, so it would be more fair to say they are
allocated 65,536 subnets.

Yes! In IPv6 we do not allocate addresses, we allocate subnet
bits. We don't count addresses either, we use an HD ratio based
on counting subnets. People don't "get addresses" or "have addresses".
They get subnets and have subnets.

So Acme DSL has been given a /32 from ARIN.
Take someone like Comcast with ~12 million subscribers.

Can anybody say "scaling effects"? Comcast will never do things
like a small ISP and vice versa.

It would take an IPv6 /24 to get 16.7 million /48's (2^24).
With a net efficiency of 10% they are going to need to be
allocated 120 million /48's. It would take a /21 to give them
2^(48-21) = ~134 million /48's.

Bad calculation. IPv6 usage efficiency is measured using the
HD ratio and that is not what you are calculating. This is
an especially important point for mid-size ISPs who go for
a /32 allocation from ARIN. If you use up that /32 allocation
and go back to ARIN to request another /32, you will *NOT* be
able to bamboozle them with arbitrary figures like you are
throwing around here. You *WILL* need to demonstrate that you
meet the current HD ratio guidelines to justify another block.

I thought one of the goals of IPv6 was to assign ISP's huge
blocks with low utilization so they don't have push a bunch
of individual prefixes out to the worlds routing tables?

It would be good to seem some mid-sized ISPs presenting how
they designed their internal addressing architecture taking
into account the HD ratio needed to justify an additional
allocation. This would include how they handle BGP route
aggregation internally and externally.

--Michael Dillon

16

No, it gives them 16 bits for subnetting. Everybody gets
64 bits for addressing because everybody (except oddballs
and enevelope pushers) uses a /64 subnet size. Since 64
bits are more than anyone could ever possibly need for
addressing and 16 bits is more than an end site could ever
possibly need for subnetting, the /48 is an ideal allocation
size.

As should be clear from the previous discussion, there are plenty of
us who disagree here, and lean towards /56 for end users (typically
residential customers) while business users would get a /48 or more
based on need.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

17

> No, it gives them 16 bits for subnetting. Everybody gets
> 64 bits for addressing because everybody (except oddballs and
> enevelope pushers) uses a /64 subnet size. Since 64 bits
are more than
> anyone could ever possibly need for addressing and 16 bits is more
> than an end site could ever possibly need for subnetting,
the /48 is
> an ideal allocation size.

As should be clear from the previous discussion, there are
plenty of us who disagree here, and lean towards /56 for end
users (typically residential customers) while business users
would get a /48 or more based on need.

I wouldn't say that is a disagreement, more of an extension.
In other words, many of us believe that 16 bits per end site
is an ideal customer allocation, but feel that residential
customers in their home are not in any way penalized by
reducing this to 8 bits. They still have scope for a significant
amount of subnetting even in extreme cases like constructing an
inlaw suite plus operating a family business out of the home.

I do agree that /56 per residential customer is the ideal allocation
for a mid-sized to large ISP that has a large number of residential
customer sites on its network. I expect that most such ISPs will
implement a model with /48's to business and /56's to residential
addresses. But I also expect that smaller ISPs or those who mainly
supply business access services, will find it simpler to just give
everyone a /48.

The only place in which people have noted that there is a possibility
of running out of bits in the existing IPv6 addressing hierarchy
is when they look at a model where every residential customer gets
a /48. In that scenario there is a possibility that we might runout
in 50 to 100 years from now. If only the ISPs with a large residential
user population go to a /56 per residential site, then we have solved
the problem.

--Michael Dillon

18

So if /64 is "subnet" rather than "node" then the practice of placing one
and only one node per subnet is pretty wasteful.

The whole point here is flexibility. IEEE defined several standards for globally unique identifiers including EUI-48/MAC-48 and EUI-64.

MAC-48 should last us til 2100, but the IEEE seems to be thinking longer term and also came out with EUI-64. Rather than create a protocol that wouldn't be able to handle longer MAC addresses the IPv6 WG decided to use EUI-64 for the host address in IPv6. This works for two reasons, a) There is a defined method for converting from MAC-48 to EUI-64 addresses (and back) and b) Even if Ethernet (or whatever comes next) uses a longer MAC addresses (up to 64 bits obviously) it will still make sense in IPv6.

64 bits is also a nice multiple for 32 and 64 bit systems which doesn't hurt when you're writing routing software or designing hardware.

And giving residential users a /48 will leave them with 80 bits for
addressing.

It leaves them with 65k subnets to choose from. Would a /56 make more sense? Right now- sure- becaue we lack the imagination to really guess what might happen in the future. Nanobots each with their own address, IP connected everything, who knows? Assigning a /48 to everyone gives everyone ample room and simplifies provisioning.

I'd rather push for /48 and have people settle on /56 than push for /56 and have people settle on /64.

Take someone like Comcast with ~12 million subscribers.

It would take an IPv6 /24 to get 16.7 million /48's (2^24). With a net
efficiency of 10% they are going to need to be allocated 120 million /48's.
It would take a /21 to give them 2^(48-21) = ~134 million /48's.

In answer- so what?

So in short, a /48 to subscribers seems like complete overkill, and a /32 to
ISP's seems completely inadequate (80 vs 16 bits).

A /32 is the equivalent of a class A. How many small ISP's do you know with a class A? And larger networks? Give Comcast a /18. There is plenty of space.

IPv4 is 32 bits and has room for 4 billion addresses.
Adding one additional bit gives you 33 bits and room for 8 billion addresses. Adding two additional bits gives you room for 16 billion.

Adding 32 additional bits gives you room for 4 billion times 4 billion addresses. Seriously- stop and think about that for a second. We've taken the entire IPv4 Internet, multiplied it by 4 billion, and set that aside JUST FOR THE NETWORK PORTION of addresses! We've got 4 billion times 4 billion networks- that's a mind numbing increase in size even if you only assign a single host to each /64 subnet. If you put multiple hosts on each subnet then you've got an even larger space.

People just can't seem to wrap their head around how large the new address space is.

-Don

19

The only place in which people have noted that there is a possibility
of running out of bits in the existing IPv6 addressing hierarchy
is when they look at a model where every residential customer gets
a /48. In that scenario there is a possibility that we might runout
in 50 to 100 years from now.

Is it even a possibility then? A /48 to everyone means 48 bits left over for the network portion of the address.

That's 281,474,976,710,656 /48 customer networks. It's 16 million times the number of class C's in the current IPv4 Internet. Am I just not thinking large or long term enough?

-Don

20

Once upon a time, Donald Stahl <don@calis.blacksun.org> said:

It leaves them with 65k subnets to choose from. Would a /56 make more
sense? Right now- sure- becaue we lack the imagination to really guess
what might happen in the future. Nanobots each with their own address, IP
connected everything, who knows? Assigning a /48 to everyone gives
everyone ample room and simplifies provisioning.

Do you really think that today's allocations are going to be in use
(unchanged) when people are building homes out of IPv6-addressed
nanobots, or when people are trying to firewall the fridge from the TV
remote, etc.? I understand trying to plan for the future, but if
someone is setting all this stuff up, getting a new (and larger) IPv6
block from their ISP is going to be the easiest part in the process.

I'd rather push for /48 and have people settle on /56 than push for /56
and have people settle on /64.

Again, why the hang-up on 8 bit boundaries? Why not /52 or /60? /60 is
not much bigger than /64, but /52 gives an end-site 16 times as many
subnets as /56 while giving the ISP 16 times as many blocks as /48.