This site has always been about experiments. I’m taking things a little bit further by doing a really radical experiment. Just like my main blog (which contents have been imported into this one), this blog is hosted on a VM on a Proxmox hypervisor in my colo. Only this server is a bit different. While it is IPv4-enabled, it only has a RFC-1918 address. But it does also have a globally-routable IPv6 address assigned and that’s what you’re viewing this on. So if you were wondering, “Has my ISP enabled IPv6 yet?” then I can confidently answer for you yes, yes they have.
You can clearly see that over the last decade, IPv6 adoption has sky-rocketed. This is being fueled by the increasing prices of IPv4 subnets, which is in turn raising prices for providers and in turn, the users of those services. A prime example is the hosting provider Hetzner. In January 2022, they added a surcharge for all IPv4 addresses on their servers and started doing IPv6-only deployments (e.g. if you ordered a server, by default you get a /64 prefix to go along with it, but if you want a /30 or more of IPv4 space, then pony up some cash).
That’s what has lead me to this experiment. While I don’t use Hetzner nor do I agree with many of their practices (like they use cheap hardware which leads to more failures along with charging setup fees like it’s 2002), I admire them for dragging many people kicking and screaming into modern times.
My IPv6 Deployment
At home, I do run dual stack IPv4 with IPv6. Something I tried a long time ago was in my DHCPv6 Prefix Delegation request, I tried setting this to /56 instead of /64 as my ISP said. To my surprise, it worked. Their DHCPv6 server happily handed me /56 which is 256 /64 prefixes. This allowed me to fully implement IPv6 internally across all VLANs. Each VLAN gets a /64 just like it gets it’s own /24 out of my /16 RFC-1918 supernet.
In my colo, things have been tricky. Because I do run my colo like home (e.g. there’s a firewall where IPv4 goes through NAT and firewall rules handling the security of things), IPv6 has been a different beast. I’m currently working with my colo provider to see how I can route the IPv6 space they issued me. You see, they issued me a /48. Which is great. But it’s not “routed”. Rather I can use space from this but it has to point to the ::1 gateway (their router). When I tried to break of a /64 for the WAN and /64 for the LAN side, I discovered it wasn’t routed. On the LAN side, I could trace as far as their router. No bueno. So I ended up going back to trusty Hurricane Electric and using an IPv6 tunnel from Tunnel Broker. Not ideal, but it works. And that’s how you’re reaching this blog (at least for now).
And that leads to the main experiment of this blog. You see, in IPv4-land, I would have to connect this blog to my reverse proxy server which has ports 80 & 443 passed to it from the firewall. From there, the reverse proxy handles SSL termination for the public internet. Traffic then goes into the corresponding server and the request goes back out through the reverse proxy and then out to the IPv4 requestor. It’s an extra step because of the IPv4 shortage. I don’t like this extra step. I think it’s ridiculous and unnecessary. Instead, this blog doesn’t need it. IPv6 traffic goes from Hurricane Electric over the tunnel to my firewall. My firewall does IPS on the traffic, and then passes it on to the server directly. No reverse proxy needed.
We need more IPv6 – and we need to change our views
IPv6 is much more simple than IPv4 which is one of the reasons I absolutely love it. SLAAC (Stateless Address Auto-Configuration) is one of the best features of IPv6! I don’t have to waste precious resources running an additional server to hand out IPs. Instead, the devices can just configure their own with a little help from RAs which are basically nothing more than occasional “helper” packets being sent over the wire for devices to pick up and understand what they need to configure – for example, in the network where this blog runs, RAs are sent every so often with the /64 prefix servers should use as well as what DNS servers they should be configuring. Do you know how nice it is to not have to configure DHCP pools and set options? And this is why we need to change our views.
One of the reasons why I think it’s harder for even well-seasoned networking veterans to pick up is because we expect it to work just like IPv4. But here’s the thing – it’s not! We have to accept that IPv6 isn’t IPv4 and that it is a good thing! If you configure the services on your network just right, you shouldn’t have to type in or remember IPv6 addresses to get to devices – just the hostnames. At home, I don’t type in my firewall’s address to get to it. I type in “fw01.<mydomain>.com”. And with web servers, SNI has been a thing for a while now, too. That means to reach a SSL site, you have to provide a domain name otherwise you’re going to get the default SSL site.
Try before you deny!
Argyle may have said that in regards to pineapple on pizza (which I have tried, so I can deny), but it applies to IPv6 as well. Get IPv6 addresses from your ISP. Route them to a lab environment. Lab. It. Out. Actually try to replicate a small-scale version of your enterprise network (or home network for you homelabbers denying IPv6 still). Actually use IPv6 for a while before you throw your hands up and say “meh!”
Here are the books I’ve been referencing and using to assist me:
IPv6 Essentials, 3rd Edition. Hagen, Silvia. ISBN: 978-1-449-31021-2
IPv6 Address Planning. Coffeen, Tom. ISBN: 978-1-491-90276-2
IPv6 Network Administration. Murphy, Niall Richard; Malone, David. ISBN: 978-0-596-00934-2
These books, especially IPv6 Essentials, are incredibly useful. I also believe that before anyone can criticize IPv6, reading IPv6 Essentials is required. You might change your viewpoint.
And if you’re reading this post and you think IPv6 is dumb, useless, pointless, a waste of time, well then you might want to check your router settings because this post is only being directly delivered on the IPv6 internet my friend!