login
Search
=46orward to bonding and netdev If IPv6 is disable in kernel config bonding loads. But I think it is=20 regression, it should be possible to disable IPv6 if not required.
This hard dependency was apparently introduced by this commit:
commit 305d552accae6afb859c493ebc7d98ca3371dae2
Author: Brian Haley <brian.haley@hp.com>
Date: Tue Nov 4 17:51:14 2008 -0800
bonding: send IPv6 neighbor advertisement on failover
I'm not really sure how to work around this. If bonding is compiled with CONFIG_IPV6, then the IPv6 support is compiled in, and bonding will need the ipv6 module loaded to resolve its symbols. The simple answer (don't turn on CONFIG_IPV6) isn't really useful for the common case of distro kernels, which will generally have CONFIG_IPV6 enabled. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com --
From: Jay Vosburgh <fubar@us.ibm.com> This whole "disable ipv6 module load in /etc/modules.conf" was bound to eventually cause problems like this. There are so many chicken-and-egg issues wrt. this it isn't even funny, for example: 1) If we provide a sysctl which is a bitmask of protocols to disallow registering, we have the same problem we have now since ipv6 won't be able to load when the sock_register() fails. 2) If we add some ipv6 sysctl that says "don't do ipv6" so the module can load yet not automatically add link local ipv6 addresses to interfaces and solicit for routers on the network, the sysctl can't be set until the module is loaded. And this bonding stuff in particular wants to get into the neighbour discovery state of the ipv6 module. Therefore it's not like we can split out a few functions into some kind of "ipv6_helpers.ko" kernel module to eliminate the problem either. --
I initially had bonding IPv6 support as a Kconfig option, but it was decided it would be cleaner if it just got built-in whenever CONFIG_IPV6 was set like SCTP, with the assumption you might want it. Is it a common configuration to not allow a module to load like you're doing in modprobe.conf? I don't know how hard it would be to rip this out into it's own bonding_ipv6.ko module, simply turning-off CONFIG_IPV6 seems better. -Brian --
I'm not sure either of those really helps. Distro kernels are built with CONFIG_IPV6 (and would have the CONFIG_BONDING_IPV6_DINGUS enabled as well), so the common case users would have it enabled, too. Putting the ipv6 bits into a different module might not help, either, because the "core" bonding code would still have the call to the ipv6 functions. Unless there's some magic way to somehow know at runtime whether or not the ipv6 module is loaded, and only try to resolve those symbols if ipv6 is loaded. That seems complicated. To answer your question, I have come across this (aliasing ipv6 to nothing in modprobe.conf to disable IPv6) from time to time, but didn't think of it when the NA code was added to bonding. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com --
This separate bonding_ipv6 module would have to register itself with the "core" one with a new proto_ops of some sort. Calls are made for the appropriate method, for example bond_ops->send_gratuitous(bond). We'd change the IPv4 code too. It's just a theory, does make things more So I guess I'll start hacking the above, unless someone has a better suggestion. -Brian --
I don't see any reason to change the IPv4 bits; there won't ever be a case of ipv4 not being loaded, and this would just add the complexity of a registration gizmo with no real benefit. A "bonding ipv6 ops" would be strictly a hack to deal with ipv6 module dependencies for cases when the kernel is built with CONFIG_IPV6 but the ipv6 module itself is prevented from loading. A registration gizmo doesn't need to be especially complicated; there's only three functions in bond_ipv6.c that are called from the bonding core: bond_send_unsolicited_na, and the ipv6 notifier register / unregister. The bonding_ipv6 module can simply be bond_ipv6.c, which calls some exported "hey, bond_send_unsol_na is here" thing in the bonding core during init and another "hey, send_unsol_na is gone" during unload. The bonding_ipv6 module can do its own notifier registration Well, I think this is pretty heinous, but I don't have a better idea at the moment. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com --
IMO, a better solution could be to add a dummy ipv6 module that returns -EOPNOTSOPP or appropriate for most calls. --
What about aliasing ipv6 to a dummy module "dummy-ipv6-for-bonding" that
only provide the required symbols and do (close to) nothing ?
Just my two cents.
Nicolas.
--
From: Jay Vosburgh <fubar@us.ibm.com> This is a non-starter, as I described in one of my other replies. --
That's not an option for distro kernels ... -- Thomas --
From: Brian Haley <brian.haley@hp.com> It's unfortunately how users get told to turn off ipv6. There were some back-compat issues with how GLIBC emitted DNS requests a few months ago that required turning off ipv6 completely otherwise DNS requests would timeout. Sticking an ipv6.ko module load disable into /etc/modprobe.conf was the only tenable workaround. --
From: Andrey Borzenkov <arvidjaar@mail.ru> Don't configure ipv6 into your kernel, really. There is no other way to handle this. If we want to support IPV6 layer things in the bonding driver, it is going to call helper functions in the ipv6 module and therefore must be able to load it and use functions in it. --
What does a poor corporate user do if they're running a distro kernel that was built with CONFIG_IPV6, but local security policy says "Disable IPv6 because we don't do it yet, or because it breaks mission-critical software package XYZ?" There's a *lot* of people who implement that by the "block the ipv6 module from loading" trick. And building a kernel that doesn't include IPv6 may not be feasible due to vendor certification issues... Heck, *I*'m almost in that boat - probably need to use bonded ethernet on some servers because we can't get 10GigE, but the software used in the project the servers were bought for blows chunks if it gets a whiff of an IPv6 address. Ended up spending 3 weeks doing a massive kludgery of one sort in DNS for the rest of the world, and equally massive lying in /etc/hosts for the hosts... (Don't ask - it was long and ugly, and just disabling the module would have saved me about 2.95 weeks of work, so I know where those people are coming from...)
From: Valdis.Kletnieks@vt.edu Well, first of all, if you keep trying to push the box into the round hole you get what you ask for :-) Next, if it's just an issue of IPV6 traffic, install a packet scheduler rule that rejects all packets with ethernet proto ETH_P_IPV6 If openning up ipv6 sockets is problematic, that can be blocked using the security layer, which your super-duper distro kernel is guarenteed to have enabled. :-) I'm sure there is someone who has legacy problems with ipv4 and that can't be disabled, and somehow people cope. Amazing. --
> Next, if it's just an issue of IPV6 traffic, install a packet > scheduler rule that rejects all packets with ethernet proto > ETH_P_IPV6 > > If openning up ipv6 sockets is problematic, that can be blocked > using the security layer, which your super-duper distro kernel > is guarenteed to have enabled. :-) This reminds me of a related issue that some users have run into with IP-over-InfiniBand -- the IPoIB module also depends on ipv6 symbols if ipv6 is enabled, so when ipoib is loaded then ipv6 gets loaded. And this causes a problem from some people in the IB case because assigning an ipv6 address to the ipoib interface actually consumes some network resources (the number of multicast groups that the network supports may be limited and having a solicited node multicast group for each node may use them all up). Anyway, this leads to the folowing question: is there a way to prevent a link-local ipv6 address from being configured automatically for the ipoib interface? Thanks, Roland --
The reality is that there are far more people who have legacy problems with ipv6 than ipv4 (which has been around and in active use for about 3 decades, after all), whereas ipv6 has been around and largely ignored for about a decade. :-/ I'll admit that I ran into some wierd sh*t problems with some open source software or another failing mysteriously when IPv6 was enabled, and I dealt with it by simply disabling IPv6 (yeah, I blocked the module). I was in a hurry, and it just didn't work, and I had better thing to do than to spend time trying to debug why the presense of an IPv6 enabled interface caused programs to misbehave in random ways. I think I can pretty much guarantee that distro users will be clamoring for a quick and easy way to block ipv6, and it's in our interest to document the recomended way to block it that doesn't cause weird problems with bonding, etc. - Ted --
Here's another "me too". Kernel RPC support also has this problem. We hit it just a couple of weeks ago now that we have IPv6 enabled NFS in prototype. If PF_INET6 listener creation fails (eg. because ipv6.ko is blacklisted), our workaround right now is to retry the listener socket creation with PF_INET. There are plenty of somewhat rare corner cases that make A better solution would be to design kernel and user space networking to handle this use case, instead of providing a workaround. From the variety of comments I've heard, this use case is pretty common. Considering the government mandates requiring IPv6 support (and the advertisements by Linux vendors claiming IPv6 support), IPv6 needs to become a first-class citizen in Linux in fairly short order. It still feels a little piecemeal to me to be called "production ready." -- Chuck Lever chuck[dot]lever[at]oracle[dot]com --
And another "me too" for SCTP. When IPv6 is turned on in the kernel config file, we include the necessary pieces into the SCTP module and sctp.ko will not load if ipv6.ko is blacklisted. Having worked in other environments where ipv6 has to be explicitly enabled per interface, I've thought that this level of control was always missing from linux. Being able to configure only the interface that users want seems like a good thing to have. Would a module parameter that disables ipv6 or at least addrconf be enough of a solution? --
There does seem to be a sysctl for it, just doesn't seem to work. Possible patch below. This actually brings up the issue that the "all" ipv6 sysctl, for example net.ipv6.conf.all.disable_ipv6, doesn't actually do anything (at least it didn't seem to for me). Maybe it's time to fix that too to be like IPv4, things like IN_DEV_RPFILTER() and friends aren't looking so bad... I tested this patch on lo and a few Ethernet devices and saw no IPv6 addresses. Don't know if EPERM is the right errno since we don't know if the user set this or DAD failed. The disable_ipv6 knob was meant to be used for the kernel to disable IPv6 on an interface when DAD failed for the link-local address based on the MAC, but we should also be able to administratively disable it on an interface, or the entire system. This patch fixes the per-interface problem. Signed-off-by: Brian Haley <brian.haley@hp.com>
While this sysctl is definitely useful, I don't think it meets the needs of those users and distributions that are currently blacklisting the ipv6 module. Even if you disable IPv6 on all interfaces, apps will still be able to create AF_INET6 sockets, and thus some apps will break or do inappropriate things because there isn't real IPv6 connectivity. I've tried to put together an RFC patch that turned off all externally-visible IPv6 behavior that could break something, but I keep running into distasteful choices. The current default behavior must be preserved--if you drop this patch into an existing distribution, the IPv6 stack must come up the way it always has. Thus the knob (let's call it ip6_disable) must default false. It seems desirable to make this a per-net-namespace knob. But that means each new net will be initialized before the distribution has a chance to disable the IPv6 part. This will lead to neighbor solicits going out for link-local addresses, which some people can't accept. The only alternative I can think of is to make it a module parameter, which would leverage people's current habit to disable IPv6 via the module configuration files, but doesn't fit well into a virtualized world. Exactly what to disable is unclear too. Turning off neighbor and router solicits, responding to same, etc.--almost certainly. Refusing to create AF_INET6 sockets--definitely. Erroring on ioctl() and netlink API calls related to IPv6--probably. Hiding /proc entries for IPv6--I don't know. Ideally, once ip6_disable was set true, every API, /proc and /sys entries, etc. would look just like the ipv6 module was not loaded. But to do this, while still initializing most of the IPv6 code (so that those hooks from other modules won't do unexpected things) is very invasive. So it seems to me that the only practical solution is to live with blacklisting module ipv6 until the apps are fixed and sending IPv6 packets isn't considered a crime. -- John --
On Wed, 18 Feb 2009 21:21:07 +0000 There are also ipv6 purists who would like to see the same mechanism exist to force ipv6 only (no ipv4). So any long term solution should support both. --
OK we should definitely fix that. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
From: Vlad Yasevich <vladislav.yasevich@hp.com> We have it, it's just that (as others have stated) it doesn't prevent IPV6 sockets from being openned by applications. --
Is that what people really want to block? Or do they want to prevent the use of IPv6 in environments where IPv6 is not supported? If it's this case, then simply not configuring any IPv6 addresses on the system interfaces will make it seem as if IPv6 is not there. Without IPv6 addresses, AF_INET6 sockets are the same as AF_INET. I really see no reason to block them. Any legacy apps that people might worry about don't use this type socket any way. One doesn't even need to worry about processing IPv6 traffic, since the system would never join any IPv6 multicast groups and thus would never see 99% of the traffic. -vlad --
We already have a way: echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6 Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
We have the same issue with the qeth_l3 driver (it requires IPv6 symbols). Distributors compile with IPv6 but some customes want to disable IPv6 without building a custom kernel. If there would be a generic solution to address this kind of runtime IPv6 dependencies this would be creat. --
Just for clarification, is this a run-time (module load-time) error but not a build error? -- ~Randy --
Yes, this is run-time error. If IPV6 is disabled during kernel build,=20 everything works; but the error was seen on distribution kernel which=20 includes IPV6.
Yes, module load error, but not a build error. The build with CONFIG_IPV6 is fine, and bonding loads fine as long as ipv6 is loaded. The issue arises when the ipv6 module is prevented from loading; in that case, bonding cannot load because it now requires functionality from ipv6. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com --
