I’m excited to have been invited by Cricket Liu and Tom Coffeen to join Infoblox’s IPv6 Center of Excellence (CoE) and to provide some content to the CoE Bloxhub site to spark some interesting discussion and debate around IPv6, DNS, network management and automation. It is also an opportunity to give my perspective on what I see happening in the industry. I wanted to begin with a post about IPv6 (a topic I am passionate about) and how it’s connected to some of the other technologies I think are relevant and exciting in the industry.
IPv6 within the context of the big things happening in networking today
IPv6 is one of many transformative technologies that will impact the networking industry over the next 5-10 years. While currently Software Defined Networking (SDN), Software Defined Data Center (SDDC), Openflow and Network Function Virtualization (NFV) command much of the headlines in trade journals and industry shows I still believe that IPv6 will be a technology that network professionals will need to embrace and learn. Why do I feel this way? First, SDN, SDDC, Openflow and NFV are all about automating the data center, often for the purpose of running cloud infrastructure (OpenStack, CloudStack, vCloud, etc.) The goal of this automation is to empower application developers to more rapidly provision services for companies. The automation for private, hybrid and public cloud all share this theme (along with the additional goal of doing more with less). Automation however does not solve some fundamental issues that come with building large elastic cloud architectures.
A critical problem in dealing with large cloud infrastructures is managing resources. Sometimes the solution to this challenge involves solving scarcity problems in novel ways (network overlay solutions to get around VLAN limits) and sometimes it involves adopting newer technologies to overcome legacy constraints (Openflow, SDN and IPv6 could all fit this description). Uniqueness is critical in multi-tenant (shared) environments making isolation and security controls key requirements. IPv6 helps address the two issues of scarcity of IP addresses and global uniqueness within any cloud or non-cloud environment. By solving these two issues, cloud infrastructure providers are able to enable growth and scalability while still ensuring they are providing global uniqueness and the capabilities (if needed) of security isolation.
So there it is, my explanation of why IPv6 is going to be so important to network and cloud operators. But what about enterprise and small and medium sized businesses?
IPv6 within the context of enterprise and SMB networks
IPv6 is a different discussion for enterprise and SMB customers. Often for them, the key questions around IPv6 are:
Why should I bother deploying IPv6? IPv4 works just fine and I have no IP resource limitations with the RFC 1918 address space I am using today in conjunction with NAT so why add the headache?
And,
If I do deploy IPv6 in my environment, how do I make it look and operate the same as IPv4?
The question around why has been previously addressed here, here, and (dating all the way back to 2007 from the legendary Jeff Doyle himself), here.
For a while now, my summary argument has been: The date the first RIR experiences depletion is the only date that matters (and that date has already happened for APNIC). The rationale for my argument is that when businesses, education institutions and government organizations in that part of the world are only given IPv6 as a means to communicate on the Internet then the rest of the world needs to talk IPv6. If you choose to not talk IPv6 then you lose the ability to communicate with the next generation of the Internet and in the immediate future this may work but long term you will have a degraded Internet experience. If you only want a fraction of the Internet than stay on IPv4 only but realize you will eventually have to move to IPv6.
It is that simple.
You can argue how long it will take for an IPv6 communication channel to become critical for your organization but eventually you must add IPv6 or risk the potential of losing Internet connectivity. Even if you think you would never do business, or correspond with entities, in that part of the world, something will eventually happen that will cause you to reconsider adoption of IPv6. Perhaps one of your executives will vacation in Australia, New Zealand, Singapore, Japan or China. They attempt to establish (from a local business or hotel) a VPN connection back to the company network, but IPv6 is the only protocol available in that part of the world. Do you tell them to go find someplace that has IPv4 available? Do you tell them you have no plans to support IPv6? Do you just explain it isn’t that important to your business? Perhaps you would like to admit to them you don’t understand it? Perhaps this is your early retirement plan?
Well, enough on why, lets tackle the how question.
“How do I make it look and operate the same as IPv4?”
As people learn IPv6, they become very aware that it has a different network deployment model. Almost everyone today is leveraging RFC 1918 IPv4 address space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) to address their internal network(s). They utilize a firewall or routing device at their Internet edge to perform network address translation (NAT) and perhaps even port address translation (PAT) or a combination of the two. Many mistakenly think that this NAT or PAT process affords their network some form of security (Scott Hogg covers this in more detail here). The first instinct from those looking to match their existing network configuration is to ask, how do I leverage NAT with IPv6? Can I map all my firewall rules for IPv6 to IPv4? Is there an address space in IPv6 that is the same as RFC 1918?
The answers are neither as short nor as clean as everyone would like. First, NAT was invented to address a specific need requirement of IPv4, the fact that we were running out of public IPv4 address space. NAT was invented to solve that single issue. Given the astronomical size of the IPv6 address space there is no need to conserve IPv6 addresses in the same way. In fact, there is so much IPv6 address space it is hard to argue you would ever need to use NAT for its original purpose. This is why you hear many IPv6 advocates state that NAT is dead and should not be used.
While NAT for IPv6 does exist in the form of NPTv6 (and NAT66 and formally NAT-PT), it was designed to address some very narrow use cases: Specifically, for those that might run multiple Internet connections without leveraging BGP and Provider Independent (PI) space. Needless to say, you may still have to run NAT in some situations but they should be very limited. So, what becomes the big hurdle for everyone can be stated in the form of a question:
If I am not using NAT, what am I using?
The answer is that you are utilizing global unicast IPv6 addresses throughout your network. This means you should rely on a stateful firewall, and in addition you should be running a host-based firewall. The reality is, for most organizations, they already do this today for IPv4. It just so happens your stateful network firewall also happens to run NAT. In the case of IPv6, you just don’t need that NAT function. (See, we made your life easier!).
Firewall rules – copy them all?
Mapping your existing firewall rules from IPv4 to IPv6 can be problematic. Likely, you will first bring up IPv6 in a limited fashion. There is no reason to open up all the services on the firewall for a host that may only be doing one or two IPv6 services as compared to its IPv4 counterpart. Also, Path MTU Discovery as well as some multicast requirements means that you will be developing new first-hop and firewall rules to accommodate this new behavior. Best practices for firewalls say to only enable services you use. Luckily, your firewall no longer has to consume resources to perform a NAT function for IPv6.
Things get a little more interesting with IPv6 and host firewalls along with NFV solutions for hypervisors and scaling out services in a cloud automation solution. The reality is that you are likely managing all those frameworks for IPv4 today; they will just need to get mapped over to IPv6. Some key differences will be how DHCP works and perhaps network tunnel end-points. Outside of that, it should be remarkably (and boringly) familiar to what you are already doing with IPv4.
Finally, we get down to what matches RFC 1918 in IPv6?
There is actually an IPv6 address allocation designed to not be routed on the public Internet at all. It is called ULA or unique local addresses. The idea is that you can use an algorithm to generate an IPv6 prefix that will be unique enough to build out an “internal” network. If you ever require merging your network with another company the likelihood you will have overlapping ULA space is very low. ULA may have some good use cases like labs, out of band networks, or super secure networks, but all the functions you can do with ULA you can do with global unicast addresses. So the real question is:
Are there some additional use cases above and beyond those I’ve given for ULA?
Perhaps, but I think we will leave that discussion for another post.
In summary, IPv6 will prove to be an impactful tool for those building cloud architectures and management platforms. It may not be recognized as such today but it will become so as those providing these services realize the depletion problem they face with IPv4 in addition to the scaling problems they face. The good news is that Infoblox has information, tools and solutions designed to address challenges arising from deployment of IPv6, DNS plus virtualization, network automation and soon cloud. Keep an eye out here for my next post, which will go over some common IPv4 network deployments and how you would map those over to IPv6.
– Ed Horley
Follow Ed on twitter or read his personal blog.
