bad router advertisement lead to disabilitation of ipv6 privacy extension

[Davide]

Binary package hint: linux-source

After enabling IPV6 privacy extension (with echo 2 > /proc/sys/net/ipv6/conf/eth8/use_tempaddr)
ubuntu autoconfigs, as aspected, ipv6-privacy-extension-addresses and they change every 60 seconds makeing outgoing connection droped every 60 seconds (radvd running on 6to4 prefix with AdvPreferredLifetime 20 and AdvValidLifetime 30).
After changing AdvValidLifetime to 300 in radvd (on the router) ubuntu starts getting assigned more and more addresses up to about 15.
Changing AdvValidLifetime back to 30 lead ubuntu to deconfigure ALL ipv6-privacy-extension-addresses addresses leaving the interface with only the stateless address but interface is still configured to use privacy extension but it's no longer used. So privacy is no longer ensured without any user command but just some crafted ra packets.

[stlman (stlman-linux-kernel-bugs)]

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.

[stlman (stlman-linux-kernel-bugs)]

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?

[stlman (stlman-linux-kernel-bugs)]

Created attachment 21201
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.

[stlman (stlman-linux-kernel-bugs)]

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

[stlman (stlman-linux-kernel-bugs)]

Created attachment 21208
Next revision of the same patch.

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

[akpm (akpm-linux-kernel-bugs)]

(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
<email address hidden> 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.

[davem (davem-linux-kernel-bugs)]

From: Andrew Morton <email address hidden>
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.

[Andy Whitcroft (apw)]

This is a real kernel bug moving to the linux package.

[Davide (davidef1986)]

I've just found a reference of this bug in the kernel.org bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=13221
There's also an attached patch but at the moment I haven't time to recompile the kernel and test it.

[Leann Ogasawara (leannogasawara)]

Seems patch was also posted to LKML, but needing to be fixed up:

http://lkml.org/lkml/2009/5/3/171

[Davide (davidef1986)]

I've just installed karmic (kubuntu) here the situation is even worst...
I wasn't sure if open a new bug as it's not only related with ipv6-privacy extension
Now you just need to run radvd with the following configuration:
interface br0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        prefix 2001:xxxx:xxxx:xxxx::/64 {
                AdvOnLink off;
                AdvAutonomous on;
                AdvRouterAddr on;
                AdvPreferredLifetime 20;
                AdvValidLifetime 30;
        };
};
and you will get your ipv6 address and (if you enabled privacy extension) the privacy one. after a while all configured address just disappear not just the privacy one as said in the first post but all (only linklocal address remains) !!
I think that now it's something more than medium as in a network like that ipv6 is just unusable.

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Davide (davidef1986)]

I have just checked with the 2010-03-06 live cd and the bug is always there.
The configuration of radvd was the same as reported in the 2009-08-23 comment

[Mike Mestnik (cheako)]

I've just configured my Debian router with the above example + my RDNSS settings. I've confirmed my Desktop( linux-image-3.2.0-23-lowlatency-pae/3.2.0-23.31) has many addresses, presumably this can't be anything but privacy extensions.

After a bit I'll either close or confirm this bug.

[Mike Mestnik (cheako)]

Confirmed, all use_tempaddr are set to 2.

[Mike Mestnik (cheako)]

Well, I'm committing this and I still have ll my addresses. So this bug is closed.

[Mike Mestnik (cheako)]

Well, I spoke too soon. This did bite me today, all my connections are dead and my addresses gone.

[Mike Mestnik (cheako)]

This is the config that broke me, I think.

root@purgatory:~# cat /etc/radvd.conf
interface br0
{
   AdvSendAdvert on;
   MinRtrAdvInterval 3;
   MaxRtrAdvInterval 10;
   prefix 2001:470::/64
   {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;
   };
   route ::/0
   {
   };
   RDNSS 2001:470::8888 2001:4860:4860::8844 {
   };
};

[penalvch (penalvch)]

Davide, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder, but the one at the top) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[e633 (e633)]

Perhaps related to https://bugs.launchpad.net/linuxmint/+bug/1310335