christian clark

NAT isn't security

2026-09-03T00:00:00Z

The most common reaction to enabling any form of IPv6 on your network is turning it on, seeing your device has a routable IP, and then ignoring it from there. A small voice probably asks if everything on your network is now accessible by anyone from the outside.

But.. it didn't, understanding why takes a bit of unlearning with the idioisms of IPv4. The thing that protected you from that was never really for that.

We've been here before?

A globally routable address on a home computer isn't new territory. It's how the internet started for most of (however, not me, I'm a zoomer).

In the dial-up days, your modem spoke PPP over the phone line to the ISP, and the public address on the other end of that call belonged to your computer.

Not to a router, because there wasn't one. A different address on each call, sure, but real and reachable just as if your computer was a router. The funniest part of that is that Microsoft didn't enable the firewall by default until Windows XP SP2 in 2004.

Early broadband kept a similar arrangement with the modem bridging straight into the PC's network card but the connection never hung up (PPPoE instead of straight PPP). The combination public (and predictable) addressing, no filtering, and always-on are what allowed the Blaster worm to destroy the internet in 2003.

The incident seems to be a big part of why people think NAT is a security-first protocol.

Home routers went mainstream in a similar period bought mostly so another computer can share the same broadband service. Primarily people were buying them so multiple devices could share the internet, but an unintentional effect was a deny inbound ruleset by default. NAT collected the credit for this and now over 20 years later people are nervous to allow devices to route straight to the internet.

The difference this time is that there is a stateful firewall in front of it.

NAT wasn't a security feature

As I said above, NAT isn't a security feature. It was a stop gap to allow RIR's to hold onto some more addresses and to slow the bleed of IPv4 assignments.

The world (IANA) globally ran out of more IPv4 addresses on 31 January 2011. APNIC (my home RIR) was the first one to run out. LACNIC, ARIN, and then AFRINIC were the first to run out, with RIPE running out nearly 8 years later.

On the technical level, think of NAT as a recepionist. When you make a connection outside, they note it down and then put it through to the phone on your desk. But when a random person rings through asking for nobody in particular, they can't connect them anywhere.

That was the protection NAT gave. Unsolicited traffic gets dropped because the router had nowhere to send it. It feels like a firewall, but it was a side effect of emergent bookkeeping.

The real security was hiding in plain sight the whole time, the connection table. It tracks the connections that were started from the inside and only lets maching return traffic come back. This is known as stateful filtering and it's the thing actually doing the grunt work for IPv6. It's keeping the table but throwing away the receptionist.

Routable but not reachable!?

Bit of a shift in thinking here. An addres means a packet can find it's way to your router; your firewall will still decide whether it gets through. Your house has a street address that means anyone in the world can write on an envelope, and that has never once meant a stranger can come through your door. Addressability and access mean different things, NAT bundled them together very tightly for over 20 years (RFC 2663).

A sane router should ship with defaults that look like this:

Allow anything outbound
Allow inbound traffic that belongs to a connection a device made on the inside (most call this 'established' and 'related')
Drop all non-solicited

Read it again. Sound like NAT? It's what the connection tracking was doing, without rewriting all of your packets. If someone on the internet sends through a packet to your laptop, all it's going to do is reach your router, see nothing in the state table, and it'll get dropped. Just as it would on NAT.

With IPv4, you ask 'which ports do I need to forward and to where?', under IPv6 you instead need to be asking 'what traffic in, and from where', same way you would for your internal traffic.

Nothing gets translated, which also means that the traffic that leaves your edge is the same packet that reaches the other end.

ICMPv6 isn't the same as ICMP for IPv4

A big habbit of network engineers and system administrators is to block ICMP from the edge because it feels like a recon tool. Putting aside the technical issues I'll talk to soon, there's no issues with this in IPv6. With the amount of addresses possible in even a /64 prefix, it isn't worth worrying about.

Protocol wise, it will break quite a few things. To start, ARP isn't a thing in IPv6, it was replaced with NDP, this is essentially an ICMPv6 message.

ICMPv6 Message Types ^[1]

Router Solicitation (`RS, ICMPv6 type 133`)

Sent by hosts to request immediate Router Advertisements from routers. Destination: FF02::2 (all-routers multicast).

Router Advertisement (`RA, ICMPv6 type 134`)

Sent by routers periodically or in response to RS. Contains prefixes, MTU, and configuration flags (M/O bits for DHCPv6). Destination: FF02::1 (all-nodes multicast).

Neighbor Solicitation (`NS, ICMPv6 type 135`)

Used for IPv6-to-MAC resolution, reachability checks, and Duplicate Address Detection (DAD). Sent to a solicited-node multicast address derived from the target IPv6.

Neighbor Advertisement (`NA, ICMPv6 type 136`)

Response to NS or to announce link-layer changes. Usually unicast to the requester.

Redirect (`ICMPv6 type 137`)

Sent by routers to inform hosts of a better next-hop for a destination.

It's still a net gain

An explicit firewall is auditable in a way NAT never could be. Want to know what's exposed on your network, read the inbound rules and that is your entire answer. Under IPv4, that has been smeared across port forwarding, helper modules, and whatever your Xbox 360 decided to open up back in 2011 via UPnP. We've let vulnerable devices punch holes in the firewall for far too long using NAT and we called it normal.

IPv6 gives you back the internet the way it was supposed to be, with a proper size that is designed for everyone to have multiple individual devices..

Sources

Cisco Systems. ICMPv6 Packet Types and Codes. 2005. www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/22974-icmpv6codes.html ↩

My IPv6 Learnings

2026-08-31T00:00:00Z

IPv6 Without the Headache

IPv6 has a reputation problem. People see an address like 2001:db8:4f2a:1::1 and quietly go back to NAT and port forwarding, because at least that pain is familiar. Which is a shame, since the mental model behind IPv6 is actually simpler than IPv4 once someone explains it without drowning you in RFC numbers.

So let's do that. No packet header diagrams, no history lesson. Just the parts you need to actually run it at home or in a small network. (The RFCs are cited along the way for anyone who wants to go deeper, but you don't need to read them.)

The address is split in the middle

An IPv6 address is 128 bits long, and the simplest way is to think of it in two halves. Take this with a grain of salt as it isn't entirely accurate but helps simplify it to someone who has only worked with IPv4.

The first half (in the case of a typical ISP) belongs to them. It's the network part, it's saying that this traffic belongs to (for example, Neptune Internet), you don't pick it, and you don't really need to think about it.

The second half is yours, it identifies the individual devices and networks on your side of the connection.

Where exactly that line sits depends on how large the prefix your provider assigns to you (RFC 6177 covers how end sites should be sized), and this is where the slashed numbers come in. When your provider delegates you a prefix, the number after the slash tells you how many bits they control. This is essentially identical to how IPv4 works, but you are working with four times as many bits (128-bit vs 32-bit).

A /48 means that the ISP owns the first 48 bits and then you get the remaining 80. It's a huge allocation that is typically reserved for business or power user connections. Assigning according to RFC 4291's one-/64-per-subnet convention, you get 65,536 individual networks that can be accessed externally without any NAT.
A /56 is the typical handout to a residential service. You get 8 bits to subnet with, which works out to 256 networks (same RFC as above). Far more than any house would need, especially considering they may end up using the flat network /64 that the ISP delegates to their home router, anyway. This prefix is almost always big enough for most small-medium offices.

The smaller the number after the slash, the more of the address that you control. A service with a /48 controls more space than one with a /56, even though 48 is a smaller number.

Compare that to IPv4, where your ISP will typically only give you one public address and you cram your entire network behind NAT. In IPv6, you get 18,446,744,073,709,551,616 addresses (2^64) in a single /64. Every device gets a real address just for themselves. NAT just isn't in the equation.

Subnetting and You - Just SLAAC off

Here's where IPv6 gets so much easier than IPv4: every normal subnet should be a /64. Your LAN is a /64, your guest WiFi is a /64, your IoT network is a /64. As a general rule of thumb, everything is a /64. (RFC 7421 is the long version of why the 64-bit boundary exists, if you're curious.)

That's it. No calculating whether a /27 gives you enough hosts, no wondering whether an address is free. Each /64 holds 18 quintillion addresses, so you'll never outgrow one and need to resize it.

Say your ISP gives you 2001:db8:4f00::/56. That's 256 subnets, and you can number them by changing a single byte:

2001:db8:4f00:0::/64 for the main LAN
2001:db8:4f00:1::/64 for guests
2001:db8:4f00:2::/64 for the lab

Pick a number between 00 and ff, drop it in the slot, done.

Why /64 specifically? Because devices expect it. SLAAC, the mechanism that lets hosts configure their own addresses automatically, only works on a /64 (RFC 4862). Unless you're numbering point-to-point links between routers (RFC 6164 blesses /127s for those), don't fight it.

Advertising your router to the network

In IPv4, a device will join the network knowing nothing and screams into the void asking for a DHCP lease and waits for a server to assign it an address.

IPv6 flips the direction of this and instead the router advertises to everyone on the segment (Router Advertisements, part of Neighbor Discovery, RFC 4861) and it says three useful things.

I exist, I'm your way out to the internet and this networks' prefix is 2001:db8:4f00:0::/64. A device joining the network can also ask for one without waiting.

From a single RA, a fresh device onto the network will almost immediately learn the gateway and network it has joined onto. No lease history is kept, it just announces itself onto the network.

RAs also carry flags that tell devices how to get an address, which is where the next two pieces come together.

SLAAC: devices name themselves?

SLAAC stands for Stateless Address Autoconfiguration (RFC 4862) and it's exactly what it sounds like. Once a device/node/endpoint sees the RA come through, and learns it's prefix, it generates it's second half of the address all by itself.

total time elapsed: about a second

'Stateless' is the main word here. Nothing on the network, aside from maybe the firewall itself keeps a log of traffic traversing the network keeps a list of what had which address. There isn't a lease database, no DHCP server to babysit, or even a potential pool to exhaust. The router announces the prefix and every device chooses it's address. Remember how I said before that a /64 can hold 18 quintillion addresses, that's why devices can just pick one at random with no real collision chance.

Modern operating systems also rotate these for privacy (temporary addresses, RFC 8981) so websites can't track a single device on an address for months. For a home network, SLAAC and RA is the whole story. You will likely never need to touch the rest.

What's the point in DHCPv6?

Devices picking their own address is a great default but can also be a horrific fit for some environments and situations. DHCPv6 (RFC 8415) exists for those.

Predictable addresses. Your printer, your NAS, your servers: things other machines connect to should have addresses you chose, not ones they invented.
An audit trail. In a corporate network, "which device had this address last Tuesday at 2pm" is a question you'll eventually need to answer. SLAAC can't tell you; a DHCPv6 lease log can.
Extra configuration. DHCPv6 can push options like DNS servers, NTP servers, and domain search lists. (RAs can carry DNS info too these days via RFC 8106, but support varies, and DHCPv6 handles the richer cases.)
Prefix delegation. This one's sneaky: DHCPv6 is usually how your router receives that /56 from your ISP in the first place, through a mechanism called DHCPv6-PD (part of RFC 8415, originally RFC 3633). So even a pure-SLAAC home network probably used DHCPv6 once, at the WAN edge, to get its prefix.

Definitions

Prefix - The network half of an address, the part your ISP (or you, when subnetting) controls. Written with a slash, like 2001:db8:4f00::/56.

Prefix length (/48, /56, /64...) - The number of bits locked in from the left. Smaller number, more space for you. Same idea as IPv4 CIDR notation, just on a 128-bit address.

/64 - The standard size for a single network segment in IPv6. Defined by the addressing architecture in RFC 4291, dissected at length in RFC 7421.

Interface Identifier (IID) - The second half of a /64 address, the 64 bits that identify one device on the segment. This is the part SLAAC generates.

RA (Router Advertisement) - The periodic announcement a router sends onto a segment: here's the gateway, here's the prefix, here's how to get an address. Part of Neighbor Discovery (RFC 4861).

NDP (Neighbor Discovery Protocol) - IPv6's replacement for ARP plus a bit more, covering router discovery, address resolution and duplicate detection. RFC 4861.

SLAAC (Stateless Address Autoconfiguration) - Devices building their own address from the prefix in an RA, with no server involved. RFC 4862.

Temporary/privacy addresses - Randomised, rotating SLAAC addresses so a device isn't trackable by one stable address forever. RFC 8981 (which replaced RFC 4941).

DHCPv6 - The stateful, server-assigned alternative to SLAAC. Central control, lease logs, extra options. RFC 8415.

DHCPv6-PD (Prefix Delegation) - The mechanism your router uses to request a whole prefix (like a /56) from the ISP, rather than a single address. Also RFC 8415, previously RFC 3633.

RDNSS - The RA option that carries DNS server info, so a pure-SLAAC network can still hand out resolvers. RFC 8106.

NAT (Network Address Translation) - The IPv4 workaround of hiding many private addresses behind one public one. Not needed in IPv6, where every device can hold a globally unique address.

2001:db8::/32 - The documentation prefix. Every example address in this post lives here on purpose; it's reserved so examples never collide with real networks. RFC 3849.