IPv4 & IPv6 Network Security — From Packet Filtering to Behavioural Defence
Modern network security is not a single firewall rule or access list. It is a layered control system that determines who can communicate, which traffic is permitted, where trust boundaries exist, how IPv4 and IPv6 behave differently, and how abnormal traffic is detected and investigated.
Networks must support legitimate application traffic while limiting unwanted access, protecting infrastructure protocols, controlling lateral movement, and maintaining visibility across both IPv4 and IPv6 paths.
Define the Boundary
Identify trust zones, interfaces, identities, services and the traffic that should be permitted between them.
Enforce Policy
Apply ACLs, firewall policy, segmentation and IPv6-specific protections at the points where traffic crosses a security boundary.
See Behaviour
Combine flow telemetry, packet visibility, DNS, connection metadata and infrastructure events to establish what normal looks like.
Investigate Change
Correlate unusual behaviour with policy, topology and application context to determine whether an event is expected, suspicious or malicious.
Security follows the data flow.
A secure design starts with the communication path: source, destination, protocol, service, trust boundary and enforcement point. IPv6 introduces additional control-plane considerations such as Neighbor Discovery, Router Advertisements and multicast behaviour, while transition technologies introduce their own security boundaries.
Who or what is attempting the communication?
Should this source be allowed to reach this destination?
What does the traffic reveal about behaviour and change?
Does the observed behaviour indicate compromise or abuse?
Behavioural Threat Detection Explorer
Security visibility turns network telemetry into intelligence. Explore how traffic patterns can expose beaconing, DNS tunnelling, lateral movement and abnormal east-west activity.
Network Security Control Plane Explorer
Modern network security is not enforced by a single firewall. Identity, segmentation, network controls, application inspection and detection work together to determine whether traffic should be allowed, blocked or isolated.
Security Enforcement Pipeline
POLICY ACTIVEControl Analysis
Establish who is requesting access
Identity is the first decision point in a modern security architecture. Authentication, device posture and contextual information establish whether the request can continue through the security pipeline.
Security Pipeline Outcome
READYSelect a control above to examine how that layer contributes to the overall network-security decision.
IPv4 & IPv6 Network Security
Follow the security model from architecture and policy through IPv6 control-plane protection, telemetry, behavioural investigation, automated response and continuous assurance.
Security Architecture — Follow the Data Flow
Start with the communication relationship before choosing the security control. Tap a component to see where the trust boundary and enforcement decision belong.
Who initiates the traffic?
Start at the source. Identify the system initiating the communication before deciding what should be permitted.
Security Architecture & Trust Boundaries
Network security begins before a firewall rule is written. The first task is to understand what is communicating, where trust changes, which traffic is expected, and where that communication can be controlled. This creates the security architecture that later filtering, inspection and monitoring mechanisms enforce.
A useful security model connects the source, destination, application, protocol, trust zone and enforcement point rather than treating the network as a collection of isolated devices.
Who initiates?
Identify the user, endpoint, server, workload or infrastructure device generating the traffic.
What is reached?
Determine the destination network, host, service or application being accessed.
Where does trust change?
Identify the boundary between users, servers, management, Internet, cloud and other security zones.
Where is it enforced?
Place the appropriate ACL, firewall, segmentation or inspection control at the point where it can make the required decision.
Trust Boundaries
A trust boundary is the point at which traffic moves between different security assumptions. The boundary may exist between a user VLAN and server network, between an enterprise and the Internet, or between on-premises infrastructure and a cloud environment.
- User and endpoint networks
- Server and application zones
- Management infrastructure
- Internet and external services
- Cloud and hybrid environments
Control Points
Once the boundaries are understood, security controls can be mapped to the traffic path. The objective is not simply to block traffic, but to make the policy decision explicit and observable.
- Router and Layer 3 ACLs
- Stateful firewall policy
- Network segmentation
- Identity and access controls
- IDS/IPS and inspection systems
IPv4 and IPv6 must be secured as separate control planes.
A network can appear secure from an IPv4 perspective while IPv6 provides an overlooked path around the intended policy. Security architecture must therefore account for both protocol stacks, their control-plane behaviour, addressing model, routing, neighbour discovery and enforcement mechanisms.
Trust Boundary Investigation
Policy Decisions — Permit the Relationship, Not the Guess
Build a simple security decision by defining who is communicating, what protocol is being used and whether that relationship is actually required.
Permit only required access
The selected relationship represents an intentional communication path. Enforce it at the appropriate ACL or firewall control point.
ACLs, Firewall Policy & Network Segmentation
Once trust boundaries and expected communication flows are defined, the next step is enforcement. ACLs and firewalls provide the decision logic that determines whether traffic is permitted, denied, inspected or logged. Segmentation then limits how far a compromised endpoint or workload can move through the network.
A strong policy is specific about source, destination, protocol, service and direction. Broad rules may restore connectivity quickly, but they also make the security boundary difficult to understand and defend.
ACLs
Apply packet-level permit and deny decisions using addresses, prefixes, protocols and ports at routing or interface boundaries.
Stateful Firewalls
Evaluate traffic in the context of connections, zones, applications and security policy rather than treating every packet independently.
Segmentation
Reduce unnecessary reachability between users, workloads, management systems and sensitive services.
One policy. Two protocol stacks.
Deploying IPv6 does not automatically inherit the security posture of IPv4. IPv6 requires its own filtering and control-plane considerations, including Neighbor Discovery traffic and the protocols required for normal IPv6 operation.
Reduce reachability before detecting compromise.
Segmentation provides a preventative control. If an endpoint is compromised, limiting which networks and services it can reach can reduce lateral movement before detection and response mechanisms take effect.
Policy Decision Engine
IPv6 Control Plane — Follow the Discovery Sequence
IPv6 relies on Neighbor Discovery for router discovery, prefix discovery, address resolution, duplicate-address detection and neighbor reachability. Step through the sequence to see where security controls matter.
Router Advertisement
Router Advertisements provide hosts with information about available IPv6 routers and network configuration. An unexpected RA can therefore influence how hosts configure and route traffic.
IPv6 Control-Plane Security
IPv6 changes more than the address format. Core network functions such as address resolution, router discovery and duplicate-address detection are performed through Neighbor Discovery Protocol (NDP) and IPv6 multicast. These mechanisms are essential to normal operation, but they also create security considerations that do not have a direct IPv4/ARP equivalent.
Security controls must distinguish legitimate Neighbor Discovery and Router Advertisement traffic from malicious or unexpected control-plane behaviour.
Neighbor Discovery
Provides neighbour discovery, address resolution, router discovery, prefix discovery and neighbour reachability functions.
Router Advertisements
Hosts learn IPv6 prefixes, default-router information and other configuration parameters through Router Advertisements.
Duplicate Address Detection
Hosts use Neighbor Solicitation to determine whether an IPv6 address is already in use before assigning it to an interface.
RA Guard
Layer 2 infrastructure can filter unauthorized Router Advertisements at the access boundary before they reach end hosts.
RA Guard at the access boundary
An unauthorized device sending Router Advertisements can influence how hosts select default routers or configure their IPv6 connectivity. RA Guard provides a Layer 2 enforcement mechanism that can block unwanted Router Advertisements on access ports while allowing them on trusted router-facing paths.
IPv6 attacks can begin with control traffic.
Security monitoring should not focus exclusively on application payloads. Unexpected Router Advertisements, abnormal Neighbor Discovery behaviour, duplicate-address events or unusual IPv6 multicast activity can provide valuable evidence during an investigation.
IPv6 Control-Plane Investigation
IPv6 Transition — Choose the Mechanism for the Problem
NAT64, NPTv6 and tunnelling solve different connectivity problems. Select a mechanism to see what changes in the packet path and where the new security boundary appears.
NAT64 — IPv6 to IPv4 Translation
Protocol TranslationIPv6 Transition, Translation & Tunnelling
IPv4 and IPv6 will often coexist for many years. Security architecture therefore has to account for transition mechanisms as well as native IPv6 traffic. Translation, prefix translation and tunnelling solve different engineering problems and introduce different security boundaries.
NAT64 provides IPv6-to-IPv4 communication, NPTv6 performs stateless IPv6-to-IPv6 prefix translation, while GRE can encapsulate traffic across an IPv4 underlay. Their security properties and control points are fundamentally different.
NAT64
Allows IPv6-only clients to communicate with IPv4-only destinations through an IPv6-to-IPv4 translation function.
NPTv6
Provides stateless IPv6-to-IPv6 prefix translation. It can be useful for prefix independence or multihoming designs, but it does not provide IPv4/IPv6 interoperability.
GRE + IPsec
GRE can carry IPv6 traffic across an IPv4 transport network. GRE itself does not provide confidentiality; IPsec can be used to protect the encapsulated traffic.
Every translation or tunnel changes what you can see.
A security device may observe the original IPv6 flow, a translated IPv4 flow, or an encapsulated tunnel depending on where inspection occurs. Logging and policy therefore need to identify the correct enforcement point and preserve enough context to reconstruct the original communication.
Secure the transition mechanism itself.
Translation and tunnelling infrastructure should be treated as part of the security architecture. Restrict management access, monitor unusual translation or tunnel activity, apply appropriate filtering and ensure that security policy remains consistent across both sides of the transition boundary.
IPv6 Transition Architecture Explorer
Security Visibility — Choose the Evidence
Different telemetry sources answer different questions. Select an evidence source to see what it can establish, what it cannot prove, and how it contributes to an investigation.
NetFlow / IPFIX
FLOW EVIDENCENetwork Telemetry & Security Visibility
Prevention alone cannot establish whether a network is behaving as expected. Security operations require evidence from multiple visibility layers: flow records, packet observations, infrastructure telemetry, connection metadata and security events. The objective is to turn raw network activity into an evidence trail that can be investigated.
Effective monitoring means collecting the right evidence at the right observation point and correlating it with topology, identity, policy and application context.
NetFlow / IPFIX
Provides flow metadata such as endpoints, ports, protocol, byte counts, packet counts and timing information.
sFlow
Uses sampling to provide scalable visibility into traffic behaviour and interface activity across large networks.
SPAN / Capture
Provides packet-level evidence for deeper protocol analysis and investigation when flow metadata is insufficient.
Security Telemetry
Firewall, IDS/IPS, DNS, authentication and endpoint events add context around network behaviour and policy decisions.
What the Network Can Tell You
Flow and telemetry systems may not expose application payloads, but they can still reveal important behavioural signals.
Encrypted Traffic Still Leaves Signals
Encryption protects payload content, but network communication still produces observable metadata. Traffic volume, packet sizes, timing, destinations, connection frequency and DNS activity can contribute to behavioural analysis.
Observe → Correlate → Baseline → Investigate
A useful security monitoring architecture does not stop at collecting telemetry. Evidence becomes valuable when network observations can be correlated with infrastructure state, identity, policy and application behaviour.
Network Telemetry & Security Evidence Lab
Behavioural Threat Detection — Investigate the Change
A security event becomes meaningful when it can be compared with normal behaviour. Step through the investigation from baseline to correlated evidence and determine whether the change needs investigation.
Establish the baseline
The first question is not "is this malicious?" It is whether the observed communication differs from the expected operating pattern.
Behavioural Threat Detection
Traditional security controls are designed around known policy: permitted destinations, approved services, trusted systems and expected communication paths. Behavioural detection adds another question: does the observed behaviour match the normal operating pattern? This allows security teams to identify suspicious change even when no single packet or rule violation provides the complete answer.
A useful detection model establishes a baseline, identifies meaningful deviations and correlates several weak signals before escalating an event into an investigation.
Know Normal
Understand normal hosts, services, destinations, traffic volumes and communication patterns.
Find Change
Identify unusual communication, volume, timing, destinations or access patterns.
Build Evidence
Combine network, DNS, identity, endpoint and security telemetry to strengthen the signal.
Explain the Change
Determine whether the deviation is expected activity, misconfiguration or evidence of compromise.
Behavioural Signals
Individual observations are rarely enough to establish an incident. Their value increases when several signals point toward the same behavioural change.
IPv4 & IPv6 Behaviour
Dual-stack environments create another investigation dimension. Security teams must determine whether IPv4 and IPv6 exhibit the same expected communication relationships.
Baseline → Detect → Correlate → Validate → Respond
Behavioural detection should produce an explainable evidence chain rather than an isolated alert. The investigator starts with the deviation, identifies the affected systems and communication paths, then validates whether the observed behaviour is expected before taking containment or response action.
Behavioural Threat Investigation Console
Response Decisions — Automate What You Understand
Detection does not automatically justify containment. Select the confidence level and see how the response should become more controlled as evidence becomes stronger.
Validate Before Acting
LOW CONFIDENCEInvestigate — Do Not Automatically Contain
A single signal is not enough to justify a disruptive policy change. Gather additional evidence and validate the event first.
Security Operations & Automated Response
Detection becomes valuable when it can drive a controlled response. Security operations connect the investigation evidence from the previous sections with enforcement systems such as firewalls, IDS/IPS, access controls, routing policy and endpoint controls. The objective is not to automate every decision, but to make response consistent, explainable and repeatable.
High-confidence, well-defined actions can be automated. Ambiguous events should retain a human investigation step before disruptive controls are applied.
IDS / IPS
Identify suspicious traffic and, where appropriate, apply prevention or blocking controls.
Segmentation
Reduce the reachable attack surface by isolating affected systems or communication paths.
Policy Change
Update firewall, ACL, routing or access policy when evidence justifies a change.
Restore State
Remove temporary controls and confirm that normal, validated behaviour has returned.
Response Decisions
Response should be proportional to confidence and impact. A suspicious signal does not automatically justify a disruptive network change.
Human + Automation
Automation is most effective when it operates inside clearly defined guardrails rather than replacing engineering judgement.
Detect → Validate → Contain → Verify → Recover
Automation platforms such as Ansible Automation Platform can orchestrate repeatable operational actions across network and security infrastructure. The important engineering control is the workflow around the automation: evidence, approval boundaries, execution, verification and rollback.
Security Response Decision Engine
Continuous Security — Validate the Network You Actually Have
Security controls drift as networks change. Explore the assurance loop and see how expected data flows are compared with observed reality across IPv4 and IPv6.
Map the Expected Flow
ASSURANCE 01Understand the communication relationship
Before validating security, establish which systems should communicate, across which protocol stack and through which control points.
Continuous Security & Assurance
Network security is not a configuration that is completed once and then forgotten. Networks change, applications move, policies evolve and new IPv4 and IPv6 paths appear. Continuous security assurance validates that the intended communication model still matches the observed environment.
A policy can be syntactically correct while still being ineffective. Assurance therefore compares intended reachability, enforced controls and observed behaviour.
Understand the Flow
Identify systems, services, trust boundaries and the communication paths that should exist.
Validate Policy
Confirm ACLs, firewalls, segmentation and IPv6 controls enforce the intended relationships.
Compare Reality
Use telemetry to determine whether actual communication matches the expected security model.
Close the Gap
Remove unnecessary reachability, improve visibility and update controls as the environment changes.
Continuous Validation Questions
Assurance should turn security policy into measurable engineering questions rather than relying only on configuration review.
Security Drift
Security drift occurs when the environment gradually moves away from the intended security model. This can happen through new applications, firewall changes, temporary exceptions, topology changes or previously unknown IPv6 connectivity.
Model → Enforce → Observe → Compare → Improve
The strongest security architecture continuously compares the intended network model with observed behaviour. This turns security from a static collection of rules into an engineering feedback loop.
