Table of Contents:
This is as yet, an almost-complete tale of my travels through IPv6: from emails to ISP’s to self-education and enlightenment. There’s a whole lot of guesswork involved too, as I’ve had to teach myself how IPv6 works, along with trying to figure out how my ISP has deployed it to me.
Uh… OK
IPv6. It’s been around for years, and as of 2025, it’s widely used by various countries and Internet service providers (ISPs). For example: countries such as France, Germany, and India now run the majority of their traffic to Google over IPv6. Other countries like the United States, Brazil, and Japan have around 50% adoption. Russia and Australia have over 30% adoption, while China has less than 5% and some countries such as Sudan and Turkmenistan have less than 1% IPv6 adoption. Additionally, mobile operators like Verizon have mandated IPv6 operation for their 4G networks since 2009.
So I thought I’d look into it. I’d had a small dalliance in the corporate world a few years ago, but didn’t really make any effort to understand it and duly shrugged it off with a humph, a shrug of the shoulders and a splutter. Never to be seen again.
So I thought it was high time I had a look at it and see what all the fuss was about. Although there’s nothing wrong with my current NAT’d private IPv4-addressed home network (see Appendices below), it was suggested (by “them” on the internet) that things may run a little faster if IPv6 was used.
OK then. Research ensued.
The ensuing. Of the research.
I read some stuff about IPv6. Quite a lot of stuff, ranging from full and complete descriptions of how IPv6 works, to brief “how-to” articles.
What I got from that research was this:
- IPv6 has eight sets of four numbers, separated by a colon (:) like this:2001:0db8:0000:0000:0000:8a2e:0370:7334
- The numbers are hexadecimal, so can be from 0000 to ffff giving many, many combinations.
- IPv6 has a prefix for a range of addresses. An ISP will allocate a /64 or /58 prefix.
- The prefix is apportion of the address that is used for routing purposes. With a /64 prefix, the first four sets of numbers (allocated by the ISP) is the routing information.
- Which leaves the last four sets of numbers to be manipulated for the internal network.
- There does exist a private IPv6 addressing schema.
- Shortcuts can be made in addresses. The number “0” can be shortened (or omitted) to make the address a bit easier to use. In the above example, that can be shortened to: 2001:db8::8a2e:370:7334
- It appears that regardless of what IPv6 addressing schema you choose for your networks, a networked device will create a temporary IPv6 address based on your allocated one, so that the internet can’t backtrace the IP and hack you. Now isn’t that cool!?
- There’s no need for NAT (see appendices) or (it would appear) an IPv6 DHCP address to be allocated to your home router.
A realignment of braincells
I went into this whole IPv6 thing thinking like an IPv4 network person. That in itself was a considerable disadvantage, however I’ll make a note of it, in case it helps anybody.
Routers and ISP’s
I had a TP-Link Archer AX50 providing my router services since I had my fibre broadband installed. It was (I thought) much better than the Linksys Mesh thingy that my ISP provided, so I used that instead. And for five years, it’s been magnificent.
The first step to IPv6 was therefore to turn it on, on the router. I did that.
The TP-Link has an IPv6 configuration page that expects DHCPv6, SLAAC or RDNSS. Cutting a very long story very short: I played with a multitude of different combinations of those settings, but failed to get absolutely anything out of it.
Thinking that IPv6 may not be enabled in my area, I sent an email to my ISP support desk to verify whether IPv6 was enabled (or not) for me. They replied and said that yes, it was enabled in my area and to try powering off the various routers and fibre connection points for a bit. OK then.
I did that many times, it made not a jot of difference.
Meanwhile…
Whilst I was waiting for reboots and resets and who knows what else, I decided that I would at least see if I could allocate a private IPv6 range to me network devices.
I was using my Pi-Hole server as a DHCP server for IPv4, noticing that there was an option for IPv6, as long as the server had an IPv6 address. I duly created a private IPv6 address range for me to use.
This was my train of thought…
I was thinking like an IPv4 network engineer, in that I would create an internal address range that was not routable on the internet, then NAT that out through the router, once that had been allocated a DHCPv6 address. That’s what’s done with IPv4, should be the same for IPv6, yes? (No!)
So I thought I’d do that, at the very least it would allow me to create some IPv6 addresses and possibly test the Pi-Hole server for DHCP distribution of it.
And indeed, that was what I did. It was successful: I could ping other devices using IPv6 and access resources like web pages on my web server using IPv6. Lovely. All I need now is that address from the ISP.
I waited for a day or so, but no DHCPv6 address was forthcoming. I decided to swap the TP-Link router for the one supplied by the ISP five years ago.
Uh… what’s that address!
I spent a good couple of days swapping between the TP-Link and the Linksys router before I realised that IPv6 still wasn’t working. I was at least expecting an address allocated on the Linksys router, but all I had was “Connecting…” in the logs. I’d configured the IPv4 part of the Linksys to my network topology, including the wireless bit and that was all working fine. As the Pi-Hole was serving DHCP, I’d turned that off on the Linksys.
I’d also messed around with disabling the DHCP on the Pi-Hole and enabling it on the Linksys – and although that worked reasonably fine, I still had no IPv6.
Until I pinged Google (with the Linksys acting as router) using IPv6 from my workstation. And it worked! Uh… what?
It did indeed. An ipconfig /all on my workstation revealed some IPv6 addresses I hadn’t seen before – and they were internet routable! My private range was still in there too. OK then. Thinking is to be done.
In the meantime…
I’d been sending emails back and forth with my ISP’s support desk trying to figure it out. They had no idea about how it worked either, but they did book an engineer’s visit. He duly turned up and although he was a very nice man, he know absolutely nothing about IP anything, let alone dual stacks or DHCP. He very kindly gave me a new router (an updated Linksys) and fibre termination box, but of course it made no a jot of difference. He said he’d escalate it and went away.
And that was the last I heard from my ISP!!
It’s alive!
I did a lot of thinking. I could see the routable IPv6 addresses in my ipconfig results. Occasionally, I could ping Google using IPv6. So I must be getting the addresses from somewhere, but it wasn’t from me (as in an internally generated address). They must therefore be coming from my ISP, through SLAAC or some such mechanism. It’s obvious that they weren’t using DHCPv6, otherwise I would have seen an address on the router.
Reconfiguration was required:
- Removed all of the IPv6 private addressing.
- Set the Pi-Hole to distribute IPv4 addresses only.
- Disabled the IPv4 DHCP on the Linksys router.
- From the *ipconfig /all* results on my workstation, I could work out what the router gateway was, the DNS server that was being used and from the temporary and DHCP addresses, I could guess the prefix (/64).
That meant the Pi-Hole was set as the IPv4 DHCP server, using the Pi-Hole for secure DNS.
An unexplainable anomaly
For the IPv6 addresses however, there was something weird going on. I wanted IPv6 DNS lookups to go through the Pi-Hole server, as that was my secure DNS server. If I used the Pi-Hole as the IPv4 and IPv6 DHCP server, that was easy. However not if I used the Linksys (or so I thought!).
Amongst the many fiddling and trial-and-errors that I’d done, once I’d set the Linksys DHCP server to on (disabling the Pi-Hole one first, obvs.) and set the only DNS server to be the Pi-Hole server address (on IPv4).
When the clients renewed their DHCP leases, their DNS server was still showing as the Linksys router. Investigating the query log on the Pi-Hole however, revealed that DNS queries were happening, but all coming from the Linksys router address, rather than the client. Very odd, but it did mean that clients were using the Pi-Hole for secure DNS, just in a roundabout fashion.
When I disabled the Linksys DHCP and set the IPv4 addresses to be distributed from the Pi-Hole server, that was reflected in the client’s ipconfig, but the DNS lookups were still going through the Pi-Hole. I’m going to turn away from that one for the time being an call it “fixed”. I’ve no doubt that there’s a reason for that behaviour, however as it’s working, I’ll apply some though to that a bit later on down the line.
Static IPv6 addresses
I’d managed to work out what my prefix (and therefore network address) was from the ipconfig results, so I could generate some static IPv6 addresses for those that needed it, along with the necessary gateways etc. That all works very well and I can ping and traceroute successfully using IPv6.
Finishing up
I’m reasonably happy with the setup now. I have my (ISP autoconfigured) IPv6 addresses and I have my statics where needed. Everything is using the Pi-Hole for secure DNS lookups (which incidentally work for IPv6 as well) and the temporary IPv6 addresses are being used when accessing internet resources.
The only downside is that I am obliged to use the Linksys router. It’s very much a personal preference but I really don’t like Linksys (I’ve had some historical shenanigans with Linksys equipment), but it does seem to be working OK for the moment. And as it’s an ISP-supplied router, if it does go wrong, they’ll give me a new one.
So far then, the six has been joyful.
Appendices
Herewith some appendices explaining a bit more about IPv4, how it currently works, IPv6 and the issues with address exhaustion. I haven’t put them further on up the post as there’s quite a high danger of TL;DR!
Appendix A: IPv4
I’ve written about IP addresses in my post: Secure DNS: Something We Should Do?, where I’ve attempted to explain internet addressing and the relationship between those numbers and a physical server location (like a postcode, or zip code).
That was one type of – and the most popular by a long way – addressing called IPv4. IPv4 is made up of four sets of numbers, each set can be anything between 0 and 255. Working out the number of addresses from that, calculates as 4,294,967,296 IPv4 addresses.
However: the way that IPv4 works is that there’s a set of addresses that are designated as private ranges. These ranges are not routable on the internet, but are used for special purposes, including allowing individuals to access the internet through something called NAT (which we’ll deal with in a moment). The upshot of that is that there are a finite number of IPv4 addresses available to devices that are based on the internet. Roughly 3.7 billion.
Although that number sounds a lot (and it probably did in the early 1980’s when IPv4 was introduced), it’s now considerably less than the number of devices that we want – as a planet – to access internet resources. When you consider each device that wants to access the internet – whether it’s a computer, server, phone, or smart device – will need a unique address to do so.
That 3.7 billion number was far exceeded years ago!
NAT
Enter NAT. NAT stands for Network Address Translation.
What this means is this: a home router that is connected to the internet can have assigned to it one internet routable IPv4 address – usually called the external network. Behind the router – in the internal network – are devices. Devices like phones, computers, servers, Alexa, printers, smart thermostats and anything else that wants to connect to the internet. These devices are automatically allocated IPv4 addresses by the home router, however these are from a private address range. A private address range is one of the “special purpose” ranges mentioned earlier, whose IP addresses are not routable on the internet.
The result of which is that you can have as many devices as you like (well, up to 255) in your home, but only use one IP address on the internet. The home router does the necessary addressing and translation automatically to make sure traffic goes in the right direction.
Corporate NAT
In the corporate world, it’s very similar, but a bit bigger (obviously). There are three sets of private address ranges, each supporting an increasing number of devices. Organisations can use those, or a combination of those to provide their internal networks device addressing, but the greater majority of outbound corporate traffic will use NAT on an address for their outbound traffic.
For corporate inbound traffic, organisations normally purchase blocks of internet IPv4 addresses and use those. But as the availability of IPv4 addresses becomes ever more scarce, the price of those IPv4 blocks rise.
A good solution?
It was for a while. But as the number of devices on the planet rises, the number of IPv4 addresses stays the same. NAT can only do so much.
And that was why – 30 years ago – somebody though “oh, we’re going to run out of IPv4 addresses!”. For a full explanation of IPv4 (if you’re still awake/interested) check out the Wikipedia page.
Appendix B: IPv6
It was actually in December 1995 that IPv6 was initially conceived as a replacement for IPv4, but it didn’t become an internet standard until 22 years later, in 2017.
What is it?
It’s still an address, like a postcode or a zip code, just like IPv4. Remember IPv4? IPv4 was a number made up of four sets, from 0 to 255 and looked like this: 192.168.1.5
IPv6 is still a number, but this time it comprises of eight sets of hexadecimal numbers, from 0 to ffff and looks like this: 2001:0db8:0000:0000:0000:8a2e:0370:7334 (or shortened to 2001:db8::8a2e:370:7334).
Using that format, the number of addresses that can be calculated from that is: 340,282,366,920,938,463,463,374,607,431,768,211,456 (it’s quite a lot!). Which is deemed to be more than enough for every device on the planet (and then some) and is supposed to see us through for quite some time.