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 (, 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 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 brd 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
  • 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 Jul 24 '16 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 Jul 24 '16 at 5:28
  • Please try to run ip addr on one of the client machines and include the output in the question. – kasperd Jul 24 '16 at 7:35
  • 1
    @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 Jul 24 '16 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 Jul 24 '16 at 18:25

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.

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

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.

  • 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 Apr 12 '20 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 Apr 26 '20 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 Jul 26 '20 at 0:33
  • @stochastic try changing the wan to wan6. I'm not aware of any recent changes that could've possibly broken this. If this method works I will gladly edit my answer. I think I executed the commands on 19.07.1 – Sir Muffington Jul 26 '20 at 10:48

/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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.