A firewall restriction verified over IPv4 does not establish that the same restriction applies over IPv6. When a network supports both protocols, its access policy needs to cover both. The rules may share a management interface, but the operator still needs to confirm which addresses, connections, and inspection functions they actually govern.
For IT directors and MSPs, the question is practical: can the same business service become reachable through an address family that was left out of the policy review? The answer depends on the deployed configuration, not simply whether the firewall advertises IPv6 support.
What does a successful IPv4 test leave unanswered?
A dual-stack device can communicate using IPv4 and IPv6. NIST's IPv6 deployment guidance treats the transition as a planning and security task, with changes to infrastructure and systems. The intended access boundary should be part of that planning.
Consider a hypothetical internal reporting server. The business permits access from the finance network and denies it from another department. An administrator verifies the denial using the server's IPv4 address. That result establishes something about the tested IPv4 connection; it says nothing about a separate IPv6 connection to the same service.
If the server also listens on IPv6, the team must establish which policy governs that connection. It might be correctly restricted already. It might be unreachable because no route exists. Or it might have a different permission. Those outcomes require different explanations, even when an initial connection attempt fails.
This is a planning example, not a customer incident. Its lesson is to record the address family alongside the source, destination, service, and expected access decision.
Should the IPv6 rules simply copy the IPv4 rules?
The business intent should be equivalent, but the technical rules need to respect protocol differences. IETF RFC 9099 recommends consistent security policy across a dual-stack network, with access controls and firewalls configured to protect IPv6 as well as IPv4. It also notes the operational challenge of keeping those policies aligned over time.
ICMPv6 is an important example. It carries control messages used to establish and maintain IPv6 communication. RFC 4890 explains why IPv4 ICMP filtering strategies cannot simply be transferred to IPv6. Its examples include Packet Too Big messages, which help a sender determine the packet size a path can carry.
A blanket decision to discard ICMPv6 can therefore break legitimate communication. Conversely, allowing every control message without considering its purpose and scope is not a sound substitute for policy. Have the network operator implement the platform's appropriate IPv6 controls while preserving the intended application-access restrictions.
Will the monitoring team see both paths?
Filtering coverage and investigation coverage are separate acceptance questions. The Canadian Centre for Cyber Security's IPv6 guidance calls for IPv6-capable security monitoring, log aggregation, and testing in both dual-stack and IPv6-only scenarios. An existing IPv4 dashboard does not establish that those capabilities are configured for IPv6.
Our practical recommendation is to trace an authorized, harmless connection test through the records the responding team will actually use. Can the analyst identify the IPv6 source and destination, the relevant device or asset, and the policy decision? A record visible on the gateway but missing from the central investigation view leaves a different gap from a rule that never matched.
Use designated test systems and agreed timing. Confirm a permitted workflow as well as a restricted one for each in-scope address family. Preserve the observed result and enforcement evidence; mark untested paths explicitly. This tests the stated coverage without requiring exploit traffic.
Make address-family coverage part of the service scope
Ask who maintains IPv4 and IPv6 policy together, which inspection and logging functions cover each, and when changes trigger another review. Include host controls and internal network boundaries where they form part of the actual traffic path. A gateway review alone cannot establish the behavior of every local connection.
Network Box USA's Managed Unified Threat Management brings firewall policy, intrusion prevention, logging, and operational support into an agreed gateway service. To discuss the traffic paths, address families, and validation responsibilities in your environment, contact our team.