Internet centralization and the original sin of NAT
- ID
- 20144
- Status
- summarized
- Published
- 31 Aug 2026, 10:23 AM
- Fetched
- 02 Sep 2026, 9:32 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://dreamstation.systems/personal/ntppost.html
- Source URL
- https://hnrss.org/best
Summary
- Score
- 6.5
- Created
- 02 Sep 2026, 9:36 AM
- Tags
- Audience
- developersvibe_coders
What happened
This article argues that NAT, introduced in RFC 1631 (1994) as a short-term fix for IP address depletion, broke the internet's original peer-to-peer design by making direct connections between personal computers exotic and difficult. It walks through the concrete packet-header rewriting mechanics of how a home router translates private IPs to a single public IP, explaining why ordinary users can't just run an FTP server or accept inbound connections without workarounds like STUN/TURN/ICE.
Why it matters
If you build or deploy anything peer-to-peer, self-hosted, or real-time (WebRTC, agents calling home, local-first apps), NAT and CGNAT are the concrete reason you need relay infrastructure and can't just connect two devices directly. Understanding the packet-rewriting mechanics helps you reason about when your architecture will hit a wall and need TURN servers or a cloud intermediary.
Discussion angle
How much of the current push toward centralized AI APIs and cloud agents is downstream of NAT making direct device-to-device communication hard — and would IPv6 adoption actually change the calculus for self-hosted AI agents?