Bug 496444 - IPV6INIT=no does not disable IPv6
Summary: IPV6INIT=no does not disable IPv6
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 19
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 496557 (view as bug list)
Depends On:
Blocks: 516998 554389
TreeView+ depends on / blocked
 
Reported: 2009-04-19 09:10 UTC by Allen Kistler
Modified: 2014-03-17 03:18 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 554389 982740 (view as bug list)
Environment:
Last Closed: 2013-02-14 02:58:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
patch to ifup-ipv6 to disable IPv6 on a per-interface basis (845 bytes, patch)
2009-04-19 09:10 UTC, Allen Kistler
no flags Details | Diff
patch to ifcfg-lo to re-enable IPv6 on lo by default (183 bytes, patch)
2009-04-19 09:11 UTC, Allen Kistler
no flags Details | Diff
patch to ifup-ipv6 to disable IPv6 on a per-interface basis (1.27 KB, patch)
2009-06-19 07:36 UTC, Allen Kistler
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 753482 0 unspecified CLOSED wifi drops every 15 minutes (ip-config-unavailable) because of IPv6 RDNSS timeout 2021-02-22 00:41:40 UTC

Internal Links: 753482 982740

Description Allen Kistler 2009-04-19 09:10:24 UTC
Created attachment 340221 [details]
patch to ifup-ipv6 to disable IPv6 on a per-interface basis

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?

Comment 1 Allen Kistler 2009-04-19 09:11:39 UTC
Created attachment 340222 [details]
patch to ifcfg-lo to re-enable IPv6 on lo by default

Comment 2 Bill Nottingham 2009-04-21 22:16:43 UTC
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.

Comment 3 Allen Kistler 2009-04-22 00:43:02 UTC
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?

Comment 4 Bug Zapper 2009-06-09 14:06:36 UTC
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

Comment 5 Allen Kistler 2009-06-19 07:36:05 UTC
Created attachment 348618 [details]
patch to ifup-ipv6 to disable IPv6 on a per-interface basis

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.

Comment 6 Allen Kistler 2009-06-19 20:03:50 UTC
*** Bug 496557 has been marked as a duplicate of this bug. ***

Comment 7 Karel Volný 2010-01-11 15:50:18 UTC
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?

Comment 8 Bill Nottingham 2010-01-11 17:33:36 UTC
Any operation that depends on timeouts and then removing configuration isn't the right way to go about it.

Comment 9 David Ward 2010-09-24 19:28:56 UTC
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?

Comment 10 Bug Zapper 2010-11-04 11:20:21 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

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

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

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

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

Comment 11 David Ward 2010-11-04 14:04:36 UTC
@Bill: this bug affects Fedora 14.  Please update revision.  Also please respond to my earlier comment.

Comment 12 Bill Nottingham 2010-11-04 18:05:40 UTC
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.

Comment 13 Lukas Middendorf 2011-06-05 22:15:28 UTC
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)?

Comment 14 Aaron Sowry 2011-11-15 21:56:08 UTC
This bug is still present in F16. Please update version.

Comment 15 joshua 2012-02-09 20:29:27 UTC
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 !!

Comment 16 Pavel Šimerda (pavlix) 2012-03-09 21:41:46 UTC
Related bug 591630 also makes NetworkManager and thus Fedora not IPv6 ready.

Comment 17 Frank Ch. Eigler 2012-05-17 11:57:15 UTC
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.

Comment 18 Bill Nottingham 2012-05-17 14:42:26 UTC
Blanket systemwide disabling should be done with "ipv6.disable_ipv6=1" on the kernel commandline, period.

Comment 19 joshua 2012-05-17 16:57:33 UTC
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?

Comment 20 Bill Nottingham 2012-06-29 19:23:53 UTC
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.

Comment 21 joshua 2012-07-06 22:38:30 UTC
Excellent, thank you Bill!

Comment 22 Fedora End Of Life 2013-01-17 02:02:19 UTC
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

Comment 23 Fedora End Of Life 2013-02-14 02:58:34 UTC
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.

Comment 24 Christian Schmitt 2013-07-09 17:40:55 UTC
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.

Comment 25 David Tonhofer 2013-12-25 13:58:12 UTC
This bug has been cloned to bug#982740 on 2013-07-09

All visitors are advised to follow.


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