Bug 169809

Summary: ifup-ipv6 doesn't set sysctl net.ipv6.conf.$DEVICE.autoconf
Product: [Fedora] Fedora Reporter: H. Peter Anvin <hpa>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 12CC: cra, herrold, pb, pekkas, rvokal, triage
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-05 07:18:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description H. Peter Anvin 2005-10-03 21:22:05 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
I have a machine on an IPv6 subnet which uses a /96 prefix, making it incompatible with the autoconf mechanism.  I have in my network config

IPV6_AUTOCONF=no

... but ifup-ipv6 never sets the associated sysctl, so this has no effect, resulting in dmesg spewage.


Version-Release number of selected component (if applicable):
initscripts-8.11.1-1

How reproducible:
Always

Steps to Reproduce:
1. Set IPV6_AUTOCONF=no in ifcfg-eth*
2. /etc/init.d/network restart
3. cat /proc/sys/net/ipv6/conf/*/autoconf
  

Actual Results:  1


Expected Results:  0


Additional info:

Comment 1 Peter Bieringer 2005-10-03 22:09:17 UTC
@Pekka:

Currently, only following values are set:

ipv6_exec_sysctl -w net.ipv6.conf.$DEVICE.forwarding=$ipv6_local_forwarding
ipv6_exec_sysctl -w net.ipv6.conf.$DEVICE.accept_ra=$ipv6_local_auto
ipv6_exec_sysctl -w net.ipv6.conf.$DEVICE.accept_redirects=$ipv6_local_auto 

I don't know whether bug reporter knows, what "autoconf" really means:

doc tells:

autoconf - BOOLEAN
        Autoconfigure addresses using Prefix Information in Router
        Advertisements.

        Functional default: enabled if accept_ra is enabled.
                            disabled if accept_ra is disabled.

â¬bug reporter:
What is your real problem? If you want to avoid the autocreation of the /64
address, you have to manually remove it afterwards, I do not know any mechanism
which prevents creation of /64 link-local address *before* interface is coming up.


Comment 2 Pekka Savola 2005-10-05 10:23:43 UTC
I think the reporter's problem is that if he configures address with a /96
prefix, I think kernel prints out error messages that autoconfiguring addresses
using that prefix length failed (I haven't checked this out myself).


The problem here has been seen in the past: you cannot disable "accept_ra"
before the interface is brought up (because the sysctl branch doesn't exist, and
accept_ra values are *NOT* taken from net.ipv6.conf.default branch), and after
you've brought the interface up, the damage is already done.

Compare this problem to the one where you want to manually configure an IPv6
address and NOT learn another address if a router were to advertise a prefix on
the link.. I think the symptoms are the same.







Comment 3 H. Peter Anvin 2005-10-06 20:33:18 UTC
That characterization pretty much sums things up.


Comment 4 Pekka Savola 2005-10-07 05:14:30 UTC
You may also want to take a look at the thread:
http://marc.theaimsgroup.com/?t=112282648300001&r=1&w=2

Another similar case:
http://marc.theaimsgroup.com/?l=linux-netdev&m=109592784618933&w=2

As for the fixes, there are two things that could be looked at:

 (1) verifying whether this works if scripts were to (early enough, so that
ethernet drivers etc. haven't been loaded yet) change conf.all.accept_ra (and/or
default.accept_ra) to disabled.  If this would work, changes could possibly be
done there if /etc/init.d/network can do it early enough.

 (2) look at whether the all/default kernel behaviour needs to be made saner.



Comment 5 Bug Zapper 2008-04-03 16:25:09 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

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

The process we're 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.

Comment 6 Pekka Savola 2008-04-04 10:41:13 UTC
This problem still persists in Fedora 8.

I looked into this and the problem is that accept_ra toggle is changed in
ifup-ipv6.  However, ifup-ipv6 is called after IPv4 address assignment, DHCPv4
etc.  This is too late as you will already have obtained an IPv6 address or
gotten the kernel warning message.

This problem could be fixed by setting accept_ra etc. _before_ the link is up. 
The first place this happens appears to be in ifup when VLANs are created.  So,
I suppose these IPv6 settings would need to be added before that happens.

You can avoid the problem by putting IPV6_AUTOCONF=no into
/etc/sysconfig/network but that disables autoconf on every interface.

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

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

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

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

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

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

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

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

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

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

Comment 9 R P Herrold 2010-09-24 16:52:18 UTC
This is still not closed through time and an autoclose -- is it still a future feature?

Comment 10 Bug Zapper 2010-11-04 12:18:19 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 Bug Zapper 2010-12-05 07:18:44 UTC
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.