* Linux kernel handling of IPv6 temporary addresses
@ 2012-11-14 21:14 George Kargiotakis
2012-11-14 21:29 ` David Miller
0 siblings, 1 reply; 8+ messages in thread
From: George Kargiotakis @ 2012-11-14 21:14 UTC (permalink / raw)
To: netdev
Hello all,
Due to the way the Linux kernel handles the creation of IPv6 temporary
addresses a malicious LAN user can remotely disable them altogether
which may lead to privacy violations and information disclosure.
By default the Linux kernel uses the 'ipv6.max_addresses' option to
specify how many IPv6 addresses an interface may have. The
'ipv6.regen_max_retry' option specifies how many times the kernel will
try to create a new address.
Currently, in net/ipv6/addrconf.c,lines 898-910, there is no
distinction between the events of reaching max_addresses for an
interface and failing to generate a new address. Upon
reaching any of the above conditions the following error is emitted by
the kernel times 'regen_max_retry' (default value 3):
[183.793393] ipv6_create_tempaddr(): retry temporary address
regeneration [183.793405] ipv6_create_tempaddr(): retry temporary
address regeneration [183.793411] ipv6_create_tempaddr(): retry
temporary address regeneration
After 'regen_max_retry' is reached the kernel completely disables
temporary address generation for that interface.
[183.793413] ipv6_create_tempaddr(): regeneration time exceeded -
disabled temporary address support
RFC4941 3.3.7 specifies that disabling temp_addresses MUST happen upon
failure to create non-unique addresses which is not the above case.
Addresses would have been created if the kernel had a higher
'ipv6.max_addresses' limit.
A malicious LAN user can send a limited amount of RA prefixes and thus
disable IPv6 temporary address creation for any Linux host. Recent
distributions which enable the IPv6 Privacy extensions by default, like
Ubuntu 12.04 and 12.10, are vulnerable to such attacks.
Due to the kernel's default values for valid (604800) and preferred
(86400) lifetimes, this scenario may even occur under normal usage when
a Router sends both a public and a ULA prefix, which is not an uncommon
scenario for IPv6. 16 addresses are not enough with the current default
timers when more than 1 prefix is advertised.
The kernel should at least differentiate between the two cases of
reaching max_addresses and being unable to create new addresses, due to
DAD conflicts for example.
Best regards,
--
George Kargiotakis
https://void.gr
GPG KeyID: 0xE4F4FFE6
GPG Fingerprint: 9EB8 31BE C618 07CE 1B51 818D 4A0A 1BC8 E4F4 FFE6
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses
2012-11-14 21:14 Linux kernel handling of IPv6 temporary addresses George Kargiotakis
@ 2012-11-14 21:29 ` David Miller
2012-11-14 23:03 ` George Kargiotakis
0 siblings, 1 reply; 8+ messages in thread
From: David Miller @ 2012-11-14 21:29 UTC (permalink / raw)
To: kargig; +Cc: netdev
From: George Kargiotakis <kargig@void.gr>
Date: Wed, 14 Nov 2012 23:14:11 +0200
> Due to the way the Linux kernel handles the creation of IPv6 temporary
> addresses a malicious LAN user can remotely disable them altogether
> which may lead to privacy violations and information disclosure.
A malicious user who can emit random packets as root on your LAN can
also corrupt your ARP cache with entries that point to the wrong MAC
address.
What's your point?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses
2012-11-14 21:29 ` David Miller
@ 2012-11-14 23:03 ` George Kargiotakis
2012-11-14 23:08 ` David Miller
0 siblings, 1 reply; 8+ messages in thread
From: George Kargiotakis @ 2012-11-14 23:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev
On Wed, 14 Nov 2012 16:29:56 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> From: George Kargiotakis <kargig@void.gr>
> Date: Wed, 14 Nov 2012 23:14:11 +0200
>
> > Due to the way the Linux kernel handles the creation of IPv6
> > temporary addresses a malicious LAN user can remotely disable them
> > altogether which may lead to privacy violations and information
> > disclosure.
>
> A malicious user who can emit random packets as root on your LAN can
> also corrupt your ARP cache with entries that point to the wrong MAC
> address.
>
> What's your point?
Hello,
I think it's an issue that a LAN root user can disable a
locally enabled kernel "feature" for good. The kernel could provide a
somewhat more informative message on such an occasion taking place,
since it knows that max_addresses limit has been reached and it's not a
DAD failure.
My point is that I'd like the kernel to handle this situation a bit
differently than it currently does.
Best regards,
--
George Kargiotakis
https://void.gr
GPG KeyID: 0xE4F4FFE6
GPG Fingerprint: 9EB8 31BE C618 07CE 1B51 818D 4A0A 1BC8 E4F4 FFE6
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses
2012-11-14 23:03 ` George Kargiotakis
@ 2012-11-14 23:08 ` David Miller
2012-11-16 21:27 ` Ben Hutchings
2012-12-27 15:57 ` George Kargiotakis
0 siblings, 2 replies; 8+ messages in thread
From: David Miller @ 2012-11-14 23:08 UTC (permalink / raw)
To: kargig; +Cc: netdev
From: George Kargiotakis <kargig@void.gr>
Date: Thu, 15 Nov 2012 01:03:24 +0200
> I think it's an issue that a LAN root user can disable a
> locally enabled kernel "feature" for good. The kernel could provide a
> somewhat more informative message on such an occasion taking place,
> since it knows that max_addresses limit has been reached and it's not a
> DAD failure.
>
> My point is that I'd like the kernel to handle this situation a bit
> differently than it currently does.
Read my example again, it's the same thing for ipv4.
The root LAN user can disable all IPV4 communications to arbitrary IP
addresses on the local LAN by emitting bogus ARP requests and
poisoning everyone's caches. What's the difference between that
and this arbitrary ipv6 issue?
There is none at all.
If you have a root person on your local LAN you're subject to injection
of bogus addressing and routing information. This issue is not specific
to ipv4 or ipv6 and is fundamental in nature.
So it is misleading to bring this up as an ipv6 specific problem, it's
not.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses
2012-11-14 23:08 ` David Miller
@ 2012-11-16 21:27 ` Ben Hutchings
2012-12-27 15:57 ` George Kargiotakis
1 sibling, 0 replies; 8+ messages in thread
From: Ben Hutchings @ 2012-11-16 21:27 UTC (permalink / raw)
To: David Miller; +Cc: kargig, netdev
On Wed, 2012-11-14 at 18:08 -0500, David Miller wrote:
> From: George Kargiotakis <kargig@void.gr>
> Date: Thu, 15 Nov 2012 01:03:24 +0200
>
> > I think it's an issue that a LAN root user can disable a
> > locally enabled kernel "feature" for good. The kernel could provide a
> > somewhat more informative message on such an occasion taking place,
> > since it knows that max_addresses limit has been reached and it's not a
> > DAD failure.
> >
> > My point is that I'd like the kernel to handle this situation a bit
> > differently than it currently does.
>
> Read my example again, it's the same thing for ipv4.
>
> The root LAN user can disable all IPV4 communications to arbitrary IP
> addresses on the local LAN by emitting bogus ARP requests and
> poisoning everyone's caches. What's the difference between that
> and this arbitrary ipv6 issue?
>
> There is none at all.
>
> If you have a root person on your local LAN you're subject to injection
> of bogus addressing and routing information. This issue is not specific
> to ipv4 or ipv6 and is fundamental in nature.
>
> So it is misleading to bring this up as an ipv6 specific problem, it's
> not.
You're quite right about this, but I think George's point may be that
it's harder to recover if and when the malicious traffic is stopped.
Poisoned ARP table entries will expire fairly quickly.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses
2012-11-14 23:08 ` David Miller
2012-11-16 21:27 ` Ben Hutchings
@ 2012-12-27 15:57 ` George Kargiotakis
2012-12-27 16:54 ` Eric Dumazet
1 sibling, 1 reply; 8+ messages in thread
From: George Kargiotakis @ 2012-12-27 15:57 UTC (permalink / raw)
To: netdev
Hello all,
I had previously informed this list about the issue of the linux kernel
losing IPv6 privacy extensions by a local LAN attacker.
Recently I've found that there's actually another, more serious in my
opinion, issue that follows the previous one. If the user tries to
disconnect/reconnect the network device/connection for whatever reason
(e.g. thinking he might gain back privacy extensions), then the device
gets IPs from SLAAC that have the "tentative" flag and never loses
that. That means that IPv6 functionality for that device is from then
on completely lost. I haven't been able to bring back the kernel to a
working IPv6 state without a reboot.
This is definitely a DoS situation and it needs fixing.
Here are the steps to reproduce:
== Step 1. Boot Ubuntu 12.10 (kernel 3.5.0-17-generic) ==
ubuntu@ubuntu:~$ ip a ls dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0
inet6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic
valid_lft 86379sec preferred_lft 3579sec
inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global dynamic
valid_lft 86379sec preferred_lft 3579sec
inet6 fdbb:aaaa:bbbb:cccc:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic
valid_lft 86379sec preferred_lft 3579sec
inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global dynamic
valid_lft 86379sec preferred_lft 3579sec
inet6 fe80::5054:ff:fe8b:995d/64 scope link
valid_lft forever preferred_lft forever
ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = 2
net.ipv6.conf.lo.use_tempaddr = 2
ubuntu@ubuntu:~$ nmcli con status
NAME UUID DEVICES DEFAULT VPN MASTER-PATH
Wired connection 1 923e6729-74a7-4389-9dbd-43ed7db3d1b8 eth0 yes no --
ubuntu@ubuntu:~$ nmcli dev status
DEVICE TYPE STATE
eth0 802-3-ethernet connected
//ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6
ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=70.9 ms
--- 2a00:1450:4002:800::100e ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 70.994/70.994/70.994/0.000 ms
# tcpdump -ni eth0 host 2a00:1450:4002:800::100e
17:57:37.784658 IP6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64
17:57:37.855257 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:ad1f:9166:93d4:fd6d: ICMP6, echo reply, seq 1, length 64
== Step 2. flood RAs on the LAN ==
$ dmesg | tail
[ 1093.642053] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
[ 1093.642062] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
[ 1093.642065] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
[ 1093.642067] IPv6: ipv6_create_tempaddr: regeneration time exceeded - disabled temporary address support
ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = -1
net.ipv6.conf.lo.use_tempaddr = 2
//ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6
ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=77.5 ms
--- 2a00:1450:4002:800::100e ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 77.568/77.568/77.568/0.000 ms
# tcpdump -ni eth0 host 2a00:1450:4002:800::100e
17:59:38.204173 IP6 2001:db8:f00:f00:5054:ff:fe8b:995d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64
17:59:38.281437 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:5054:ff:fe8b:995d: ICMP6, echo reply, seq 1, length 64
//notice the change of IPv6 address to the one not using privacy extensions even after the flooding has finished long ago.
== Step 3. Disconnect/Reconnect connection ==
// restoring net.ipv6.conf.eth0.use_tempaddr to value '2' makes no difference at all for the rest of the process
# nmcli dev disconnect iface eth0
# nmcli con up uuid 923e6729-74a7-4389-9dbd-43ed7db3d1b8
ubuntu@ubuntu:~$ ip a ls dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0
inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global tentative dynamic
valid_lft 86400sec preferred_lft 3600sec
inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global tentative dynamic
valid_lft 86400sec preferred_lft 3600sec
inet6 fe80::5054:ff:fe8b:995d/64 scope link tentative
valid_lft forever preferred_lft forever
//Notice the "tentative" flag of the IPs on the device
//ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6
ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
^C
--- 2a00:1450:4002:800::100e ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
# tcpdump -ni eth0 host 2a00:1450:4002:800::100e
18:01:45.264194 IP6 ::1 > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64
Summary:
Before flooding it uses IP: 2001:db8:f00:f00:ad1f:9166:93d4:fd6d
After flooding it uses IP: 2001:db8:f00:f00:5054:ff:fe8b:995d --> it has lost privacy extensions
After disconnect/reconnect it tries to use IP: ::1 --> it has lost IPv6 connectivity
Best regards,
--
George Kargiotakis
https://void.gr
GPG KeyID: 0xE4F4FFE6
GPG Fingerprint: 9EB8 31BE C618 07CE 1B51 818D 4A0A 1BC8 E4F4 FFE6
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses
2012-12-27 15:57 ` George Kargiotakis
@ 2012-12-27 16:54 ` Eric Dumazet
2012-12-28 17:19 ` Eric Dumazet
0 siblings, 1 reply; 8+ messages in thread
From: Eric Dumazet @ 2012-12-27 16:54 UTC (permalink / raw)
To: George Kargiotakis; +Cc: netdev
On Thu, 2012-12-27 at 17:57 +0200, George Kargiotakis wrote:
> Hello all,
>
> I had previously informed this list about the issue of the linux kernel
> losing IPv6 privacy extensions by a local LAN attacker.
> Recently I've found that there's actually another, more serious in my
> opinion, issue that follows the previous one. If the user tries to
> disconnect/reconnect the network device/connection for whatever reason
> (e.g. thinking he might gain back privacy extensions), then the device
> gets IPs from SLAAC that have the "tentative" flag and never loses
> that. That means that IPv6 functionality for that device is from then
> on completely lost. I haven't been able to bring back the kernel to a
> working IPv6 state without a reboot.
>
> This is definitely a DoS situation and it needs fixing.
>
> Here are the steps to reproduce:
>
> == Step 1. Boot Ubuntu 12.10 (kernel 3.5.0-17-generic) ==
> ubuntu@ubuntu:~$ ip a ls dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
> link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0
> inet6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic
> valid_lft 86379sec preferred_lft 3579sec
> inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global dynamic
> valid_lft 86379sec preferred_lft 3579sec
> inet6 fdbb:aaaa:bbbb:cccc:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic
> valid_lft 86379sec preferred_lft 3579sec
> inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global dynamic
> valid_lft 86379sec preferred_lft 3579sec
> inet6 fe80::5054:ff:fe8b:995d/64 scope link
> valid_lft forever preferred_lft forever
>
> ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr
> net.ipv6.conf.all.use_tempaddr = 2
> net.ipv6.conf.default.use_tempaddr = 2
> net.ipv6.conf.eth0.use_tempaddr = 2
> net.ipv6.conf.lo.use_tempaddr = 2
>
> ubuntu@ubuntu:~$ nmcli con status
> NAME UUID DEVICES DEFAULT VPN MASTER-PATH
> Wired connection 1 923e6729-74a7-4389-9dbd-43ed7db3d1b8 eth0 yes no --
> ubuntu@ubuntu:~$ nmcli dev status
> DEVICE TYPE STATE
> eth0 802-3-ethernet connected
>
> //ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6
>
> ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
> PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
> 64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=70.9 ms
>
> --- 2a00:1450:4002:800::100e ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 70.994/70.994/70.994/0.000 ms
>
> # tcpdump -ni eth0 host 2a00:1450:4002:800::100e
> 17:57:37.784658 IP6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64
> 17:57:37.855257 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:ad1f:9166:93d4:fd6d: ICMP6, echo reply, seq 1, length 64
>
> == Step 2. flood RAs on the LAN ==
>
> $ dmesg | tail
> [ 1093.642053] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
> [ 1093.642062] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
> [ 1093.642065] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
> [ 1093.642067] IPv6: ipv6_create_tempaddr: regeneration time exceeded - disabled temporary address support
>
> ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr
> net.ipv6.conf.all.use_tempaddr = 2
> net.ipv6.conf.default.use_tempaddr = 2
> net.ipv6.conf.eth0.use_tempaddr = -1
> net.ipv6.conf.lo.use_tempaddr = 2
>
> //ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6
>
> ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
> PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
> 64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=77.5 ms
>
> --- 2a00:1450:4002:800::100e ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 77.568/77.568/77.568/0.000 ms
>
> # tcpdump -ni eth0 host 2a00:1450:4002:800::100e
> 17:59:38.204173 IP6 2001:db8:f00:f00:5054:ff:fe8b:995d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64
> 17:59:38.281437 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:5054:ff:fe8b:995d: ICMP6, echo reply, seq 1, length 64
>
> //notice the change of IPv6 address to the one not using privacy extensions even after the flooding has finished long ago.
>
> == Step 3. Disconnect/Reconnect connection ==
> // restoring net.ipv6.conf.eth0.use_tempaddr to value '2' makes no difference at all for the rest of the process
>
> # nmcli dev disconnect iface eth0
> # nmcli con up uuid 923e6729-74a7-4389-9dbd-43ed7db3d1b8
>
> ubuntu@ubuntu:~$ ip a ls dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
> link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0
> inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global tentative dynamic
> valid_lft 86400sec preferred_lft 3600sec
> inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global tentative dynamic
> valid_lft 86400sec preferred_lft 3600sec
> inet6 fe80::5054:ff:fe8b:995d/64 scope link tentative
> valid_lft forever preferred_lft forever
>
> //Notice the "tentative" flag of the IPs on the device
>
> //ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6
>
> ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
> PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
> ^C
> --- 2a00:1450:4002:800::100e ping statistics ---
> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
>
> # tcpdump -ni eth0 host 2a00:1450:4002:800::100e
> 18:01:45.264194 IP6 ::1 > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64
>
> Summary:
> Before flooding it uses IP: 2001:db8:f00:f00:ad1f:9166:93d4:fd6d
> After flooding it uses IP: 2001:db8:f00:f00:5054:ff:fe8b:995d --> it has lost privacy extensions
> After disconnect/reconnect it tries to use IP: ::1 --> it has lost IPv6 connectivity
>
> Best regards,
We should only rate limit, and not disable forever.
If I cook a patch, are you willing to compile a kernel and test it ?
Thanks
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses
2012-12-27 16:54 ` Eric Dumazet
@ 2012-12-28 17:19 ` Eric Dumazet
0 siblings, 0 replies; 8+ messages in thread
From: Eric Dumazet @ 2012-12-28 17:19 UTC (permalink / raw)
To: George Kargiotakis; +Cc: netdev
On Thu, 2012-12-27 at 08:54 -0800, Eric Dumazet wrote:
> We should only rate limit, and not disable forever.
>
Something like :
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index dd52d51..32d51e2 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1282,7 +1282,7 @@ max_desync_factor - INTEGER
Default: 600
regen_max_retry - INTEGER
- Number of attempts before give up attempting to generate
+ Number of attempts per second before give up attempting to generate
valid temporary addresses.
Default: 5
diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h
index 9356322..8f206cf 100644
--- a/include/net/if_inet6.h
+++ b/include/net/if_inet6.h
@@ -70,6 +70,7 @@ struct inet6_ifaddr {
struct list_head tmp_list;
struct inet6_ifaddr *ifpub;
int regen_count;
+ u32 regen_stamp;
#endif
struct rcu_head rcu;
};
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 408cac4a..c41925c 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -980,6 +980,7 @@ static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, struct inet6_ifaddr *i
int max_addresses;
u32 addr_flags;
unsigned long now = jiffies;
+ u32 stamp;
write_lock(&idev->lock);
if (ift) {
@@ -994,18 +995,22 @@ retry:
in6_dev_hold(idev);
if (idev->cnf.use_tempaddr <= 0) {
write_unlock(&idev->lock);
- pr_info("%s: use_tempaddr is disabled\n", __func__);
+ pr_info_ratelimited("%s: use_tempaddr is disabled\n", __func__);
in6_dev_put(idev);
ret = -1;
goto out;
}
spin_lock_bh(&ifp->lock);
+ stamp = jiffies / HZ;
+ if (stamp != ifp->regen_stamp) {
+ ifp->regen_stamp = stamp;
+ ifp->regen_count = 0;
+ }
if (ifp->regen_count++ >= idev->cnf.regen_max_retry) {
- idev->cnf.use_tempaddr = -1; /*XXX*/
spin_unlock_bh(&ifp->lock);
write_unlock(&idev->lock);
- pr_warn("%s: regeneration time exceeded - disabled temporary address support\n",
- __func__);
+ pr_warn_ratelimited("%s: regeneration time exceeded - disabled temporary address support\n",
+ __func__);
in6_dev_put(idev);
ret = -1;
goto out;
^ permalink raw reply related [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-12-28 17:19 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-14 21:14 Linux kernel handling of IPv6 temporary addresses George Kargiotakis
2012-11-14 21:29 ` David Miller
2012-11-14 23:03 ` George Kargiotakis
2012-11-14 23:08 ` David Miller
2012-11-16 21:27 ` Ben Hutchings
2012-12-27 15:57 ` George Kargiotakis
2012-12-27 16:54 ` Eric Dumazet
2012-12-28 17:19 ` Eric Dumazet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).