Introduction: The Preeminence of Dual-stack
It’s probably safe to assume that when most of the enterprise IT administrators and network architects that have yet to deploy IPv6 think of what it will initially look like in their environment, they envision some model of dual-stack deployment. This is not by chance, of course. For over a decade, the prevailing advice from the IPv6 cognoscenti has been some paraphrase of the original quote from our very own Infoblox CoE blogger Scott Hogg: “Dual-stack where you can, tunnel where you must” (and often followed by the dire admonition to “translate only when you have a gun to your head.”)
But as with all axioms not handed directly from $DIETY in stone tablet form, it’s generally a good habit to periodically ask “why?” – especially given how rapidly our chosen field changes in general and, in particular, given how prominent certain deployments of IPv6-only have become in recent years. Our other Infoblox CoE blogger Ed Horley has written extensively about some of the reasons for these IPv6-only deployments along with the opportunities and challenges they may present to enterprise network administrators here, here, here, and here.
So why dual-stack? Probably the most perennially compelling answer to this question remains the primary reason it was advocated in the first place: as a risk-reducing transition mechanism in the critical interval between legacy IPv4-only network and IPv6-only networks. On a timeline that transition looks like this:
Having a network that forwards both IPv4 and IPv6 packets simultaneously doesn’t guarantee that all applications will work perfectly. But it does greatly reduces the risk, in theory at least, that an application will not work at all. This could happen either from its total lack of IPv6 support (in which case, the application continues to use IPv4 with no impact to the user) or from poor design or configuration causing it to behave erratically and rendering the application unusable.
The “Dual-stack network” column of the simple table below illustrates how, ideally, a dual-stack network would provide the greatest likelihood of connectivity for the greatest number of applications.
For the purposes of our discussion, in assuming that the dual-stack strategy of reducing application failure risk is successful, this table elides more obscure failure cases where an app may behave erratically or fail due to how it accesses the underlying network stack (or even how the underlying network itself may misbehave). Note of course that either of these cases is not unique to dual-stack and that such cases can and do occur with any routed protocol. A further qualification is that IPv6-only applications are very rare. Subsequently, the failure case of an IPv6-only application on an IPv4-only network is also rare (as opposed to the case of the IPv4-only application on an IPv6-only network, which as we’ll read about below, may be encountered more frequently due to the deliberate design choice of an IPv6-only network).
Dual-stack’s Dirty Little Secret and the Appeal of IPv6-Only
I’ve mentioned dual-stack as an architecture primarily employed to reduce the risks of adopting IPv6 – or perhaps more aptly, to amortize those risks over a long enough timeline as to make them manageable in a cost-effective way. None of this precludes the possibility that particular discrete networks within an organization might opt for an IPv6-only architecture. An often suggested example of this would be a brand new on-prem data center deployment. Building a data center using only IPv6 may provide provisioning and operational efficiencies that can’t be realized using either dual-stack or only IPv4. For example, the dirty little secret of dual-stack is the possibility of additional operational overhead that stems from having to deploy, maintain, and troubleshoot two address families – especially when the application or operating system stack choice of which protocol to use can be difficult to isolate.
This difficulty is a natural outcome of, among other reasons, the complexity of having two address families that each contain their own subsets of addresses – i.e., address scopes or ranges – that are defined to create some logical identification and/or isolation of networks by having address ranges that identify a particular use case or application. For IPv4, RFC 1918 address space is perhaps the most immediately familiar example of this. But an interface in IPv4 typically has only one address where IPv6 is designed and expected to configure many address per interface – each with a different range or scope, and therefore, supporting a different or variant use case.
The rules defining which source or destination address an application should use (defined in RFC 6724) can be quite complex – especially when IPv4 and IPv6 are both present – and thus make troubleshooting an application that appears to be misbehaving due to network access difficult and time-consuming. Thus, an on-prem greenfield data center deployment might offer architects the opportunity to avoid such additional operational complexity by opting to use only IPv6.
And there are additional potential benefits to using IPv6 in the data center. For example, the abundance of address space in IPv6 means always having enough unique (i.e., non-overlapping) address prefixes. Further, these prefixes can be allocated or assigned in a manner to facilitate aggregation (for routing optimization) and/or isolation (for better security). This is especially beneficial with multi-tenancy data center architectures. As long as the overall organizational IPv6 address plan – which will include the data center(s) – is done correctly, no shortage of unique subnets and addresses can occur.
Ed Horley offers additional arguments for why IPv6-only may make sense for the enterprise data center in this blog.
An IPv6-only Data Center Using DNS64/NAT64
The theoretical appeal of an IPv6-only network given the operational efficiency, architectural simplicity, and address provisioning ease it offers should be more clear. However, most data centers host applications or services that require the ability to connect to IPv4 resources on the Internet. Since IPv6 and IPv4 are not backward compatible, without some transition mechanism in place, an IPv6-only node has no way of establishing a connection with an IPv4-only resource (and vice versa).
DNS64 (RFC 6147) and NAT64 (RFC 6146) is one way of providing such an Internet translation interface for mono-protocol hosts. The diagram below depicts a customer on-premise or cloud location with an IPv6-only data center relying on DNS64/NAT64 to permit the IPv6-only nodes within the private data center to communicate with IPv4-only resources on the Internet. Note that the DNS64 and NAT64 components are often co-located within the IPv6-only data center (though they need not be: In this diagram they are somewhat dispersed as logical components for the sake of clarity).
Let’s review the steps indicated in the diagram to get a better idea of how DNS64/NAT64 works.
- An IPv6-only node in the data center wants to reach www.ipv4only.com. This node sends a query for www.ipv4only.com/AAAA to the local recursive name server running DNS64.
- This local recursive name server sends along the www.ipv4only.com/AAAA query but gets a negative response from ns1.ipv4only.com; it follows up with a query for www.ipv4only.com/A and gets a response.
- Using the 64:ff9b::/64 prefix, the local recursive name server running DNS64 synthesizes an IPv6 address to return an AAAA record to the requesting node.
- Next, the IPv6-only node sends a packet with the synthesized IPv6 address as the destination, which gets routed to the NAT64 component.
- The NAT64 component sends this packet to the destination IPv4 address, keeping track of the NAT64 mapping for the connection.
- The IPv4-only web server receives the request forwarded from the NAT64 component and returns a response to the NAT64 component.
- The NAT64 component translates the packet to IPv6 and returns it to originating IPv6-only node in the data center.
This solution can scale and perform quite well and doesn’t require a lot of additional hardware or software configuration to a make it work. If you’re already running Infoblox NIOS you probably have DNS64 support available. All you would need for additional hardware would be a NAT64 component. Several network hardware vendors, including A10 Networks, Cisco, Palo Alto Networks, etc.) offer NAT64 components that will integrate with Infoblox. The usual caveats wherever NAT is concerned may still apply: broken applications, broken geolocation, etc. Also, since DNS64/NAT64 is essentially fabricating a DNS response to facilitate a form of IPv6 to IPv4 translation, it violates one of the key premises of DNSSEC; namely, that DNS responses haven’t been modified in transit (which might otherwise suggest an invalid response or man-in-the-middle attack.
Two caveats with this design approach. The first one is that applications may use IPv4 literals; i.e., a specific IPv4 address in the application code requiring IPv4 connectivity without which the application will likely fail in some way. These IPv4-only literals can show up in URLs. Since these are actual IPv4 addresses that don’t require name resolution, the DNS64/NAT64 mechanism cannot “detect” then facilitate their attempts to connect to the IPv4-only Internet. The result is broken application behavior.
The second caveat is that the DNS64/NAT64 approach doesn’t provide a solution for the “inbound” case; i.e., IPv4-only hosts needing to access IPv6-only resources on the same network. In that instance, the simplest solution would be to proxy those IPv4-only inbound requests. Using an SLB46 solution at the Internet edge of the IPv6-only data center is one method for accomplishing this.
Optimizing for IPv6-Only
Vendors that are serious about supporting their customers IPv6 adoption efforts have taken steps to support IPv6-only environments. For instance, a widely-recognized advantage of the Infoblox DDI solution set derives from its patented Grid technology, which makes its DDI functions highly available, secure, and easily managed regardless of the scale of the solution. The communication required between members to support the Grid works over IPv6-only.
Though IPv6-only deployments are still much less common than dual-stack deployments, standards bodies such as the IETF continue to propose optimizations for IPv6-only environments in an effort to continue to IPv6 drive adoption and enhance the performance of IPv6-only wherever deployed. One recent optimization of this type can be found in the this draft: IPv6 Router Advertisement IPv4 Unavailable Flag. The idea is simple enough: one of the available reserved bits in the IPv6 Router Advertisement would be used to indicate that IPv4 is not present on the link. This flag could be detected by clients on the segment allowing them to optimize their configurations (including for instance disabling IPv4 altogether) in order to avoid one or more of the following issues:
- Excessive Layer 2 broadcast traffic, especially with big wireless networks
- A resulting overloading of switches in multi-segment wireless networks
- The draining of battery power on wireless hosts that aren’t configured for IPv4 (or are and attempt to access services over IPv4)
- The use of IPv4 as an attack vector where IPv6-only monitoring mechanisms would fail to detect them
Conclusion
The path from IPv4-only to dual-stack to IPv6-only has proven to be a relatively long one, given the overall age of the Internet and considering as well that IPv6 has been in the works since the early 1990s. Dual-stack has been critical in making the risks and costs associated with IPv6 adoption and resulting application performance more manageable. Transition technologies beyond dual-stack such as DNS64/NAT64 are proving useful in enabling the emergence of the IPv6-only data center with all the advantages it may offer. Vendor support for IPv6-only features is helping keep the risks and costs low on the path to an IPv6-only enterprise. Meanwhile, the IETF continues to propose optimizations that should enhance performance in IPv6-only environments. Likely sooner that we expect, the phrase “IPv6-only” will sound quaint.
Tom Coffeen (@ipv6tom) is a co-founder of HexaBuild, an IPv6 consulting and IPv6 training company. Tom is the author of IPv6 Address Planning on O’Reilly Media. You can follow HexaBuild on Twitter and LinkedIn.
