I don't know your background, but I find that the people who feel that there's nothing wrong with IPv4 have never done any work with UPNP or NAT. For them it's always "just worked" and they don't recognise what pain has gone into trying to keep it working well despite our usage of it bordering abusive.

NAT is the devil.

If anyone replies to this with the myth that NAT is a security mechanism I will firmly, yet politely, point them to a network development course because they don't know what they're talking about and I'm sick of hearing it. It's not true, I will not entertain this falsehood anymore.

▲

yjftsjthsd-h 20 hours ago | parent | next [-]

I dunno, I've manually set up NAT (down to the sysctls and iptables) and it's... fine. There's a small learning curve, but it's small. You should of course run a firewall which NAT is not; that's also simple and just basic hygiene.

▲

dijit 20 hours ago | parent [-]

Well, if you've set it up then you're aware that you need conntrack;

Conntrack is not always your friend, and even when it is: it's adding a lot of overhead.

https://www.tigera.io/blog/when-linux-conntrack-is-no-longer...

▲

yjftsjthsd-h 20 hours ago | parent [-]

Well yes, a stateful NAT is stateful. But as that article notes:

> For most workloads, there’s plenty of headroom in the table and this will never be an issue.

And yes, if you're doing thousands of connections per second then you should evaluate things more carefully for performance, but again... That's rather a lot.

▲

dijit 19 hours ago | parent [-]

It's interesting that you'd think that.

Connection table of a single IP is as high (by default) as 16,383[0].

I've hit this limit personally, and due to limitations in stateful firewalling we had to move to stateless filters inside our network equipment instead.

[0]: https://learn.microsoft.com/en-us/troubleshoot/windows-clien...

▲

yjftsjthsd-h 18 hours ago | parent [-]

It's interesting that I agree with the article that you linked?

I'm not contesting that it's completely possible to hit the limits in play, but 16k connections (per IP) is high enough that I don't think that's a common problem, even in public-facing web services. Granted, I suspect the services I've run professionally all dealt with it by making it the problem of a load balancer in front of the application and internal network, but... you probably have that anyways, so I'm still not seeing the problem.

▲

dijit 18 hours ago | parent [-]

it’s interesting because I think youve internalised the constraint and built mechanisms around it rather than engaging directly with it, subconsciously.

	▲	yjftsjthsd-h 17 hours ago \| parent [-]
		I'm not sure why that would be interesting either, but no, it's not a constraint I've ever hit so I doubt that I'd bother avoiding it, subconsciously or otherwise.

▲

wolvoleo 20 hours ago | parent | prev [-]

I do work with NAT, but the stuff I use does hole-punching pretty transparently. I run 2 VPSes to facilitate this. I don't use UPNP, I have it explicitly disabled everywhere (too much malware that tries to leverage it)

And yes I know that NAT has the same effect as a "deny all inbound" on IPv6. Which is something I would set there too if I did use IPv6 so I'd still have to do hole-punching anyway.