IPv6 is not insecure because it lacks a NAT • Hacker News Board

Re: IPv6 is not insecure because it lacks a NAT

#471

Post by tsimionescu » Wed, Jan 21, 2026, 8:32 PM UTC

Dagger2 wrote: post #434

mannyv wrote: post #163

Earlier quoted context omitted.

You are wrong because you are being overly pedantic. NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side. A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate). Your definition of security is too narrow. And saying that NAT is broken a…

> NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side. No... it doesn't do that. NAT edits your packets so that your outbound connections appear to come from your router's IP. If you set up a port forward rule, then it edits matching inbound connections so they appear to be coming to a different destination IP. Notice how no part of that descr…

So what do you think will happen with a packet that arrives at the router with destination IP set to the router's IP, and destination port set to some port for which there is no port forward rule (and no currently open TCP connection)? Will it reach some machine on the network, or will it get dropped/NACKed?

Re: IPv6 is not insecure because it lacks a NAT

#472

Post by rnhmjoj » Wed, Jan 21, 2026, 8:33 PM UTC

InfamousRece wrote: post #450

rnhmjoj wrote: post #312

Earlier quoted context omitted.

Ok, I'll bite: why do you say that IPv6 lacking NAT (which is not true by the way) would be annoying? We can finally get rid of an ugly workaround from 30 years ago that broke one core principle of the Internet (end-to-end connectivity) and a ton of protocols that required even uglier hacks (FTP and SIP ALGs, TURN/STUN, etc.) to barely work. Why would this be annoying?

At my previous place IPv6 was useable (I was getting /60 prefix rather than /64 I’m getting now) but the prefix was changing often - several times per day. This was annoying because every prefix change all addresses of my devices changed too. So in practice I always used private IPv4 addresses to connect to them. A NAT would solve this issue.

Well, delegated IPv6 prefixes are supposed[1] to be static or somewhat persistent, but some ISPs do this, yes. This is most likely a practice carried over from IPv4 where there is a small pool of addresses. Fortunately in my experience it's not too common: most ISPs that deployed IPv6 did it the right way.

Anyway, to get persistent addresses you can set up a ULA prefix (the equivalent of RFC 1918 addresses) and a simple prefix translation[3]. This is a form of NAT, but unlike the usual IPv4 NAT (actually NAPT) it doesn't deal with ports, so it's slightly less annoying problematic. There also are a few more techniques, like using mDNS and writing firewall rules that match the suffix of the client addresses, but not many CPE allows for this.

[1]: https://www.ripe.net/publications/docs/ripe-690/#53-why-pers...

[2]: https://en.wikipedia.org/wiki/Unique_local_address

[3]: https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6

Re: IPv6 is not insecure because it lacks a NAT

#473

Post by Denatonium » Wed, Jan 21, 2026, 8:33 PM UTC

fdr wrote: post #160

For those of you with this handy technology, the mobile phone, in the United States: you have an IPv6 address without NAT. Some of you even exist on a network using 464XLAT to tunnel IPv4 in IPV6, because it's a pure IPV6 network (T-Mobile). These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons. This is all to underscore the author's point: NAT may necessitate s…

In the case of T-Mobile, unsolicited inbound IPv6 connections are blocked, but direct P2P is still possible. I successfully established a WireGuard tunnel over IPv6 between 2 phones. With IPv6, since the internal addresses and ports and the same end-to-end, all that is needed is a dynamic DNS service; STUN isn't necessary. I did need to set a persistent keepalive of 25 seconds on both sides of the tunnel to keep the firewall holes open.

Interestingly, Verizon Wireless blocks connections to other Verizon Wireless IPv6 addresses. T-Mobile-to-T-Mobile connections work, Verizon-to-T-Mobile connections work, but Verizon-to-Verizon connections do not work. Given the way Verizon's network has stagnated while T-Mobile's network has been rapidly improving, it may be time to move away from Verizon.

Slightly off-topic, but if you have a modern Google Pixel phone, Google includes "free" VPN service (which probably collects/sells your data). This service uses Endpoint-Independent filtering, so if you send an outbound packet with the source port you want to map, regardless of the destination IP/port, you can effectively receive unsolicited inbound connections from any host on the internet that contacts your IP:port, so long as you send a periodic keepalive packet from the source port you are using to anywhere.

Re: IPv6 is not insecure because it lacks a NAT

#474

Post by tsimionescu » Wed, Jan 21, 2026, 8:35 PM UTC

Dagger2 wrote: post #459

fc417fc802 wrote: post #446

Earlier quoted context omitted.

If you don't initiate a corresponding outbound connection first then any attempt at an inbound connection will be dropped (unless you have a DMZ configured ofc). The router literally can't forward the traffic because it doesn't know where it should go.

It might be dropped by a firewall, but not by NAT. IP packets have a "destination IP" field in the header. The router knows where to forward packets because it reads that IP out of the header.

Sure, but the Internet will not route packets going to RFC1918 addresses. So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped. And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused.

This is all behavior that happens even with no firewall whatsoever.

Re: IPv6 is not insecure because it lacks a NAT

#475

Post by Denatonium » Wed, Jan 21, 2026, 8:38 PM UTC

lunar_rover wrote: post #234

dannyobrien wrote: post #230

Earlier quoted context omitted.

What would be the obvious reasons? (I'm not being flippant here -- I'm genuinely interested in what arguments people have to not allow servers on that network)

The most common use case for mobile data servers is probably pwned cheap/old phones forming DDoS swarms. Pure P2P over internet is very rare on mobile, no sense not blocking ingress from the perspective of ISPs.

I kind of doubt this, as the rapidly changing nature of mobile IP addresses would mean that a periodic outbound connection would still be necessary to keep the attack up-to-date on the compromised devices current IP address. At that point, you may as well have the compromised device periodically poll an attacker-controlled server for instructions rather than jump through a bunch of hoops by getting things to work over inbound connections.

Re: IPv6 is not insecure because it lacks a NAT

#476

Post by Dagger2 » Wed, Jan 21, 2026, 8:39 PM UTC

sedawkgrep wrote: post #337

bandrami wrote: post #282

Earlier quoted context omitted.

The ISP is the primary threat vector here (do you trust yours? Along with their contractors and anyone who might have compromised them?). But like I said route-poisoning attacks do exist.

yeah but the likelihood of this is incredibly remote. It would shock me if ISPs didn't have alarms going off if RFC1918 space was suddenly routable within their BGP table. Not to mention the return packet would be NAT'd so the attacker would have to deal with that complication.

The return packet wouldn't be NATed, because stateful NAT tracks connections and only applies NAT to packets that belong to outbound connections.

Arguing over how likely this is is missing the point. If it can happen at all when you're running NAT, then it should be clear that NAT isn't providing security.

Re: IPv6 is not insecure because it lacks a NAT

#477

Post by tsimionescu » Wed, Jan 21, 2026, 8:43 PM UTC

nobody9999 wrote: post #363

mannyv wrote: post #163

Earlier quoted context omitted.

You are wrong because you are being overly pedantic. NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side. A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate). Your definition of security is too narrow. And saying that NAT is broken a…

>NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side. No. NAT enables internal, non-routable (cf. rfc1918[0]) actors on the inside to access external resources on the Internet. Generally, that's done via NAT masquerade[1] (one-to-many NAT), but can also be done with one-to-one NAT. >A firewall is not required for NAT to work, although many fir…

> No. It isn't. And if you enable NAT without firewall rules, it will happily expose your internal network to external actors. In fact, that's the whole point of NAT.

How exactly would a regular NAT implementation, such as s consumer router's NAT, remove security compared to a direct connection? Assuming there is no port forwarding configured, the NAT will drop (or NACK) any packets addressed to the router's IP on any port that doesn't correspond to a currently open connection.

Since the machines behind the NAT have RFC1918 addresses, remote actors will not be able to send a packet to them, other than by sending packets to the router's IP.

So, overall, a NAT box with no firewall rules configured still acts like a stateful firewall for remote attackers. It's true that attackers that have access to the WAN port of the router, such as someone infecting your ISP, can still send traffic directly to the RFC1918 addresses behind the router, and the router would deliver them (whereas with a firewall, those would also get dropped). So a firewall is still preferable, but the difference in security is actually quite low.

> In fact, not using IPv4 NAT is enormously more secure than using IPv4 NAT, assuming you're using RFC1918 addresses internally. Primarily because non-NATted RFC1918 addresses won't be forwarded by routers on the Internet (CGNAT notwithstanding).

This statement makes no sense. If you are not using NAT of some kind, and your machines only have RFC1918 addresses, then your machines can't access the Internet at all. Now, sure, that is quite secure - but you can get the exact same security by disconnecting the WAN port of the router, with the exact same effects - so this is quite irrelevant to the use-cases being discussed.

Re: IPv6 is not insecure because it lacks a NAT

#478

Post by paulddraper » Wed, Jan 21, 2026, 8:53 PM UTC

deng wrote: post #294

Before you engage in discussions, may I suggest to look into RFC 4787, especially section 5 about filtering behaviors of NAT: https://datatracker.ietf.org/doc/html/rfc4787#section-5 Several things can be correct at the same time: * NAT is not a firewall * NAT can still filter traffic (and practically always does) * NAT can hence still provide security features * The real world often does not care about original defin…

1. NAT is not firewall.

2. "NAT" is changing addresses. PAT (port address) is the most common type.

3. "Firewall" is dropping packets.

4. The same component can (and often does) do address translation and filtering.

5. A NAT precludes some security features: "NAT reduces the number of options for providing security." [1]

6. A NAT provides some degree of anonymity.

7. IPv6 can have (but does not require) NAT.

[1] https://www.rfc-editor.org/rfc/rfc1631.html

Re: IPv6 is not insecure because it lacks a NAT

#479

Post by Dagger2 » Wed, Jan 21, 2026, 8:53 PM UTC

aboardRat4 wrote: post #374

bigstrat2003 wrote: post #177

Earlier quoted context omitted.

This is a terrible argument. First, NAT doesn't provide the security behavior users want. The firewall on their router is doing that, not the address translation. Second, that firewall is on by default, blocking inbound traffic by default, so why on earth would you conjecture that router manufacturers will suddenly stop doing that if NAT isn't on by default? Third, it's not remotely likely that a user will misconfigu…

>This is a terrible argument. First, NAT doesn't provide the security behavior users want. Try breaking into my machine. Login:pass are administrator:pa$$w0rd, external ip 58.19.1.129, internal ip is 192.168.1.124, the system is Windows xp, and firewall is turned off on both the computer and the box the ISP gave me.

Sure, okay. You're using RFC1918 on the internal network, so I'll need to connect to your router's WAN interface to do it, but after that it's just a matter of doing `ip route add 192.168.1.0/24 via 58.19.1.129` and then connecting to whatever I want.

How do you want to get me onto your WAN interface? Unless you happen to live near me it'd probably be easiest if you give me a tunnel. Alternately, if you change the internal network to a properly-routed non-RFC1918 range, I can demonstrate this over the Internet too.

I offered to do this once before, and the person I was talking to replied with "so, you're refusing to do it then" and blocked me. So just for the avoidance of doubt: I'm offering to do this, but if you're going to provide the test environment, you're responsible for making sure I can actually reach the test environment. Otherwise you aren't going to learn anything about NAT.

Re: IPv6 is not insecure because it lacks a NAT

#480

Post by Dagger2 » Wed, Jan 21, 2026, 9:07 PM UTC

tsimionescu wrote: post #469

Dagger2 wrote: post #429

Earlier quoted context omitted.

NAT: iptables -A POSTROUTING -o wan0 -j MASQUERADE Firewall: iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m state --state INVALID -j DROP iptables -A FORWARD -i lan0 -j ACCEPT iptables -A FORWARD -j REJECT --reject-with icmp-admin-prohibited If you omit the first line, you get firewalling without NAT. If you omit the second set of lines, you get NAT without firewalling. This…

And if you have only the first line, what will happen if someone sends a request to the NAT's external IP on some random port?

Whichever machine has the NAT's external IP assigned to it will accept or refuse the connection, depending on whether they have a server running on that port or not.