3 ms·
NAT (Or more correctly PAT) was never a good idea and this is the main reason why the cheap network device suffer. It should not need any kind of intelligence.
by jlouis 14y ago
NAT (Or more correctly PAT) was never a good idea and this is the main reason why the cheap network device suffer. It should not need any kind of intelligence. When some of us "Software" guys are up in arms over the slow IPv6 adoption it is because the current IPv4 state translates to thousands of extra code lines for little to no benefit.
We also need those cheap consumer devices to understand Active Queue Management, but that is another problem :)
- dsl 14y agoHaving seen the "sausage factory" of consumer gateway devices myself, I can tell you the problem is not NAT or any other technology you'd like to blame. The specs are written by non-technical product managers in the US, a contractor in Taiwan selects the OEM boards that most closely fit the spec requirements, pieces are combined and packaged in China with firmware outsourced to a completely different company in South Korea working off the OEM specs not the designs of the final product. (none of this is an exaggeration and is an example from a major broadband router maker) They literally don't know if a feature works enough to print on the box until the first batch is unloaded off the boat.
- noobface 14y agoHeh. You've seen what I've seen.
- meaty 14y agoSounds like Thompson or whoever they are called this week.
- jlouis 14y agoI don't doubt you, but my comment there was not directed at the CPE device. Rather for the code inside the program (on the PC endpoint) which has to deal with breaking through NAT.
- ishbits 14y agoMore correctly, NAPT is what is most commonly used, but often referred to as NAT. Just being picky as I've implemented just NAT, just PAT, and NAPT before.
- aidenn0 14y agoExcept we will still need stateful firewalls in consumer devices with ipv6, and that's just as hard to get right as NAT.