netdev - Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in 29-rc5

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Feb 2009 13:29:01 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	John Dykstra <john.dykstra1@...il.com>
Cc:	Brian Haley <brian.haley@...com>, jamagallon@....com,
	Valdis.Kletnieks@...edu,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	bonding-devel@...ts.sourceforge.net, rjw@...k.pl,
	Vlad Yasevich <vladislav.yasevich@...com>,
	Chuck Lever <chuck.lever@...cle.com>,
	Theodore Tso <tytso@....edu>, arvidjaar@...l.ru,
	David Miller <davem@...emloft.net>
Subject: Re: [Bonding-devel] 2.6.29 regression? Bonding tied to IPV6 in
 29-rc5

On Wed, 18 Feb 2009 21:21:07 +0000
John Dykstra <john.dykstra1@...il.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html