IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Hello, this is Venkat Kalyanasundaram, Senior PFE from New York Metro area.
As someone that works a lot with IPv6 I see the same set of questions come up over and over again. I want to take some time to address some of the more common ones and really try to remove the mystery of IPv6. This will be one of a series of posts so check back often for more IPv6 goodness.
The first question I want to address is an extremely common one. How does the name resolution process work in dual stack scenario with Windows? In specific, we would like to know the impact to our network environment when IPv6 is enabled in Windows?
Well let’s just get this out of the way. As we’ve said before we do not recommend disabling IPv6 in Windows (http://technet.microsoft.com/en-US/network/cc987595.aspx, Review the FAQ “What are Microsoft recommendations about disabling IPv6” for more specifics.)
The key here is to get some basic understanding on how the name resolution process works in Windows when both IPv4 and IPv6 are enabled.
In the IPv4 world, we are used to managing the name resolution process using Microsoft WINS and DNS. In IPv6 world, WINS has no relevance. In other words, IPv6 addresses do not get registered in WINS and they need to be managed completely via DNS. IPv6 address is represented as an AAAA (Quad A) record in DNS similar to how we represent IPv4 address as Host A record. The concept of PTR record (for reverse name resolution) also applies to IPv6 addresses in DNS.
With IPv4, normally we are used to just one IP address getting registered in DNS for a given machine. With IPv6 we have to deal with different types of addresses (Link local, Global etc as discussed earlier by Mark and Ray in their blog. http://blogs.technet.com/b/askpfeplat/archive/2013/06/24/ipv6-for-the-windows-administrator-ipv6-fundamentals.aspx). Note all types of IPv6 addresses are not registered in DNS. For example, Link local address starting with FE80: (active only with in its local subnet and not a routable address) do not get registered in DNS. Global address get registered in DNS as Quad A record. When dealing with Transition technologies, Teredo addresses do not get registered in DNS. The Microsoft Technet article DNS Client behavior explains this behavior in detail.
Let us review few real life scenarios where the existing Corp network is pretty much 100% running in IPv4 and you are trying to bring up new Windows machines with dual stack enabled. We will try to find out how these new Windows machines communicate on the existing network.
As you can see from the above diagram, we have two machines (say Windows 7 client and Appserver1 running with Windows 2008/R2) located in two different subnets running with both IPv4 and IPv6 enabled (Dual stack). When you enable IPv6, the Link Local address (starting with FE80: that you can verify with IPCONFIG output) will be configured automatically in Windows. We will not go into the detail now on how the Link Local Address get generated automatically based on certain parameters. That is a separate topic for another day. Assume we have not configured any other global IPv6 address or addresses from transitional technologies for IPv6.
Appserver1 registers its IPv4 address in DNS. The Link Local Address from IPv6 do not get registered in DNS since it is a not routable address and confined to the local subnet. In other words, we have only one host A record pointing to 10.1.0.2 for Appserver1 name in DNS even though we had enabled IPv6 in the Server.
Say Windows 7 client needs to communicate to Appserver1, let us see how things work in the background from network and name resolution perspective. Initially the client sends a request to DNS server for resolving the name “Appserver1.Contoso.com”. DNS responds with A record pointing to 10.1.0.2 for Appserver1. Now the client communicates to Appserver1 by sending the request to 10.1.0.2 address. As you can clearly see, the communication still happened via IPv4 even though we had enabled both IPv4 and IPv6 in both client and Server. There is no impact to the network from performance perspective. Assume the client or Server is configured only with IPv4 address (no IPv6 address) we will be encountering the same behavior as explained above.
Let us extend the scenario #1 further. Say the Client now is configured with dual stack (IPv4 address and Link local IPv6 address as in scenario # 1) and Server is configured with IPv4 address and a global IPv6 address.
In this scenario, the Appserver1 will register A record (for IPv4 address 10.1.0.2) and AAAA record (for the global IPv6 address) in DNS. Link local address is also generated in this case in AppServer1 which do not get registered in DNS.
What will happen when the Win7 client wants to communicate to Appserver1 in this scenario? The client sends a request to DNS Server only for the A record to resolve the name Appserver1. The client never tries to query for AAAA record (even though DNS has AAAA record for Appserver1) since it knows it is configured with link local address only which is not a routable address. DNS responds back with IPv4 address. Now the client communicates via IPv4 similar to scenario #1.
Assume we configure global Ipv6 address in both client and Server in this scenario. Assume your network team is configuring the routers also for proper routing with IPv6 addresses. This means you are taking explicit actions to configure global IPv6 address in your network either manually or from DHCP server or from the Router. (yes, you can configure IPv6 address directly from the router. Covered here briefly http://blogs.technet.com/b/askpfeplat/archive/2013/07/08/ipv6-for-the-windows-administrator-more-ipv6-subnetting-zones-address-autoconfiguration-router-advertisements-and-ipv4-comparisons.aspx )
In this scenario both client and Server registers A record (IPv4 address) and AAAA record (Global IPv6 address) in DNS. When the Win7 client tries to communicate to Appserver1 in this scenario, it communicates to DNS for resolving the name Appserver1. DNS responds back with A (pointing to IPv4 address) and AAAA values (pointing to global IPv6 address) for Appserver1. The client communicates to the server via IPv6 in this case. With both A and AAAA records resolvable, the default behavior in Windows is to try communicating via IPv6.
As you can see from above scenarios, the scenario #3 is the only one where the client and server communicate via IPv6.In this scenario explicit actions are taken by Windows and Network administrators to configure global IPv6 address in Windows machines and routers. If you do not take any explicit actions and end up enabling both IPv4 and IPv6 in Windows machines with default settings, the impact is very minimal as you can see from scenario #1 and scenario #2.
As you have noticed in the above scenarios, we had used IPv4 addresses which are in private range. If your network is using public range IPv4 addresses (ranges other than 10.x.y.z, 172.16.x.y, 192.168.x.y) there are few more things that we need to be aware. I will cover this scenario in my next blog post.
11-25-13 Spanish version of this post http://blogs.technet.com/b/ask-pfe-latam-plat/archive/2013/11/15/ipv6-para-el-administrador-de-windows-como-funciona-la-resoluci-243-n-de-nombres-en-un-escenario-dual-ipv4-ipv6.aspx -MarkMoro