IPv6 Security in Dual-Stack Networks

Link-Local Addressing

One of the first things that changed how I looked at IPv6 was link-local addressing because an IPv6-enabled interface normally has an address in:

fe80::/10

without me manually assigning a globally routable address or depending on stateful DHCPv6.

A link-local address might look something like:

fe80::a8c4:12ff:fe35:8821

and while that address cannot simply be routed across the Internet, it is still extremely important to how IPv6 works locally.

Neighbor Discovery depends heavily on link-local communication, routers commonly advertise themselves using link-local addresses, and two hosts on the same Layer 2 segment can communicate using link-local IPv6 even if nobody intentionally deployed globally routable IPv6 on that segment.

That is why the statement:

can be misleading.

A question I think is more useful is:

Is IPv6 enabled on the interfaces?

Because if it is, some IPv6 behavior is already present whether I built a complete routed IPv6 deployment or not.

Neighbor Discovery and ICMPv6

IPv4 uses ARP to resolve an IPv4 address to a Layer 2 address on the local network.

Conceptually it is asking:

IPv6 does not use ARP. Neighbor Discovery Protocol handles that type of function using ICMPv6, including Neighbor Solicitation and Neighbor Advertisement messages.

That is one reason I think treating ICMPv6 as simply “IPv6 ping” is a bad mental model. ICMPv6 is involved in core protocol behavior including Neighbor Discovery, Router Discovery, Path MTU Discovery, Duplicate Address Detection, and error reporting.

Bringing an old habit such as:

into IPv6 without understanding which ICMPv6 messages are actually required can create some extremely strange failures.

The better goal is not to blindly allow every ICMPv6 message either. It is to understand which message types the network requires, where they should be accepted, and where they should not originate.

Router Advertisements and SLAAC

IPv6 hosts can learn a surprising amount about the local network through Router Advertisements.

A router can advertise information such as the network prefix, whether it should be used as a default router, prefix lifetimes, and flags that influence whether hosts use SLAAC or DHCPv6 for additional configuration.

For example, a host could receive information for:

2001:db8:100:30::/64

and construct its own usable address instead of waiting for a DHCP server to hand it one exact host address.

Conceptually the process looks something like:

Router Advertisement
        |
        v
Host learns /64 prefix
        |
        v
Host forms an address
        |
        v
IPv6 interface becomes usable

That has an operational side effect I think is easy to overlook: a DHCP lease table is not automatically a complete IPv6 asset inventory.

Depending on the addressing method, devices can have valid IPv6 addresses that were not handed out by a stateful DHCPv6 server at all.

DHCPv6 and Prefix Delegation

DHCPv6 exists, but I do not think of it as DHCPv4 with longer addresses because an IPv6 network can combine several different mechanisms.

A network might use:

SLAAC only
SLAAC with stateless DHCPv6
Stateful DHCPv6
Different combinations depending on the segment

Then there is DHCPv6 Prefix Delegation, which becomes particularly useful in routed environments.

Instead of an upstream provider assigning one address to a router, it can delegate an entire prefix. For example:

ISP
 |
 | delegates 2001:db8:1234:5600::/56
 |
 v
EDGE ROUTER

The router can then divide that /56 into /64 networks:

2001:db8:1234:5601::/64   Users
2001:db8:1234:5602::/64   Servers
2001:db8:1234:5603::/64   IoT
2001:db8:1234:5604::/64   Management

That design is clean, but it also means the full prefix assigned to internal networks can depend on what the upstream provider delegates. If the provider changes the delegated prefix, hardcoding full IPv6 addresses or prefixes throughout a firewall configuration can become painful very quickly.

That is where address groups, prefix-aware objects, and a firewall platform's actual IPv6 behavior start mattering quite a bit.

Stateful Filtering Without NAT

IPv4 NAT gets criticized a lot because NAT itself is not really a security control, and I agree with that.

At the same time, NAT helped create a mental shortcut that people got used to:

Internal address = private
External address = public

IPv6 breaks that shortcut because a host can have a globally routable IPv6 address while still being protected from unsolicited inbound connections by a stateful firewall.

For example:

LAN -> WAN
Allow established/expected outbound communication

WAN -> LAN
Block unsolicited inbound communication

That does not require address translation.

A globally routable address means the address can participate in global routing. It does not mean every system on the Internet should be allowed to initiate a connection to it.

Routing and permission are separate things.

Once I stopped relying on the existence of NAT as a visual security boundary, IPv6 actually made the firewall model a little clearer to me: the firewall policy protects the host, while address translation does not need to pretend to be the security control.

Dual-Stack Firewall Policy

This is where dual-stack networks can get messy.

Suppose I intentionally create IPv4 policy such as:

USER -> MANAGEMENT     DENY
USER -> SERVER:443     ALLOW
USER -> INTERNET       ALLOW

Everything looks good, then IPv6 gets enabled and the IPv6 rule set has a broader default or simply does not have an equivalent deny.

Now I can end up with something like:

IPv4 USER -> MANAGEMENT    DENY
IPv6 USER -> MANAGEMENT    ALLOW

The user network is segmented over IPv4 and not actually segmented over IPv6.

DNS can make this even less obvious. A hostname might return:

A     192.0.2.10
AAAA  2001:db8:30::10

The client can attempt IPv6, and if that connection succeeds the application simply works. Nobody using the application necessarily notices that the equivalent IPv4 connection would have been blocked.

That is why I think a dual-stack policy test should be treated as two related tests:

POLICY TEST
├── IPv4
└── IPv6

rather than one generic:

POLICY TEST
└── IP

The security intent may be the same, but the routing and filtering behavior can be different.

Address-Family Selection

Modern operating systems try pretty hard to hide connectivity problems from users, which is usually a good thing.

Happy Eyeballs, described in RFC 8305, allows clients to work with IPv6 and IPv4 in a way that reduces the delay caused when one address family has a broken or slower path.

From a usability standpoint that is great.

From a troubleshooting standpoint, it means the fact that:

https://app.example.com

loaded successfully does not necessarily tell me which network path actually worked.

Maybe IPv6 succeeded.

Maybe IPv6 failed and IPv4 won.

Maybe IPv4 is blocked exactly the way I intended while IPv6 is succeeding over a policy path I forgot existed.

When I am specifically validating dual-stack policy, I would rather remove that ambiguity by forcing the address family:

curl -4 https://app.example.com
curl -6 https://app.example.com

and checking the DNS records separately:

dig A app.example.com
dig AAAA app.example.com

Now I know what I actually tested instead of relying on whatever path the client happened to choose.

Security Monitoring and IPv6

Firewall policy is only one part of the problem because monitoring can quietly remain IPv4-centric even after the network becomes dual-stack.

I could build a monitoring environment around:

IPv4 firewall logs
IPv4 network objects
IPv4 threat feeds
IPv4 dashboards
IPv4 detection logic

and then have endpoints start communicating over IPv6.

Nothing necessarily broke on the network.

My visibility did.

A query written around something such as:

src_ip = 192.0.2.0/24

does not automatically describe the same host when that system communicates using:

2001:db8:1234:30::a42

One endpoint can have several identities that matter operationally:

IPv4 address
IPv6 global address
IPv6 link-local address
temporary IPv6 address
hostname
MAC address
user/account identity

That means security monitoring increasingly has to correlate the device instead of assuming one IP address is the device.

Temporary IPv6 Addresses

IPv6 privacy extensions make that identity problem even more interesting because a workstation can use temporary IPv6 addresses for outbound communication instead of presenting one stable interface-derived address forever.

That behavior is useful for reducing long-term tracking, but it can complicate firewall logs, incident investigation, host attribution, inventory, and SIEM correlation.

A richer identity model might need to consider:

address
+
hostname
+
DHCP/DNS information
+
switch or AP association
+
endpoint telemetry
+
user identity

instead of assuming:

To be fair, that assumption was already questionable in IPv4.

IPv6 just makes the weakness in that model much harder to ignore.

First-Hop Security

Router Advertisements also create a first-hop security problem because hosts on the local Layer 2 segment receive information that can influence their IPv6 routing behavior.

If an untrusted endpoint can start advertising itself as an IPv6 router, clients may accept routing information that I never intended them to receive.

That is one reason controls such as RA Guard exist on managed switches.

Conceptually:

UNTRUSTED ACCESS PORT
        |
        | rogue RA
        X
      SWITCH
     RA GUARD


TRUSTED ROUTER PORT
        |
        | legitimate RA
        v
      CLIENTS

The basic idea is similar to other first-hop protections: do not blindly trust infrastructure control messages coming from ports that should never be originating them.

This is also a reminder that not every IPv6 security control belongs on the edge firewall.

Some of them belong on the switch.

Layer 2 and Neighbor Discovery

It is easy to focus almost entirely on routing and firewalling once IPv6 is involved, but a lot of important IPv6 behavior happens locally before a packet ever reaches a central firewall.

Neighbor Discovery happens on the local segment.

Router Advertisements happen on the local segment.

Duplicate Address Detection happens on the local segment.

That means segmentation still needs to answer questions such as:

• Which devices share the VLAN?
• Which switchports are trusted?
• Which devices are allowed to advertise routing information?
• Can clients communicate directly with each other?
• What first-hop protections are enabled?
• What does wireless client isolation actually block?
• At which layer is each security control enforced?

IPv6 does not eliminate Layer 2 security problems.

It just gives some of them different protocols.

IPv6 Subnet Size

IPv4 trained a lot of us to think constantly about conserving address space.

We divide networks into:

/24
/25
/26
/27
/28

and try not to waste addresses.

Then IPv6 gives a normal LAN a /64, which contains an absurd number of addresses by IPv4 standards.

The immediate reaction can be:

Usually that is the wrong way to think about it.

IPv6 LAN design and several protocol behaviors are built around /64 prefixes. The enormous address space is intentional, and the goal is not to squeeze every possible endpoint into the smallest prefix the way we often did with IPv4.

A perfectly normal plan can look like:

Users       /64
Servers     /64
IoT         /64
Management  /64
Guest       /64
Cameras     /64

and feel ridiculously wasteful while still being exactly what the architecture expects.

That took me a little while to mentally accept because it goes against years of IPv4 subnetting habits.

Dual-Stack Validation

If I am validating a dual-stack network now, I want to inspect IPv6 directly rather than assuming it matches the IPv4 state.

Basic host checks can start with normal tools:

ip -6 addr
ip -6 route
ip -6 neigh
dig AAAA example.com
curl -6 https://example.com
traceroute6 example.com

Then I want the actual policy tests to reflect both protocols.

For example:

USER-VLAN -> MANAGEMENT-VLAN
IPv4 = BLOCK
IPv6 = BLOCK

USER-VLAN -> APPLICATION
IPv4 TCP/443 = ALLOW
IPv6 TCP/443 = ALLOW

GUEST -> INTERNAL
IPv4 = BLOCK
IPv6 = BLOCK

Same security intent.

Two actual observations.

And just like with IPv4, a timeout by itself does not automatically tell me which control caused the failure. If attribution matters, I still want target liveness, listener state, firewall counters or logs, packet captures, or another useful vantage point before I make a stronger claim than the evidence supports.

Operational Design

I think one of the worst ways to deploy IPv6 is basically:

Because IPv6 touches much more than the address field on a network interface.

It affects:

Addressing
Routing
DNS
Firewalling
Switching
Monitoring
Logging
Host identity
First-hop security
Troubleshooting
Incident response

That is a system.

Treating IPv6 as another checkbox on top of an IPv4 network is how the second path becomes something nobody really understands.

I would rather intentionally think through:

ADDRESSING
    |
ROUTING
    |
DNS
    |
POLICY
    |
MONITORING
    |
VALIDATION

for both address families, and then if IPv4 and IPv6 behave differently I know the difference was intentional instead of something I discovered six months later during an incident.

Conclusion

IPv6 is not difficult because the addresses are long.

Honestly the addresses are probably the easy part.

The bigger adjustment is that IPv6 removes or changes several assumptions people accumulated while working with IPv4 networks.

NAT is not the boundary.

DHCP is not necessarily the complete inventory.

ICMPv6 is not optional noise.

One host can have several valid addresses.

A globally routable address does not mean globally permitted access.

Router configuration can arrive dynamically.

Security tooling has to understand another address family.

And a dual-stack application can reach the same destination through two different routing and filtering paths.

That is why I do not really think of IPv6 as:

It is another network protocol operating beside IPv4 with its own addressing, discovery, routing, policy, and visibility requirements.

If I secure and validate only one address family in a dual-stack environment, I have not really validated the network I built.

I validated half of it.

Key Takeaways

References

• • Internet Engineering Task Force. RFC 8200: Internet Protocol, Version 6 (IPv6) Specification.
• • Internet Engineering Task Force. RFC 4861: Neighbor Discovery for IP version 6 (IPv6).
• • Internet Engineering Task Force. RFC 4862: IPv6 Stateless Address Autoconfiguration.
• • Internet Engineering Task Force. RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
• • Internet Engineering Task Force. RFC 8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency.
• • Internet Engineering Task Force. RFC 8981: Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6.
• • Internet Engineering Task Force. RFC 9099: Operational Security Considerations for IPv6 Networks.