17

When I use stock Linksys firmware on my router, my networked devices properly use IPv4 only to access the Internet.

When I use OpenWRT 15.05.1, the devices try to connect to various sites using IPv6 addresses, which would be great if my ISP provided IPv6 service, which it doesn't.

I've tried a few things which haven't worked: turning off DHCPv6, disabling the DNS caching of dnsmasq, setting dnsmasq's DHCP server to provide a static DNS server address (8.8.8.8), and setting OpenWRT's internal DNS server setting to use that DNS server.

How do I get OpenWRT to stop telling devices that it's OK to use IPv6?

Results of commands on one of the networked devices

The results of ip addr are:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:1a:80:7a:4e:47 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.107/24 brd 192.168.1.255 scope global dynamic enp6s0
       valid_lft 42521sec preferred_lft 42521sec
    inet6 fd7f:77c6:629f::9e8/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd7f:77c6:629f::4e3/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd7f:77c6:629f:0:21a:80ff:fe7a:4e47/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::21a:80ff:fe7a:4e47/64 scope link 
       valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:1d:e0:44:04:57 brd ff:ff:ff:ff:ff:ff

The results of route -6 are:

Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
fd7f:77c6:629f::4e3/128        ::                         U    256 0     0 enp6s0
fd7f:77c6:629f::9e8/128        ::                         U    256 0     0 enp6s0
fd7f:77c6:629f::/64            ::                         U    100 1     3 enp6s0
fd7f:77c6:629f::/48            fe80::c256:27ff:fe77:37a7  UG   100 0     0 enp6s0
fe80::/64                      ::                         U    256 2    10 enp6s0
::/0                           ::                         !n   -1  1   729 lo
::1/128                        ::                         Un   0   3     6 lo
fd7f:77c6:629f::4e3/128        ::                         Un   0   1     0 lo
fd7f:77c6:629f::9e8/128        ::                         Un   0   1     0 lo
fd7f:77c6:629f:0:21a:80ff:fe7a:4e47/128 ::                         Un   0   2     3 lo
fe80::21a:80ff:fe7a:4e47/128   ::                         Un   0   2    30 lo
ff00::/8                       ::                         U    256 2    67 enp6s0
::/0                           ::                         !n   -1  1   729 lo

The results of both ping6 google.com and ping6 2607:f8b0:4008:808::200e are:

connect: Network is unreachable
Improve this question
8
  • When I try to connect to some domains, an IPv6 address is used to connect, which fails as my ISP doesn't support IPv6. Instead, the connected devices should limit themselves to IPv4 addresses. This used to be the behavior when my router used Linksys's firmware, but it's now broken with OpenWRT.
    – Olathe
    Commented Jul 24, 2016 at 5:17
  • Because some programs tell me, when they're connecting, what the domain name they're connecting to resolves to (something like "Connecting to example.com [IPv6 address here]"). Then it tells me that that fails. When I try later, it tells me that the domain resolved to an IPv4 address, and it succeeds. It's rather difficult to share all details, as this happens in several programs, and including all details for all those programs would be absurd.
    – Olathe
    Commented Jul 24, 2016 at 5:28
  • Please try to run ip addr on one of the client machines and include the output in the question.
    – kasperd
    Commented Jul 24, 2016 at 7:35
  • 2
    @Olathe Great. Now it is clear what the problem you are facing is. And I think it is a bad idea for OpenWRT to behave that way by default. I don't know how to configure OpenWRT, so I cannot tell you how to fix the configuration. But at least the question now has sufficient information that somebody with OpenWRT knowledge should be able to answer it.
    – kasperd
    Commented Jul 24, 2016 at 9:04
  • 3
    kasperd: I agree. Those bugs need to be solved at some point though, otherwise they will keep causing problems. Especially when homenet will become more common. So I'm trying to find them and send in patches :)
    – Sander Steffann
    Commented Jul 24, 2016 at 18:25

3 Answers 3

Reset to default
23

A simpler approach would be to SSH into your OpenWrt router and execute the following commands:

uci set 'network.lan.ipv6=off'
uci set 'network.wan.ipv6=off'
uci set 'dhcp.lan.dhcpv6=disabled'
/etc/init.d/odhcpd disable
uci commit

The first command disables the IPv6 LAN interface, the second the IPv6 WAN interface, the third and fourth disables the DHCPv6 Server and uci commit commits the changes.

UPDATE

It seems my information has not aged well... The settings are a bit different and these are additional bits. The information should now be up to date for 2021.

The syntax got changed a bit:

uci set 'network.lan.ipv6=0'
uci set 'network.wan.ipv6=0'
uci set 'dhcp.lan.dhcpv6=disabled'
/etc/init.d/odhcpd disable
uci commit

and then disable RA and DHCPv6 so no IPv6 IPs are handed out:

uci -q delete dhcp.lan.dhcpv6
uci -q delete dhcp.lan.ra
uci commit dhcp
/etc/init.d/odhcpd restart

You can now disable the LAN delegation:

uci set network.lan.delegate="0"
uci commit network
/etc/init.d/network restart

You might as well disable odhcpd:

/etc/init.d/odhcpd disable
/etc/init.d/odhcpd stop

And finally you can delete the IPv6 ULA Prefix:

uci -q delete network.globals.ula_prefix
uci commit network
/etc/init.d/network restart

UPDATE 2

To quote @Kurt Fitzner:

Use ifconfig to show all the network devices and note which ones have IPv6 addresses. Then navigate through the graphical OpenWRT interface to Network->Interfaces, and select the Devices tab. For each device that had an IPv6 address, select "configure" for that device and uncheck "enable IPv6".

Improve this answer
12
  • 2
    To avoid rebooting my router to pickup changes, I run /etc/init.d/odhcpd stop right after the uci commit so that dhcp server stop leasing IPV6 addresses right away ;)
    – Pablo Burgos
    Commented Apr 12, 2020 at 2:27
  • @PabloBurgos Thank you so much for providing me with the hint that I needed to either run that command, or reboot my router, for these config changes to actually take effect. I thought I was going crazy when my devices were still getting IPv6 addresses after this change!
    – Kenny83
    Commented Apr 26, 2020 at 19:05
  • 1
    This approach did not work for me. It seems that ipv6 settings are located in separate uci interfaces (wan6 instead of wan) tied to the same underlying network interfaces. I'm using openwrt 19.07.3
    – stochastic
    Commented Jul 26, 2020 at 0:33
  • 1
    @SirMuffington Yes: Use ifconfig to show all the network devices and note which ones have ipv6 addresses. Then navigate through LUCI to Network->Interfaces, and select the Devices tab. For each device that had an ipv6 address, select "configure" for that device and uncheck "enable ipv6".
    – Kurt Fitzner
    Commented Nov 27, 2022 at 14:39
  • 1
    @SirMuffington Of course! I just wish there was an easy way to do this in UCI since the the rest of the answer is formulated that way.
    – Kurt Fitzner
    Commented Nov 28, 2022 at 16:30
16

On initial installation (or settings reset) OpenWrt generates a Unique Local Address prefix and assigns ULAs to all the devices in the network, allowing them to communicate internally via IPv6 even without global IPv6 connectivity.

This generally works fine, except in two scenarios:

  1. An end device attempts to route global IPv6 traffic anyway, despite this address range not being usable for that purpose. Your routing table doesn't indicate that this is what is happening, and no commonly used operating system from the last decade or so would be doing this.
  2. An application misbehaves, and attempts to make global IPv6 connections when the computer does not have global IPv6 connectivity (or more specifically, a default route). From your description, this seems to be what is going on.

To be explicit: By advertising a ULA prefix, OpenWrt is not telling your devices that it's OK to access the Internet via IPv6. It is only telling them that it's OK to access your home network via IPv6.

The long-term solution is to fix the misbehaving applications. If you have run into this behavior in a particular application, you should report it as a bug to its developers.

The short-term workaround is to have OpenWrt not advertise a ULA prefix. You can go to Network > Interfaces, blank out the IPv6 ULA-Prefix box, and click Save & Apply. This will prevent OpenWrt from advertising a ULA prefix. If you ever reset your router's settings to defaults, you may need to do this again.

Improve this answer
2
  • 1
    Great answer/detail. Thank you so much! Anyway to have OpenWRT generate a new ULA again?
    – IMTheNachoMan
    Commented Feb 16, 2019 at 3:07
  • 2
    For me, the "IPv6 ULA-Prefix" box was under: Network > Interfaces > Global network options
    – mmortal03
    Commented Sep 8, 2020 at 9:36
0

/etc/modules.d contains links to kernel modules that will be loaded on boot. Simply delete the links to ip6tables, ipt6-nat and nf-conntrack6 then reboot. IPv6 will be gone for good, until you do a hard reset.

This method has the added benefit of freeing a lot more RAM as the module are never loaded.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .