OpenWrt and pihole and ipv6

Hello, i have a pihole and an archer c7 with openwrt, pihole manage dns, openwrt manage dhcp, and everything is working fine, im using the conditional forwarding method on pihole, openwrt give the pihole dns as part of the dhcp request, devices ask pihole for a and aaaa records and pihole ask outside or openwrt as needed, now to my concerns:

Openwrt assigns correctly ipv4s, internal ipv6s (fd04) and external ipv6s to each device, ive seen that to fully disable dhcp on ipv4 i need to go to interfaces - lan - dhcp server section - general tab - tick mark on ignore interface and for ipv6 dhcp server section - ipv6 tab - dhcpv6 server - disable, is this correct or do i need to do something else?

What happens with the ipv6 pd when i do this? pihole will take over it and also assign ipv6 both internal and external to each device? do i need to manually set something on openwrt to move the external ipv6 management to the pihole? i know that its still early to move fully to ipv6 and some people simply avoid it because its complex and sometimes give more problems than solutions but in my case ipv6 worked fully ootb, since i installed openwrt on my router it got an ipv6 PD from my isp and gave correct internal and external addresses to my devices so i would prefer to keep a fully working dual stack after i do this move...

Thanks in advance for any help, this community is incredibly helpfull, i had some wireguard-on-openwrt problems about a month ago and i got exelent support and solved my issue :smile:

Why do you want to use the dhcp and dhcpv6 servers on pi-hole? It seems openwrt has more capabilities.

In the pi-hole source I can see that the IPv6 prefix is specified by configuring the interface. I guess you would need to configure the pi-hole interface using SLAAC, which would assign it a prefix for dhcpv6. And also disable dhcpv6 service on openwrt.

IPv6 (only) supports another type of range. In this, the start address and optional end address contain only the network part (ie ::1) and they are followed by constructor:<interface>. This forms a template which describes how to create ranges, based on the addresses assigned to the interface. For instance

--dhcp-range=::1,::400,constructor:eth0

will look for addresses on eth0 and then create a range from <network>::1 to <network>::400. If the interface is assigned more than one network, then the corresponding ranges will be automatically created, and then deprecated and finally removed again as the address is deprecated and then deleted. The interface name may have a final "*" wildcard. Note that just any address on eth0 will not do: it must not be an autoconfigured or privacy address, or be deprecated.

Its more a convenience thing than anything else, on the query logs on pihole it shows the ipv6 address of clients instead of the hostnames for some but i was seeing last night that that is "normal" since in occassion devices use temporary ipv6 to communicate and a few hours later the address is dumped by the device but stay on the pihole log so basically its a futile task to try to track that, im not sure if its a feature of the ipv6 stack or a bug (or rather lack of maturity in the implementation of ipv6) on behalf of either pihole or openwrt...(i was thinking that maybe pihole should get the hostname of the device the same moment the request is made and store it along the request)
So on one side its probably futile to setup this and on the other maybe pihole just need time to polish this issue on their app so im going to wait and see instead of opening a can of worms with high chances of changes in the near future...

This is a misunderstanding on your part. Once a prefix is advertised any machine on that network can immediately generate a trillion addresses and use them all. There is no one to one mapping between machine and DNS name and IP address.

Privacy addresses are never going to have names associated, even SLAAC are probably not, only DHCPv6 will and there's no reason to expect machines to use their DHCPv6 addresses for outgoing connections necessarily.

1 Like

So its normal if pihole show no hostname for addresses marked as temporary ipv6 and what i was trying to do was futile from the begining, right? so, not only there is no bug but in fact works as intended, right?

It probably doesn't show the hostname for non-temporary addresses assigned using slaac either, unless you have added those to an internal dns server manually.

BTW ip6neigh seems useful, but I haven't tried it myself.

Giving local DNS names to IPv6 SLAAC addresses [OpenWrt/LEDE shell script]

https://github.com/AndreBL/ip6neigh/

That still leaves out temporary addresses and im sure that at least 2 addresses on the pihole are of those temporarys (they are from 2 different desktop computers, checked with ipconfig, showing as "temporal" in the list) and im my case it was just a convenience issue and if im going to end with a partial and/or hacky solution anyway im going to leave it as is for now and wait and see in the future.

ip6neigh should support temporary addresses anyway.

`ip6neigh` uses DNS labels, which can be thought of as subdomains for the top level domain `lan` . Example DNS labels (in bold) that `ip6neigh` use are:

* Computer. **TMP** .lan (a temporary address)
* Computer. **LL** .lan (a link-local address)
* Computer. **TMP.GUA** .lan (a temporary GUA)
* Computer (no DNS label applied, e.g. a non-temporary ULA)

That even IPv4 DHCP carries a host name is a "convenience" and not a required part of the spec. A DHCPv4 client is neither obligated to provide a host name, nor to to accept that suggested in a DHCP lease. The "best" you can do is to reserve addresses for known MACs and hope that the others provide a host name in their requests.

As pointed out above, IPv6 address assignment is done very differently than DHCPv4. Unless you're on a managed network (most home users aren't), a client picks one of over a billion billion addresses in the prefix advertised by the router and uses it (after checking for the improbable collision in that many addresses). A client is free to choose any of its IPv6 addresses to communicate, subject to scope limitations (namely you can't use a link-local address to reach off-link addresses). A client is also free to change its IPv6 addresses at will (subject to preventing collisions) and many do so regularly.

Yes, this is "by design" of IPv6 for a variety of reasons, including eliminating the mess of DHCPv4.

1 Like

Im not complaining at all about the design of ipv6, i know that ipv4 was old (both aged and though for a much smaller www, on a time when researchers didnt even imagine the size of this monster that is nowadays (in a good sense)) altho i can see the need to "friendly-name" computers in an easy way specially in private environment (call them soho/home/smallbiz) without the need to manually edit a document on a server and enter manually a mac address (feels so 90s) but if thats the trend nowadays i guess im gonna need to use something like that ip6neigh script or wait and see if devs/netadmins think of alternate solutions now that ipv6 is starting finally to be allmost everywhere...or maybe ip6neigh or alternate similar solutions are going to be included on the base openwrt? anyway we are diverting heavily out of the subject here, thanks for the sugestions and explanations :smiley:

Yep, I think just leave as is. You'll do much better with DNS on the openwrt, because the openwrt is what is doing the prefix advertisement, otherwise every time you reboot your router you might need to change your pi-hole config or something.

It's not machines that get names, it's IP addresses. the point of the friendly name is to let you reach inbound to a service, so you can connect to myserver.lan via SMB or whatever. On the other hand, just because a machine responds to the ip address associated with myserver.lan doesn't mean it has to use that IP address for outgoing connections from itself.

So, yes you definitely need to friendly name all the server IPs that provide services to other people, but there's no point in hoping that all outbound connections from a given machine should always be resolvable back to a name associated with the ip used in that outbound connection.

1 Like

For pure organization on my part I only advertise the internal ipv4 address that way the logs show those addresses on my pihole, ipv6 is still resolved this way.

I use pihole + unbound.

Yea its was only a convenience issue, and i know that the hostname is assigned to the ip adress and all that, and i in fact have 2 sbc as servers with static ipv4 and ipv6 leases with proper names in my lan, but this was only to identify wich ip in pihole was doing requests to x or y site, pure convenience and something that i can totally live and work without, and yea ipv4s have hostnames as expected but i see a lot of ipv6s since most devices afaik use the temporary addresses pretty often to communicate
@mrpink57 you mention unbound but for what i can understand about it its not related with local hostnames, right? or i miss something that can apply here to solve the "issue" for wich i started the post? (the privacy part is something l allready wondered before tho)

once you realize that there's nothing keeping a machine from generating a brand new IPv6 for every single outbound request then it becomes obvious that it's futile to try to attach a name to each one. Imagine 1 million outbound requests a day, your database of names grows ridiculously large in just a few hours to a month.

Technology has to adapt to the man, not the other way around, that being said even if that is allowed by the protocol there is probably a problem if a single app is creating a million outbound connections a day (unless we talk about a true web server with 10k visitors per hour or more) and there is something that need to be corrected, and even if thats the case again tech needs to adapt to the man, there are compression algorythms so 1 million addresses + hostname + mac adress probably wont takemore than a dozen megs probably and if a mere sbc with 1,3ghz can compare a name to a 600000 addresses and give an answer in a timelly maner of a few ms (accepted or denied dont matter in this example) then storing a million addresses and compare to them every time they are asked for is a menial task...and yea, probably an sbc is more powerfull than most old routers BUT modern routers already include 2 and 4 cores and 1,2ghz and more...so yea, you make it seem and sound like a gargantuan task but in fact is not, and even if it is a gargantuan task again tech needs to adapt to the man, maybe we need to actually atach a name to an ip adress sometimes so the option maybe needs to be there...but again, we are diverting way far off track again lol

it becomes a denial of service attack if you try to do it. A malicious machine can literally send outbound requests on the order of millions per second with different addresses for each one. The addresses are generated at random so a compression algorithm can never make them smaller than 64 bits, and it will bring your machine to its knees in a few seconds to a minute. In other words there are reasons not to even try to make this a possibility. Unfortunately we have to consider the malware not just the properly functioning devices.

But I agree, this starts to get off topic, I just mention it because there are plenty of others who have similar ideas and it's useful to have an explanation in one place.

Millions per second actually sound like a DoS attack, millions per day can be a heavy weight server answering web requests but you are diverting even WAY further of track there, going back to topic i know it is a convenience issue only but maybe assigning hostnames to even temp ipv6 addresses needs to be included in openwrt, even if as a disabled option by default...

You might want to look into an IDS, rather than trying to shoehorn it into software that wasn't designed for the task of identifying and tracking hosts.

Sorry to be so noob, whats an IDS?