IPv6 Address Pooling (non-contiguous IP ranges)
Currently, cPanel supports the concept of configuring IPv6 addresses as contiguous blocks/ranges.
The issue with that for some people is that their Colocation or VPS providers instead provide a number of random addresses from within a much larger range of IP's from their allocation. This means you have to add single IP as a /128 range. For users being allocated 16, 32 or even 64 addresses this way, running each as a separate single-IP range is time consuming and also difficult to manage. The listings for just 16 addresses are quite long.
It would be useful for many people to be able to add a list of single IP's into a pool, from which accounts can have an IP allocated. It could work exactly as the Ranges now, except allowing multiple single addresses into a named 'pool'.
Could you elaborate on what constraint you're attempting to work around?
The entirety of IPv4 and IPv6 work around the concept of everything being a "range". Even if that range is a single IP address. To attempt to represent the mapping and binding of IP addresses to a server in a different way would be to cloud and misrepresent a core networking design and implementation for the internet. I see attempting to represent IP addresses in any other way a severe risk of adding significant confusion.
Perhaps if you can elaborate, with an example, of the current stress point(s) you're experiencing while using cPanel & WHM we can better understand what issue you're attempting to work around. Whether you're speaking of routers themselves or end-user interfaces (even down to your operating system itself), everything represents IPs in the context of a member of a "range". This is consistent behavior because of how IPs functionally work.
Could you elaborate on what constraint you're attempting to work around?
The entirety of IPv4 and IPv6 work around the concept of everything being a "range". Even if that range is a single IP address. To attempt to represent the mapping and binding of IP addresses to a server in a different way would be to cloud and misrepresent a core networking design and implementation for the internet. I see attempting to represent IP addresses in any other way a severe risk of adding significant confusion.
Perhaps if you can elaborate, with an example, of the current stress point(s) you're experiencing while using cPanel & WHM we can better understand what issue you're attempting to work around. Whether you're speaking of routers themselves or end-user interfaces (even down to your operating system itself), everything represents IPs in the context of a member of a "range". This is consistent behavior because of how IPs functionally work.
Could you elaborate on what constraint you're attempting to work around?
The entirety of IPv4 and IPv6 work around the concept of everything being a "range". Even if that range is a single IP address. To attempt to represent the mapping and binding of IP addresses to a server in a different way would be to cloud and misrepresent a core networking design and implementation for the internet. I see attempting to represent IP addresses in any other way a severe risk of adding significant confusion.
Perhaps if you can elaborate, with an example, of the current stress point(s) you're experiencing while using cPanel & WHM we can better understand what issue you're attempting to work around. Whether you're speaking of routers themselves or end-user interfaces (even down to your operating system itself), everything represents IPs in the context of a member of a "range". This is consistent behavior because of how IPs functionally work.
Could you elaborate on what constraint you're attempting to work around?
The entirety of IPv4 and IPv6 work around the concept of everything being a "range". Even if that range is a single IP address. To attempt to represent the mapping and binding of IP addresses to a server in a different way would be to cloud and misrepresent a core networking design and implementation for the internet. I see attempting to represent IP addresses in any other way a severe risk of adding significant confusion.
Perhaps if you can elaborate, with an example, of the current stress point(s) you're experiencing while using cPanel & WHM we can better understand what issue you're attempting to work around. Whether you're speaking of routers themselves or end-user interfaces (even down to your operating system itself), everything represents IPs in the context of a member of a "range". This is consistent behavior because of how IPs functionally work.
VPS providers using SolusVM as their management tool on OpenVZ currently assign IP's as the software does not support assigning (for example) a single /124 of 16 addresses. It instead allocates 16x /128's in a non-contiguous range for use in the VPS.
It must be said that this is a SolusVM issue, although I believe there are a couple of other OpenVZ management tools which do the same thing.
What I would like is to be able to simply copy/paste in the IP addresses, and have WHM know that this is a group of single IPv6 addresses, and have them grouped as one rather than 16 separate ranges. It also cuts down on the manual addition of each single IP address as a separate range. Obviously adding 64 separate IPv6 addresses is not going to be a fun experience.
VPS providers using SolusVM as their management tool on OpenVZ currently assign IP's as the software does not support assigning (for example) a single /124 of 16 addresses. It instead allocates 16x /128's in a non-contiguous range for use in the VPS.
It must be said that this is a SolusVM issue, although I believe there are a couple of other OpenVZ management tools which do the same thing.
What I would like is to be able to simply copy/paste in the IP addresses, and have WHM know that this is a group of single IPv6 addresses, and have them grouped as one rather than 16 separate ranges. It also cuts down on the manual addition of each single IP address as a separate range. Obviously adding 64 separate IPv6 addresses is not going to be a fun experience.
Even in the situation you describe, those IPs are still part of a range and must be expressed as part of a range, not as an individual IP. Without the "range" information, there's no way to know how to route it properly on the system.
Simply stating the IP:
805B:2D9D:DC28::FC57:D4C8:1FFF
Provides no way to know how to route it.
Providing the prefix length (the "range" it's part of) allows us the knowledge to route it properly:
805B:2D9D:DC28::FC57:D4C8:1FFF/48
So if you're asking for a way to bulk add in a bunch of IPv6 ranges with proper prefix lengths ("range" information), then that is reasonable and possible. If you're asking for a way to add just a bunch of individual IPv6 addresses without prefix lengths (which is the way I've interpreted your original request and why I asked for further clarification), then that would not be something possible.
Of course there could be a compromise of the two where you provide a list of individual IPs and then the prefix length once as intended to be attributed to all of them. I could see that being a confusing interface, though, prone to errors when individuals didn't fully understand IPv6 routing and how it works (providing IPs that are *not* within the same prefix).
The equivalent here for IPv4 would be how every IPv4 address routed requires an appropriate netmask. You couldn't just dump a bunch of IPv4 addresses individually without also providing the proper netmask for their routing. Same deal here with IPv6 and prefix lengths.
Even in the situation you describe, those IPs are still part of a range and must be expressed as part of a range, not as an individual IP. Without the "range" information, there's no way to know how to route it properly on the system.
Simply stating the IP:
805B:2D9D:DC28::FC57:D4C8:1FFF
Provides no way to know how to route it.
Providing the prefix length (the "range" it's part of) allows us the knowledge to route it properly:
805B:2D9D:DC28::FC57:D4C8:1FFF/48
So if you're asking for a way to bulk add in a bunch of IPv6 ranges with proper prefix lengths ("range" information), then that is reasonable and possible. If you're asking for a way to add just a bunch of individual IPv6 addresses without prefix lengths (which is the way I've interpreted your original request and why I asked for further clarification), then that would not be something possible.
Of course there could be a compromise of the two where you provide a list of individual IPs and then the prefix length once as intended to be attributed to all of them. I could see that being a confusing interface, though, prone to errors when individuals didn't fully understand IPv6 routing and how it works (providing IPs that are *not* within the same prefix).
The equivalent here for IPv4 would be how every IPv4 address routed requires an appropriate netmask. You couldn't just dump a bunch of IPv4 addresses individually without also providing the proper netmask for their routing. Same deal here with IPv6 and prefix lengths.
The big issue here is that SolusVM has a very broken implementation of IPv6 - I agree that any allocations or delegations should indeed be a contiguous block. However the big issue for your clients - of which many do have small OpenVZ VPS for a few dollars per month and of which cPanel is by far the most expensive part of their monthly invoice - are going to find it hard to maintain and manage their allocations, especially if they change. This has already occurred to me once.
You can read more about the very bad IPv6 implementation in SolusVM at https://www.mpkossen.com/?p=9 which explains it really nicely. It should bring understanding to the discussion.
So, if we can import a list of IP's into a 'pool' or 'group', of course you would need a CIDR/netmask for each address. While I am suggesting that the import script accept just a standard IP address with no CIDR/netmask, since 99% of the time they are all single IP's then the input script should merely append /128 to each in the event of no CIDR/netmask being provided.
I agree that there needs to be a 'sure-fire' way to make sure everything works, I submit that appending /128 to all addresses will work for your SolusVM customers.
The big issue here is that SolusVM has a very broken implementation of IPv6 - I agree that any allocations or delegations should indeed be a contiguous block. However the big issue for your clients - of which many do have small OpenVZ VPS for a few dollars per month and of which cPanel is by far the most expensive part of their monthly invoice - are going to find it hard to maintain and manage their allocations, especially if they change. This has already occurred to me once.
You can read more about the very bad IPv6 implementation in SolusVM at https://www.mpkossen.com/?p=9 which explains it really nicely. It should bring understanding to the discussion.
So, if we can import a list of IP's into a 'pool' or 'group', of course you would need a CIDR/netmask for each address. While I am suggesting that the import script accept just a standard IP address with no CIDR/netmask, since 99% of the time they are all single IP's then the input script should merely append /128 to each in the event of no CIDR/netmask being provided.
I agree that there needs to be a 'sure-fire' way to make sure everything works, I submit that appending /128 to all addresses will work for your SolusVM customers.
Replies have been locked on this page!