4 ms·

NAT was introduced by private company called Network Translation Inc. and successfully broke efforts to migrate off IPv4 (which was supposed to be EOLd by 1990)

by p_l 2y ago

NAT was introduced by private company called Network Translation Inc. and successfully broke efforts to migrate off IPv4 (which was supposed to be EOLd by 1990) and permanently broke the "network of hosts" into asymmetric one of servers and clients. Note that we had a solution for address exhaustion by 1991, but it was just "good" and not "perfect" and worst of all it used the hated OSI protocol stack (TUBA - TCP & UDP on top of OSI CLNS - also known as IPv9). It even had at least two usable implementations at the time it was proposed (for SunOS and Cisco IOS)

Hikikomori 2y ago
First product, but does the early RFCs and discussions predate their work?
- p_l 2y ago
  There's some work predating it, but it was very much undeployed before PIX let out the genie out, because even the early NAT work notes it might be problematic even in short term.
fc417fc802 2y ago
> permanently broke the "network of hosts" into asymmetric one of servers and clients. That was inevitable and can't reasonably be blamed on NAT. As but a few examples. ISPs arbitrarily break things unless you pay them extra. Stateful firewalls are a good thing. Even on my local LAN I can't reliably SSH into my laptop because it's on WiFi and does funky power saving stuff with the chipset I guess. My phone is far worse than my laptop in that regard. Setting up a reliable and widely reachable server requires deliberate effort regardless of the existence of NAT.
wmf 2y ago
People would have resisted TUBA the same ways they're resisting IPv6 now. It's not a technical problem.
- p_l 2y ago
  It's partly technical (BSD Sockets being bad API that hard does low level proto ok details in applications) and partially business - vendors didn't want to do the work to upgrade software and hardware - especially with advent of CEF and similar hardware routing options. And by 1990s the government-led standardisation efforts that gave us widespread ethernet and IPv4 got axed, and efforts to make vendors update if only for federal contracts died in waiver hell. The others kinds of problems are from there over time.

by p_l 2y ago

Hikikomori 2y ago

First product, but does the early RFCs and discussions predate their work?

p_l 2y ago
There's some work predating it, but it was very much undeployed before PIX let out the genie out, because even the early NAT work notes it might be problematic even in short term.

fc417fc802 2y ago

> permanently broke the "network of hosts" into asymmetric one of servers and clients. That was inevitable and can't reasonably be blamed on NAT. As but a few examples. ISPs arbitrarily break things unless you pay them extra. Stateful firewalls are a good thing. Even on my local LAN I can't reliably SSH into my laptop because it's on WiFi and does funky power saving stuff with the chipset I guess. My phone is far worse than my laptop in that regard. Setting up a reliable and widely reachable server requires deliberate effort regardless of the existence of NAT.

wmf 2y ago

People would have resisted TUBA the same ways they're resisting IPv6 now. It's not a technical problem.

p_l 2y ago
It's partly technical (BSD Sockets being bad API that hard does low level proto ok details in applications) and partially business - vendors didn't want to do the work to upgrade software and hardware - especially with advent of CEF and similar hardware routing options. And by 1990s the government-led standardisation efforts that gave us widespread ethernet and IPv4 got axed, and efforts to make vendors update if only for federal contracts died in waiver hell. The others kinds of problems are from there over time.