lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 1 Apr 2019 14:02:09 -0700
From:   Maciej ┼╗enczykowski <zenczykowski@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     Linux NetDev <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/2] net: enable IPv6 iff IPv4

> 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

Powered by blists - more mailing lists