IPv4 was evolved, it is now a 48 bit address, signified by IP:PORT.

There are many things wrong with this analogy, but the most important ones seem to be:

- NAT gateways are inherently stateful (per connection) and IP networks are stateless (per host, disregarding routing information). So even if you only look at the individual connection level, disregarding the host/connection layering violation, the analogy breaks.

- NAT gateways don't actually route/translate by (IP, port) as you imply, but rather by (source IP, source port, destination IP, destination port), as otherwise there simply would not be enough ports in many cases.

▲

iso1631 an hour ago | parent [-]

> IP networks are stateless

Until you have stateful firewall, which any modern end network is going to have

> NAT gateways don't actually route/translate by (IP, port) as you imply, but rather by (source IP, source port, destination IP, destination port), as otherwise there simply would not be enough ports in many cases.

If 192.168.0.1 and 0.2 both hide behind 2.2.2.2 and talk to 1.1.1.1:80 then they'll get private source IPs and source ports hidden behind different public source ports.

Unless your application requires the source port to not be changed, or indeed embeds the IP address in higher layers (active mode ftp, sip, generally things that have terrible security implications), it's not really a problem until you get to 50k concurrent connections per public ipv4 address.

In practice NAT isn't a problem. Most people complaining about NAT are actually complaining about stateful firewalls.

	▲	lxgr an hour ago \| parent [-]
		> Until you have stateful firewall, which any modern end network is going to have Yes, but it's importantly still a choice. > not really a problem until you get to 50k concurrent connections per public ipv4 address. So it is in fact a big problem for CG-NATs. > In practice NAT isn't a problem. Most people complaining about NAT are actually complaining about stateful firewalls. No, I know what I'm complaining about. Stateful firewall traversal via hole punching is trivial on v6 without port translation, but completely implementation dependent on v4 with NAT in the mix, to just name one thing. (Explicit "TCP hole punching" would also be trivial to specify; it's a real shame we haven't already, since it would take about a decade or two for mediocre CPE firewalls to get the memo anyway.) Having global addressing is also just useful in and of itself, even without global reachability.

▲

nine_k 3 hours ago | parent | prev | next [-]

Routing of this additional /16 is more tricky and non-uniform though. NAT, hole-punching, all that.

▲

WorldMaker 2 hours ago | parent [-]

Which is the exact problem any other IPv4 "extended" proposal would have hit. But the practical reality if the port number really was the only freely available bits in the IPv4 header to reasonably extend into. Almost everything else had ossified middleboxes doing something dumb with it. (And we've seen from NAT/hole-punching/etc how even port numbers had a lot of assumptions to overcome from middle boxes and we aren't using a full /16 there either. A lot of the safest traffic has to be > 10,000, a constraint on 14 of those 16 bits.)

There was never 64-78 bits in the IPv4 header unconstrained enough to extend IPv4 in place even if you accepted the CGNAT-like compromise of routing through IPv4 "super-routers" on the way to 128-bit addresses. Extending address size was always going to need a version change.

	▲	bombcar an hour ago \| parent [-]
		DNS SRV records actually can identify a port, so for "many" uses it would be transparent. I've rarely seen it used in practice, but it's in theory doable.

▲

themafia 3 hours ago | parent | prev [-]

You're thinking of TCP or UDP. IP does not have ports.

	▲	wtallis an hour ago \| parent [-]
		The workarounds for IPv4 address exhaustion were a major contributing factor to today's Internet being basically unable to reliably handle traffic that isn't TCP or UDP. Protocol ossification and widespread tolerance of connections that were effectively only usable for WWW has led to the Internet as a whole almost losing an entire layer of the network stack.