[GH-ISSUE #5788] Feature request: IPv6 ingress support for Netbird Cloud reverse-proxy clusters (*.netbird.services) #11768

Open
opened 2026-08-05 01:30:54 -04:00 by saavagebueno · 2 comments
Owner

Originally created by @renne on GitHub (Apr 2, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5788

Is your feature request related to a problem? Please describe.
The Netbird Cloud reverse-proxy clusters (*.netbird.services) currently expose only IPv4 (A) records as ingress endpoints. This means that services published via the dashboard HTTP service tunnels are unreachable from IPv6-only clients or networks. In environments where ISPs assign only IPv6 prefixes (e.g. DS-Lite, 464XLAT), or where internal networks prefer IPv6 (e.g. ULA-only segments), there is no path to reach Netbird-published services through the cloud proxy.

Describe the solution you'd like
Since Traefik is already deployed in front of the reverse-proxy clusters, enabling IPv6 ingress should be straightforward:

  1. Add AAAA records to *.netbird.services pointing to the Traefik ingress
  2. Configure Traefik to listen on IPv6 (i.e. bind to :: in addition to 0.0.0.0)
  3. Traefik can handle the IPv6→IPv4 conversion internally before forwarding to the backend

No changes to the Netbird peer or tunnel layer should be required — Traefik already terminates TLS and routes by SNI/Host header.

Self-hosted deployments would benefit as well: documenting the Traefik IPv6 bind configuration so operators can enable it themselves.

Describe alternatives you've considered

  • Deploying an additional external dual-stack reverse proxy in front of the existing stack — unnecessarily complex given Traefik is already present.
  • Relying on NAT64 or 464XLAT on the client side — not always available and adds latency.

Additional context
IPv6 adoption is growing rapidly in Europe and especially in home/ISP contexts. Many modern home networks are DS-Lite or IPv6-primary. Without dual-stack ingress on the proxy clusters, the Netbird HTTP service tunnel feature is effectively unavailable for a significant and growing share of clients.

Originally created by @renne on GitHub (Apr 2, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5788 **Is your feature request related to a problem? Please describe.** The Netbird Cloud reverse-proxy clusters (`*.netbird.services`) currently expose only IPv4 (A) records as ingress endpoints. This means that services published via the dashboard HTTP service tunnels are unreachable from IPv6-only clients or networks. In environments where ISPs assign only IPv6 prefixes (e.g. DS-Lite, 464XLAT), or where internal networks prefer IPv6 (e.g. ULA-only segments), there is no path to reach Netbird-published services through the cloud proxy. **Describe the solution you'd like** Since Traefik is already deployed in front of the reverse-proxy clusters, enabling IPv6 ingress should be straightforward: 1. Add AAAA records to `*.netbird.services` pointing to the Traefik ingress 2. Configure Traefik to listen on IPv6 (i.e. bind to `::` in addition to `0.0.0.0`) 3. Traefik can handle the IPv6→IPv4 conversion internally before forwarding to the backend No changes to the Netbird peer or tunnel layer should be required — Traefik already terminates TLS and routes by SNI/Host header. Self-hosted deployments would benefit as well: documenting the Traefik IPv6 bind configuration so operators can enable it themselves. **Describe alternatives you've considered** - Deploying an additional external dual-stack reverse proxy in front of the existing stack — unnecessarily complex given Traefik is already present. - Relying on NAT64 or 464XLAT on the client side — not always available and adds latency. **Additional context** IPv6 adoption is growing rapidly in Europe and especially in home/ISP contexts. Many modern home networks are DS-Lite or IPv6-primary. Without dual-stack ingress on the proxy clusters, the Netbird HTTP service tunnel feature is effectively unavailable for a significant and growing share of clients.
Author
Owner

@michelkroon commented on GitHub (Apr 4, 2026):

Would love to see this feature implemented! When on 5G on my cellphone, I only have IPv6 as an option from my ISP and this breaks my communication with all my exposed services behind my self-hosted setup.
Hope that the netbird team can add this without to much effort 🙂

<!-- gh-comment-id:4186667740 --> @michelkroon commented on GitHub (Apr 4, 2026): Would love to see this feature implemented! When on 5G on my cellphone, I only have IPv6 as an option from my ISP and this breaks my communication with all my exposed services behind my self-hosted setup. Hope that the netbird team can add this without to much effort 🙂
Author
Owner

@sjansen1 commented on GitHub (Apr 23, 2026):

The whole Netbird stack is not IPv6 capable and a blocker for our second PoC. I see some ongoing work in another issue for overlay support. I have no idea why IPv6 was not implementent from the start.

<!-- gh-comment-id:4302947282 --> @sjansen1 commented on GitHub (Apr 23, 2026): The whole Netbird stack is not IPv6 capable and a blocker for our second PoC. I see some ongoing work in another issue for overlay support. I have no idea why IPv6 was not implementent from the start.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11768