It is arguable that IPv6-only might be years away but it is still worth reviewing what technologies you will need to introduce to your environment to support legacy IPv4 once you make the move. There are already examples of IPv6-only networks such as Facebook and others. When IPv6 becomes the de facto protocol for the Internet it is highly likely that many organizations will make the change over to IPv6. While this outcome seems unlikely today there is a reasonable amount of evidence that this could happen sooner than many anticipate. Just take a look at the public IPv6 adoption statistics for North America that Google provides to understand the current path IPv6 adoption is on.
So let’s jump from my last article titled “What Tech do I need in a dual-stack adoption strategy? “ and consider what technologies are required when dealing with an IPv6-only network. At a minimum it will be an interesting academic exercise (for those who will stay with dual-stack).
Assuming you decide to move to IPv6-only then there are specific technologies that would be of interest to help deal with the occasions where you might need to connect to IPv4 services. You may need this for legacy services (islands of IPv4 within your network) or public Internet IPv4 that has not adopted IPv6 yet. If you are unfortunate enough to be stuck with much older operating systems like Windows XP, Windows Server 2003 or old Apple Mac OSes you might have odd behavior like DNS lookups over IPv4-only even if they partially support IPv6. You may also face the situation of embedded systems that will only support IPv4 like badge readers, old surveillance systems, KVMs, UPSs, etc. These will be your grouped logical islands of IPv4 but they likely are very distributed which provides its own sets of challenges.
Like the previous article, I am going to limit the discussion to technologies that would be of interest to enterprises and smaller businesses. There is a broad and extensive set of technologies available to service providers, telecommunication and hosting providers that are not tailored to the needs to most enterprises and small businesses.
IPv6-only phase:
The weird moment you thought would never happen actually happens. You have made the decision to move the company entirely to IPv6-only. Let us establish some ground rules about IPv6-only so we all start with the same assumptions.
- All your current equipment and systems in your network support IPv6
- You will need to provide a transition method for those systems that are “stuck” on IPv4-only as a protocol
- You will start by removing IPv4 from a small, tightly controlled segment of the overall network
- You will isolate the IPv4-only hosts into islands
- You may provide IPv4 as a service (overlay or tunneling)
Now that we have this basic understanding, let us talk about the things you need to do for an IPv6-only network to function in this IPv4 centric world.
- Just like with IPv4-only or dual stack, put in place First Hop Security (FHS) measures for IPv6 to ensure that a misconfiguration or bad actor cannot put their own RA on the Ethernet Layer-2 segment
- Have inspection systems in place looking for IPv4 and IPv6 traffic and monitor that traffic. Because you are primarily running an IPv6-only network you may eventually raise alarms when IPv4 traffic is seen
- Allow the correct ICMPv6 traffic in your ACLs to allow for the proper functioning of Neighbor Discovery (including components like Path MTU Discovery)
- Inspect IPv6 traffic for IPv6 and IPv4 tunneled traffic (all IPv4 should be tunneled in some way since this is an IPv6-only network)
- Modify (or choose) your DDI platform to handle IPv4 and IPv6 values
- Provide access to IPv4 resources from IPv6 only hosts (via a translation method such as DNS64/NAT64)
The great news is that what you need from a technology basis you likely already established when moving to dual-stack. You already built out a DNS64/NAT64 solution so you simply continue maintaining that. You may need to establish more IPv4 tunnels on top of your IPv6-only network to allow a centralized DNS64/NAT64 model but it is possible to build a distributed model and have that service at the edge of every IPv4-only island.
The major technologies you will use for transition are either tunneling or translation-based. Tunneling really is not an option for hosts but for network overlays is a useful tool to connect islands of IPv4-only. Because IPv6 is not backwards compatible with IPv4 there is no simple way for the networking protocol itself to accommodate the translation. Often this would mean running a proxy of some kind to solve this shortfall. There are several pseudo-proxy-like technologies available as an edge service to accommodate IPv6-only hosts accessing IPv4-only services and the reverse. They are:
SLB64
SLB46
DNS64/NAT64
We covered these in detail in the last article so go back and review that material to understand it better. Far more interesting is what are the scaling and technical difficulties you will run into when trying to operate an IPv6-only network.
There are two structural problems you will face in operating an IPv6-only network. First, integration with third party networks (Cloud, partner, etc.) will likely continue to operate as IPv4. If they do not have an IPv6 option, you will need to build an island of IPv4 for the expressed purpose of terminating these IPv4 peering points (VPN or otherwise) and then provide them an SLB46 service to communicate with your local IPv6-only hosts. There is no guarantee the SLB64 service will work properly for all services (especially if you are supporting some really old systems). If you run into a problem, you may need to deploy a dual-stack proxy host to accommodate the single service you need to connect to. Alternately, you can do host IPv4 tunneling to effectively route an IPv4 address to the specific host that needs to talk to that cloud or partner services. This is using a network IPv4 overlay on top of your IPv6-only network but for the explicit purpose of connecting to the cloud or partner services. You could do this with VMware NSX for example.
The second structural problem is connecting with public IPv4-only hosts on the Internet. It is likely the majority of those connections are http/https based and will work just fine with DNS64/NAT64. Getting some sort of data and alerting out of this solution will be important however because when things break having accurate data to troubleshoot will be important. Having a DDI system that gives you far better visibility into what is happening will become an important tool in your tool belt at that time.
As you can see, you likely already deployed both these technologies when you moved to dual-stack. With careful planning, you actually will not be adding new services to move to IPv6-only. Your transition plan will simply be removing IPv4 addresses, routes and resources from the network.
This means getting to IPv6-only is relatively simple. Start from your host OS infrastructure and start disabling IPv4. This can be done in mass by removing IPv4 DHCP helper address information or scripting to remove manual IPv4 assignments to servers. Once you have a network functioning IPv6-only then you can remove that IPv4 subnet and route from your network gear. This frees up resources on that device. Eventually you can turn off IPv4 routing and any specific IPv4 resource specific configurations on your switch and routing platforms. You will still want to run security services on IPv4 to protect your network from rogue IPv4 resources.
Some resources you might want to review are:
RFC 6586 – Experiences from an IPv6-Only Network
RFC 7404 – Using Only Link-Local Addressing inside an IPv6 Network
That covers the third and final phase. If you manage to move to an IPv6-only network anytime soon, congratulations. You have accomplished something many companies today cannot do. With that said, even moving to dual-stack is a huge deal and all of us here on the Infoblox IPv6 Center of Excellence really want to hear your stories about your journey. So please reach out on twitter or comment on this blog post and share your thoughts and ideas. We love hearing from you all!
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now!
– Ed
