| Message ID | 49A6ED6D.3090508@hp.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
On Feb 26, 2009, at Feb 26, 2009, 2:28 PM, Brian Haley wrote: > Jay Vosburgh wrote: >>>>> I've been fooling with the disable_ipv6 sysctl, and one issue is >>>>> that, at least on the distro I'm testing on (SLES), it's not >>>>> picked up >>>>> from /etc/sysctl.conf at boot time (presumably because ipv6 >>>>> isn't loaded >>>>> yet, although I haven't really checked). >>>> Correct, that's the problem. >>>> >>>> We could create a blocker bitmap. Two sysctls, "block_af" and >>>> "unblock_af". You write the AF_foo value for the protocol there >>>> and >>>> it sets or clears the assosciated bit in the internal blocker >>>> bitmap. >>>> >>>> Things like sys_socket() et al. key off of this. >>> I'm open to suggestions at this point in time, I just don't see >>> how this >>> will solve the bonding problem since it still wouldn't load, right? >> It would permit users to load ipv6 (thus allowing bonding to >> load), but prevent ipv6 from actually doing anything. (because >> sys_socket, e.g., won't open an ipv6 socket if block_af includes >> ipv6). > > Right, but it doesn't help someone that changed /etc/modprobe.conf > to have "install ipv6 /bin/true" - they'll have to stop doing that. > > 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. In this case, if IPV6ONLY is set on an AF_INET6 listener, it should still get AF_INET traffic, correct? > 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... > > -Brian > > > -- > > 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> > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > index f8f76d6..90f2a81 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 */
Chuck Lever wrote: > On Feb 26, 2009, at Feb 26, 2009, 2:28 PM, Brian Haley wrote: >> Jay Vosburgh wrote: >>>>>> I've been fooling with the disable_ipv6 sysctl, and one issue is >>>>>> that, at least on the distro I'm testing on (SLES), it's not >>>>>> picked up >>>>>> from /etc/sysctl.conf at boot time (presumably because ipv6 isn't >>>>>> loaded >>>>>> yet, although I haven't really checked). >>>>> Correct, that's the problem. >>>>> >>>>> We could create a blocker bitmap. Two sysctls, "block_af" and >>>>> "unblock_af". You write the AF_foo value for the protocol there and >>>>> it sets or clears the assosciated bit in the internal blocker bitmap. >>>>> >>>>> Things like sys_socket() et al. key off of this. >>>> I'm open to suggestions at this point in time, I just don't see how >>>> this >>>> will solve the bonding problem since it still wouldn't load, right? >>> It would permit users to load ipv6 (thus allowing bonding to >>> load), but prevent ipv6 from actually doing anything. (because >>> sys_socket, e.g., won't open an ipv6 socket if block_af includes ipv6). >> >> Right, but it doesn't help someone that changed /etc/modprobe.conf to >> have "install ipv6 /bin/true" - they'll have to stop doing that. >> >> 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. > > In this case, if IPV6ONLY is set on an AF_INET6 listener, it should > still get AF_INET traffic, correct? No. IPV6ONLY means just that, native IPv6 traffic only. That socket would sit idle. -vlad > >> 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... >> >> -Brian >> >> >> -- >> >> 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> >> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c >> index f8f76d6..90f2a81 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 */ > -- 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
Chuck Lever 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. > > In this case, if IPV6ONLY is set on an AF_INET6 listener, it should > still get AF_INET traffic, correct? No, it should get nothing, and a send should get ENETUNREACH. -Briian -- 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
Brian Haley wrote: > Jay Vosburgh wrote: >>>>> I've been fooling with the disable_ipv6 sysctl, and one issue is >>>>> that, at least on the distro I'm testing on (SLES), it's not picked up >>>>> from /etc/sysctl.conf at boot time (presumably because ipv6 isn't >>>>> loaded >>>>> yet, although I haven't really checked). >>>> Correct, that's the problem. >>>> >>>> We could create a blocker bitmap. Two sysctls, "block_af" and >>>> "unblock_af". You write the AF_foo value for the protocol there and >>>> it sets or clears the assosciated bit in the internal blocker bitmap. >>>> >>>> Things like sys_socket() et al. key off of this. >>> I'm open to suggestions at this point in time, I just don't see how this >>> will solve the bonding problem since it still wouldn't load, right? >> >> It would permit users to load ipv6 (thus allowing bonding to >> load), but prevent ipv6 from actually doing anything. (because >> sys_socket, e.g., won't open an ipv6 socket if block_af includes ipv6). > > Right, but it doesn't help someone that changed /etc/modprobe.conf to > have "install ipv6 /bin/true" - they'll have to stop doing that. > > 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... > > -Brian > > > -- > > 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> > > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > index f8f76d6..90f2a81 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); > Don't forget net->ipv6.devconf_all->disable_ipv6. -vlad > /* Ignore adding duplicate addresses on an interface */ -- 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
On Feb 26, 2009, at Feb 26, 2009, 3:01 PM, Brian Haley wrote: > Chuck Lever 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. >> In this case, if IPV6ONLY is set on an AF_INET6 listener, it should >> still get AF_INET traffic, correct? > > No, it should get nothing, and a send should get ENETUNREACH. Sorry, I got my logic backwards. If IPV6ONLY is intentionally cleared on an AF_INET6 socket, it should still be able to handle AF_INET traffic. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
Chuck Lever wrote: > On Feb 26, 2009, at Feb 26, 2009, 3:01 PM, Brian Haley wrote: >> Chuck Lever 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. >>> In this case, if IPV6ONLY is set on an AF_INET6 listener, it should >>> still get AF_INET traffic, correct? >> >> No, it should get nothing, and a send should get ENETUNREACH. > > Sorry, I got my logic backwards. If IPV6ONLY is intentionally cleared > on an AF_INET6 socket, it should still be able to handle AF_INET traffic. Yes. :-) -vlad > > -- > Chuck Lever > chuck[dot]lever[at]oracle[dot]com > -- 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
Brian Haley <brian.haley@hp.com> wrote: >Jay Vosburgh wrote: >>>>> I've been fooling with the disable_ipv6 sysctl, and one issue is >>>>> that, at least on the distro I'm testing on (SLES), it's not picked up >>>>> from /etc/sysctl.conf at boot time (presumably because ipv6 isn't loaded >>>>> yet, although I haven't really checked). >>>> Correct, that's the problem. >>>> >>>> We could create a blocker bitmap. Two sysctls, "block_af" and >>>> "unblock_af". You write the AF_foo value for the protocol there and >>>> it sets or clears the assosciated bit in the internal blocker bitmap. >>>> >>>> Things like sys_socket() et al. key off of this. >>> I'm open to suggestions at this point in time, I just don't see how this >>> will solve the bonding problem since it still wouldn't load, right? >> >> It would permit users to load ipv6 (thus allowing bonding to >> load), but prevent ipv6 from actually doing anything. (because >> sys_socket, e.g., won't open an ipv6 socket if block_af includes ipv6). > >Right, but it doesn't help someone that changed /etc/modprobe.conf to have >"install ipv6 /bin/true" - they'll have to stop doing that. Yes. There's no reasonable solution that won't require some change for users that have aliased out ipv6. >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. >-Brian > > >-- > >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> >diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c >index f8f76d6..90f2a81 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 */ -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com -- 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
Jay Vosburgh wrote: > Brian Haley <brian.haley@hp.com> wrote: > >> Jay Vosburgh wrote: >>>>>> I've been fooling with the disable_ipv6 sysctl, and one issue is >>>>>> that, at least on the distro I'm testing on (SLES), it's not picked up >>>>>> from /etc/sysctl.conf at boot time (presumably because ipv6 isn't loaded >>>>>> yet, although I haven't really checked). >>>>> Correct, that's the problem. >>>>> >>>>> We could create a blocker bitmap. Two sysctls, "block_af" and >>>>> "unblock_af". You write the AF_foo value for the protocol there and >>>>> it sets or clears the assosciated bit in the internal blocker bitmap. >>>>> >>>>> Things like sys_socket() et al. key off of this. >>>> I'm open to suggestions at this point in time, I just don't see how this >>>> will solve the bonding problem since it still wouldn't load, right? >>> It would permit users to load ipv6 (thus allowing bonding to >>> load), but prevent ipv6 from actually doing anything. (because >>> sys_socket, e.g., won't open an ipv6 socket if block_af includes ipv6). >> Right, but it doesn't help someone that changed /etc/modprobe.conf to have >> "install ipv6 /bin/true" - they'll have to stop doing that. > Hi Jay > Yes. There's no reasonable solution that won't require some > change for users that have aliased out ipv6. > >> 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? 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. -vlad > >> -Brian >> >> >> -- >> >> 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> >> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c >> index f8f76d6..90f2a81 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 */ > > -J > > --- > -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com > -- 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
Vlad Yasevich <vladislav.yasevich@hp.com> wrote: >Jay Vosburgh wrote: [...] >> Brian Haley <brian.haley@hp.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@us.ibm.com -- 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
On Thu, Feb 26, 2009 at 3:57 PM, Vlad Yasevich <vladislav.yasevich@hp.com> wrote: > > 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? > > 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. I feel extremely nervous about people discussing disabling IPv6 going forward. Current estimates are that the first RIRs will begin to exhaust their address spaces (after IANA's address space is exhausted) early in 2011. If you consider that any change probably won't be in a released kernel until June or so, there would be all of 18 months left until IPv6 is *required* to contact some hosts on the internet. At this point in time, anyone looking at "disabling" IPv6 should be doing so with standard firewall rules *exactly* the same way that they would disable IPv4 traffic; adding rules using ip6tables or ebtables is easy. You could simply drop all IPv6 ethernet frames: ebtables -P INPUT ACCEPT ebtables -A INPUT -p IPv6 -j DROP ebtables -P FORWARD ACCEPT ebtables -A FORWARD -p IPv6 -j DROP ebtables -P OUTPUT ACCEPT ebtables -A OUTPUT -p IPv6 -j DROP Alternatively for a per-interface switch you could "ebtables -A INPUT -i eth4 -p IPv6 -j DROP", etc... You could also do this instead (this includes IPv6 tunnels and whatnot): ip6tables -t raw -P INPUT DROP ip6tables -t raw -P OUTPUT DROP This allows programs which have been written to use AF_INET6 even for IPv4 sockets to continue to function appropriately (and there are at least a few). Cheers, Kyle Moffett -- 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
From: Kyle Moffett <kyle@moffetthome.net> Date: Fri, 27 Feb 2009 02:25:54 -0500 > I feel extremely nervous about people discussing disabling IPv6 going > forward. Current estimates are that the first RIRs will begin to > exhaust their address spaces (after IANA's address space is exhausted) > early in 2011. If you consider that any change probably won't be in a > released kernel until June or so, there would be all of 18 months left > until IPv6 is *required* to contact some hosts on the internet. Dear Chicken Little, Please take this elsewhere, you're just distracting from the discussion, and we don't have time for that. The fact is that people want to disable ipv6, full stop, for one reason or another. And all of your talk about firewalling solutions and "the sky is falling" ipv4 address depletion talk is just ignoreing reality. -- 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
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index f8f76d6..90f2a81 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 */