Client assignment IP/MAC?

Through my work, I recognize how more and more Internet providers distribute dual-stack routers where the user / admin cannot set anything. There is not even a portal that you could visit, maybe just a reset button and a larger one to deactivate wifi.
On the client side there are hardly any devices without IPv6, and also - especially with mobiles - it is less and less possible to set or deactivate anything. In such a environment, this means that your IPv4-only-pi-hole is completely bypassed by using IPv6. Precisely because in such cases there is simply no way to do without IPv6.
Furthermore, I am firmly convinced that IPv6 will be needed more and more in a modern network. Certainly not because it is too big for IPv4, but to ensure communication with the IPv6-based internet.
I know I know, there is also the IPv4 to IPv6 translation, but nobody really wants that, and is usually not used in a standard routers.

Do these devices / routers not allow you to use ULA space under the network admin's control? Do they require you to use GUA addresses that open up every device to remote access? Do you need to have globally routed IP addresses on every client?

The only time I have ever seen the need for GUA space on a LAN is for getting around CGNAT to give remote access to a DMZ'd device. So, extremely rare.

As to an IPv6 based internet, we've been talking about that since I got my college degree and the paper that was printed on has turned to dust from old age.

  1. No, mostly everything is already specified using prefix delegation (i guess).
  2. No, unique local addresses are used (fc00::/64 or similar).
  3. And again, no, it's a local network after all.
  4. Then you know that it is unstoppable. :wink:

:~$ ping6

PS: By the way, this forum is also accessible without IPv4 as only with IPv6. ..Just to say.

I know how this forum is accessible, I set up the servers and I control the A/AAAA records.

My points fall on deaf ears so I'll back out of the conversation now.

North America is officially, out of IPv4 addresses since 2015. They all have to change their network or do IPv6 tunneling because every new internet connection has been IPv6 only for 5 years. There is no way back. Pi-Hole 4.5 is ready for this and works. Pi-Hole 5.0 too, but the new function cannot handle it. Or it only works under certain conditions.

In my opinion this is a problem, not necessarily a known error, but a problem that should be solved. I'm very sorry to say but idealistic views - as much as I share them - will not change this.

Ah, yeah, like I said. Most people asking about IPv6 just don't know what they are talking about. Thanks for proving my point.

1 Like

My pleasure. Now that you know what it's all about, it may be easier to take care of client management from pihole. :wink:

Maybe it could be an idea to make sure that all ip's of a client can be assigned to a group at once. Could this possibly work based on the client-id?

Please enter a new feature request with a good description of the changes you recommend.

Sure, it could be an idea. Open a feature request. We'll implement it soon after IPv4 addresses are actually out and no longer used by the vast majority of internet traffic.

Thank you very much, I will take care of it as soon as possible. I hope you understand if it takes a while, you know because of all the new routers ..

Until then, and thanks again.

The underlying issue here is a technical one. And note something easily or straightforwardly to be solved. I know, a lot has been said in here already, however, let me quickly summarize what the issue is.

Why don't we use MAC addresses for client recognition?

Using MAC addresses instead of IP addresses is not going to work for (at least!) two reasons:

  1. Many users operate devices which are not immediately connected to the Pi-hole, like (FritzBox) guest networks, VPN-connected clients and other VLAN configurations. The MAC address will not be available for them.
  2. The IP address is what the DNS server sees as source for an incoming query. It is also where the reply is sent to. Comparing incoming IP addresses against IP addresses (possibly with subnet information) in the database is fast and we can cache the result.
    Speed matters, especially on low-end hardware such as embedded board like the Raspberry Pi or even lower-end devices. If we'd have to do an additional lookup, trying to relate the current IP (again, this is all the DNS server sees) to some MAC address (mind, this correlation may not even be possible for many devices) and then look up this one in the database being prepared for a fallback if the MAC address was not found (do we resort to using IP addresses then?) adds more and more I/O which will make DNS resolution slow. This is not a good thing.

Changing IPv4 addresses

Caused by using non-deterministic DHCP servers. This can be resolved by using a deterministic DHCP server (like the Pi-hole built-in one). Alternatively, static assignments (whilst this is only fixing the symptoms, not curing the disease).

Changing IPv6 addresses

Caused by maybe alternating prefixes, maybe privacy extension. Suggestions on how to address this, having aboves point in mind, are welcome and could very well go into a v5.1 or v5.2. I see no issues with this if we can find some good solution.


Very good explanation, thanks for that.

What about a DHCP6? Would it be possible to fix the IPv6 clients with static DHCP6 leases and to attach a checkbox at http: //pi.hole/admin/groups-clients.php to configure (together with the searchbox) all IPs of a client in one go ?

DHCPv6 is really a bad idea in my mind. IPv6 was intentionally designed to allow stateless IP address autoconfiguration (SLAAC). When stateless autoconfiguration is deployed, the host essentially grabs its own IP address with no need for an additional protocol like DHCP.

Why DHCPv6 is a bad idea has been explained numerous times, so repeating the story once again seems a waste of time, please check, for instance,

If we'd go with the conclusion there,

If you’re running a dual-stack environment, with both IPv4 and IPv6, then it probably makes sense to use DHCP and DHCPv6.

We could use UIs (unique identifiers) and MAC addresses for client identification. Still, this leaves all those devices who are outside the scope of the DHCP server, such as VPN or VLAN connected devices. I'm really not seeing a solution as of now. I feel the necessity to avoid patchwork configuration (some identified this way, some the other). It will be very complicated to understand, configure and debug such configurations.

1 Like

Yes, you're absolutely right, that's bullshit. I'm tired, and that's probably why I'm a little distracted. My thought was STATIC PRIVATE SLAAC's. How did I suddenly get to DHCPv6? I do not know.
Whatever, the current state cannot remain. I have an iPhoneX in my network that has 180 entries so far. Only one of them is an IPv4. For comparison: The Philips HUE Bridge has 3 entries, the Sonos Play even only 2 (1x IPv4 and 1x IPv6).
The iPhoneX is certainly the worst, but nothing is the only thing that has so many entries. All of them can be assigned to the corresponding groups. Especially in a larger network - with me <120 clients - Pi-Hole quickly becomes a full-time job.

As much as I hate saying this, it may come down to: In this case, you maybe cannot use this feature now. Only when we find another way to do this which is currently unknown.

1 Like


Well actually I can, but it is not practical and I have to limit myself to a maximum of 1 or 2 groups. Unassociated and maybe Unfiltered too. But that v5.0 works like a somewhat better v.4.5 was not the idea during development, right?

In this respect, I am fully with you.

180 IPs! Have you put any effort into determining why your iPhone X is accumulating that many different IP addresses? Over what period of time?

Yes, but without much success. It is clear that all Apple devices have an exceptionally large number of entries. It also shows that mobiles have more entries than computers, and that the more new they are, the more entries they have.

Here are the current figures:

iPhoneX - 181
iPad Pro - 91
iPhone 6s - 72
MacBook Pro - 18th
MacBook Air - 9

All of the five devices are only recorded via wifi, and as you can see on the iPhoneX, new entries are being added on an ongoing basis.

From the iPhone I now know that you can only renew the lease. It is not possible to change the IPv6 settings, or at least to deactivate them. There are instructions in the network, but only for celullar, not for wifi. The iPhoneX holds 3 IPv6 addresses that are continuously exchanged individually. At what intervals, or why is not yet known to me.

I have taken the trouble to record all known clients that have been registered with domain, and to assign device-specific groups. That's where the numbers come from. In the meantime I have assigned over 500 entries and there are still many known clients without client-id.domain left. It is therefore difficult to assess whether the number of private slaacs is still growing or is already complete. If the latter is true, I could imagine that an iPhoneX, for example, has around 250 IP's that rotate at unknown intervals. If the latter were true, I could imagine a function with which all visually listed can be assigned to one or more groups at once.

Example: You use the search box to search for iphonex, set a jackbox for "config all" and then set up everything that was found in one go.

It would still be a lot of work the bigger the network is, but at least a little less.

Another thing: All five devices receive a static IPv4 from DHCP. Just so - not that you think it would be somehow different. :wink:

Would you have some samples for IPv6 addresses, preferably from one client only, and from the three different IPv6 ranges, i.e. both privates and public? Also, which device is acting as your network's DHCP server?
Feel free to obfuscate the second half of the identifier part a bit, I am mainly interested in the prefixes right now.