Message-ID: <22047.1235685397@death.nxdomain.ibm.com>
Date:	Thu, 26 Feb 2009 13:56:37 -0800
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Vlad Yasevich <vladislav.yasevich@...com>
cc:	Brian Haley <brian.haley@...com>,
	David Miller <davem@...emloft.net>, arvidjaar@...l.ru,
	chuck.lever@...cle.com, tytso@....edu, Valdis.Kletnieks@...edu,
	rjw@...k.pl, netdev@...r.kernel.org,
	bonding-devel@...ts.sourceforge.net, jamagallon@....com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] bonding: move IPv6 support into a separate kernel module

Vlad Yasevich <vladislav.yasevich@...com> wrote:

>Jay Vosburgh wrote:
[...]
>> Brian Haley <brian.haley@...com> wrote:
[...]
>>> I think changing ipv6 to support a disable_ipv6 module parameter like Vlad
>>> suggested would work, as long as we're not worried about someone opening
>>> an AF_INET6 socket - even if they do they won't get anywhere.  That, along
>>> with the patch below to actually not add the addresses, would work (sorry
>>> in advance for using an attachment).  I'll get started on that...
>> 
>> 	I agree that it would work, and could even be set up such that
>> opening sockets doesn't work, either (if ipv6 never registered via
>> sock_register, for example).  I'm sticking some on the opening sockets
>> failure behavior because it's the current behavior if ipv6 is aliased
>> out.  It just seems like a logical place for the permission denial to
>> occur, rather than later, and is consistent with what happens if ipv6
>> isn't loaded at all or is not configured in the kernel.
>> 
>> 	I still tend to like the bitmask to disable address family
>> gizmo.  It's not specific to one particular protocol (although it would
>> likely need a check in the protocols for things like addrconf).  As
>> somebody pointed out, there are likely to be (if not now, then
>> relatively soon) users somewhere that want to turn off ipv4 and run ipv6
>> only.
>
>Yes.  The bitmask to disable certain family can be useful, but it's orthogonal
>the issue of IPv6 support.  As you said, it can be used to disable
>any address family that user wishes.  The slight issue with this might
>be, should the settings affect already create sockets?

	Unless I'm misunderstanding your position, I don't think the
bitmask method is really orthogonal, since it can be used to disable
IPv6 (AF_INET6).  More on that below.

	I'd also argue that such a method should affect the entirety of
the protocol family, so extant sockets would cease to function.  That
may or may not be practical or necessary.

>I guess it comes down how many levels of control to do we want to provide.
>Things that have been suggested so far:
>	1) Global on/off switch (i.e module parameter)
>	2) Per interface on/off switch (currently exists, but has bugs).
>	3) Socket on/off switch (i.e blocker bitmask)
>
>I think numbers 1 and 2 turn off the IPv6 protocol on the wire, while number
>3 turns off the interface to the user.  The two can be done independent.

	Yes, I think this reaches the crux of the matter: disabling the
protocol vs. disabling the interface.  Any of the knobs (1 - 3, above)
can potentially do either one or both of these.

	My feeling is that, for consistency of behavior, whatever knob
is turned should act like ipv6 was never loaded.  That might or might
not be the right answer in the grand scheme of things, but it's the
expected behavior of the users currently aliasing out ipv6 in
/etc/modprobe.conf.

	When The Knob (however it ends up being done) is turned, why
should the "ipv6 off" behavior be any different than what is currently
observed when aliasing out ipv6 or compiling a kernel without
CONFIG_IPV6?

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists