{"id":777,"date":"2018-05-03T21:59:26","date_gmt":"2018-05-03T21:59:26","guid":{"rendered":"https:\/\/live-infoblox-blog.pantheonsite.io\/?p=777"},"modified":"2022-10-19T16:03:45","modified_gmt":"2022-10-19T23:03:45","slug":"on-the-road-to-ipv6-only-from-dual-stack-to-dns64-nat64-and","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/on-the-road-to-ipv6-only-from-dual-stack-to-dns64-nat64-and\/","title":{"rendered":"On The Road to IPv6-Only: From Dual-Stack to DNS64\/NAT64 and Beyond"},"content":{"rendered":"

Introduction: The Preeminence of Dual-stack<\/strong><\/p>\n

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:\u00a0“Dual-stack where you can, tunnel where you must”<\/a>\u00a0(and often followed by the dire admonition to “translate only when you have a gun to your head.”)<\/p>\n

But as with all axioms not handed directly from $DIETY in stone tablet form, it’s generally a good habit to periodically ask “why?” \u2013 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\u00a0here<\/a>,\u00a0here<\/a>,\u00a0here<\/a>, and\u00a0here<\/a>.<\/p>\n

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:<\/p>\n

\"IPv4<\/p>\n

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.<\/p>\n

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.<\/p>\n

\"Dual<\/p>\n

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\u2019ll read about below, may be encountered more frequently due to the deliberate design choice of an IPv6-only network).<\/p>\n

Dual-stack’s Dirty Little Secret and the Appeal of IPv6-Only<\/strong><\/p>\n

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\u00a0additional operational overhead<\/a>\u00a0that stems from having to deploy, maintain, and troubleshoot two address families \u2013 especially when the application or operating system stack choice of which protocol to use can be difficult to isolate.<\/p>\n

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 \u2013 i.e., address scopes or ranges \u2013 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 \u2013 each with a different range or scope, and therefore, supporting a different or variant use case.<\/p>\n

The rules defining which source or destination address an application should use (defined in\u00a0RFC 6724<\/a>) can be quite complex \u2013 especially when IPv4 and IPv6 are both present \u2013 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.<\/p>\n

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 \u2013 which will include the data center(s) \u2013 is done correctly, no shortage of unique subnets and addresses can occur.<\/p>\n

Ed Horley offers additional arguments for why IPv6-only may make sense for the enterprise data center\u00a0in this blog<\/a>.<\/p>\n

An IPv6-only Data Center Using DNS64\/NAT64<\/strong><\/p>\n

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).<\/p>\n

DNS64 (RFC 6147<\/a>) and NAT64 (RFC 6146<\/a>) 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).<\/p>\n

\"IPv6<\/p>\n

Let’s review the steps indicated in the diagram to get a better idea of how DNS64\/NAT64 works.<\/p>\n

    \n
  1. An IPv6-only node in the data center wants to reach\u00a0www.ipv4only.com<\/a>. This node sends a query for\u00a0www.ipv4only.com\/AAAA<\/a>\u00a0to the local recursive name server running DNS64.<\/li>\n
  2. This local recursive name server sends along the\u00a0www.ipv4only.com\/AAAA<\/a>\u00a0query but gets a negative response from ns1.ipv4only.com; it follows up with a query for\u00a0www.ipv4only.com\/A<\/a>\u00a0and gets a response.<\/li>\n
  3. 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.<\/li>\n
  4. Next, the IPv6-only node sends a packet with the synthesized IPv6 address as the destination, which gets routed to the NAT64 component.<\/li>\n
  5. The NAT64 component sends this packet to the destination IPv4 address, keeping track of the NAT64 mapping for the connection.<\/li>\n
  6. The IPv4-only web server receives the request forwarded from the NAT64 component and returns a response to the NAT64 component.<\/li>\n
  7. The NAT64 component translates the packet to IPv6 and returns it to originating IPv6-only node in the data center.<\/li>\n<\/ol>\n

    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\u00a0DNS64<\/a>\u00a0support available. All you would need for additional hardware would be a NAT64 component. Several network hardware vendors, including\u00a0A10 Networks<\/a>, 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.<\/p>\n

    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\u2019t require name resolution, the DNS64\/NAT64 mechanism cannot \u201cdetect\u201d then facilitate their attempts to connect to the IPv4-only Internet. The result is broken application behavior.<\/p>\n

    The second caveat is that the DNS64\/NAT64 approach doesn\u2019t provide a solution for the \u201cinbound\u201d 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.<\/p>\n

    Optimizing for IPv6-Only<\/strong><\/p>\n

    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\u00a0Grid technology<\/a>, 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\u00a0works over IPv6-only<\/a>.<\/p>\n

    Though IPv6-only deployments are still much less common than dual-stack deployments, standards bodies such as the\u00a0IETF<\/a>\u00a0continue 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:\u00a0IPv6 Router Advertisement IPv4 Unavailable Flag<\/a>. 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:<\/p>\n