diff mbox

2.6.29 regression? Bonding tied to IPV6 in 29-rc5

Message ID 499C681A.6000008@hp.com
State RFC, archived
Delegated to: David Miller
Headers show

Commit Message

Brian Haley Feb. 18, 2009, 7:57 p.m. UTC
Vlad Yasevich wrote:
> 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>

Comments

John Dykstra Feb. 18, 2009, 9:21 p.m. UTC | #1
On Wed, 2009-02-18 at 14:57 -0500, Brian Haley wrote: 
> Vlad Yasevich wrote:
> > 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.  
> 
> There does seem to be a sysctl for it, just doesn't seem to work.

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
stephen hemminger Feb. 18, 2009, 9:29 p.m. UTC | #2
On Wed, 18 Feb 2009 21:21:07 +0000
John Dykstra <john.dykstra1@gmail.com> wrote:

> On Wed, 2009-02-18 at 14:57 -0500, Brian Haley wrote: 
> > Vlad Yasevich wrote:
> > > 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.  
> > 
> > There does seem to be a sysctl for it, just doesn't seem to work.
> 
> 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

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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Herbert Xu Feb. 19, 2009, 1:32 p.m. UTC | #3
Brian Haley <brian.haley@hp.com> wrote:
> 
> There does seem to be a sysctl for it, just doesn't seem to work. 

OK we should definitely fix that.

Thanks,
diff mbox

Patch

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 03e2a1a..9bc761f 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -603,6 +603,11 @@  ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr, int pfxlen,
 		goto out2;
 	}
 
+	if (idev->cnf.disable_ipv6) {
+		err = -EPERM;
+		goto out2;
+	}
+
 	write_lock(&addrconf_hash_lock);
 
 	/* Ignore adding duplicate addresses on an interface */