Temporary addresses aren't regenerated properly if: 1) temp_prefered_lft - desync_factor < ADDR_CHECK_FREQUENCY. Address verification do not schedule generating of a new address but deprecates the address during the first verification after it is created. 2) temp_valid_lft changes between verifications so that there is no chance for an address to become deprecated. If any of the above happens there is no chance to create new valid and preferred temporary address because they are created only when: 1) a new public is created 2) a temporary address is going to be deprecated. (it needs to be verified at least ones as valid and preferred in addrconf_verify()) All in all we end up with no temporary address and no chance to get one. PS. I'll try to work it out this weekend.
Yet another problem is that desync_factor is constant and equal max_desync_factor (i.e. 10 minutes) which makes it completly useles. RFC says: The value DESYNC_FACTOR is a random value (different for each client) that ensures that clients don't synchronize with each other and generate new addresses at exactly the same time. When the preferred lifetime expires, a new temporary address is generated using the new randomized interface identifier. so i suppose it will be ok if there is a single value for all interfaces generated in addrconf_init and probably regenerated when max_desync_factor is set to a value that is lower then the current value of the desync_factor. BTW, rfc doesn't say anything about max_desync_factor being tunable. Should it be?
Created attachment 21201 [details] More elaborate fix of temporary address assgnment. This patch fixes issues with temporary address assignment and improper expiration. Described in bug #13208. It also implements RFC-compliant DESYNC_FACTOR variable that prevents clients form synchronizing in address reassignment. The patch has been created against Linux 2.6.30-rc4.
*** Bug 13208 has been marked as a duplicate of this bug. ***
Created attachment 21208 [details] Next revision of the same patch. This is the same patch as before with some issues ironed.
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). Someone seems to have just unbusted something at bugzilla.kernel.org and I'm being flooded with old bugzilla reports. On Fri, 1 May 2009 21:22:34 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13221 > > Summary: IPv6 Privacy extension, temporary are not regenerated > properly. This one has patches attached. Please send patches via email, not via bugzilla. Let's start again on this one. Please send a fresh, fully changelogged patch to the ipv6 maintainers and mailing list (available in ./MAINTAINERS). Thanks.
From: Andrew Morton <akpm@linux-foundation.org> Date: Tue, 5 May 2009 14:25:36 -0700 > Let's start again on this one. Please send a fresh, fully changelogged > patch to the ipv6 maintainers and mailing list (available in ./MAINTAINERS). He already did this the other day.