Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • NetworkManager NetworkManager
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 165
    • Issues 165
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 19
    • Merge requests 19
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • NetworkManagerNetworkManager
  • NetworkManagerNetworkManager
  • Issues
  • #799
Closed
Open
Issue created Sep 12, 2021 by chrysn@chrysn

Prefix delegation: Prefixes stuck exceeding lifetime

In continuous operation of an IPv6 shared interface (possibly in connection with a second interface that only becomes available occasionally that is also shared) with alternating uplinks (switching back and forth between WiFi and wired Ethernet), the interface accumulates prefixes that are not longer active. When the upstream DHCP server then delegates the prefixes to a different device, addresses there are not available until the route on the local interface is manually removed.

In my concrete example setup, my tapbr0 (a bridge of tap intefaces) has accumulated:

tapbr0: connected to tapbr0
        "tapbr0"
        bridge, 86:2E:80:41:74:09, sw, mtu 1500
        inet6 2a02:b18:c13b:801c::1/64
        inet6 2a02:b18:c13b:801c:77f2:4b96:5cc5:f98f/64
        inet6 fd9e:3dfd:6b4c:1c::1/64
        inet6 fd9e:3dfd:6b4c:1c:81:720b:5bba:24a4/64
        inet6 fd9e:3dfd:6b4c:18::1/64
        inet6 fe80::157b:e0b6:d952:d2ca/64
        route6 2a02:b18:c13b:8012::/64
        route6 2a02:b18:c13b:8014::/64
        route6 2a02:b18:c13b:8018::/64
        route6 2a02:b18:c13b:801c::/64
        route6 fd9e:3dfd:6b4c:12::/64
        route6 fd9e:3dfd:6b4c:14::/64
        route6 fd9e:3dfd:6b4c:18::/64
        route6 fd9e:3dfd:6b4c:1c::/64
        route6 fe80::/64

even though only 2a02:b18:c13b:801c::/62 and 2a02:b18:c13b:8018::/62 is assigned to me according to my OpenWRT router (for my WiFi and Ethernet connections, respectively), and 8014 is delegated to a different device.

Reproducibility: I've seen it on 1.30.6 (packaged in Debian as -1) and a few earlier versions; given it's all depending on long term leases I don't have steps to perfectly reproduce this yet.

While I'm collecting more information, are there any more concrete answers (or log pieces) I can start gathering for?

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking