Has anyone done some analysis of what this might look like? Especially with growth etc.
Sure, probably lots of people lots of times. Off the top of my head, using some current/common allocations sizes: Current "Global Unicast" space --> 2000::/3 An "average" RIR --> /12 an "average" ISP --> /32 an average enterprise --> /48 an average home user --> /56 So, "the current IPv6 world" (2000::/3) can support 512 standard RIR sized allocations. Each standard RIR can support 1M standard ISPs. Each standard ISP can support 64K enterprises or 16M standard home-users, or some combination thereof. So - How much do we want held in reserve? How "flexibly" (ref RFC3531) are we allocating our addresses? How many total (enterprise | home) clients do we want to support? Off the cuff, let's say we use left-most (sparse) allocation and only hit 50% efficiency (keeping the right-most bit totally in reserve!) ... If I am an ISP, and I have 300M home users (/56s) I just need a /26, and that actually gives me a lot of room for more clients (like 200M more). So - what was the problem again? Let's make it even more interesting - let's say I am an ISP, I am allocating /48s, and I need to support - say - 6B assignments for every person in the world + 2B for every organization in the world (#s chosen arbitrarily, feel free to add another bit if it makes you feel better). Bearing in mind that this means every single person and organization has 64k subnets, each of which contains "as many hosts as is appropriate", and all of these are globally routable ... I "just" need a /15 to cover this absolute worst case. Heck, let's make it /14 for good measure. So now each standard RIR can "only" support 4 of this size service provider, but we still have 512 RIR sized allocations. If the individuals got /56s instead these numbers getting even bigger ... So - what was the problem again? Oh, and this is just from the 2000::/3 range ... next up, 4000::/3 ... 6000::/3, 8000::/3, a000::/3, c000::/3. And if we feel like we burned through 2000::/3 too fast at some point in the future, maybe we revisit the rules around the time we start thinking about allocating from 4000::/3? (Or "skip one", and star the new rules with 6000::/3 ... I am not picky). Note, I am _NOT_ saying we should be careless or cavalier about address allocation, just saying we don't live in a constrained situation. And if there is a choice to be made between scalability/flexibility/summarization'ability (is that a word?) and strict efficiency ... the efficiency loses. /TJ PS - Yes, 4.3B seemed really big at one point ... but seriously, do the above numbers not _really_ sound big enough?