It is not a secret that I’m both an early adopter and a critic of IPv6, particularly its deployment and the strong, near-religious conviction from network engineers, that we’re all basically ready for IPv6, except for a few naysayers holding back progress. I tend to disagree as there is still an obvious amount of work needed to be done to allow a seamless experience for people who don’t want to know what IPv6 is in the first place.
When approaching IPv6 problems, I have usually taken a more conceptual approach, that requires little to no understanding of the networking stack and tooling. This time I have more questions than answers, because I’m fairly sure there are answers, at least in the enterprise space, but I have no experience with it to be able to form a clearer impression of how applicable those answers are to the consumer world. And at the same time, I have not really spent a lot of time looking at alternative consumer hardware and software solutions — the only three network connections I manage nowadays are my flat’s (which is obviously shared with my wife), my mom’s and my mother in law’s, and none of them lead themselves to me having time to play around with different network gear and configuration. So if you do think that you have answers, please do share them — I’ll gladly correct myself.
Caveats out — here’s the problem: if you have a consumer network that is IPv6 enabled, how do you enforce controls on the devices attached to it? This question is probably at the same time more obvious and more nuanced to network professionals rather than consumers, so I think it’s worth trying to restrict that field a bit more.
Without getting in too detailed explanations, there are three type of controls that you can apply over a network: who can connect to said network; who can receive inbound connections; who can initiate outbound connections. The last two are usually solved through some sort of firewall solution, either in software or “in hardware.” I’m oversimplifying here, for sure — particularly in corporate environments there’s a lot more nuance around, but I don’t think it is really relevant, if we want to insist that IPv6 is ready for consumers.
The first of the three is probably one of the most commonly solved problems — to a point. Pretty much all of us are used to the idea of using a password to authenticate to a WiFi network, or have to sign up or sign in with a restaurant’s or hotel’s provider. This only solves WiFi access, as I don’t think most consumers care about access to the physical Ethernet ports in their home — corporates should, but even there 802.1x is not widely deployed — I have to apologize to my schoolmate Lorenzo for disagreeing with him 20 years ago about the usefulness of WiFi security in dispelling the false sense of security of Ethernet ports.
The other two are a bit more complicated, because then you have to further divide them in terms of access to the local network (intranet), and access to the wider Internet. A firewall at the border between the local network and the Internet, which is one of the most common deployments as part of a gateway/router, can only apply controls for connections that need to cross said border — so over the years we have gotten used to run firewall software on network-connected devices such as PCs and home servers. While all of this is relevant, I’m going to gloss over the details because they change from computer to computer, from operating system to operating system, and so on.
Yes, I’m intentionally glossing over VLANs, multiple WiFi networks, and so on. Those are the kind of features that network geeks would love to go on about — and let’s be honest, I also use those – but don’t really fit into the “consumer” space.
Over the years, the border between Intranet and Internet for consumers changed significantly. With the exception of a few highly invested enthusiast, back in the days of dial-up, you would end up connecting one computer to the Internet, which would get a public IPv4 address — and maybe you would share its connection with other computers on the network through some OS-specific solution. Eventually with the advent of broadband, modem/routers started becoming more common, and then you would be delegating the “connection sharing” to this device — in either case, that meant your gateway (be it a PC or dedicated network appliance) would almost certainly be providing NAT (Network Address Translation) to allow other devices on the same Intranet to make outbound connections past the border. Port forwarding (D-NAT) either through static mapping, UPnP or NAT-PMP became the most common way to let these clients to receive inbound connections from the wider Internet — as geeks, pirates, and gamers learnt easily. Of course, the same feature has been abused by malware and malicious devices to expose themselves to the Internet, but hey, everything is a trade-off.
Now, if you ask both Security and Networking folks, they will tell you that NAT was never intended to be a security feature, and they are correct by all counts… except that it significantly changed the deployment semantics for most consumers: with the exception of the gateway, which increasingly was not a PC, their computers would no longer be facing the Internet directly! But this complacency didn’t last long either — as WiFi-enabled laptops became the norm, public WiFi became common as well, and now most of the worries you had about putting your computer directly reachable on the Internet would apply to use those networks, too — I have already mentioned this in my previous post on public WiFi, so I’m not going to spend too much time on it now, but that’s why you have Windows asking you if you’re on a Private or Public network when you connect to something new.
Since the IPv4 shortage is a real problem, many ISPs have over the past few years started putting a new layer of NAT (CGNAT), so that the consumer gateways are no longer directly connected to the Internet, and even port forwarding does not let computers on the local network to receive inbound connections. This has, as a side effect, defused some of the malware that relied on the ability of forward ports, but this is neither a significant obstacle for malware authors, nor an intentional design of CGNAT. Once again, NAT is not a security feature, but its existence shaped a lot of other decisions over the year.
Speaking of things I’m going to gloss over and not talk about, I”m not going to get into STUN and other NAT-bypassing protocols.
Once you deploy IPv6 on the network, though, things get more complicated: devices that receive an IPv6 can theoretically receive inbound connections from the wider Internet, since the addresses are now globally routable, so if you don’t have a firewall, you may find yourself thrown back to the dial-up days, of when your computer would get an unfiltered public IP address — and it wasn’t until Windows XP that Microsoft provided built-in firewall software (and not a good one at that), previously you needed to install third-party software to achieve that, and you now know the risks.
Now, thankfully, the world is not quite as bad: most gateways would need packet filtering (i.e. a firewall) to do CGNAT anyway, and most IPv6 deployment is done in tandem with CGNAT, because the alternative of not having IPv4 at all, implies that for most smart devices won’t be able to even connect to the WiFi, let alone function. And unless designed by total amateurs, and sold by irresponsible vendors, they should have default policies that don’t allow inbound connections from the wider Internet to the computers running within someone’s home.
For most people, that should suffice, the gateway acting as a firewall is all you need, allowing outbound connections only, which is generally the default. Great! But what if you want just a little more control without going full on enterprise?
Well, I don’t think there’s an obvious answer here, IPv6 makes a few things more complicated, but it is not intrinsically worse than IPv4. Yes, of course if you think about the ability to easily access one specific device on the network, using static IP addresses seems the logical conclusion — and indeed, it’s common to “fix” an address as provided by DHCP through a router’s interface (DHCP only means that your addresses are not statically defined on the device connecting, not that they are required to change constantly). In an IPv6-enabled world there is no direct equivalent — partly because DHCPv6 is basically a niche product, that Android refuses to support on philosophical grounds, and there are very few implementations of Route Advertisement that I know of, none of which tried to implement this type of logic.
Originally, IPv6 deployments actually had completely fixed autogenerated address, based off the MAC address of a device — and the MAC address of each device would be unique and static. This had privacy implications that eventually became clear, so now the addresses are either completely made up and temporary, or fixed per device-network combination. And if you use Windows, you get both by default: an outbound-facing temporary, rotating address, and a fixed address you can use for inbound connections. You can configure something similar with systemd, if I remember correctly, I just hadn’t done that in a long while.
What this means is that it’s very hard to have outbound policy filters — unless you use separate VLANs. Any device on your network can get a different outbound address at any point, and the only way to prevent that could come to haunt you in the form of a much more easily trackable address. Once again, NAT is not a security system, but the relative privacy we have come to expect out of it (you can possibly tell all the requests come from one’s own home connection, but not which ones come from one computer rather than another) is pinned on the NAT feature directly.
To be clear, I’m not suggesting that this peculiarity of IPv6 is a significant subversion of the security model — because even on IPv4 a malicious device could just as easily get multiple addresses through DHCP, set an address that is not in the DHCP range but in the same subnet (fairly common), and so on. The only real, functional way to apply network controls is through a default-deny policy, that only allows specific addresses through, and since neither DHCP nor RA/NDP allow for signed requests (to the best of my knowledge), if you need that level of security you need VLANs and 802.1x.
What I am saying, is that IPv6 changes enough of the way we have been doing network access controls over the past years that I expect a transparent-to-the-consumer deployment risks creating significant security headaches.
Aside, which I already mentioned in previous posts, the fact that most of the time you end up using the globally-routable address to access local devices over IPv6 is also something that causes friction, in my experience. Even before CGNAT, most ISPs would rotate through different public IPs for a connection, roughly once a day. This made it harder (not impossible) for server-side tracking of requests for a particular household. But the way you accessed the local devices wouldn’t be affected by this rotation. With IPv6, the prefix deleted from the ISP becomes part of the address – unless you do something very specific about it – making rotation cumbersome, as you would change the address you would use to access the same device. And yes, I do know that link-local IPv6 addressing exists, but I have seen too many corner cases with those that makes it unlikely I will be using them again.
So what would I expect as a solution to this? I’m not sure. I know that there are plenty of enterprise solutions for zero-trust networks. But I don’t believe there is any consumer-friendly solution available right now. For it to work, you would need a significant change in networking, with a mutual authentication between a computer and its gateway, so that it doesn’t matter which IPv6 address it uses, the gateway can consider all of the connections belonging to that source. But that sounds a lot like a point-to-point VPN with local access to the network, doesn’t it? I even believe this might work if you were to use 802.1x with username/password authentication.
But I think this is going to be extremely overkill for most consumer users, so I don’t expect it to ever show up as being a feasible option. But one might as well dream, once you’re pretty much in FantasyLand.
