4 ms·

Really really. It's 16 IPs. By comparison, your IPv4 mask is /24 or something, but that doesn't mean the whole subnet is yours.

IgorPartola 10y ago
I don't think you understand how IPv6 works.
- wongarsu 10y ago
  What are the popular use cases where you need more than 16 IPs (use cases applicable to the small-ish cloud servers digitalocean offers)? I'm genuinely curious
  - IgorPartola 10y ago
    You could run a VPN, you could give each service you have its own address, you could expose every docker container to the world as its own address, etc.
  - mnordhoff 10y ago
    However much space you personally need, it's beneficial to be isolated on a separate /64 from other clients. A lot of services block IPv6 abuse on a /64 basis. It sucks when one jerk gets everyone else in the data center blocked by something.
  - zAy0LfpBZLC8mAC 10y ago
    One somewhat popular use case specifically for large address space certainly is simply using it as connectivity for your office/servers located elsewhere via tunneling, given that many on-premises providers also suck at address assignment. However, your mistake probably is more in thinking in terms of "number of addresses", as you would with IPv4. IPv6 is meant to be easy to deploy. Part of the specs are mechanisms for automatic address allocation. And one big reason for why the IPv6 address space is so huge in the first place is to enable those, and to thus avoid all the bureaucratic overhead that address exhaustion causes. As such, it is important that address allocations are standardized, so that software that implements such mechanisms just works. The best-known mechanism probably is SLAAC (stateless address auto-configuration). SLAAC requires a /64 per network segment to work. If you don't have that, you'll have to configure things manually. For no reason at all. Imagine a world where you would not ever have to manually assign addresses at all. That's kindof the goal with IPv6. Any ethernet segment always has a /64, so there is never any situation where you could connect a new machine and there wouldn't be any addresses available for it. You just plug it in, it performs router discovery, assigns itself addresses, and it just works. If it's supposed to have a DNS name, it might fire off a DNS update to the DNS server to make its addresses known to the world. And all of that without any need for some kind of DHCP server keeping track of assignments. This is also applicable to virtual machines and containers. A common setup is to bridge virtual machines and containers to the host machine's ethernet interface. In that case, a container isn't really any different from a physical machine plugged into the ethernet, as far as address configuration is concerned. So, if the VM hoster's (virtual) ethernet interface has a /64 with router advertisements, you can simply start stuff in containers bridged to that interface, and they'll automatically have addresses assigned without you having to do anything. So, even if you only have three containers, some fixed allocation of 16 addresses prevents that automatic configuration from working. But also, it's completely reasonable to have more than 16 containers running in a VM, in which case you'd be out of luck with 16 addresses, and would have to start using workarounds like NAT and non-public addresses and stuff that terribly complicate things--again, for no reason whatsoever. But also, just bridging stuff isn't the only reasonable thing to do. You might want to have a bunch of containers isolated a bit, so you want to have them behind a packet filter. So, you set up a virtual bridge that you add all those containers to, and then you set up routing between that bridge and your upstream ethernet interface. Now, you obviously still want autoconfiguration to work for the containers on that isolated virtual ethernet. But you need a /64 for that. But you also need a /64 for your host, and maybe another bridge with completely unfiltered containers. Now, you already need two /64s. Unless you prefer configuring everything manually, that is. Also, the long-term perspective should be to even automate the assignment of /64 prefixes to any such subnets that you might configure. In principle, such a mechanism already exist, in the form of DHCP-PD (prefix delegation), but it isn't really used much in data center setups (but, well, IPv6 isn't used much either ...). With that in place, you should be able to simply rent some virtual machine in the cloud, install some "private cloud" software stack, and then be able to have a user interface that allows you to create virtual network segments and filters between them and containers for various applications connected to those segments--without ever having to think about addresses at all, without ever entering any address, without even seeing any addresses. Addresses simply are always available, as many as you need, and there are standardized protocols that take care of assigning unique addresses to everything that needs an address. Also, as a result of that, it should be outright trivial to migrate everything to a different hoster. Everything should be able to renumber fully automatically to the prefix allocated by the new hoster. You simply shut down your VM, transfer an image to the new hoster, and boot it back up, and it should just work. Addresses should never be a factor to consider what designing your network/server/hosting setup. If you think something should be in a container, you should be able to launch a container, and it will have an address.

IgorPartola 10y ago

I don't think you understand how IPv6 works.

wongarsu 10y ago
What are the popular use cases where you need more than 16 IPs (use cases applicable to the small-ish cloud servers digitalocean offers)? I'm genuinely curious
- IgorPartola 10y ago
  You could run a VPN, you could give each service you have its own address, you could expose every docker container to the world as its own address, etc.
- mnordhoff 10y ago
  However much space you personally need, it's beneficial to be isolated on a separate /64 from other clients. A lot of services block IPv6 abuse on a /64 basis. It sucks when one jerk gets everyone else in the data center blocked by something.
- zAy0LfpBZLC8mAC 10y ago
  One somewhat popular use case specifically for large address space certainly is simply using it as connectivity for your office/servers located elsewhere via tunneling, given that many on-premises providers also suck at address assignment. However, your mistake probably is more in thinking in terms of "number of addresses", as you would with IPv4. IPv6 is meant to be easy to deploy. Part of the specs are mechanisms for automatic address allocation. And one big reason for why the IPv6 address space is so huge in the first place is to enable those, and to thus avoid all the bureaucratic overhead that address exhaustion causes. As such, it is important that address allocations are standardized, so that software that implements such mechanisms just works. The best-known mechanism probably is SLAAC (stateless address auto-configuration). SLAAC requires a /64 per network segment to work. If you don't have that, you'll have to configure things manually. For no reason at all. Imagine a world where you would not ever have to manually assign addresses at all. That's kindof the goal with IPv6. Any ethernet segment always has a /64, so there is never any situation where you could connect a new machine and there wouldn't be any addresses available for it. You just plug it in, it performs router discovery, assigns itself addresses, and it just works. If it's supposed to have a DNS name, it might fire off a DNS update to the DNS server to make its addresses known to the world. And all of that without any need for some kind of DHCP server keeping track of assignments. This is also applicable to virtual machines and containers. A common setup is to bridge virtual machines and containers to the host machine's ethernet interface. In that case, a container isn't really any different from a physical machine plugged into the ethernet, as far as address configuration is concerned. So, if the VM hoster's (virtual) ethernet interface has a /64 with router advertisements, you can simply start stuff in containers bridged to that interface, and they'll automatically have addresses assigned without you having to do anything. So, even if you only have three containers, some fixed allocation of 16 addresses prevents that automatic configuration from working. But also, it's completely reasonable to have more than 16 containers running in a VM, in which case you'd be out of luck with 16 addresses, and would have to start using workarounds like NAT and non-public addresses and stuff that terribly complicate things--again, for no reason whatsoever. But also, just bridging stuff isn't the only reasonable thing to do. You might want to have a bunch of containers isolated a bit, so you want to have them behind a packet filter. So, you set up a virtual bridge that you add all those containers to, and then you set up routing between that bridge and your upstream ethernet interface. Now, you obviously still want autoconfiguration to work for the containers on that isolated virtual ethernet. But you need a /64 for that. But you also need a /64 for your host, and maybe another bridge with completely unfiltered containers. Now, you already need two /64s. Unless you prefer configuring everything manually, that is. Also, the long-term perspective should be to even automate the assignment of /64 prefixes to any such subnets that you might configure. In principle, such a mechanism already exist, in the form of DHCP-PD (prefix delegation), but it isn't really used much in data center setups (but, well, IPv6 isn't used much either ...). With that in place, you should be able to simply rent some virtual machine in the cloud, install some "private cloud" software stack, and then be able to have a user interface that allows you to create virtual network segments and filters between them and containers for various applications connected to those segments--without ever having to think about addresses at all, without ever entering any address, without even seeing any addresses. Addresses simply are always available, as many as you need, and there are standardized protocols that take care of assigning unique addresses to everything that needs an address. Also, as a result of that, it should be outright trivial to migrate everything to a different hoster. Everything should be able to renumber fully automatically to the prefix allocated by the new hoster. You simply shut down your VM, transfer an image to the new hoster, and boot it back up, and it should just work. Addresses should never be a factor to consider what designing your network/server/hosting setup. If you think something should be in a container, you should be able to launch a container, and it will have an address.