IPv6 security considerations about temporary/random address


I have a question about security considerations regarding temporary IPv6. Now with native IPv6 I got each device directly accessible from the internet at its DHCPv6 IP (if it wasn't all blocked by the routers firewall which is good)

Anyways, for some reason, IPv6 Temporary Address / Address Randomization is disabled. That' s from the pre-IPv6 days, not sure why I configured it this way.

Now how important is this setting for IPv6 security? Should I re-enable temporary address or can I leave it the way it is?

While it was enabled by default, I remember issues with pihole -r detecting some temporary address and using it, which lead to run pihole -r again whenever it changed. Since I got DHCPv6, I hope pihole -r will detect the DHCP-assigned address and use it.

Screenshot 2021-07-15 163417

General IPv6 question about security. Since every device has its unique IP without NAT, portscans on my Pi-Hole DHCPv6 IP result in showing a lot of filtered ports. Looks like the screenshot (from Windows PC but Pi looks alike).

Is it supposed to look that way with IPv6? How important is now to run additional firewall on Pi-Hole?

First of all:
Security =/= Privacy
Since you are connecting to the internet with the unique IP address of the device, having a permanently static address makes it easier to track you. With NAT, each device seems to have the same IP address and so you gain a little obfuscation of what device is actually connecting. You don't have that anymore without NAT66.

Having regularly changing IP addresses alleviates the problem of tracking and provides a little more privacy, but I don't think you gain any significant security benefit from that.

On a different note, does the generation of temporary addresses even work with stateful DHCPv6? I thought you must use SLAAC for automatic generation of temporary addresses. Need to check that again.

I'm pretty sure that just changed the IP address that is displayed on the settings page and checked for in the debug log. That shouldn't have mattered for Pi-hole's operation, though, as long as you gave your clients the static IP address.

You should check in the documentation of whatever software you used for the portscan to find out what Filtered really means. Maybe also do the portscan from outside your network to see what your router's firewall is doing. That should still do its job of blocking traffic that you didn't explicitly allow.

1 Like

Thats a good question. I experience Linux clients and other devices like Smart TVs / Cellphone getting assigned one global DHCPv6 IP, which seemingly is the ISP prefix plus parts of the link local fe80:: address. Together its the EUI-64 if I understood this correctly.

So then Windows clients come into play and they are confusing me. In addition to EUI-64 and link local IPv6, Windows 10 apparently generates a random IPv6 for every connection it opens. At least it feels that way.

My Windows PC has always something between 20 and hundreds of temporary addresses. Not sure if that is even SLAAC doing the randomization, or rather its some special Windows way of doing things.

I don't think Windows even uses all those generated addresses, since in Pi-Hole Network Table I see the Windows Clients with only three IPs assigned: IPv4, EUI-64 and link local IPv6, not those 200 random/temporary.

That I had before DHCPv6, when there was only ULA and some random EUI-64 for each client, causing each client have 20+ IPv6s in Pi-Hole network table and Pi-Hole unable to determine IPv6 hostnames for stats correctly. That finally changed with proper DHCPv6 and now all hostnames are know to Pi-Hole.

No. EUI-64 in IPv6 refers to a method of constructing an interface identifier (64 bits) from a network interface's MAC. An IPv6 address can then be constructed by combining that interface identifier with any given IPv6 prefix.

No, it doesn't on the client side (edit: however, a client may request a temporary address from a DHCPv6 server (see RFC 8415 section 6.5)).
But providing a DHCPv6 server in your network would not stop a client from constructing IPv6 Privacy Extension addresses (RFC 4941) for itself in addition to any addresses acquired by DHCPv6. You'd have to additionally adjust your router's an/or your clients' configurations to make sure that only DHCPv6 would be in effect. If IPv6 Privacy Extension address is present, most OSs will prefer to use it, at least for connecting to public IPv6 IPs.

Once such an address expires (when its preferred lifetime (RFC suggested default: one day) has been reached), it becomes deprecated, i.e. it won't be used to newly establish outgoing connections - but it will remain active to receive incoming traffic until it becomes invalid (RFC suggested default: 7 days).

On Windows systems, those preferred lifetime and valid lifetime parameter values can be queried by netsh interface ipv6 show privacy. For Debian systems, try sudo sysctl -a | grep ipv6.*lft.

None of the above is related to Pi-hole - please also consider consulting other forums that focus on IPv6 networking.

Thanks for all your answers, sorry me being a bit off-topic. I still have one unsolved mystery with IPv6 and my Pi-Hole.

To access my PiVPN also running on the Pi-Hole server, I need to create an IPv6 Port Forwarding in the FritzBox. However, this requires an Interface ID.

The Pi-Hole is the one single device on my LAN that does not tell the FritzBox its interface ID.

It looks like this in the router. As said, all other devices have their interface ID filled in here, just not the Pi.

So now AVM Support told me this to "fix" it and get interface ID provided:

Access from external via port forwarding is done in FRITZ!Box by specifying a non-changing identifier of the device. This is usually via EUI-64-based identifiers with FF:FE derived from the MAC address. For its own outgoing IPv6 traffic of the client service, the operating system then uses the randomized temporary identifiers for privacy reasons.

Here in your case the operating system apparently does not provide an EUI-64 based identifier. It looks like Linux, presumably you can, or rather would have to enable it there.

How would I enable EUI-64 on Pi-Hole?

Or any known common places where I should look for possible misconfigurations causing the issue?

Would it work if I just calculate it with https://eui64-calc.princelle.org/ (the part with "end of IP address seems to be what I want) and enter it manually in the FritzBox port sharing setup screen?

You don't, for the simple reason that Pi-hole isn't involved at all.

IPv6 address configuration is part of your OS networking stack.

Also, you wouldn't need a public IPv6 address nor any router side port forwarding for Pi-hole's operation.

It is your VPN server software that necessitates those requirements (and it is not apparent whether IPv6 would be required or could be avoided altogether).

Again, none of this is related to Pi-hole.
As said before, you should consider consulting other forums that put their focus on your immediate issue (i.e running a VPN server in a home network with IPv6).

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