> This is a response to what appears to be a complaint that IPv6 is not treated as a first class citizen by some providers, not literally that it's hard.

Last time I've checked, some telecoms such as Vodafone didn't even supported IPv6 yet.

telecoms that deal with consumers have at best 0 (zero) incentive to deploy ipv6 unless there's regulatory pressure.

b2b telecoms as a consequence also have at best zero incentive since if the consumer doesn't have ipv6, businesses don't need or want ipv6.

the solution here, which will inevitably strike a nerve with some, is to have a regulatory mandate for ipv6. a soft version would start with 'government networks must run exclusively on ipv6, this applies to any and all contractors, including govclouds' and work upwards from there. I understand such policies were in place or at least planned; OTOH in the current political climate it'll be sort of a miracle if the existing ipv4 networks keep working.

Change at tier one telecoms providers tends to be glacial. It follows hardware upgrade cycles that take ages to plan and implement.

I spent a decade writing element management systems. An element is a network device - switch, router, ROADM, etc. Often you give the customer kit & software and they spend a couple of years assessing it. This software would be installed on secure out of band networks with no route to the internet. 10/8 would have been adequate for the lifetime of the hardware currently in service - 200G stuff. However, that's not how things played out.

When I started working on EMS software IPv6 support was a requirement but it was just a box ticking exercise. No one was actually going to use it. A decade later IPv6 HAD to work for northbound and southbound traffic, on an internal network. Otherwise, no sale. IPv6 is being used in anger in telecoms. I have no idea how long that will take to filter to in band networks.

> telecoms that deal with consumers have at best 0 (zero) incentive to deploy ipv6 unless there's regulatory pressure.

I don't think this is true. The IPv4 address exhaustion is still a problem and it's getting worse, and telecoms which also provide internet services need to allocate addresses to their clients. With the 5G rollout these telecoms need to make room for new devices, and that's not feasible with IPv4.

I was under the impression that cell carriers famously went all in on v6 because it saves them money?

Yes that don't have to allocate an IPv4 address for each customer or deploy ugly solutions like CGNAT. They simply cooperate with phone OS makers (Apple and Google) to make sure the OS and the apps work in an IPv6-only environment. Apple then forces app developers to make their app work in an IPv6+NAT64+DNS64 environment.

> telecoms that deal with consumers have at best 0 (zero) incentive to deploy ipv6 unless there's regulatory pressure.

Not entirely true. 10/8 is only so big, so the management of addresses very much has a nonzero opex cost.

And on top of that there's capex on "carrier grade NAT".

For the biggest providers 10/8 is not even big enough for their production environment. And then they acquire some some company that (obviously) also uses 10/8.

No, there's definitely incentive there. Just… not enough.

240/4 is usually used when 10/8 isn't enough.

Do you have data on that? I've heard rumors, but never seen it actually done.

It was never a viable option for the Internet (million or billions of devices would never support it, and anyway it'd only buy us like 3 months), but in theory it should work better in the (more, but not entirely) controlled environment of a large prod environment.

I know of several massive setups that when running out of 10/8 evaluated 240/4 but deemed it less feasible, riskier, and definitely more work, than to "just" move to IPv6. Sorry, can't namedrop them, since I don't want to doxx myself. I've never seen 240/4 actually chosen.

We use them in AWS as IPv6 hasn't been feasible, though its become better in the last 1-2 years. AWS uses it internally, likely other big providers probably also do. If you can get away with IPv6 only, ie not constrained by provider/device, its likely worth going that direction instead.

Works fine in Linux, doesn't really work on Windows and some BSDs.

https://blog.benjojo.co.uk/post/class-e-addresses-in-the-rea...

240/4 is multicast range, and mobile devices WILL wreak havoc in that range (though it's not impossible to simply drop all such traffic at ingress). I usually see service providers using 172.16/12 instead.

224/4 is multicast. AWS uses it, we use it in AWS, as do others. Works fine with Linux, Windows not so much, afaik android and osx are fine with it.

They're using it internally. It's probably for the best that the last place they test it on is their customers.

"Hard" for many is "unfamiliar." IPv4 plus NAT and all that ugliness is the devil we know.

I'm also convinced that the length of IPv6 addresses and the difficulty in typing them is a major reason for lack of adoption. Very seemingly small UX annoyances can have a large effect.

> I'm also convinced that the length of IPv6 addresses and the difficulty in typing them is a major reason for lack of adoption. Very seemingly small UX annoyances can have a large effect.

I've been convinced of this since around 2000. Every network utility dealing with IPv4 had... dotted quad addresses. You could remember them, you could read them, you could speak them to someone else. Brainwise, we can remember 3-5 things - segments, digits, etc. Remembering more is harder for the average person.

Having the 6 be literally dotted sextant(?) - 5.73.192.168.0.4 for example - would have been much much much easier to transition in to, and would have given us 64k x 4 billion addresses. Yes, it's not the near infinity we have with IPv6, where apparently every molecule in the universe can have multiple IP addresses or whatever the max number is. But it would have been much much easier to transition. 27 years later we're not transitioned from ipv4, and we've got another 27 years of dotted quad baked in to daily usage everywhere.

That would have required exactly as much work to transition, plus require computers to get good at 48-bit math. ("Why are the top 2 bytes always 0xFF?" "I don't know, grandson, but I'm sure it seemed like a great idea before Y248.")

I'd imagine many countries would claim a top spot or two, and transition all canadian addresses to, say, 7.0.0.0.0.0. Big companies would probably get some of their own. Legacy/default stuff would have leading 0.0, sure, but... so what?

No, it wouldn't have taken 'exactly as much work to transition'. See another reply. In 2024, I'm still reading about BGP/routing table issues, and hardware having problems keeping up with IPv6 networking - it's just too large. How was this supposed to work in 1999?

A smaller stepped transition from 4 billion addresses to... 64k of those would have been an easier transition step, and the ease - mental, UI, training, testing, security, etc would have given everyone involved the confidence and positive feedback to tackle a next stage to IPv6 (eventually).

I think you’re exactly right on this. Further , difficulty in remembering or visualizing IPv6 addresses I think makes it more difficult to understand how it works (vs learning how v4 really works) and thus weaker adoption

You have merely re-invented IPv6 but with a 48-bit address space. In your universe you would still have to run dual-stack with IPv4 indefinitely.

They didn't invent SLAAC, so no that wasn't a reinvention of IPv6.

But even if they had the counter argument to "128 bit addresses are too long, 48 bit would have been better" is obviously not "that's the same thing just with 48 bit addresses!"

Prefix every IP with 'missing' info with 0.0.

Part of this would just be transitory, but... would take up far less space. Even as late as last year, I'm reading stories about BGP issues and slowdowns because routing tables are too large/many for the hardware. In 2024. How on earth was this expected to work on hardware from 1999?

Those routing tables are badly made. An IPv6 route takes twice as much memory as an IPv4 route, and there are a lot less than half as many IPv6 routes.

https://blog.apnic.net/wp-content/uploads/2023/01/Figure-1-%...

https://blog.apnic.net/wp-content/uploads/2023/01/Figure-14-...

there is something called an "IPv4-compatible IPv6 address" and it's exactly the scheme you suggest: the first 96 bits are zero. It doesn't help deal with the billions of devices that only handle a 32-bit address space, however. What do you suggest we do with them? _They_ are the long tail that keeps us in the dual stack world.

Yes, though in hex.

Maybe a long time ago, but just about everything I've used recently supports mDNS for LAN hostnames. If I add a computer named "foo" to the LAN, it's almost certain I can run "ping foo" on another computer 3 seconds later.

that's not mDNS that's just dhcp+dns and it's something ipv6 actually breaks, which is part of the problem. DHCPv6 is optional, so local devices don't necessarily ever register their hostname nor do they necessarily ever consider your local DNS server.

>that's not mDNS that's just dhcp+dns

Actually mDNS does exactly what they said just fine. You’re confusing it with the ability of a DHCP server to make updates in DNS on behalf of clients. There is more than one way to skin the cat. Both achieve the same affect, just differently.

> nor do they necessarily ever consider your local DNS server.

Hardcoded DNS servers are just as equally a thing with IPv4.

> Hardcoded DNS servers are just as equally a thing with IPv4.

Of course, but they aren't the baseline expectation like it is with ipv6 since ipv6 baseline assumption is SLAAC. And SLAAC is terrible. If you control all the devices on the network, like a cloud install, you can just pretend SLAAC doesn't exist and live in a much better world.

If it's a home network then you're stuck expecting at least some usage of SLAAC. And you're better off just not supporting ipv6 at all at that point

> they aren't the baseline expectation like it is with ipv6

Why not? Are you saying your computer doesn't need to know the IP address of any dns server in order to be useful?

What do you mean when you say that SLAAC is terrible? Especially when you control all the devices on the network, you are in full control of what SLAAC manages for you. Also, SLAAC is the only way to use the IPv6 Privacy Extensions.

That's right. I'm specifically talking about mDNS, not DHCP+DNS. It works out of the box nearly all the time that I've tried it.

mDNS would work just fine but the given command ('ping foo') wouldn't be using mDNS. That's just standard name resolution. `ping foo.local` would potentially use mDNS if you have a ping that does such a thing, but that's restricted to `.local` specifically.

Rather, most routers add DHCP hostname requests to the local DNS routes. That doesn't require mDNS, nor would you want to replace it with mDNS as mDNS is more limited & flakier.

My resolved in its default configuration will try appending .local and search via mDNS if no results are found via the DHCP provided server. I believe macOS does the same.

Ping foo on my machine results in foo.local being successfully pinged. Your mileage may vary.

> would potentially use mDNS if you have a ping that does such a thing

It's not a feature of ping, it's a feature of the name resolution setup on your machine (nsswitch and/or resolved on Linux).

> Rather, most routers add DHCP hostname requests to the local DNS routes

What do you mean?

You don't need DHCPv6 to auto register hosts in DNS. You just configure the DNS server to register based on neighbor discovery.

Things like RA and NDP would clue hosts into the local DNS server as well. You don't need DHCPv6 to advertise a local DNS server.

> I'm also convinced that the length of IPv6 addresses and the difficulty in typing them is a major reason for lack of adoption.

Possibly, but I think it's also that some aspects of IPv6 are just badly designed, and subsequent updates only fixed some of the issues.

SLAAC, for example, is godawful stupid. And while DHCPv6 exists to fix some of that, critical aspects of the protocol, like prefix delegation, are manually configured. This is beyond idiotic and makes things like subnets massively more difficult than they have any right to be.

SLAAC and PD combine to create the worst sin of all - flakiness. It's hard to figure out why IPv6 isn't working because everything is telling you it is (it "auto configured" a valid IP despite not having any actual route to anywhere else, so helpful! /s). If IPv6 was literally just "IPv4 but 128-bit addresses instead of 32-bit ones" it almost certainly would have been adopted en masse by now. But it isn't, it made things more fragile and harder to configure for no goddamn reason.

And of course you then have ISPs doing silly stuff, like my ISP only gives me a /64 so I literally can't use IPv6 on my network since I want VLAN isolation. 18446744073709551615 possible addresses are given to me yet dividing that up into 3-5 subnets is completely impossible. Fucking stupid protocol.

Why is delegating smaller addresses impossible? Kernels will totally take /72, /88, /96, etc. without issue... or at least any OS I've ever used will.

It breaks SLAAC so routers won't do it. Or if they do, it's non-standard and they won't easily let you do it. /64 is the smallest PD by spec ( RFC 5375 )

It may brake SLAAC. OpenBSD implements autoconfiguration for non /64 prefixes (IIRC)

You can do it with DHCPv6, but of course there's Android. Android aside, it works fine.

The core of V6 -- longer IPs -- is great. SLAAC and /64 being the smallest need to be deprecated. It's asinine.

Really absolutely everything but longer IPs should be deprecated and was a mistake.

> You can do it with DHCPv6, but of course there's Android. Android aside, it works fine.

are you sure? what about homepods, Chromecasts, Hue bridges, kasa smart plugs, esphome, etc etc etc...?

How much are you willing to bet your home network on Android being the final user of SLAAC? And how much time do you want to invest in figuring that out in the first place?

You can have IPv6. Though you can't have SLAAC.

Although https://www.rfc-editor.org/rfc/rfc7217 doesn't require a /64 or shorter prefix for its variant of address auto-configuration, for example Linux doesn't allow otherwise.

Honestly we probably need IPv7 to roll back most of the things from IPv6 and be closer to IPv4x4. IPv6 is now older than IPv4 was at the time IPv6 was invented.

Heck, I would have probably simply added an Options flag for "long address" to support longer addresses. With the first part of the address being the IPv4 address of some ISP backbone router and the next 3 words being a device address on the network (with the all-0 device address reserved for the router itself). Then you don't even need to upgrade most of the routers beyond configuring them to accept packets with that option set. It would have been so simple and elegant and we would have probably upgraded most of the world by 2001.

>IPv6 is now older than IPv4 was at the time IPv6 was invented.

The quantity of existing deployments that need to change is much larger for v6 than it was for v4. The problem with deploying v6 isn't that it's too different from v4, the problem is that it's different at all. Your v7 will have the same problems.

IPv6 looks silly until you learn about the problems it actually solves, and then realize it would be completely impossible to incrementally upgrade IPv4 to get there.

> "Hard" for many is "unfamiliar." IPv4 plus NAT and all that ugliness is the devil we know.

Indeed. I meant that if evaluating the two de novo, IPv4+NAT is harder.

I agree that NAT sucks but IPv6 having two different ways of assigning addresses (SLAAC and DHCPv6) with one of them being practically optional (Android doesn't do DHCPv6 for address assignment) does make IPv6 harder than it needs to be.

Then there are crimes against network protocols like NAT66 that are borderline necessary in some situations because terrible ISPs have decided to dynamically alter IPv6 prefixes so they can charge extra for a static prefix.

I still think NAT makes everything harder than it should be, but I get why some people struggle with IPv6 if their ISP is particularly terrible.

I don't generally care for Android but I'm glad they chose not to support DHCPv6. It's a nice forcing function to make network admins actually learn how SLAAC works and why they should almost certainly prefer it to DHCP.

The sin of IPv6 was trying to do too much. They should have extended address sizes, period. SLAAC and most of the other extensions were a mistake.

Everyone should bomb Android bug reports with complaints about lack of DHCPv6 until they fix it. Then people can de-facto deprecate SLAAC. AFAIK Android is the only major offender here.

Some corporate networks already don't do SLAAC if they don't need Android to work on them.

In that case ISPs would give you a single /126 and ask more money for extra devices, eg. /124 for a "family plan".

I don't disagree, but I would point out that one upside to every LAN being behind NAT, is that those LANs are also inherently firewalled.

This is dependent on the firewall features of the NAT router, but at least its something, and the router provides one centralized point of protection from interent traffic.

In IPv6 typically every machine on a LAN is directly connected to the internet with a public IP address. Every one of those machines now needs a full strength internet firewall.

This complicates some intra-LAN communications, and removes the feature of having the LAN be a walled garden, mostly isolated from the interent.

Or you can implement a firewall on your gateway device with a default drop policy for inbound traffic. Essentially the same behavior as NAT in terms of unsolicited (usually malicious) inbound traffic, but without the downsides of one-to-many NAT.

Which is, coincidentally, exactly how it works if your LAN is made up of devices with publicly-routable IPv4 addresses as well, which happens in business/academic/military networks all the time.

But most users are not business academic military.

They just want to watch some reels.

And? Most consumer routers also implement a stateful firewall with deny-by-default inbound policy. My point is that NAT isn't a security feature, and that firewalls in edge network equipment is table stakes these days.

>Most consumer routers also implement a stateful firewall with deny-by-default inbound policy.

No they don't.

Most ISP boxes only implement the bare minimum of functions to make sure that youtube is available to the users. Which includes NAT, because otherwise youtube does not work, and does not include anything else.

Well, that's news to me. I don't use consumer routers myself, but I know lots of folks who do. Now, I won't say that I go investigating their home networks, but IPv6 is rather prevalent among the discount ISPs where I live, and I know of at least two coworkers who have an IPv6 firewall by default with their router.

Anyway, NAT is costlier than a firewall. It uses more memory, it requires rewriting packets on-the-fly, and typically if you're using embedded Linux (I'll assume that the vast majority of consumer devices for this are) then you're already using `iptables` or `nftables` to get NAT functionality. It is comparatively to set default inbound/forward drop policies.

But yes, I should have said "in my experience," since it's true that I only know the networking equipment of a few people in a small country with limited IPv6 rollout (my ISP does not provide it).

NAT is awesome. It automatically forces users to have a stateful border firewall that makes incoming connections impossible.

NAT does not, in any way, "force" the use of a firewall. They're entirely separate concepts.

NAT _is_ a firewall. And it provides the same level of security as pretty much all of the "firewalls" marketed as such.

No... it's not? It's simply a widely-used technique to rewrite the addresses of IP packets that transit a router. It inherently makes no policy decisions on which packets should and shouldn't flow over and above what a router does anyway.

I’ve never seen one without the other, so while technically correct, not useful to debate.

shrug at work we use NAT to let two different networks with overlapping addresses talk to each other all the time. No firewalls there.

NAT wasn't invented for the home-broadband user, you know.

But I'm at least glad we've cleared up the myth that NAT provides any security benefit when, in fact, it's the often deployed accompanying stateful firewall that's actually providing this.

We out-number companies, perhaps by an order of magnitude.

Not by allocated IP address count.

It's useful to correct this misunderstanding, because people often take "I've always seen NAT come with firewalling" to mean "firewalls are impossible without NAT".

You quite regularly see people pop up in these threads arguing something like, oh, I dunno, "In IPv6 typically every machine on a LAN is directly connected to the internet with a public IP address. Every one of those machines now needs a full strength internet firewall.", as if this is somehow a problem with IPv6 rather than a problem with their own understanding. It's hard enough to get people to deploy v6 as it is without them mistakenly believing that a lack of NAT means their router can't provide firewalling either.

It automatically prevents the outside world from being able to access the inside network. Which is the main function of most of the firewalls.

Pretty much everything else in a firewall in the modern world is just useless feature creep.

It doesn't do that. It rewrites the source address that outbound connections appear to come from; it doesn't implement any kind of access control.

Take two networks that are identical, except one is doing NAT and one isn't, and test them. Every connection that works on the without-NAT network will also work on the with-NAT network. The only difference you'll find is that some outbound connections which didn't work on the former will work on the latter.

Some would argue that "every connection that used to work still works, and some connections that didn't work before do now work" is kind of the opposite of a firewall.

> It doesn't do that. It rewrites the source address that outbound connections appear to come from; it doesn't implement any kind of access control.

It absolutely does. There is no way with NAT to connect from the outside network to the inside ("but what if the attacker is directly attached to the next hop blahblahblah"). That's all that firewalls need to do, everything else is useless noise in the current world.

> Take two networks that are identical, except one is doing NAT and one isn't, and test them.

Here's my IP: 192.168.80.36. Feel free to attack me. Go on. The public IPv4 of my router is 76.191.126.81. I even opened a port 8871 for you with a static page with a Bitcoin wallet worth $1000, you just need to get to it.

You can't. There's no way to get to my computer without hacking the NAT server first.

That's why NAT _is_ a firewall, and a foolproof one at that. It's secure by default, unlike IPv6 firewalls that can fail open.

I've just remembered the firewall alignment chart, which asserts a view of the world that an excavator is a firewall.

https://sh.itjust.works/pictrs/image/421c9549-83ee-487a-9fa0...

It's possible to get to your computer without hacking the "NAT server", but I'm not in a position to do it. There's no point setting up a demonstration if you don't make it possible for me to actually do the demonstration!

When I set one up for you (back here: https://news.ycombinator.com/item?id=39173556) I gave you the access needed to actually do the test (...but you either missed that message or opted to ignore it, so you never tried it). You need to either move your network to routed IPs or give me a tunnel to the upstream network of your router first.

Not doing either of those doesn't make you right. NAT is still not acting as a firewall here. I'm just not in a position to take advantage of that, due to your use of RFC1918 addresses on the LAN side.

> It's possible to get to your computer without hacking the "NAT server", but I'm not in a position to do it.

Nope. Even with a misconfigured box that forwards the traffic from WAN to LAN, you need to be in the direct contact with the NAT server (an OpenWRT box). And that's the point, you are _not_, as is pretty much everybody else in the world, outside of people who have keys to my house and my ISP.

In practice, this provides all the practical security you need from a firewall.

> I'm just not in a position to take advantage of that, due to your use of RFC1918 addresses on the LAN side.

Well, duh. That's the whole point of NAT (when used typically). You don't get to access my internal network, you simply can't do that physically.

No, you don't need to be in direct contact with the NATing router. That's kind of the entire point we're trying to making here.

All you need to be able to do is send a packet that ends up at your router with the dest IP set to one of your LAN machines. This only requires being directly attached to your router if you're using RFC1918 on the LAN; if you're using a properly routed prefix then it can be done from anywhere.

> Even with a misconfigured box that forwards the traffic from WAN to LAN

Forwarding traffic from WAN to LAN isn't a misconfiguration. Your router needs to do that for TCP to work, or get replies to outbound UDP.

> No, you don't need to be in direct contact with the NATing router.

Or control the internal network of my ISP.

> All you need to be able to do is send a packet that ends up at your router with the dest IP set to one of your LAN machines.

Which you can't do.

> if you're using a properly routed prefix then it can be done from anywhere.

If I had a publically routed /24, then I wouldn't be using NAT in the first place. Which is the case in point: NAT _is_ a firewall.

> Forwarding traffic from WAN to LAN isn't a misconfiguration

Sigh. I mean allowing the SYN packets to be forwarded from WAN to LAN.

You can do it from anywhere on the Internet, you don't need to control the ISP's network or anything. If your NATing router receives a packet with the dest IP set to a LAN machine, it forwards it to said LAN machine regardless of where that packet came from, unless blocked by a firewall.

Whether or not someone can get that packet to your router in the first place is a separate question. If you're using RFC1918 then yeah, they'd need access to your direct upstream network. But the point I've been trying to make is that NAT doesn't influence the answer to this question: whether or not you do NAT has no influence on the behavior of any of the routers upstream of you.

NAT has no influence on whether these packets can reach your router or not, or on whether your router will forward them if they do arrive. That's why it's not a firewall: because it's not actually doing any firewalling.

> If I had a publically routed /24, then I wouldn't be using NAT in the first place. Which is the case in point: NAT _is_ a firewall.

It's not possible to go from "I wouldn't be using NAT if I had a routed /24" to "NAT's a firewall".

If you had a routed /24 then you might not use NAT, but that says nothing about whether NAT works as a firewall or not. The relevant part isn't "would I still be using NAT if the situation was different?", it's "does NAT block inbound packets?". Since it doesn't, it's not.

> Sigh. I mean allowing the SYN packets to be forwarded from WAN to LAN.

Well, yeah, allowing those is generally a misconfiguration... in the firewall. The routing part of the router doesn't pay any attention to TCP flags, just IP addresses.

NAT is by definition not a firewall. And while it provides security, it provides no more security than having a firewall, while making various scenarios worse. NAT is not a good solution for security.

It forces the use of some system that statefully tracks packets and makes routing decisions based on that information. Such a system will be capable of firewalling unless you go out of your way to make it not.

No, your thinking of a stateful IPv4 home style NAT. There's also stateless subnet mapping.

There are some stateless things that are also called NAT, sure, but that's not what we're talking about here. (Fairly obviously, since a stateless mapping doesn't and can't save addresses).

But this feels tautological. It's been reduced to "If you want to use NAT with features that only a firewall gives you, then that forces you to use a firewall".

I suspect when people talk about "NAT" in the context of a residential connection, what they actually mean is a "default-deny firewall with connection tracking".

Feel free to replace "NAT" with "the kind of NAT that permits you to share an address between multiple devices" if you feel the need to be pointlessly pedantic about it. The point is that any device that allows sharing a single IP between multiple devices will necessarily implement connection tracking, and will therefore be capable of functioning as a firewall.

(Are you going to point out that statelessly blocking a fixed IP range used to be called "firewalling" so a device without connection tracking can still technically be a "firewall" next?)

Pretty much any system that's capable of handling IP traffic is also capable of firewalling. Not sure what that's got to do with address rewriting though.

> Pretty much any system that's capable of handling IP traffic is also capable of firewalling.

A system that can't track connection state, or doesn't have enough capacity to do so at line rate, can't meaningfully firewall. When the norm for home equipment is ISPs sending it out for "free", they absolutely send out the cheapest stuff they can get away with, and in the pre-smartphone era that meant "modems" that would just provide a straight PPPoA connection with no firewalling.

In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whatever) it does block incoming connections, only allowing replies to internally-originated traffic, and to do that it tracks the state of all traffic.

Is that a real, full firewall? Heck no, I'm equally worried about what my systems leak than outside threats, and it does nothing for that.

but aren't we nitpicking a little here? veering on the "technically correct, worst kind of correct".

> In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whatever) it does block incoming connections, only allowing replies to internally-originated traffic, and to do that it tracks the state of all traffic.

Yes, but that's because it's co-located with a stateful firewall, sharing the same connection tracking state. Without that firewall, if a device on the WAN side sends to your router a packet with destination address on the LAN side, your router will route that packet to the LAN, even though it's not a reply to anything sent from the LAN to the WAN. That is: it's a misconception that port mapping NAT blocks incoming connections; port mapping NAT only affects outgoing connections and replies to them.

> if a device on the WAN side sends to your router a packet with destination address on the LAN side

This can happen only if the device is directly attached to the NAT server. Basically, only your ISP can do that.

Most NAT servers by default also prohibit this kind of routing (because why even allow it?!?), but even the most misconfigured bad NAT server is still vulnerable only if you control the ISP, in practice.

> Is that a real, full firewall? Heck no, I'm equally worried about what my systems leak than outside threats, and it does nothing for that.

But it is. Even a "full" firewall can't do anything against something on one of the inner host leaking into the outside. Most of the traffic is encrypted, even DNS. So the firewall can't operate on much more than the destination address to decide if a connection should be allowed.

If you want more security, you need to secure individual endpoints.

I second this, it forces security by default (at least keeping devices from being directly exposed)