ULA prefix length for DHCP

Help
1

I also wanted to use pihole DHCP function to assign IPv6 ULA addresses to clients. The GLA is already assign by SLAAC and the router advertisement of my internet provider, but for internal functions on my server I want to only allow ULA addresses, as the provider prefix may change an this would require adaption of the iptables rules.
To achieve this I have disable ipv6 in the web interface and instead manually added a dhcp range in an additional config file:

dhcp-range=fd3e:64c2:2817:d97e::100,fd3e:64c2:2817:d97e::1ff,64,24h
##dhcp-range=fd3e:64c2:2817:d97e::,ra-names,slaac,24h
enable-ra
ra-param=*,0,0

This is working in principle, but the clients get an /128 prefix assigned by dhcp (which I want to use), although it is clearly stated that I want to use a /64 bit one. This way the clients have an address but still can not reach other machines in the local net. If I manually add the correct route in a client everything is working.
If I use the (commented) slaac statement instead the prefix and route are automtically generated by the clients and are correct. I think, this is a bug in pihole, or am I missing something?

2

Have you checked this? From the dnsmasq manual for that command

"there is an optional prefix length which must be equal to or larger then the prefix length on the local interface."

3

This is the config of the local interface, prefix length is 64:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.114.3  netmask 255.255.255.0  broadcast 192.168.114.255
        inet6 fd3e:64c2:2817:d97e::3  prefixlen 64  scopeid 0x0<global>
        inet6 2a02:xxxx:xxxx:xxxx:5ef4:abff:fe64:b0d4  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::5ef4:abff:fe64:b0d4  prefixlen 64  scopeid 0x20<link>
        ether 5c:f4:ab:64:b0:d4  txqueuelen 1000  (Ethernet)
        RX packets 116375607  bytes 192855099 (183.9 MiB)
        RX errors 0  dropped 1923  overruns 0  frame 0
        TX packets 14677943  bytes 3229682220 (3.0 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
4

Many clients do not or only have partially support for DHCPv6. This may be the reason here. Can you check how a different client with a different operating system does it?

Looking at the code, the DHCP server will send out the expected subnet on requests so my best assumption at the moment is that your client chooses to ignore it.

5

Thanks. I have tried with different clients already (all linux of course with current debian stable and unstable, using ifup/down on desktop or network-manager on laptops). I got the same result for all of them. I have also tried with dnsmasq instead of pihole - same result. How can I check what the server sends? Is there something like radvdump for dhcpv6?

6

My best bet would be tcpdump (which, despite its name, doe snot only capture TCP).

Something like

tcpdump -i <interface name> -n -vvv ‘(udp port 546 or 547) or icmp6’

(with sudo) should show only the relevant bits. The ports target DHCPv6 and icmp6 just to get some more context.

If that doesn't really work, you may want to try again with a less strict filter, like ip6 and ether src or dst 11:22:33:44:55:66 (replace the MAC by the one of your Pi-hole).

You cna also use the option -w output.dump to dump the received packets if you want to share them with us.

7

The netmask by itself is not an issue with DHCPv6 clients: It's normal for DHCPv6 assigned addresses to carry a /128 netmask, as DHCPv6 (unlike IPv4's DHCP) is just assigning that address.
IPv6 clients are expected to procure additional information on your network by other appropriate means as needed and to create their own proper routing from that information automatically (just as you've observed for slaac).

I tried to recreate your issue, but for the most part seemed to fail:
I found DHCPv6 client's routing tables to match the /64, and I had no problems pinging their DHCPv6-assigned IPs either (clients were running Raspbian Buster and Win8.1) - with one exception:
I couldn't ping client DHCPv6 IPs from my Pi-hole machine.
At that time, its network interface also didn't carry a DHCPv6 address.

After rebinding the network interface (sudo dhcpcd -n eth0), the former SLAAC ULA was marked as deprecated (as expected), but it still didn't acquire a DHCPv6 IP. It took a reboot to fix that, and then it was working.

In contrast to the rest of my network, my Pi-hole machine is using a static IPv4 address as defined in /etc/dhcpcd.conf. Since my other clients didn't have any issues acquiring an address via DHCPv6 nor pinging each other, I suspect that this may contribute, but I haven't looked further into that.

Also, I am not sure whether my observation of a failure on just the Pi-hole machine itself would actually match your report?

Did you observe failures to connect to your clients on each client?
Could you check whether your DHCPv6 clients can actually ping each other?

8

Thanks for all the help. Since my provider enabled dual stack I have all kinds of problems with ipv6. Main reason is, that the providers router sends out router advertisements every 4 second which I can not disable. On one of my laptops network manager creates a new temporary address every 4 second until I even loose ipv4 connectivity...
Back to pihole. What I found so far:

  • Prefix length is sent by router advertisement not by dhcpv6. (as Bucking_Horn wrote)
  • this works in principle with pihole but after some time the ra from pihole stop (or are sent very seldom only and not recognized by my machine any more, may be due to some kind of timeout). If I disconnect the router it works...
    I will try to force pihole to do ra every 4 s as my providers router does, may be this will help
9

That is crazy and likely some kind of misconfiguration let there?

Quoting the relevant man page section for you:

ra-param=<interface>,[mtu:<integer>|<interface>|off,][high,|low,]<ra-interval>[,<router lifetime>]
The priority field for the router may be altered from the default of medium with eg ra-param=eth0,high.

The interval between router advertisements may be set (in seconds) with ra-param=eth0,60.

The lifetime of the route may be changed or set to zero, which allows a router to advertise prefixes but not a route via itself. ra-param=eth0,0,0 (A value of zero for the interval means the default value.) All four parameters may be set at once. ra-param=eth0,mtu:1280,low,60,1200

10

I now get good results with the following settings:

    dhcp-range=fd3e:64c2:2817:d97e::100,fd3e:64c2:2817:d97e::1ff,64,24h
    #dhcp-range=fd3e:64c2:2817:d97e::,ra-names,slaac,24h
    enable-ra
    ra-param=eth0,5,0

Important is the interval time (5 in my case). The dhcp setting with slaac would also work but than I still have the issues with mass creation of temporary ipv6 addresses by network manager as described above. But on a different laptop also working with network manager I don't have that issue, so either it is hardware related or fixed in a newer network manager version.

11

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.