4 ms·

2^128 is an enormous number. 128 is not. If you start assigning semantic meaning to the bits in an address (the trailing 64 are the devices, the leading 0-31 a

2^128 is an enormous number. 128 is not. If you start assigning semantic meaning to the bits in an address (the trailing 64 are the devices, the leading 0-31 are the ISP customer, 32-63 are the subnet) then things really do start to exhaust if you have a use case where the lines blur (a multitenant datacenter for instance, where it's not clear who the "ISP customer" is and different tenants want their own subnet ranges, etc.) There's a lot of IP's, but it's easy to paint yourself into a corner if you make the wrong assumptions about what bits should mean what.

iso1631 4y ago
Certainly giving a /32 to anyone who wants one is a problem Giving a /56 or a /48 isn't. There are 281 trillion /48s If you gave everyone who has ever lived and gave everyone a /48, you'd have 281 trillion left
- ninkendo 4y ago
  > 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 4y ago
    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 4y ago
      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 4y ago
      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.
      - bauruine 4y ago
        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.

iso1631 4y ago

Certainly giving a /32 to anyone who wants one is a problem Giving a /56 or a /48 isn't. There are 281 trillion /48s If you gave everyone who has ever lived and gave everyone a /48, you'd have 281 trillion left

ninkendo 4y ago
> 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 4y ago
  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 4y ago
    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 4y ago
    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.
    - bauruine 4y ago
      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.