If these policies cause 2000::/3 to be exhausted then there are 7 more tries left to do it all over again.
This is the essential characteristic of IPv6 that so many of us, weaned on IPv4, seem to forget. We need to keep this fact uppermost in our minds at all times. Even this subset of IPv6 is much bigger than the IPv4 space. So we can afford to be generous and, in fact, we can afford to make mistakes. If we err, we should err on the side of being slightly too generous because if 2000::/3 runs out, we can try again, older but wiser. This means that we should not be excessively concerned with conserving address space or wasting addresses. It is entirely appropriate to give a /32 to anyone who might be some sort of an ISP, either traditional or some new type, like Google or BMW or Cadburys. It is entirely appropriate for these ISPs to give a /48 to every customer except in the very unusual situation where a customer connects with only a single device that has a single network in it. The only such situation that I can think of is a mobile phone. However, we should not stop thinking about conservation. This is the real world and we do have limitations in router hardware and memory chip capacities and speeds. It would be foolish to allow the routing table to grow without bounds. This is where we need to be conservative and make policies which are not wasteful of routing table space. Now, a set of IPv6 policies in which no globally routable prefixes are longer than /32 allows router manufacturers to optimize memory usage and design router tables to only carry those 32 bits of the IPv6 address. This will conserve memory and allow the routers to scale easier. Of course, any such design will impose a computation penalty on prefixes longer than /32, i.e. /8 prefixes, and that would make it inappropriate to announce /48 prefixes globally for things like DNS infrastructure. Note that I am not interested in whether or not current router implementations or BGP implementations support truncated prefixes in order to realize savings of memory, bandwidth, transmission time, or computation time. That is not our job. Our job is to make a sensible policy that allows the use of IPv6 to scale smoothly so that it meets the needs of humankind for the next generation or two. Let's not be so arrogant that we try to solve all addressing problems forever. That is not necessary. There will be people who come after us and if they feel that we botched the job in 2000::/3, then they have the opportunity for a much easier transition than the transition from IPv4 to IPv6. --Michael Dillon