slaacd(8) is generating IPv6 addresses at a very high rate

Post by Matthias Schmidt
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
$ 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?

Post by Matthias Schmidt
$ 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.

Post by Matthias Schmidt
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.

Post by Matthias Schmidt
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 :)

Stuart Henderson

2017-06-27 01:43:38 UTC

Post by Matthias Schmidt
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.

Some routers announce ULA so that you have a stable address range
for LAN connections that doesn't change if/when the provider renumbers
you, though pltime 0 would seem odd for that..

Matthias Schmidt

2017-06-27 17:40:32 UTC

Hi Stefan,

I was on a business trip since Sunday evening and now I can - strangely
enough - no longer reproduce the issue :/ The machine was in suspend
during that time. I rebooted, plugged in a cable,
however, everything works as expected. Nevertheless, I will answer your
questions below since I hit the issue in the first place.

Does this number keep growing over time? Or does it just
collect a bunch of addresses when the interface comes up?

Initially the number was growing over time. After some minutes I had so
many fd00:: addresses that the ifconfig output scrolled for some seconds
long.

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?

Yes.

Post by Stefan Sperling
Were these all from the fc00::/7 prefix?

Yes.

Post by Stefan Sperling
Were there any with pltime > 0?

Yes.

Post by Stefan Sperling
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 :)

As said above, I no longer see any fd00:: addresses assigned.

Whenever the issue comes back, I'll write another email.

Cheers and thanks

Matthias

Matthias Schmidt

2017-06-28 16:44:31 UTC

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

Does this number keep growing over time? Or does it just
collect a bunch of addresses when the interface comes up?

The above one is a standard SLAAC address and is expected.

This one is a valid privacy address.
I would expect IPv6 connections to work and use this address as source.

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 :)

Florian Obser

2017-07-03 13:40:22 UTC

Hi Matthias,

can you please send a pcap to me in private (no need to bother the
mailing list with it). If at all possible with a few solicitations &
advertisements in there.

The output of
slaacctl sh in
could also be interesting...

Thanks,
Florian

Post by Matthias Schmidt
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.
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 ..........}.....
0040: 0000 0000 0000 0000 2001 16b8 224c 7000 ........ ..."Lp.
0060: 0000 0e10 0000 ......
I can provide a longer dump as pcap on request.
Cheers
Matthias

Does this number keep growing over time? Or does it just
collect a bunch of addresses when the interface comes up?

The above one is a standard SLAAC address and is expected.

This one is a valid privacy address.
I would expect IPv6 connections to work and use this address as source.

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 :)

--
I'm not entirely sure you are real.

Florian Obser

2017-07-05 20:24:21 UTC

I just commited this diff:

diff --git engine.c engine.c
index 147ba75d66f..986ee0a250e 100644
--- engine.c
+++ engine.c
@@ -1554,6 +1554,11 @@ void update_iface_ra(struct slaacd_iface *iface, struct radv *ra)
gen_dfr_proposal(iface, ra);

LIST_FOREACH(prefix, &ra->prefixes, entries) {
+ if (!prefix->autonomous || prefix->pltime == 0 ||
+ prefix->vltime == 0 || prefix->pltime >
+ prefix->vltime || prefix->prefix_len != 64 ||
+ IN6_IS_ADDR_LINKLOCAL(&prefix->prefix))
+ continue;
found = 0;
found_privacy = 0;
LIST_FOREACH(addr_proposal, &iface->addr_proposals,

in the pcap I could see router advertisements with a pltime of 0.
slaacd would generate a privacy address that immediately expired and
then generate a new one. and so on and on....

This is not yet the final fix, since we have the same problem
with pltime 1. Need to read a bit more what to do about this.

--
I'm not entirely sure you are real.

Theo de Raadt

2017-06-28 16:48:54 UTC