Sitting pretty in IPv4 land? Look, you're gonna have to talk to IPv6 at some stage

How to juggle two smartly incompatible protocols

We can be forgiven for not having weaned ourselves onto IPv6 earlier. It's been around in draft form since late 1998, but was only released as a standard in July 2017 (that'll be RFC 8200). That this has finally happened, though, means we're being told more loudly than ever that we no longer have an excuse. So do we have one? Can we still stick with IPv4 if we want to?

IPv6 and IPv4

The two "flavours" of the Internet Protocol are different things entirely. You can't talk directly to an IPv6 device using IPv4, and vice versa. Those of you who are old enough, think back to the days when we ran Novell NetWare, which had its own proprietary protocol (IPX). You couldn't talk to an IPX-based NetWare server using IP, and neither could you talk to an IP-based Unix box using IPX. We therefore have to deal with two different protocols, so we're basically configuring two sets of networking on our equipment.

Computers are doing it for themselves

Some of our systems are already trying to make us evolve. Take the MacBook Pro I'm typing this on, whose Network control panel tells me that my IP address is 192.168.1.150. Just below that it tells me the IPv6 address, and that of my router, without me ever having told them to. IPv6 has been done for me. Looking down my router's DHCP log, I see that it has also assigned IPv6 addresses to a bunch of other stuff. Even without us thinking about it, IPv6 is creeping in.

Is doing nothing an option?

As the world moves to IPv6, you need to support it for your internet-facing devices. Expect people using your extranet portal to insist on IPv6. Expect people with whom you establish IP tunnels over the internet to demand it too. So, you could take the unilateral decision to stick with just IPv4 on your internet-facing setup, but as the world changes it'll leave you behind.

And IPv6 will, sooner rather than later, become the default when you run up a new device. Right now, if you fire up a new router it'll have IPv4 as its default access mechanism: don't be surprised if, in five years, it's IPv6 instead.

You therefore need to start supporting IPv6, even if your heart still belongs to IPv4.

What kit do I need?

You might think, if you're sticking with IPv4, that you don't have to change your internal network – but that's not the case. You still need to support IPv6 to some extent, even if you're not deliberately using it.

Happily, most of your existing kit will – as long as it's not ridiculously ancient. Dual IP stack support is common in new kit so your LAN routers, servers, desktops, laptops, Wi-Fi access points and so on will be fine. But don't take this for granted. If you do have older kit – or you've not upgraded switch, router, server and PC operating systems for aeons – some updates or replacements may well be in order.

Where you need to focus, with regard to tools that help you run a dual world (since that's what you'll end up with) is your core network management/monitoring tools and your "edge" devices.

Management tools

As your infrastructure is probably capable of routing both IPv4 and IPv6 (so long as you tell it to), you need to ensure that both protocols exist on the network – which means giving all the routing devices addresses in both protocols. And this is pretty straightforward, because much of it works in the same way as IPv4. In the domain name service, for example, you have "A" (address) records for mapping names to IPv4 addresses: IPv6 simply adds a new "AAAA" record for the new equivalent. On your routers, an IPv6 interface is named rather like its IPv4 equivalent. In the GUI of your Windows DHCP server you can create a new IPv6 scope just as easily as a new IPv4 scope.

Make sure your monitoring tools support both protocols too: the last thing you need is to require one set of tools for each type of kit – a single point of reference is essential for management and monitoring, and there's no reason you can't achieve that.

Why do I need IPv6 monitoring and management if I'm using IPv4? A couple of reasons.

First, you may have some stuff that forces you to use IPv6 whether you like it or not: any of you using Microsoft's Direct Access will be familiar with that concept, for example. You can't monitor it if your monitoring platform can't see it.

Second, with the tsunami of IoT kit (particularly in the "shadow IoT" realm), you need to be able to detect devices appearing on the network running IPv6, which you can't do if your management and alerting system can't see or understand the traffic. And where stuff is demanding an IPv6 address, you should seek to control what addresses are allocated rather than leaving devices' address selection to their own... well, devices.

At the edge

The fun bit is at the edge of the network, when the private network meets the big wide world. Internally you can do what you like (you're never going to run out of RFC 1918 private addresses), but externally you have to support both IPv4 and IPv6 if you're to ensure that everyone can get at, say, your website.

What's at the edge?

Let's imagine you have a web server, because you probably do. In our brave new world, you need to make it available to people via both IPv4 and IPv6 – because like it or not, there will soon be people out there who only do IPv6 and you increasingly need to support them.

So, your typical setup will be an edge router on your Internet connection, then some kind of firewall, then your web server. How shall we do this in our world where we want to prefer IPv4 but support IPv6?

Dual support to the endpoint

Option one is to run a complete dual-protocol stack as far as the server. So, you enable both IP flavours on the router, the firewall and the server. IPv6 connections are forwarded all the way with IPv6, and IPv4 ones with IPv4. It's not the best way to go, though. Two protocol stacks equals two lots of stuff to manage, and in my experience having two paths into and out of a server can lead to some interesting times if you have weird routing problems to diagnose. It's better to support just one protocol family wherever you can.

Multiprotocol landing point

What you'll do, then, is land the inbound connection from the internet on some kind of application-oriented edge device. A basic load balancer wouldn't work here, if all it does is direct the stream of traffic to the appropriate back-end server; instead, you'd use a reverse proxy or application firewall. The difference is that with the latter approach the proxy/app firewall is making a separate connection, so there's no need to support all protocols both inside and outside: you'd support both protocols on the internet side, but just IPv4 internally. As with most technology these days, it's no problem finding a reverse proxy (Apache is your friend, for instance) or app firewall that can do both IP flavours where you need it to.

Is that it?

Yes, pretty much. The thing with sticking with IPv4 is that you already have all the tools and knowledge you need in order to run it, so it's not a big deal to stick with it. The complexity is that while sticking with something you know, you still have to resign yourself to making at least part of your world work with IPv6, because if you don't you'll find yourself at least partly disconnected.

So, focus on the edge: the place where you can interface a multiprotocol internet to a single-protocol private network. Use a reverse proxy to put a virtual "air gap" between outside and inside and you can do what you like internally.

And make sure you monitor the internal world too. Even if you think you're IPv4 only, it's likely that you're not – and even if you are, shadow IT and IoT will soon change that. ®

PS: Yes, we know we're still on IPv4. The Register will be hitting IPv6 very Soon™...