While a bit cliche, the last days of each year are a good opportunity to reflect on the year – progress made, problems solved, insights gained – and to look towards those same things for the upcoming year.

2012 saw Google measuring IPv6 traffic clearing over 1% of overall traffic – while 1% is still too low, check the chart.  The phrase “hockey stick” comes to mind – it will be very interesting to see if this exponential growth trend continues (or accelerates).

2012 saw “World IPv6 Launch” happen, a very successful follow-up to “World IPv6 Day” in 2011.  ”This time it is for real”, meaning not just a 24 hour light-up of some Ipv6-capable site; but a permanent light-up of IPv6 of your primary site.  And getting ISPs to commit to lighting up some customers as well.

(Sidenote:  I personally benefit from this in that Comcast has deployed native IPv6 in  my service region.  I have native IPv6 at my home; not because I ‘know someone’ and not because I configured a tunnel or loaded custom hacked-up firmware on my CPE.  I have native IPv6 because my ISP supports it, my cable modem happens to be DOCSIS3.0 capable, my off-the-shelf CPE (Linksys 4200v2, if you must ask) does DHCPv6 and because all of the computing things in my house support it.  Win!!)

2012 also saw the US federal government’s “OMB2012″ deadline come to pass.  And while many agencies failed to meet it, many did (kudos to the Department of Veterans Affairs (va.gov) and even those that didn’t – hopefully they have started down the right path.  A great guide to these requirements, and the now-on-deck 2014 deadline is available in the “Planning Guide/Roadmap Toward IPv6 Adoption within the U.S. Government”

In our view, 2012 is also the year when having an IPv6 presence on the Internet became An Important Thing.  sadly, many environments that have taken this bold step often fail to maintain the same level of service, support and monitoring as their IPv4 offerings.  To that end, we encourage the use of something like IPv6Sonar to monitor the status and performance of you site, over both IPv4 and IPv6.

Anecdotally, 2012 has also seen the training work continue to accelerate.  This is a Good Thing, as understanding IPv6 is an important step in getting it deployed – and we have a long way to go in spreading this knowledge!

On the topic of sharing information, another pet peeve of mine: articles authored in such a way that they could easily be misunderdstood.  For example, this article makes several valid points – but also raises points that require more clarification to avoid misunderstandings.
(Also, note that NAT-PT has officially been deprecated – DNS64/NAT64* is where it is at; (go read about that here and here!))

* – as a final aside: IPv6-only devices are something many have said will not happen in the near future, but clearly that is short-sighted and ignores one very important aspect for certain deployment scenarios.  Such as my phone.  In the interest of mitigating certain technical and economic impacts of dual-stacking cellular devices, my carrier** has elected to make IPv6-only an option for connecting to their network (and it is an option for now, the user needs to reconfigure the phone to do this).  Naturally, I continue to need access to IPv4-only sites – and this happens via DNS64/NAT64!

** – OK, I lied.  One more aside – while my carrier is doing this great work in getting IPv6-only devices deployed, note that their website is IPv4-only.  That’s right, I actually need to use their DNS64/NAT64 implementation to get to their own website.  Insert the “sad trombone” sound here …

And I close with a smile – feel free to take a minute (less, actually!) to watch our video about how you might approach your IPv6 training needs .

I hope you had a fantastic 2012, and are looking forward to an even more IPv6-enabled 2013!
/Your humble IPv6 servant

Last time we looked at NAT444, this time we will examine DNS64/NAT64.  I always write the mechanism that way because the DNS lookup (and possible manipulation) comes first, then the NAT operation.

The DNS64/NAT64 mechanism (RFC 6147, RFC 6146) provides a way for an IPv6-only client to exchange IP packets with an IPv4-only server.  Because (of course) IPv6 nodes can only send IPv6 packets, and vice-versa for IPv4-only nodes, translation must be performed on the packets somewhere along the path.

Translating IPv6 packets to IPv4 packets is not a particularly modern capability.  For example, NAT-PT specified a similar capability (RFC 2766, February/2000).  NAT-PT does not scale well, however, because so much manual state had to be developed and distributed to the participating nodes.  As a result, NAT-PT was moved to “Historic” status (RFC 4966, July 2007).  DNS64/NAT64 builds on NAT-PT, but enlists the DNS server capability, with some DNS64-specific extensions, to make IPv6-IPv4 packet translation scalable and deployable.  One significant difference between NAT-PT and DNS64/NAT64 is that in the later the IPv6-only node must initiate the connection.    That is why above I use the language “IPv6-only client” and “IPv4-only server”.

As we often do, let’s explore DNS64/NAT64 via an example.

The diagram shows a simplified and idealized provider network.  This provider has chosen to deploy IPv6-only services towards subscribers, but wants to provide an IPv4 service as well, so that  subscribers can reach both IPv6-only and IPv4-only services (and of course dual-stack services as well, on either stack).  IPv6 services have been built out to the subscriber edge.  The node at bottom left, for example, has the IPv6 address 2001:db8:5:4::a.

The subscriber has also built out the DNS infrastructure, and has included the DNS64 extensions.  In a nutshell (and there are RFCs on this whole process, so this is *very* terse), this is the DNS64 capability:

1) upon receiving a AAAA query from a downstream client, behave as a “regular” DNS caching server and query upstream towards the authoritative DNS server

2) if an IPv6 address is returned, behave as a “regular” DNS caching server and return query result to the client

3) if **NO IPv6 address returned** , use DNS64 extension, and perform the following process

3a) send an A query for the same name

3b) if no IPv4 address returned, behave as a “regular” DNS caching server and return “no such name”

3c) if IPv4 address returned, create *synthetic* IPv6 address using well-know prefix (64:ff9b::/96, as defined in RFC 6052) and embedding returned IPv4 address in low 32 bits of IPv6 address, and return to client as AAAA query answer

Going back to the example, make “Client-A” the client, and the IPv4-only node “Server-A” the server.   For DNS and DNS64 above, the recursive AAAA query would fail, and the DNS64-initiated A query would return 192.0.2.205.  DNS64 would create the synthetic IPv6 address 64:ff9b::192.0.2.205 (same as 64:ff9b::c000:2cd), and return that to Client-A.

At this point DNS64 has completed.  On to NAT64.

Client-A will launch the IPv6 session, convinced that Server-B is also an IPv6-capable node.  The IPv6 packets will be sourced by Client-A from its IPv6 address and destined for the synthetic IPv6 address manufactured by DNS64.  These packets will be routed within the IPv6 enclave (the network to the left in the diagram) to the NAT64 inside-facing interface (following the default route in this case).  The NAT64 function knows that if there is an IPv6 packet, sourced internally and arriving on the inside interface, where the destination is within the prefix 64:ff9b::/96, that this is a packet that will be translated.

The NAT64 platform will translate the packet into IPv4, making the source address the IPv4-Internet-facing address (192.0.2.15) and making the destination the 32-bit value “plucked” from the low 32-bits of the IPv6 destination address (the synthetic address) – 192.0.2.205.  The NAT64 device will also make a state entry for this session, using L4 port multiplexing, much like an IPv4 hide-NAT stateful device would use to track and manage sessions.

In this manner, many internal IPv6-only clients can access any IPv4-based server with an IPv4 address in the global DNS, all with no explicit manual configuration of sources and destinations.

And that’s it for DNS64/NAT64.

A few last quick points:

1) DNS64/NAT64 does have downsides; for one not all applications work well through the mechanism, and for another any content that uses IPv4 addresses rather than Fully Qualified Domain Names (FQDNs) (like an embedded link to a graphic within a webpage) will not work – translation depends on the DNS entry.

2) Note that IPv6 native traffic is simply routed at the enclave perimeter.  This means that, for Client-A, sessions to IPv4-only Internet-based servers is translated, which is probably an “acceptable, but not great” solution, and sessions to IPv6-only Internet-based services runs as native IPv6 end-to-end, providing an excellent solution.

3) Now that World IPv6 Launch Day has come and gone, and as more content providers make their content reachable over IPv6, less and less traffic in the example scenario will use the DNS64/NAT64 translation service and more traffic will be carried natively.

That’s it for this blog entry.  In the next installment of the NAT444 and DNS64/NAT64 story we’ll talk briefly about relative strengths and weaknesses of the two mechanisms and provide some practical deployment considerations.