GNOME Bugzilla – Bug 761740
IPv6 temporary addresses accumulate over time
Last modified: 2016-02-10 09:58:21 UTC
On my office desktop machine I observe that it accumulates temporary IPv6 addresses over time, even though all except one are marked as deprecated already. E.g. right now my IP list looks like this: 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2620:101:80fc:224:ad8a:b15b:f83e:99e9/64 scope global temporary dynamic valid_lft 594471sec preferred_lft 75471sec inet6 2620:101:80fc:224:7484:af8e:1051:52b9/64 scope global temporary deprecated dynamic valid_lft 508673sec preferred_lft 0sec inet6 2620:101:80fc:224:3855:ba9f:c4ab:5784/64 scope global temporary deprecated dynamic valid_lft 422875sec preferred_lft 0sec inet6 2620:101:80fc:224:ac16:b27:9fa4:4f5d/64 scope global temporary deprecated dynamic valid_lft 337078sec preferred_lft 0sec inet6 2620:101:80fc:224:f0c6:8f9f:74b8:99ca/64 scope global temporary deprecated dynamic valid_lft 251280sec preferred_lft 0sec inet6 2620:101:80fc:224:e070:5f9b:9783:bd0d/64 scope global temporary deprecated dynamic valid_lft 165483sec preferred_lft 0sec inet6 2620:101:80fc:224:f46a:182b:e2c8:d026/64 scope global temporary deprecated dynamic valid_lft 79685sec preferred_lft 0sec inet6 2620:101:80fc:224:baca:3aff:fea3:1b50/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 2591996sec preferred_lft 604796sec inet6 fe80::baca:3aff:fea3:1b50/64 scope link valid_lft forever preferred_lft forever Once I reboot the interface has only the one IP addressed based on MAC address plus one temporary address. I verified manually via 'netstat -anp' that no active network connections or listening sockets remain on the interfaces which are marked as deprecated. I think the deprecated addresses should be removed once no socket is any longer using the address.
Downstream Ubuntu bug: https://bugs.launchpad.net/network-manager/+bug/1542523
NetworkManager leaves managing the temporary addresses to kernel. It does so, by adding the public address with "mngtmpaddr" flag. It's entirely up to kernel to manage those. It's also not clear why it is wrong that these addresses are still around. Does it cause any problem to you? Note that their lifetime is not yet expired. I don't think that the RFC suggest that deprecated addresses should be removed when no socket is using them. They get removed when their lifetime expires, and not earlier. Even if netstat -anp doesn't show active connections, the address still can be used for every practical purpose. Read up here: https://tools.ietf.org/html/rfc2462 Closing this bug, because anyway it's not NetworkManager managing the lifetime of these addresses and IMO the behavior is as expected.
I overlooked that the addresses still had valid lifetime left. Well it causes "problems" with ICE: https://tools.ietf.org/html/rfc5245 Because ICE tries every single IP address on each interface the full mesh table of IP address combination grows very large with this high amount of IPv6 addresses. Interestingly other operating systems like OS X, Windows and even other Linux distributions then Ubuntu don't accumulate that many IP addresses. E.g. on my Mac I see always only a single temporary plus one permanent IPv6 address.
your valid lifetime is significantly larger then your preferred time. I don't see anything wrong there... ??
I guess I was hoping that this quote from RFC 3041 would get implemented: As an optional optimization, an implementation may wish to remove a deprecated temporary address that is not in use by applications or upper-layers. To rephrase the problem: ICE opens a socket for each IP address and tries to connect from each of these sockets to the other side. I hope we can agree that it is highly likely that all these temporary IPv6 addresses have the same probability to connect or not. So iterating through all of them is just a waste of resources. And on the other hand it is unlikely that Firefox will implement a Netlink interface to query the deprecated status or lifetime of IPv6 address.
Yeah, that sounds reasonable. Anyway it's not NM to track the lifetime of those addresses (it's kernel). Also, NM wouldn't know whether an address is still in use either, so it cannot fix this. All NM can do, is to set a knob (sysctl value) that configures how kernel cleans deprecated addresses up.