IPv6 Not working, it is enabled on router stateless giving only a FE80 link local address

Latest Dietpi 8.7.1 Latest pihole v5.11.4 FTL v5.16.1 Web Interface v5.13
I have IPv6 stateless enabled on the router, it assigns 4 IPv6 addresses to all OSX/WIndows machines:
IPv6 Global Unicast Addresses(GUA), 2 Temporary link locals, and a Link-Local Address FE80.
win/osx machines can ping ipv6.google.com and resolve the ipv6 address. And ipv4 dns is going through the pihole correctly.(Verified through the Query log)

The dietpi is only getting an IPv4 and IPv6 FE80 address. No GUA. Ipv6 is enabled in the dietpi config.
I can ping ::1 and fe80:: a:b:c:d%eth0 fine on the dietpi.
(ip a)
inet6 fe80:: a:b:c:d/64 scope link
valid_lft forever preferred_lft forever
Cannot ping ipv6.google.com, error: Network is unreachable
Unbound is setup on the dietpi.

I have ::1#5335 set under Upstream DNS custom 3(ipv6)


source interfaces.d/*

allow-hotplug eth0
iface eth0 inet static

#allow-hotplug wlan0
iface wlan0 inet dhcp

Does the router offer SLAAC? I guess that would be needed to tell the client on how to generate the GUA.

Following this side, it is required using stateless configuration

A stateless DHCPv6 server does not provide IPv6 addresses at all. It only provides "other information " such as a DNS server list and a domain name. It works in conjunction with another feature called SLAAC that tells hosts how to generate global unicast addresses

Why do all the win/osx machines receive a gua, but not the dietpi?
There is no slaac option, it has 6rd enabled, it’s a centurylink zyxel c3000z

Maybe DHCPv6 client would need to be installed. Just guessing. Maybe @MichaIng has another idea.

Usually SLAAC works fine, DHCPv6 is rarely ever required or useful. Via ifupdown, the isc-dhcp-client can be used for DHCPv6 as well.

Can you let the following run (for up to 30 minutes) so see whether DietPi receives RAs from the router, used to setup the GUA and default route for IPv6?

apt install tcpdump
tcpdump -n -i eth0 icmp6 and ip6[40] == 134

Ok installed tcpdump
outputs every minute the same:
IP6 fe80:: a:b:c:d > ff02::1: ICMP6, router advertisement, length 136

Okay so RAs arrive. Do you get an IPv6 default route?

ip -6 r

This is the output:
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium

Any ideas to fix this?

IPv6 is by default preferred over IPv4 on OSX and Windows machines.

Which bypasses the dietpi PIHOLE DNS using IPV6.

Only other option is to disable IPv6.

Just to avoid a misunderstanding, following is just an example and I’m not doing a statement your issue is irrelevant. Definitely we would need to find a cause.

But this is not on issue, if you instruct your DHCP server to distribute PiHole link local IPv6 address :wink:
That’s how I did on LAN.

This is how a test for one of my Windows box looks like

C:\Users\>nslookup dietpi.com
Server:  pi.hole
Address:  fe80::dea6:xxx

Nicht autorisierende Antwort:
Name:    dietpi.com
Addresses:  2a06:98c1:3120::3


As you can see, my Widnows box is connecting to PiHole using an fe80 address.

PiHole themselves is using IPv4 to connect to upstream DNS

Link local fe80 is being assigned by the router to the dietpi fine.
I get a link local fe80 address for the dietpi. (fe80:: a:b:c:d)
But DNS IPv6 checking by clients to the dietpi pihole still does not work.
I have Unbound installed so my upstream server is localhost


set under Upstream DNS custom 3(ipv6)

This is what I get on windows:

nslookup dietpi.com
DNS request timed out.
 timeout was 2 seconds.
Server:  UnKnown
Address:  fe80:: a:b:c:d
DNS request timed out.
  timeout was 2 seconds.

If I remove the link local fe80:: a:b:c:d IP6 dns entry under the network adapter IP6 settings it will return an IP6 ip, but over IPv4 and not over IPv6
It gives this as a result instead:

nslookup dietpi.com
Server:  pi.hole

Non-authoritative answer:
Name:    dietpi.com
Addresses:  2606:4700:3032::ac43:aadb

The link local address is automatically generated by the system itself and not assigned by a router

This is not needed. You can use the IPv4 address to connect to Unbound. Nevertheless, it will resolve IPv6 DNS names.

Can you check if PiHole + Unbound are LISTEN to IPv6 interface.

ss -tulpn | grep 'pihole-FTL\|unbound'

Yes they are:

ss -tulpn | grep 'pihole-FTL\|unbound'
udp   UNCONN 0      0                  *    users:(("unbound",pid=363,fd=3))
udp   UNCONN 0      0                  *    users:(("pihole-FTL",pid=367,fd=6))
udp   UNCONN 0      0                *    users:(("pihole-FTL",pid=367,fd=4))
udp   UNCONN 0      0                                [::1]:53              *:*    users:(("pihole-FTL",pid=367,fd=10))
udp   UNCONN 0      0           [fe80::a:b:c:d]:53   *:*       users:(("pihole-FTL",pid=367,fd=8))
tcp   LISTEN 0      5                  *    users:(("pihole-FTL",pid=367,fd=19))
tcp   LISTEN 0      32                 *    users:(("pihole-FTL",pid=367,fd=7))
tcp   LISTEN 0      32               *    users:(("pihole-FTL",pid=367,fd=5))
tcp   LISTEN 0      256                *    users:(("unbound",pid=363,fd=4))
tcp   LISTEN 0      256                *    users:(("unbound",pid=363,fd=6))
tcp   LISTEN 0      5                                [::1]:4711         [::]:*    users:(("pihole-FTL",pid=367,fd=15))
tcp   LISTEN 0      32                               [::1]:53           [::]:*    users:(("pihole-FTL",pid=367,fd=11))
tcp   LISTEN 0      32     [fe80::a:b:c:d]%eth0:53   [::]:*    users:(("pihole-FTL",pid=367,fd=9))
tcp   LISTEN 0      256                              [::1]:8953         [::]:*    users:(("unbound",pid=363,fd=5))

But I just noticed “::1:5335” is not open?
I used dietpi-config to install Unbound, and enable ipv6, might need an extra configuration option to make it open ipv6 on port 5335?

How do I configure it to open “::1:5335”?

As stated above, this is not needed, and you could easily use IPv4 to connect from PiHole to Unbound. Usually, dietpi-software will set IPv6 inside Unbound configuration if we found a working IPv6 gateway.

Anyway, you could do it manually

G_CONFIG_INJECT 'do-ip6:[[:blank:]]' '	do-ip6: yes' /etc/unbound/unbound.conf.d/dietpi.conf
systemctl restart unbound

So I ran:

G_CONFIG_INJECT 'do-ip6:[[:blank:]]' '	do-ip6: yes' /etc/unbound/unbound.conf.d/dietpi.conf
systemctl restart unbound

and got this output:

[  OK  ] G_CONFIG_INJECT | Desired setting in /etc/unbound/unbound.conf.d/dietpi.conf was already set:  do-ip6: yes

I rebooted, but port “::1:5335” still not open?

you can check Unbound logs

journalctl -u unbound

As well, did you tried to configure PiHole to use IPv4 to connect to Unbound? (custom#1)
And just for testing. How does it behave if you select one of the IPv4 options for a global upstream DNS provider instead of Unbound? Again, for PiHole itself, it is not important to use IPv6 to connect to an upstream DNS server. IPv4 is totally fine. It’s just the user client that would need to have to IPv6 connection to PiHole.

journalctl -u unbound didnt provide any useful info, only that it had started unbound dns server.

I have in custom 1 dns upstream already.
It works fine for ip4 dns resolution.

Now my only issue is getting unbound to listen on “::1:5335” I have not been able to find a way to open that port on ipv6 unbound?

This is not really an issue for your use case. You are fine having Unbund running on IPv4 only. For your clients this doesn’t matter at all. Clients are just care on PiHole as PiHole is the only one who needs to LISTEN to IPv6 interface. This is described same way on PiHole wiki. There is no need for Unbound to LISTEN to IPv6

fe80 addresses are link local and they are automatically generated by the host as long as the ipv6 is active. They are not created after receiving a router advertisement. From RAs the hosts create the GUA and ULA addresses. It is also evident that pihole is not listening to [::]:53 only to [::1]:53 which is the localhost, hence it doesn’t respond to IPv6 queries.
Since you can see the RAs in tcpdump, but no GUA IPv6 is created, can you check if firewall is blocking these packets? All my dietpi hosts where able to acquire an IPv6 from RAs, DHCP6 was a bit more problematic, but this is not your case.

1 Like