NAT does nothing? The NAT setup is the reason incoming connections don't reach devices on the LAN. I get that you can phrase this as NAT actually being the thing forwarding the packets, and on a home ipv4 router without NAT the incoming packets would just go nowhere, but everyone is talking about the realistic options of NAT vs device having own public IP addr.
I get that an ipv6 router can have a firewall with good defaults blocking incoming connections, emulating that aspect of a NAT.
With IPv6 instead of NAT deciding that port 2000 maps to 192.168.1.3 port 22, you have a firewall that may or not choose to route to xx:yy:zz or not, and to allow an incoming connection over port 22 to that host or not.
If you don't want to accept incoming connections to a given machine or network on IPv6 without NAT that's very easy to have.
IPv6 has so many addresses that the default is for /64 subnets to be the minimum network size, allowing devices to choose their addresses randomly within that range. If they do that, 2^64 is big enough that it's not practical to enumerate all devices on a given network. Attempting to do so would be a bandwidth DoS attack: attempting to ping 2^64 devices requires 2^64 * 64 bytes = 1024EiB, roughly equal to total global internet traffic per year.
Now, sometimes NAT is needed anyway: QubesOS supports IPv6 using NAT because it splits things up into many different VMs on one computer. But that's a pretty rare case.
EUI64 means that random space is effectively reduced to just 48-bits of real entropy, <40 bits if you start making assumptions about device vendors. For example maybe the attacker has a VMWare exploit: enumerating that OUI (00:50:56) leaves them with just 24-bits of address space to scan, a measly 1GiB of traffic.
It's security through obscurity at best, i.e: not security. You shouldn't be relying on size of address space to protect you from anything. An IDS/IPS that alerts on abnormal ICMP behavior will be useful whether an attack is 1GiB of traffic in size or 1024EiB of traffic in size. (Also you don't even need automated scanning to find some juicy targets: I've seen a lot of routers on the edge of a prefix configured at ::1/64 and ::2/64 for instance.)
Most systems aren't using EUI64. Within a subnet, they're using random addresses per RFC 4941. So, if I've got a /64 IPv6 allocation (which I do right now), that means I've got 64 bits of randomness to play with. Right now, my macOS system has four publicly-routable IPv6 IPs, all of which were randomly-generated, and which regularly regenerate.
I did not have to do anything to get this. My macOS system has IPv6 set to Automatic. My home ASUS router picks up the /64 allocation from my ISP, passes the info on to things on the LAN, and acts as a firewall for IPv6 (while continuing to act as a NAT for IPv4).
I don't see what's wrong with the outside knowing your local IP addresses. But I absolutely wouldn't want EUI64 encoding my device vendors in the addrs.
To be fair that info is already available w/ port sequence analysis, the same machine will pick from the same set of ephemeral ports for outgoing connections. I'd say the time for vanity privacy arguments is over, I'm all-in for team globally routable addresses w/ firewalls just saying "yes" or "no" to connections instead of routers guessing at port mappings.
My network would look like it has dozens of machines, since everything is periodically rotating its IP randomly around the subnet, and often have multiple IP addresses at once with privacy extensions…
Your machines could change their IPs for every second of every day and you wouldn't come close to exhausting your /64 subnet for the next billion years.
Won't this break your TCP connections? NAT won't, because it's connection-aware by its nature. And you also get a new "address"(=port) on each new connection, regardless of any setting.
> Unconfigured/not activated firewalls usually fail reachable
Local firewalls on devices, maybe, but network firewalls generally are default-deny on untrusted interfaces, and between 0 and 1 interfaces are trusted by default.
Back in 2007 Apple's Airport Extreme Base Station shipped with a firmware that defaulted to allowing all IPv6 traffic, which was quickly pointed out in the tech media and fixed in a patch a few months later. A few of the garbage pile combo modem/router devices distributed by ISPs have had similar issues over the years as well. That's not normal behavior though, when it's observed it's rightfully considered a security flaw and tends to get the kind of attention vendors don't want.
If you know of a mainstream device that would "fail reachable" as you claim here, name and shame please.
> without explicit port forwarding or exposed hosts, NATs fail unreachable.
I work in VoIP and can say from plenty of direct experience this is not true. In the modern work from home era I've had to deal with a lot of the aforementioned garbage pile consumer devices and a recurring issue with some of our clients who had older phones is that their users' home routers did the laziest NAT possible and literally just opened a two way hole on port 5060 (SIP) so as long as the phone was communicating with our server and keeping the pinhole open *ANY* other traffic that hit port 5060 was also sent to the phone, which meant they got all kinds of "phantom calls" from bots looking for unprotected SIP relays.
Newer phones generally have an option to only accept SIP messages from trusted servers, but older ones sometimes don't so when combined with badly implemented NAT that happens.
And yea, obviously that's a consequence of a particularly bad NAT implementation, but your complaint is about an issue that would only occur in a particularly bad IPv6 implementation.
It takes effort to make NAT that bad. Something jank like UPnP has to map the port, and even that requires action on the device's part. I don't quite understand your SIP example; how does the router know which IP is the phone's?
Bad IPv6 is as simple as not having a firewall or default-allowing it like AirPort did. If Apple can make that mistake, a lot of random manufacturers can too. I can see the whole NATless firewall setup but wouldn't use it for a very long time, to let things settle.
One could argue that if e.g. FTP is not working behind the NAT then the NAT is misconfigured. NAT needs to aware of certain protocols so that it can modify the application layer data.
Of course, if the protocol added workaround for NAT and NAT is modifying that application layer data then it can cause another set of issues.
IP networking was designed with separate layers, NAT breaks this by having to span multiple layers.
Generally NAT gateways only support TCP/UDP, other protocols are simply not supported, which has basically stifled protocol innovation (eg look at SCTP, it has some neat features but is hardly ever used because of NAT).
It gets even worse with higher level protocols like FTP. There is such a thing as FTPS (FTP over SSL) but it's rarely used because if you encrypt the traffic then the NAT gateway can't inspect and rewrite the traffic.
The same is true of IPSEC/ESP, if you have an encrypted TCP packet encapsulated with ESP the NAT gateway can't keep track of which internal host to forward it to because it can't see the source and destination ports.
A normal router does not need to care about anything further up the stack than IP. A firewall does, but even when a firewall doesn't explicitly support a particular protocol you could write a rule allowing any traffic with a particular protocol number between specific hosts is allowed, and anything else denied.
The amount of firewall config I have to write to let an incoming connection cross from WAN to LAN is the same regardless of whether it goes to a NAT'd IPv4 address or to an IPv6 address.
