Subject: Re: PROBLEM: IPv6 autoconf/accept_ra default values

From: Brian Haley <[email-masked]>
Date: Fri, 20 Mar 2009 14:02:35 -0400

Kolbjørn Barmen wrote:
> I personally really dont care what is default as long as I have a _very
> easy_ way to turn it off, kernel module paramters and boot parameters -
> great! If the rest of the world has decided they want to fight this
> manually by default, fine by me :)

I'll work on the module parameters Yoshifuji mentioned, the "harder" version
since to me it seems more useful.  Since it's of interest to you can you give me
some input?  Are the two parameters he described for this going to be good
enough for you?  I was thinking of also adding a "default" keyword to control
net.ipv6.conf.default.*, for example:

	disable_ipv6=all,default,eth0,eth1
	autoconf=all,default,eth2,eth3

This is because "default" is what's inherited by all the ethX values, "all" is
the big hammer.

And also adding an "enable_ipv6" one:

	enable_ipv6=lo,eth4,eth5

This would let you do:

	disable_ipv6=default
	enable_ipv6=lo,eth0

Which saves you from listing many interfaces:

	disable_ipv6=eth1,eth2,eth3,eth4....

Of course I could be over-thinking this and the simple solution could work just
fine:

	disable_ipv6=1
	autoconf=0

Then just let you put things in sysctl.conf to enable what you want.  I'll play
with that first to see if it's enough.

I'd rather get this right the first time...

> How about the behaviour that I described:
> 
>     root:~# sysctl net.ipv6.conf.all.accept_ra 
>     net.ipv6.conf.all.accept_ra = 1 
>     root:~# sysctl -w net.ipv6.conf.all.accept_ra=0 
>     net.ipv6.conf.all.accept_ra = 0 
>     root:~# sysctl net.ipv6.conf.eth0.accept_ra 
>     net.ipv6.conf.all.accept_ra = 1  
> 
> Is this intended behaviour or not? Bug or (mis)feature?

I *think* that's intended, at least it's one of the ways IPv6 differs from IPv4
- setting "all" doesn't reset to individual nic settings.  But the code in
ndisc_router_discovery() should probably check the "all" flag and drop the RA.
The other "all" sysctl's should behave the same, so someone needs to take a
deeper look.

-Brian