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

[Fernando Fernandez Mancera <fmancera@suse.de>]

On 3/9/26 1:43 PM, Krzysztof Kozlowski wrote:
> On 09/03/2026 12:38, Fernando Fernandez Mancera wrote:
>> 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
> 
> Not for end user devices. None of my devices - neither routers, nor
> embedded boards, nor mobile phone from 5G provider - receive IPv6
> address, thus for them it is not fundamental.
> 

I am not so sure about this. Many if not most modern routers provide 
IPv6 support and as I said it is enabled as built-in in openWRT since 
[1]. For mobile phones they probably use IPv6 when connected to routers 
but even 5G providers are using IPv6. They are working on IPv6-only 
deployments with NAT64 too [2].

[1] 
https://github.com/openwrt/openwrt/commit/0c8f0186d58468024db96a5ab0ca36a4d400d408

[2] https://www.ietf.org/archive/id/draft-ma-v6ops-5g-ipv6only-01.html

> I agree it is fundamental for your cloud machines and network backbone
> which you are targeting, but this patchset completely ignores other
> users calling their use-cases "little practical benefit"! Try running
> Amiga machine...
> 
> There is no even bloatometer stats for these defconfigs so we can see
> the impact.
> 

Sure. I can provide them.

>> 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.
> 
> Maybe there are other reasons why distro should not choose it as module
> (like module load calls on ipv6 packets) but that was not explained here.
> 
> Arch Linux Rpi kernel on arm64 has IPV6=6 and the module itself is 650
> kB. That's noticeable for smaller arm64 boards.
> 
> For arm it would be even more noticeable as some have 256 MB RAM like
> first Rpi.
> 
>>
>> 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.
> 
> It's not the same. You enabled it on amiga_defconfig and do you
> understand what sort of machine is that? The newest have 16 MB RAM, many
> much less like 2 MB, and ipv6 module on m68k is 400 kB, so pretty
> significant change.
> 

Fair enough. Of course I am not familiar with all the architectures 
affected. This feedback is more than welcome and it might make a lot of 
sense to disable IPv6 on Amiga and probably different architectures. By 
the way if by Amiga you mean [3] then I believe it should be disabled.

[3] https://en.wikipedia.org/wiki/Amiga

Thanks,
Fernando.