How to set up IPv6 for Pihole correctly?

I recently bought a new router which I have not debranded yet, so I can't turn off IPv6.
The problem is that there is no option to assign a static IPv6 address so I have to manually update it when I reboot the Pihole.

Is there an automated solution to this?

1 Like

How are IPv6 addresses assigned in the first place? Is the router providing stateful DHCPv6? SLAAC addresses are generally static unless the originally generated address was taken by another device (the chances of this are practically zero).
You can assign a static IPv6 address on the host machine of pihole with dhcpcd5 by adding static ip6_address=<address_of_choice> to /etc/dhcpcd.conf.

With IPv6, clients may join a network using SLAAC, Stateful or Stateless DHCPv6.
Only the latter is similar to DHCP for IPv4, where a DHCP server assigns an address to a client requesting one.

In all other cases, a client will construct its IPv6 addresses autonomously, procuring information as required. Most importantly, a public IPv6 prefix (as offered by a router or a DHCPv6 server) is picked up by a client for constructing a public address. The same is true for a local ULA prefix, provided that's available.

Chances are that your IPv6 addresses aren't static.
In fact, they are even designed to change, depending on both your client's and your network's configuration.

When considering an IPv6 address for Pi-hole, you should probably avoid using a public address (2000::/3 range) altogether: Not only is Pi-hole not meant to be publically available, but with a public IPv6, both your IPv6 prefix and the interface identifier are subject to change (the former by your ISP, the latter by IPv6 Privacy Extensions and the likes), and Pi-hole requires a stable address.

That said, I'd advise against manually defining a static IPv6 address in dhcpcd.conf, unless you are familiar with IPv6 and willing to also manually handle IPv6 prefix changes as potentially imposed by your ISP (some ISPs routinely shift IPv6 prefixes for consumer plans).

To keep at least a stable prefix, you could configure a ULA prefix (if your router supports it), and have your router advertise Pi-hole's ULA address (fd00::/8 range).

If using an IPv6 ULA address is not an option with your router, try using your Pi-hole's link-local IPv6 address instead (fe80::/10 range). Link-local addresses are also the least likely to change.
However, note that such an address is only accessible for devices on the same network segment.

You can list all current IPv6 addresses for your Pi-hole by running:

ip -6 address show
1 Like

Thank you for the detailed explanation. This seems really comlicated to me and I wonder why it is not added into the tutorial. It just says "Turn off IPv6, but without debranding the router I can't.

I tried setting up a static adress by entering

interface eth0
static ip_address=192.168.184.34/24
static ip6_address=xxxx:4540:xxxx:e900:xxxx:xxxx:xxxx:d6e5/64
static routers=192.168.184.1

in my /etc/dhcpcd.conf but the IP adress is still shown as dynamic when I list it via ip address.

Ah I just tried the link local address by just adding fe::80 as you suggested and it seemd to work.

Thank you! :slight_smile:

Ah no it doesn't work. I can't download new effects from the KDE server when I have it activated. Something is still not right :frowning: Other websites work though. Really weird!

I'm using pfsense "track interface" to assign IPv6 addresses, works perfectly. If you have an IPv6 DHCP service running somewhere on your network, you shouldn't need to assign a static entry on the pi, however it is is possible to do this.

The easiest way I have found to assign an (additional) static address to the pi ( tested on Raspberry Pi OS Lite, Release date: January 11th 2021) is to create a file /etc/dhcpcd.exit-hook, content (example):

#add secondary IP address
if [ "$reason" = "PREINIT" ]; then
        sudo ip -6 addr add fdaa:bbcc:ddee:2::5552/128 dev eth0
        sudo ip -4 addr add 192.168.2.120/24 dev eth0 label eth0:1
        exit 0
fi

example for IPv4 and IPv6, both are possible, simultaneously, change the addresses to suit your needs.

Have a look whether the KDE server is blocked by some of your blocklists.

See How do I determine what domain an ad is coming from?

EDIT:

Which tutorial are you referring to?

Just because this is not known to anyone - and because the world of IPv6 is really different than IPv4 - let me stress again what @Bucking_Horn said above, just to avoid any possible further frustration: While DHCPv6 may work, it is certainly not the right way of assigning IPv6 addresses. I say this because IPv6 addresses should not be assigned at all. IPv6 is a protocol made for auto-configuration. While DHCPv6 may work, there are many devices that do not support getting configured by DHCPv6. They may only partially pick up the assignment or chose to ignore it altogether.


This is very much in contrast to the IPv4 world with DHCP. (I'm simplifying below to make it easier to understand):

In the IPv4 world a new client actively asks the network:

Help, I'm new, I don't know anything. Please tell me what to do.

A DHCP server (or multiple if you have multiple, but that's more involved, assume only one here) replies to the client and tells it:

Don't worry, here is what you need. I also already have an address for you. Use this one plus that DNS server, etc.

With IPv6 it is somewhat different. Instead of coming and actively asking for help, not being able to do anything until you get the response from the DHCP server, the process is a multi-step one, without the need for one DHCP server.

  1. The client comes up with a (hopefully unique) link-local (LL) address. This is typically build from it's MAC address (which should be unique).
  2. It sends out a neighbor solicitation (NS) packet to the broadcast address to check if there is already another device with this address. If a neighbor advertisement (NA) is received, it tries again with a new LL address. If not, the LL address is not used and can be used for this client.
  3. Since the client can now communicate within our local network (we have a valid LL address), it wants to also get a global address for communication beyond its local network (typically the Internet). Hence, it sends out a router solicitation (RS) packet (from the LL address to ff02::2 which is the "All Routers Multicast Address").
  4. All routers on the link will reply with router advertisement (RA). Containing various bits of information, but always the address prefix to be used and, most often, the DNS information for the network.
  5. The client uses the prefix to generate its own global address (global unicast address, GUA).
  6. The client repeats the duplicate address check already described in step 2.
  7. The auto-configuration is done.

Nowhere in the steps above, we needed a DHCP server. This is what the standard wanted to have and what we call SLAAC (Stateless Address Autoconfiguration).

I'm also writing this text here to be used in an introduction/tutorial later to - hopefully - improve understanding of IPv6. It is unfortunate now that you cannot change the DNS settings broadcasted by the router without rebranding. This is a clear defect of the router. If you can disable/change the DHCP server for IPv4, you should also have the ability to do the same/similar for IPv6's RAs.

Coming back to where I started (DHCPv6): This SLAAC is (must!) be supported by all the devices according to the standards. DHCPv6 has been standardized for clients that need more than can be provided by RAs, e.g., network boot options. It somewhat organically grew over time to be able to do even more, now including assigning addresses and handing out DNS server addresses. However, a lot of possibilities showed that the developers did not always understood the entirety of the new SLAAC way of handling addresses and a lot was rolled back later on. As a consequence, we have a vast amount of diverging implementations out there. Linux does it differently than Windows, Android does special things and Macs just ignore a lot of other options.

There is no one way to do it right. SLAAC is the best one but if you cannot change the router's configuration in what it broadcasts as DNS server, you'll really have a hard time.

TL;DR:

if you're experiencing issues. Yes, you will loose some performance bits here and there, however, the vast vast majority of the Internet will be reachable over IPv4-only for a very long time. Once the trend goes towards IPv6-only, router vendors will give you more options because their customers will ask for them.

1 Like

I do assign static IPv6 addresses on my pi, using the above described method (/etc/dhcpcd.exit-hook)

I use this to identify the different resolvers pihole-FTL is forwarding DNS requests to.

My hosts file contains these entries:

# dnscrypt-proxy v2
127.10.10.4     dnscrypt-IPv4
fdaa:bbcc:ddee:2::5554  dnscrypt-IPv6

# unbound
127.10.10.2     unbound-IPv4
fdaa:bbcc:ddee:2::5552  unbound-IPv6

the IPv4 addresses simply work, you don't have to do anything to use them in the configuration files of unbound and dnscrypt-proxy. The IPv6 addresses are assigned, using the above method (/etc/dhcpcd.exit-hook).
In my setup, these adresses are only useful on the pi, allowing pihole-FTL to forward to unbound and dnscrypt-proxy

Why? for this result in the dashboard:

I agree you should not assign GUA addresses, in any way (static or DHCPv6), this should be handled by auto-configuration, my pfsense assigns GUA addresses (track interface) to devices, derived from the IPv6 address my provider assigns to my routers WAN interface

You (DL6ER) once said "without IPv6, you're missing out on a big part of the internet". That is what triggered me to research and setup IPv6 on my network.
You also said on this forum, communicating over IPv6 is faster (more efficient) than IPv4, I hope you still support this statement.
So disabling IPv6? NO. Research the problem and try to fix it...

For sure, which is why I said


Disabling is the solution for those who don't want to do this or cannot afford the time. Starting learning IPv6 for a complete beginner is ... a steep and stony path. Not so much if you already have networking experience.

For inter-communication between Pi-hole and a co-located unbound, one address does suffice. There is nothing to be gained by supplying an IPv6 in addition to an IPv4 address, or vice versa.
I'd drop the respective other, which in your case would have me prefer IPv4 since that already simply works, as you put it. :wink:

I looked for that immediately and it isn't. Other websites are failing too. I think it didn't work at all and there were just a few websites left in the DNS cache.

This one

but it seems I remembered it wrong. It says to either use IPv4 or IPv6.

My Pi shows me this link local address, but it doesn't work

   inet6 fe80::f9d8:a73b:2fb6:8839/64 scope link 
       valid_lft forever preferred_lft forever

I have a Fritz!Box 7590 which is on of the best routers out there. The provider restricts a few settings with its branding. I had to debrand the older Fritz!Box to even set up Pi-Hole as the only DNS server.

I still don't really understand what to do. It is really overwhelming how complicated IPv6 is. I am also at the end of my studies, super busy and not able to learn anything new.

Your initial issue of setting up IPv6 seems to have been solved:

Your subsequent observation is not related to configuring IPv6, but rather about blocking of sites you wish to access (note that there won't be any blocking by Pi-hole if it would be by-passed by IPv4 or IPv6):

As already suggested, failure to resolve a domain is typically related to your choice of blocklists.

Download problems in general may also be attributable to other causes, e.g. temporary high server load.

If this happens again, keep a close watch of Pi-hole's Query Log and try to establish whether this is actually related to DNS by running nslookup for the domain in question, once via Pi-hole and once through a public DNS server.

It may also be favourable to open a new topic for this, as this seems unrelated to IPv6.

Well, I have the same one (next to a 7530) and disagree. They are rated based on simplicity of configuration and hoe the average user can use them. That's all. I bought a WRT54GL some ten years ago and used it for a long time. It ran OpenWRT and gave me the full control of everything. And it was on the order of 50 € back then admittedly, it didn't have an embedded VDSL modem as this didn't exist back then). Just to put this in comparison... Yes, AVM uses Fritzbox to make a router that tries to fit everyone. However, they still limit heavily what can be configured by the user and what not. Giving less options also makes the support easier because there are less possibilities to break things.