+++ This bug was initially created as a clone of Bug #496444 +++ Description of problem: Putting IPV6INIT=no in either /etc/sysconfig/network or, on a per-interface basis, in /etc/sysconfig/network-scripts/ifcfg-* does not disable IPv6. The real issue is the ability to disable IPv6 on a per-interface basis. Version-Release number of selected component (if applicable): initscripts-8.94-1.i586 How reproducible: Always Steps to Reproduce: 1. Put IPV6INIT=no (or anything != yes) in ifcfg-eth1 (e.g.) 2. ifup eth1 3. ifconfig eth1 Actual results: eth1 Link encap:Ethernet HWaddr 00:24:81:23:D2:71 inet addr:192.168.1.129 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 2002:wwxx:yyzz:1:224:81ff:fe23:d271/64 Scope:Global inet6 addr: fe80::224:81ff:fe23:d271/64 Scope:Link Expected results: eth1 Link encap:Ethernet HWaddr 00:24:81:23:D2:71 inet addr:192.168.1.129 Bcast:192.168.1.255 Mask:255.255.255.0 Additional info: /etc/sysconfig/network-scripts/ifup-ipv6 tests very early if IPV6INIT=yes and exits if it's not. Basically that means that whatever the kernel wants to do with that interface for IPv6 is what happens. Ideally, IPV6INIT=no (or !=yes) should disable IPv6 on that interface, then exit. In my case, there are two times to need this capability. 1. To bring up an interface with no IP address of any type, typically for listening (e.g., intrusion detection or network diagnostics) on a switch span port 2. To bring up an interface with only an IPv4 address on a machine where another interface (typically on another segment) has the IPv6 address (There's a third case, bridging, but that needs to be a separate bug.) I'll attach a small patch that disables IPv6 for any ifcfg file that does *not* have IPV6INIT=yes in it. However, there's a complication. ifcfg-lo is one such ifcfg file. People who are already using IPv6 may not expect that they'd have to put IPV6INIT=yes in ifcfg-lo to get ::1 on lo. I suggest adding that line in the default ifcfg-lo distributed with the package to maintain the behavior admins have come to expect of lo. One condition of the patch is that disabling IPv6 only appears to work after IPv6 has initialized on the interface to begin with. That usually requires setting LINKDELAY in the ifcfg file as well. In my testing, I found 0.1 to be a sufficient delay on a couple different machines, so it doesn't have to be big. I also found Bug 472761, in which the reporter had an issue with package updates overwriting ifcfg-lo with IPV6INIT=no in it. I didn't research what package changes constituted the resolution, but I expect it was just a matter of marking ifcfg-lo as a config file in the rpm, true? --- Additional comment from Allen Kistler on 2009-04-19 05:11:39 EDT --- --- Additional comment from Bill Nottingham on 2009-04-21 18:16:43 EDT --- IPV6INIT isn't defined to operate on inidividual interfaces, according to sysconfig.txt. That may be an oversight in this case. That being said, any solution that relies on LINKDELAY to work correctly isn't right. --- Additional comment from Allen Kistler on 2009-04-21 20:43:02 EDT --- I've always used NETWORKING_IPV6 for the global config variable. In sysconfig.txt, it does certainly read like NETWORKING_IPV6 and IPV6INIT are pretty much the same thing, although maybe unintentionally. However, ifup-ipv6 certainly processes IPV6INIT as if it's a per-interface variable. Otherwise "install ipv6 /bin/true" is much more effective at disabling IPv6 for everything. I can try to come up with a suggestion that does not rely on LINKDELAY. The only reason my previous suggestion needs it is because IPv6 config, including disabling, takes a little while. For turning stuff on, it seems to work okay to set it, move on, and let it actually take effect a second or two later. Turning it off doesn't work the same way. If you try to turn it off before it's ready to be turned off, it just ignores you, then comes up a second or two later, anyway. In any case, coming to an understanding of IPV6INIT as a per-interface value seems like something that needs to be agreed first. Next steps? --- Additional comment from Bug Zapper on 2009-06-09 10:06:36 EDT --- This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping --- Additional comment from Allen Kistler on 2009-06-19 03:36:05 EDT --- Re: Comment 2 Bill Nottingham wrote: > IPV6INIT isn't defined to operate on inidividual interfaces, according to > sysconfig.txt. That may be an oversight in this case. I think there's an error in sysconfig.txt. The usage comment in ifup-ipv6 itself is: # IPV6INIT=yes|no: controls IPv6 configuration for this interface and that's how the existing code uses it (or tries to use it). > That being said, any solution that relies on LINKDELAY to work correctly > isn't right. I've attached a new patch that obsoletes both previous patches and doesn't use or require LINKDELAY. It has its own wait loops, which use "sleep" and time out after 5 sec. The slowest box I tested needed about 2 sec, so 5 sec should be safe. If the /proc entries appear and disappear faster than 5 sec, then execution doesn't wait for the timeout. Since I wrote the original bug report, there's an extension of one of the points in it: an interface with not even an IPv6 link-local address as an 802.1q trunk port. I've done a few of them recently. I've beat on this patch a bit, so I'm comfortable with it, myself. I moved the meat of the code to later than the current IPV6INIT test is. 1. It uses a network-functions-ipv6 call, so it's after their definition. 2. It's after the test if ipv6 is loaded, so IPv4-only won't see any delay. --- Additional comment from Allen Kistler on 2009-06-19 16:03:50 EDT --- --- Additional comment from Karel Volný on 2010-01-11 10:50:18 EST --- updating version to F12, as I can confirm that IPv6 addresses get assigned to interfaces no matter of IPV6INIT=no @Bill, what do you think about the latest patch? --- Additional comment from Bill Nottingham on 2010-01-11 12:33:36 EST --- Any operation that depends on timeouts and then removing configuration isn't the right way to go about it. --- Additional comment from David Ward on 2010-09-24 15:28:56 EDT --- Affects Fedora 13 and 14-Alpha. Please update revision. This bug affects me for reason (1) described in original comment. @Bill, is there at least an agreement that IPV6INIT is a per-interface, rather than per-machine, configuration variable? --- Additional comment from Bug Zapper on 2010-11-04 07:20:21 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 --- Additional comment from David Ward on 2010-11-04 10:04:36 EDT --- @Bill: this bug affects Fedora 14. Please update revision. Also please respond to my earlier comment. --- Additional comment from Bill Nottingham on 2010-11-04 14:05:40 EDT --- Re: latest patch, I still maintain that any solution that involves waiting for addresses to show up and then removes them is the wrong way to go about it. Yes, the included documentation implies IPV6INIT is per-interface. --- Additional comment from Lukas Middendorf on 2011-06-05 18:15:28 EDT --- Still present in F15. As a workaround I just have ip6tables drop any traffic on the interface. I don't have a problem with the link local address I get, just don't want to get any router announcements. Why is there an "Enable IPv6 configuration for this interface" checkbox in system-config-network if it does not work (at least not for the traditional network service)? --- Additional comment from Aaron Sowry on 2011-11-15 16:56:08 EST --- This bug is still present in F16. Please update version. --- Additional comment from on 2012-02-09 15:29:27 EST --- We really need a fix for this... if it just can't work, let's get it removed from the docs that say it does in time for F17 !! --- Additional comment from Pavel Šimerda on 2012-03-09 16:41:46 EST --- Related bug 591630 also makes NetworkManager and thus Fedora not IPv6 ready. --- Additional comment from Frank Ch. Eigler on 2012-05-17 07:57:15 EDT --- Never mind per-interface ipv6 disabling; blanket systemwide ipv6 disabling also doesn't appear to work. This is a shame, since if there are any accidental/erroneous ipv6 router-advertisements on the network, fedora* will latch onto it like a rottweiler on a shank bone, and not let go. Since ipv6 is preferred by default in several bits of the OS, a bad ipv6 address trumps a good ipv4 one and damages connectivity. Bad doggie. Bad, bad doggie. No biscuits. --- Additional comment from Bill Nottingham on 2012-05-17 10:42:26 EDT --- Blanket systemwide disabling should be done with "ipv6.disable_ipv6=1" on the kernel commandline, period. --- Additional comment from on 2012-05-17 12:57:33 EDT --- Then can we please eliminate this from the networking scripts and documentation, so that we don't keep confusing people with something that doesn't really do what it says it does? --- Additional comment from Bill Nottingham on 2012-06-29 15:23:53 EDT --- Clarified in http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=ff894fdcac9713314c8d3234c8a1c843a43760ad IPV6INIT is per-interface, applies to the IPV6 configration in the config file itself. Global disabling of IPV6 should be done with the above module parameter. --- Additional comment from on 2012-07-06 18:38:30 EDT --- Excellent, thank you Bill! --- Additional comment from Fedora End Of Life on 2013-01-16 21:02:19 EST --- This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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, you are encouraged to click on "Clone This Bug" 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 --- Additional comment from Fedora End Of Life on 2013-02-13 21:58:34 EST --- Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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. --- Additional comment from Christian Schmitt on 2013-07-09 13:40:55 EDT --- This bug is still present in Fedora 19. I can't turn off IPv6 per Interface. IPV6INIT will get ignored and the Ingore or Off in the graphical NetworkManager will also get ignored. I would help to resolve this bug since i found it while i investigated: https://bugzilla.redhat.com/show_bug.cgi?id=965718
The other bug was moved to F19. Duplicates?
I'm sorry, maybe I shouldn't have moved this to F19. I apologize if this was the wrong thing to do.
(In reply to joshua from comment #2) > I'm sorry, maybe I shouldn't have moved this to F19. I apologize if this > was the wrong thing to do. No problem, I think that was the right thing to do. Now just let the packagers (most probably Dan Williams) do what they see fit with the existing bug reports. For the record, we're talking about bug 496444.
Btw i cloned the bug since he will still appears on fedora 19. Maybeits a very trivial bug. But still a odd behavior. I mean i have a ignore button or a ipv6 on/off button in nm that correctly sets ipv6init to no but nothing happens then. The value will just getting ignored. I would give any infos you need if somebody want to fix it.
Christian, the “Fedora End Of Life” message in the other bug report provides the instructions and suggests reopening and changing the version, not cloning. Now the best thing you can do is to keep the bug reports as they are.
I couldn't do that somehow, that's why i cloned it. The only thing that i could've edited would be the CC list.. Also some additional infos: I tested this on 2 versions. IPV6INIT gets set by NM but will get ignored. IPV6 is always on per device.
(In reply to Christian Schmitt from comment #6) > Also some additional infos: > I tested this on 2 versions. IPV6INIT gets set by NM but will get ignored. > IPV6 is always on per device. Sounds like a problem in the ifcfg reader.
+1 for fixing this bug. Please also consider making IPv6INIT the default for all network interfaces, because of IPv6 defaults vulnerability like router advertisements. See: https://lists.fedoraproject.org/pipermail/users/2013-July/437679.html https://lists.fedoraproject.org/pipermail/users/2013-July/437696.html https://lists.fedoraproject.org/pipermail/users/2013-July/437689.html https://lists.fedoraproject.org/pipermail/users/2013-July/437684.html for my aguments in favor of that.
I meant; making IPV6INIT=no the default.
(In reply to Fernando Lozano from comment #9) > I meant; making IPV6INIT=no the default. Nah that won't be a good default, since it's a system for endusers mostly home users. So IPV6INIT=yes is okai. Just fix the bug to turn it off. Btw. People could use Puppet to turn it off in enviroments that needs IPV6INIT=no on some interfaces.
Christian, I don't know there, but here (Brazil) almost all home users, even those with brand new machines and brand new cable / adsl modems, have IPv4 only. Besides IPv6 enabled with protocol defauts by the spec has a lot of security issues and there's a lot of discussion in the IETF about how to solve them, let alone those being implemented by products. So a user with IPv6 enabled from default after installation is vulnerable. The same way we don't recomend running with a firewall turned off, we shouldn't recomend running with IPv6 enabled by default. System defaults after installing should be the ones for most users. IMHO most users still are on IPv4 only networks and won't know what steps to configure a secure IPv6 network if they have it on their LAN or ISP link. So the default should be disabled, and Anaconda / Network Manager provide an easy way to enable for those who know how to setup IPv6 or are willing to risk it without knowing so well. This is not a Fedora-only problem. Most OSes today come with IPv6 enabled by defailt, and configured in an insecure way (because IPv6 defaults per current IETF standards are insecure).
fact is that on a F19 machine with 3.10.0-1.fc20.x86_64 it is impossible to disable ipv6 * not with the old modprobe-tricks * not with for a short time working sysctl settings * not in ifcfg-files * not with kernel-params * and not with /etc/sysconfig/network this is ridiculous - 5 sometimes working options are came and gone every few months the way how to get rid of link-local addresses changes until now on my F17/f18 machines "ipv6disable=1" as kernel param works which was needed after F18 because the in the meantime removed sysctl-settings had no longer any effect there is *no reason* that the machine below has a ipv6 local-link address since ipv6 is disabled on 3 different places and the interface is *statically* configured this is a Üsecurity* problem because having this link-local address inside a network where ipv6 is not used, not supported on the gateway and so servers inside the LAN may have no firewall settings for ipv6 any random machine also coming up with a ipv6-link-local may bypass the existing security concept ____________________________ kernel param "ipv6disable=1" is present [root@rawhide ~]# uname -r 3.10.0-1.fc20.x86_64 [root@rawhide ~]# cat /etc/sysconfig/network NETWORKING=yes NETWORKING_IPV6=no NOZEROCONF=yes [root@rawhide ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=00:0c:29:30:82:b9 ONBOOT=yes BOOTPROTO=static TYPE=Ethernet MODE=Managed IPADDR=192.168.196.18 NM_CONTROLLED=no IPV6INIT=no NETMASK=255.255.255.0 GATEWAY=192.168.196.2 USERCTL=no MTU=1500 [root@rawhide ~]# ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.196.18 netmask 255.255.255.0 broadcast 192.168.196.255 inet6 fe80::20c:29ff:fe30:82b9 prefixlen 64 scopeid 0x20<link> ether 00:0c:29:30:82:b9 txqueuelen 1000 (Ethernet) RX packets 690 bytes 59854 (58.4 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 553 bytes 146864 (143.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
(In reply to Harald Reindl from comment #12) > fact is that on a F19 machine with 3.10.0-1.fc20.x86_64 it is > impossible to disable ipv6 > Not true, try this sysctl -w net.ipv6.conf.all.disable_ipv6=1 can be set permanently, see man sysctl.conf
i am really tired about this topic i had "net.ipv6.conf.all.disable_ipv6" a long time and it did *not* disable ipv6 entirely and after someone suggested "ipv6.disable=1" as kernel param it was solved which doe snot work now as you can see above i am tired of all this *permanently* changig ways to disable it - period if a interface has IPV6INIT=no and/or is *statically* configured with no ipv6 configuration it has not to become a ipv6-lik-local address - period -------- Original-Nachricht -------- Betreff: [systemd-devel] "sysctl.conf" applied too late Datum: Wed, 08 Feb 2012 16:07:11 +0100 Von: Reindl Harald <h.reindl> Organisation: the lounge interactive design An: Mailing-List systemd <systemd-devel.org> hi can someone please take a look at this in myopinion it is not optimal starting services which possibly read settings controlled by "systcl.conf" and after that the local settings get applied sample below: after boot smbd is listening on ipv6, sysctl disables this, but seems to do it after smbd has started, manual restarting the service stops smbd to listen on ipv6 this may also problematic for all sort of software -------- Original-Nachricht -------- Betreff: Re: kernel 3.2 / 2.6.42 disable ipv6 Datum: Wed, 08 Feb 2012 15:57:28 +0100 Von: Reindl Harald <h.reindl> Antwort an: Community support for Fedora users <users.org> An: users.org Am 08.02.2012 10:33, schrieb Reindl Harald: >> sysctl -w net.ipv6.conf.all.disable_ipv6=1 >> echo "net.ipv6.conf.all.disable_ipv6=1" >> /etc/sysctl.conf >> >> The first command disables it immediately, the second after a reboot. > > thanks, this works! > "systcl -p" makes changes in /etc/sysctl.conf active immediately > > well, my /etc/sysctl.conf is growing and growing :-) hm - but it seems not to work perfectly "sysctl.conf" is applyied not at the first begin of the boot-process so it seems samba as example is starting while the option is not set, restart it after boot hash fnished removes the ipv6-listening [root@rh:~]$ netstat -l | grep smb tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1123/smbd tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1123/smbd tcp 0 0 :::445 :::* LISTEN 1123/smbd tcp 0 0 :::139 :::* LISTEN 1123/smbd [root@rh:~]$ service smb restart Redirecting to /bin/systemctl restart smb.service [root@rh:~]$ netstat -l | grep smb tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 5430/smbd tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 5430/smbd
(In reply to Fernando Lozano from comment #11) > Besides IPv6 enabled with protocol defauts by the spec has a lot of security > issues and there's a lot of discussion in the IETF about how to solve them, > let alone those being implemented by products. So a user with IPv6 enabled > from default after installation is vulnerable. > IPv6 is enabled, at the stack level and the application level, however it is by default not granted access through the firewall, so the default setup does not leave any vulnerabilities. A system can only become vulnerable if the user actively makes changes to the firewall settings to permit the activity.
> IPv6 is enabled, at the stack level and the application level and that is *wrong* if ih vae no working way to disable it on the stack level it makes only problems in pure ipv4 networks because applications may believe ipv6 is available which is not the case - period best practices in systems-administration are and where always: disable *anything* ypu do not actively use and so https://bugzilla.redhat.com/show_bug.cgi?id=982740#c12 must not happen
> however it is by default not granted access through the firewall > A system can only become vulnerable if the user actively makes > changes to the firewall settings to permit the activity mhh and that is why "Chain INPUT (policy ACCEPT 0 packets, 0 bytes)" of ip6tables after install the service and enable it on the machine where i can not get rid of the link-local address? [root@rawhide ~]# Installed: iptables-services.x86_64 [root@rawhide ~]# systemctl enable ip6tables.service ln -s '/usr/lib/systemd/system/ip6tables.service' '/etc/systemd/system/basic.target.wants/ip6tables.service' [root@rawhide ~]# systemctl start ip6tables.service [root@rawhide ~]# ip6tables --list --numeric --verbose Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Oh guys, I don't wanted to discuss what's better to make it default or not. Just the way that it won't should be fixed. When IPV6INIT=no works, we still can discuss what's better, to make it default or not. Currently I think some system administrators want to disable it on 'some' interfaces, since lot's of company networks won't have a ipv6 nameserver and/or gateway, so a link local ipv6 network just brings another layer of problems. but that could be turned off easily with ipv6init=no. I mean when we won't fix this bug, we should greyout or disable the ON/OFF or ignore feature in NetworkManager, since it's useless.
(In reply to Harald Reindl from comment #14) > i had "net.ipv6.conf.all.disable_ipv6" a long time and it > did *not* disable ipv6 entirely and after someone Does it still not work?
*currently* it seems to work again how can i trust that tomorrow it is not ignored again after all that iterations and how to disable it on a machine with multiple interfaces for specific ones? eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.196.18 netmask 255.255.255.0 broadcast 192.168.196.255 ether 00:0c:29:30:82:b9 txqueuelen 1000 (Ethernet) RX packets 263 bytes 22219 (21.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 170 bytes 17793 (17.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
(In reply to Harald Reindl from comment #20) > *currently* it seems to work again > > how can i trust that tomorrow it is not ignored again after all that > iterations and how to disable it on a machine with multiple interfaces for > specific ones? The sysctl setting is the correct one documented in the kernel-doc package and it works for several distros. Therefor it is most likely to work. IMHO the other methoeds were mostly workarounds. To disable it for a specifc interface substitute "all" in the sysctl setting with the interface's name. See /usr/share/doc/kernel-doc-*/Documentation/networking/ip-sysctl.txt from the kernel-doc package.
and *why* this with the sysctl-settings below? udp6 0 0 :::123 :::* 461/ntpd exactly *this* was the reason for my message to systemd list quoted above and ended with "ipv6disable=1" as kernel-param until now net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.all.send_redirects=0 net.ipv6.conf.all.accept_redirects=0 net.ipv6.conf.all.accept_source_route=0 net.ipv6.conf.default.accept_redirects=0 net.ipv6.conf.default.accept_source_route=0 this is all a fragile crap - period
It seems to be an ignored setting in Fedora 20. I have to confess I haven't looked into this at any depth (stacking up on IPv6 has been on my todo list since before the War On Terror), but here are the observations: Static configuration of ethernet interface (no NetworkManager, dnsmasq, dhclient or anything) In /etc/sysconfig/network-scripts/ifcfg-em1 After all the IPv4 stuff ---------- # IPV6; to be done IPV6INIT="no" # IPV6_AUTOCONF="yes" # IPV6_DEFROUTE="yes" # IPV6_PEERDNS="yes" # IPV6_PEERROUTES="yes" # IPV6_FAILURE_FATAL="no" ---------- In /etc/sysconfig/network, there is nothing Result: the Ethernet interface gets an IPv6 address (with the ISP "/56" prefix given by the router), although the "lo" does not: -------------------- em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::XXXX:XXff:feXX:XXXX prefixlen 64 scopeid 0x20<link> inet6 2001:7e8:c0bc:1a01:XXXX:XXff:feXX:XXXX prefixlen 64 scopeid 0x0<global> ether XX:XX:XX:XX:XX:XX txqueuelen 1000 (Ethernet) RX packets 36665 bytes 44110657 (42.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 24525 bytes 3032172 (2.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 em1:DNS: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255 ether XX:XX:XX:XX:XX:XX txqueuelen 1000 (Ethernet) --------------------
*** Bug 1009776 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug is still present as of fedora 25! Please reopen the bug. Chosing "Ignore" as the method under "IPv6 Settings" for some NetworkManager connection produces a /etc/sysconfig/network-scripts/ifcfg-$IF with MODE=Managed and IPV6INIT=no but apparently has no effect at all. How hard can it be to fix this bug?
You can certainly fix this if you're using the old network-scripts. e.g. service network start (as opposed to systemctl start NetworkManager) just edit the file /etc/sysconfig/network-scripts/ifup-ipv6 Look for a section like this # Test whether IPv6 configuration is disabled for this interface [[ "$IPV6INIT" = [nN0]* ]] && exit 0 and replace that second line with these four lines... if [[ "$IPV6INIT" = [nN0]* ]] ; then echo 1 > /proc/sys/net/ipv6/conf/$DEVICE/disable_ipv6 exit 0 fi As for a fix for NetworkManager itself, after have a short look at the code and a bit of googling, I suspect this fault is actually with NetworkManager itself and not the redhat plugin. SLAAC configuration is done by the kernel and I suspect that NetworkManager is not disabling this behaviour. I was able to find HOWTO's for ArchLinux and Ubuntu which suggest using sysctl.conf to disable the kernels AUTOCONF. I see sections of code in NM which uses sysctl to disable the "accept_ra" when doing shutdown cleanups, but not for startup. I only had a brief look, so I could be wrong. I'd suggest taking this up with the upstream package maintainers. https://wiki.gnome.org/action/show/Projects/NetworkManager There is a good write up here too. http://ask.xmodulo.com/disable-ipv6-linux.html
"just edit the file /etc/sysconfig/network-scripts/ifup-ipv6" is by all respect a nonsense recommendation [harry@srv-rhsoft:~]$ rpm -q --file /etc/sysconfig/network-scripts/ifup-ipv6 initscripts-9.69-1.fc25.x86_64 guess what happens when the initscripts package becomes an update...
Created attachment 1302571 [details] /etc/NetworkManager/dispatcher.d/01-ipv6init Solution for NetworkManager Save the attached file as /etc/NetworkManager/dispatcher.d/01-ipv6init make it executable e.g. # chmod +x /etc/NetworkManager/dispatcher.d/01-ipv6init # restorecon /etc/NetworkManager/dispatcher.d/01-ipv6init It looks for NETWORKING_IPV6=no in /etc/sysconfig/network Also looks in /etc/sysconfig/networking-scripts/ifcfg-DEVICE for IPV6INIT=no and takes action to disable ipv6 on that DEVICE or globally if set.
This may also be relevant https://bugzilla.redhat.com/show_bug.cgi?id=1402555
Another relevant bug (or feature request) with gnome https://bugzilla.gnome.org/show_bug.cgi?id=682932 It appears that this bug is more to do with NetworkManager itself not having the feature to disable IPv6, it only has method=ignore (which means don't enable and don't disable).