netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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).