3 things you can do with IPv6 that are difficult with IPv4

Published Nov 13, 2026, 7:00 AM EST Umair Khurshid is a technology writer and developer with a strong focus on Linux, FreeBSD, cloud infrastructure, and automation. Before focusing on writing, Umair worked as a developer and DevOps engineer building and automating cloud-native systems. IPv6 has been around for decades, and most of us have probably heard the same explanation about why we need it. We are running out of IPv4 addresses; IPv6 has an almost unimaginable number of addresses, and eventually, everything will move over to it. That is usually where the conversation ends, which is a shame because IPv6 has some pretty interesting features up its sleeve. I have been experimenting with IPv6 in my homelab, and I think we spend far too much time talking about its address space while overlooking what we can actually do with it. Some of these things are technically possible with IPv4, but they involve workarounds that IPv6 makes unnecessary and if you run your own servers or enjoy tinkering with networking, there are a few advantages worth exploring. Stop fighting over ports 80 and 443 Run multiple web servers without a reverse proxy Suppose you have managed to expose your home server to the internet. Everything works, and naturally, you decide to host something else. Then another service, and before long, you have a small collection of web applications running on different machines. This is usually when port forwarding starts getting annoying. Imagine you have three physical servers. One hosts Nextcloud, another runs a personal website, and the third has a dashboard you want to access remotely. All three use HTTPS on port 443. If you have only one public IPv4 address, you cannot forward port 443 to all three machines at the same time. You could change the external ports, but who wants to remember that one service uses :8443 and another uses :9443? The usual solution is a reverse proxy, and I am a big fan of Caddy for exactly this kind of setup. Still, sometimes you just want each machine to handle its own traffic. This is where IPv6 makes things interesting. Instead of sharing a single public IPv4 address, your servers can have their own globally routable IPv6 addresses. You can then point a different domain name at each machine using AAAA records: cloud.example.com 2001:db8:1234:1::10 blog.example.com 2001:db8:1234:1::20 home.example.com 2001:db8:1234:1::30 All three servers can now use port 443 without interfering with each other. You can even take this a step further by assigning multiple IPv6 addresses to a single network interface. That allows different applications on the same machine to listen on the same port, provided each is bound to a different address. The nice thing is that you do not have to configure any port forwarding for this to work. You still need to allow the relevant traffic through your IPv6 firewall, and your ISP must provide working IPv6 connectivity. Some routers also block incoming IPv6 connections by default, so that is something you might need to configure. Give every VLAN more addresses than it will ever need Subnetting becomes a lot less of a headache Once you have a few servers running, the next logical step is to start separating things into different networks. Perhaps you want your IoT devices on their own VLAN, a separate network for your virtual machines, and another for guests. This is where you start playing the familiar IPv4 subnetting game. You assign 192.168.10.0/24 to one VLAN, 192.168.20.0/24 to another, and keep adding subnets as your network grows. There is nothing particularly wrong with this approach. I have used it for years, and for most home networks, it works perfectly fine. Things get more interesting when you start connecting multiple locations through VPNs, building larger networks, or dealing with overlapping private address ranges. IPv6 has a wonderfully excessive solution to the address planning part of this problem. Your ISP can delegate an entire IPv6 prefix to your router. If you receive a /56, for example, you can divide it into 256 separate /64 networks. And each /64 contains approximately 18.4 quintillion addresses. I cannot imagine any realistic homelab that would come close to exhausting even one of those subnets. In fact, it is such a ridiculously large number that trying to conserve addresses the way we do with IPv4 starts to feel a little silly. What I particularly like about this approach is that you can assign a standard /64 to each VLAN. That is the conventional subnet size for IPv6 networks using Stateless Address Autoconfiguration (SLAAC), which allows devices to configure their own addresses. For instance, you could have one /64 for your main LAN, another for IoT devices, and separate ones for your servers and guest network. Your router advertises the appropriate prefix on each network, and compatible devices can configure their addresses without requiring a DHCPv6 server. This also makes expanding your homelab easier. If you decide to add another VLAN for testing containers or experimenting with a new hypervisor, you can simply allocate another /64 from your delegated prefix. There is no need to worry about whether a subnet has enough available addresses for future devices. Of course, having all those addresses does not mean you can forget about network planning entirely. You still need to think about routing, firewall rules, and what happens if your ISP changes your delegated prefix. Unique local addresses can help if you want internal addressing that remains independent of your ISP. There is also the question of what your ISP actually provides. Some delegate a /56 or /48, while others give you only a /64. Certain consumer routers also have poor support for prefix delegation, which can make setting up multiple IPv6 networks more frustrating than it should be. Use temporary IP addresses without giving up a stable one IPv6 privacy extensions are surprisingly clever One of the things I find interesting about IPv6 is that your computer does not have to stick with one address. In fact, it can have several IPv6 addresses assigned to the same interface and use them for different purposes. Why would you want that? Well, imagine you have a Linux machine that you access remotely over SSH. You want it to have a predictable address because constantly looking up a new address would get old pretty quickly. Perhaps you also have DNS records pointing to that machine, or firewall rules that depend on a particular address. At the same time, using one persistent address for all your outgoing connections creates potential privacy concerns. Websites could use that address as one of the signals to recognize your device over time. IPv6 has a feature called temporary address extensions, which is also sometimes called privacy extensions, that helps with this. Your computer can maintain a stable IPv6 address while also generating temporary addresses for outgoing connections. Those temporary addresses change periodically, making it harder to track the same device using a persistent interface identifier. The interesting part is that you might already be using this feature without realizing it. Many modern operating systems enable IPv6 privacy extensions by default, although the exact behavior depends on the system and its network configuration. On Linux, you can check with: ip -6 addr show scope global If privacy extensions are active, you should see one or more addresses marked temporary. These addresses have limited preferred lifetimes, and your operating system can generate replacements as the older ones age. Existing connections can continue using an older address while it remains valid, so the rotation normally happens without interrupting what you are doing. I think the clever part is how little you have to do to benefit from this. Your machine can continue accepting SSH connections through a stable address while preferring temporary addresses for new outgoing connections. That said, temporary addresses are not something you would normally want to use for hosting services. If you are maintaining DNS records or address-based firewall rules, you probably want those to reference an address that won't change every few hours. IPv6 is useful, but I would not ditch IPv4 just yet For all the conveniences IPv6 brings, I would not recommend moving your entire homelab to IPv6 only just yet. There are still plenty of services that depend on IPv4, and sometimes you discover those limitations in rather frustrating ways. I learned that while experimenting with an IPv6-only mail server. You can technically set one up, and I have tried it myself, but getting reliable email delivery is another story. Many mail providers still cannot receive mail over IPv6, while others impose additional requirements on IPv6 senders. You might eventually need an IPv4-enabled relay anyway, which somewhat defeats the purpose of the experiment. That is why I think dual-stack networking makes the most sense for now. You can already enjoy the advantages of IPv6 without rebuilding your entire network around it. Start with a few servers, experiment with IPv6 addressing on your VLANs, and see what works for you. There is plenty worth exploring, even if IPv4 is going to stick around for a while.