| ▲ | xorcist 21 hours ago |
| > caring, at the very least, that it's either TCP or UDP. You left out ICMP, my favourite! (And a lot more important in IPv6 than in v4.) Another pretty well known protocol that is neither TCP nor UDP is IPsec. (Which is really two new IP protocols.) People really did design proper IP protocols still in the 90s. > Can I just make up a packet and send it to a host across the Internet? You should be able to. But if you are on a corporate network with a really strict firewalling router that only forwards traffic it likes, then likely not. There are also really crappy home routers which gives similar problems from the other end of enterpriseness. NAT also destroyed much of the end-to-end principle. If you don't have a real IP address and relies on a NAT router to forward your data, it needs to be in a protocol the router recognizes. Anyway, for the past two decades people have grown tired of that and just piles hacks on top of TCP or UDP instead. That's sad. Or who am I kidding? Really it's on top of HTTP. HTTP will likely live on long past anything IP. |
|
| ▲ | xyzzyz 18 hours ago | parent | next [-] |
| There is little point in inventing new protocols, given how low the overhead of UDP is. That's just 8 bytes per packet, and it enables going through NAT. Why come up with a new transport layer protocol, when you can just use UDP framing? |
| |
| ▲ | mlhpdx 16 hours ago | parent [-] | | 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. | | |
| ▲ | Karrot_Kream 2 hours ago | parent [-] | | I think the "problem" of sending data is a lot harder without some concept of payloads and signaling. HTTP just happens to be the way that people do that but many RPCs like zeromsg/nng, gRPC, Avro, Thrift, etc work just fine. Plenty of tech companies use those internally. Some of this is hurt by the fact that v8, Node's runtime, has had first class JSON parsing support in but no support for binary protocol parsing. So writing Javascript to parse binary protocols is a lot slower than parsing JSON. |
|
|
|
| ▲ | gruturo 21 hours ago | parent | prev | next [-] |
| > NAT also destroyed much of the end-to-end principle. If you don't have a real IP address and relies on a NAT router to forward your data, it needs to be in a protocol the router recognizes. Not necessarily. Many protocols can survive being NATed if they don't carry IP/port related information inside their payload. FTP is a famous counterexample - it uses a control channel (TCP21) which contains commands to open data channels (TCP20), and those commands specify IP:port pairs, so, depending on the protocol, a NAT router has to rewrite them and/or open ports dynamically and/or create NAT entries on the fly. A lot of other stuff has no need for that and will happily go through without any rewriting. |
| |
| ▲ | xorcist 20 hours ago | parent | next [-] | | 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. | | |
| ▲ | gruturo 12 hours ago | parent | next [-] | | Actually the observation about ports being mostly a TCP/UDP feature is a very good point I had failed to consider. This would indeed greatly limit the ability of a NAT gateway - it could keep just a state table of IP src/dst pairs and just direct traffic back to its source, but it's indeed very crude. Thanks for bringing it up! | |
| ▲ | Hikikomori 19 hours ago | parent | prev [-] | | You can NAT on IP protocol as well, just not to more than one per external IP. |
| |
| ▲ | lxgr 20 hours ago | parent | prev [-] | | 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. | | |
| ▲ | Hikikomori 19 hours ago | parent [-] | | You can NAT on IP protocol as well, just not to more than one per external IP. | | |
|
|
|
| ▲ | lxgr 21 hours ago | parent | prev [-] |
| > You left out ICMP, my favourite! Even ICMP has a hard time traversing NATs and firewalls these days, for largely bad reasons. Try pinging anything in AWS, for example... |
| |
| ▲ | 6031769 20 hours ago | parent | next [-] | | 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. | |
| ▲ | Hikikomori 19 hours ago | parent | prev [-] | | Doesn't really have anything to do with nat though. |
|
