IPv6 Support (Creation, GUI Display, Input Validation, DB Storage, etc)

[w8fyz]

Hello! I've recently come across this project, and I must say it's really impressive. Thank you for sharing this with the community :)
I was wondering if there are any plans to incorporate IPv6 support into the project? It would be fantastic to have the ability to create VMs and access them using IPv6.

Once again, thanks for this wonderful project.

[lsthompson]

Thanks for the request!

I love the idea. We'll keep this open.

[APIVersa]

Would personally love to use your project but the IPv6 is DEFINITELY a major issue for anyone looking to use this in a hosting environment today. Most things need dual-stack at best, IPv6 at minimum. IPv4 is a dying protocol.

What I mean by this is, anyone building newer networks, newer hosting providers, etc will want IPv6 as IPv6 is easy to get and readily routable almost anywhere. Simply adding a backup DNS64 server incase a website doesn't have IPv6 solves all issues going IPv6 only.

Sorry for the small rant, but IPv6 is the future and you really really should implement it into your solution to make this usable for any hosts.

[lsthompson]

@APIVersa we agree & it's on the next-FY agenda. Don't forget this module is welcome to PRs from anyone!

Looks like we can use a built-in function to verify a valid v4/v6 address:
https://www.php.net/manual/en/function.inet-pton.php

[lsthompson]

Alright, this is bubbling up to the top!

So a few things here as we plan this - questions we hope to have answered by the community:

1. We can either have a 2nd interface added if v6 details are entered, or do you prefer v4/v6 on 1x vNIC
2. We only need to specify either auto (SLAAC) or the ip6 value only, optional gw6, plus dhcp option
3. Presumably we also need to amend nameserver for LXC case, to include a v6 option if one is being passed in
4. In keeping with the best-practice IPv6 approaches, we're leaning toward a simple v6/CIDR based option to issue from?

That way we're following the KISS principle, allowing for own blocks to be added, while keeping management simple.

It also depends on how prevalent SLAAC is, as it may be simpler to deploy with auto to begin with.

Ref: https://pve.proxmox.com/pve-docs/api-viewer/#/nodes/{node}/qemu

Don't have much time to give this, so hope to hear back!

[lsthompson]

IPv6 via SLAAC should now be enabled by default in the repo - as yet unversioned.

a63bfd6

Still considering options for specific IPv6 implementation, in terms of issuing prefix size and so on.

We'd appreciate your feedback to make the rest of the functionality ideal for usage.

[Tftlegal]

Hello! A little off topic, but I would really like to share and thank you for the product.

If it becomes possible to add a second network interface, that will be great.
However, when testing on LXC v1.2.2, I noticed that when a second interface with DHCP appears, resource consumption increases significantly.
So if there is an option to enable/disable it in the client area, that would be absolutely cool!

There are different situations, you can’t foresee everything - the simpler the better.
The need to use both versions of the IPv4/IPv6 protocol on one interface is most likely a special case.
Good luck with your development!

[lsthompson]

Hello! A little off topic, but I would really like to share and thank you for the product.

Thanks a bunch for your feedback!
We're working hard to deliver a quality piece of FOSS for PVE lovers!

There are different situations, you can’t foresee everything - the simpler the better.

Absolutely, we're angling for a robust solution which allows for easy v6 deployment, and after a bit, more complex confs.

If it becomes possible to add a second network interface (for IPv6), that will be great.
The need to use both versions of the IPv4/IPv6 protocol on one interface is most likely a special case.

That makes sense. Especially with regard to addressing/starting failure, best to have one stack fail only, than both.

LXC v1.2.2, I noticed that when a second interface with DHCP appears, resource consumption increases significantly.

Hmm, my understanding of what we've done with v6 thus far, is to enable SLAAC via auto, and not DHCP. Thoughts?

Are you instead explaining that you find any more than 1 instance of DHCP per-guest - and resource usage rises?

So if there is an option to enable/disable it in the client area, that would be absolutely cool!

For sure, I'm thinking we will tackle this at the VM/CT Plan level - hence can be OFF, SLAAC, DHCP or addressed.

[lsthompson]

If you update SQL to have the new columns, you should now (on same/single int. only) be able to specify off/DHCP/auto?

Next step will be to re-factor network config sections to tidily handle the IPv6 / 2nd-interface case instead of both on eth0.

[Tftlegal]

"So if there is an option to enable/disable it in the client area, that would be absolutely cool!
For sure, I'm thinking we will tackle this at the VM/CT Plan level - hence can be OFF, SLAAC, DHCP or addressed." - Thanks for the answer, don't bother with it yet.

"If you update SQL to have the new columns, you should now (on same/single int. only) be able to specify off/DHCP/auto?..." - I didn’t want to update yet, due to the fact that I haven’t figured everything out yet, I wrote about it in the adjacent thread.

[lsthompson]

I didn’t want to update yet, due to the fact that I haven’t figured everything out yet, I wrote about it in the adjacent thread.

No problem. We'll wait for further IPv6-related feedback and get this one through to done!

[lsthompson]

Would appreciate feedback here please!

Have just forked to a new vNIC in 0ab97dc