I'm running Pi-hole on a Raspberry Pi 4 running Debian Buster 64-bit. Router is three-pack eero Pro 6. I have a GUA from my ISP Spectrum 2603:8000:3602:XXX::/64 and the router configured a ULA fd60:fee2:578f:XXXX::/64. All devices on the network show GUA and ULA, and are reachable/pingable on both addresses. I've assigned the Raspberry Pi a static ULA in /etc/dhcpcd.conf, and it now has two ULA addresses and one GUA. Pi-hole's setupVars.conf also shows the static ULA.
The weird thing is when I assign Pi-hole's ULA as IPv6 DNS through the router, the clients all get the address but almost none of the IPv6-capable clients use it (30+ clients, Linux/macOS/iOS/few others). Only my two LG TV's use the ULA, the rest use the IPv4 LAN address.
However, when Pi-hole's GUA is assigned as IPv6 DNS, all IPv6-capable clients use that almost exclusively. So, it's clear they prefer IPv6, but why GUA and not ULA? Does anyone have any ideas what could be the cause of this or how I could begin to debug it.
What's your motivation for using a static IPv6 address?
In general, I wouldn't recommend setting a static IPv6 address.
IPv6 is heavily emphasising auto-configuration, and setting a static IPv6 may interfere.
For once, if the respective IPv6 prefix for your network changes for any reason, you'd have to manually reconfigure your static client. If you were to run an IPv6 only network, that could also mean you are forced to access your RPi via its link-local IPv6 to do so.
Of course, a ULA prefix is less likely to change, as it is commonly controlled by you rather than your ISP. But I've noticed an abundance of ULA prefixes in your network.
According to your debug log, your RPi4's eth0 interface carries 8 IPv6 addresses, and 6 of those are ULAs, for a total of 5 different ULA prefixes.
Commonly, you'd only advertise a single ULA prefix in your network.
If you do not intend to use as many ULAs, you may want to revise your configuration.
One posssible explanation:
If the ULA prefix you've used for your RPi4's static IPv6 address isn't advertised by your router, your clients may not know how to reach that address, and thus fall back to IPv4.
@Bucking_Horn Thank you for taking a look at my debug log. The plethora of ULA addresses on eth0 are thanks to Thread. It may be Apple’s implementation is a little broken at this time, because our one Apple TV and three HomePod mini’s each set up their own ULA and incessantly send out RA’s. Syslog is filled with them, and there’s nothing I can do to change that, short of unplugging them lol.
The ULA fd60:fee2:587f:1::/64 is the subnet established by my router and being advertised along with GUA 2603:8000:3602:xxxx::/64. Which is so puzzling why clients will use the GUA exclusively when broadcast but don’t touch ULA when it’s broadcast.
Removing the static IPv6 assignment and broadcasting the Pi’s generated ULA produces the same result.
Solving the riddle of IPv4 preference over IPv6 ULAs would be a networking issue, rather than a Pi-hole one. I don't have any of that equipment, so can't reproduce it.
It could be that multiple IPv6 ULA prefixes have a negative impact on some client's source and target address selection (see RFC 6724 for details). EDIT: IPv4s may even be expected to be preferred over ULAs, depending on the prefix policy table a client is using.
Note that as long as your clients' DNS requests reach Pi-hole, there is no impact on DNS resolution:
Pi-hole will duefully return A and AAAA records as requested, regardless of whether a client communicates via IPv4 or IPv6.
I was leaning in that direction, but wanted to check here first in case anyone had an answer.
That's certainly possible, but with the growing popularity of Thread—which I'm not an expert on by any means—seems to be IPv6-only (from what I've gathered advertising multiple ULA's is expected behavior). If that is causing clients to prefer IPv4, doesn't that negate IPv6 and by extension Thread? Maybe I'm misconstruing things and I'm happy to be corrected to learn.
In terms of IPv4 being preferred over ULA's, wouldn't that also negate IPv6, especially if at least one ULA has a valid default route to a gateway? I'm thinking out loud at this point
I know that and Pi-hole has been amazing for the 2+ years I've been using it. My post is more about my curiosity with what I think is unexpected behavior, and if I learn something in the process I couldn't be any happier.
I could use a GUA which works very well, but the lack of hostname resolution in the admin GUI is not ideal. I can't manually enter many GUA's for clients since they use privacy extensions and can't disable them on many of my Apple products. I've tried looking for a script that does something akin to ip -6 neigh and updates a custom hosts file that Pi-hole can use for hostname resolution. I've thought of creating one but I don't know where/how Pi-hole stores MAC addresses that it references in Network Tables.
The source address a client picks is specific for a communication target, i.e. address selection is performed separately for any given combination of source and destination IP addresses, according to the client's prefix policy table (e.g. your client will use a GUA when communicating with a GUA target address).
While that table should be configurable, most users will likely go with the defaults as configured by the client OS. It would then depend on whether the OS maintainers would adhere to the older RFC 3484 default table (does not consider ULAs explicitly) or to the more recent RFC 6724 (already linked above - with IPv4 at a higher precedence than ULAs ), or whether they'd add their own flavour.
Reading through RFC 6724 (specifically the section 10 Default Source and Destination Address Selection examples) along with inspecting your client's prefix policies should allow you to figure your client's behaviour when communicating to one of Pi-hole's addresses.
