Why IPv6 should be included in enterprise security testing

Many organisations still describe their networks as “IPv4 environments”. In practice, that description is often incomplete.

Modern operating systems, network devices and applications commonly support IPv6, and the protocol may be active on internal interfaces even where the organisation has not completed a formal IPv6 deployment. Microsoft describes IPv6 as a required component of modern Windows versions and recommends preferring IPv4 through prefix policies, where necessary, rather than disabling IPv6 outright.

The security problem is therefore not simply whether an organisation has intentionally adopted IPv6. The more important question is whether IPv6 is present, understood, governed and monitored.

When security testing examines only IPv4, it can leave part of the real network behaviour untested.

Dual stack creates an additional control plane

A dual-stack device can communicate using both IPv4 and IPv6. This does not automatically make the device insecure, but it means security controls must account for both protocols.

An organisation may have mature IPv4 controls covering:

• Network segmentation
• Firewall rules
• Intrusion detection
• Asset discovery
• DNS monitoring
• Endpoint hardening
• Network access control
• Security logging

The equivalent IPv6 controls may be incomplete, inconsistently configured or absent.

This can create situations where a service is filtered over IPv4 but reachable over IPv6, where an asset is missing from an IPv4-focused inventory, or where IPv6 activity passes through security tooling without generating the visibility defenders expect.

An assessment that tests only the organisation’s documented IPv4 architecture may therefore validate the intended network while overlooking how endpoints actually communicate.

IPv6 is not simply IPv4 with larger addresses

IPv6 introduces different mechanisms for address configuration, router discovery and communication between systems on the same network segment.

The IPv6 Neighbor Discovery protocol allows hosts to identify neighbouring systems, resolve link-layer addresses, discover routers and maintain reachability information. Router Advertisements can also provide hosts with network parameters and information used for address configuration.

These mechanisms are legitimate and necessary parts of IPv6. However, they also need appropriate governance.

The Neighbor Discovery specification notes that the protocol does not inherently determine which neighbouring systems are authorised to send certain messages, including Router Advertisements. Without suitable network controls, a system connected to the local segment may be able to present itself as a source of IPv6 configuration.

This matters because endpoints can process IPv6 configuration even where administrators do not consider IPv6 part of the production network.

Rogue configuration can become an identity problem

A local network weakness does not always remain a network-layer issue.

During an authorised internal assessment, a tester may investigate whether an untrusted device can influence IPv6 configuration, name resolution or traffic routing. In a Windows environment, successful manipulation of those services may cause systems to communicate with infrastructure controlled by the tester.

The immediate effect may be altered DNS resolution or redirected authentication traffic. The more serious question is whether that position can be used to interact with enterprise authentication protocols, relay credentials, access internal services or reach a more valuable security objective.

MITRE ATT&CK documents DHCP spoofing, including DHCPv6-based behaviour, as an adversary-in-the-middle technique that may redirect network traffic towards attacker-controlled systems. Its mitigation guidance specifically recommends controlling DHCPv6 traffic and incoming Router Advertisements where they are not expected.

This illustrates why weaknesses should not be assessed in isolation. A network configuration issue may appear low risk until it is combined with:

• Weak name-resolution controls
• NTLM authentication exposure
• Insufficient signing or channel-binding protections
• Excessive machine-account privileges
• Misconfigured Active Directory Certificate Services
• Inadequate network segmentation
• Limited monitoring of IPv6 traffic

The resulting attack path can be more significant than any individual configuration weakness suggests.

“We do not use IPv6” is not evidence that it is absent

One of the first objectives of an assessment should be to establish the actual state of IPv6 across the environment.

That includes determining:

• Which endpoints and servers have IPv6 enabled
• Which IPv6 addresses are assigned
• Whether Router Advertisements are present
• Whether DHCPv6 is in use
• How DNS servers are learned
• Which services listen on IPv6 interfaces
• Whether IPv6 traffic crosses security boundaries
• Whether network and endpoint controls inspect that traffic
• Whether security teams can detect unexpected IPv6 behaviour

The goal is not to generate IPv6 traffic indiscriminately. Testing should be proportionate, authorised and aligned with the agreed rules of engagement.

The objective is to compare the organisation’s assumptions with observable network behaviour.

Disabling IPv6 is not a complete security strategy

It can be tempting to treat disabling IPv6 as the simplest remediation. In some environments, restricting IPv6 may be appropriate. However, blanket removal is not always practical and may affect operating-system or application functionality.

Microsoft advises that IPv6 is a required component of current Windows networking and recommends preferring IPv4 over IPv6, where that behaviour is required, rather than disabling IPv6 completely.

A more sustainable approach is to make an explicit architectural decision:

• Where IPv6 is required, configure, secure and monitor it as a production protocol.
• Where IPv6 is not required, restrict unauthorised IPv6 configuration and traffic using supported network and endpoint controls.
• Where the position is unclear, perform discovery before deciding how the protocol should be governed.

Ignoring IPv6 while leaving it enabled provides neither the operational benefits of a managed deployment nor the risk reduction of an intentionally restricted one.

What IPv6 security testing should cover

The exact test plan should reflect the environment, but an internal infrastructure assessment may include:

• IPv6 host and service discovery
• Comparison of IPv4 and IPv6 exposure
• Router Advertisement and DHCPv6 behaviour
• Unauthorised network-configuration testing
• DNS configuration and resolution paths
• IPv6 firewall and segmentation validation
• Neighbor Discovery protections
• Endpoint configuration review
• Authentication exposure over IPv6
• Monitoring and alerting validation
• Controlled testing of potential attack-path combinations

Testing should also establish whether defensive controls respond consistently across both protocol families.

For example, a security team may detect suspicious DNS or authentication activity over IPv4 but have little equivalent visibility when the same behaviour occurs over IPv6.

Include IPv6 explicitly in assessment scope

IPv6 should be addressed during scoping rather than silently assumed to be absent.

Useful scoping questions include:

• Is IPv6 intentionally deployed?
• Is it enabled on Windows endpoints and servers?
• Are IPv6 firewall rules maintained?
• Are Router Advertisements and DHCPv6 controlled?
• Can security monitoring inspect IPv6 traffic?
• Has IPv6 been included in previous penetration tests?
• Are IPv6 findings owned by a specific operational team?

Where IPv6 is present, proportionate testing can determine whether it creates additional reachability, configuration or identity attack paths. Where it is genuinely absent or effectively restricted, the assessment can validate that conclusion rather than relying on assumption.

Test the network that exists

Enterprise security testing should reflect actual system behaviour, not only the architecture shown in diagrams.

IPv6 is not automatically a vulnerability, and its presence does not mean an organisation is exposed to a specific attack. The risk emerges when the protocol is enabled but excluded from asset management, hardening, monitoring and security validation.

For organisations operating modern Windows environments, IPv6 should therefore be treated as an explicit part of infrastructure-security scoping.

Testing both sides of a dual-stack network provides a more accurate view of exposure and reduces the chance that an overlooked protocol becomes an alternative path around otherwise mature controls.

This article is informed by research presented by Safestorm’s founder at BSides London in the talk “From Silent Threat to Visible Danger: IPv6 Attacks Inside Corporate Networks”.

References and further reading

• Microsoft: Guidance for configuring IPv6 in Windows — support status, prefix policies and Microsoft’s recommendation against disabling IPv6.
• IETF RFC 4861: Neighbor Discovery for IPv6 — Neighbor Discovery, Router Advertisements and the protocol’s security considerations.
• MITRE ATT&CK T1557.003: DHCP Spoofing — DHCPv6 spoofing, adversary-in-the-middle behaviour and mitigation guidance.
• NIST SP 800-119: Guidelines for the Secure Deployment of IPv6 — IPv6 security considerations and deployment guidance.
• NSA: IPv6 Security Guidance — security risks associated with IPv6 transition and increased attack surface in dual-stack networks.
• CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection — asset discovery covering systems accessible through either IPv4 or IPv6.