[ninkendo]

> If you gave everyone who has ever lived and gave everyone a /48, you'd have 281 trillion left

What if I got a /48 and my customer wants a bunch of /48's? Better ask my upstream for a /40 so that I can give it to them. What if my provider already has a bunch of people that want /40's? They'll probably want a /32. What if their provider has a lot of customers that want /32's? (and so on.)

I'm not saying any of the above make any sense (you don't typically have that many layers of "providers"), but I've seen it happen in really huge corporations that have this kind of logic:

"It'd be nice to know where a packet comes from using only its address, let's give a /64 to each server, a /56 to each rack, a /48 to each aisle, a /40 to each server room", etc... but suddenly your needs change and your servers themselves need to have multiple /64's, or you start needing to add regions to the list of stuff packed into an address. Suddenly you're asking for a /32 in order to keep your inventory management simple, even though you're barely using any of the addresses.

I'm not saying the above is a good idea, just that if you do dumb stuff with your address space, you can end up running out of addresses even though you have many many orders of magnitude more addresses than you actually use.

[bauruine]

As a LIR you get a /32 by default, no questions asked. If you need more you need justification and from my experience with RIPE and PI space they can be a pain in the ass regarding that. AFAIK the biggest one they ever give a LIR is a /28 with the note that they never ever want to hear from you again. There are 268'435'456 /28 available. I don't think i will still life when we reach the only 200 Million /28 left mark.

[Arnavion]

Also all the current allocation standards are for 2000::/3. If it turns out we have some unforeseen issue with the current policy of handing out blocks we can come up with something else for the five other /3's that are completely unused.

[ninkendo]

Giving a /32 to anyone who wants one without any questions asked is probably a good example of why "aren't we making the same mistake as ipv4?" isn't an entirely meritless question.

I mean it's probably crazy to imagine a scenario where we have more than 4 billion "local internet registries" in the universe, but it's not so crazy to imagine a scenario where the ability to ask for a /32 maybe needs to get constrained a little more.

In the end, I think the idea of making all subnets /64's may have been a mistake. It's cool that you can put MAC addresses right in the address and thus don't need DHCP any more, but carving out room for 18,446,744,073,709,551,616 devices per broadcast domain is a bit crazy on the face of it. Plus you need all the privacy addresses to hide your MAC address from trackers anyway, which is way more complexity than we really needed. IMO DHCP isn't so bad, it's boring/predictable technology at this point, and I'd be perfectly comfortable with shifting the "provider vs customer" boundary many bits to the right in an address, so that a typical subnet is more like a /104 and ISP's give out /96's, etc. That would give us a lot more headroom than the system we have now where anyone can grab a /32.

[iso1631]

> In the end, I think the idea of making all subnets /64's may have been a mistake.

True, but just imagine the subnets are only 64k hosts, with ipv6's address space as a /80.

My own ipv4 routed network (which is currently routed across 5 continents) is based on a space in the 172.16/12 range comprising 5 /16s. A lot of the subnets I use are chopped down to /27, /28 and /29 (and of course /30 and /31s for links and /32s for loopbacks).

That said it's a bit of a squeeze at the moment.

To implement that in an ipv6 world, I'd make every subnet currently sizing between /29 and /25 into a /64. At most it's 8 subnets per /24 at the moment, so call it 16.

As such every /24 I currently allocate would be a /60.

and I have 1280 of those /24s, so 11 bits, which means I need a /49.

Add some expansion space (which I'm currently looking at) and that seems quite neat as a /48.

That's a fairly big network. At some point in the future I could see justifying a second /48.

My company as a whole certainly has more requirement than that, but we have a /32 allocated (we also have a /16 and /19 in ipv4 land and 2 ASes). That /32 could allocate 65,000 of my continent spanning networks. I think we have about 8, and only a couple are really large. The main one is based on the 10/8 network range, which would probably fit into a single /48, but certainly in a handful of them.

> where anyone can grab a /32.

If the requirement to grab a single /32 is an ability to fill in a form asking for it, we aren't going to be running into any issues any time in the next 100 years.

[icedchai]

You can get more space easily. I got a /44 through a RIPE LIR as an individual, no questions asked.

[iso1631]

A /44 is very small compared with a /32 though.

[icedchai]

True, though I know brand new LIRs (one man operations) that got /32's, so I can't imagine a major enterprise would have trouble getting one with a little bit of documentation.

[bauruine]

Everyone that is willing to pay an initial 2400.- and yearly 1400.- to RIPE.

Yes we may have to constrain this a little more sometimes but we have plenty of IP space and therefore time before we have to consider this.