Pihole DHCP not assigning ipv6 address to clients

my ISP supports ipv6 and it is enabled, my router has public ipv6 address.
I've manually set static ipv4 and ipv6 address to my raspberry through /etc/dhcpcd.conf:

slaac hardware
interface eth0
        static ip_address=192.168.0.xxxx
        static routers=192.168.0.x
        static domain_name_servers=
        static ip6_address=2804:14c:65e4:xxxxx
pi@retropie:~ $ ip -6 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2804:14c:65e4:xxxxx/128 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:xxxx/64 scope link
       valid_lft forever preferred_lft forever

IPV6_ADDRESS is set in /etc/pihole/setupVars.conf.

Then I've switched off DHCP from my router (bad router, provided by ISP) and now my pihole has DHCP enabled for both ipv4 and ipv6, using " Enable IPv6 support (SLAAC + RA)" enabled.

ipv4 dns sinkhole and dhcp is working fine. But ipv6 dhcp is not working. My windows client workstation used to have ipv6 assigned when DHCP came from router...now that is set from pihole, dhcp only works for ipv4 and not ipv6.

Aug  1 17:44:24 dnsmasq-dhcp[1371]: RTR-SOLICIT(eth0) 24:18:1d:ba:dd:ad 
Aug  1 17:44:24 dnsmasq-dhcp[1371]: DHCPDISCOVER(eth0) 24:18:1d:ba:dd:ad  
Aug  1 17:44:24 dnsmasq-dhcp[1371]: DHCPOFFER(eth0) 24:18:1d:ba:dd:ad 
Aug  1 17:44:24 dnsmasq-dhcp[1371]: DHCPREQUEST(eth0) 24:18:1d:ba:dd:ad 
Aug  1 17:44:24 dnsmasq-dhcp[1371]: DHCPACK(eth0) 24:18:1d:ba:dd:ad Samsung-Galaxy-S7-edge

Expected Behaviour:

Pihole DHCP should assign ipv6 address do clients

Linux retropie 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux
pi@retropie:~ $ cat /etc/*release*
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION="9 (stretch)"

Actual Behaviour:

Pihole DHCP not assigning ipv6 address to clients

Debug Token:


Defining a public static IPv6 address has a different quality than defining a static IPv4.
For once, you will have to manually adopt changes in the IPv6 prefix (which is controlled by your ISP). And you have to consider that IPv6 prefix in your assignment as well, lest your Pi-hole would assume a /128 netmask, and that wouldn't leave nay space for any additional clients in your network.

If you want to stick with a public address, don't forget to define an appropriate netmask:

        static ip6_address=2804:14c:65e4:xxxxx/64
1 Like


Thanks, putting ipv6 netmask in dhcpcd.conf resolved my problem. Now pihole dhcp server is assigning ipv6 address to clients normally.

I know I'm getting out of scope here, but I was also expecting to pass public ipv6test sites (like https://ipv6-test.com/ or https://ipv6test.google.com/), but I'm still failing...When my router was the DHCPv6 server, it was passing the tests...any tips to why is this occurring?

I'm newbie in ipv6, I know what is my public ipv6 and I put that public ipv6 into

static ip6_address=2804:14c:65e4:xxxxx/64 --> public ip address, but not sure if 64 is the correct netmask

Thanks again

I've never used those.
Maybe inquire at the site owners about how they derive at their conclusions?

If that's meant as a question, I do not know the answer - your ISP may.

I suggested a /64 as the first 64 bits of an IPv6 address constitute an IPv6 prefix, so technically, it is sufficient to distribute the whole lot of them as prefix in your network. Your ISP may grant you a larger net by assigning e.g. a /56 prefix (though that's unlikely for private plans). As long as you do not subdidvide your net into additional subnets in that same public address space on your network, you should be fine with a /64.

Let me re-emphasise that by assigning an IPv6 address statically, you essentially preclude your Pi-hole machine from acquiring relevant network parameters that you'll have to provide manually if you need them, and by using an IPv6 public address, you run an increased risk of exposing your local DNS traffic (depending on your router's IPv6 firewalling.

1 Like