The application server cannot reach the database management interface over IPv4. Good.
Now run the same test over IPv6.
If the second connection succeeds, the application is not contained. One address family is contained. That distinction belongs in the acceptance criteria, not in a footnote on the network diagram.
This is an implementation review, not a claim about a newly discovered attack campaign. The useful question is simple: does your segmentation intent survive a change of address family?
Start With Policy Parity, Not Identical Rules
RFC 9099 recommends security-policy consistency between IPv4 and IPv6 in dual-stack networks. It also discusses the operational difficulty of maintaining that consistency over time.
My translation into a microsegmentation requirement: the business relationship should remain the same, even when the addresses and enforcement details differ.
If the front end may call the application API, that relationship should work over the supported address families. If it may not administer the database, neither address family should provide that route.
Do not measure parity by counting rules. Measure it by comparing outcomes for the same source workload, destination role, protocol and operation.
Inventory The Second Path
For one critical application, I would build a small reachability inventory before changing policy:
- Every source workload and its IPv4 and IPv6 addresses.
- Every destination interface, including administration and monitoring interfaces.
- DNS names and the addresses they resolve to from the source environment.
- The route and enforcement point used for each address family.
- The owner of each required connection.
Include paths within a subnet, across routed boundaries and through service front ends. Treat these as distinct test cases rather than assuming that a perimeter rule covers all of them.
The output should be a short connection contract. For example:
| Source | Destination | Intended result | Evidence required |
|---|---|---|---|
| Front-end workload | Application API | Allow approved API port | Successful request over each supported family |
| Front-end workload | Database administration | Deny | Failed connection plus enforcement evidence for each family |
| Application workload | Its database listener | Allow approved database port | Successful application transaction for each supported family |
| Application workload | Unrelated application tier | Deny | Separate IPv4 and IPv6 negative tests |
| Quarantined workload | Ordinary application peers | Deny | Isolation verified over both families |
This is a proposed acceptance matrix, not a universal port list. Fill in the actual dependencies. Keep administrative access separate from application traffic.
Kubernetes Makes The Question Concrete
The Kubernetes dual-stack documentation describes support for IPv4 and IPv6 addresses on Pods and Services, subject to networking prerequisites. Service settings such as ipFamilies and ipFamilyPolicy describe address-family behavior. They do not establish your application’s authorization boundary.
For a dual-stack cluster, I would review three things together: the Service configuration, the selected workloads and the actual policy implementation.
The NetworkPolicy documentation makes two important points: enforcement requires a supporting network plugin, and applicable policies are additive. Creating an object is not proof of enforcement. Adding a restrictive-looking policy does not cancel permissions granted by another policy.
Review the combined permissions for the selected Pods. Then test both address families through the paths the application actually uses. Include direct Pod access and Service access where those paths exist.
Keep node and host-network traffic in a separate review. Kubernetes documents implementation-dependent behavior for hostNetwork Pods. Do not silently include those workloads in a containment claim established only for ordinary Pod networking.
For external destinations represented by CIDRs, explicitly review the IPv4 and IPv6 ranges. For selector-based relationships, verify the resulting behavior rather than assuming that an address-independent policy definition guarantees equivalent enforcement in your installed configuration.
Do Not Break IPv6 To Prove You Blocked It
An unreachable destination is not automatically evidence of a working deny rule. A missing route, broken name resolution or unhealthy listener can produce the same failed application test.
RFC 9099 also explains why selected ICMPv6 messages are needed for functions such as Neighbor Discovery and Path MTU Discovery. A blanket ICMPv6 block is not a substitute for a designed application boundary. See its enterprise-network recommendations.
I would distinguish three outcomes in the review:
- Allowed and working: the approved application operation succeeds.
- Denied by policy: the attempted operation fails and enforcement evidence explains the failure.
- Not testable: the destination or route is unavailable, so the test does not establish containment.
That third category matters. Without it, an incomplete IPv6 deployment can produce an impressive-looking security result that disappears when someone fixes routing.
Run A Small, Repeatable Acceptance Test
Choose a controlled source workload that represents the application tier. Use an approved test destination with a known working listener. Avoid broad scanning of production networks.
For an HTTP service in that test environment, forcing the address family makes the comparison explicit:
curl -4 --connect-timeout 5 https://test-service.example/health
curl -6 --connect-timeout 5 https://test-service.example/health
Replace the example hostname with your controlled service. These requests test connectivity and application response, not the entire segmentation policy. Use the relevant protocol client for non-HTTP dependencies.
For each allowed and denied relationship, record the source identity, destination address, address family, policy revision, timestamp, result and matching enforcement event. Confirm destination health from an authorized source. A timeout alone is insufficient.
Then apply the proposed quarantine state to the controlled source and repeat the denied-path checks over both families. Verify required response access separately. Test restoration to the normal approved policy as another explicit state transition.
My acceptance criterion would be: no prohibited relationship succeeds over either family, and the required business connections remain usable. Any unexplained difference stays open as a defect.
Make Address-Family Changes A Security Change
I would rerun this matrix when enabling dual-stack networking, changing a network plugin, introducing an IPv6 route or adding a second address family to a Service. Also rerun it when changing the enforcement technology or quarantine procedure.
Assign one owner to the application boundary across both families. Otherwise, an IPv4 policy review and an IPv6 networking review can both finish without anyone proving the combined result.
The point is not that IPv6 is inherently less secure. The point is that a containment claim must cover every supported path to the protected workload.
An attacker does not need your preferred address family. They need one permitted connection that should have been denied.
Sources
- IETF: RFC 9099, Operational Security Considerations for IPv6 Networks.
- Kubernetes: IPv4/IPv6 dual-stack.
- Kubernetes: Network Policies.
