1) It can't be unloaded anyway. 2) If it's a module, it will be loaded at entirely random times, depending on what sockets a user opens, what functions they call, etc. For example, 'ping6 -?' loads IPv6. 3) Because of its modularity, users attempt to disable it in a variety of misguided ways, which may or may not work depending on when the module is loaded. 4) Because of its unpredictability of loading, setting IPv6 sysctls for an interface becomes complicated. It requires both the presence of the device, and the presence of the IPv6 module; however, these events aren't tied together.
By building in IPv6, we solve these issues, and make the behavior of the system more predictable. Plus, hey, it's the future.
To disable IPv6, boot with:
ipv6.disable_ipv6=1 (to disable IPv6 addresses on all interfaces)
or
ipv6.disable=1 (to render the entire module non-functional) --- config-generic | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/config-generic b/config-generic index 6b18a41..524e8fd 100644 --- a/config-generic +++ b/config-generic @@ -814,7 +814,7 @@ CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m CONFIG_IP_VS_PE_SIP=m
-CONFIG_IPV6=m +CONFIG_IPV6=y CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y
On Tue, Jun 07, 2011 at 01:28:30PM -0400, Bill Nottingham wrote:
- It can't be unloaded anyway.
- If it's a module, it will be loaded at entirely random times, depending
on what sockets a user opens, what functions they call, etc. For example, 'ping6 -?' loads IPv6. 3) Because of its modularity, users attempt to disable it in a variety of misguided ways, which may or may not work depending on when the module is loaded. 4) Because of its unpredictability of loading, setting IPv6 sysctls for an interface becomes complicated. It requires both the presence of the device, and the presence of the IPv6 module; however, these events aren't tied together.
5) It solves alot of dependency issues - i.e. bonding/bridging and several other modules are dependent on ipv6.ko, and people often try to disable ipv6 by blacklisting it, which inadvertently breaks the aforementinoed modules.
By building in IPv6, we solve these issues, and make the behavior of the system more predictable. Plus, hey, it's the future.
To disable IPv6, boot with:
ipv6.disable_ipv6=1 (to disable IPv6 addresses on all interfaces)
or
ipv6.disable=1 (to render the entire module non-functional)
Can we not promote this method, I'd really like to see it go away upstream, its a hack, the disable_ipv6 sysctl is really the way to go.
+1 to making ipv6 built-in though. Neil
config-generic | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/config-generic b/config-generic index 6b18a41..524e8fd 100644 --- a/config-generic +++ b/config-generic @@ -814,7 +814,7 @@ CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m CONFIG_IP_VS_PE_SIP=m
-CONFIG_IPV6=m +CONFIG_IPV6=y CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y -- 1.7.5.2
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Tom Callaway (tcallawa@redhat.com) said:
On 06/07/2011 01:51 PM, Neil Horman wrote:
+1 to making ipv6 built-in though.
Seems like a no-brainer to me. What are the cons? A slightly larger vmlinuz?
The module is ~460k on my x86_64 system, would be ~150k compressed. I would say that that is larger than most modules, but unlikely to actually break anything. I believe the biggest space concern we have for the kernel is ppc initramfs sizes for some ppc platforms; don't know of any concerns for primary architectures that would come into play here.
Is there some sort of performance impact?
I have not done benchmarks, but I'd be pretty shocked if it has more impact on networking performance than the default firewall does.
Bill
On Tue, Jun 7, 2011 at 2:11 PM, Bill Nottingham notting@redhat.com wrote:
Tom Callaway (tcallawa@redhat.com) said:
On 06/07/2011 01:51 PM, Neil Horman wrote:
+1 to making ipv6 built-in though.
Seems like a no-brainer to me. What are the cons? A slightly larger vmlinuz?
The module is ~460k on my x86_64 system, would be ~150k compressed. I would say that that is larger than most modules, but unlikely to actually break anything. I believe the biggest space concern we have for the kernel is ppc initramfs sizes for some ppc platforms; don't know of any concerns for primary architectures that would come into play here.
If the issue is the initramfs size then you're actually helping that issue by building it into the kernel vs. having it sitting in the initramfs as a module. Right?
Either way, 460k/150k isn't even a drop in the bucket towards the issues the F15 initramfs has in ppc/ppc64. It's on the order of 100MB too big, not 100k. That's why F16 with the hopefully reworked anaconda/initramfs setup is the first target for ppc to make it's comeback.
josh
On Tue, Jun 07, 2011 at 02:11:08PM -0400, Bill Nottingham wrote:
Is there some sort of performance impact?
I have not done benchmarks, but I'd be pretty shocked if it has more impact on networking performance than the default firewall does.
The disable parameters look like they'd be equivalent to not loading the module (modulo the extra memory usage of course).
+1 from me.
Dave
On Tue, 07 Jun 2011 13:56:00 -0400 Tom Callaway tcallawa@redhat.com wrote:
+1 to making ipv6 built-in though.
Seems like a no-brainer to me. What are the cons? A slightly larger vmlinuz? Is there some sort of performance impact?
Indeed it's the creeping bloat we're facing. IMHO IPv6 is not a problem on anything with half a gig or more. It takes half a meg give or take, or about 1%.
-- Pete
On 06/07/2011 02:42 PM, Pete Zaitcev wrote:
On Tue, 07 Jun 2011 13:56:00 -0400 Tom Callaway tcallawa@redhat.com wrote:
+1 to making ipv6 built-in though.
Seems like a no-brainer to me. What are the cons? A slightly larger vmlinuz? Is there some sort of performance impact?
Indeed it's the creeping bloat we're facing. IMHO IPv6 is not a problem on anything with half a gig or more. It takes half a meg give or take, or about 1%.
So, we can either be slightly fatter and guarantee that IPv6 works predictably, or stay thin and have erratic behavior. I still think this is a good decision.
As to the "creeping bloat", I think that may be worthwhile to consider separately.
~tom
P.S. Creeping Bloat is a great band name.
== Fedora Project
On Tue, 07 Jun 2011 14:45:35 -0400 Tom Callaway tcallawa@redhat.com wrote:
So, we can either be slightly fatter and guarantee that IPv6 works predictably, or stay thin and have erratic behavior. I still think this is a good decision.
My smallest box is 512 MB, so I'm ok. Also, it's a 32-bit Atom, so I use about 30%, 40% less RAM than Bill (hashes and tables got lots of pointers maybe?). Just wondering what Smolt says, what's the median RAM size? Will OLPC people hate us?
-- Pete
Hi,
On Tue, Jun 07 2011, Pete Zaitcev wrote:
So, we can either be slightly fatter and guarantee that IPv6 works predictably, or stay thin and have erratic behavior. I still think this is a good decision.
My smallest box is 512 MB, so I'm ok. Also, it's a 32-bit Atom, so I use about 30%, 40% less RAM than Bill (hashes and tables got lots of pointers maybe?). Just wondering what Smolt says, what's the median RAM size? Will OLPC people hate us?
We aren't using your kernel source at the moment (a few stubborn patches not upstreamed yet), and if we were we'd have a separate kernel config, so it's all good; +1 from OLPC.
Thanks,
- Chris.
kernel@lists.fedoraproject.org
-
Bill Nottingham -
Chris Ball -
Dave Jones -
Josh Boyer -
Neil Horman -
Pete Zaitcev -
Tom Callaway