Re: IPv6 autoconf/accept_ra default values - revisited

[Brian Haley <brian.haley@hp.com>]

Hi Kolbjorn,

Kolbjørn Barmen wrote:
> Cheers, remember me? :)
> 
> Regarding the autoconf parameter for the ipv6 module, was it not the
> intention that it should cover accept_ra as well?

It wasn't my intention, but I see how there's a bit of a mess here.

> I ask since I have used this paramater in the belief that it also did
> cover accept_ra, however on a couple of systems that are using bridge
> interface, I noticed that they "fall off" ipv6-wise, unless I explisitly
> ping them.
> 
> So I finally got around to find out what was going on, and to my surprise
> I see that they both have autoconfigured routes on eth0 (using link local)
> that they want to use instead of what I have statically configured for br0.

So I re-read RFCs 4861 and 4862 to see what the recommendation was here, and
found this paragraph which I think explains what the Linux kernel is doing:

[RFC 4861, Section 6.3.4]

      Note: Implementations can choose to process the on-link aspects of
      the prefixes separately from the stateless address
      autoconfiguration aspects of the prefixes by, e.g., passing a copy
      of each valid Router Advertisement message to both an "on-link"
      and an "addrconf" function.  Each function can then operate
      independently on the prefixes that have the appropriate flag set.

I'm guessing whoever wrote this code followed this suggestion for a reason.

For a test, can you turn-off accept_ra/accept_ra_defrtr/accept_ra_pinfo
and see if you can get the behavior you want?

> So, could "autoconf" also please turn off accept_ra?
> Or, if you like, add another parameter for it :P

There are other things in the RA that are useful, like MTU, turning-off
accept_ra would miss that, I think maybe ignoring the prefix info options
when autoconf=0 might be what you want.  I guess we could do another
module parameter if we had to.

> I tried using disable_ipv6 in all kinds of tricky ways to get what I want,
> but it's close to impossble, with interfaces coming and going in the
> bridge I always end up with autoconfigured addresses where I dont want
> them, strange routing issues etc. I cannot just add entries in sysctl.conf
> for bridge interfaces, since the bridge interfaces (and others for that
> matter) are not there when sysctl is run on bootup.

If you set "default.disable_ipv6=1" that should be inherited when a new
interface is configured.

> And the entire "all" vs. "default" still confuses me.
> 
> * "default" is supposed to cover _all future_ interfaces?
> * "all" is supposed to cover _all existing_ interfaces, and change them?
>   If not, then what is its function?

Yes, "default" covers future interfaces, but "all" behavior depends on
the option - "all->forwarding" and "all->disable_ipv6" will reset interfaces
and "all->proxy_ndp" affects all interfaces.  Other than that, the "all"
variables seem not to be used.  Making it more like the IPv4 code sooner
than later might be a good thing, maybe others have thoughts on that?

> And lastly - all this would be a non-issue if the defaults values were so
> that all autoconf/accept_ra were 0 - it's _so_ easy to turn on, but
> incredibly complicated to turn off. The harder it is to make sense out of
> things like this, the harder it is to have people start with IPv6.

I don't think that default is going to change since it would effectively
disable IPv6 for 99.9% of users, my grandmother would wonder why nothing works
any more and not know how to fix it :)  In other words, people not doing
autoconfiguration are in the minority, and might need to change all these
default settings, but we should make it easier to use.

Hope that helps.

-Brian