“But… why???”

This is the question I’m often asked, typically by vendors and manufacturers of networking equipment. I am an advocate for IPv6-native operation on our campus. That means no IPv4 addresses are allocated to individual nodes. While many sites are running dual-stack right now (using both IPv4 and IPv6 addresses side-by-side), we are trying to turn IPv4 off completely. This is the “gotcha” for many vendors; while IPv6 support has gotten much better in recent years, being able to fully turn off IPv4 still causes problems.

This post is an attempt to explain why I’m such a fan of IPv6 and why I am now making IPv6-native operation a requirement for any new equipment that we purchase.

We’re out of IPv4 addresses

The simple fact is that we’re out of IPv4 addresses. Yes, the entire world, but more relevant to my situation, our campus. We have a /23 allocated to us, which is 510 addresses. While that’s enough to host a bunch of servers with a public IPv4, it’s not nearly enough for a school campus.

We have just over 400 students and 200 employees (to say nothing of visitors and guests). Assuming one device per user, we’re already over our IPv4 allotment. However, it’s much worse than that. Many of our students have multiple devices (laptop, phone, tablet, game console). We have hundreds of phones, printers, security cameras, access points, projectors, AppeTVs, and network switches.

We segregate our network into multiple VLANs, each with their own subnet. This means that we “waste” possible IP addresses by allocating specific ranges to subnets that may not be full.

Thus, we’d need thousands (eventually possibly tens of thousands) of addresses to have “enough” for the entire campus. To increase our allocation, we’d need to lease addresses at a prohibitive cost.

[Most] NAT Sucks

Because we don’t have enough public IPv4 addresses, we do what everyone else in our situation does: NAT combined with RFC 1918 private addresses. More specifically, per RFC 4787, we have a NAT that features Address and Port-Dependent Mapping combined with Address and Port-Dependent Filtering. This is highly secure; traffic can only pass from the internet to our devices if our devices first initiate a connection. However, it means that the end-to-end, peer-to-peer nature of the internet is broken. If one of our machines wants to talk to another machine on the internet that is also behind a similar NAT setup, the communication cannot take place.

This messes up things like hosting online games, and requires other protocols to have workarounds (like STUN, TURN, and ICE) to deal with NAT traversal.

As an aside, I’d like to reinforce the notion that NAT is not a firewall. NAT like ours (where a pool of addresses are shared) must contain a state tracker to remember which connections go with which addresses. As such, they often reject connections that don’t match an existing state, resulting in firewall-like behavior. However, you don’t need NAT to have a firewall, and (at least for simple 1:1 mappings) you don’t need a firewall for NAT.

Thus, NAT (in my mind) is not a desirable feature. We have it out of necessity (not having enough addresses). If I had enough public IPv4 addresses, I would not use it.

Dual-Stack Is Double The Work

For many years, we’ve been running a dual-stack network, where clients get both an IPv4 and IPv6 address. This has worked quite well, and we routinely observe 40%-60% of our traffic going over IPv6 without any attempt on our part to prioritize IPv6.

However, maintaining both address families is a bit of a pain. We have to subnet both families, advertise both via DNS, have ACLs for both, etc. And, when issues occur, we need to debug both families in case there is an issue with one but not the other.

One NAT Is Better Than Two

Our IPv6 addresses are globally-routable, and so are “real” addresses that support any use we want. Our IPv4 addresses are RFC 1918, and do not work as global addresses (they are behind NAT). Thus, we’d rather use IPv6 addresses.

However, we still need a way to reach IPv4-only resources. Currently, that’s what assigning each node a v4 address is good for. If we go IPv6-only we still need a mechanism to get to the IPv4 internet.

Luckily for us, that mechanism exists: NAT64. It’s still NAT, and has the same drawbacks as our current IPv4 NAT (can’t play games, ports and addresses are shared in a pool). However, there are no additional disadvantages (NAT64 is no worse than NAT44).

So, if we accept that we need to use NAT to reach the IPv4 internet (either NAT64 or NAT44), why not pick the one that doesn’t require us to support an entire legacy address family?

Our Plan

Our current plan is to deploy IPv6 to all nodes on our campus (done), and provide a campus-wide NAT64 service to allow those nodes to reach legacy IPv4 addresses (in testing). Once that’s in place, we should be able to disable IPv4 for all nodes that implement IPv6 fully (we will have some legacy equipment that cannot be upgraded to use IPv6).

The laptop I’m typing on has no IPv4 address assigned to it right now, and actually hasn’t had one for several months. I’m able to do all my work without issue, connecting to services, browsing the web, etc. I have discovered the occasional service on campus that is v4-only, and I’ve been fixing those as I go. Honestly, I thought I would run into many more issues, but so far it’s been nearly seamless.

Postscript Rant: IPv6 Sucks Less Than Other Options

Is IPv6 perfect? Of course not; nothing is. It had some glaring omissions when it was getting started, and it occasionally suffers from second system syndrome.

I happen to think that IPv6 is still a decent protocol, even with its warts. However, no matter how much you may not care for it, it is the least worst option. Consider some of the alternatives:

❌ Ignore the issue / make NAT better

I tend to hear this from people who have the luxury of sitting on plentiful IPv4 address allocations. Good for you, but my campus doesn’t have enough public addresses, and I’m not keen to accept NAT as “good enough” for all applications. And, there are certainly applications that do not work with NAT (online games being the first example that comes to mind).

NAT is about as good as it’s going to get. Given the pressure on IPv4, if we could have made NAT any more tolerable, we would have by now. The traversal workarounds that exist are helpful, don’t get me wrong, but pure peer-to-peer connectivity simply cannot exist in all situations.

❌ Reclaim some of the reserved/underutilized IPv4 space

This is just kicking the can down the road. Even if we reclaim millions of addresses, they will be used up by new devices and services. The 4.2 billion IPv4 addresses out there are a finite resource, and not enough. Additionally, a lot of software would need to be upgraded to allow use of previously reserved IP ranges.

APNIC has a very detailed analysis on the utilization of IPv4 addresses and discusses some subtleties that I’m glossing over here. Addresses are being traded, sold, and “recovered” that weren’t used before. The Class E space (260+ million addresses) is still marked as “reserved” and could be freed for use. However, I feel that even that many addresses won’t make a big difference on a planet that already has tens of billions of active devices.

❌ Extend IPv4

There are proposals to extend the v4 address space by reclaiming reserved addresses, using header extensions, or making other minor (compared to v6) changes. However, end-to-end is still very difficult; we would need a way to identify these addresses (extensions to DNS?) and route them (update all the routers?). Given the foot-dragging that we’ve seen on IPv6, I don’t think another competing “let’s update everything everywhere” strategy is effective. To my knowledge, no proposal of this type has received serious consideration.

❌ Start Over

Some argue that if it’s taken this long and IPv6 still hasn’t been adopted, we should start over. However, I don’t think that a new protocol would be so much better that it would drive instant adoption across the world. It would likely suffer from similar adoption issues, and have wasted 20 years of work on IPv6.

I hate to argue in favor of sunk-cost, but practically speaking a new protocol is not going to get designed, agreed upon, and adpoted at this stage of the game.

We are effectively out of IPv4 addresses; we don’t have decades to start over and try again with a new protocol (especially considering that it would now compete with the partially-adopted IPv6).

I Don’t Care That You Don’t Use It

One of my major pet peeves is when manufacturers claim that very vew of their customers use IPv6, and thus it isn’t a priority to support it. I argue that more people would use it if the manufacturers properly supported it!

10 years ago I was willing to tolerate equipment that didn’t support IPv6. Back then I had a major argument with our core switch provider (Juniper Networks) about IPv6 functionality, and they told me there was “no business case for IPv6 feature parity”. I didn’t like it then, and went all the way to the VP of Product Line Management before I was forced to give up.

Companies have had over 20 years to get their products working with IPv6, and during the last 5 of those it should have been abundantly clear that IPv6 is not going away and will be required moving forward. I know that I’m likely ahead of the adoption curve (in terms of not being willing to fall back to IPv4), but I expect more network operators to demand these features as time goes by.

Thus, I no longer accept missing functionality in IPv6; products that lack feature parity will not get my business. Full stop.