NetBird's overlay has been IPv4-only since day one. Every peer got an address from , every ACL was an IPv4 ACL, every network route a v4 CIDR. That covered the vast majority of use cases, but it also meant IPv6-only services on the backend side, modern home networks that prefer v6, and dual-stack clouds had to be reached through v4 plumbing.
v0.71 changes that. The overlay is now dual-stack. Each account gets a unique IPv6 prefix, peers can receive both an IPv4 and an IPv6 overlay address, and the rest of the system, DNS, firewall rules, exit nodes, network routes, domain routes, follows along.
Every account on v0.71 gets its own IPv6 range alongside the existing IPv4 one. The default is a , which is plenty for any realistic peer count, but you can configure anything from down to if you have a reason to.
The prefix is account-scoped, so two different accounts in the same management server have non-overlapping IPv6 space. This matches how IPv4 overlay addressing already worked and means cross-account routing scenarios behave the same regardless of address family.
IPv6 doesn't get force-fed to everyone the moment you upgrade. New accounts have IPv6 enabled for the All group by default, so a fresh install lights it up everywhere. Existing accounts opt in by selecting which groups should receive IPv6 addresses under Settings > Network.
Only peers that belong to at least one selected group get an IPv6 address. Everyone else stays v4-only. This gives you a way to roll IPv6 out to a pilot group, validate things look right, then widen the scope, instead of flipping the whole network at once.
Assignment is also gated on a per-peer capability. The v0.71 client advertises IPv6 support to management on connect; older agents don't, so management skips IPv6 assignment for them even if their group is selected. Upgrade the client and the peer picks up an address on the next reconnect, no manual reassignment required.
Capability is platform-wide: the WireGuard interface picks up the v6 overlay address on Linux (both kernel and userspace WireGuard), macOS, Windows, iOS, Android, FreeBSD, and the netstack/userspace path used for sandboxed environments. There's no platform-specific cutout where v6 is silently disabled.
The point of doing this properly is that IPv6 isn't a feature flag bolted onto one corner of the product. Once a peer has an IPv6 address, the rest of NetBird treats it the same way it treats IPv4:
The headline value here is mostly that nothing about your existing policies needs to change. If you already have a group-based ACL letting reach , that policy now applies to v6 traffic too, automatically.
Some hosts have reasons to stay off IPv6, single-stack environments, compliance constraints, or just buggy upstream IPv6 support that you'd rather sidestep. v0.71 ships a flag on the client:
When set, the client doesn't request an IPv6 address, doesn't advertise IPv6 support to management, and won't accept inbound IPv6 traffic from remote peers. The same toggle is available in the desktop UI under Settings > Disable IPv6 and in the iOS and Android apps under Advanced Settings.
now shows the IPv6 address when one is assigned:
If you only want the v6 address, for instance to feed it into a script, there's a flag for that:
NetBird's IPv6 prefixes are overlay addresses, not publicly routable. They work the same way as the existing IPv4 range: reachable inside the NetBird network, not announced to the public internet. If you want a peer to be reachable on the public IPv6 internet, that's still a job for whatever public addressing your host already has, the overlay isn't a replacement for that.
One thing worth flagging if you run a routing peer inside a container: NetBird tries to set on startup, but in unprivileged containers or locked-down Kubernetes pods that sysctl is read-only, the write fails silently, and IPv6 forwarding stays off.
Set it at the orchestrator layer instead:
If a routing peer has an IPv6 address but traffic isn't reaching the backend, this is the first thing to check.
A few details that came out of building this that are worth knowing about:
Two new fields on the account settings, one new field on peers:
See the API reference for details.
IPv6 is the headline, but a few other things landed in this release worth calling out.
Bring your own proxy (backend ready). Management now supports a full per-account reverse-proxy lifecycle: proxy tokens you can create, list, and revoke, per-account cluster allow-lists, conflict detection, and one-proxy-per-account enforcement. Self-hosted deployments can already wire a proxy in through global tokens; BYOP is the GUI-driven path that works the same way on both Cloud and self-hosted, so accounts can register their own reverse proxy and route their services through it. The backend is in v0.71, but the dashboard UI is still being polished and will land in a near-future release. Background reading: Bring Your Own Proxy documentation .
MFA for local users. If you don't federate auth through an external IdP, local users can now enable multi-factor authentication directly in NetBird. This closes a long-standing gap for self-hosted deployments that don't run an external provider in front of the dashboard.
Client and management improvements. A handful of smaller items worth scanning if you operate NetBird at scale:
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。