Stop disabling IPv6

You might have gotten here from reading documents such as the Information Security Manual (ISM), which states things like the following:

Internet Protocol version 6 (IPv6) functionality can introduce additional security risks to a network. As such, disabling IPv6 functionality until it is intended to be used will minimise the attack surface of the network and ensure that any IPv6 functionality that is not intended to be used cannot be exploited.

It then goes to list some of the things one should do, such as disabling ipv6:

Security Control: 0521; Revision: 5; Updated: Sep-18; Applicability: O, P, S, TS IPv6 functionality is disabled in dual-stack network devices and ICT equipment unless it is being used.

Security Control: 1429; Revision: 2; Updated: Jan-20; Applicability: O, P, S, TS IPv6 tunnelling is blocked by network security devices at externally-connected network boundaries.

Reading the PDF Edition, it labels these as musts - i.e. disable it.

Someone more familiar with the ISM would argue that the difference between a should and a must is only a different level of approval to not do it, howver that is not the subject of this post.

There’s already been a bunch of writeups on this topic, and what can go wrong, notably:

• Disabling IPv6 And Exchange – Going All The Way
  • Unless there are specific reasons for disabling IPv6 please do not do it., says the sysadmin who had to diagnose Microsoft Exchange issues

Microsofts official stance on the topic is as follows:

From Microsoft's perspective, IPv6 is a mandatory part of the Windows operating system and it is enabled and included in standard Windows service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, Microsoft does not perform any testing to determine the effects of disabling IPv6. If IPv6 is disabled on Windows Vista, Windows Server 2008, or later versions, some components will not function. Moreover, applications that you might not think are using IPv6—such as Remote Assistance, HomeGroup, DirectAccess, and Windows Mail—could be.

Although an outdated reference to DirectAccess and being written in 2016, it’s unclear if their policy has changed, or if disabling the setting now means your organisation can no longer recieve support.

This has recently been revised in August 2020, stating in this very large, very colourful box:

Unfortunately, this is also propogated by penetration testers as a mitigation to someone using mitm6, such as the authors of the tooling:

The only defense against this attack that we are currently aware of is disabling IPv6 if it is not used on your internal network. This will stop Windows clients querying for a DHCPv6 server and make it impossible to take over the DNS server with the above described method.

Not that they are the only penetration testers recommending disabling ipv6.

Root cause

The bigger, unaddressed root causes here are as follows:

• Layer 2 has traditionally been overtrusted
• Window’s link-local ideas of discovery were a bad idea (NETBIOS, LLMNR)
• WPAD was a bad idea
• Protocols with bad cryptographic implementations are not good to use (i.e. NTLMv1 being effectively DES + md4)
• Protocols designed without encryption were a bad idea, especially when used for authentication (i.e. LDAP not LDAPs)

The Jericho Forum had published a paper on the need for inherantly secure protocols back in 2006, in an attempt to work around terrible network decisions such as making a perimeter network, instead of just treating everything around you as hostile. Between the two, this led to the concept of Zero Trust.

Not all pentesters

Luckily, some pentest firms are identifying that it’s a bad idea, and not recommending to disable ipv6:

• Disabling IPv6 entirely may have unwanted side effects.

Finally, mentioning vohai for pointing out the mitigations are probably better off working around controlling the network better, instead of disabling ipv6.