elliot/dotfiles
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity

Debian IPv6 not working correctly (Trixie) #1

New issue
Open
opened 2026-03-30 21:38:15 +00:00 by elliot · 0 comments
elliot commented 2026-03-30 21:38:15 +00:00
Owner
Copy link

Full Diagnostic Report: IPv6 Not Working on Debian

Symptom

IPv6 connections would time out after a long delay before falling back to IPv4, making many applications and websites very slow. Other devices on the same LAN had working IPv6, ruling out the router, ISP, or network infrastructure. The issue had been ongoing for months.

System Details

  • Debian Trixie with GNOME, stock kernel 6.12.74+deb13+1-amd64
  • NetworkManager 1.52.1 (from standard Debian trixie repos)
  • NIC: Realtek r8169 (rtl8168h-2) on enp4s0
  • Tailscale installed (but off during all testing)
  • Podman installed (but no daemon running)
  • Full disk encryption via LUKS

Investigation Summary

Initial finding: net.ipv6.conf.enp4s0.accept_ra was 0, meaning the interface was ignoring Router Advertisements from the gateway entirely. Without RA, the kernel can't perform SLAAC and never establishes a routable IPv6 address.

Things ruled out:

  • Any config file explicitly setting accept_ra=0 — none found anywhere in /etc, /usr/lib, or /run
  • NetworkManager config files — clean
  • ifupdown / networking.service — disabled, made no difference
  • Docker — not installed
  • Podman — installed but not running, no sysctl rules present
  • DAD (Duplicate Address Detection) failures
  • Tailscale interference
  • Kernel boot parameters — no IPv6 disable flags
  • NIC driver (r8169) quirks
  • Motherboard/firmware — IPv6 SLAAC is OS-level
  • net.ipv6.conf.default.accept_ra — correctly set to 1
  • net.ipv6.conf.all.accept_ra — correctly set to 1

Diagnostic tools used:

  • inotifywait watching /proc/sys/net/ipv6/conf/enp4s0/accept_ra — caught nothing, ruling out /proc writes
  • auditd watch on the same file — caught nothing, confirming the value was being set via netlink rather than /proc/sys, which bypasses both tools entirely
  • strace on the NetworkManager process — revealed the kernel was already reporting DEVCONF_ACCEPT_RA=0 and IN6_ADDR_GEN_MODE_NONE in the netlink message NM received on connect
  • watch -n 0.1 on accept_ra during interface creation — confirmed the value starts at 0 the moment the interface is created and never changes
  • Checking addr_gen_mode — found enp4s0/addr_gen_mode=1 (IN6_ADDR_GEN_MODE_NONE) while default/addr_gen_mode=0 (EUI64)

Things tried that didn't fix it:

  • Adding /etc/sysctl.d/99-ipv6-accept-ra.conf — applied too early, before the interface existed
  • NM dispatcher script to set accept_ra=1 on interface up — overridden by NM via netlink
  • Modifying NM connection profile ipv6.addr-gen-mode to eui64, then stable-privacy — NM ignored both and still set addr_gen_mode=1
  • udev rule to apply sysctl at interface creation time — still overridden by NM
  • Disabling networking.service — no effect

Root Cause

Debian Bug#1025073 — a known bug in NetworkManager affecting multiple Debian versions.

When NM takes ownership of a network interface it sets addr_gen_mode=1 via netlink as the first step of its IPv6 setup sequence. This value means "I will manage address generation myself" and as a side effect causes the kernel to set accept_ra=0. NM is then supposed to complete the setup by configuring IPv6 properly and restoring accept_ra=1 — but it never does. The interface is left permanently in this half-configured state.

This is why no config file anywhere was setting accept_ra=0 — NM was doing it silently at runtime via netlink every time the connection came up, completely invisible to auditd, inotifywait, and the NM logs themselves.

Fix Applied

sudo nmcli connection modify "Wired connection 1" ipv6.method ignore
sudo nmcli connection down "Wired connection 1" && sudo nmcli connection up "Wired connection 1"

Setting ipv6.method=ignore tells NetworkManager to leave IPv6 configuration on this interface entirely alone. With NM out of the way, the kernel handles IPv6 natively: it processes Router Advertisements from the gateway, performs SLAAC, assigns a global IPv6 address, and installs the default route — exactly as it does on every other device on the LAN.

Known limitation of this workaround: NM will no longer manage IPv6 DNS on this interface. IPv6 DNS servers advertised via RA or DHCPv6 won't be picked up by NM. IPv4 DNS continues to work normally, so in practice this is unlikely to cause any issues for most use cases.

When a Fix Becomes Available

Monitor https://bugs.debian.org/1025073 for updates. When a fixed version of network-manager is released and installed on your system, do the following:

  1. Check the fix is actually installed: apt-cache policy network-manager
  2. Revert the workaround: sudo nmcli connection modify "Wired connection 1" ipv6.method auto
  3. Bounce the connection: sudo nmcli connection down "Wired connection 1" && sudo nmcli connection up "Wired connection 1"
  4. Verify accept_ra is now 1 without the workaround: cat /proc/sys/net/ipv6/conf/enp4s0/accept_ra
  5. Confirm on test-ipv6.com that IPv6 is fully working
  6. If it works, the workaround is no longer needed and NM will manage IPv6 DNS again

Claude conversation: https://claude.ai/chat/41242f09-7fed-498d-a724-ef0764877525

## Full Diagnostic Report: IPv6 Not Working on Debian ### Symptom IPv6 connections would time out after a long delay before falling back to IPv4, making many applications and websites very slow. Other devices on the same LAN had working IPv6, ruling out the router, ISP, or network infrastructure. The issue had been ongoing for months. --- ### System Details - Debian Trixie with GNOME, stock kernel `6.12.74+deb13+1-amd64` - NetworkManager 1.52.1 (from standard Debian trixie repos) - NIC: Realtek r8169 (`rtl8168h-2`) on `enp4s0` - Tailscale installed (but off during all testing) - Podman installed (but no daemon running) - Full disk encryption via LUKS --- ### Investigation Summary **Initial finding:** `net.ipv6.conf.enp4s0.accept_ra` was `0`, meaning the interface was ignoring Router Advertisements from the gateway entirely. Without RA, the kernel can't perform SLAAC and never establishes a routable IPv6 address. **Things ruled out:** - Any config file explicitly setting `accept_ra=0` — none found anywhere in `/etc`, `/usr/lib`, or `/run` - NetworkManager config files — clean - ifupdown / `networking.service` — disabled, made no difference - Docker — not installed - Podman — installed but not running, no sysctl rules present - DAD (Duplicate Address Detection) failures - Tailscale interference - Kernel boot parameters — no IPv6 disable flags - NIC driver (r8169) quirks - Motherboard/firmware — IPv6 SLAAC is OS-level - `net.ipv6.conf.default.accept_ra` — correctly set to `1` - `net.ipv6.conf.all.accept_ra` — correctly set to `1` **Diagnostic tools used:** - `inotifywait` watching `/proc/sys/net/ipv6/conf/enp4s0/accept_ra` — caught nothing, ruling out `/proc` writes - `auditd` watch on the same file — caught nothing, confirming the value was being set via **netlink** rather than `/proc/sys`, which bypasses both tools entirely - `strace` on the NetworkManager process — revealed the kernel was already reporting `DEVCONF_ACCEPT_RA=0` and `IN6_ADDR_GEN_MODE_NONE` in the netlink message NM received on connect - `watch -n 0.1` on `accept_ra` during interface creation — confirmed the value **starts at `0`** the moment the interface is created and never changes - Checking `addr_gen_mode` — found `enp4s0/addr_gen_mode=1` (`IN6_ADDR_GEN_MODE_NONE`) while `default/addr_gen_mode=0` (EUI64) **Things tried that didn't fix it:** - Adding `/etc/sysctl.d/99-ipv6-accept-ra.conf` — applied too early, before the interface existed - NM dispatcher script to set `accept_ra=1` on interface up — overridden by NM via netlink - Modifying NM connection profile `ipv6.addr-gen-mode` to `eui64`, then `stable-privacy` — NM ignored both and still set `addr_gen_mode=1` - udev rule to apply sysctl at interface creation time — still overridden by NM - Disabling `networking.service` — no effect --- ### Root Cause **Debian Bug#1025073** — a known bug in NetworkManager affecting multiple Debian versions. When NM takes ownership of a network interface it sets `addr_gen_mode=1` via netlink as the first step of its IPv6 setup sequence. This value means "I will manage address generation myself" and as a side effect causes the kernel to set `accept_ra=0`. NM is then supposed to complete the setup by configuring IPv6 properly and restoring `accept_ra=1` — but it never does. The interface is left permanently in this half-configured state. This is why no config file anywhere was setting `accept_ra=0` — NM was doing it silently at runtime via netlink every time the connection came up, completely invisible to `auditd`, `inotifywait`, and the NM logs themselves. --- ### Fix Applied ```bash sudo nmcli connection modify "Wired connection 1" ipv6.method ignore sudo nmcli connection down "Wired connection 1" && sudo nmcli connection up "Wired connection 1" ``` Setting `ipv6.method=ignore` tells NetworkManager to leave IPv6 configuration on this interface entirely alone. With NM out of the way, the kernel handles IPv6 natively: it processes Router Advertisements from the gateway, performs SLAAC, assigns a global IPv6 address, and installs the default route — exactly as it does on every other device on the LAN. **Known limitation of this workaround:** NM will no longer manage IPv6 DNS on this interface. IPv6 DNS servers advertised via RA or DHCPv6 won't be picked up by NM. IPv4 DNS continues to work normally, so in practice this is unlikely to cause any issues for most use cases. --- ### When a Fix Becomes Available Monitor **https://bugs.debian.org/1025073** for updates. When a fixed version of `network-manager` is released and installed on your system, do the following: 1. Check the fix is actually installed: `apt-cache policy network-manager` 2. Revert the workaround: `sudo nmcli connection modify "Wired connection 1" ipv6.method auto` 3. Bounce the connection: `sudo nmcli connection down "Wired connection 1" && sudo nmcli connection up "Wired connection 1"` 4. Verify `accept_ra` is now `1` without the workaround: `cat /proc/sys/net/ipv6/conf/enp4s0/accept_ra` 5. Confirm on test-ipv6.com that IPv6 is fully working 6. If it works, the workaround is no longer needed and NM will manage IPv6 DNS again Claude conversation: https://claude.ai/chat/41242f09-7fed-498d-a724-ef0764877525
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
elliot/dotfiles#1
No description provided.