so that's: source ip, dest ip, protocol, source port, dest port, connection state (say 16 bytes total)
doing NAT too is what, 3 more bytes per connection (8 bits for an offset into an IP table and 16 bits for the translated port)
I hear such takes all the time and its really frustrating; usually in threads regarding IPv6, incidentally it is usually programmers who think they understand everything about networks because they know how tcp operates.
> I hear such takes all the time and its really frustrating
maybe you'd be less frustrated if you understood what people were saying, because I didn't say that
AWS already do 1:1 NAT and there's additionally a stateful firewall, which necessitates connection state tracking
adding the extra few bytes to do port translation shouldn't vastly increase the memory required
> incidentally it is usually programmers who think they understand everything about networks because they know how tcp operates.
from someone who has written a commercial packet filter: in terms of complexity, TCP blows the preceding layers of the stack out of the water
Is that really conceptually so different from a stateful firewall allowing inbound packets only for established connections/flows?
"NATs are good because otherwise people wouldn't have any firewalls" is a tired take, yes, but I don't see the point being needlessly pedantic about the semantics of NAT vs. stateful firewalls when in this case, the effect is the same: No inbound packets without prior outbound packets (or a connection establishment for TCP).
