What is 2002:836b:0F1E::836b:0F1E and why am I seeing it?

(NOTE: IP Addresses changed to protect the innocent)

I was onsite with a customer recently who asked me a question:

    “What is 2002:836b:0F1E::836b:0F1E and why am I seeing it?”

I explained that this is a 6to4 address and is automatically assigned to the client because they use a globally routable IPv4 range for their IPv4 address range. I pull up calc.exe and in a couple of moments ask if the IPv4 address of his system was After having a brief shocked look, his response was:

    “But wait, I’ve looked at KB 929852 and it says that I can disable IPv6 by unchecking the checkbox for IPv6 on the properties of the NIC. So why am I seeing an IPv6 address?”

“Of course,” I say, “but how close did you read 929852?” We pull up the KB and look at the start of the “More Information” section (included below):

      IPv6 can be disabled either through the DisabledComponents registry value or through the check box for the Internet Protocol Version 6 (TCP/IPv6) component in the list of items on the Networking tab for the properties of connections in the Network Connections folder. The following figure shows an example.

      The DisabledComponents registry key affects all interfaces on the host. However, the check box on the Networking tab affects only the specific interface. The DisabledComponents registry value does not affect the state of the check box. Therefore, even if the DisabledComponents registry key is set to disable IPv6, the check box in the Networking tab for each interface can still be checked. This is expected behavior.

There is one very fine point often overlooked in that second paragraph, it is the second sentence: “However, the check box on the Networking tab affects only the specific interface.” (emphasis mine) What is meant by “affects only the specific interface” is exactly what it says, it unbinds IPv6 from ONLY that particular interface, leaving IPv6 enabled within the IP stack. The result of this is that for systems with a non-Private IPv4 address, a 6to4 address will still be assigned to the system. It also means that other aspects of IPv6 are still enabled and running within the system.

So if your end goal of clearing the checkbox was to disable IPv6 across the entire system, you did not meet your goal. Don’t believe me? Run “netstat –ano” from an elevated command prompt and you’ll see your system listening to the unspecified IPv6 address (::). If you insist that you must disable IPv6, use the DisabledComponents registry key as defined in KB 929852. However, as the KB article says, “We (Microsoft) do not recommend disabling IPv6.”

After this discussion as to why he needed to use DisabledComponents instead of just clearing the checkbox, he asks me how I knew what his IP address was. I explained that the 6to4 address is of the format 2002:WWXX:YYZZ::WWXX:YYZZ where WW, XX, YY, ZZ are the hex representations of the octets of his IPv4 address. We looked back at calc.exe and changed it to “Programmer” under the View menu. This allows us to select Hex and enter 8b, clicking on the Decimal (Dec) radio button displays that the decimal value of 0x83 is 131. Repeating this, we determined that 0x6b is 107, 0F is 15, and 0x1E is 30. So would be 2002:836B:0F1E::836B:0F1E.

This got us back to the discussions about how they can prevent 6to4 Addresses from being generated on their systems. There are 4 methods which could be used to disable IPv6 on their systems: The DisabledComponents key with a value of 0x1, The DisabledComponents key with a value of 0xffffffff, Group Policy, or manually via use of the netsh command. We discussed the pros & cons of these methods. Setting DisabledComponents to 0x1 will disable all tunneling adapters (ISATAP, 6to4, Teredo, IP-HTTPS) on the system, but leave the system capable of leveraging Native IPv6 addressing once they begin deploying it within their infrastructure; setting DisabledComponents to a value of 0xffffffff will disable all of IPv6 on the systems (except for the loopback adapter), but will have to be changed to 0x1 or deleted when they begin an IPv6 deployment within their infrastructure; Group Policy allows for any of the tunneling adapters to be disabled independent of the others and provides the most flexibility for the future of their infrastructure; Utilizing netsh to disable 6to4 would be a manual process which would not easily scale across multiple systems and would be a manual process to re-enable in the future.

We setup a GPO so that they could begin testing the behavior of their systems with 6to4 being disabled via GPO. The setting we defined in the GPO was “6to4 State” with a value of “Disabled”. We then re-selected the IPv6 checkbox on the properties of the NIC on the system we targeted the GPO to. The setting was located under:

    Computer Configuration –> Policies –> Administrative Settings –> Network –> TCPIP Settings –> IPv6 Transition Technologies


As illustrated above, the state of the other Transition Technologies can also be controlled via GPO.

After this GPO applied to the computer, the computer was behaving as they had originally intended them to be behaving; there was no 6to4 Address present. Because we had replaced the IPv6 checkbox on the properties of the NIC, the system did have a Link Local Address (one which begins FE80::/64), but these are not routable addresses and do not register in DNS.

If you MUST insist on disabling portions or all of IPv6, consider either using Group Policy to disable the individual Transition Technologies which you wish to have disabled or leverage a value of 0x1 for the DisabledComponents key to disable all Transition Technologies. NOTE: Avoid deploying a value of 0x1 to mobile workstations if they will be leveraging DirectAccess as this will prevent them from having the ability to connect to the DirectAccess server as they would have leveraged these tunneling mechanisms for that connection; if it is only the 6to4 Addresses which are of a concern while on the corporate network, then disable only these adapters via GPO to these clients so that they can still leverage ISATAP, Teredo, and IP-HTTPS to connect to DirectAccess. If you MUST insist on disabling ALL of IPv6, then use 0xffffffff for DisabledComponents; the same caveat for mobile workstations attempting to leverage DirectAccess applies here as well.

The customer then asked me what can they do to prevent visiting computers which are on their network from being able to connect to DirectAccess servers from their own networks. We discussed how the connections to a DirectAccess server will connect to their own DirectAccess server via IPv6 and that they would require either a Native IPv6 address or a Transition Address to connect to their DirectAccess infrastructure. Since the customer’s network isn’t yet providing Native IPv6 addresses, they only have to worry about people leveraging Transition Technologies. Both ISATAP and 6to4 utilize IP Protocol 41 to encapsulate the IPv6 packets as payload of the IPv4 packets, so blocking outbound IP Protocol 41 at their network egress points will prevent ISATAP and 6to4 connections originating from their network. Teredo utilize UDP packets at port 3544, so blocking outbound UDP 3544 packets will block Teredo traffic from originating from their network. IP-HTTPS encapsulates the IPv6 packet as SSL encrypted payload of HTTPS packets (port 443), since their network allows for unfiltered outbound SSL traffic, IP-HTTPS connections could originate from their network. We discussed utilizing things such as either a separate VLAN for guests/vendors which doesn’t route to the corporate network and leveraging IPsec within their corporate network to provide domain isolation as some possible methods of protecting the internal network from unmanaged computers (but that sort of planning is another topic for another day).

Before I left, the customer asked me how they’ll be able to re-check the IPv6 checkbox on their systems once they’ve deployed a GPO with their desired settings for IPv6. This was one of those times when I did not have good news to give a customer. There is no programmatic way that I know of to directly determine the value of the checkbox and no programmatic way to toggle the value of the checkbox. They will be manually placing the checkbox back over time as they connect to systems and update their system images to no longer have the checkbox unchecked.

While I did include this link on one of my previous posts, I’m including it again because I’ve seen many questions asking about Microsoft products and their support for IPv6. Here is the link to the Common Engineering Criteria:

Comments (0)

Skip to main content