Connecting with IPv6 in Windows 8

With World IPv6 Launch upon us, we thought it would be good to provide a look at the work in the Windows 8 Release Preview supporting IPv6. Christopher Palmer on the core networking program management team authored this post.
--Steven


IPv4 is the Internet Protocol that has been used for Internet connectivity for decades. However, IPv4 was never designed for such load and scale, and it is beginning to show signs of strain as the Internet grows—even though the incredible foresight of the original designers continues to power the Internet at a massive scale. Internet service providers are finding IPv4 increasingly costly to maintain; it will require an overhaul to sustain the upcoming onslaught of connected PCs and devices.
For several years, the industry, including Microsoft, has been working to roll out a completely new version of the Internet Protocol – IPv6 – across various devices, services, and network infrastructure. Windows releases since Windows XP SP3 have supported IPv6, making the IPv6 transition possible. We have engineered Windows 8 to keep you (and your apps) reliably connected as this dramatic transition takes place.
[h=3]The limitations of IPv4[/h] First, let’s cover some basics. Every time you browse to a website like www.bing.com, that friendly name gets turned into an IP address, something like 23.3.105.97. An IP address is conceptually similar to a telephone number. Just as all your contacts have telephone numbers, everything that connects to the Internet has one or more IP addresses. The “telephone directory” for the Internet is the Domain Name System (DNS). Given a name, DNS resolves the name to a set of IP addresses.
IPv4 only provided around 4 billion IP addresses. That seemed like a lot in the 1970s. But by 2015, an estimated 15 billion devices will be connected (PCs, phones, household appliances, cars, even furniture!). IPv4 simply does not have the addresses necessary to connect this many devices to the Internet.
As demand for IPv4 addresses has grown in recent years, the Internet community has found ways to “share” those vital resources. The most common way to share an IPv4 address is to use network address translation (NAT). This functionality is in most home routers, enabling computers and other devices in a household to share a single public IPv4 address.
Conventionally, ISPs provide a single IP address to each home. However, that is becoming increasingly difficult. Because of IP address depletion, unique IPv4 addresses simply aren’t available for each home. Soon, whole cities or countries may be behind large-scale network address translation. Internet service providers have to develop costly and complex infrastructure to continue to support IPv4. For end users, IP address exhaustion means that location-based services, such as Bing, will not work properly, and peer-to-peer applications will face degraded performance.
[h=3]IPv6 is the future[/h] Microsoft, along with other technology companies, has been working on the deployment of IPv6 to ensure that end-users continue to have high-quality Internet access, despite the performance and connectivity limitations brought about by IPv4 address exhaustion.
The most immediate benefit of IPv6 is that it provides more than 3×10[SUP]38 [/SUP]IP addresses, enough for every person to have billions of addresses all to themselves, or enough to give every atom in the universe a unique address. This will allow the Internet to grow and evolve. IPv6 also provides for many security and performance improvements, like built-in support for IPsec. (What happened to IPv5, you ask? Bing can help you find out why it’s being “skipped.”)
Upgrading the entire Internet to IPv6 isn’t something that can be done instantly. It has taken many years to get to where we are today, and we still have many years of work to do. Currently, around 1% of devices can connect to the Internet using only IPv6.
During the transition period, most networks will fall into three categories:

  • IPv4-only networks. This is probably what you have today, as most Internet Service Providers have only just started rolling out IPv6 support. Many devices that connect to the Internet might only support IPv4 as well.
  • IPv4 and IPv6 networks (dual-stack). This means your Internet Service Provider is configuring your PC with both IPv4 and IPv6 addresses. This model is common in cable and dial-up networks that are transitioning.
  • IPv6-only networks. This means your Internet Service Provider is configuring your device with only IPv6 addresses. Because many websites are still only on the IPv4 Internet, ISPs must use a translation device to allow access from your IPv6 network to the IPv4 Internet. This device is called a NAT64. This mode is becoming popular in the mobile environment, because having only one kind of Internet Protocol between the mobile device and the operator’s infrastructure is simpler to deploy and cheaper than a dual-stack configuration. Also, mobile operators are feeling the IPv4 address exhaustion pinch most severely. Here is a basic diagram of this configuration:
4645.ipv6_2D00_only_2D00_networks_5F00_696A56BE.png
You might be wondering what kind of connection you have right now. We have a widget at the bottom of this post that can show you.
2654.Address_2D00_sorting_2D00_in_2D00_Windows_5F00_5CD481A4.png

   Traditionally, address sorting relies on Windows being correctly configured by your router. Windows analyzes the routing information provided by the router and uses that information in conjunction with address sorting to ensure fast connectivity to named resources. The RFC 3484 standard specifies that IPv6 should be preferred if IPv6 is configured by your router.
World IPv6 Day showed that some clients were configured with IPv6 routing information, but they did not actually have IPv6 connectivity to the Internet. This appears to be the result of a misconfiguration by some Internet Service Providers or buggy home routers. Windows attempts to connect to websites using IPv6, expecting it to work, but it won’t! Eventually, Windows detects that the connection attempt failed and falls back to IPv4 connectivity. However, for users, connectivity to dual-stack websites can be delayed by 10-15 seconds. This obviously causes a problem for web browsers, but any network-connected app faces this issue.
As we looked into engineering a solution to this problem, we had to consider a couple of important issues. First, many enterprises deploy complex routing topologies. We had to make sure that our change did not break connectivity in these environments. Second, we needed a solution that worked not only for Internet Explorer but also all the other apps that are relying on Windows to help them connect to network resources. Those apps rely on us to remain intelligently connected throughout the IPv6 transition. Our solution needed to address the needs of existing desktop apps as well as new Metro-style apps.
Windows 8 tests IPv6 connectivity when you connect to a new network that advertises IPv6 routabilty, and it will only use IPv6 if IPv6 connectivity is actually functioning. This approach is a modification of our implementation of RFC 3484. Instead of sorting addresses as a result of policy, we use the actual state of the network as input to our algorithm. On a misconfigured network, this approach improves the experience not only for browsers but also for apps that connect to dual-stack destinations using standard Windows APIs.
Windows 8 performs the network connectivity test when you first connect to a new network; it caches this information and repeats the test every 30 days. The actual test for connectivity is a simple HTTP GET to an IPv6-only server that is hosted by Microsoft. (For standards buffs, this is implemented between rules 5 and 6 of destination address sorting in our implementation of RFC 3484.) Windows performs a similar network connectivity test for IPv4 connectivity. If both IPv4 and IPv6 are functioning, IPv6 will be preferred.
To make sure that Windows 8 does not cause problems on enterprise networks, the functionality has two safeguards:

  • If the enterprise has provided specific routing information to a particular destination, then Windows 8 will honor that preference, regardless of the connectivity determined by Windows. In enterprise environments, Windows assumes that network administrators who configure such routes specifically thought it was a good idea to use those routes.
  • This change isn’t implemented on networks with web proxies. In these networks, the proxy provides connectivity to the Internet; so end-to-end testing of IPv6 connectivity is not useful. Instead, Windows 8 simply opens connections to the proxy in the most efficient manner possible.
In this way, we’ve ensured that apps and experiences on Windows 8 can remain reliably and speedily connected to the Internet throughout the IPv6 transition, even if your local network is misconfigured.
[h=3]Ready for the future of IPv6-only networks[/h] On an IPv6-only network, the best way to improve a user’s experience is to increase the number of services and experiences that are available over IPv6. On such a network, access to the IPv4 Internet is through a NAT64. These devices can be a fragile point of failure for connectivity, and can have severe performance limitations that lead to dropped packets. They also break IPv4 peer-to-peer connectivity, needed for some multiplayer games.
Across Microsoft, we have done a lot of work to enable the growth of IPv6 deployments, both in enterprise and Internet settings. One of our most important efforts is to ensure that our server products support IPv6. IPv6 support is part of our Common Engineering Criteria (CEC). This is part of a broad company-wide commitment to customers that our business products, such as Exchange Server and SharePoint, support IPv6 in either dual-stack or IPv6-only configurations. Most Microsoft products built since 2007 have supported IPv6, but you can find out about IPv6 support in other Microsoft products on Technet. Through this effort, developers and solution providers can support IPv6 in their own products.
Microsoft is also working on IPv6 support for our own services. Earlier this year, the Internet Society announced the World IPv6 Launch, a major milestone in the process of upgrading the Internet to IPv6. In June, Bing and other websites will start serving traffic over IPv6 on a permanent basis. Hardware vendors are working on IPv6 support in home routing devices, and many ISPs will start large-scale deployments of IPv6. CDNs (content delivery networks) have also started enabling support for IPv6 within their networks.
With the release of Windows 8, some of our infrastructure services will deploy IPv6 support.
Windows Update is a critical service providing ongoing support and updates to millions of users every day. More and more PCs are going to be connected to mobile broadband networks, where IPv6-only is a popular configuration. We have to make sure that downloads are reliably available to you on those networks.
For this reason the Windows Update service now supports both IPv6 and IPv4. Windows Update utilizes CDNs for worldwide distribution of updates and we are partnering with them to enable IPv6 support. Windows 8 will use IPv6, if available, to download Windows Updates so that users always get the best possible connectivity when downloading updates.
We are working with CDNs to extend IPv6 support beyond Windows 8. Once that work is complete, even Windows 7 and Windows Vista will automatically use IPv6, where it is available, for connecting to Windows Update.
[h=3]Leading the way[/h] Windows 8 is connected and ready to use, and our support of IPv6 is a key part of ensuring that connectivity for years to come. Because IPv4 wasn’t designed to handle the scale of connectivity today, the Internet is undergoing a radical change in its foundation. Every connection to every website, every multiplayer game, and every video call will gradually move to IPv6.
As part of that transition, Microsoft is leading the way by ensuring that Windows 8 provides the most resilient connectivity to the Internet while providing IPv6-ready products and services.
- Chris
aggbug.aspx

More...
 
Back
Top