Hi,
in menuconfig, Is it a big deal to remove all ipv6 settings in the menu?
I dont need it, so if it is possible i would remove them all.
thanks
This is not really a supported configuration anymore, if it breaks, you get to keep the pieces.
Be aware that partial IPv6 removals can be dangerous (as in kernel support for IPv6, but firewall removed…).
5 Likes
would just making a script that disables it via proc be enough ?
eg.
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
or individually
echo 1 > /proc/sys/net/ipv6/conf/eth0/disable_ipv6
etc
2 Likes
it's almost time to start removing ipv4
imagine getting to remove all the NAT stuff and helpers
even the memory requirement would drop big time
3 Likes
Memory requirement isn't the only thing guaranteed to fall if you remove IPV4, now or in the foreseable future: the other is usefulness.
You can probably do this in sysctl 
But this actually didn't work for me, several interfaces would still get the ipv6 address
I think it's some what related to that network is initialized after sysctl?
I disabled ipv6 via menuconfig -> global build settings
Works great for me (as of now), same as adding DISABLE_IPV6=1 (iirc) in grub boot args in linux
Resulting image has no IPv6 support, no ::1
root@OpenWrt:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1513 qdisc mq state UP qlen 1024
link/ether ********* brd ff:ff:ff:ff:ff:ff
...
Only catch (so far) is that I need to remove the ::1 in /etc/resolv.conf
The default on my system is /etc/resolv.conf linking to /tmp/resolv.conf, had to remove the symlink and hard code /etc/resolv.conf
nameserver 127.0.0.1
search lan.
1 Like
All that is safe?
Depends on what you consider "safe"
So far (3 days) I haven't noticed any differences, before I used sysctl to disable ipv6 but now finally getting to disabling it at compile time
The image builder option CONFIG_IPV6=n didn't fully disable IPv6, as lo is still getting ::1
Not sure if this helps... my VPN provider has a manual linux script to use to connect to them.
In the script there's a section to check for & provide the commands to disable IPv6.
I've adapted it for OpenWrt.
#!/bin/sh
if [ -f /proc/net/if_inet6 ] && [ $(sysctl -n net.ipv6.conf.all.disable_ipv6) -ne 1 ] || [ $(sysctl -n net.ipv6.conf.default.disable_ipv6) -ne 1 ]; then
echo '
You should consider disabling IPv6 by running:
'
echo ' /etc/init.d/sysctl -w net.ipv6.conf.all.disable_ipv6=1'
echo ' /etc/init.d/sysctl -w net.ipv6.conf.default.disable_ipv6=1'
echo ' /etc/init.d/sysctl reload
'
fi
I haven't used it personally, but I'm curious if it works?
1 Like
It should work to some extend, but lo might not have IPv6 disabled AFAIK if you do this
I've done it this way before, but IPv6 addresses keep on coming back when I reload network
Also, if all you care about is to disable it, just run (without the IF and echo)
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
sysctl -w net.ipv6.conf.lo.disable_ipv6=1
sysctl -p
1 Like
About the only use case for just turning off IPv6 is if your ISP offers you a prefix but their IPv6 service is shoddy (super high/variable pings, variable bandwidth, dropped packets etc). In that case, you'd want to turn it off because it's not really working. Outside of that I can't imagine any scenario where turning off ipv6 offers any benefit at all.
3 Likes
My ISP doesn't offer IPv6 at all, and I have no use of it on my LAN
I have 4 machines running K8s on Ubuntu, whenever there is a network change (getting IPv6 address for example), K8s crash/turns off and restarts
Turning off IPv6 in all these machines, and the router (not necessary, just easier for me to manage) mitigated the problem
It's stock MicroK8s installation and I'm not gonna go modify the snap/source code of that 
so disabling IPv6 it is
PS: I probably have some misbehaving devices that's messing with the IPv6 auto-config on my LAN, advertises a weird (not set by me or ISP) prefix every few hours or so
1 Like
This is a security issue, and may well indicate a security breach. you should look into it. One kind of attack is to advertise an ipv6 router, and then man-in-the-middle all the traffic, or redirect it to other places.
1 Like
Did wireshark, turns out if I reconnect my Wifi on my macbook, it sends out "Router Solicitation"
Then, my homepod mini decides to respond by sending back a "Router Advertisement" that contains this prefix
This prefix fdcb:f17a:ca53:: has been applied/chosen for my LAN without my intervention...is this normal? Is there a way to get rid of this prefix and just use fe80 instead?
that's a "ULA" prefix. it's kind of equivalent to something like 10.13.55.0/24 except from a much bigger space that is essentially never going to have collisions between two randomly selected networks. By default OpenWrt chooses one of these randomly and puts it on your LAN.
This is a good thing there will be people who create modern devices like homepod minis which don't bother to implement ipv4 features, because why bother? You can focus on Ipv6 only and move forward instead of always hanging back being stuck to broken tech.
Still, it should be OpenWrt which gives out the ULA normally, not a random device. If OpenWrt gives out a ULA and then the homepod mini also gives out one, it's kinda a bit of an annoyance. Hopefully the homepod mini is only doing it because your turned off IPv6 on your router and so no one else is.
The fix is to ensure OpenWrt has ipv6 working and gives out its own ULA and then hopefully the homepod won't feel that it has to do this instead.
4 Likes
Thank you for the input
Did some investigation, turns out the RA from Homepod mini is related to the "Thread networking" IoT devices...
https://discussions.apple.com/thread/252367920
Might have also found how to fix the microk8s restarting: They restart the service whenever there's an IP address change, even on IPv6 address change (pointless since the cluster is running in a 10.0.0.0/8 network)
Going to enable IPv6 back slowly...
2 Likes
I do believe IPv6 is the future.
I hate NAT. We should use IPv6 rather than NAT.
Of course
IPv6 support is wide spread in Europe and Asia, especially in China since they don't have public IPv4 address to the home (all carrier grade NAT etc etc), so IPv6 support has been heavily invested upon and useful if you want to expose port/have direct connection (games?)
Here in North America, (most?) ISPs give customers public IPv4 addresses, I can even dial multiple PPPOE sessions to get as many IP addresses as I want (I've tried 5). We aren't running out of addresses any time soon, so no one really cares about IPv6 afaik...
In Canada you have two options:
- Bell which has FFTH, symmetrical 1G up and down, but no IPv6
- Rogers which still uses coax, 1G down and 30mbps up, but they do have IPv6
Guess which one I went for
I don't think that's right. That's the correct perspective back for 2015 or so maybe. But today, there's a whole market for trading IPs and they're expensive, and ISPs have issues with their internal networks being run on 10.x.x.x addresses but they're running out of those, and have horrible routing issues internally.
Google shows ~ 45% of US traffic comes from Ipv6 which because business users are adopting much more slowly, means more than 45% of home users.
T-Mobile has virtually 100% ipv6 only network, and they have millions and millions of users.
1 Like