NAT Is the Enemy of Low Power Devices

Original Article ↗ Hacker News Discussion ↗

IPv6 vs NAT for IoT/low‑power devices

  • Several commenters argue IPv6 is the “real” fix: removes ARP/DHCP hacks, avoids NAT, enables simpler end‑to‑end addressing and easier P2P/firewall traversal (PCP, SLAAC, etc.).
  • Others push back: IPv6 stacks add complexity (NDP, ICMPv6, MLD, SLAAC, IPsec), are still not universal on small MCUs and cellular modems, and many carriers or enterprises either don’t deploy IPv6 or cripple it (e.g., disabling SLAAC, enforcing DHCPv6).
  • Privacy is debated: some see per‑device global addresses as worse than NAT; others say with privacy extensions and shared prefixes it’s roughly equivalent to IPv4+NAT. Concern remains about revealing number/timing of devices in a household.
  • IPv6 NAT exists and can be used for prefix translation or masquerade, but many consider it philosophically wrong and only necessary where networks are misdesigned (e.g., CGNAT on IPv6).

NAT, firewalls, and virtual networking

  • NAT is recognized as both enabling today’s IPv4 scale and as a fundamental break with the “network of hosts,” pushing the world into client/server asymmetry.
  • Several comments stress that the user’s real desire is a stateful firewall; NAT is often (wrongly) treated as a security feature. Equivalent inbound‑blocking IPv6 firewalls are possible (and often default).
  • CGNAT and multi‑layer NAT (ISP + CPE + mesh) break port forwarding and direct access, complicating IoT, home servers, and P2P.
  • NAT is also used as a practical tool to work around enterprise restrictions, for VMs and home networks; some prefer it because “what the outside can’t see can’t hurt it”.

Low‑power IoT specifics (sessions, power, and stacks)

  • The core IoT pain: keeping NAT bindings and secure sessions alive forces periodic traffic, which consumes power and data; tearing sessions down requires expensive TLS/DTLS handshakes.
  • Proposed mitigations in the thread: TLS/DTLS session tickets, DTLS Connection IDs, CoAP over DTLS, cellular PSM/eDRX, SMS or NIDD as out‑of‑band wake/triggers.
  • Some practitioners report it’s usually more power‑efficient to fully power‑cycle modems and accept reconnect cost, sacrificing instant cloud‑to‑device control.
  • There is strong advocacy for mature RTOS networking stacks (e.g., Zephyr, lwIP + PPP) and using separate modems rather than closed SoC+modem combos, for better updates, protocol control, and easier hardware replacement as cellular generations sunset.

Security, local‑only design, and alternatives

  • Many argue IoT devices should be LAN‑only, with a local hub or VPN (WireGuard, OpenVPN, Tailscale) for remote access; internet‑reachable consumer IoT is viewed as insecure and economically questionable without subscriptions.
  • Suggestions include Thread/mesh with a border router, strict WLAN isolation, and assuming closed‑source IoT is compromised by default.
  • Some see the article as overblaming NAT: stateful firewalls also time out, and many IoT control flows can tolerate polling and delayed updates. Others think the NAT‑timeout problem remains a real blocker for ultra‑low‑power, always‑reachable devices.