mailing list archives
Re: Linux kernel handling of IPv6 temporary addresses
From: George Kargiotakis <kargig () void gr>
Date: Sun, 20 Jan 2013 17:02:48 +0200
and sorry for the late reply...
On Thu, 17 Jan 2013 18:43:26 +0530 (IST)
P J P <ppandit () redhat com> wrote:
+-- On Thu, 17 Jan 2013, George Kargiotakis wrote --+
| Extensions as far as I know. On your RHEL it's '0' and that's why
you | weren't seeing any 'ipv6_create_tempaddr' as previously
mentioned on your | emails. If you change this value to '2' you'll
also see those kernel | messages.
Yep, worked! I manged to reproduce the log messages. So the patch
earlier does seem to fix this issue, doesn't it? It avoids retry once
reaching the max_addresses limit.
Yes and no. When flooding finishes everything still works ok,
temp. addresses haven't been disabled, but when the preferred timer
of the temp. address of the original acquired prefix expires, the kernel
won't be able to acquire a new temporary address because the interface
is already full with 16 addresses from flooding. An already acquired
address only gets removed when it's validity timer expires. So, the
host will be left using the global non-temp address acquired by slaac
until another 'slot' (from the default 16) becomes free/expires.
Summarizing, one is still able to remotely, inside a LAN, cause
problems to another host, that is make it lose it's temp. address
functionality at least for some time.
The solution to this problem is not that simple and I've already
referenced a possible solution in one of my previous emails. Maybe a
change of logic from max_addresses per interface to max_prefixes per
interface would help.
For the dynamic tentative settings of the interface, I think another
patch would be required.
Thanks so much!
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
GPG KeyID: 0xE4F4FFE6
GPG Fingerprint: 9EB8 31BE C618 07CE 1B51 818D 4A0A 1BC8 E4F4 FFE6
Re: Linux kernel handling of IPv6 temporary addresses Kurt Seifried (Feb 22)