description: An operational security field guide for IPv6: the encryption story, first-hop and Neighbor Discovery threats, extension-header and ingress filtering, address privacy, topology hiding without NAT, and RPKI routing integrity for your isp6 allocation.

Securing IPv6: An Operational Field Guide

The parts of the security surface that are genuinely IPv6's own: the first hop, extension headers, filtering, address privacy, and routing integrity. Here is how to lock them down.

Audience: isp6 members, network and security engineers, and platform teams operating IPv6 in production, dual-stack or IPv6-only, on-premises or in cloud.

Last updated: July 2026

Most of what you already do to secure a network still applies. Ingress filtering, a default-deny border, control-plane protection, RPKI, DNSSEC, least privilege: none of that changes because the packets are longer. The differences that matter are concentrated in a few places: the first hop (Neighbor Discovery and SLAAC), extension headers, and the fact that there is no NAT doing incidental work at the border. This guide covers those, plus the one piece of received wisdom worth correcting up front: that IPv6 is somehow "encrypted by default."

For the IPv4 reflexes that most often survive into a fresh IPv6 deployment, such as blocking all ICMP, reaching for NAT, treating ULA as private addressing, scanning subnets to find hosts, see the companion article Stop Thinking in IPv4. This one stays on the IPv6 security surface itself and does not re-tread that ground.

On this article's sources. The operational analysis below draws on the Security and Management and Operations chapters of book6: A Collaborative IPv6 Book, the open-source IPv6 textbook maintained by Brian E. Carpenter and its contributors, and on the standards it cites, most importantly RFC 9099, Operational Security Considerations for IPv6 Networks. We have summarised and re-framed the material for isp6 members rather than reproduced it, and recommend book6 and RFC 9099 as the authoritative next reads.

1. The encryption question: is IPv6 "encrypted by default"?

The single most persistent claim about IPv6 security is that, unlike IPv4, it has encryption "built in." It is worth being precise about what is true here, because the loose version of the claim leads teams to under-invest in the encryption that actually protects their traffic.

What is true: IPv6 defines the IPsec headers, Authentication Header (AH) and Encapsulating Security Payload (ESP), as native extension headers, chained from the Next Header field and processed by the stack without a bolt-on shim. The original vision for IPv6 went further still: end-to-end cryptography was expected to be mandatory, via IPsec (RFC 4301) for payload protection and SEND (RFC 3971) for securing Neighbor Discovery itself.

What actually happened: that vision proved unrealistic. Requiring every device, down to the smallest embedded sensor, to implement full IKEv2 and ESP was not viable, so the requirement was relaxed from MUST to SHOULD (the trajectory is tabulated in the misconceptions article; the current baseline is RFC 8504). SEND was never meaningfully adopted by the market at all. The net result, in book6's words, is that network-layer cryptography is optional in IPv6, exactly as it is in IPv4, while cryptography has become near-ubiquitous a layer or two up, at the transport and application layers.

The practical guidance that follows from this:

• Do not treat an IPv6 packet as confidential because it is IPv6. It is exactly as cleartext on the wire as an IPv4 packet unless something encrypted it. Plan encryption explicitly.
• Encrypt at the layer that fits the job. Use TLS 1.3 / QUIC for application traffic and SSH for management. This is where the ecosystem, certificate tooling, and performance work already live. Reach for IPsec (ESP) for network-to-network tunnels and specific host-to-host cases, the same way you would on IPv4.
• Zero-trust fits IPv6 well. Because IPv6 restores end-to-end addressing, the model of authenticating and encrypting every flow, rather than trusting a perimeter, maps cleanly onto it. That is a reason to invest in per-flow crypto, not a reason to assume the network already did it for you.

The honest summary: IPv6 makes end-to-end encryption easier to reason about (no NAT in the path to mangle AH, a clean extension-header model), but it does not turn it on. Your encryption posture is still something you design and deploy.

2. The border: a firewall, not NAT

In IPv4, the stateful NAT table did a security job almost by accident: with no inbound mapping, unsolicited traffic from outside had nowhere to go. IPv6 removes NAT from the picture, which means that incidental protection disappears and must be made explicit.

This is not a downgrade. NAT was never a real security control, and both book6 and RFC 4864 are clear that a stateful firewall provides equal or better protection without the collateral damage of address translation. But it does mean the border posture has to be stated, not inherited:

• Run a stateful firewall at the border with a default-deny inbound policy, permitting only the flows you intend to expose. Every host having a globally routable address is a feature; it is not an invitation to reach every host.
• Keep dual-stack policy in parity. In a dual-stack network, still the majority of deployments, the IPv6 firewall policy should match the IPv4 policy rule-for-rule. Divergence is where the quiet holes appear: an IPv4 rule everyone remembers and an IPv6 gap nobody wrote.
• Permit the ICMPv6 that IPv6 needs. A blanket "deny ICMP" reflex from IPv4 is actively harmful here, because Path MTU Discovery and Neighbor Discovery depend on it. Follow RFC 4890; the full message-type breakdown is in the misconceptions article.

3. The first hop is the new attack surface

If IPv6 has a security story that is genuinely its own, it is on the local link. IPv4 had ARP spoofing and rogue DHCP; IPv6 has the same shape of threat, but a larger and more subtle surface, because address configuration is distributed (SLAAC) and Neighbor Discovery runs over ICMPv6 at layer 3.

The threats described in RFC 3756 remain live, because the cryptographic answer to them, SEND, was never deployed:

• Rogue Router Advertisements. A malicious (or simply misconfigured) node sending Router Advertisements can make itself the default gateway, inject prefixes, or black-hole the link. This is the IPv6 equivalent of rogue DHCP, and it is the classic man-in-the-middle setup.
• Neighbour cache poisoning. Forged Neighbor Solicitation / Advertisement messages redirect a victim's (or the router's) traffic, directly analogous to ARP spoofing.
• Duplicate Address Detection denial of service. A hostile node that answers every DAD probe can stop new hosts configuring an address at all.
• Neighbor Cache Exhaustion (NCE). Because a /64 holds 2⁶⁴ addresses, an attacker can send traffic to a flood of unused addresses on a subnet and force the router into endless address resolution, starving the neighbour cache (RFC 6583).

The defences are switch- and host-side, and they are mature even though SEND is not:

Two structural points make these easier in IPv6 than the equivalent IPv4 hardening:

• RA-Guard and DHCPv6-Shield must be enabled to matter. They are widely supported on managed switches but are frequently left off. On any access network carrying untrusted or user devices, turning them on is the single highest-value first-hop control.
• Address space lets you isolate. Where a link genuinely needs to contain a hostile or sensitive node, IPv6's abundance makes per-host segmentation cheap: give the node its own /64 on its own link. You are not rationing subnets, so isolation is a design choice rather than an addressing sacrifice, see Planning Your isp6 Allocation for the hierarchy.

Note that first-hop attacks require the attacker to be on the link. Perimeter control and physical/port security still do most of the work of keeping them off it, exactly as with ARP and DHCP in IPv4.

4. Filtering IPv6 correctly

Most filtering practice carries straight over. The IPv6-specific wrinkles are worth knowing precisely, because getting them wrong either opens a hole or breaks connectivity.

What is unchanged. Implement these for IPv6 just as for IPv4:

• Anti-spoofing ingress filtering at the network edge (BCP 38): permit only source addresses from the customer's delegated prefix. (The one deliberate exception is provider multihoming, where mutual-backup traffic must be accepted, see Multihoming IPv6 Without the Renumbering Tax.)
• Bogon / martian filtering at the perimeter, driven by the IANA IPv6 Special-Purpose Address Registry rather than a hand-maintained list (RFC 6890).
• Control-plane protection, RPKI-based route filtering, and DNSSEC, unchanged in principle for IPv6.

What is IPv6-specific:

• Scope-based filtering. Link-local addresses must never be forwarded off the link; Unique Local Addresses (RFC 4193) must be dropped at the organisation border; multicast has defined scopes that should be filtered at their respective boundaries (RFC 4291).
• Filter at /64, not longer. Filtering a prefix longer than a /64 is pointless: a host legitimately rotates through many temporary addresses within its /64. To act against a single subscriber, filter the /64 first and only widen to /60 or /56 if the problem persists; /48 is the largest a single ordinary subscriber holds.
• Extension-header handling. Extension headers are IPv6's extensibility mechanism and also its most abused feature. The baseline rule for transit is to forward packets with extension headers by default (RFC 7045); the nuanced per-header guidance on what to permit, drop, rate-limit, or reject at transit routers is RFC 9288. Over-aggressive extension-header filtering is a common cause of mysterious end-to-end IPv6 breakage.
• Fragment sanity. IPv6 fragmentation happens only at the source (never in transit) and uses an extension header. Security devices and destinations should require the first fragment to contain the entire header chain, including the transport header, and reject overlapping fragments, both mandated by RFC 8200 and central to closing the RA-Guard evasion described above.
• Budget for the cost. Each IPv6 filter entry typically consumes around four times the resources of its IPv4 equivalent (128-bit vs 32-bit matches). On under-provisioned hardware this affects scale and throughput, so size for it.

5. Privacy, many addresses, and hiding topology without NAT

An IPv6 host does not have one address; it has several, often with unpredictable, rotating interface identifiers. That is a privacy improvement and an operational consideration at the same time.

• Temporary addresses (RFC 8981) rotate the interface ID so a host is not trivially trackable across sessions by its address. Stable, per-network opaque interface identifiers (RFC 7217) remove the old MAC-derived, cross-network-traceable EUI-64 identifier without changing on a given link. Most modern stacks use both.
• The same property that protects the user complicates tracing. Because a host's outward address changes, correlating activity for auditing, abuse handling, or lawful intercept relies on logging (NDP/DHCPv6 bindings, flow records) rather than on the address being stable. Decide your logging and retention posture deliberately; RFC 7721 and RFC 9099 cover the trade-offs.

Hiding topology without NAT. Some environments, with PCI-DSS the common driver, need internal systems to be undiscoverable from outside even while offering public services. IPv4 often leaned on NAT for this; PCI-DSS v4 (2022) no longer requires it, and IPv6 has cleaner options:

• Use temporary addresses for outbound sessions from systems that should not be reachable by a stable address.
• Front services with proxies and load balancers, which intrinsically hide the core topology, and most large deployments do this for scaling anyway.
• Dis-aggregate the allocation: announce only the portion of your GUA block that needs public reachability into the global routing table, and keep the rest unannounced. This gives NAT-like obscurity without translation, at the cost of a little border-routing care, so pair the routing policy with access-control lists ("belt and suspenders") so an internal-only prefix cannot leak into the default-free zone.

6. The IPv4-only network is not exempt

A network you believe is "IPv4-only" almost certainly has IPv6-capable hosts on it, because every modern OS ships with IPv6 enabled and preferred. That creates a real attack path: a malicious node can send Router Advertisements and stand up rogue IPv6 connectivity on a link that has no IPv6 monitoring at all, using it for a man-in-the-middle or to tunnel around perimeter controls.

RFC 7123 covers this directly. The defensive posture: either run IPv6 properly (with the first-hop controls in Section 3), or, on links that must stay IPv4-only, actively suppress and monitor for rogue RAs and unexpected IPv6 tunnelling rather than assuming absence. "We don't use IPv6" is a policy statement, not a security control.

7. Routing integrity, and where isp6 fits

Everything above protects hosts and links. The layer underneath, whether the internet routes your prefix to you, is secured by RPKI, and it is the part of IPv6 security most directly tied to holding your own address space.

A Route Origin Authorisation (ROA) is a signed statement of which Autonomous System is allowed to originate your prefix. Without one, a wrong or hostile announcement of your space can pull your traffic to someone else, and validating networks have nothing to check it against. With valid ROAs, RPKI-validating networks drop the bogus route. This is the same mechanism for IPv4 and IPv6, but it only works if the prefix is genuinely yours to sign for.

That is where an isp6 allocation does security work before you configure a single firewall rule:

• RPKI ROAs, managed for you. Order a /48 or /44 through the isp6 portal and author and monitor ROAs from the subnet dashboard, including a valid ROA for every origin AS that announces the prefix, which is exactly what a multi-origin or multihomed setup needs (Multihoming IPv6 Without the Renumbering Tax).
• A clean, never-used allocation. isp6 draws your space fresh from its own RIPE NCC pool, so you start with no inherited blocklist reputation, no residue on threat feeds, and no other tenant's history attached to addresses your services now answer on.
• Reverse DNS delegated to you. PTR records, which mail systems, auditors and security tooling check, are delegated to your nameservers and managed from the same dashboard.
• The routing paperwork handled. inet6num, route6, ROA propagation monitoring, and the key pair that proves ownership to a cloud are part of the allocation, so the records the internet uses to agree a prefix is yours are correct from day one.

None of this replaces host and link security. It underpins it. The address space your firewalls, certificates, and reputation all hang on should be registered to you, with its routing integrity signed and verifiable. For the leadership view of why that matters, see Digital Sovereignty Starts at the Network Layer.

8. A practical checklist

• Encrypt explicitly: TLS 1.3 / QUIC for applications, SSH for management, IPsec (ESP) for tunnels. Never assume IPv6 encrypted anything for you.
• Default-deny stateful firewall at the border, with IPv6 policy in parity with IPv4 on dual-stack networks.
• Permit the required ICMPv6 per RFC 4890. Do not blanket-block it.
• Turn on RA-Guard and DHCPv6-Shield on every access switch carrying untrusted devices, with fragmentation/extension-header evasion hardening.
• Rate-limit Neighbor Discovery to blunt neighbour cache exhaustion.
• Ingress anti-spoofing (BCP 38), bogon filtering from the IANA registry, and scope filtering for link-local, ULA, and multicast.
• Filter at /64, forward extension headers by default in transit, and enforce first-fragment header-chain and no-overlap rules.
• Enable temporary + stable-opaque addresses, and set logging/retention to match your tracing and compliance needs.
• Don't trust "IPv4-only": monitor for and suppress rogue RAs on links meant to carry no IPv6.
• Sign a ROA for every origin AS announcing your prefix, and verify each shows valid in the isp6 dashboard.

9. Further Reading

Related isp6 articles

• Stop Thinking in IPv4: the IPv4-reflex corrections (ICMPv6, NAT, ULA, host scanning, IPsec-as-extension-header) that this guide deliberately does not repeat
• Multihoming IPv6 Without the Renumbering Tax: routing resilience and the multi-origin ROAs that Section 7 depends on
• Digital Sovereignty Starts at the Network Layer: the leadership case for owning the address space your security posture rests on
• Planning Your isp6 Allocation: the addressing hierarchy that makes per-host isolation and scope filtering cheap

External references

• book6: A Collaborative IPv6 Book: Brian E. Carpenter et al.; see the Security chapter (Layer 2 considerations, Filtering, Topology obfuscation) and Security operation, on which this article draws
• RFC 9099: Operational Security Considerations for IPv6 Networks: the authoritative operational-security overview and reference index
• RFC 4890: Recommendations for Filtering ICMPv6 Messages
• RFC 6105: IPv6 Router Advertisement Guard · RFC 7610: DHCPv6-Shield
• RFC 6583: Operational Neighbor Discovery Problems (NCE)
• RFC 9288: Filtering of IPv6 Packets Containing Extension Headers at Transit Routers
• RFC 7123: Security Implications of IPv6 on IPv4 Networks
• RFC 8981: Temporary Address Extensions for SLAAC · RFC 7217: Stable, Opaque Interface Identifiers

This document is provided for informational purposes. Protocol specifications and cloud provider behaviour are subject to change. Consult the linked RFCs and vendor documentation for authoritative, up-to-date information before making architectural decisions.