Bug 13221

Summary:	IPv6 Privacy extension, temporary are not regenerated properly.
Product:	Networking	Reporter:	Lukasz Stelmach (stlman)
Component:	IPV6	Assignee:	Hideaki YOSHIFUJI (yoshfuji)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	alan, jonathan_bin
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.30-rc4	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	More elaborate fix of temporary address assgnment. Next revision of the same patch.

Description Lukasz Stelmach 2009-05-01 21:22:33 UTC

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.

Comment 1 Lukasz Stelmach 2009-05-01 21:45:58 UTC

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?

Comment 2 Lukasz Stelmach 2009-05-03 21:23:32 UTC

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.

Comment 3 Lukasz Stelmach 2009-05-03 21:24:45 UTC

*** Bug 13208 has been marked as a duplicate of this bug. ***

Comment 4 Lukasz Stelmach 2009-05-04 13:36:04 UTC

Created attachment 21208 [details]
Next revision of the same patch.

This is the same patch as before with some issues ironed.

Comment 5 Andrew Morton 2009-05-05 21:27:56 UTC

(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.

Comment 6 David S. Miller 2009-05-05 21:30:51 UTC

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.