lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 20 Jan 2010 11:55:57 -0500 From: Brian Haley <brian.haley@...com> To: Kolbjørn Barmen <linux@...la.no> CC: Vlad Yasevich <vladislav.yasevich@...com>, davem@...emloft.net, yoshfuji@...ux-ipv6.org, netdev@...r.kernel.org Subject: Re: IPv6 autoconf/accept_ra default values - revisited 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists