Pihole + IPv6 + privacy

Help Community Help
1

running Raspberry Pi OS (32-bit) Lite (Linux raspberrypi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux)

On Windows 10, privacy extensions are enabled by default. This implies my IPv6 address, used to connect to the outside world changes regulary, making it harder for the outside world to identify me (unless of course I have to authenticate to use the service).

Apparently, Raspbian also has the option to use privacy extensions, disabled by default. The default setting implies that all my DNS request originate from the same IPv6 address.
I'm already using unbound, this setup implies that no one party is able to identify my browsing habits, however, the frequently visited parties still can identify when and how frequently I request DNS info from their nameservers.

I was looking into this, and found some interesting links, here, here and here, which resulted in the following configuration:

# https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
net.ipv6.conf.eth0.use_tempaddr=2
net.ipv6.conf.default.use_tempaddr=0
net.ipv6.conf.eth0.temp_prefered_lft = 7200
net.ipv6.conf.default.temp_prefered_lft = 86400
net.ipv6.conf.eth0.temp_valid_lft = 9000
net.ipv6.conf.default.temp_valid_lft = 604800

After activating this configuration, ifconfig now shows:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.249  netmask 255.255.255.192  broadcast 192.168.2.255
        inet6 2a02:1810:xxxx:6903:496f:yyyy:819a:zzzz  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::18f:25da:8971:5687  prefixlen 64  scopeid 0x20<link>
        inet6 2a02:1810:4d02:6903:cc3b:9557:84b1:23e5  prefixlen 64  scopeid 0x0<global>
        ether b8:27:eb:29:72:97  txqueuelen 1000  (Ethernet)
        RX packets 832  bytes 662692 (647.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 789  bytes 97365 (95.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

2a02:1810:xxxx:6903:496f:yyyy:819a:zzzz (masked) being the real IPv6 address of the test system.
2a02:1810:xxxx:6903:cc3b:9557:84b1:23e5 being the temporary IPv6 address.

I rebooted the system to check if the temporary address really changes (did not have the patience yet to wait 7200 - third setting), it does...
edit
I can confirm after two hours (7200) the system adds an additional temporary IPv6 address. Dig immediately uses the new address (visible in the query log). According to this (run the grep command) the system default will allow up to 16 IPv6 addresses on a single adapter. The reason for this would be to keep existing connections on the previous temporary address open. Since I'm only using pihole + unbound (connections only open for a very short time), I'm testing the following additional settings:

net.ipv6.conf.eth0.max_addresses=3
net.ipv6.conf.default.max_addresses=16

I will have to wait for several hours to see the effect of these settings.
/edit

edit2
It turns out the setting max_addresses doesn't have any impact on the number of temporary addresses, so I removed it. After querying for information on the Raspbian forum, a user pointed me in the right direction, the setting temp_valid_lft is the one that does the trick. I've updated the settings I'm using (see above) to reflect the settings I'm currently testing.

With these settings, a new global temporary dynamic address is generated (and used) every two hours, the global temporary deprecated dynamic address is removed 30 minutes later.
/edit2

The question(s).

  • Is it correct to assume this will increase my privacy, by preventing individual DNS servers to build a history of my DNS requests.
  • Anybody tried this (or has it enabled by default) and knows if this has any impact on the functionality of pihole or unbound.
    edit
  • Anybody has an idea how to identify the real versus the temporary IPv6 address? both ifconfig (on the test system) and ndp -na (on the pfsense router) do not provide info to identify the addresses. answer: ip -6 a
    /edit

Test scenario:

  • pihole + unbound running on primary system.
  • latest (clean) Raspbian version on test system + dnsutils
  • executed dig command on test system: dig @2a02:1810:xxxx:6902:da97:yyyy:55e:zzzz www.google.com (2a02:1810:xxxx:6902:da97:yyyy:55e:zzzz = IPv6 of primary system)
    result (query log):
    image
    image2013×251 9.05 KB

    which shows the temporary IPv6 address is indeed the address, used to initiate the query.

Any insight is welcome, IPv6 still has a lot of secrets (for me, possibly others).

2

It depends. I cannot say this right now, but please answer this question:

Both seem to start in 2a02:1810:4d02:6903 but you replaced the third component by xxxx from the real address. Was this 4d02, too?

If so, you do not gain anything from what Windows is doing here. This is very much feels like false-security. Assuming the 2a02:1810:4d02:6903 is constant, they'll still have 64 Bit to identify you, i.e., they can tell you apart as one out of 2^64 = 18,446,744,073,709,551,616 others. It is fair to say that this is entirely useless to increase privacy.

Even when they may not be able to identify which device a query came from exactly they will still be able to identify you as member of the network. This is similar to what you have in the IPv4 world with one fixed IPv4 address (while actually being worst as an IPv4 address is only telling apart 2^32 = 4,294,967,296 users).

There should be none. Pi-hole can identify your client through its MAC address and should correctly apply filtering. unbound should not be affected at all, it should only see requests from your Pi-hole. Concerning the requests that unbound send into the Internet, what I said above applies. Old addresses should not expire immediately, so even if the address changes, answers sent to the old address will still reach your unbound. Only new requests will be done over the new address. I see no issues here.

I guess it is the case for most. I attended a networking course dedicated to IPv6 deployment in our company a few years back. It actually isn't all that hard. You just have to get it into your head once. Once you get what the GUA/ULA/etc. addresses all mean, it's pretty straightforward and actually a very beautiful system. Everything fits together nicely and the auto-configuration feature makes everything pretty simple. However, it's the extensions, often born from not having understood the concepts correctly (such as DHCPv6 or privacy extension) which make IPv6 a headache. Not the initial design as such.

While having said that privacy extension is bad, I can see a motivation for doing this. It just has a number of ugly consequences, like accumulating a ton of numbers of addresses for each device. This is problematic in a lot of cases, not only Pi-hole. Imagine you want to port-forward through your firewall. The target device has privacy extension enabled and you want to use these addresses. You have to keep your DNS record updated to always show to the correct AAAA address. No big deal, just some overhead. Now, you have to do the same in your router and probably also in your firewall (may or not be two different devices). You see that this escalates quickly. The initial beauty of each device being able to talk to each device directly (without a NAT, etc.) is somehow circumvented.

2 Likes
3

I don't have extensive IPv6 knowledge, I learn by trial and error, and of lot of duckduckgo.
The first part of the ipv6 address (eight bytes) are indeed identical on this subnet. it is different on the other subnets (physical networks) I have configured.

I checked this on a windows 10 computer, also using temporary IPv6 addresses, the first eight bytes match (real and temporary address), although different from the first eight bytes on the other subnets (the subnet where the Raspbian test machine is running)

You probably know a lot more about IPv6 than I do, but my gut feeling says both Microsoft and, especially Linux, would not implement a feature that is entirely useless, and still give it the name privacy extensions...

You make it look like it's easy to identify the prefix (64 BIT constant value), thus identifying the originating network (not the individual machine), I assume it's not that easy. I do NOT get a 64 bit prefix from my provider and I'm even sure the value differs for residential users versus business users. Different ISP or customer profile -> different prefix, reality's in my world.

All the problems, you describe, as a consequence of using privacy extensions, both on windows and Linux do not affect me, the only modification I need to make on my pi, apart from the new settings in /etc/sysctl.conf, is a change in the script that detects an IPv6 address change (when my provider kicks my modem remotely), but that's easy:

This modified code (additional grep) determines the IPv6 address that is given by the router/firewall and is used in all my configuration files (used internally only).

CURRENT_IPV6_ADDRESS=$(ip -6 a | grep '2a02' | grep 'mngtmpaddr' | awk -F " " '{gsub("/[0-9]*",""); print $2}')
4

It's in the IPv6 RFC, RFC 4941 - Privacy Extensions for Stateless Address Autoconfiguration in IPv6, so if you have an IPv6 stack then you have SLAAC PE.

5

I concur with Dan. They simply implemented the RFC. Nothing more, nothing less. It does exactly what the RFC states:

Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.

They talk about nodes not about networks. So you can still be identified as being a member of the same Internet connection. In this regard, I perfectly agree with @Coro's statements above. Also that this identification is likely 100%.

It actually is that easy. IPv6 PE does nothing more than an IPv4 NAT did as well. Hide behind a common IP address. In the IPv6 world this just means "behind a common address prefix". Whether or not your devices are using PE, the prefix identification is always possible (and actually necessary for the route into your house).

So which kind of prefix do you get? Typically, you get 56 bit prefixes so you add another 8 bit yourself to distill the 64 bit prefix for your subnet.

Not sure what you are targeting here, but I agree. Each user will get a unique prefix. If they are on the same ISP or on another. They still get individual prefixes, otherwise the whole system wouldn't work because the prefix is the important bit in the route which determines to which point on the plant a package is to be transmitted.

This is an interesting bit, slightly different or totally different? Would be interesting to see real numbers (please do not obfuscate the first two bytes as they are used to identify the address type).

6

makes it more difficult for … != entirely useless

Apparently, my knowledge of IPv6 is still insuficient, I've already revealed to much info regarding my IPv6 addresses, currently in use, so I'll kick my modem myself, this always initiates an IPv6 address change.

I use pfsense on a 4 port + wifi router/ firewall. This implies I have a WAN interface and 4 LAN interfaces (the wifi module has the same configuration options as the LAN interfaces). I use track interface (pfsense terminology), which means the IPv6 address for each LAN interface is calculated, using the WAN IPv6 address. only the eight byte is different on the LAN adapters e.g. (dummy now) 2a02:1111:2222:33xx:4444:5555:6666:7777 . The xx is the variable, I need to define for each LAN interface, and is thus different for each subnet.

bad phrase, apologies, should be different prefix size, residential gets /56, business gets ...(don't remember - to long ago, but I had a conversation with the helpdesk regarding this and remember there was a difference)

8

Yeah, so this perfectly matches

So the 56 bit may still be used to identify your network. A router kick will get you a new address, however, every running connection will obviously be killed. So it's not really an option to do this very often.

Yes and No. It depends on your point of view. Yes, they cannot identify down to the single device level. However, I can also see what @Coro wants to say: They call it "Privacy Extension" but it doesn't do all that much for increased privacy. However, yes, it does a bit.

10

It's all about situational awareness. "Know your enemy". The people you are trying to hide information from already know how to get what they need, PE really isn't going to do anything to stop them. It's great for things like being on an unknown WiFi hotspot or a foreign network where you use a one-time IPv6 address (or better one time MAC) but on residential networks it's not really going to do much.

It's great that you are trying to learn this but it's a vastly complex machine, as you have found out. When I first learned IPv6 at the Cisco Academy I thought it was the best thing ever. In fact my original commit to Pi-hole was adding IPv6 support. The more you use it (IPv6) the more you find that it's a surgical knife, best used in specific situations. After 4 years of Cisco and a BS in network engineering, I still say IPv4 is all you need for residential networking. And from all my peers that I still interact with, I don't see IPv6 being widespread adoption in my lifetime.

11

sorry guys for being such a pain, thanks for your extensive replies.

I still have a question
device 1 is on LAN1 and gets IP 2a02:1111:2222:3301:4444:5555:6666:7777
device 2 is on LAN2 and gets IP 2a02:1111:2222:3302:4444:5555:6666:7777
the key being 01 and 02, ignore 4444:5555:6666:7777
doesn't this appear like two different networks for the people, analyzing the IPv6 traffic?

I started implementing IPv6 because DL6ER once said to me:
quote
Your missing out on a big part of the internet
/quote
DL6ER: Please don't be offended, I'm very glad I took the challenge, learned (and still learning) a lot, the stats I collect (from unbound and the firewall) prove a lot of software is preferring IPv6 over IPv4, so I think is not a bad move to at least try it.
DanSchaper, you're also 100% correct, about every topic you read here and elsewhere, regarding IPv6 problems, has the suggestion to simply disable IPv6. Since this is the obvious solution, and you don't hear people complaining afterwards, it looks like IPv6 currently is still nice??? to have as opposed to essential.

12

Yes, exactly.

If you're on the unfortunate end of CGNAT and want to remotely access your home network then IPv6 is great, if your ISP provides it. I've seen a lot of German providers rotate prefixes as a solution to lack of proper firewall rules, but that just causes breakage. It's possible to get /56 (or larger) from an ISP but then you're doing your own prefix delegation and subnetting. You have a powerful firewall and router, as do I, (I built my own router) but we're quite rare as far as having that capability at home.

13

No, because they know that

so they will use the 56 bit and ignore the 8 extra bits.

And he still believes in this, however, the "big part" should not be interpreted as you cannot reach a lot of the Internet when you have no IPv6. In fact, most IPv6-servers also have an IPv4 address. Not all, but the minority of IPv6-only is unlikely to be used by the majority of users out there.

The shiny part of IPv6 is that it is fast in transmit. You get less delay (= latency) and less overall processing. This means less power being spent on transmitting your packets and, in the end, in an improved ecological assessment. The reason is somewhat buried in the details, however an IPv6 header does not include a checksum. The IPv4 header checksum is calculated for the IPv4 header, and has to be recalculated by routers every time the time to live (called hop limit in the IPv6 protocol) is reduced by one. This means additional delay and power consumption. The absence of a checksum in the IPv6 header furthers the end-to-end principle of Internet design, which envisioned that most processing in the network occurs in the leaf nodes.

Just one more detail next to a lot of others. I still like and recommend IPv6, but concerning the recommendation, I also learned to take a step back. It can require a lot of thinking. It doesn't have to if your ISP does everything correct for you.

14

off topic...

now, I'm getting worried, DL6ER referring to himself in the third person? Reminds me of a very old greys anatomy episode, watch here, only takes a minute...

18

And I don't dispute any of this either. IPv6 has a number of great features built in to it, IPSEC for one.But I do think the benefits gained from zero checksumming and latency can be gained in IPv4 with kernel improvements like fastpath.

20

IPv6 is nice and easy. Maybe I should say "was" instead of "is". As long as you look at the original idea so without all the crazy extensions here and there (DHCPv6 and PE already mentioned above). But this always happens with humans. They want something that doesn't fit into what is possible (and does not make much sense, either!) so they define an extension. Once they convince/confuse enough other people, they will get it in the end. It's the same old story of: Oh, we have 11 competing standards for this, let's make a new great unifying standard which will replace them all. A bit later, there are 12 competing standards...

Sometimes it may help others as well to take a step back to get a better overview...

21
22

Or if you use Raspberry Pi, it's HDMI, MiniHDMI or MicroHDMI.

24

NOT gonna happen...

Despite the fact that, in the best case scenario, using temporary IPv6 addresses does only

and in the worst case scenario

I still very much like the fact that a site that tries to collect my IPv6 information, only gets a temporary IPv6 address, that changes regularly. Assuming that similar techniques are used to collect IP information on other sites, it will at least make it more difficult for them, if they even have implemented analysis logic in their code to determine the different IP addresses all point to the same network (= my network).

I've worked very hard to get to a perfect (100%) result on this site and (10/10) on this site (long and hard due to my lack of IPv6 knowledge, I admit that)

I've been running tests, to enable the privacy extensions on Raspbian (the OS pihole is running on) for a few days now, and finally succeeded to get it working, the way I want it. I've updated the first entry of this topic with the settings I'm using.

I have applied these settings to my production system ( latest Raspberry Pi OS (32-bit) Lite / august 2020 / Linux raspberrypi 5.4.51-v7+ #1333 SMP Mon Aug 10 16:45:19 BST 2020 armv7l GNU/Linux), first impressions (ran some tests) are that everything appears to function as expected.

I have been running packet captures on my firewall, and can confirm all IPv6 port 53 traffic (unbound requests) is now using the global temporary dynamic IPv6 address, which changes every 2 hours. I also verified if the global dynamic mngtmpaddr IPv6 address, the permanent address of the system, is used, when connecting to the outside world; it's NOT, it only appears when I ping6 it internally, this to refresh the neighbour information on my router/firewall.
I also can confirm, as soon as the temporary IPv6 address changes, unbound immediately starts using the new address for all it's queries to the outside world (ran another packet capture).

I'm aware some (if not most) will call me paranoid (if not crazy), to implement this on my system. Why?
because I can, and most important, learn a lot... Will it make my life harder when something goes wrong? probably, but again, a great learning opportunity.

Down sides of implementing this? Of course. As discussed in this topic, (TL;DR) pihole-FTL doesn't cleanup the network and network_addresses table (will be solved in a future release). Even when using the MAXDBDAYS setting to a reasonable setting (I use 8) ,the table fills up rapidly (already have 35 entries after a fresh install of pihole, less than 24 hours ago). That's NOT new, I assume windows 10 users, that haven't disabled the privacy extensions, and have been using pihole -up to get to the latest release of pihole, will have accumulated quite a lot of entries in those tables, since the database was first introduced (to the point where sqlite3 gets in trouble, performance wise???).

Will you change my mind, undoing the temporary address setup? NO, because (click the link), unless of course something goes horribly wrong in the next few days.

25

Hmm, okay, does surely not hurt

As long as it makes only your life harder and does not lead to additional workload for the Pi-hole team (because something broke in a way you do not attribute to these changes), everything should be fine.

This will not happen. Look at the users running the database with queries over 365 days. Most of them will have dozens of millions of queries in the database. The database still works fine. I don't think that thousands (which clearly much less than "dozens of millions") of entries in the network_addresses table will be any different here.

I didn't try, nobody else in here did. It is just putting things into perspective. Compare it to buying an ultra-expensive lock for your front door. However, the kitchen windows is open. This does not directly translate to the current situation (at all) but it shows that sometimes people invest a lot of time and effort into something that will not lead to any real improvement.

And this is the point where we disagree. It is commonly known in the "IPv6 community" that the vast majority of users are given /56 subnets by their ISPs. And with PE being enabled in Windows by default, why should they even try to identify you be the exact address? They will identify you be the net. I don't see why this could be seen hypothetical (just because they don't tell us explicitly what they do?). This is sufficient for their needs. If they need to go down to the individual, they will resort to identification by individual things like cookies, [Facebook, Google, etc.] logins, etc. If you prevent this, good. But it also means you belong to the minority they are not interested in.

So, coming back to where I started: My initial statement of "You will NOT gain from PE anything" still holds. From the outside, nobody sees if you are using a temporary address or a permanent one (at least not without monitoring you for long enough). To prevent flooding their analysis software with temporary addresses, they will very likely resort to using your /56 subnet in the first place. So whatever you do with the remaining 136 bits is your personal enjoyment and will not have any effect.

26

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