The lack of NAT represents the removal of an issue. The fact that you already understand NAT does not reduce the actual, real complexity that it is introducing.
I don't agree with this. First, most users don't know or care about security. So neither is more desirable for them. But also, on its merits NAT isn't more desirable. It provides zero security that is not provided by a simple default deny inbound rule on a firewall. And on top of that, it introduces additional complexity that even a non-technical user has to contend with sometimes (port forwarding).
NAT is not and never has been a security mechanism. We need to stop trying to shoehorn it in to a role it isn't meant for.
My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. With v6, I'd instead be double-checking that my router firewall is doing its job, e.g. https://community.verizon.com/t5/Fios-Internet-and-High-Spee... . Even if the router turns out to be WAI, I shouldn't have to question that!
Only because your router also has a properly configured stateful firewall for ipv4 as part of its NAT implementation. I have a Mikrotik CCR2004 at home, I can enable SNAT without appropriate firewall rules and have any other customer of my ISP on the same subnet send packets towards the WAN interface of my router and have it happily forward them onto my internal network.
NAT is implemented using a stateful firewall, but the mere presence of it does not mean the firewall is configured to reject unestablished connections from outside. IPv6 just exposes such poor configurations more readily.
> IPv6 just exposes such poor configurations more readily.
Yes, that's the exact dealbreaker for me and many corp environments.
Yeah, it does in many (most) cases. That's precisely why my firewall rules on my own router look like this:
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
DST-ADDRESS GATEWAY DISTANCE
DAd 0.0.0.0/0 1.1.1.1 1
DAc 1.1.1.0/24 wan1 0
DAc 192.168.0.0/24 lan1 0
> Yes, that's the exact dealbreaker for me and many corp environments.
My point remains, NAT is not a security measure - any corporate environment who thinks they are protected merely because they have NAT enabled is fooling themselves. The exact same set of firewall rules I need to properly secure IPv4 traffic are the same ones I need for IPv6 traffic; the only reason I haven't bothered to copy/paste them is because my ISP in 2023 still does not hand me an IPv6 allocation.
Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that.
Yes, you shouldn't rely on NAT alone, rather the router should have a firewall. Usually it does, but not always. When that fails, at least it's still pretty hard to exploit. How often does this kind of attack occur?
Yes, you understand the problem correctly. The fact that there's no legitimate reason to do it is precisely why routers have a default set of firewall rules to prevent it. Hell, as long as you control enough of the network to be able to route such a packet to the WAN interface of your router it doesn't even have to be on the same network segment - so compromise within your ISP's network would open you up to attack if you just assumed NAT alone without a proper stateful firewall would save you.
> How often does this kind of attack occur?
Due to needing to be on the same layer 2 segment or having control elsewhere of the network this would very much be a targeted attack. But one any enterprise should care about, and why the assumption that NAT alone is what protects you is dangerous. NAT just does source/destination (ip, port) rewriting, that's it.
???
Firewalls generally have inside and outside: default-deny any new connections from the outside and you're done. This is how all CPE gears ships out of the box.
> Especially when one of the other goals of ipv6 is to enable p2p applications, which might lead to permissive defaults.
For this you need hole punching, with on CPE gear is done with UPnP and/or PCP, the exact same protocols that are used with IPv4 NAT. (But of course applications also have to futz around with TURN/ICE/STUN if there's NAT.)
> No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports.
When I was still with a residential ISP that did IPv6 this was the exact same with all of my home devices behind my ten+ year old Asus.
Further, because you only have one public IPv4 address, someone can scan just that address to see which ports are forwarded. People regularly scan the entire IPv4 address space: 2^32 addresses is not a difficult task.
With IPv6, they'd have to know the IPv6 address of your service that you had opened to the public. If you hadn't advertised the address publicly, an Internet rando is not going to find it: good luck remotely scanning a single /64 (never mind a /60 or /56 that many ISPs hand out).