Add support for IPv6 networks (on Linux clients)

[pulsastrix]

Describe your changes

This PR adds some initial support for assigning IPv6 addresses to hosts inside of the wireguard network.
For now, only Linux using the kernel module and nftables as the firewall implementation is supported.

Note for reviewers:
I have been working on this on and off for a couple of months and had to merge in a lot of upstream changes, it's probably easier to review the final version instead of going through each commit separately. 😅

Notes on address assignment

On network creation (or assignment of the first IPv6 address for existing networks), a random /64 prefix in the ULA range is generated, which will be used for devices on the network.
On enabling IPv6 on supported hosts, a random address will be generated for the host.
Disabling and then re-enabling IPv6 results in a new IPv6 address being generated.

Testing

I have tested this PR on the following clients:

• Linux (both using kernel wireguard, which supports IPv6, and tun, which does not)
• Windows (which does not support IPv6)
• Version 0.25.2 on linux combined with the management server built from this branch

Unfortunately, I don't have the environment set up and/or lack the devices to test other operating systems.

How to test:

1. Spin up an instance of the management server from this branch, as well as an instance of the frontend with the necessary changes (see the corresponding PR in the dashboard repository).
2. Build and run the netbird client from this branch, add it to the management server.
3. Open the frontend, and enable ipv6 in the peer settings.
   
4. Alternatively, leave the peer IPv6 setting at "Inherit from Groups" (the default) and instead enable IPv6 for all hosts in a group in the group settings.
   
5. Look at the Wireguard interface/firewall/route configuration on the clients, test pinging the devices using IPv6, etc.

Known issues and TODOs

• Update dashboard changes to work with new dashboard versions
• Integrate with Groups (allow enabling IPv6 for an entire Group at once)
• During development, i have seen problems when updating a peer from a non-IPv6-supported version to an IPv6-supported version (other peers do not establish connections properly until they are restarted)
  • unsure if this is still the case or if other changes i made fixed that by now haven't seen this problem during my testing anymore
• When the nftables-backend is used but IPv6 is disabled by the management server, we still create an (empty) firewall table
  • maybe problematic if the peer does not support IPv6 at all (disabled kernel support, etc.)
• Improve handling of IPv6 routes
  • Prevent creation of IPv6 routes with routing peers or groups that have IPv6 disabled
    • Disabling for groups might be too inflexible, you might actually want to use an existing group with IPv6 disabled for an IPv6 route, if some of the hosts have IPv6 enabled through other means.
  • Disallow disabling IPv6 for peer if it is acting as a routing peer for an IPv6 route
    • I instead opted for the approach listed in the next bullet point
  • Automatically disable all IPv6 routes if IPv6 is disabled for a peer.
    • The "Inherit from Groups" setting should be renamed to "Auto" and also automatically enable IPv6 if peer is IPv6 routing peer.
  • Disable routing peers/groups if they no longer support IPv6 (e.g. because of a downgrade)
  • Ensure that only IPv6-enabled group members are distributed as routing peers if group is used as routing peer
    • (unsure if this is already the case)
• Improve handling of IPv6 Nameservers
  • Distribute IPv6 Nameserver IPs to IPv6 enabled peers only
• Fix compilation issues on non-linux targets caused by my last changes
• Write some more test cases, make sure the existing ones all pass
  • Fix existing test cases
  • Write test cases for client
    • Note that due to the lack of IPv6 support on GitHub Actions runners, the IPv6 tests will be skipped there. Make sure to run them locally in order to verify that they pass.
  • Write test cases for management server
• Documentation
  • can be found in Add IPv6 related documentation docs#165

Adding support for other operating systems/Linux with iptables/uspfilter is probably something better suited for a separate PR, considering the current size of this one.
I have done some preliminary testing with enabling IPv6 on Windows in one of the older commits - assignment of IPv6 addresses is pretty trivial. However, due to some issue (probably routing), I wasn't able to ping other peers, which is why I did not include it for this PR.

Issue ticket number and link

Resolves (partially) #1167 and #46

Checklist

• Is it a bug fix
• Is a typo/documentation fix
• Is a feature enhancement
• It is a refactor
• Created tests that fail without the change (if possible)
• Extended the README / documentation, if necessary

[CLAassistant]

All committers have signed the CLA.

[mlsmaycon]

Hello @pulsastrix, thanks for the fantastic contribution!

Would it be possible for you to join our Slack workspace to discuss a few points for this feature? Maybe we can schedule a short call as well.

[pulsastrix]

Quick status update:
The current state of this PR now includes all changes from the main branch up until February 25th.

Additionally, the "Assign IPv6 address by default" setting has now been replaced by a groupwide IPv6 toggle, i.e. it is now possible to enable IPv6 for an entire group at once.
By default, peers will now enable IPv6 if they are a member of at least one group that has IPv6 enabled, which allows enabling IPv6 for all hosts at once by simply enabling this toggle for the "All" group.
If IPv6 is explicitly enabled or disabled for a specific peer, the peer settings have precedence.

Finally, the Dashboard-PR has been rewritten based on the new UI.

I plan on resolving the remaining TODOs and getting this PR in a reviewable/testable state sometime during the next week, although i can't make any guarantees.

[mlsmaycon]

Thanks @pulsastrix for the changes. We will start reviewing the PR.

I left couple of notes already.

[pulsastrix]

Aside from the documentation (which I will probably write tomorrow) this pull request should now be ready for review.

Question for the maintainers: As far as I can tell the methods DefaultAccountManager.GroupAddPeer() and DefaultAccountManager.GroupDeletePeer() seem to be dead code. Is that intentional?

[pulsastrix]

Documentation has now been written and can be found in netbirdio/docs#165.

[scriptjs]

@pulsastrix, will these changes support routing traffic to private ipv6 networks?

[pulsastrix]

@pulsastrix, will these changes support routing traffic to private ipv6 networks?

@scriptjs Yes, adding routes to IPv6 networks is supported through these changes, assuming that the netbird client running on the routing peer has IPv6 support (i.e. is a Linux peer running using the kernel Wireguard implementation and nftables firewall backend).

[scriptjs]

@pulsastrix, will these changes support routing traffic to private ipv6 networks?

@scriptjs Yes, adding routes to IPv6 networks is supported through these changes, assuming that the netbird client running on the routing peer has IPv6 support (i.e. is a Linux peer running using the kernel Wireguard implementation and nftables firewall backend).

@pulsastrix Awesome! Hope this gets merged soon.

[dpy013]

hi @pulsastrix
Recommended fixes before merging
This branch has conflicts that must be resolved
This error message

[lixmal]

@pulsastrix If you need help/guidance to merge the new routemanager changes, let me know

[mlsmaycon]

@pulsastrix I am creating a feature branch for this PR as it is planned for this quarter and it will be better for us to continue your development and add support to all OS.

[scriptjs]

@pulsastrix, @mlsmaycon What sort of time line are we looking at to see this merged? With support for Linux to start.

[pulsastrix]

@scriptjs I've been pretty busy with other stuff for the past few weeks, but I will most likely get back to working on this until the end of this week/in the next few days.

However, as I'm just an outside contributor, I unfortunately don't know when this feature will be part of a release version.

[mlsmaycon]

@@scriptjs, we are looking into focusing on this feature starting next month. We will take over the amazing work done by @pulsastrix and add IPv6 to further clients.

@pulsastrix, we know you have many conflicts now; let us know if you need help resolving them.

[pulsastrix]

Sorry for the delay, I was unfortunately quite busy with other stuff.

I have now merged in all of the upstream changes from the main branch.
Hopefully this merge didn't break anything, the tests still seem to pass.

[mlsmaycon]

Sorry for the delay, I was unfortunately quite busy with other stuff.

I have now merged in all of the upstream changes from the main branch. Hopefully this merge didn't break anything, the tests still seem to pass.

No need to worry, thanks for going over the conflicts. We will review it ASAP.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[scriptjs]

@mlsmaycon Any chance you will get to this soon. Has been a long road to this point and would like to a release with the changes.

[mlsmaycon]

Thanks for the contribution @pulsastrix.

Due to the amount of diff between the code and our current changes, we will take a different approach for the IPv6 and release the feature when all clients have support to it later this year.