[1/2] net: enable IPv6 iff IPv4

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>
---
 net/Kconfig      | 1 +
 net/ipv6/Kconfig | 7 +------
 2 files changed, 2 insertions(+), 6 deletions(-)

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.