Technically I don’t think an IPv6 should ever need to be set to shared. By nature, they should be dedicated.
But I think I complicated things by bringing IPv6 into this. The reason I want this to be improved is for IPv6, but I think it might be easier to explain with just IPv4.
The only difference between IPv4 dedicated and IPv6 dedicated for interworx and the mass import is when you create a new IPv6 pool on your server, there are not IPv6 dedicated IPs available. I see in your image above you have several IPv6 showing in the list, but when you first start fresh there are none because they are created on the fly as they are needed and pulled from the IPv6 Pool. If you create one on the fly for a siteworx account, then remove it from that siteworx account, it will then show up as an IPv6 available to the system (like your image), but not before that.
Ok, so let’s talk dedicated IPv4 and mass import.
If you have a couple test servers you could try this yourself.
Create three sites with these domain names so they are sorted alphabetically on the mass import screen of the import server.
Give them each a dedicated IP.
Source Server:
bbb.com -> 1.1.1.1 (dedicated)
aaa.com -> 1.1.1.3 (dedicated)
ccc.com -> 1.1.1.2 (dedicated)
Make sure the same exact IPv4s (1.1.1.1, 1.1.1.3, and 1.1.1.2) are created and ready to use on the import server, as dedicated.
Run mass import on the Mass Import Server and it will show something like this:
aaa.com -> 1.1.1.1 (dedicated)
bbb.com -> 1.1.1.2 (dedicated)
ccc.com -> 1.1.1.3 (dedicated)
Basically the issue is that the domains show up in the mass import list domains (siteworx accounts) are sorted alphabetically and are assigned dedicated IPv4s in numerical order.
Because A comes first, it gets the first IPv4 of 1.1.1.1 instead of it’s correct IP of 1.1.1.3.
The only way I’ve come up with to fix this now is to import them wrong and then manage IP on each SiteWorx account to move them around after the import. This does get tricky because in order to give site aaa.com it’s correct IP, you first have to set ccc.com to another IP (like a shared IP on the system) and then remove that dedicated IP from it to get the process started. Then you can switch aaa.com, freeing up the 1.1.1.1 IP which can then be assinged to bbb.com. Then that frees up 1.1.1.2 to be set on ccc.com.
So basically the same idea applies to IPv6, but instead of having to manually fix a handful of SSL sites that need a static IPv4, it will be all your sites. So the workload to fix this, and not mess something up, is amplified 100x when dealing with IPv6. Then throw on top of that the way IPv6 are pulled out of the pool, and it gets even tricker. Because maybe all your sites are given complete different IPv6 from the pool than on the previous server, so you can’t even move them around like my fix for IPv4 above.