but much less hard to burn through a /32.
Sure a large ISP handing out a /48 to each customer can consume a /32 in no time. But in this case we are talking about an ISP with a /20 worth of IPv4 addresses. They can hand out a /48 to each customer and still have plenty of IPv6 addresses left by the time that IPv4 space gets really tight.
Your example use of /57 and /58 prefix lengths got me thinking, though.
I didn't actually suggest using a /57 at any point. What I said was you could be using a /57 on average. Everything delegated to the customer would still be on a nibble boundary.
The RFC draft I mentioned explicitly states that CPE routers by default should round up its prefix request to a nibble boundary. I would expect most such routers to need between 2 and 7 /64s. And anything from 2 to 16 would be rounded up to a /60. Hence I expect that a year or two from now, most new routers will request a /60.
I did suggest the provider could be using a /58 per customer. That was in order to provision for a customer with more than one router requesting a /60. Even though from the customers point of view these are completely independent /60 and /64 prefixes, it makes sense for the ISP to keep them within a /58 to easier keep track of which addresses goes with which customer, and to keep routing tables small.
My main point was that a /58 was the longest prefix you should consider provisioning per customer. After learning the size of this ISP I wouldn't even suggest that they provision that long a prefix per customer, they will have plenty of addresses to provision a shorter prefix to each customer.
Assume an ISP have some equipment where they can terminate 50 customer connections (I don't know if that is a size they would actually use, this is just for the example). How large a prefix should they route to this equipment?
They could route a /52 to the equipment and allocate a /58 out of that for each customer. (You'd be wasting 14 /58 blocks, but that's not a problem). Then that equipment can split each /58 into 3 /60 blocks for delegation and plenty /64 for link to customer and more for delegation. In this case all routing is happening at nibble boundaries namely /52, /60, and /64. But to find out which customer an IP address belongs to, you'd be looking at /58s. The /58s is only relevant for administrative purposes within the ISP. It affects nobody outside of that ISP, and they can use any size they please.
In the same setup, if you prefer to change that /58 to a nibble boundary, then you'd have a /56 per customer. Out of that /56 you'd use one /64 for the link to the customer and you'd have 15 /60s and 15 /64s left, which could be delegated to the customer's routers. Then the equipment would need to have a /48 routed to it in order to have enough /56s for 50 customers. You'd be wasting 206 /56 blocks.
At this level of the hierarchy you'd only have an HD-ratio of 70%. Those 70% would be less than the 80% target which is what is required in order to be able to have a /48 to every end site. But since the example was splitting a single /48 into blocks to route to individual customers, then it isn't actually a problem. A /48 for every such piece of equipment would be perfectly acceptable, even if most of it is wasted. You'd still need to route more /48s to it, if any customer actually has a router requesting a /48.
If you would actually route a /40 to one such piece of equipment in order to provision a /48 for each of the 50 customers. Then your waste would reach a level where it is a slight concern. Again you'd have an HD-ratio of 70% in this byte of the address. If the previous byte of the address had same utilization, you'd only have 50 such pieces of equipment within the entire /32, and you could only allow for 2500 customers. That is not sufficient.
If you want to achieve 80% HD-ratio, you may need to subnet at boundaries that are not nibbles. But it is only for the subnetting within the ISP. They can receive a /32 from RIPE and delegate /48s to customers. But those 16 bits that the ISP has for subnetting may need to be split with finer granularity than nibble boundaries.
If you only ever subnet on nibble boundaries, then the worst case is an HD-ratio of 25% when you have a fanout of 2 and allocate an entire nibble. If you subnet on arbitrary bits, then the worst case is an HD-ratio of 77% when you have a fanout of 5 and allocate three bits. This is assuming subnets of similar sizes.
I was saying that until there's some really rock solid consensus about standard ways to deploy v6 and to make addressing and subnetting less frightening
IPv4 is much worse. With IPv4 you have to aim for a much higher HD-ratio. With IPv4 I think you might need to aim for 95% or higher HD-ratio. An HD-ratio of 90% is certainly not good enough with the shortage of IPv4 addresses. Needing such a high HD-ratio gives you very little flexibility.
With IPv6 you only need an HD-ratio of 80%. And if you don't need to allocate a /48 to each customer, but instead only hand them whatever prefix they request using DHCPv6, you can go with an even lower HD-ratio. That means you can organize your subnetting in a much cleaner way.
Within the ISP network do subnetting at boundaries that work for you. I have given quite a few examples in this thread. But they are nothing but examples. If I knew your network, I could give more appropriate suggestions for your specific network. And don't care what the rest of the world does. Within your own network you only need to care what works for you. And before you start deploying verify that you have allocated enough bits to the fanout you need at each level of the hierarchy, and verify that you have achieved a sufficiently high HD-ratio.
Between the ISP and the customers my advice is to allocate one /64 for the link to each customer and to delegate prefixes to each customer as requested by their routers through DHCPv6.
On the interface between the ISP and the customer I believe consensus is that prefix delegation will be done using DHCPv6. There may not be consensus about how large a prefix you should delegate to each customer. There is probably never going to be consensus, and it doesn't matter anyway. You can just choose a size and go with it or simply give each customer whatever their router asks for (up to some reasonable maximum).