Thursday, July 21, 2011

June 2011 Microsoft Springboard Series Insider Article - What You Should Know About IPv6

I was recently published in the June 2011 issue of Microsoft's Springboard Series Insider newsletter. The newsletter goes out to 1M plus IT Pros. Unfortunately it is NOT published to the web at all so I am providing the content of the article in case others are interested in reading it.

What You Should Know About IPv6
Recently in the news you might have been reading more about IPv6, both in IT publications but even in mainstream news outlets. There have been some significant events over the last 6 months that are worthy of a quick mention to have an understanding of why IPv6 right now should be of interest to you.
On February 3rd, 2011, the IANA announced they had allocated all public IPv4 address blocks available out to all the 5 regional registries around the globe, which are AfriNIC (Africa), APNIC (Asia/Pacific), ARIN (North America), LACNIC (Latin America and some Caribbean Islands) & RIPE (Europe, Middle East and Central Asia.) These 5 regional registries allocate IPv4 and IPv6 addresses to local service providers and others who request IP address space within their respective areas. Because each regional registry has a different run rate of requests for IPv4 addresses, each region has a different predicted depletion date. See the sidebar for more about the predicted timelines. Effectively what this means is that we have emptied out the pool of IPv4 addresses that fills the bucket of the regional registries which then provide IP addresses to all of us.
In April, APNIC (the regional registry that handles Asia/Pacific) ran low enough on IPv4 addresses that they can no longer hand out larger public IPv4 address blocks and are only handing out much smaller IPv4 address blocks per very strict guidelines. APNIC will likely be the first regional registry to completely run out of IPv4 address blocks to hand out. RIPE, the registry for Europe, is not much further behind and for many ISPs and larger hosting providers it will be difficult if not almost impossible to get larger IPv4 address blocks by the end of 2011. In fact, the current aggressive projections is that RIPE will run out of addressing by September of 2011.
So what impact does this have on IT Pros that run and maintain services on the Internet today? What about services like VPN, OWA, SharePoint, Exchange, DNS and others? Likely in the immediate short term, not a lot. That being said, it will become more and more common that you encounter hosts that may only have IPv6 connectivity due to the lack of IPv4 addresses in certain parts of the world. If your services do not have IPv6 translation services or native IPv6 available then you will be unable to communicate with those hosts. Remember that IPv4 and IPv6 are incompatible protocols that cannot communicate without a protocol translator of some kind. Initially this may not be a large concern for smaller enterprises and small business. However, for larger international enterprises and government entities this concern is very real. How do you handle a situation where an executive traveling in Asia or Europe using a local ISP only has IPv6 addressing and is unable to connect to any of the corporate resources? Do you have a plan to address this inevitable situation?
Microsoft has enabled IPv6 by default in their recent OS platforms and actually has a long history of working on and supporting IPv6. Specifically Windows 7 and Windows Server 2008 R2 are IPv6 Ready Logo certified and work well in native IPv6 environments along with dual stack environments. (Dual stack refers to the situation where both IPv4 and IPv6 are available on the same Layer 2 network, wired or wireless, and the host gets both types of addresses.) Joseph Davies, author of Understanding IPv6, Second Edition by Microsoft Press has produced many articles on IPv6 and I highly recommend reading them as the starting point of learning IPv6 in a Microsoft Enterprise and Home network.
Given the difficulty of having IPv6 hosts trying to reach IPv4 resources, clearly Microsoft would have thought of some sort of transition services to allow IPv6 traffic on an IPv4 network and you are correct in assuming they put those into the OS. Windows 7 and Server 2008 R2 have the following transition services built into the OS.
  • 6to4 - tunnels IPv6 traffic over IPv4 without having to build an explicit tunnel, uses public relays to get to the IPv6 Internet, and requires the host to have a public IPv4 address to auto-generate it's IPv6 addresses based off that public IPv4 address.
  • ISATAP - allows dual stack nodes to tunnel on top of IPv4 utilizing an ISATAP router for auto-configuration and forwarding, doesn't require multicast, and is typically used in enterprises to build an overlay IPv6 network on an existing IPv4 one to get around gaps in native IPv6 routing.
  • Teredo - same function as 6to4 but works behind an IPv4 NAT (able to do NAT traversal); to route to the IPv6 Internet, a Teredo relay has to be functional.
Each of the above transition services is a tool for an IT pro to design a solution to meet their requirements for migrating and supporting IPv6. Unfortunately, you need to understand when these transition services are on by default and when they are not. This is critical in Enterprise networks where compliance and auditing of existing IPv4 traffic may be in place but a lack of understanding of when IPv6 is or is not functional on the platform may cause additional behavior that was not anticipated. Remember, with Windows 7 and Windows Server 2008 R2, IPv6 is enabled by default and the OS will prefer to use IPv6 if it is available. When IPv6 hosts are Layer 2 adjacent to each other, hosts will auto-assign IPv6 addresses (link-local addressing) and also auto discover and do name resolution with adjacent hosts in IPv6. This can cause some interesting behavior for IT Operations when they are watching reported stats back on logical Layer 3 IPv4 addresses and suddenly the hosts begin passing all their traffic across the logical Layer 3 IPv6 address instead! The graph for the IPv4 address goes to almost zero and if you are not graphing the IPv6 address, you might wonder (in an alarmed state!) where the heck all your traffic went.
Here is a quick example of IPv6 transition services being on by default and following best practices for a deployment, but might not result in the most desirable outcome. If you are deploying Exchange 2010 and you set up Edge Transport role servers per their recommendations in a DMZ with Windows Server 2008 R2-based computers that are not domain joined and happen to use public IPv4 addresses in your DMZ, you might want to check your servers to see if they are doing 6to4 automatically. If you did not turn off 6to4 explicitly and the server has a public IPv4 address, the server is likely sending out some traffic via it's 6to4 interface if it is getting AAAA records back via DNS which would specify an IPv6 address as the best way to reach a host. You might see similar behavior with Teredo if the server has a private IPv4 address.
You can check the status of your IPv6 interfaces using the following netsh commands:
netsh interface ipv6 show interface
netsh interface ipv6 show address
netsh interface ipv6 show route
You can turn off 6to4, ISATAP and Teredo with the following netsh commands:
netsh interface ipv6 6to4 set state state=disabled
netsh interface ipv6 set teredo disable
netsh interface ipv6 isatap set state state=disabled
The takeaway is that you can't ignore IPv6. You should proactively design and deploy solutions and transition technologies within your environment but understand what their purpose is and if you are running them. You will have to support IPv6 and your OS platforms (all the major OS platforms use IPv6 first and "fallback" to IPv4) are already making use of IPv6, so simply ignoring that the protocol is running on your network is folly. Importantly, do NOT turn off IPv6 - you might actually break something that is working just fine in your network today! Additionally, if you have a separate network team that is planning on deploying IPv6, if you turn off IPv6 you are actively blocking the ability of that team to provide you those new services. The key is to be aware and KNOW what you are running in your environment.
So, what are the 10 steps I should take as an IT pro to get IPv6 deployed in a Microsoft enterprise network?
  1. Acquire Provider Independent IPv6 address space through a regional registry.
  2. Do native IPv6 peering or use a tunnel service to get your address space routable.
  3. Get an external firewall and external routing working.
  4. Test public IPv6 with external DNS, mail and perhaps a test web server.
  5. Evaluate transition services as needed - perhaps you have a case for using ISATAP.
  6. Test your applications in a lab - do NOT make your corporate or production users guinea pigs! Additionally Microsoft has an IPv6 Test Lab available for Windows 7 and Windows Server 2008 R2.
  7. Get internal IPv6 routing, DNS & DHCP working (phases are possible).
  8. Dual stack your servers.
  9. Provide dual stack to your workstation virtual local area networks (VLANS).
  10. Deploy a VPN dual-stacked solution.
A more detailed presentation can be found on my blog or on the California IPv6 Task Force website and yes, you can reach both of those sites via IPv6!
If you are able to get at least the first 3 items done, you can participate in World IPv6 Day on June 8th, 2011. All the major content providers on the Internet plan to make their services available via IPv6 on that day including Facebook, Google, Yahoo!, Bing, Xbox, and tons of others. You can find the current list at the ISOC website which also has information on how to take part in the event.
If you don't have time to get Provider Independent IPv6 space but you would like to get something up quickly to test with on June 8th, I would recommend several tunnel broker services that you can get up and working within minutes. If you have a router or server that can do a 6in4 tunnel, check out IPv6 Tunnel Broker, which is run and maintained by Hurricane Electric, a premier IPv6 provider. Additionally, if you already have a BGP ASN you can peer with them directly via a tunnel and if you have Provider Independent IPv6 space, advertise it that way to get it working ASAP. You can also try out the gogoCLIENT, which makes use of the Freenet6 project and has clients for Windows 7 (32 and 64-bit), Linux and OSX. Other projects like SixXS are available to do IPv6 tunnel services too.
Finally, Microsoft has ongoing articles on TechNet on all sorts of IPv6 topics. For instance, Chris Palmer wrote a blog entry on World IPv6 Day and Windows and Microsoft keeps an ongoing IPv6 Blog along with its main IPv6 site at, which contains links and resources about IPv6. To top it all off, there are regional task forces across the world that are helping to spread the word locally about IPv6. You can find out more about them on the IPv6 Forum. Finally, make sure to check out Bing on June 8th via your IPv6 connection!

Ed Horley is a Principal Solutions Architect at Groupware Technology in the San Francisco Bay Area. Ed is actively involved in IPv6 serving as the co-chair of the California IPv6 Task Force and additionally helping with the North American IPv6 Task Force. He is a current Microsoft MVP (first awarded back in 2004) and has spent the last 15 years working in networking as an IT professional. He is actively involved in the Pacific IT Professionals users group and enjoys umpiring women's lacrosse when he isn't playing around on IPv6 networks. Contact him at or check out his blog at
- Ed

No comments: