IPv6 in NetBird angekommen: Was sich mit v0.71 ändert und wer jetzt umstellen sollte

NetBird hat am 14. Mai 2026 die Version v0.71.0 veröffentlicht. Das wichtigste Feature ist nicht nur ein weiterer Schalter im Dashboard, sondern ein größerer Architektur-Schritt: NetBirds Overlay-Netzwerk kann jetzt dual-stack arbeiten. Jeder Account bekommt ein eigenes IPv6-Prefix neben dem bestehenden IPv4-Bereich, und Peers können zusätzlich zur IPv4-Adresse eine IPv6-Overlay-Adresse erhalten.

Für viele DACH-Umgebungen kommt das genau zur richtigen Zeit. Home-Office-Anschlüsse, Mobilfunknetze und Cloud-Backends sind längst nicht mehr sauber IPv4-only. Wer NetBird bisher in modernen Heimnetzen, auf mobilen Clients oder vor IPv6-only Backend-Ressourcen genutzt hat, musste häufig mit zusätzlichem IPv4-Plumbing arbeiten.

Der wichtige Punkt: Wer eine bestehende NetBird-Installation betreibt, muss IPv6 nicht blind für alles aktivieren. v0.71 setzt auf einen gruppenbasierten Roll-out. Das macht die neue Funktion gut pilotierbar.

Inhaltsverzeichnis

• Was ist neu in NetBird v0.71?
• Warum IPv6 für NetBird-Admins 2026 relevant ist
• NetBird vs. Tailscale: Das IPv6-Modell im Vergleich
• Wie der Roll-out funktioniert
• Was ihr konkret testen solltet
  • 1. Client-Versionen prüfen
  • 2. DNS prüfen
  • 3. ACLs stichprobenartig validieren
  • 4. Exit Nodes mit IPv6 testen
  • 5. Container-Routing-Peers prüfen
• Die ehrlichen Caveats
  • Overlay-IPv6 ist nicht Public-IPv6
  • Mixed Fleets bleiben gemischt
  • Einzelne Hosts können v4-only bleiben
• Was sonst noch in v0.71 steckt
• API-Änderungen für Integrationen
• Roll-out-Plan für Admins
  • Innerhalb von 7 Tagen: Bewertung und Pilot
  • Innerhalb von 30 Tagen: Validierung
  • Innerhalb von 60 bis 90 Tagen: Ausrollen
• Was das für birdhost-Kunden bedeutet
• Zusammenfassung
• Quellen

Was ist neu in NetBird v0.71?

Die Release Notes nennen IPv6 Overlay Addressing als Headline-Feature. NetBird beschreibt das neue Modell so: Jeder Account erhält ein eigenes IPv6-Prefix, standardmäßig ein /64, konfigurierbar von /48 bis /120. Peers können damit gleichzeitig eine IPv4- und eine IPv6-Adresse im NetBird-Overlay bekommen.

Die wichtigste Änderung ist nicht die Adresse selbst, sondern dass die angrenzenden Systeme mitziehen:

Das ist sauberer als ein isolierter IPv6-Schalter. NetBird behandelt IPv6 nicht als Sonderfall, sondern zieht DNS, Policies, Routen und Exit-Node-Verhalten mit.

Warum IPv6 für NetBird-Admins 2026 relevant ist

IPv6 ist in DACH kein Zukunftsthema mehr. Viele Privat- und Mobilfunkanschlüsse sind seit Jahren dual-stack oder IPv6-priorisiert. Gerade bei Home-Office- und mobilen Clients ist das relevant: Der Laptop oder das Smartphone sitzt nicht mehr nur hinter einem klassischen IPv4-NAT, sondern oft in einem Netz, in dem IPv6 der natürliche Pfad ist.

Gleichzeitig ziehen Backend-Umgebungen nach. Dual-stack Kubernetes, IPv6-only Subnetze in Cloud-Architekturen und moderne Netzwerksegmente sind kein Spezialfall mehr. Ein Remote-Access-Overlay, das nur IPv4 sprechen kann, funktioniert weiterhin, aber es zwingt Admins zu zusätzlichen Übersetzungsschichten.

NetBird v0.71 schließt deshalb eine reale Lücke:

• Mobile-Clients können in IPv6-lastigen Netzen sauberer arbeiten.
• Backend-Ressourcen mit IPv6-CIDRs lassen sich ohne IPv4-Workaround einbinden.
• Exit Nodes können wirklich "allen Traffic" routen, ohne IPv6 am Tunnel vorbei laufen zu lassen.
• Policies müssen nicht doppelt für zwei Adressfamilien gepflegt werden.

Das bedeutet nicht, dass jedes Unternehmen sofort alles auf IPv6 drehen sollte. Es bedeutet aber: Wer NetBird strategisch als Remote-Access- und ZTNA-Baustein betreibt, sollte v0.71 nicht als kosmetisches Release behandeln.

NetBird vs. Tailscale: Das IPv6-Modell im Vergleich

Tailscale unterstützt IPv6 schon länger. Der Unterschied liegt im Modell.

Tailscale verwendet einen globalen ULA-Bereich fd7a:115c:a1e0::/48, aus dem Geräte in Tailnets private IPv6-Adressen erhalten. Das ist pragmatisch und funktioniert für viele Setups gut. NetBird geht mit v0.71 anders vor: Jeder Account bekommt ein eigenes Prefix.

Für ein einzelnes Unternehmen ohne komplexe Mandantenstruktur ist der praktische Unterschied oft klein. Für MSPs, Multi-Tenant-Setups oder Organisationen, die Adressräume bewusst pro Mandant trennen wollen, ist NetBirds Per-Account-Ansatz die sauberere Architektur.

Das ist kein "Tailscale schlecht, NetBird gut". Tailscale hat IPv6 früh und robust in die Praxis gebracht. NetBird zieht mit v0.71 nach, entscheidet sich aber für ein Modell, das besser zu self-hosted und mandantenfähigen Installationen passt.

Einen breiteren Architekturvergleich findet ihr in unserem NetBird vs. Tailscale Vergleich.

Wie der Roll-out funktioniert

NetBird aktiviert IPv6 nicht einfach für jede bestehende Installation. Das ist wichtig.

Neue Accounts haben IPv6 für die All-Gruppe standardmäßig aktiv. Bestehende Accounts müssen IPv6 unter Settings > Network aktivieren und dort die Gruppen auswählen, die IPv6-Adressen bekommen sollen.

Nur Peers, die in mindestens einer aktivierten Gruppe liegen, bekommen eine IPv6-Adresse. Zusätzlich muss der Client selbst IPv6-Support signalisieren. Alte Agents bleiben v4-only und laufen weiter, bis sie aktualisiert werden.

Der pragmatische Roll-out sieht so aus:

1. Management Server und Clients auf v0.71+ bringen
2. Pilot-Gruppe mit wenigen Peers erstellen
3. IPv6 nur für diese Gruppe aktivieren
4. DNS, ACLs, Exit Nodes und Routes testen
5. Mobile- und Home-Office-Clients nachziehen
6. Gruppen schrittweise erweitern

Damit lässt sich IPv6 wie jede andere Netzwerkänderung behandeln: klein starten, messen, ausrollen.

Was ihr konkret testen solltet

Nach dem Update ist nicht die Frage "Ist IPv6 an?", sondern "Ist IPv6 dort an, wo es betrieblich Sinn ergibt?"

1. Client-Versionen prüfen

Auf Peers sollte v0.71 oder neuer laufen:

netbird status

Wenn IPv6 aktiv ist, zeigt netbird status zusätzlich die IPv6-Adresse. Wer nur die IPv6-Adresse für Scripting oder Inventarisierung braucht, kann laut NetBird-Dokumentation den IPv6-Status gezielt ausgeben:

netbird status --ipv6

2. DNS prüfen

NetBird liefert für dual-stack Peers A- und AAAA-Records. Reverse DNS funktioniert ebenfalls. In der Praxis solltet ihr prüfen, ob eure internen Tools, Logs und Monitoring-Systeme mit beiden Adressfamilien sauber umgehen.

dig A peer-name.netbird.selfhosted
dig AAAA peer-name.netbird.selfhosted

Passt den Zonennamen an eure Self-Hosted-Installation an. Entscheidend ist nicht der konkrete Name, sondern dass A und AAAA erwartbar aufgelöst werden.

3. ACLs stichprobenartig validieren

Bestehende Group-zu-Group-Policies sollen automatisch für IPv4 und IPv6 gelten. Trotzdem lohnt sich eine Stichprobe: SSH, RDP, HTTP oder ein interner API-Port einmal über IPv4 und einmal über IPv6 testen.

Wenn eine Policy für IPv4 funktioniert, für IPv6 aber nicht, liegt die Ursache meistens nicht in einer fehlenden zweiten Policy, sondern in Client-Version, Gruppenzuordnung, Host-Firewall oder Routing.

4. Exit Nodes mit IPv6 testen

Wenn ein Exit Node bisher 0.0.0.0/0 geroutet hat, erzeugt NetBird für IPv6-fähige Peers automatisch eine passende ::/0-Route. Genau hier solltet ihr testen, weil v6-Leaks bei "send all traffic"-Setups sonst schwer auffallen.

curl -4 https://ifconfig.me
curl -6 https://ifconfig.me

Der IPv6-Test muss über den erwarteten Exit-Pfad laufen. Wenn curl -6 außerhalb des Tunnels landet oder fehlschlägt, stimmt der Exit-Node- oder Client-Pfad noch nicht.

5. Container-Routing-Peers prüfen

Routing-Peers in Containern sind der wichtigste Caveat in diesem Release. NetBird versucht net.ipv6.conf.all.forwarding=1 zu setzen. In unprivilegierten Containern oder gehärteten Kubernetes-Pods kann dieser sysctl read-only sein. Der Write schlägt still fehl, IPv6-Forwarding bleibt aus.

Für Docker oder Podman Compose gehört der sysctl an den Container-Start:

sysctls:
  - net.ipv6.conf.all.forwarding=1

In Kubernetes gehört die Einstellung in die Pod- oder Node-Konfiguration:

securityContext:
  sysctls:
    - name: net.ipv6.conf.all.forwarding
      value: "1"

Wenn ein Routing-Peer eine IPv6-Adresse hat, aber Traffic das Backend nicht erreicht, ist das der erste Prüfpunkt.

Die ehrlichen Caveats

Overlay-IPv6 ist nicht Public-IPv6

NetBirds IPv6-Adressen sind Overlay-Adressen. Sie sind innerhalb des NetBird-Netzes erreichbar, aber nicht öffentlich im Internet geroutet. Das entspricht dem bestehenden IPv4-Modell.

Wer einen Peer öffentlich per IPv6 erreichbar machen will, braucht weiterhin eine öffentliche IPv6-Adresse vom Hoster oder Internet-Provider. NetBirds Overlay-Adresse ersetzt das nicht.

Mixed Fleets bleiben gemischt

Ältere Clients bleiben v4-only. Das ist gut für Kompatibilität, bedeutet aber auch: Während des Roll-outs haben unterschiedliche Peers unterschiedliche Connectivity-Profile. Plant das ein, vor allem bei Mobile-Clients, alten Linux-Paketen und selten aktualisierten Außenstandorten.

Einzelne Hosts können v4-only bleiben

Nicht jedes Gerät muss IPv6 bekommen. Wenn Compliance-Vorgaben, fehlerhafte Kernel, Embedded-Systeme oder Legacy-Anwendungen dagegen sprechen, nutzt:

netbird up --disable-ipv6

Das ist sauberer als den gesamten Standort oder die ganze Gruppe auszuschließen.

Was sonst noch in v0.71 steckt

IPv6 ist das Headline-Feature, aber nicht die einzige relevante Änderung.

MFA für lokale User: Lokale Nutzer ohne externen Identity Provider können Multi-Factor Authentication direkt in NetBird aktivieren. Für Self-Hosted-Setups ohne externen IdP schließt das eine wichtige Lücke.

Bring Your Own Proxy Backend: NetBird hat Backend-Support für per-account Reverse-Proxy-Lifecycle ergänzt. Das Dashboard kommt laut Release Notes später. Für Betreiber ist das trotzdem interessant, weil es die Proxy-Architektur weiter in Richtung Mandantenfähigkeit bewegt.

Public IPv4/IPv6 Posture Checks: Posture Checks können öffentliche IPv4- und IPv6-Eigenschaften prüfen. Für Zero-Trust-Setups mit Standort- oder Netzwerkbedingungen ist das ein sinnvoller Baustein.

Debug Bundles: MTU, SSH-Auth-Config und Public Key des Peers landen jetzt umfangreicher im Debug Bundle. Das klingt klein, spart aber Zeit in Support- und Incident-Situationen.

DNS Upstream Failover: NetBird skippt Failover bei definitiven EDE-Responses. Das reduziert falsche Retry-Pfade bei DNS-Fehlern.

API-Änderungen für Integrationen

Wer eigene NetBird-Integrationen, Inventarisierung oder Compliance-Checks betreibt, sollte die neuen IPv6-Felder berücksichtigen.

Wenn ihr eigene Dashboards, CMDB-Syncs oder Audit-Exports betreibt, sollte IPv6 nicht als Freitext im Log landen, sondern als eigenes Feld.

Roll-out-Plan für Admins

Innerhalb von 7 Tagen: Bewertung und Pilot

• Management-Server-Version prüfen
• Client-Versionen inventarisieren
• Pilot-Gruppe mit 3 bis 5 Peers definieren
• IPv6 nur für diese Gruppe aktivieren
• Einzelne Hosts mit netbird up --disable-ipv6 bewusst v4-only halten

Innerhalb von 30 Tagen: Validierung

• A- und AAAA-Auflösung prüfen
• Reverse-PTR in Logs und Monitoring testen
• ACL-Stichproben für IPv4 und IPv6 fahren
• Exit Nodes mit curl -4 und curl -6 testen
• Container-Routing-Peers auf net.ipv6.conf.all.forwarding=1 prüfen

Innerhalb von 60 bis 90 Tagen: Ausrollen

• Weitere Gruppen aktivieren
• Mobile-Clients aktualisieren
• Public IPv4/IPv6 Posture Checks einführen
• Dokumentation und Betriebshandbuch um IPv6 ergänzen
• API-Konsumenten und Monitoring auf IPv6-Felder erweitern

Was das für birdhost-Kunden bedeutet

Für birdhost-Kunden ist v0.71 vor allem ein Update-Thema, kein Infrastrukturprojekt. Wir betreiben NetBird als Managed NetBird Hosting und übernehmen Management-Server-Updates, Validierung und Roll-out-Planung.

Das bedeutet:

• keine manuelle Pflege des Management Servers
• kontrollierte Update-Fenster
• Prüfung von DNS, ACLs, Exit Nodes und Routing-Peers
• Unterstützung bei Pilot-Gruppen und Roll-out-Strategie
• Betrieb in deutschen ISO-27001-zertifizierten Rechenzentren (Zertifizierung des Rechenzentrumsbetreibers)

Wenn ihr NetBird selbst hostet, ist v0.71 trotzdem ein guter Anlass, eure Update-Prozesse zu prüfen und den Eigenbetrieb gegen eine Managed-Instanz zum Festpreis zu rechnen. Wenn ein Remote-Access-Stack geschäftskritisch ist, sollte ein Release wie dieses nicht zwischen Tagesgeschäft und "machen wir irgendwann" verschwinden.

Zusammenfassung

NetBird v0.71 ist eines der wichtigeren NetBird-Releases des Jahres 2026. IPv6 Overlay Addressing bringt NetBird näher an die Netzwerkrealität vieler Unternehmen: dual-stack Clients, mobile Nutzer, moderne Home-Offices und IPv6-fähige Backend-Umgebungen.

Die drei wichtigsten Punkte:

1. IPv6 ist account-scoped und gruppenbasiert ausrollbar. Bestehende Installationen werden nicht blind umgestellt.
2. DNS, ACLs, Network Routes und Exit Nodes ziehen automatisch mit. Admins müssen Policies nicht doppelt pflegen.
3. Container-Routing und alte Clients bleiben die wichtigsten Caveats. Genau dort sollte der Roll-out zuerst getestet werden.

Mit birdhost bekommt ihr NetBird als vollständig gemanagten Service: eigene Instanz, Updates durch unser Team, Hosting in Deutschland und persönlicher Support.

Jetzt starten: birdhost.de

Quellen

• NetBird v0.71.0 GitHub Release: https://github.com/netbirdio/netbird/releases/tag/v0.71.0
• NetBird Knowledge Hub: IPv6 Overlay Addressing: https://netbird.io/knowledge-hub/ipv6-overlay-addressing
• NetBird Docs: IPv6 Overlay Addressing: https://docs.netbird.io/manage/settings/ipv6
• Tailscale Docs: IPv6 Support: https://tailscale.com/docs/concepts/ipv6