Completely drop CONFIG_IPV6

[f00b4r0]

A patch has been submitted to "hide" CONFIG_IPV6, the disabling of which is no longer supported (it breaks build, as reported in https://github.com/openwrt/openwrt/issues/9580).

However, as has been pointed out before and now, the correct approach is to entirely remove CONFIG_IPV6 from the openwrt trees.

This requires a coordinated change across the buildroot and the packages repositories (and maybe third-party repositories as well).

This issue is opened to serve as a reminder of what still needs to be done.

HTH

[pkgadd]

Given the long standing issues with CONFIG_IPV6, this is long overdue, thank you for taking this up.

[f00b4r0]

I have to reopen this issue, because droping "IPv4 only" support is absolutely not acceptable! We have a project (Freifunk) that depends on disabling IPv6 in firmware.

That's your prerogative. I'm not sure why it should bear particular relevance to the project as a whole?

First we do not need this

I'm sorry, who's "we"?

and secondly there is no space in flash. Kernel and all its modules take a lot of space which does not fit into flash memory of routers with 8mbyte or lower. In addition we need to implement unused security/network/iptables for IPv6. This is against any idea behind openwrt. It must be an open platform and it must be possible to have IPv4 only systems as long Linux supports this and has this included.

And you absolutely can disable IPv6 at the interface level or system-wide through sysctl. Your argument about firewalling is moot.

The project uses a common code base, so small and new routers can be supported including other non-router devices. When you just drop IPv6 because you just don't want to fix this issue, this will cause huge problems, not just for Freifunk.

We didn't "drop IPv6", in fact it's quite the opposite. Besides, this is 2023. IPv6 should have replaced IPv4 a long time ago, so your argument seems rather backwards.

Openwrt 22.03.0-rc4 is the last version that does work. all other candidates or releases have this blocking issue.

• What has changed since then?

Feel free to bisect and submit a patch if you can dedicate the resources to fix this.

I really appreciate if you can fix this issue.

That's not how this [open source] works.

Unless we have an unsolvable problem with our project which is doomed to be end. A lot of devices are not available in shops and new devices are build. All those can not be used in future.

They certainly can, although not easily. The kernel has already grown so big that very old devices with very small flash can no longer even store the kernel alone. Are you suggesting we should stop updating the kernel so that these ancient devices be supported forever, and that thus newer devices should never be supported?

Besides, 21.02 is still supported, it also caters to this type of use case. And if you can afford to run your own security updates, you can use 19.07 or even older releases.

I really hope that such profound decisions will be reverted and will never happens again . There were already a lot of massive changes during upgrades from openwrt 19 to 21 without any upgrade posibility (except factory reset) in an environment, where routers are in field and not accessible physically. We could solve this upgrade problem by reverting some patches in openwrt.

Droping IPv4-Only support is not possible.

It very much is: see, it happened.

[dwfreed]

This issue is not about dropping IPv6. This issue is about dropping the ability to disable IPv6 only at compile time. Which means IPv6 capability would be built into the kernel, and then one can easily use sysctls to disable IPv6 during runtime.

[f00b4r0]

Sorry, but you haven't understood my problem.

I did: it's indeed your problem. You however do not understand OpenWrt's rationale for doing this.

kthxbye.

[champtar]

What's the size difference with / without IPv6 ?

[jow-]

You can still disable IPv6 kernel support through kernel_menuconfig and you can still omit packages not needed for ipv6 functionality (odhcpd, odhcp6c, ...).

What will be gone after this change is the ability to compile certain packages without support for IPv6. Many packages don't honor CONFIG_IPV6 anyway and will contain support for dealing with AF_INET6 regardless of the option choice. Some of the packages which do respect the option fail to compile with it being turned off and some will yield usable binaries that simply do not understand AF_INET6.

What is proposed here is the removal of the buildroot level (not kernel!) CONFIG_IPv6 option which is not regarded at all by many packages, broken for others and ineffective for some (e.g. musl libc's inet_pton() or inet_aton() will still parse and produce IPv6 addresses, regardless of the option being turned off).

To give an expression of the kind of code being protected by CONFIG_IPV6, take a look at the #ifdef CONFIG_IPV6 instances here: https://github.com/openwrt/packages/blob/master/net/mwan3/src/sockopt_wrap.c

The machine code level differences are insignificant and likely not measurable at all.

[AiyionPrime]

Maybe one can take a deep breather, especially if one talks about what the freifunk project needs.

If this discussion got really just started because you want OpenWrt developers to support this toggle even longer then they already did, take note that it's an ever increasing challenge, as well as one with ever diminishing returns. It's not a question about if, but when this toggle does not make sense anymore.

If you want this toggle to stay, don't tell others why you need this, but show them there's no need to remove it by either continuously fixing the codebase around packages that are not going to respect a IPv4 only domain anymore (a task other developers have done for you so far) or motivate other developers to do so.

But let me tell you: nudging developers by "the freifunk project needs this" is not only pretty impolite and for obvious reasons wrong as other communities have shown for a long time already, but does depict a project and its contributors I really appreciate as ungrateful, demanding and tilting against windmills on others cost.

As such I'd really appreciate if you'd dim the tone to a somewhat more constructive one. Possibly starting with asking for documentation on how to help supporting the toggle a little longer, while being aware of, that it will be an annoying task and won't end without giving this toggle up.

I really appreciate you standing up for Freifunk, but imho this is not the right way to do so.

If you want to discuss tiny devices and their Freifunk-Support these years, feel free to join us in Freifunks Forum topic.

But this place should stay clean of loaded discussions for subprojects requirements.

Opinions are as always mine and neither the views of Freifunk Hannover nor Gluon.

[Spudz76]

stop whining or we'll put in systemd and make it non-negotiable too

[f00b4r0]

Le 8 janv. 2023 à 01:17, Stephan:

 ok, this is not the kind of support an help I expected. I see no one is willing to fix issues,

There are no “issues”, this is by design. IPv6 is futureproof, IPv4 is not. FWIW the EU (which should concern your alleged “needs”) is pushing forward for massive IPv6 deployment. In that context, asking for a way to entirely remove IPv6 support seems rather backwards.

4/32 devices are no longer supported either. If this is what you’re using, you’re on your own. 16/128 is the current minimum recommendation.

If you want to keep using ancient outdated technologies because of whatever “needs” of yours, so be it: use ancient outdated software as well; but do not expect everyone else to follow suit with your absurd demands.

just workaround them. If your only help is, that I have to fix the issue myself (because you can't) or find people that like to help...

Again, that’s not how this works and you have the wrong attitude here.

Why have you not told me in your first answer that?

We did, apparently you did not want to listen.