I feel like this is a silly narrowing of the problem for normal, retail users. My priority isn't masking "the number of addresses" or devices. My desire is to not have a persistent identifier to correlate all my traffic. The whole idea of temporary addresses fails at this because the network prefix becomes the correlation ID.

I'm not an IPv4 apologist though. Clearly the NAT/DHCP assignments from the ISP are essentially the same risk, with just one shallow layer of pseudo-obscurity. I'd rather have IPv6 and remind myself that my traffic is tagged with my customer ID, one way or another.

Unfortunately, I see no real hope that this will ever be mitigated. Incentives are not aligned for any ISP to actually help mask customer traffic. It seems that onion routing (i.e. Tor) is the best anyone has come up with, and I suspect that in today's world, this has become a net liability for a mundane, privacy-conscious user.

"If you enable" is doing ALL THE HEAVY LIFTING THERE.

Again, my point isn't about what is possible, but what is likely. -- which is MUCH MORE IMPORTANT for the real world.

If we'd started out in an IPv6 world, the defaults would have been "easy to discover unique addresses" and it's reasonable to think that would have made "pay per device" or other negatives that much easier.

Not every device can run its own firewall. IoT devices, NVR systems, etc should be cordoned off from the internet but typically cannot run their own firewall.

Most public wifi has client isolation enabled for this reason. Firewall or not, you can't communicate with other clients.

> You can have IPv6 firewalls emulate the behavior of NAT so it blocks unsolicited inbound traffic while allowing outbound traffic.

Are there any (consumer?) firewalls that do not do this? I know Asus do this (and have for years).

AIUI most 'enterprise' firewalls have a default deny shipped from the factory and you have to actively allow stuff.

Right, but if you’re messing around as a naive learner it’s easy to accidentally disable that or completely open up an IP or range due to a bad rule. It’s a lot harder to accidentally enable port forwarding on a NAT.

As someone who has done this while tired, it’s a lot easier to accidentally open extra ports to a publicly routable IP (or overbroad range of IPs) than it is to accidentally enable port forwarding or DMZ.

That article is making a narrower claim than you're implying. It argues that NAT is not a security mechanism by design and that some forms of NAT provide no protection, which is true.

It also explicitly acknowledges that NAT has side effects that resemble security mechanisms.

In typical deployments, those side effects mean internal hosts are not directly addressable from the public internet unless a mapping already exists. That reduces externally reachable attack surface.

So, the disagreement here is mostly semantic. NAT is not a security control in the design sense, but it does have security-relevant effects in practice.

I personally do consider NAT as part of a security strategy. It's sometimes nice to have.

Silliness of smart bulbs aside, I would hope the answer is how ipv6 is actually safe for this, not that you should just not use wifi.

A lot of people, even on HN, mistake "addressable" for "accessible".

Well, the disadvantage would be that it would be really difficult to do direct connections between devices.

I don't want VPNs between private ranges.

I don't want publically-routable IP addresses on anything.

This is not something I ever want any device on my network to do.

Is this solved by the device having between 1 and X randomly generated IPv6 addresses?

Some of my devices have 1, some 2, and some even more. Takes some precision out, at least.

Aren't your home addresses assigned by your local router?

The ISP still doesn't know how many devices are connected, because a lot of those devices are using randomized and rotating IPs for their outbound connections.

IPv6 can "leak" MAC addresses of connected devices "behind the firewall" if you don't have the privacy extensions / random addresses in use.

There are a number of footguns for privacy with IPv6 that you need to know enough to avoid.

I don't have CG Nat, I choose a proper ISP. Opening a hole in my ipv6 firewall or forwarding a port in in my ipv4 firewall is effectively the same thing, I define the policy (allow traffic arriving on $address on tcp/1234 to this server on vlan 12) and it goes live.

Away from home, like I am at the moment, I vpn all my traffic back home, to work, or to a mullvad endpoint. Neither the hotel wifi nor tethering off my phone gives me a working ipv6 address (anything other than an fe80::) anyway.

All my workflows work on ipv4 only. Some workflows (especially around the corporate laptop) don't work on ipv6 only - maybe that's a zscaler thing, maybe its a windows thing.

As such the only choice is ipv4 with ipv6 as a nice to have, or ipv4 only.

Personally I prefer the smaller attack surface of a single network protocol.

Sounds like ipv6 is a good solution for people who choose ISPs with CGNat. It doesn't matter to me if I vpn home via my ipv6 endpoint or my ipv4 endpoint, I expose a very minimal set of services.

I guess if I wanted to host more than 4 servers on the same port at home it would be handy, as my ISP will only allow me to have 4 public IPs without paying for more. I don't host anything other than my wireguard endpoint and some UDP forwards which I specific redirect to where I want to go (desktop, laptop, server) - another great feature of nat, but yes nat66 can do that too.

But where's the killer feature of ipv6. Is it just CGNat on poor ISPs?

> the common advice is to use a firewall rule that disallows incoming connections by default.

That's good advice! But firewall hole punching is also significantly easier (and guaranteed to work) compared to NAT hole punching. Address discovery is part of it, but there are various ways to implement a NAT (some inherently un-hole-punch-able) and only really one sane way to do a firewall.

> you'd need the average person to mess with their router configuration,

At least with IPv6, that firewall is likely to exist in the CPE, which sophisticated users can then ideally open ports in (or which can implement UPnP/NAT-PMP or whatever the current name for the "open this port now!!" protocol of the decade is); for CG-NAT, it's often outright impossible.

Hole-punching tricks work fine. They don't work at all of both users are behind IPv4 NAT/CGNAT.

UPnP has covered a huge percentage of use cases that actual users care about, and those who it doesn't cover are often able to do their own customization.