Happy World IPv6 Day!

After months of development, the beta is finally here for IPv6! InterWorx is thrilled to announce full dual-stack IPv6 support for the InterWorx Control Panel.

To install:
With an install of InterWorx 4.11.4 or higher, go to the Software Updates page (NodeWorx -> Server -> Software Updates) and choose the Beta software channel. After changing channels, the available package list will show the latest beta - select and install.


IP Addresses - Multiple IPv4 and IPv6 support
  - Added support for SiteWorx accounts to have multiple IPv4
  - Added support for IPv6
  - Added IPv6 Pools

  - Added IPv6 support
    - requires kernel 2.6.28 or greater
    - requires ipvsadm 1.25 or greater
  - Improved Load balancer graphs to include more accurate data
  - Fixed Bug: using LVS fwmarks would break the load balancing
    page in InterWorx
    - This is not full support yet, but prevents the system from 
      crashing if rules are added manually.

  - Improved DNS Templates
    - Templates now use variables, such as {ipv4}, instead of 
      reserved special values, such as
  - Added ipv4.{domain} and ipv6.{domain} A and AAAA records
    - Allows explicit access to a domain via IPv4 or IPv6 for testing

Backup / Restore / Import
  - Updated backup and restore to support multiple IPv4 and IPv6.
  - Fixed Bug: long unix names in the DirectAdmin importer would fail
  - Fixed Bug: imports containing a secondary domain with SSL failed 
    destructively when imported to a shared IP

Pointer Domain Redirects
  - Pointer domains can now be created as 301 or 302 redirects, 
    instead of just serveraliases

User Interface Improvements
  - Advisory messages on inputs - suggestions, rather than errors
  - New multi-step popups
  - New scrolling input for larger data sources

Other Improvements
  - Added IP Range validation to the APF Whitelist. IP Ranges can 
    no longer contain system IPs, which would cause security 
  - Changed the calculation of the default threshold for CPU High Load alerts.
  - Fixed a problem where a missing my.cnf file caused crashes in InterWorx

I suggest checking out the IPv6 Pools as a starting point. You can set up a pool of IPs by assigning a CIDR block to the server. Pools are assigned to resellers and SiteWorx accounts, which then handle the activation and assignment of IPv6 address as needed.

With ARIN’s default allocation being a /48 or a /32, InterWorx recommends assigning a /96 to each of your servers. Even with a /48, this will leave you with a potential for 4 billion servers with 4 billion IPv6s each!

Just FYI, reverting to the previous version is non-trivial, so if you need to do it, please log a support ticket.

What we’re looking for:
InterWorx has tested this as thoroughly as we can in “the lab”. We’re looking for help in the real world. We want this in the hands of our users, and that’s you guys! If you’re connected with IPv6 already, give it a shot and let us know how it works for you!

Give us feedback right here, or if you find a problem, log a ticket over at the help desk - https://support.interworx.com/

There are a few known issues:

  • Importing from competitor's backups is pretty much broken right now
  • Mass import transfer system doesn't allow mapping of individual domains yet
  • General polish - a few unfriendly error messages to improve, a few spots where JavaScript helpers are in the works to improve the user experience

With ARIN’s default allocation being a /48 or a /32, InterWorx recommends assigning a /96 to each of your servers.

Any reason you suggest a /96 rather than a /64?

What we’re looking for:
InterWorx has tested this as thoroughly as we can in “the lab”. We’re looking for help in the real world. We want this in the hands of our users, and that’s you guys! If you’re connected with IPv6 already, give it a shot and let us know how it works for you!

Are licenses granted for beta testers of this update, or would we have to purchase a license to test the v6 beta? Obviously for beta I wouldn’t expect to be able to put any customers on it, but at the same time, I really doubt I could sell “but, c’mon, it’s beta v6!” to accounting.

As far as I can tell, APF doesn’t support IPv6 yet. How do you address this?

Centos/RHEL previous to 6 can’t do stateful inspection in any case, w/o compiling or installing a custom kernel.

Again, I’d be happy to test, but I can’t possibly do this on a production system, and I can’t offer to pay for a license simply to beta test v6.

Hey zombie! Lots of questions, lemme see if I can get them all.

The reccomendation of a /96, rather than a /64, is arbitrary, but here’s our thinking. Basically, a /96 is 4.3 billion ips, and if you have a /64, you’ll have 4.3 billion /96s. It just didn’t seem necessary to have more than that on a single server.

As of the currently released beta, we kinda just didn’t address the APF issue. I’m working on that this week. We’ve actually approached the author of APF to see if we can help at all, or even to find out a status. As a temporary solution (until APF does support ipv6, I mean) the intent is to mirror the port configurations of IPv4, and have InterWorx interact with ip6tables directly. It’s not a complete solution, of course, but the best we can do at the moment.

I’ll PM you about the beta license, I’m sure we can work something out. At the least, I can issue a fully-featured, time-limited demo for you.


Cool - thanks for the reply. I was wondering if the /96 was defense against ND exhaustion attacks or something. I’ve setup v6 on a few servers, but I’m not at all hip to all of the server-related v6 BCP.

I’ll try to get a VM running soon.

OK, after a couple of hours testing out the new v6 stuff, here’s what I’ve found.

On my system, I can’t stop or start the firewall from the GUI. It sits there grinding away, but the state change never takes effect, and there is never any confirmation or failure message, and there is nothing obvious (warns or errors) in iworx.log. Changing the start up preference and rebooting does change the firewall state, though.

As expected, ip6tables isn’t changed to reflect IPv4 rules when the firewall is running. This is no issue for me since I generally write iptables rules by hand anyhow, but I can see this being a big issue for some folks.

The link local address is available to add to siteworx accounts - I can’t think of a scenario where this would make any sense. The panel is aware that it’s link local, not GUA, but it still makes it available as a checkbox when adding siteworx accounts. Not a major issue at all, but something I noticed. It’s possible there’s a scenario I’m overlooking as well, so this may not be an issue at all.

Edit: simply deleting the LL addy and rebooting removes it from the “available” pool and resolves this non-issue.

IPs that have been assigned out of IPv6 pools to accounts that are then deleted remain active on the system. This isn’t necessarily an issue, but something I noticed.

IP Pools. I guess I don’t really understand how they’re supposed to work - can someone explain the idea?

Assuming I wanted to simply give each customer a /124 (or whatever block) to use for whatever they wanted to, would I have to create a pool per-siteworx-account? I had initially assumed that this was the purpose of the netmask option in the pool itself, but that’s obviously not the case.

Basically, assuming that I want to allow users to have access to a couple of v6 IPs, I do this with a pool? If I only want them to have access to one static IP, I assign that like I do IPv4 currently? If I don’t want customers assigning IPs out of the same pool, I have to create small pools and assign those pools to only a single site?

A single /64 or /96 or whatever available to everyone seems like it’d be way too open to snowshoe spamming.

Under DNS, the template doesn’t include the AAAA record. Adding it doesn’t appear to cause issues, though. I haven’t played with adding v6 MX, etc yet.

Creating an account with no IPv6 IP initially appears to make it impossible to add IPv6 later, though you can add IPv6 for secondary domains later. Additionally, there’s no “enable ip changes” check box, either, so I can’t change IPv4 IPs to a static IP for certing, etc. This one is a fairly major issue unless I’m missing something.

Edit - ok, I was missing the blindingly obvious “Manage IPs” link on the “Siteworx Account Management” screen - I was expecting to manage things the way I did with previous interworx installs, entirely my fault. While everything on that page appears to work, I’d say it’s sort of non-obvious how to move from a shared IP to a dedicated one, or how to add an IPv6 IP from an IPv6 pool. With some fiddling around I figured things out, but a few help prompts would be very useful.

With a shared IPv4 IP address and a static IPv6 address, I can’t create an SSL cert. I’m not exactly sure what the rules in this scenario are, TBH, but it seems like the v6 IP should be enough. As far as I can tell, v6-only isn’t an option. Mixed “shared” v4 and static v6 is currently an unlikely scenario, I guess.

As usual, lots of great questions!

The firewall issue is (probably) known - there are some problems because of ip6tables, though that’s being resolved (I just need to clean up and commit). If it persists after the next beta release (soon, we hope), please log a support ticket, we’ll look at it more closely.

I happen to agree with you about the Link-local thing…but someone mentioned running an internal-only cluster as a feature request (happens with IPv4, so while…interesting…it’s not impossible). I think, though, that I’ll log a feature request to disable listing LL by default, and have a setting that you could enable if you wish. So, you’re right, it’s not formally an Issue, but it still strikes me as weird.

We changed our minds several times on the idea of automatically purging auto-generated IPv6 when the SiteWorx account is created. I have a feeling that our decision will need to be revisited.

IPv6 Pools: The idea was that with IPv6, the old way of “adding ALL the ips to the box and dealing with them later” just wasn’t going to cut it with 4.3 billion IPs :slight_smile: The idea was to assign a block to the server, and then just pull them into service as needed. To have a /124 per SiteWorx accout, you would need to create individual pools. I see what you mean about the netmask - but it’s actually the real netmask that the resulting IPv6 will use.

You have me thinking, though - the Pools are just arbitrary structures, something I made up. It might be possible to add a “pool chunk size” value, which would do what you’re saying - assign a smaller, restricted sub-pool to the actual account…hmm.

Yes, IPv4 assignments stay about as they are, with the added benefit of allowing multiple IPs per account.

The AAAA behavior is clearly a bug. I know it’s fixed in our development branch, but I don’t know if it was released with the last update. You can fix it manually by adding a AAAA record with rdata {ipv6} to the template - it won’t fix existing accounts, but future accounts will be correct.

With regards to the changes in managing account IPs - good point. I’ll see about getting a pointer added to show that it’s been moved.

InterWorx uses (up to) 2 vhost directives in Apache per domain - one for port 80, one for port 443. When we added IPv6, we simply add the IPv6 as an extra listen. Since this means that the IPv6 and IPv4 therefore have to share an SSL cert, there’s the requirement that both IPs be able to handle SSL. Like you said, it’s unlikely to really want separate SSL certs, or non-SSL on one IP.

However, we’re working on implementing SNI for a future release, which will allow SSL use on shared IPv4s (not sure there’s a point to shared IPv6)

Thanks again! This post alone is leading to 3 new feature requests being logged! Thanks for your feedback, and keep it up - we’ll wind up with a much better product for it :slight_smile:


Thanks for the followup Tim! I figured the SSL thing was the way it was for a reason, and at least until v6-only is really a viable option I can’t see it being much of a concern. I just mentioned it because I noticed it.

Having pools definitely makes IP allocation much easier, so I think they’re a great idea. I do think that adding the ability to have a master pool to draw smaller “chunked” pools from for customers would make things easier in the one scenario where the plan is to hand small subnets to the customer. That said, I’m not exactly sure what most people would do with multiple IPs, and can see obvious ways multiple IPs might be a bad thing. This might be “ipv4 think” though.

I’ve been tied up with non-web-server stuff recently so haven’t had much of a chance to do much more, but I’ll keep an eye out for the update.

Thanks again!

No problem -

Just to let you know - your last input resulted in 5 feature requests/bugs, 3 of which are already fixed. I’m currently working on the sub-pool chunks (which will work, but there’s some “chicken and the egg” problems), and I think the cleanup of pool-generated IPv6 when deleting a SiteWorx account will become a checkbox (you can choose to clean up or not).

As far as multiple IPv6s go - secondary domains. The idea is that with 4 billion billion IPv6, there’s really no reason to have them be shared among multiple domains. We implemented shared as a possibility, because someone somewhere is going to have a valid reason for that, but the default is to have each IPv6 dedicated. IPv6-only will happen eventually, but like you said, it’s not entirely viable yet.


Beta 3 is here! I believe all the feature requests you guys have come up with from Beta 2 have been implemented - Subpools, cleaning up when deleting a SiteWorx account, suppressing link-local addresses, etc. Thanks for the input, and keep it up! Beta 4 is coming soon - with RC1 hopefully on its heels.