Re: [PATCH 00/10 net-next] Convert CONFIG_IPV6 to built-in and remove stubs

[Fernando Fernandez Mancera]

On 3/9/26 11:22 AM, Krzysztof Kozlowski wrote:
> On 09/03/2026 03:19, Fernando Fernandez Mancera wrote:
> > Historically, the Linux kernel has supported compiling the IPv6 stack as
> > a loadable module. While this made sense in the early days of IPv6
> > adoption, modern deployments and distributions overwhelmingly either
> > build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
> > entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
> > no practical benefit today.
>
> It does. We all use generic kernels, thus it is one configuration for
> all boards and some setups have IPv6 and some not. The ones without IPv6
> just don't use that module.

While I understand this, I would like to clarify that IMHO IPv6 isn't a 
secondary protocol and it is fundamental to modern networking. This is 
why I believe it should be built-in by default. Currently OpenWRT, 
Debian ARM and others already ships the kernel with CONFIG_IPV6=y. I 
know that Alpine and Yocto doesn't do that for arm64.

I guess the most critical one here is Yocto but if the developer of the 
embedded device is sure they won't use IPv6 at all, they should turn it off.

At the same time, Alpine ships software that enable IPV6 and is 
frequently loaded as a module. So the only remaining concern would be 
the boot partition size. I don't really have a solution for that problem.

I think that the infrastructure for allowing IPV6=m is bug-prone and it 
impacts performance. Forcing the use of indirect function calls in core 
networking, Netfilter or BPF datapaths seems like a heavy tax to me.

> Also, with these generic kernels (so again all machines are using same
> ones, e.g. distro) users can easily blacklist the module.

FWIW; users can still boot with kernel command line parameter 
ipv6.disable=1 and then IPV6 will be administratively disabled.

At the end this a trade-off, I still believe it is worth it but I 
understand your concerns.

Thanks,
Fernando.