We're about half-way to exhausted, but a huge chunk of the ones assigned are long deprecated and/or proprietary technologies and could conceivably be reassigned. Assignment now is obviously a lot more conservative than it was in the 1980s.

There is sometimes drama with it, though. Awhile back, the OpenBSD guys created CARP as a fully open source router failover protocol, but couldn't get an official IP number and ended up using the same one as VRRP. There's also a lot of historical animosity that some companies got numbers for proprietary protocols (eg Cisco got one for its then-proprietary EIGRP).

https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers

Probably use of some type of options. Up to 320 bits, so I think there is reasonable amount of space there for good while. Ofc, this makes really messy processing, but with current hardware not impossible.

People will start overloading the numbers.

I do hope we'll have stopped using IPv4 by then... But well, a decade after address exhaustion we are still on it, so who knows?

Agreed. Building a custom protocol seems “hard” to many folks who are doing it without any fear on top of HTTP. The wild shenanigans I’ve seen with headers, query params and JSON make me laugh a little. Everything as text is _actually_ hard.

A part of the problem with UDP is the lack of good platforms and tooling. Examples as well. I’m trying to help with that, but it’s an uphill battle for sure.

I think we agree. Of course a NAT router with an application proxy such as FTP or SIP can relay and rewrite traffic as needed.

TCP and UDP have port numbers that the NAT software can extract and keep state tables for, so we can send the return traffic to its intended destination.

For unknown IP protocols that is not possible. It may at best act like network diode, which is one way of violating the end-to-end principle.

Of course NAT allows application layer protocols layered on TCP or UDP to pass through without the NAT understanding the application layer – otherwise, NATted networks would be entirely broken.

The end-to-end principle at the IP layer (i.e. having the IP forwarding layer be agnostic to the transport layer protocols above it) is still violated.

Have to say that I don't encounter any problems pinging hosts in AWS.

If any host is firewalling out ICMP then it won't be pingable but that does not depend on the hosting provider. AWS is no better or worse than any other in that regard, IME.

Doesn't really have anything to do with nat though.

See nearby comment about terminology. Either we're discussing odd IP protocols, then the devices you're describing aren't just "routers" (and particularly what you're describing is not part of a "router"), or we're not discussing IP protocols, then we're not having this thread.

And note the GP talked about "intermediate routers". That's the ones in a telco service site or datacenter by my book.

TCP congestion control is performed by the end device based on mostly packet drop feedback. Middleboxes just drop traffic. Though sometimes there are techniques such as AQM (active queue management) where middleware router sends a special ECN (exlicit congenstion notification) bit in the packet but then still that relies on both endpoints to support and respect that notification.

Most intermediate routers don't care much. Lookup the destination IP in the routing table, forward to the next hop, no time for anything else.

Classic congestion control is done on the sender alone. The router's job is simply to drop packets when the queue is too large.

Maybe the router supports ECN, so if there's a queue going to the next hop, it will look for protocol specific ECN headers to manipulate.

Some network elements do more than the usual routing work. A traffic shaper might have per-user queues with outbound bandwidth limits. A network accelerator may effectively reterminate TCP in hopes of increasing acheivable bandwidth.

Often, the router has an aggregated connection to the next hop, so it'll use a hash on the addresses in the packet to choose which of the underlying connections to use. That hash could be based on many things, but it's not uncommon to use tcp or udp port numbers if available. This can also be used to chose between equally scored next hops and that's why you often see several different paths during a traceroute. Using port numbers is helpful to balance connections from IP A to IP B over multiple links. If you us an unknown protocol, even if it is multiplexed into ports or similar (like tcp and udp), the different streams will likely always hash onto the same link and you won't be able to exceed the bandwidth of a single link and a damaged or congested link will affect all or none of your connections.

They probably can do deep/shallow packet inspection for that purpose (being one of the non-nefarious applications I alluded to), but that's not to say their correct functioning relies on it. Those routers also need to support at least UDP, and UDP provides almost no extra information at that level -- just the source and destination ports (so, perhaps QoS prioritization) and the inner payload's length and checksum (so, perhaps dropping bad packets quickly).

If middleware decides to do packet inspection, it better make sure that any behavioral differences (relative to not doing any inspection) is strictly an optimization and does not impact the correctness of the link.

Also, although I'm not a network operator by any stretch, my understanding is that TCP congestion control is primarily a function of the endpoints of the TCP link, not the IP routers along the way. As Wikipedia explains [0]:

> Per the end-to-end principle, congestion control is largely a function of internet hosts, not the network itself.

[0]: https://en.wikipedia.org/wiki/TCP_congestion_control

Can also do 1:1 NAT for IP protocols like ipsec, or your own protocol.

Yeah, this is basically what I was wondering, why QUIC used UDP instead of their own protocol if it's so straightforward. It seems like the answer may be "it's not as interference-free as they'd like it".

You can call the things mangling IP addresses and TCP/UDP ports what you want, but that will unfortunately not make them go away and stop throwing away non-TCP/UDP traffic.

And by your definition my home router is not a router since it does NAT? There's really no point in arguing semantics like this.

Both things come on the same box nowadays.

There are many routers that don't care at all about what's going through them. But there aren't any firewalls that don't route anymore (not even at the endpoints).