NAT（網路位址轉譯）改變了整個網際網路的運作方式，許多網路設備上的預設 NAT 設定其實並不一致，這也讓開發人員花了數十年的時間來克服它帶來的各種限制。選擇這條路線，實際上把第 4 層的通訊協定限制在 TCP 和 UDP，排除了像 DCCP、UDP-Lite 和 SCTP 這些本來可能成為替代選擇的協定。
事實上，IPv6 的原生路由功能早在 1995 年（RFC 1883）就已經提出，它提供一種更乾淨、更直接的方式來處理封包傳遞，早期雖發展緩慢，近幾年全球則已加速推進。
但即使到了今天，在許多環境中「路由」功能仍然沒有被充分發揮。其實在某些情況下，透過內部閘道協定（IGP）、邊界閘道協定（BGP）或其他路由協定來做網路設計會更合適，但許多系統仍然選擇部署 NAT。這種誤解其實也延伸到了第 2 層的網路設計上 —— 橋接網路還是很常見，結果經常導致網路變得複雜、容易形成迴圈。反觀如果用第 3 層的路由架構來設計，整體會更清晰，也更具可擴展性。
NAT的出現，改變了網際網路的原始設計
許多人把 NAT 當作一種「必需品」，但它實際上是個「不得已的選擇」。最常見的 Port Address Translation（PAT）讓 NAT 更加複雜，也促使業界發展出一堆「繞道而行」的技術，例如 STUN、TURN、ICE、WebRTC、ALG 等。這些技術大多只是為了繞過 NAT 的限制。
NAT 改變了原本開放、端對端（end-to-end）的網際網路結構，使得像 DCCP、UDP-Lite、SCTP 這類傳輸層協定無法順利發展。相對地，IPv6 自 1995 年（RFC 1883）便已提供原生、無需轉譯的路由機制。
其實應該「能路由就路由」
許多情況下，原本應該採用 Layer 3 路由的設計，卻仍然選擇使用 NAT 或 Layer 2 橋接，導致網路環境變得複雜且不穩定。「能路由就路由，非橋接不可才橋接。」或許現在我們該補上一句：「如果你考慮 NAT，那就部署 IPv6。」
NAT的真實代價：不是只有技術負擔
NAT 帶來的問題，尤其在 P2P 應用場景中非常明顯，例如：
- VoIP通話：在 NAT 後的用戶端，常無法直接連線，須使用 TURN 中繼，導致延遲增加。
- 同網段NAT：若同一 LAN 中兩設備透過 STUN 獲得相同的公網 IP，且 NAT 沒有啟用 hairpinning，流量仍會被繞送到遠端中繼。
- 線上遊戲：無法 P2P 配對，只好靠 TURN，結果遊戲延遲高、體驗差。
- 流量集中化：越來越多應用選擇中心化的 server-client 架構，降低了網路的去中心化特性與效能。
更別說在大型網路中（如 ISP 或企業），P2P 流量極為普遍，WhatsApp、Signal 等訊息應用，原本可以區域內就完成傳輸，卻因 NAT 被迫繞路。
CGNAT進一步加重IPv4的負擔
Carrier-Grade NAT 雖是短期的解決方案，但它也引入了「port 枯竭」的問題。在同一個公網 IP 下要支援成千上萬用戶，port 分配成了瓶頸。這種限制在 IPv6 的原生路由架構下根本不存在。
那…有沒有「比較不爛」的NAT？
可以，但不等於好用：
- 開啟 NAT Hairpinning：讓同網段內設備可以透過公網 IP 溝通，減少中繼需求。
- 支援 EIM / EIF（RFC 7857）：讓 NAT 映射與過濾更為獨立，提高連通性。
- 實作 Port Control Protocol（PCP）：動態調整 NAT 映射，但支援度不一，實務成效有限。
可惜的是，這些「強化 NAT」的方式，在實際網路設備上的支援仍然不一致，例如 MikroTik 僅支援 UDP 的 EIM，甚至有些設備連 hairpinning 都不預設啟用。
IPv6才是可持續的未來
IPv6 的原生路由特性，才是解決 NAT 所有問題的根本。
我們需要：
- 讓新世代工程師成為主力：正如過去電路交換到 IP/MPLS 的轉型，IPv6 的普及也將由理解其優勢的年輕工程師帶動。
- 改變教育與認證制度：IPv6 應成為預設教學內容，而不是附帶提及的選項；IPv6為理解 IP 網路提供了更清晰、更具可擴展性的基礎。
最後的提醒：NAT不是防火牆
很多人誤認 NAT 提供安全性，其實防火牆才是真正的安全策略工具。無論是 IPv4 還是 IPv6，若要安全，就該配置 stateful firewall，而非仰賴 NAT 的副作用。
結語：
NAT 曾經是過渡期的臨時解法，如今卻成了長期依賴的「偏方」。真正穩健且可擴展的網路架構，應該回歸路由本質，擁抱 IPv6，才能邁向未來的網際網路發展。
「若你正在考慮 NAT，請先問問自己，為什麼不是 IPv6？」
本文為作者個人想法，不代表TWNIC之立場，若對此內容有興趣，請參閱原文：
https://blog.apnic.net/2025/05/13/lets-talk-about-cgnat-and-ipv6-again/