I have been having more discussions with colleagues around IPv6-only networks. This is an interesting development and I wanted to explore some of the drivers and rationale behind why this is becoming of greater interest to some really smart folks.
The discussions I have participated in have had four main rationales that come up as to why an IPv6-only network solution might make more sense. Let’s take a look at some of the motivations and explore if these could be potential reasons for you and your company to leverage IPv6-only architectures.
- Data Centers
At some point a data center outgrows the network segment definition that was established long ago when someone had to do some sort of sizing as part of their design. It is typical that an IPv4 /24 or similar sized allocation is given to data center network segments. With the rise of containers and solutions like Kubernetes and Mesos, having limited sized IPv4 subnets does not really give these services the capability to expand and grow in the way that they require. Having a single Layer 3 subnet with the 254 useable addresses available in a /24 subnet is extremely limiting for something like Docker, which might want to run hundreds if not thousands of instances at the same moment within the same network. How do you address this need without having to redo the IPv4 network design over and over again? A single /64 prefix in IPv6 can handle a huge amount of IPv6 addresses in any given subnet. In fact, you can allocate 10 million addresses a second in a /64 and not run out of addresses for fifty eight thousand years. You can see the math at my blog http://www.howfunky.com/2015/06/ipv6-docker-and-building-for-scale.html
Beyond the new address-hungry applications, we are now running data centers with a much higher server density within a single rack configuration than ever before. For instance, Facebook runs their TOR switches as a Layer 3 termination and traditionally allocates a single /24 per TOR switch for the devices in that rack. But they ran into allocation issues where they had more than 254 end nodes within a rack. They were having to add or modify the addressing and routing topology to accommodate this. A single /64 IPv6 prefix assigned to the TOR switch greatly simplified this situation. They should never have to go back to add addressing capacity to a single TOR before the lifetime of the equipment expires (see my math above). Keeping IPv4 in that environment actually limits what Facebook can do in terms of growth. When you are growing and adding services at the pace of Facebook you want to remove as many limitations as possible. Though the mass majority of companies are not growing at the rate of Facebook, I would still argue that they are a leading indicator for other businesses of how to solve many network scale problems. You can check out how Facebook is striving to move to IPv6 only data center at http://www.internetsociety.org/deploy360/resources/case-study-facebook-moving-to-an-ipv6-only-intern…
- Merger and Acquisition
The repeated structural problems with overlapping IPv4 RFC 1918 address space causes the need for RFC 1918 NAT, which breaks . Specifically, you can’t have multiple remote offices all with the exact same IPv4 address space appearing in the same routing table unless you translate the duplicates to a different address space, which is where NAT comes into play. For large organizations, which likely have a lot of IPv4 RFC 1918 address space already used or allocated this becomes a more pressing issue to address. This is especially true if they are merging or acquiring an equally large organization that relies equally on IPv4 RFC 1918 address space. How do you solve this? You can utilize public IPv4 to ensure the networks are unique but most organization do not have enough public IPv4 to address their entire network. At this point, Global Unicast IPv6 address space looks very attractive. You can guarantee global uniqueness and have more than enough address space and networks for any size global company. You would also have a very simple routing topology and simple access-lists to manage within the network. In many ways moving to an IPv6-only network for this use case can make a lot of sense. Alternately, you can deploy global IPv6 and use dual-stack to allow existing IPv4 networks to operate but between company networks use IPv6. By publishing IPv6 DNS for selected resources, common services are exposed and used. Take a look at Scott Hogg’s excellent blog on some of the challenges of running a dual-stack environment at http://www.networkworld.com/article/2222870/cisco-subnet/dual-stack-will-increase-operating-expenses…
- IoT networks
At some point you will have some sort of IoT network operating. It is likely you already have one at home if you are using products like Google Nest. These products are making their way into other markets like enterprise, SMB and large scale utility companies. Many of the solutions in the IoT space leverage IPv6 using small discrete networking stacks like 6LoWPAN. IPv6 is an ideal networks protocol since auto provisioning of addresses, discovery of services, and configuration of the default gateway can be done by the host without . Traditionally, IPv4 doesn’t have this flexibility in the protocol. There have been solutions that have been bolted on since IPv4 was first released but they are exactly that, bolted on, and require work and special skills to ensure they operate properly. If you are looking to have a simple-to-maintain system that runs at scale, can self-provision, and is easy to support, IPv6-only starts looking very appealing. Granted, IPv6 isn’t perfect. There are still issues that need to be fixed in IPv6 around multicast performance on Wi-Fi networks but these are being addressed by the wireless manufacturers and will likely be fixed soon.
- Isolated secure networks
It might seem strange to point this one out but if you have to run an isolated network (one that is not on the Internet at all) then IPv6 makes a lot of sense. First, you can guarantee that you do not have any leakage out to the Internet if your public connection is IPv4 only (or optionally you decide to use Unique Local Addresses or ULA). If you run the network as IPv6-only you have the added advantage that no IPv4 RFC 1918 or public IPv4 address space can do any routing on your isolated networks. Policies around access and tools that are used to detect any issues can narrowly focus on seeing IPv4 traffic and know that it is not allowed. Obviously, everything running in that network would need to natively support IPv6 but given the wide range of IPv6 support out there today I doubt that would be a huge roadblock at all.
So there you go, some valid use cases around why you might end up running IPv6-only portions of your network. These business use cases might come up sooner than you think so learning and understanding IPv6 will become more pressing. Investing in products and tools that support IPv6 today will go a long way to ensuring you can be nimble and adopt IPv6 quickly. Get ahead of the curve and start investing now on understanding and using IPv6. I’m not the only one thinking about this either, check out what the IETF has produced:
RFC 6586 – Experiences from an IPv6-Only Network
https://tools.ietf.org/html/rfc6586
RFC 7381 – Section 5 also talks about IPv6-only
https://tools.ietf.org/html/rfc7381#section-5
RFC 7404 – Using Only Link-Local Addressing inside an IPv6 Network
https://tools.ietf.org/html/rfc7404
Along with some good industry comments at:
http://packetpushers.net/why-your-network-should-go-ipv6-only/
http://blog.ioshints.info/2012/05/ipv6-only-data-center-built-by-tore.html
http://www.rmv6tf.org/wp-content/uploads/2012/11/Why-Your-Network-Should-Go-IPv6-Only1.pdf
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now!
– Ed
