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 back with another IPv6 post for everyone.
We discussed in my previous post IPv6 for the Windows Administrator: How Name Resolution Works in a Dual IPv4/IPv6 Scenario and talked about the behavior when using a private IP address range. Today we will discuss a special scenario when you have public ranges of IPv4 addressing deployed in your internal network. Let us get started.
The following three blocks of addresses in IPv4 world are treated as private range addresses. In short, these addresses cannot be used for globally routed Internet traffic and can be deployed within corporate network for Intranet traffic. If you have the patience and time to read RFCs, you can get more details on this topic from http://www.faqs.org/rfcs/rfc1918.html.
10.0.0.0 – 10.255.255.255 (10/8 prefix)
172.16.0.0 – 172.31.255.255 (172.16/12 prefix)
192.168.0.0 – 192.168.255.255 (192.168/16 prefix)
If you had deployed your IPv4 addressing range other than one of the above three blocks of addresses, then probably you would have deployed one of the public facing range of addresses. While it is not common to deploy public range of IPv4 addresses in your internal network, people may still do it for various reasons. Technically there is nothing that may prevent you to deploy public range of IPv4 addresses in your internal network.
If you are one of the people who had deployed public range of IPv4 addresses in your internal network, you’ll want to pay attention below.
Dual Stack Default Behavior and 6to4 Tunneling Addresses
Windows machines (dual stack enabled with IPv4 and IPv6) that are configured with public range IPv4 address (131.107.x.y for example) in your network will have a default behavior to generate 6to4 tunneling address.
If you are wondering what is 6to4 tunneling address, then you need to understand the concept of transition technologies with IPv6. On a high level, this is what they mean – You are basically tunneling an IPv6 packet inside IPv4 frame in an IPv4 only network. There are different types of tunneling mechanism available (ISATAP,6to4 and Teredo) depending on the type of IPv4 networks involved. If you are interested in learning more about the tunneling technologies in IPv6, you can get information from this Technet link http://technet.microsoft.com/en-us/library/bb726951.aspx
Let us review this with an example. A Windows machine is configured from a public range IPv4 address 18.104.22.168 as shown in the above IPCONFIG output. Assume IPv6 is also enabled and there is no global IPv6 address explicitly configured in this machine. The default behavior in Windows is to generate 6to4 tunnel address and in this case is configured in the 6to4 Adapter section of IPCONFIG output.
The 6to4 tunnel address always starts with a 2002. The remaining digits 836b:1714 are generated based out of the IPv4 address that is configured on the machine and it gets repeated in the interface ID portion also. It is basically hex representation of IPv4 address values. If you convert the decimal digit 131 to a hex value, it is 83, 107 becomes 6B in hex and so on. As I mentioned earlier, if you want to know more about how the tunneling technologies work, review the white paper in technet link http://technet.microsoft.com/en-us/library/bb726951.aspx
Real World Impact and Active Directory
With the automatic generation of 6to4 tunnel address, let us now see the impact it creates further. A 6to4 address is treated as a normal IPv6 address and it gets registered in DNS as AAAA record with dynamic updates enabled at DNS level. With both AAAA and A record resolvable between two Windows machines, the default behavior in Windows is try communicating via IPv6. (As per the name resolution behavior that we discussed in previous blog and explained in the above diagram). Things still work because 6to4 address gets tunneled inside IPv4 packet and transmitted as IPv4 traffic by intermediate network devices like routers etc.
Most of the people do not even realize the above behavior is occurring in their network when they use public range IPv4 in Windows machines. They are surprised to see AAAA records in DNS as displayed in the above picture showing AAAA and A records for the machine with 6to4 enabled. They also tend to forget to define equivalent IPv6 subnet/site association in Active Directory (Refer the picture below for AD Sites and Services MMC)
So the real impact here – You start getting into performance issues at the Active Directory level because Windows clients are trying to communicate via IPv6 (6to4 tunnel address) and we do not have any IPv6 subnet/sites defined in Active Directory. So you could end up in scenarios like – Windows client is trying to authenticate with a Domain controller in remote site (even though there is a DC available in the local site) or any services like DFS or Applications that relies on AD site costing may encounter performance issues.
The next logical question becomes how I can disable the automatic generation of 6to4 tunnel address in the above case that we discussed with an example.
Disabling 6 to 4 the Proper Way
You can use Windows group policy to disable 6to4 tunnel adapter as displayed in the below picture. By disabling via group policy, you still keep IPv6 stack enabled except 6to4 address will not be generated. Next best option is to use “Disabledcomponents” registry key as mentioned in the KB http://support.microsoft.com/kb/929852
Just a final point to note, you do not have to worry about this if you had deployed private ranges of IPv4 addresses in your network.
11-25-13 Spanish version of this post http://blogs.technet.com/b/ask-pfe-latam-plat/archive/2013/11/22/ipv6-para-el-administrador-de-windows-la-direccion-2002-tunel-6to4-y-su-impacto.aspx -MarkMoro