European ISP enables IPv6 for all?

Date: Tue, 18 Dec 2007 11:30:55 -0500
From: Jared Mauch <jared@puck.nether.net>
Sender: owner-nanog@merit.edu

>
> * Jeroen Massar:
>
> > For a list of ISP's doing IPv6 check:
> > FAQ : Connectivity (Tunnels and Subnets) : Where can I get native IPv6 / Which ISPs provide IPv6? :: SixXS - IPv6 Deployment & Tunnel Broker
>
> Does PPPv6 still work on the T-DSL platform? 8-/
>
> The list would be more convincing if it contained links to product
> pages.

  You likely want to look at this page:

FAQ : Connectivity (Tunnels and Subnets) : Where can I get native IPv6 transit? :: SixXS - IPv6 Deployment & Tunnel Broker

  This is the page that has those that are doing native
that are reasonably major service providers.

Note that sixxs only deals with commercial providers. Many (most?) of
the major research and education networks around the globe have done
IPv6 in production for years. That includes ESnet, DREN, NREN and
Internet2 in the US, CAnet in Canada, Geant/Dante in Europe and a number
of national networks in Asia.

At least ESnet has offered IPv6 as a production service for several
years including DNS service. If you check the headers, you should see
that this message started out via IPv6 and, if your mail host is IPv6
reachable, took IPv6 for the entire path.

That said, while we provide IPv6 services, we see minimal traffic and
have found that IPv6 is, at best, poorly supported by most vendors
(excluding host OS vendors). Most hosts support IPv6 fairly well, but
switching and routing equipment lacks many features for IPv6 that are
present for IPv4 and system management and security products tend to be
even worse. E.g. try SNMP access to your routers by IPv6 and you might find a
few problems, depending on the vendor...and don't expect much help from
the vendor.

If you see IPv6 as a solution to the exhaustion of IPv4 space, take a
look at http://www.civil-tongue.net/clusterf/. It may help at some
point, but many of us see no clear way to get from here to there without
massive growth in both the RIB and the FIB in the process.

I am actually more concerned with the CPE problem and how to make autoconfiguration work for end users.

For instance, should we assign /64 to end users and have them do whatever they need (subnet to /80 if they need more than one network)? We need to provision routes in whatever routers connect to customers, which I guess is the FIB/RIB-problem mentioned above?

Is there general agreement that IPv6 requires a router at the customer prem to scale (ISP doesn't want to know what the end user devices are)?
Also, is it ok to statically assign /64 to end user or should end user be able to switch addresses (some like dynamic IPs because it's not persistant over time and like the "privacy" you get by changing IP all the time).

I haven't been able to find a BCP regarding the end user equipment and how to configure it, does anyone have any pointers?

If you see IPv6 as a solution to the exhaustion of IPv4 space, take a
look at http://www.civil-tongue.net/clusterf/. It may help at some
point, but many of us see no clear way to get from here to there without
massive growth in both the RIB and the FIB in the process.

I am actually more concerned with the CPE problem and how to make autoconfiguration work for end users.

For instance, should we assign /64 to end users and have them do whatever they need (subnet to /80 if they need more than one network)? We need to provision routes in whatever routers connect to customers, which I guess is the FIB/RIB-problem mentioned above?

Is there general agreement that IPv6 requires a router at the customer prem to scale (ISP doesn't want to know what the end user devices are)?
Also, is it ok to statically assign /64 to end user or should end user be able to switch addresses (some like dynamic IPs because it's not persistant over time and like the "privacy" you get by changing IP all the time).

In my opinion there is two type of users as usually ISP services are marketed:

1. Home user - not really interested in configuration of their devices - they just want Internet (now IPv4, soon IPv4 and IPv6) connectivity: They generaly don't use more than one LAN internally. All their devices are connected either directly to ISP device or to the home-gateway purchased at the cornet. In this case the /64 with autoconfiguration is the best option. User don't have to configure anything (may be enabling IPv6 on their computers).

2. Power users/business users - they can configure their devices, and they want measured and reported SLAs. If they want IPv6 they can articulate their needs: /64, /60, /56, or /48 with prioritisation, filtering
and other business needs. In this case DHCPv6 prefix delegation seems to be the most flexible solution. Since they can configure basic things on their device. The ISP can help them and negotiate accordingly...

In my opinion 99% of the users belongs to the home user category. However I think 80% the IPv6 traffic volume will be generated by power/business users.

I haven't been able to find a BCP regarding the end user equipment and how to configure it, does anyone have any pointers?

There is a draft that starts addressing the CPE problem available at:

If you think you can contribute, IETF v6ops welcomes you.

Best Regards,
      Janos Mohacsi

I am actually more concerned with the CPE problem and how to make autoconfiguration work for end users.

For instance, should we assign /64 to end users and have them do whatever they need (subnet to /80 if they need more than one network)?

Subnets that aren't /64 don't support autonegotiation so you can't really subnet a /64 in practice. This means that you should probably give your customers something bigger, like a /64, a /56 or even a /48. (Yes, we have enough address space for a /48 per customer.)

The tricky part is provisioning a subnet to a customer. There is a good protocol for that: DHCPv6 prefix delegation. But there aren't any CPEs on the market that support this. (If it wasn't for Apple's Airport Extreme base station and a few somewhat expensive and hard to configure Cisco boxes you could argue that there aren't any IPv6-capable CPEs commercially available in the first place.)

We need to provision routes in whatever routers connect to customers, which I guess is the FIB/RIB-problem mentioned above?

Don't think so. As long as you don't let your customers take their address space with them when they move you can aggregate customer space in your network (you can even waste some address space for that without complaints from ARIN) so in practice your IPv6 routing tables will probably be smaller than their IPv4 counterparts.

Is there general agreement that IPv6 requires a router at the customer prem to scale (ISP doesn't want to know what the end user devices are)?

The alternative is having your device act as the default gateway in your customer's LAN, which more or less means you need to have a separate subnet/VLAN per customer, which is usually not the best way to go in larger setups. Don't expect to be doing much with DHCP for IPv6, though, most stuff that's out there today doesn't support it and you still need router advertisements because DHCPv6 doesn't tell you your default gateway.

Also, is it ok to statically assign /64 to end user or should end user be able to switch addresses (some like dynamic IPs because it's not persistant over time and like the "privacy" you get by changing IP all the time).

Customers can already randomize the lower 64 bits of their address so there is some level of privacy. In a prefix delegation system I would probably make things such that customers get the same addresses for some time (a few months) but I get to change their prefix if/when I want to.

I haven't been able to find a BCP regarding the end user equipment and how to configure it, does anyone have any pointers?

Unfortunately, there is no industry-wide consensus on how CPEs and ISP equipment should interact for IPv6, so it's probably not possible at this point in time to make a CPE that will completely autoconfigure unless you stick to 6to4 tunneling which gets the job done but is less than optimal because it needs public gateways.

The good part about using /48 is that it gives customers an even : boundry for their space. Apart from that, I think /56 is a better idea (or perhaps even a /60). Good point there about autoconfiguration, subnetting using less than /64 is probably a bad idea.

So, out of our /32, if we assign each customer a /48 we can only support 65k customers. So in order to support millions of customers, we need a new allocation and I would really like for each new subnet allocated to be very much larger so we in the forseeable future don't need to get a newer one. So for larger ISPs with millions of customers, next step after /32 should be /20 (or in that neighborhood). Does RIPE/ARIN policy conform to this, so we don't end up with ISPs themselves having tens of aggregates (we don't need to drive the default free FIB more than what's really needed).

Other option is to have more restrictive assignments to end users and therefore save on the /32, but that might be bad as well (long term).

From the RIPE perspective, there are seven "empty" /32s between my /32 and the next allocation.

I imagine this is fully intentional, and allows the NCC to grow my v6 address pool, without growing my footprint in the v6 routing table.

Andy

Changing subject for these replies which will definitely be a bit on the
quite mean side... no offense but start reading for once. Next to that
there are also LIR courses which cover all of this.

(see other mail for /56 for end-user-sites, /48 for end-business-sites)

Mikael Abrahamsson wrote:
[..]> So, out of our /32, if we assign each customer a /48 we can only

support 65k customers.

Can I read from this that you never actually read any of the $RIR policy
documentation about getting IPv6 address space even though you did
request a /32 before, clearly without thinking about it?

So in order to support millions of customers, we need a
new allocation

"new" as in "We already have one, but we actually didn't really know
what we where requesting, now we need more"

and I would really like for each new subnet allocated to

be very much larger so we in the forseeable future don't need to get a
newer one. So for larger ISPs with millions of customers, next step
after /32 should be /20 (or in that neighborhood). Does RIPE/ARIN
policy conform to this, so we don't end up with ISPs themselves having
tens of aggregates (we don't need to drive the default free FIB more
than what's really needed).

This explains quite a bit why people are looking so weird when certain
other organizations get a /20 and upward from $RIR.

My suggestion: start reading.

Other option is to have more restrictive assignments to end users and
therefore save on the /32, but that might be bad as well (long term).

That would be stupid and totally against the idea of IPv6.

Andy Davidson wrote:
[..]

From the RIPE perspective, there are seven "empty" /32s between my /32
and the next allocation.

I imagine this is fully intentional, and allows the NCC to grow my v6
address pool, without growing my footprint in the v6 routing table.

That is exactly what it is for. Then again, if you actually had
*PLANNED* your address space like you are supposed to when you make a
request you could have already calculated how much address space you
really needed and then justify it to the $RIR. In case you have to go
back to ask the $RIR for more you already made a mistake while doing the
initial request...

Greets,
Jeroen

Kevin Oberman wrote:
[..]

Note that sixxs only deals with commercial providers. Many (most?) of
the major research and education networks around the globe have done
IPv6 in production for years. That includes ESnet, DREN, NREN and
Internet2 in the US, CAnet in Canada, Geant/Dante in Europe and a number
of national networks in Asia.

Which is a well know fact and who have quite a limited set of end-sites
who can actually connect to them, that is why these are not listed.
Similarly it doesn't list hosting providers either, enabling a colo to
do IPv6 should be childs play, getting it to the enduser though... :wink:

That said, while we provide IPv6 services

You provide services and access, but which places are actually enabled
to use it? That the network is there is one thing, this is the easy
part, linking up the end-sites is the hard one.

Greets,
Jeroen

Mohacsi Janos wrote:
[..]

In my opinion there is two type of users as usually ISP services are
marketed:

1. Home user - not really interested in configuration of their devices -
they just want Internet (now IPv4, soon IPv4 and IPv6) connectivity:
They generaly don't use more than one LAN internally. All their devices
are connected either directly to ISP device or to the home-gateway
purchased at the cornet. In this case the /64 with autoconfiguration is
the best option. User don't have to configure anything (may be enabling
IPv6 on their computers).

This would force these places to:
a) use bridging to get that single /64 onto their network
    thus making firewalling really difficult.
b) get a 'power users' abo, which would thus make people have
    to PAY for getting more IP addresses.

ISP's are paying their transits by paying for the *BANDWIDTH* usage.
So why don't ISP's have a couple of classes (to keep it simple) which
are like eg:
  10Gb account
  50Gb account
100Gb account

This would also solve the "Those stupid users are torrenting" problem,
as they are PAYING for the traffic and other costs that you actually have.

Don't charge for IP addresses, charge for *BANDWIDTH* usage. If I have
200 devices on the network which don't do a thing (maybe they are light
bulbs or it is my fridge) I will do much less traffic than one single
user who is trying to complete his nature movie collection.

2. Power users/business users - they can configure their devices, and
they want measured and reported SLAs. If they want IPv6 they can
articulate their needs: /64, /60, /56, or /48 with prioritisation,
filtering
and other business needs. In this case DHCPv6 prefix delegation seems to
be the most flexible solution. Since they can configure basic things on
their device. The ISP can help them and negotiate accordingly...

Scratching the 'power users' concept, as they belong in the above home
user part, I agree.

Greets,
Jeroen

With respect, Jeroen, because I did *PLAN* (your emphasis) our organisational requirements, this is precisely the reason why I think it's significant that a lot of space was left unallocated following my allocation.

My RIR only asked me to *PLAN* two years in advance (see ripe-414 [footnote 0]), though prudent organisations may plan for longer. I thought it was significant (and good) to note that they are allow me room to grow sometime after that period.

If you offer the sweeping statement that anyone who ever needs to go back to the RIR for more space has made a 'mistake' with their requirement planning shows you're only thinking in an incredibly short term manner. Unless, of course, you are only used to working in companies which do not grow. :slight_smile:

Can I read from this that you never actually read any of the $RIR policy
documentation about getting IPv6 address space even though you did
request a /32 before, clearly without thinking about it?

I never requested IPv6 space personally. I work with routing, not with LIR administration. I also know that RIR people don't work with routing, and it shows.

"new" as in "We already have one, but we actually didn't really know what we where requesting, now we need more"

We got our current block in 2000 (or earlier, I don't know for sure, but 2000 at the latest). So yes, we didn't know what we were doing back then. Then again, I'd say nobody knew back then.

That is exactly what it is for. Then again, if you actually had *PLANNED* your address space like you are supposed to when you make a request you could have already calculated how much address space you really needed and then justify it to the $RIR. In case you have to go back to ask the $RIR for more you already made a mistake while doing the initial request...

The world tends to change in 7 years. You seem to like bashing people for not knowing future policy and changes 7 year ahead of time, which I think it quite sad.

Mohacsi Janos wrote:
[..]

In my opinion there is two type of users as usually ISP services are
marketed:

1. Home user - not really interested in configuration of their devices -
they just want Internet (now IPv4, soon IPv4 and IPv6) connectivity:
They generaly don't use more than one LAN internally. All their devices
are connected either directly to ISP device or to the home-gateway
purchased at the cornet. In this case the /64 with autoconfiguration is
the best option. User don't have to configure anything (may be enabling
IPv6 on their computers).

This would force these places to:
a) use bridging to get that single /64 onto their network
   thus making firewalling really difficult.

I am not quite sure. My colleague tested NetScreen box with /64 advertised from LNS. It seems to be working.

b) get a 'power users' abo, which would thus make people have
   to PAY for getting more IP addresses.

They aready do it. In Hungary, if you are home user you can have 1 single IPv4 address. If you are a business customer, then your can have an address space allocated from your provider. You pay more if you need bigger address block....

Best Regards,

So, out of our /32, if we assign each customer a /48 we can only support 65k customers. So in order to support millions of customers, we need a new allocation and I would really like for each new subnet allocated to be very much larger so we in the forseeable future don't need to get a newer one. So for larger ISPs with millions of customers, next step after /32 should be /20 (or in that neighborhood). Does RIPE/ARIN policy conform to this, so we don't end up with ISPs themselves having tens of aggregates (we don't need to drive the default free FIB more than what's really needed).

RIPE has been giving out _extremely_ large IPv6 blocks on occasion. I'm sure that the other RIRs will also give you a bigger block than /32 if you expect to need more than that, so please don't limit what you give to your customers.

From the RIPE perspective, there are seven "empty" /32s between my /32 and the next allocation.

I imagine this is fully intentional, and allows the NCC to grow my v6 address pool, without growing my footprint in the v6 routing table.

Unfortunately, they do this without there being a community-supported policy in place.

IPv4 experience also shows that people rarely merge the adjoining space with the existing block when they get the extra space. So all this does is fragment the address space and make prefix length filters harder. This is really a very bad policy.

> "new" as in "We already have one, but we actually didn't really know
> what we where requesting, now we need more"

We got our current block in 2000 (or earlier, I don't know for sure, but
2000 at the latest). So yes, we didn't know what we were doing back then.
Then again, I'd say nobody knew back then.

I'd say it's fair to bet that quite a few folks in all regions pursued
ipv6 allocations more than 3-5 years ago when the policy was
essentially '/32 per provider, simply show a business plan for
providing services to 200+ customers in the next N years' (without
much in the way of planning or proof-of-planning).

> That is exactly what it is for. Then again, if you actually had
> *PLANNED* your address space like you are supposed to when you make a
> request you could have already calculated how much address space you
> really needed and then justify it to the $RIR. In case you have to go
> back to ask the $RIR for more you already made a mistake while doing the
> initial request...

The world tends to change in 7 years. You seem to like bashing people for
not knowing future policy and changes 7 year ahead of time, which I think
it quite sad.

in the case of allocation policy for ipv6 things have changed
significantly in the last 2-3 years certainly. It's probably also
important to look further in the future than the current RIR policy
decision process requires. ARIN/RIPE (atleast) have a 2 year planning
horizon for LIR allocations, this isn't sufficient for ipv6 which is
supposed to last significantly longer and be as limited in
prefix/entity as possible. Some large providers are attempting to plan
5-10 years out for address policy if possible, not everyone has that
luxury, but in the end we (internet routing community) want limited
prefixes/org that means planning horizons have to be adjusted up from
2yrs to <something else>.

-Chris

also for Comcast and Cox (I believe) in the US and Verizon (I know)
you aren't paying for 'ip addresses' but for 'management
of/change-request-for ip addresses'... which is a scam since in any of
these cases they update their 'radius' server (dhcp/radius/blah) once
and everything's done. hurah!

Mikael Abrahamsson wrote:
[..]

The world tends to change in 7 years. You seem to like bashing people
for not knowing future policy and changes 7 year ahead of time, which I
think it quite sad.

Not intended that way. What I was really surprised, and critical, of
though is you mentioning that you say "So, out of our /32, if we assign
each customer a /48 we can only support 65k customers. So in order to
support millions of customers, we need a new allocation", which I read
as "We got a /32 recently, but never thought that we should give /48's
to endsites". Changes the interpretation quite a bit.

But even in 2000 the policy was and still is:
/128 for really a single device
/64 if you know for sure that only one single subnet will
      ever be allocated.
/48 for every other case (smart bet, should be used per default)

As such, if you have near 60k customers then you should already have
realized that you needed more than a /32, especially as you can then
also guess that in a couple of years it will be quite a bit more. For
the longer term, I guess 7 years might fall into that by now, thus if
you got a /32 in 2000 and you had 10k customers then you should be fine.
If you already had 200k customers or so and then only requested a /32
though I think one can definitely state you made a big booboo.

Andy Davidson wrote:
[..]

With respect, Jeroen, because I did *PLAN* (your emphasis) our
organisational requirements, this is precisely the reason why I think
it's significant that a lot of space was left unallocated following my
allocation.

Correct, that is a good thing.

My RIR only asked me to *PLAN* two years in advance (see ripe-414
[footnote 0]), though prudent organisations may plan for longer. I
thought it was significant (and good) to note that they are allow me
room to grow sometime after that period.

Nothing wrong there indeed and you should indeed at least plan for two
years and probably more, when adding HD ratio and some prospects one
should easily come up with a pretty good ballpark figure of clients that
you will be having. Unless you will suddenly in a year grow by 60k
clients (might happen) or really insanely with other large amounts your
initial planning should hold up for quite some while

If you offer the sweeping statement that anyone who ever needs to go
back to the RIR for more space has made a 'mistake' with their
requirement planning shows you're only thinking in an incredibly short
term manner. Unless, of course, you are only used to working in
companies which do not grow. :slight_smile:

As mentioned above, not the way I intended it to mean.

Greets,
Jeroen

Mohacsi Janos wrote:

This would force these places to:
a) use bridging to get that single /64 onto their network
   thus making firewalling really difficult.

I am not quite sure. My colleague tested NetScreen box with /64
advertised from LNS. It seems to be working.

If you are routing the /64, thus that it exists entirely on the
clien-side, then it should work, but if you are allocating 1 single /64
to the customer, and eg keeping ::1 as the ISP side, then you have to do
weird magic to make that work.

b) get a 'power users' abo, which would thus make people have
   to PAY for getting more IP addresses.

They aready do it. In Hungary, if you are home user you can have 1
single IPv4 address. If you are a business customer, then your can have
an address space allocated from your provider. You pay more if you need
bigger address block....

That is IPv4 and seems to be the case in general for IPv4.
That mentality needs to be stopped for IPv6.

When an ISP is not going to provide /48's to endusers then RIPE NCC
should revoke the IPv6 prefix they received as they are not following
the reasons why they received the prefix for.

Greets,
Jeroen

Christopher Morrow wrote:

"new" as in "We already have one, but we actually didn't really know
what we where requesting, now we need more"

We got our current block in 2000 (or earlier, I don't know for sure, but
2000 at the latest). So yes, we didn't know what we were doing back then.
Then again, I'd say nobody knew back then.

I'd say it's fair to bet that quite a few folks in all regions pursued
ipv6 allocations more than 3-5 years ago when the policy was
essentially '/32 per provider, simply show a business plan for
providing services to 200+ customers in the next N years' (without
much in the way of planning or proof-of-planning).

HD ratio and all related documentations have existed for quite some time
already. If they would have read the docs they would have understood
what it meant and also gotten the reason why they asked for the 200+
rule in the first place.

[..] Some large providers are attempting to plan
5-10 years out for address policy if possible, not everyone has that
luxury, but in the end we (internet routing community) want limited
prefixes/org that means planning horizons have to be adjusted up from
2yrs to <something else>.

I can fully agree with this and it is definitely something that one
might want to push into the RIRs. I actually hope that most ISP's do
realize that they might become a bit larger in a few years, fortunately
there is the 7 adjacent /32's that can be used for sizing up quite a
bit. The only thing then is to hope that only the aggregate ends up in BGP.

Greets,
Jeroen

you got a /32 in 2000 and you had 10k customers then you should be fine.
If you already had 200k customers or so and then only requested a /32
though I think one can definitely state you made a big booboo.

From what I have been told by my colleagues, we actually received a /35

back then and the requirement was to have 200 end users, otherwise you basically couldn't receive a "PA" at all. This was then converted into a /32 at a later date, I guess due to a change in policy.

So my wondering is basically, if we say we have millions of end users right now and we want to give them a /56 each, and this is no problem, then the policy is correct. We might not have them all IPv6 activated in 2 years which is the RIR planning horizon. I do concur with other posters here that the planning horizon for IPv6 should be longer than three years so we get fewer prefixes in the DFZ as a whole. Then again, *RIR people don't care about routing so I am still sceptical about that being taken into account.

you will be having. Unless you will suddenly in a year grow by 60k clients (might happen) or really insanely with other large amounts your initial planning should hold up for quite some while

We grow by much more than 60k a year, it's just hard to plan for it. If we project for the highest amount of growth then we're most likely wasteful (in the case of IPv4 space anyway), if we project for lowest amount of growth then we get DFZ glut.

We would also like to do regional IPv6 address planning since we're too often in the habit of (without much notice for the operational people) selling off part of the business.

Then again, with a /32 we can support ~16 million residential end-users with /56 each, which I guess will be enough for a while.

So my wondering is basically, if we say we have millions of end users right now and we want to give them a /56 each, and this is no problem, then the policy is correct. We might not have them all IPv6 activated in 2 years which is the RIR planning horizon. I do concur with other posters here that the planning horizon for IPv6 should be longer than three years so we get fewer prefixes in the DFZ as a whole. Then again, *RIR people don't care about routing so I am still sceptical about that being taken into account.

So... I need to ask for some clarification here.

What, exactly, do you mean by "RIR people"?

Do you mean the staff at the RIR?

In that case, you're right, sort of. They care about following the policies set by their
respective constituent communities. In the case of ARIN, this would be essentially
anyone who cares to participate. However, if people who care about routing choose
to participate (which they seem to vigorously in ARIN), then, their views will be
reflected in policy as a result (they certainly are, at least to some extent in the
ARIN policies).

Do you mean the RIR Boards, Advisory Councils, or other representative governing
bodies?

In that case, you're also partially right. They care about representing their community
of users and the best fiduciary interests of the RIR. I don't know about the structure of
the other RIRs, but, at least in the case of ARIN, the Advisory Council is definitely
primarily concerned with shaping policy according to the consensus of the constituent
community and the board is concerned with insuring that the AC is following the correct
processes in policy adoption and the fiduciary best interests of ARIN as an organization.

Do you mean the RIR end users and customers who receive address resources from the
RIRs?

In that case, I think, actually that most of them care a great deal about routing.

Note, in these statements, I am speaking only as an individual, and, not as someone who
was recently elected to a future term on the ARIN AC or on behalf of the AC in any way.

you will be having. Unless you will suddenly in a year grow by 60k clients (might happen) or really insanely with other large amounts your initial planning should hold up for quite some while

We grow by much more than 60k a year, it's just hard to plan for it. If we project for the highest amount of growth then we're most likely wasteful (in the case of IPv4 space anyway), if we project for lowest amount of growth then we get DFZ glut.

IPv6 needs a much longer time horizon than IPv4 in my opinion. If nothing else, I would say
that you should be able to project your addressing needs for the next two years at least in the
ball-park of continuing your previous growth trends. If you added 100k customers last year and
80k customers the year before, then, I think it's reasonable, especially in IPv6, to plan for 125k
customer adds next year and 150k customer adds the following year.

If you're figures turn out to be excessive, then, in two years when you'd normally have to apply
for more space (I'd like to see this move to more like 5 for IPv6), you can skip that application
until you catch up. No real problem for anyone in that case.

We would also like to do regional IPv6 address planning since we're too often in the habit of (without much notice for the operational people) selling off part of the business.

Heh... Then you should force the new owners to renumber.

Then again, with a /32 we can support ~16 million residential end-users with /56 each, which I guess will be enough for a while.

So split the difference and ask for a /28. Personally, I think /56s are plenty for most
residential users. I'm a pretty serious residential end-user, and, I can't imagine I'd need
more than a /56 in terms of address planning. However, I have a /48 because that's the
smallest direct assignment available for my multihomed end-site.

Owen