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.
CCing Pekka Savola who was involved in the discussion mentioned - hope that's OK :-)
The solution to bug 250921 and this one may be related.
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.
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.
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?
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.
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 :-)
Is there any reason you'd want to have this be a per-address setting? (Note: that config variable is awful.)
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".
RFC3041 per prefix is not supported by kernel, if enabled on an interface, for all autogenerated addresses a "secondary dynamic" one is created.
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
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.
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.
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.
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)
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.
Created attachment 161111 [details] Patch for ifup-wireless, same like as needed for ifup-eth
The updated ifup-ipv6 patch from comment 16 works fine for me.
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?
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...
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
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
Still an issue in F8
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
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
I think this is still an issue in 12.
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
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
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.
Sorry for delay, confirming still present in F13.
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.
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.
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
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
(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?
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
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 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"
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.
FWIW, now that the specification has been superseded by RFC4941, the variable name is a bit unfortunate.
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.
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.
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
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.
(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).
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"
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.
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