IPv6 is coming.  Like SDN, we can’t ignore it.  Are you ready?  Are you apps ready?  I’ll wager the answer is no.  Mine aren’t.  I’ve been working on IPv6 for about 11 years, from early days of tunnels to full native IPv6 at home and at work.  In teaching the IPv6 workshop for internet2, one of the things that I always suggest is to have a dual stacked host and an IPv6 only host available for testing.  These can be virtual machines or physical host, the important detail is that that need to be something that is deployed and a known working configuration. Ideally they’re a mirror or an analog of a typical workstation and or server on your network.
I’ve been doing this for some time, but I must admit I’m a little ashamed that I’ve never tried to do this for my personal day to day workstation, only for one off testing.  Well, that ends now, and the results aren’t pretty.

My every day workstation is a mac. So, to remain productive, I didn’t use my primary workstation, but instead I attempted to mirror it as closely as possible.  The chosen analog was a mac mini running MacOS 10.7.  It was immediately clear that this wasn’t going to be a fully functional workstation.
Right from the get go there was an issue.  IPv6 doesn’t do any options in the SLACC implementation that 90% of folks doing dual stack are going to use.  DHCPv6 is still not widely deployed, DHCPv6 relay isn’t available in a vast swath of network hardware and most folks are going to initially start with stateless auto config, at least until they realize it’s more or less unmanageable.  Translated: you have no DNS without explicitly setting it statically.
Yuck.  I strongly discourage statically assigning things.  It makes changes far more painful than they need to be, is a support nightmare at nearly any scale  and decentralizes control. However, I had to for this test.  Fine, an IPv6 resolver was added.
Next step, run patching.  Nope.  Apple doesn’t support patching via their automated process via IPv6.  Most of this should be served by Akamai, which does support v6 in many cases, but not this one.  I can’t even patch the workstation without either running my own IPv6 enabled patch service (which requires manual configuration of a host to utilize), using a thumb drive or IPv6 enabled network mapping to grab the patches or plumbing IPv4 into it.
After fighting through patching the host, I wanted to actually use it.  This was mostly an exercise in patience as well.  The google based services I used all just worked.  Searches, gmail, blogger, etc.  I didn’t notice any difference whatsoever. One interesting thing that I noticed right away was that many ads and images on pages I was able to surf to weren’t working at all.  Ad content providers are behind the curve on delivering over IPv6.  This surprised me a bit since this is a revenue stream that is going to grow, and they’re missing the boat.  The upside was that I didn’t need to look at a bunch of ads, potentially distracting images and marketing hype.
Many of my work services such as exchange aren’t yet IPv6 enabled, I knew that wasn’t going to work because it’s actually on my teams list to remedy, however, I gave it a try anyway.  No go on OWA.  No go on any of the exchange access whatsoever.  NTP sync worked just fine after adding in our NTP server, its been IPv6 ready for a very long time.
Luckily for me, most of what I do is CLI based and the equipment I need to get into and help maintain has been IPv6 enabled for years.  SSH on this mac worked with absolutely no issues, as expected.  It’s one of those nice things that I’d been using IPv6 for in a dual stacked environment for years and is essentially transparent.
I was able to work on this blog post, since forwardingplane.net has been IPv6 compliant since it’s inception thanks to the hosting provider, arp networks.
Other services that I use regularly, are a mixed bag.  Box.net has no IPv6 support. Dropbox, which I expected to work since it is hosted in the amazon cloud, doesn’t but probably trivially could.  Spideroak didn’t work with only IPv6.  Crashplan didn’t work to the cloud or my NAS.  NAS was expected since it doesn’t do v6.  This is a frightening wake-up call.  Enabling IPv6 support into these every day apps should have been done from the beginning or at the very least before IPv6 day.
Some other things I noticed, my 2 NAS at home don’t do IPv6 at all.  The aging Dell powerconnect gig switch I have at home doesn’t do IPv6.  My Sonicwall TZ 210 wireless-N that I’ve been testing at home has no IPv6 support by default although I think there is Beta code that I’ve been trying to get my hands on.
My appleTV, however, does do IPv6 as do my Linux VMs, Windows 7 VM and host Linux system.  My normal gateway device, a pfSense install running on a PC Engines ALIX board has done IPv6, correctly mind you, for years, either by code I hacked into it (in the early days) or fully supported by the project.  It supports dhcpv6 server, dhcpv6-pd from my upstream provider and SLAAC.  It also does IPv6 firewall functions better than most commercial firewall devices.
I’m 100% sure it’s just the tip of the iceberg. If you’re a networking professional and you’re not learning IPv6, you’re already 10 years behind.  Head in the sand won’t make it go away, it’s happening, just like SDN is happening.  In fact, they’ll be happening together in some cases.  Learning new things is fun, and IPv6 is a necessity.  You can hide behind NAT and existing allocations for a while, but believe me, you’re doing yourself a disservice as well as missing out on some cool stuff if you’re not talking about your IPv6 plans and learning about this inevitable reality.