> 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.
