Following on from my post from yesterday, here are four more of the most common misconceptions about IPv6 that I’ve come across (and some facts to set them straight).
Misconception #3: I’ll think about it tomorrow
Having read my previous post, you might now think, “Ok, looks like I need to deploy IPv6. But can it wait until the next month, or next quarter, or next year?”
In these circumstances I often point people to the Eisenhower matrix and ask, “If you have a task in the important, less urgent, quadrant of the matrix, do you wait until that task becomes important and urgent? (One example of where this might happen is when you need to enable IPv6 on your VPN infrastructure ASAP because your managers attended a conference with IPv6-only Wi-Fi?) Or is it more cost effective to be proactive now, if only to make sure the task is at least underway?”
Remember that while updating hardware and software and modifying workflows and procedures takes time, even more time is needed to change people’s mindset. That’s why we all should have started deploying IPv6 yesterday.
Misconception #4: IPv6 is IPv4 with longer addresses
If I’ve managed to convince you to deploy IPv6 and deploy it right now, one thing you should not be doing is assuming that IPv6 is just IPv4 with more bits for addresses — nor replicating your existing IPv4 infrastructure — because there’s more to it than that.
IPv6 is a much more advanced protocol and it has features and capabilities that do not exist in the IPv4 world. You might decide not to use all of this functionality but let’s take a look first so you know what IPv6 is offering.
A long time ago, I used to work for a system integrator company and would spend hours and hours discussing IPv4 address plans for customers’ networks: Shall this subnet be /25 or /26? Can we make that subnet /27 or would /28 still be ok?
Now, my address plan is extremely straightforward: /128 for loopbacks, /127 for point-to-point interfaces, and /64 for everything else. Saved time and simplified automation — priceless!
The next item on the simplification list: backbone addressing scheme.
Allocating and configuring subnets to infrastructure links (don’t forget creating PTR DNS records!) is such a chore even with automation in place. But does it have to be that way? One of the possible approaches is to assign global addresses to routers loopbacks only, leaving infrastructure links with link-local addresses (Figure 1). There are pros (simplified address plan, routers and DNS configuration) and cons (ability to address/reach a specific interface), many of which are discussed in detail in RFC 7404.
Figure 1 — Link-local only addresses on backbone links.
Another thing that can be simplified in IPv6 is host network stack configuration. I know I’m touching on an extremely sensitive topic here but just think about configuring network parameters on hosts in one RTT (router solicitation sent / router advertisements received), without the operational costs of an additional DHCP service and, most importantly, the ability to signal network configuration changes back to hosts instantly (particularly useful in multihoming scenarios).
Mentioning multihoming brings us to the topic of multiple provisioning domains (mPvD), another example of what IPv6 could provide. A PvD is a consistent set of network configuration information associated with a specific network. The concept was developed to assist multihomed hosts to deal with conflicting configuration between networks and to allow hosts to simultaneously use multiple networks. The PvD information is sent in the Router Advertisement option and may contain not just basic network config parameters (IPv6 prefix, default router, DNS), but also more sophisticated ones (such as captive portal information, bandwidth and so forth).
If this sounds interesting I’d recommend looking at this very good mPvD overview presented at IETF 98. If it sounds too complicated, then it’s time to talk about another misconception…
Misconception #5: IPv6 is too complex
For me, the most amazing thing about IPv6 is how many people consider it too complex and hard to understand.
Why do engineers who have no problem understanding EIGRP, OSPF and ISIS, the same people who are able to develop complex traffic engineering policies for BGP and troubleshoot RSVP, find IPv6 over engineered? Is it because, as we’ve discussed, people expect to deal with 128-bit IPv4?
Or is it because there are not so many good learning resources around? Unfortunately, many books tend to concentrate on just dull facts about the protocol without explaining why it works the way it does. Such an approach might make IPv6 look like a mysterious, complex machine; its inner logic, mechanics and, I’d even say, elegance is concealed from the readers. Well, I have good news for you. There is at least one book that talks about the whys and wherefores of IPv6 architecture, so I hope after reading it you would agree that IPv6 is no more complex than other technologies we work with.
Start your IPv6 journey IPv6@APNIC
Misconception #6: I’ve enabled IPv6, I’m done!
Last but not least, let’s talk about what to do when you have finally deployed IPv6.
The most common mistake is to assume that the job is now done. Unfortunately, not yet. What is now required is monitoring to ensure that IPv6 works and is being used. It’s not unheard of IPv6 being broken for a long time without anyone noticing (because nobody was looking). New equipment, new versions of software, misconfigurations during maintenance, and other kinds of human errors all could result in IPv6 not working as intended or not working at all.
In addition to a rather obvious idea of monitoring end-to-end IPv6 connectivity, IPv6 traffic level could be used as a very good indicator of potential issues. A sudden drop or unexpected decline on an IPv6 traffic graph would usually mean Happy Eyeballs fallback to IPv4 (Is IPv6 being slower? Is there any packet loss or have IPv6 packets gone travelling around the world due to a geolocation problem? Is IPv6 not available?)
One way of making sure this won’t happen again is to get rid of IPv4. It might sound extreme or futuristic but IPv6-only networks are becoming an operational reality and they do exist even outside of the cellular world.
But that’s another story and maybe a topic for another blog post sometime in 2019.
Jen Linkova is a Network Engineer at Google and Co-Chair of the RIPE IPv6 Working Group.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.