This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 250919 - IPV6_PRIVACY=rfc3041 in /etc/sysconfig/networking/devices/ifcfg-eth0 does not take effect
IPV6_PRIVACY=rfc3041 in /etc/sysconfig/networking/devices/ifcfg-eth0 does not...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On: 700138
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-05 04:21 EDT by Russell Odom
Modified: 2014-03-16 23:07 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 700138 (view as bug list)
Environment:
Last Closed: 2012-08-16 15:38:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Amends to ifup-ipv6 as suggested by Peter (1.76 KB, patch)
2007-08-05 11:11 EDT, Russell Odom
no flags Details | Diff
NOT WORKING: Amends to ifup-eth to call "ifup-ipv6 ... pre" (1.01 KB, patch)
2007-08-05 11:16 EDT, Russell Odom
no flags Details | Diff
Proper support of IPV6_PRIVACY (rfc3041) option (2.77 KB, patch)
2007-08-07 02:08 EDT, Peter Bieringer
no flags Details | Diff
Patch for ifup-eth to call ifup-ipv6 with special option before interface is going up (757 bytes, patch)
2007-08-07 02:11 EDT, Peter Bieringer
no flags Details | Diff
Updated patch for ifup-ipv6 (6.15 KB, patch)
2007-08-11 05:24 EDT, Peter Bieringer
no flags Details | Diff
Patch for ifup-wireless, same like as needed for ifup-eth (395 bytes, patch)
2007-08-11 05:25 EDT, Peter Bieringer
no flags Details | Diff
Patch for F14 to ifup-ipv6 and ifup-eth to enable proper working rfc3041 support (2.27 KB, patch)
2011-04-28 02:12 EDT, Peter Bieringer
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 250921 None None None Never

  None (edit)
Description Russell Odom 2007-08-05 04:21:08 EDT
Description of problem:
Setting IPV6_PRIVACY=rfc3041 in /etc/sysconfig/networking/devices/ifcfg-eth0
should auto-configure an unpredictable, changing, IPv6 address for your host
instead of one based on the card's MAC address, but does not do so (except under
certain circumstances - see later).

This was discussed in 2 threads started by Peter Bieringer at
http://lists.deepspace6.net/archive/initscripts-ipv6/2004-August/thread.html
(particularly the second one) but no resolution appears to be forthcoming. To
summarise the discussion, the appropriate flag
(net.ipv6.conf.$DEVICE.use_tempaddr) is set in ifup-ipv6, but this is too late
to take effect, so either a) it needs setting earlier in the process - in one of
the other ifup scripts before ifup-ipv6, or b) the IPv6 implementation needs
extending to create a temporary address any time
net.ipv6.conf.$DEVICE.use_tempaddr is changed to 1 or 2, not just if it's set
when the interface comes up.


Version-Release number of selected component (if applicable):
[root@detritus ~]# rpm -q initscripts
initscripts-8.45.7-1.x86_64
[root@detritus ~]# uname -a
Linux detritus.local 2.6.20-1.2948.fc6 #1 SMP Fri Apr 27 19:18:54 EDT 2007
x86_64 x86_64 x86_64 GNU/Linux


How reproducible: Almost every time; I've managed to get it to work by taking
the device down and back up again (I think!) but I can't reproduce it reliably.
Seems consistent with the discussion previously mentioned, though.


Steps to Reproduce:
1. Enable IPV6INIT=yes, IPV6_AUTOCONF=yes and IPV6_PRIVACY=rfc3041 in
/etc/sysconfig/networking/devices/ifcfg-eth0
2. "service network restart"
3. "ifconfig eth0"
  
Actual results:
You will see an auto-generated IPv6 address that bears a remarkable similarity
to your MAC address.

Expected results:
An auto-generated IPv6 address that is different to your MAC address and changes
each time.

Additional info:
I tried moving the block of code in ifup-ipv6 that deals with the IPV6_PRIVACY
flag right to the top of the script, before anything else happens, in the hope
that doing it before we enable accept_ra would cause it to work, but no joy.

In /etc/sysconfig/networking/devices/ifcfg-eth0 I also set IPV6ADDR and
IPV6ADDR_SECONDARIES but this has no bearing on whether it works or not. I have
radvd running on a router on my network advertising a public IPv6 /48 assignment
tunneled via www.uk6x.com.
Comment 1 Russell Odom 2007-08-05 04:28:17 EDT
CCing Pekka Savola who was involved in the discussion mentioned - hope that's OK :-)
Comment 2 Russell Odom 2007-08-05 05:19:15 EDT
The solution to bug 250921 and this one may be related.
Comment 3 Peter Bieringer 2007-08-05 08:30:28 EDT
I also have no idea how to fix this compatible to current initscripts layout
without support of the kernel.

2 possibilites:
1) kernel gets support for "tempaddr" switching on an UP interface

2) initscripts layout will be extended with "ifup-ipv6-pre" (which can be
"ifup-ipv6", called with a parameter "pre"), which is called by ifup-eth before
bringing the interface up.
Comment 4 Russell Odom 2007-08-05 11:11:05 EDT
Created attachment 160712 [details]
Amends to ifup-ipv6 as suggested by Peter

OK, the first part of Peter's suggestion - amending ifup-ipv6 to take an
optional second arg 'pre' (or 'post', for completeness). Moved the use_tempaddr
setting to the new 'pre' section.
Comment 5 Russell Odom 2007-08-05 11:16:31 EDT
Created attachment 160714 [details]
NOT WORKING: Amends to ifup-eth to call "ifup-ipv6 ... pre"

Following on from that, I put the appropriate calls to "ifup-ipv6 ... pre" in
what looks to me like the right places... but it still doesn't work - I'm
guessing it's not early enough still. Or is it too early?

Peter, was this where you had in mind for this hook, or did I get it wrong?
Comment 6 Peter Bieringer 2007-08-05 11:17:39 EDT
Your solution won't work as far as I tested, because the per device value is
inherit from "default". I don't know, why, but it is. Better workaround is
mentioned in
http://lists.deepspace6.net/archive/initscripts-ipv6/2007-August/000168.html
Please run some tests with my patch set.
Comment 7 Russell Odom 2007-08-05 12:29:06 EDT
As replied on the list: I get the address generated from my MAC which I had
before, *plus* a random-looking RFC3041 address (which changes every time I
restart the network). I would have expected not to see the one from my MAC at
all, just the RFC3041 one. However, re-reading the RFC it doesn't seem to
specify that the other address should not be present, just that the temporary
one should be used in preference for outgoing connections.

Having visited http://www.whatismyipv6.net/ I see the RFC3041 address instead of
the one based on my MAC, so IMO Peter's patches fix the issue :-)
Comment 8 Bill Nottingham 2007-08-06 17:17:12 EDT
Is there any reason you'd want to have this be a per-address setting? (Note:
that config variable is awful.)
Comment 9 Pekka Savola 2007-08-07 01:10:34 EDT
You probably mean a per-prefix setting?  I could imagine cornercases where that
would be useful but I suspect that per-interface is typically enough.

Agreed about config variable.  Note that RFC3041 is being updated and is soon
replaced by another RFC number.  Maybe "rfc3041" should be transitioned away and
replaced with a simple "yes".
Comment 10 Peter Bieringer 2007-08-07 02:04:59 EDT
RFC3041 per prefix is not supported by kernel, if enabled on an interface, for
all autogenerated addresses a "secondary dynamic" one is created.
Comment 11 Peter Bieringer 2007-08-07 02:08:59 EDT
Created attachment 160799 [details]
Proper support of IPV6_PRIVACY (rfc3041) option

This patch in conjunction with the following one for ifup-eth fixes the
currently not working support of IPV6_PRIVACY. Also the option now maps "yes"
to "rfc3041" as suggested by Pekka
Comment 12 Peter Bieringer 2007-08-07 02:11:31 EDT
Created attachment 160800 [details]
Patch for ifup-eth to call ifup-ipv6 with special option before interface is going up

This patch adds a call of ifup-ipv6 before interface is going up to setup
kernel parameters, which are only recognized if interface is down and going up
later.
Comment 13 Peter Bieringer 2007-08-07 03:57:08 EDT
I will run some regression tests next days on patch
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250919#c11 regarding the
real need of setting default instead of per device before interface going up on
eth and on wireless. Also I will implement the control of accepting router
advertisements in the pre section.
Comment 14 Bill Nottingham 2007-08-07 10:26:00 EDT
Looking at the patch:

- I'd just check [ -n "$IPV6_PRIVACY" -a "$IPV6_PRIVACY" != "no" ], or similar.
- it's possible that ifup can get called in parallel - that will break this change

The reason I asked about per-address is... if you want it for all interfaces,
you might as well just set it in sysctl.conf and not be frobbing it before and
after interface bringup.
Comment 15 Peter Bieringer 2007-08-07 10:52:47 EDT
Regarding "it's possible that ifup can get called in parallel: have to check
whether toggling the "default" value is really necessary (I still remember, but
regressions will show the truth). If yes, we run into the next CANTFIX problem.

Perhaps we should push some problems to the kernel folks to supply user space
with a proper support instead playing tricks all the time in the initscripts
which means:

- working enabling/disabling tempaddr on a running interface (like expected)
- working enabling/disabling accept_ra on a running interface (like expected)
- capability selection of default address for outgoing connection by adding a
"preferred" flag to an address (one per scope should be possible)


Comment 16 Peter Bieringer 2007-08-11 05:24:13 EDT
Created attachment 161110 [details]
Updated patch for ifup-ipv6

Updated patch for proper support of IPV6_PRIVACY and disabling automatic
address generation, if IPV6ADDR is given.

Regression tests show, that setup of sysctl/default before interface is going
up is required, original values are stored in lock file, which is also checked
for possible reentrance.
Comment 17 Peter Bieringer 2007-08-11 05:25:39 EDT
Created attachment 161111 [details]
Patch for ifup-wireless, same like as needed for ifup-eth
Comment 18 Russell Odom 2007-08-12 06:04:31 EDT
The updated ifup-ipv6 patch from comment 16 works fine for me.
Comment 19 Russell Odom 2007-08-30 16:53:21 EDT
OK, I spoke too soon... I rebooted my machine for the first time in a few
months, and I just noticed that, despite nothing having changed in my config, I
didn't get an auto-generated RFC3041 address on startup - just the Link
(fe80::...), Site (fec0::..) and Global (2001:...) addresses generated from my
MAC, and the Site and Global addresses specified in IPV6ADDR_SECONDARIES.

Running "service network restart" gave me additional random Site and Global
addresses.

Any thoughts? Some timing issue related to contacting radvd (which runs on my
router, and advertises my Site and Global prefixes), maybe?
Comment 20 Tomasz Kepczynski 2008-01-09 01:18:55 EST
I can see the same behaviour as in #19 above.
Additionally it looks like temporary addresses are being
disabled after some time. I can see the following:

geralt:~# cat /proc/sys/net/ipv6/conf/eth0/use_tempaddr
-1

and from /var/log/messages:

Jan  9 06:49:02 geralt kernel: ipv6_create_tempaddr(): regeneration time
exceeded. disabled temporary address support.
Jan  9 06:50:32 geralt kernel: ipv6_create_tempaddr(): use_tempaddr is disabled.
Jan  9 06:50:35 geralt kernel:last message repeated 2 times

This may explain why we don't see temporary address after boot -
it may just get disabled before we have a chance to check on it.

I also think there is one more problem: I have a feeling that
temporary address may be removed from the interface even if
it is still in use (by ssh session for example). But this
probably is kernel issue...
Comment 21 Tomasz Kepczynski 2008-01-09 01:20:32 EST
I forgot to mention that all of this happens on Fedora 8 with:
kernel-2.6.23.9-85.fc8.x86_64
initscripts-8.60-1.x86_64
Comment 22 Bug Zapper 2008-04-04 03:30:43 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 23 Russell Odom 2008-04-04 06:22:38 EDT
Still an issue in F8
Comment 24 Bug Zapper 2008-11-26 02:38:40 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 25 Bug Zapper 2009-11-18 05:07:31 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Pekka Savola 2009-11-24 02:37:37 EST
I think this is still an issue in 12.
Comment 27 Beat Siegenthaler 2010-09-08 11:08:03 EDT
Seems to be still actual in 
Linux 2.6.32.21-166.fc12.i686.PAE #1 SMP Fri Aug 27 06:33:34 UTC 2010 i686 i686 i386 GNU/Linux
Comment 28 Bug Zapper 2010-11-04 08:08:32 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 29 Bug Zapper 2010-12-05 02:15:25 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 30 Russell Odom 2011-01-27 10:31:31 EST
Sorry for delay, confirming still present in F13.
Comment 31 Daniel Roesen 2011-02-21 03:34:54 EST
IPv6 addressing privacy concerns are making the press by now. Linux and MacOS being pointed out as being "problematic by default" as most (all?) Linux distros don't enable IPv6 Privacy Extensions by default. I'm going to raise another bug to get this hopefully changed in Fedora, but as far as I can see, there's still infrastructure work to be done, according to what I read here. Is there any chance of that getting any traction?

Changing release to F13 as per Russells comment.
Comment 32 Daniel Roesen 2011-02-21 03:36:44 EST
Also removing the Triaged keyword as the bug has been reopened. To my understanding of the Triaged description, it was prolly set when this bug got auto-closed.
Comment 37 Frank Ch. Eigler 2011-04-27 12:21:50 EDT
Bill, have you tried designating the original inet6 address as deprecated,
so as to avoid its use as a source address:

ip -6 addr change 2001:470:1d:1c6:f2de:f1ff:fe05:8579/64 dev eth0 preferred_lft 0
Comment 38 Bill C. Riemers 2011-04-27 12:25:09 EDT
At least with Fedora 14, I can confirm that you can enable rfc3401 privacy by adding the respective option in the /etc/sysctl.conf.   e.g.

echo net.ipv6.conf.eth0.use_tempaddr=2 >> /etc/sysctl.conf

presumably you could specify all devices with:

echo net.ipv6.conf.all.use_tempaddr=2 >> /etc/sysctl.conf



You can enable it at runtime per device via:

ifdown eth0
sysctl net.ipv6.conf.eth0.use_tempaddr=2
ifup eth0


This to me seems much better than setting an option inside an ifcfg file.

Bill
Comment 39 Bill C. Riemers 2011-04-27 12:48:07 EDT
(In reply to comment #37)
> Bill, have you tried designating the original inet6 address as deprecated,
> so as to avoid its use as a source address:
> 
> ip -6 addr change 2001:470:1d:1c6:f2de:f1ff:fe05:8579/64 dev eth0 preferred_lft
> 0

That probably would not be a very practical approach.  As if the "perminent" ipv6 address is actually something that updates frequently this setting would be lost.   For example, if you were using a anycast 6to4 tunnel with a dynamic ipv4 address, your "permanent" address would change whenever your IPv4 address changed.

use_tempaddr=2 definitely seems like the way to do it correctly.   There is still the unknown, do I need to manually set firewall rules that block incoming connection requests on the temporary address?   If so what is the best way to do that?
Comment 40 Peter Bieringer 2011-04-27 14:20:25 EDT
Background of this still existing issue is the provided workaround:

ifdown eth0
sysctl net.ipv6.conf.eth0.use_tempaddr=2
ifup eth0

which has 2 requirements if this should be reboot-safe and working

1. IPv6 module must be loaded
=> otherwise, net.ipv6.conf.* doesn't exist at all

2. Device must exist
=> otherwise, per interface sysctl doesn't exist

3. Interface must down
=> otherwise, the toggle isn't recognized

which means at least on Fedora 14, that following key must exist in /etc/sysctl.conf:

sysctl net.ipv6.conf.all.use_tempaddr=2

to enable IPv6 privacy...so in theory currently and in the past working...until dracut puts the IPv6 module into RAMdisk.

nowadays this "all" approach is no longer working (I assume, during loading IPv6 module in early state and interfaces are configured by udev earlier than the default "all" is changed), each interface must be 
specified directly in /etc/sysctl.conf, like 

sysctl net.ipv6.conf.eth0.use_tempaddr=2

BTW: as seen in the old entries for that bug, there is a initscripts extension available, which creates a hook in ifup to apply (if configured) first the sysctl *before* bringing interface up. Unfortunately, this extension was never taken over into upstream :-(


I think the current mechanism is still strange and there are 3 options which can proper solve this:

1) integrate ifup-ipv6 into ifup and adjust systl *before* bringing interface up

2) integrate hooks for something like ifup-ipv6-PRE into ifup

3) extend IPv6 implementation in kernel that IPv6 privacy can be enabled/disabled on an running interface, not requiring interface down/up
Comment 41 Peter Bieringer 2011-04-28 02:12:19 EDT
Created attachment 495410 [details]
Patch for F14 to ifup-ipv6 and ifup-eth to enable proper working rfc3041 support

Patch 161111 is still valid
Comment 42 Peter Bieringer 2011-04-28 02:13:30 EDT
Comment on attachment 495410 [details]
Patch for F14 to ifup-ipv6 and ifup-eth to enable proper working rfc3041 support

RFC3041 is enabled, if ifcfg-INTERFACE contains:

IPV6INIT=yes
IPV6_PRIVACY="rfc3041"
Comment 43 Bill Nottingham 2011-04-28 12:31:56 EDT
So, a configuration variable whose paradigm is:

switch foo
  rfc3041)
  rfc9491)
         <do something>
  *)
         <error>

As stated in comment #8, that's awful.

Realistically, things like this don't belong in the ifup path, they belong in the udev path. But people seem highly opposed to that sort of change.
Comment 44 Pekka Savola 2011-04-28 13:15:29 EDT
FWIW, now that the specification has been superseded by RFC4941, the variable name is a bit unfortunate.
Comment 45 Peter Bieringer 2011-04-28 16:18:13 EDT
Regarding https://bugzilla.redhat.com/show_bug.cgi?id=250919#c43

using udev for setting the sysctl toggle for IPv6 privacy won't work on Fedora 14 out-of-the-box:

the IPv6 module is loaded by initial RAM disk *after* udev initialization, means if e.g. an udev rule like following

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
   ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", 
   RUN+="sysctl net.ipv6.conf.%k.use_tempaddr=2" 

won't work.

The only workaround I found was:
- create a new RAM disk with "--with ipv6"
- extend boot option with "rdloaddriver=ipv6"
- use full qualified path for sysctl

So udev initialization is imho no option at all for setting IPv6 privacy, especially, if this should be controllable per device.

If one would use the udev mechanism for per interface settings, each time a new RAM disk must be created...

Imho, ifcfg-INTERFACE would be still a good location for such interface settings to keep configuration in one place.


Regarding https://bugzilla.redhat.com/show_bug.cgi?id=250919#c44

In an extended version of ifup-ipv6 (on deepspace6), another "privacy" mode is supported, which is based on setting a random private MAC address on the interface before bringing up. Therefore the intention of using "rfc3041" as method was that IPV6_PRIVACY should be flexible to support others than the RFC 3041 one.
Comment 46 Peter Bieringer 2011-05-12 03:09:34 EDT
I made another interesting experience, which can be the case why it on some level works and suddenly after upgrading distribution or switching distribution no longer.

On Scientific Linux 6.0 (=RHEL 6) IPV6_PRIVACY="rfc3041" *works*, but from known details, the sysctl toggle is switched after ip link set DEV up. So this behavior is now unexpected.

I digged deeper and found that the toggle switch is no longer successful, if a 10 second sleep is inserted:

--- ifup-ipv6.orig	2010-09-01 16:34:41.000000000 +0200
+++ ifup-ipv6	2011-05-11 16:56:26.391664836 +0200
@@ -142,10 +142,15 @@
 
 # Enable IPv6 RFC3041 privacy extensions if desired
 if [ "$IPV6_PRIVACY" = "rfc3041" ]; then
+	ip link show dev $DEVICE
+	ip addr show dev $DEVICE
+	sleep 10
 	/sbin/sysctl -e -w net.ipv6.conf.$DEVICE.use_tempaddr=2 >/dev/null 2>&1
 	if [ $? -ne 0 ]; then
 		echo $"Cannot enable IPv6 privacy method '$IPV6_PRIVACY', not supported by kernel"
 	fi
+	ip link show dev $DEVICE
+	ip addr show dev $DEVICE
 fi
 
 # Setup default IPv6 route, check are done by function


=> the "it works" behaviour is depending on a timinig issue, I assume at least two possible cases:

- the sysctl toggle is still accepted until first IPv6 negotiation is started or finished (e.g. router advertisement is received)
- the "ip link set dev DEV up" has some internal delay and if system speed is fast, the sysctl toggle is set before internal IPv6 initialization.

Anyway, current implementation leads to unpredictable behavior.
Comment 47 Bug Zapper 2011-06-02 14:40:15 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 48 Bill Nottingham 2012-02-15 16:53:33 EST
Re: comment #45

In current releases, IPv6 is built in, and systemd automatically runs net.conf.<device> sysctls on device insertion. So, I believe sysctl.conf should work, and should work much better than doing this in the ifup path.

Note that there's a bug report (bug 790610) about making this the default.
Comment 49 Peter Bieringer 2012-02-28 15:15:04 EST
(In reply to comment #48)
> Re: comment #45
> 
> In current releases, IPv6 is built in, and systemd automatically runs
> net.conf.<device> sysctls on device insertion. So, I believe sysctl.conf should
> work, and should work much better than doing this in the ifup path.

How is systemd handling this in detail? I'm asking because I ran here into a strange problem with unknown reason.

# grep ipv6 /etc/sysctl.conf 
net.ipv6.conf.all.use_tempaddr=2
net.ipv6.conf.default.use_tempaddr=2

Now after some time (unsure when, but perhaps after hibernating the system), suddenly such setting on the interface is gone and turned to 

net.ipv6.conf.p32p1.use_tempaddr=-1

BTW: if anyone still interested in bringing this IPV6_PRIVACY back to working, I can run through my old patches and create a new set. In principle, this must be set per interface *before* it's coming up, so in the ifup script, a special hook will be created (minor patch) or integrating IPv6 from ifup-ipv6 into main ifup (bigger patch probably).
Comment 50 Bill Nottingham 2012-02-28 15:41:34 EST
See /lib/udev/rules.d/99-systemd.rules, specifically where it does:

# Apply sysctl variables to network devices (and only to those) as they appear.

SUBSYSTEM=="net", KERNEL!="lo", RUN+="/lib/systemd/systemd-sysctl --prefix=/proc/sys/net/ipv4/conf/$name --prefix=/proc/sys/net/ipv4/neigh/$name --prefix=/proc/sys/net/ipv6/conf/$name --prefix=/proc/sys/net/ipv6/neigh/$name"
Comment 51 Peter Bieringer 2012-02-28 15:56:13 EST
Ok, this sounds reasonable at least since F16, where IPv6 is no longer "extra" as kernel module.

Last time I've tried setting use_tempaddr via udev (<= F15 afair) it won't work because the IPv6 module was not built-into kernel by default which meant that the sysctl failed because network device appear earlier than IPv6 module was loaded.
Comment 52 Fedora End Of Life 2012-08-16 15:38:07 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note You need to log in before you can comment on or make changes to this bug.