Disabling IPv6 autoconfiguration in sysctl.conf doesn't affect boot process

Bug #997605 reported by Gabriele Tozzi on 2012-05-10
86
This bug affects 18 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned

Bug Description

When you put the following lines in sysctl.conf

net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0

the expeced result is to disable IPv6 autoconfiguration at bootup, but, actually, it does nothing, because sysctl.conf network settings are applied after network has been started.

So what happens:
1. Network interfaces are started by /etc/init.d/networking
1a. IPv6 uses autocnfiguratin, because it is enabled at this point
2. Sysctl.conf settings are applied by /etc/init/procps.conf

I don't know if there is an easy solution, because inverting order things are called could break something else.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in netbase (Ubuntu):
status: New → Confirmed
Stéphane Graber (stgraber) wrote :

I certainly agree with the problem and we've been hit by some other weirder instances of it (privacy extensions).

This is ultimately a kernel bug where "all" and "default" mean the same thing for sys/net/ipv6/conf entries.
This is obviously wrong, "all" should be updating "all" interfaces and "default" should be applying only to new ones. However the network subsystem maintainer seems to disagree based on the feedback to our patch last cycle.

Anyway, this bug isn't related to netbase or to any other userspace networking packages but is an actual kernel bug, once fixed in the kernel, sysctl will work as expected.

Re-assigning to the linux kernel and adding bot-stop-nagging to prevent their bot from spamming this report.

affects: netbase (Ubuntu) → linux (Ubuntu)
tags: added: bot-stop-nagging
Joseph Salisbury (jsalisbury) wrote :

@Gabriele

Just to confirm, you are seeing this behavior on Quantal?

Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: quantal
tags: added: kernel-da-key
removed: quantal
Gabriele Tozzi (gabriele-tozzi) wrote :

Sorry for late reply,

yes, i can confirm it for Quantal.

Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.5kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. Please only remove that one tag and leave the other tags. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc1-quantal/

tags: added: needs-upstream-testing quantal
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Gabriele Tozzi (gabriele-tozzi) wrote :

It looks like this has been solved with kernel
3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Will try to do more tests

Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
Copernica B.V. (operations) wrote :

This is still an issue in 3.2.0-40-generic #64-Ubuntu SMP Mon Mar 25 21:22:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Changed in linux (Ubuntu):
status: Expired → Confirmed
Gabriele Tozzi (gabriele-tozzi) wrote :

I confirm it is not solved. It is still an issue after update to raring 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:35:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

tags: added: needs-kernel-logs
tags: added: raring

Gabriele Tozzi, would the following placed in sysctl.conf achieve the intended objective:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Stéphane Graber, could you please provide a URL to the upstream maintainer discussion you referred to in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997605/comments/2 ?

Changed in linux (Ubuntu):
status: Confirmed → Incomplete

Christopher M. Penalver, no: the commands above completely disables all my IPv6 addresses.

I need to keep manually assigned ones.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Thiago Martins (martinx) wrote :

Guys,

This problem still persist on Ubuntu 14.04.1, as follows:

https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1345847

Dmitry (trtrmitya) wrote :

This problem still persists on Ubuntu 15.10.

dino99 (9d9) on 2015-12-23
tags: added: wily
removed: quantal raring

Is this going to be fixed in 16.04?

nand (p-ucuntu-t) wrote :

Still not fixed in 16.04. On a fresh boot I get an autoconfigured IPv6 address despite net.ipv6.conf.all.autoconf being set to 0 in sysctl.conf.

(Only solution for me seems to be manually setting the interface to static in /etc/network/interfaces - but I have to do this on every single VM I create, which is sort of annoying)

Ruben Portier (rubenportier) wrote :

I'm having a similar issue. I have disabled Route Advertisement (accept_ra=0) in sysctl.conf file, but at boot I still get a default IPv6 route to my router with an RA flag, which means it was assigned using a ra.

The default route expires soon after the boot, as it does not get renewed. This shows that the accept_ra=0 is actually working. It's not accepting route advertisements anymore, so this route does not get renewed. However, why do I still get the first route over RA? It's bugging my interface, as it has a gateway rule, but is not able to set it as there is already a default route assigned by a RA. I have no idea why it's even possible to get a route automatically before the actual interface is up (it's trying to assign the gateway I put in the interfaces file, but I get an error: File exists.).

Only solution so far is removing the gateway line, causing the default route to appear automatically by RA and setting accept_ra to 1.

Still affect Xenial here too.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers