Bug 982740 - IPV6INIT=no does not disable IPv6
IPV6INIT=no does not disable IPv6
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
: 1009776 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-09 13:46 EDT by Christian Schmitt
Modified: 2017-07-22 01:12 EDT (History)
27 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 496444
Environment:
Last Closed: 2015-02-17 11:01:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/NetworkManager/dispatcher.d/01-ipv6init (342 bytes, application/x-shellscript)
2017-07-21 20:14 EDT, David Beveridge
no flags Details


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

  None (edit)
Description Christian Schmitt 2013-07-09 13:46:38 EDT
+++ 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
Comment 1 Pavel Šimerda (pavlix) 2013-07-09 18:16:02 EDT
The other bug was moved to F19. Duplicates?
Comment 2 joshua 2013-07-09 18:20:33 EDT
I'm sorry, maybe I shouldn't have moved this to F19.  I apologize if this was the wrong thing to do.
Comment 3 Pavel Šimerda (pavlix) 2013-07-09 18:31:15 EDT
(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.
Comment 4 Christian Schmitt 2013-07-10 02:16:31 EDT
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.
Comment 5 Pavel Šimerda (pavlix) 2013-07-10 04:27:31 EDT
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.
Comment 6 Christian Schmitt 2013-07-10 04:52:20 EDT
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.
Comment 7 Pavel Šimerda (pavlix) 2013-07-10 05:26:47 EDT
(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.
Comment 8 Fernando Lozano 2013-07-12 13:46:48 EDT
+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.
Comment 9 Fernando Lozano 2013-07-12 13:48:08 EDT
I meant; making IPV6INIT=no the default.
Comment 10 Christian Schmitt 2013-07-12 15:30:38 EDT
(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.
Comment 11 Fernando Lozano 2013-07-12 17:35:10 EDT
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).
Comment 12 Harald Reindl 2013-07-12 17:36:31 EDT
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
Comment 13 David Beveridge 2013-07-12 19:22:25 EDT
(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
Comment 14 Harald Reindl 2013-07-12 19:38:34 EDT
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@thelounge.net>
Organisation: the lounge interactive design
An: Mailing-List systemd <systemd-devel@lists.freedesktop.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@thelounge.net>
Antwort an: Community support for Fedora users <users@lists.fedoraproject.org>
An: users@lists.fedoraproject.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
Comment 15 David Beveridge 2013-07-12 22:42:41 EDT
(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.
Comment 16 Harald Reindl 2013-07-13 04:02:28 EDT
> 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
Comment 17 Harald Reindl 2013-07-13 04:34:10 EDT
> 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
Comment 18 Christian Schmitt 2013-07-13 05:24:29 EDT
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.
Comment 19 Till Maas 2013-07-13 14:06:32 EDT
(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?
Comment 20 Harald Reindl 2013-07-13 14:36:55 EDT
*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
Comment 21 Till Maas 2013-07-13 14:55:47 EDT
(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.
Comment 22 Harald Reindl 2013-07-13 15:04:55 EDT
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
Comment 23 David Tonhofer 2013-12-25 08:39:55 EST
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)
--------------------
Comment 24 Charles R. Anderson 2014-04-15 09:28:10 EDT
*** Bug 1009776 has been marked as a duplicate of this bug. ***
Comment 25 Fedora End Of Life 2015-01-09 13:48:29 EST
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.
Comment 26 Fedora End Of Life 2015-02-17 11:01:31 EST
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.
Comment 27 Peter Backes 2017-07-13 03:18:22 EDT
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?
Comment 28 David Beveridge 2017-07-13 09:24:48 EDT
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
Comment 29 Harald Reindl 2017-07-13 09:26:42 EDT
"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...
Comment 30 David Beveridge 2017-07-21 20:14 EDT
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.
Comment 31 David Beveridge 2017-07-21 21:36:45 EDT
This may also be relevant
https://bugzilla.redhat.com/show_bug.cgi?id=1402555
Comment 32 David Beveridge 2017-07-22 01:12:20 EDT
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).

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