[Closed] Network: add IPv6 support in apps (and don't force IPv4)

Copied over from Jira

Hi,

I created issue NAS-115004 because apps weren’t accessible via IPv6. Waqar Ahmed nicely mentioned:

There are various issues of different moving parts where we don’t have upstream support for ipv6 completely functional i.e k3s-io issue 284. Once it has stabilized upstream, we definitely look forward to adding that to SCALE.

Recently, this issue got a pull request merged in k3s pull 4450 which adds the IPv6 support needed to add IPv6 functionality to the apps feature of Scale.

With that said, I’d like to kindly request two things.

The first one is to please add support for IPv6 in apps, it’s a basic and very important feature, NAT64 networks can’t properly work without this.

The second one is that now when setting up Kubernetes it is asked for the user to input an IPv4 network for Kubernetes, which is fine (although some users like me would prefer not to have IPv4), and when adding a Kubernetes network it requires the user to add a default gateway in the system, but for people without IPv4, this is impossible leading to the inability to initialize apps. So I ask for you guys to either not force the user to add an IPv4 gateway or allow the user to not have an IPv4 network. This second request assumes that the first one is addressed.

I don’t think I need to emphasise the importance IPv6 is starting to have since you guys are starting to add IPv6 support to the customer-facing interfaces, thank you for that btw.

Thank you very much!

Anything you need, including testing, just say something!

1 Like

Kubernetes is going away in the next major release of SCALE, so it seems pretty unlikely they’ll change anything in that regard.

Kubernetes is going away in the next major release of SCALE

I’m confused by this description.
Could you please provide the relevant link?

I got it.

TrueNAS apps are now fully migrated to Docker (June 1st being the cutoff for auto-migration), and with Docker Desktop today announcing native IPv6 support (see Docker blog post re: version 4.42) this would be a great time to add the same to TrueNAS apps!

Would it be enough just to remove IPv6 from Address Pools without breaking installed apps? As there us no use for it in LAN. And even in WAN most ISPs don’t have IPv6. IPv4 is just far easier to read and operate with.

This is completely wrong. IPv6 is needed everywhere so that we can stop doing NAT. NAT is not scalable or sustainable. IPv6 has been around for like 30 years at this point, there is no excuse besides laziness and intransigence. IPv6 is actually simpler to work with because the subnetting is more straightforward and there is no NAT to deal with. IPv6 addresses aren’t that hard to read either, but beyond that you should be using hostnames.

1 Like

I don’t see any issue with subnets. It’s safer and easier to maintain.

IPv6 has subnets too, they’re just easier to manage because you don’t have to do so much slicing and dicing to conserve address space. It just works. I am not sure what you mean is “safer and easier to maintain” unless you are trying to imply that NAT is a security feature, which it is not.

1 Like

Enclosed subnets with unique address space. It’s better. It’s not slicing and dicing. It’s structurization and ordering.

Let alone the fact that IPv6 is pain to read. So IPv4 is not going anywhere. It’s still used by most of the world. And especially dominantly for very this purposes. You’ll be very lucky to find a corpo network with IPv6.

Only places where IPv6, or what will supersede it, may overcome are mobile networks and similar, where IP isn’t important.

3 Likes

whatever you say, pal.

Whatever market says. Again, you wouldn’t find a single corpo network around the World that using IPv6.

1 Like

IPv6 is here to stay. Welcome to the twentyfirst century.

2 Likes

Yes its something I’ll grapple with and get over eventually, but IMO IPv6 can be a bit annoying to work with in a more home user or home lab environment where certain approaches to device management aren’t already established as second nature. Its whats kept me from bothering with it on my network.

The first is losing the ability to strictly think of each machine as a single IP. Now with the privacy address and link-local, I’m less confident that my firewall rules that used to simply target one IP would work with as much totality as I’m once sure they did. Instead you have to make much more judicious use of aliases and partial prefixes to devices that are common to all of their addresses. It’s been a while since I looked, but I remember being confused how to best handle firewalls with IPv6 when trying to target a specific device, regardless of which address in particular was at play, at least on OPNsense. I was also dismayed by what felt like somewhat poor and opaque documentation for a specification that has been around forever now. Though, this was years ago.

The second is how DHCPv6 seem to be deprioritized, considered somewhat of an enterprise feature, and outright not supported on some devices. Perhaps this is more “old habits die hard” from the above, but assigning IPs via MAC reservations is bread and butter networking for me. Having devices end up anywhere via SLAAC (particularly the privacy address) like it’s the wild west just feels wrong. Of course, it might just be a change in mindset that’s needed, but it certainly goes agaisnt the IPv4 grain. It just adds to that sense of a lack of control and increased complexity. NAT may be a bandaid for a problem truly solved by IPv6 (and yes in principle the concept of individual devices being directly internet routable is something that excites me), but I agree that the limitations of IPv4 inadvertently created a form of simplicity through structure and isolation.

This approach of “a device shouts to the ether that its a router and clients can figure out the rest themselves” also sometimes leads to shenanigans in situations related to how things like Thread can work over IPv6. There was a time where after a brief network outage, a couple of my clients got stuck trying to route their internet traffic through an adhoc network because they hooked onto the Router Advertisements send out by an Amazon Echo! I had to manually kick them off back to the normal network. Obviously that was more of a fluke caused by poor implementation and isn’t directly IPv6s fault itself, but generally devices aren’t doing anything like that with IPv4.

The third is the lack of consistency with the various, often half-baked, IPv6 implementations that ISPs have employed and the jank that comes with them, though this has improved in time.

Acting like IPv6 doesn’t require a different way of thining/introduce complexities, and is straight up easier to conceptualize is grossly misleading IMO. I can see it being more straightforward in some ways once you’re used to it.

2 Likes

:joy: you keep living in your little fantasy world

Due to the changes made to the product since the original request, this issue is now being closed. If there are features in this area that have not yet been addressed, please raise a new feature request specific to these.

1 Like