Hi, now it happened again, Just after I resumed my machine from suspend.
After 10 minutes I discovered the issue and up to now I have 649 random fd00:: IPv6 addresses. All have pltime == 0. Excerpt online at https://pastebin.com/yRYDmnPs. The error message is the same as last time. As soon as I stop slaacd the issue disappears. Here is a tcpdump record: 18:41:32.133759 fe80::527b:9dff:fe73:aa8a > ff02::2: icmp6: router solicitation 0000: 6000 0000 0010 3aff fe80 0000 0000 0000 `.....:......... 0010: 527b 9dff fe73 aa8a ff02 0000 0000 0000 R{...s.......... 0020: 0000 0000 0000 0002 8500 4a3b 0000 0000 ..........J;.... 0030: 0101 507b 9d73 aa8a ..P{.s.. 18:41:32.201292 fe80::9ec7:a6ff:fe56:3e67 > ff02::1: icmp6: router advertisement 0000: 6000 0000 00b0 3aff fe80 0000 0000 0000 `.....:......... 0010: 9ec7 a6ff fe56 3e67 ff02 0000 0000 0000 .....V>g........ 0020: 0000 0000 0000 0001 8600 7d97 ffc8 0708 ..........}..... 0030: 0000 0000 0000 0000 0304 40c0 0000 0000 ..........@..... 0040: 0000 0000 0000 0000 2001 16b8 224c 7000 ........ ..."Lp. 0050: 0000 0000 0000 0000 0304 40c0 0000 1c20 ..........@.... 0060: 0000 0e10 0000 ...... I can provide a longer dump as pcap on request. Cheers Matthias * Stefan Sperling wrote: > On Sun, Jun 25, 2017 at 08:34:46PM +0200, Matthias Schmidt wrote: > > Hi, > > > > I installed a recent snapshot from June 23 and noticed that slaacd is > > generating IPv6 addresses with privacy extensions enabled in a high > > rate. I can easily reproduce the bug by just starting slaacd. After > > one second I already see 29 IPv6 addresses: > > > > $ ifconfig trunk0 | grep inet6 | wc -l > > 29 > > Does this number keep growing over time? Or does it just > collect a bunch of addresses when the interface comes up? > > > $ ifconfig trunk0 | grep inet6 > > inet6 fe80::527b:9dff:fe73:aa8a%trunk0 prefixlen 64 scopeid 0x5 > > inet6 fd00::c00d:a431:9cfc:899a prefixlen 64 deprecated autoconf > > autoconfprivacy pltime 0 vltime 7043 > > > inet6 2001:16b8:2234:3200:527b:9dff:fe73:aa8a prefixlen 64 autoconf > > pltime 3461 vltime 7061 > > The above one is a standard SLAAC address and is expected. > > > inet6 fd00::527b:9dff:fe73:aa8a prefixlen 64 deprecated autoconf > > pltime 0 vltime 7061 > > > inet6 2001:16b8:2234:3200:50e2:4a65:a0af:3926 prefixlen 64 autoconf > > autoconfprivacy pltime 3443 vltime 7043 > > This one is a valid privacy address. > I would expect IPv6 connections to work and use this address as source. > > > inet6 fd00::c8c1:eda0:2f1b:7e99 prefixlen 64 deprecated autoconf > > autoconfprivacy pltime 0 vltime 7044 > > inet6 fd00::b081:7ff1:9740:fb6 prefixlen 64 deprecated autoconf > > autoconfprivacy pltime 0 vltime 7044 > > inet6 fd00::3ceb:3269:d174:c8cd prefixlen 64 deprecated autoconf > > autoconfprivacy pltime 0 vltime 7046 > > inet6 fd00::e875:55ac:6557:2d74 prefixlen 64 deprecated autoconf > > autoconfprivacy pltime 0 vltime 7046 > > All the fd00 addresses are from the fc00::/7 prefix. > See https://en.wikipedia.org/wiki/Unique_local_address > > Not sure what the fritzbox is announcing this prefix for. > The fritzbox might be doing this if it does not have a routable IPv6 > prefix yet, perhaps? A prefix lifetime of zero implies that these addresses > are not used for new connections. They should disappear once vltime hits zero. > > > [...] > > What did you omit here? More addresses? > Were these all from the fc00::/7 prefix? > Were there any with pltime > 0? > > Could you record router solicitations and router advertisements with tcpdump > and show us what they contain? Does the fritzbox keep announcing the fd00::/64 > prefix with a non-zero prefix lifetime? > > The kernel SLAAC code probably filtered these addresses out somehow. > My guess (from code inspection) is that, in 6.1-release, the fd00 > addresses were replaced once a "real" global prefix was configured. > But the details are not immediately obvious. It's IPv6, after all :)
