No address range available for DHCPv6 request via eth0

[nacifyas]

The issue I am facing:
I get the following warnings at the Pihole web interface:

no address range available for DHCPv6 request via eth0

Details about my system:
I am running Pihole with Unbound in one docker container according to this guide on top of a RPI 4B with Ubuntu Server 20.04 LTS
What I have changed since installing Pi-hole:
I've made some changes to the docker-compose file, resulting into this:

version: '3.7'

services:
  pihole:
    container_name: piholeDNS
    image: cbcrowe/pihole-unbound:latest
    hostname: 'pihole'
    domainname: 'pihole.domain.my'
    network_mode: 'host'
    cap_add:
      - NET_ADMIN
      - CAP_SYS_NICE
      - CAP_NET_RAW
    ports:
      - 53:53/tcp
      - 53:53/udp
      - 8083:8083/tcp
      - 5335:5335/tcp
      - 547:547/udp
      - 67:67/udp
    environment:
      TZ: 'Europe/Madrid'
      WEBPASSWORD: 'password'
      DNS1: 127.0.0.1#5335 # Hardcoded to our Unbound server
      DNS2: 127.0.0.1#5335 # Hardcoded to our Unbound server
      DNSSEC: "false" # Disable DNSSEC
    dns:
      - 192.168.1.57 # So the host itself uses pihole too (just a preference)
    volumes:
      - /media/volumes/piholeDNS/etc:/etc/pihole:rw
      - /media/volumes/piholeDNS/dnsmask:/etc/dnsmasq.d:rw
      - /media/volumes/piholeDNS/unbound:/etc/unbound:rw
      - /media/volumes/piholeDNS/lighttpd:/etc/lighttpd:rw
    restart: always

Set up nginx reverse proxy so I can access the web UI from outside the LAN.

Added two new entries from UPSTREAM DNS (IPv6):

Added blocklists and enabled DHCP from the web UI:

I've set up UFW firewall rules, allowing 547 and 67 both only over UDP and from 0.0.0.0 (I actually had my firewall disabled for sometime and I've still gotten the mentioned warning)

I disabled DHCP (for both IPv4 and IPv6) from my router gateway. And by the way, what domain does it refer to at the Pihole Domain Name section? My public one, or is this just for local use only?
And what is DHCPv4 rapid commit for?

Here is my debug token:
https://tricorder.pi-hole.net/7P05CS34/

So my devices seemed to be able to pick IPv4 addresses with no problem. Any help would be really appreciated. DNS resolution seems good, and I think it is working also for IPv6 (correct me if I am wrong). Please let me know if there is something wrong in my set up according to my debug token.

Will I see the IPv6 assigned by the Piholes's DHCv6 at the IP Leases section?

Thank you for the great work, and thank you in advance.

[jfb]

Please see this thread, which may answer all your questions.

No address range available for DHCPv6 request via eth0

Please follow the below template, it will help us to help you! If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category. Expected Behaviour: -operating system -hardware]_ Raspberry pi 4 Actual Behaviour: no address range available for DHCPv6 request via eth0 Debug Token: https://tricorder.pi-hole.net/0gLFnAMi…

[nacifyas]

Thank you so much for the quick answer.

I've already reached to that thread before with no success. I made sure that I only have one single DHCP server, and that one is Pihole's. Aside, I do want Pihole to offer DHCPv6 too which is where my issue is, in regard of the warning messages I've got from the UI as I mentioned before.

So what is wrong in my set up or what is needed to be done, in order to make pihole successfully do DHCPv6?

Thank you.

[nacifyas]

I had a look at the 02-pihole-dhcp.conf file in case it may help, but the IPv6 range is going from 100-1ff wich seems legit. I don't know what is the issue, and why I am getting the message No address range available for DHCPv6 request via eth0

###############################################################################
#  DHCP SERVER CONFIG FILE AUTOMATICALLY POPULATED BY PI-HOLE WEB INTERFACE.  #
#            ANY CHANGES MADE TO THIS FILE WILL BE LOST ON CHANGE             #
###############################################################################
dhcp-authoritative
dhcp-range=192.168.1.200,192.168.1.254,744h
dhcp-option=option:router,192.168.1.1
dhcp-leasefile=/etc/pihole/dhcp.leases
#quiet-dhcp

domain=lan
#quiet-dhcp6
#enable-ra
dhcp-option=option6:dns-server,[::]
dhcp-range=::100,::1ff,constructor:eth0,ra-names,slaac,64,3600
ra-param=*,0,0

[DL6ER]

@nacifyas

I do want Pihole to offer DHCPv6 too

But do you have upstream IPv6 connectivity? If not, there will be no routable address on the interface eth0 which could be used by Pi-hole to deduce the appropriate prefix (what comes in front of the configured ::100 - ::1ff) and, hence, the warning.

This is also what the documentation suggests:

[DL6ER]

@nacifyas

And by the way, what domain does it refer to at the Pihole Domain Name section? My public one, or is this just for local use only?

It is good practice to only use fully-qualified domain names (FQDN). This means a domain should always be at least one name under a top-level domain (TLD). Take, for instance, somethings.net - your Pi-hole will immediately know that this is a domain on the Internet. Now take laptop.lan - when lan is the Pi-hole domain name, it, again, immediately knows that this is a local (and local-only) client. Requests are, thus, never forwarded to any upstream server on the web (they couldn't answer the request in the first place).

Pi-hole still supports unqualified domain names (UQDN, i.e. without a TLD such as .net) so laptop will still resolve. It is, however, unclear if this is local or not. Pi-hole in standard configuration is configured to not forward such UQDNs but its always better to define the scope immediately through the domain.

@nacifyas

And what is DHCPv4 rapid commit for?

Rapid commit is standardized by RFC 4039. The introduction explains it well:

1. Introduction
In some environments, such as those in which high mobility occurs and the network attachment point changes frequently, it is beneficial to rapidly configure clients. And, in these environments it is possible to more quickly configure clients because the protections offered by the normal (and longer) 4-message exchange may not be needed. The 4-message exchange allows for redundancy (multiple DHCP servers) without wasting addresses, as addresses are only provisionally assigned to a client until the client chooses and requests one of the provisionally assigned addresses. The 2-message exchange may therefore be used when only one server is present or when addresses are plentiful and having multiple servers commit addresses for a client is not a problem.

You will see this in clients registering faster in your local network. It is generally a good thing, however, only if the constraints (highlighted above in italics by me) are satisfied. This is not always the case as, sometimes, users have router and Pi-hole distribute DHCP - which should obviously be avoided as it can cause a lot of issues. The extra protection without rapid commit can often safe your network from collisions in this case, though.

[nacifyas]

Thank so much for your both responses.
I have IPv6 enabled in my router, I have local IPv6 local addresses on my devices:

$ ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:cd:22:f6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.57/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::dea6:32ff:fecd:22f6/64 scope link
       valid_lft forever preferred_lft forever

But as you've said I was missing the upstream connectivity without my knowledge, and it seems to be the issue, coming from my ISP.

To get out of doubt I've restored DHCP (v4 and v6) to router, stopped my pihole container, and accessed IPv6 test sites:

I just assumed I have IPv6 because I was seeing IPv6 addresses in my devices, and in my router.

Thank you for your great assistance.

[DL6ER]

Those fe80:: addresses are so-called link-local addresses and are always generated by the devices themselves. They are not routeable and, as such, do not even work across routers and cannot be used to access anything on the web. For instance, if you'd have a separated network like a guest WiFi, these IPv6 addresses could not be used to communicate with each other.

In your case it is safe to just leave the DHCPv6 box unticked.