[alfons_foobar]

NAT is a crutch to circumvent the problem of "there are not enough addresses for each device".

I _assume_ you are referring to a default deny inbound firewall (so that devices are not reachable from the outside), but these are very different, completely orthogonal concerns (and independent of the IP version in use).

[djha-skin]

Everyone I've talked to with this opinion are typically mobile devs thinking about cell phones. Ipv6 works great there, but NATs are often used in corporate networks for isolation and in particular obfuscation. You can't tell what's behind a NAT by inspecting traffic coming from inside it like you can with no NAT networks. Some of the networks I administrate are contractually obligated to be so isolated.

[alfons_foobar]

I am not a mobile dev :D

I am aware that NAT is often used in corporate networks, but it does not automatically make any more sense there - the isolation is achieved by the firewall, not by NAT.

NAT (address or port translation) and a firewall (allowing traffic from/to those addresses or ports) are orthogonal concepts.

You can do NAT on IPv6, if you so desire.

It _should_ make no difference whether any adversary knows "what's behind a NAT", because it is your firewalls job to block any unwanted traffic.

Relying on "nobody knows what is inside our network so it can't be attacked" is not a viable strategy.

[Plasmoid]

> I administrate are contractually obligated to be so isolated

Yeah, I've seen those contracts. They just reference a SeCuRiTy doc that's 20+ years old, and has never been re-evaluated. Things are secure because they follow the doc, not because they have actually evaluated the reasonable attack space.

I've fighting customers for years on their ideas of proper TLS usage and it's always the same thing. They've got a security doc that never changes and has never evaluated any of the trade-offs. Almost to the point that the people who wrote them choose things that increase downtime and KTLO work without helping security.

[kstrauser]

Ah-yup. The equivalent in my world is contracts that insist we make our employees rotate their passwords every 2 months or whatever, which was a popular (but still dumb) idea 20 years ago and is strongly recommended against today.

[icedchai]

Yep. I get real tired of adding a month and year to the same base password every time I need to rotate it.

[kstrauser]

On week one of my current job, I turned that off for the whole company. Here's the citation you can give your security department to show them why they're doing it wrong.

NIST Special Publication 800-63B, the July 2025 version, section 3.1.1.2, says:

"Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."

The previous version from June 2017, section 5.1.1.2, says:

"Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator."

So 9 years ago, NIST said to stop requiring that. Last year, they clarified that to say, no, really, freaking stop it. Any company still making people do that today is 9 years out of date, and 1 year out of compliance.

[thayne]

There isn't any reason you can't set up a NAT like that with ipv6.