Message ID | 20190401194459.168345-1-zenczykowski@gmail.com |
---|---|
State | Rejected |
Delegated to: | David Miller |
Headers | show |
Series | [1/2] net: enable IPv6 iff IPv4 | expand |
From: Maciej Żenczykowski <zenczykowski@gmail.com> Date: Mon, 1 Apr 2019 12:44:58 -0700 > From: Maciej Żenczykowski <maze@google.com> > > IPv6 is 20 years old and IPv4 has run out of IP addresses > and is deprecated. > > It is time to make IPv6 a first class citizen. > > As such we remove the ability to compile IPv6 as a module, > and IPv4 support now implies IPv6 support. > > This has the nice benefit of allowing upcoming code simplification: > all IPv6 module support can be removed, and we'll be able to merge > IPv6 socket state into the base IPv4 socket state... > > At some point we should be able to reverse things and make IPv4 > the optional protocol and possibly even make an ipv4.ko. > > Signed-off-by: Maciej Żenczykowski <maze@google.com> Things are modular because we don't unilaterally make decisions for people on this level. This is why I'm very much not too motivated to integrate changes like this, even though I understand the motivation and simplifications this would enable. I mean, who the heck are we to tell someone that because they make some tiny device meant for an isolated ipv4 environment that they _MUST_ have ipv6 also built into their kernels? Seriously...
> Things are modular because we don't unilaterally make decisions for > people on this level. We do unilaterally make various decisions - some of them quite big in scope. Although perhaps not this one. > This is why I'm very much not too motivated to integrate changes like > this, even though I understand the motivation and simplifications this > would enable. > I mean, who the heck are we to tell someone that because they make > some tiny device meant for an isolated ipv4 environment that they > _MUST_ have ipv6 also built into their kernels? One of the major reasons why ipv6 is seeing such slow adoption is because people keep manufacturing ipv4 only devices. It's just a stupid network attached sensor, but it doesn't work on your network because it doesn't support ipv6... and as a result you need to keep around legacy ipv4 support. Why should the manufacturers be allowed to tell me how to run my network? These small devices are unlikely to be even running a 5.2+ kernel for another half decade or more. ie. we're talking about hardware that'll come to market 3-4 years from now, at the earliest, probably later, since no one updates the kernel/software on these devices after they initially start shipping. If they truly need something so tiny and so ipv6 unsupporting, they can simply run 5.1 or older. It's not like we'll delete the source code for older versions of Linux. --- Perhaps just making ipv6 a boolean instead of a tristate would be acceptable? That would get rid of most of the craziness with supporting loading ipv6 as a module, the checks for is this function null, etc. and we could still move all the fields into the main ip struct just surrounded by #ifdef IPV6
From: Maciej Żenczykowski <zenczykowski@gmail.com> Date: Mon, 1 Apr 2019 14:02:09 -0700 > Why should the manufacturers be allowed to tell me how to run my > network? He isn't, unless he forced you to buy his device? This is like how various "internet pioneers" complain about how google products do DNS directly to 8.8.8.8 and 8.8.4.4, instead of simply not buying Google's products. Touche'.
On 4/1/19 12:44 PM, Maciej Żenczykowski wrote: > From: Maciej Żenczykowski <maze@google.com> > > IPv6 is 20 years old and IPv4 has run out of IP addresses > and is deprecated. > > It is time to make IPv6 a first class citizen. > > As such we remove the ability to compile IPv6 as a module, > and IPv4 support now implies IPv6 support.> > This has the nice benefit of allowing upcoming code simplification: > all IPv6 module support can be removed, and we'll be able to merge > IPv6 socket state into the base IPv4 socket state... If you exclude size increase for the built-in part of the kernel, yes, it's all beneficial. There are tons of systems where IPv6 will likely never be used, let's face it, so why kill the ability to insmod the IPv6 stack since it really does not come at the cost of trying to fix the unloading part already? I am not convinced this is solving any problems TBH... > > At some point we should be able to reverse things and make IPv4 > the optional protocol and possibly even make an ipv4.ko. > > Signed-off-by: Maciej Żenczykowski <maze@google.com> > --- > net/Kconfig | 1 + > net/ipv6/Kconfig | 7 +------ > 2 files changed, 2 insertions(+), 6 deletions(-) > > diff --git a/net/Kconfig b/net/Kconfig > index 3e8fdd688329..0f2ca2137f9e 100644 > --- a/net/Kconfig > +++ b/net/Kconfig > @@ -68,6 +68,7 @@ config INET > bool "TCP/IP networking" > select CRYPTO > select CRYPTO_AES > + select IPV6 > ---help--- > These are the protocols used on the Internet and on most local > Ethernets. It is highly recommended to say Y here (this will enlarge > diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig > index 613282c65a10..9197f496a112 100644 > --- a/net/ipv6/Kconfig > +++ b/net/ipv6/Kconfig > @@ -2,10 +2,8 @@ > # IPv6 configuration > # > > -# IPv6 as module will cause a CRASH if you try to unload it > menuconfig IPV6 > - tristate "The IPv6 protocol" > - default y > + bool "The IPv6 protocol" Huh, no, please? If you need IPv6 make it built-in to your kernel, but don't bother people taht > ---help--- > Support for IP version 6 (IPv6). > > @@ -15,9 +13,6 @@ menuconfig IPV6 > Documentation/networking/ipv6.txt and read the HOWTO at > <http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/> > > - To compile this protocol support as a module, choose M here: the > - module will be called ipv6. > - > if IPV6 > > config IPV6_ROUTER_PREF >
On 4/1/19 2:02 PM, Maciej Żenczykowski wrote: >> Things are modular because we don't unilaterally make decisions for >> people on this level. > > We do unilaterally make various decisions - some of them quite big in scope. > Although perhaps not this one. > >> This is why I'm very much not too motivated to integrate changes like >> this, even though I understand the motivation and simplifications this >> would enable. > >> I mean, who the heck are we to tell someone that because they make >> some tiny device meant for an isolated ipv4 environment that they >> _MUST_ have ipv6 also built into their kernels? > > One of the major reasons why ipv6 is seeing such slow adoption is because > people keep manufacturing ipv4 only devices. It's just a stupid > network attached > sensor, but it doesn't work on your network because it doesn't support ipv6... > and as a result you need to keep around legacy ipv4 support. > > Why should the manufacturers be allowed to tell me how to run my network? > > These small devices are unlikely to be even running a 5.2+ kernel for another > half decade or more. > > ie. we're talking about hardware that'll come to market 3-4 years from now, > at the earliest, probably later, since no one updates the > kernel/software on these > devices after they initially start shipping. > > If they truly need something so tiny and so ipv6 unsupporting, they > can simply run 5.1 or older. You can't use your own argument both ways and complain that people design devices that are never upgraded and then just give them another argument for not updating because IPv6 simply makes them make an unacceptable decision which could be either of: - creating another attack surface they had not thought about initially - making their memory budget explode to the point where a new kernel becomes out of the equation, period - the product is simply not meeting the requirements of *not* supporting IPv6 (granted it could be a stupid requirement, yet be one) > It's not like we'll delete the source code for older versions of Linux. No, but it is another roadblock to upstreaming changes for your embedded device if you need to make a few tweaks here and there. And given the direction you want to go later on, it won't be as simple as a revert of your patches to go back to hypothetical pre-5.1 behavior. > > --- > > Perhaps just making ipv6 a boolean instead of a tristate would be acceptable? > > That would get rid of most of the craziness with supporting loading > ipv6 as a module, > the checks for is this function null, etc. and we could still move all > the fields into > the main ip struct just surrounded by #ifdef IPV6 > Are you seeing a performance problem where having IPv6 be built-in and all code being reachable would help, or are you trying to improve the maintenance burden, or is it something else?
From: Florian Fainelli <f.fainelli@gmail.com> Date: Mon, 1 Apr 2019 14:37:25 -0700 > There are tons of systems where IPv6 will likely never be used, let's > face it, so why kill the ability to insmod the IPv6 stack since it > really does not come at the cost of trying to fix the unloading part > already? > > I am not convinced this is solving any problems TBH... I agree. Saying everyone must be doing ipv6 3 to 4 years from now is the height of arrogance. And maybe it is this arrogance of people pushing ipv6 that blocks widespread ipv6 adoption rather than any technical reasons. That's nice on your network, but don't tell me what's appropriate or useful on mine. And ironically the "don't tell me what to do on my network" argument was used as justification for this change. It cuts both ways.
diff --git a/net/Kconfig b/net/Kconfig index 3e8fdd688329..0f2ca2137f9e 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -68,6 +68,7 @@ config INET bool "TCP/IP networking" select CRYPTO select CRYPTO_AES + select IPV6 ---help--- These are the protocols used on the Internet and on most local Ethernets. It is highly recommended to say Y here (this will enlarge diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig index 613282c65a10..9197f496a112 100644 --- a/net/ipv6/Kconfig +++ b/net/ipv6/Kconfig @@ -2,10 +2,8 @@ # IPv6 configuration # -# IPv6 as module will cause a CRASH if you try to unload it menuconfig IPV6 - tristate "The IPv6 protocol" - default y + bool "The IPv6 protocol" ---help--- Support for IP version 6 (IPv6). @@ -15,9 +13,6 @@ menuconfig IPV6 Documentation/networking/ipv6.txt and read the HOWTO at <http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/> - To compile this protocol support as a module, choose M here: the - module will be called ipv6. - if IPV6 config IPV6_ROUTER_PREF