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.

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.