starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-13 12:50:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

After adding IPv6 prefix in config, existing machines don't get IPv6 addresses #270

New Issue
Closed
opened 2025-12-29 01:25:35 +01:00 by adam · 5 comments
adam commented 2025-12-29 01:25:35 +01:00
Owner
Copy Link

Originally created by @viq on GitHub (Jun 6, 2022).

Configuration without any prefixes defined, thus using only the default 100.64.0.0/10. A few machines connected. Added IPv6 prefix (shown in examples fd7a:115c:a1e0::/48), restarted headscale. Even after restarting their services, existing machines did not get IPv6 addresses, that required removing them from headscale and adding anew.

  • set up config only with IPv4 prefix
  • add some machines
  • add IPv6 prefix to configuration
  • only newly added machines receive IPv6 address

Context info

  • headscale 0.15.0
  • tailscale 1.24.2
  • OS: headscale on NixOS (unstable); tailscale on NixOS (unstable), OpenBSD (snapshots); FreeBSD 12.3
Originally created by @viq on GitHub (Jun 6, 2022). <!-- Headscale is a multinational community across the globe. Our common language is English. Please consider raising the bug report in this language. --> Configuration without any prefixes defined, thus using only the default `100.64.0.0/10`. A few machines connected. Added IPv6 prefix (shown in examples `fd7a:115c:a1e0::/48`), restarted headscale. Even after restarting their services, existing machines did not get IPv6 addresses, that required removing them from headscale and adding anew. <!-- A clear and concise description of what the bug is. Describe the expected bahavior and how it is currently different. If you are unsure if it is a bug, consider discussing it on our Discord server first. --> - set up config only with IPv4 prefix - add some machines - add IPv6 prefix to configuration - only newly added machines receive IPv6 address <!-- Steps to reproduce the behavior. --> **Context info** <!-- Please add relevant information about your system. For example: - Version of headscale used - Version of tailscale client - OS (e.g. Linux, Mac, Cygwin, WSL, etc.) and version - Kernel version - The relevant config parameters you used - Log output --> - headscale 0.15.0 - tailscale 1.24.2 - OS: headscale on NixOS (unstable); tailscale on NixOS (unstable), OpenBSD (snapshots); FreeBSD 12.3
adam added the bug label 2025-12-29 01:25:35 +01:00
adam closed this issue 2025-12-29 01:25:35 +01:00
adam commented 2025-12-29 01:25:35 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jun 11, 2022):

This highlights a couple of other issues as well, since the IP is only given when a node joins, it will not update if the user:

  • adds more networks (like described here)
  • removes a network
  • changes a network

Not sure yet what would be the best approach.

We could;

  • Check periodically if what we have in the DB aligns with the config
  • Check when a node wakes up/reconnects
@kradalby commented on GitHub (Jun 11, 2022): This highlights a couple of other issues as well, since the IP is only given when a node joins, it will not update if the user: - adds more networks (like described here) - removes a network - changes a network Not sure yet what would be the best approach. We could; - Check periodically if what we have in the DB aligns with the config - Check when a node wakes up/reconnects
adam commented 2025-12-29 01:25:36 +01:00
Author
Owner
Copy Link

@gbraad commented on GitHub (Jul 3, 2023):

So this also means that when IPv6 is removed, it will still show an IPv6 address for nodes that have registered before the change... and probably also when the range changed?

@gbraad commented on GitHub (Jul 3, 2023): So this also means that when IPv6 is removed, it will still show an IPv6 address for nodes that have registered before the change... and probably also when the range changed?
adam commented 2025-12-29 01:25:36 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 10, 2024):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Mar 10, 2024): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 01:25:36 +01:00
Author
Owner
Copy Link

@viq commented on GitHub (Mar 10, 2024):

Ping.

@viq commented on GitHub (Mar 10, 2024): Ping.
adam commented 2025-12-29 01:25:37 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Apr 15, 2024):

I've given this some thought, and it is definitively possible to do this now with the new allocator, what I am unsure about is "when" to do it, I first thought about it as a check every time we load a node, but it has a lot of sharp edges, both resource and what if:

  • you had ipv4 and added ipv6?
  • you had both, removed ipv6?
  • all the other combos.

What I am leaning towards is having a "back fill based on current setting function" that can be called via CLI/API, and nothing automatic.

So if you have ipv4, and add ipv6, this func will iterate over all machines and add ipv6 if its missing. or if you have both and remove ipv6, it will iterate over and remove all ipv6 addrs.

Yes it is a manual step, but this should be something needed on only rare occasions?

@kradalby commented on GitHub (Apr 15, 2024): I've given this some thought, and it is definitively possible to do this now with the new allocator, what I am unsure about is "when" to do it, I first thought about it as a check every time we load a node, but it has a lot of sharp edges, both resource and what if: - you had ipv4 and added ipv6? - you had both, removed ipv6? - all the other combos. What I am leaning towards is having a "back fill based on current setting function" that can be called via CLI/API, and nothing automatic. So if you have ipv4, and add ipv6, this func will iterate over all machines and add ipv6 if its missing. or if you have both and remove ipv6, it will iterate over and remove all ipv6 addrs. Yes it is a manual step, but this should be something needed on only rare occasions?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#270
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?