NATは中央集権型インターネットの原罪である

ネットワークアドレス変換（NAT）は、1994年にRFC 1631でIPv4アドレス枯渇の短期的な対策として提案された。30年後、それは単なる一時しのぎではない——それはあなたのホームサーバーに到達できない理由であり、何かをホストするためにVPSを借りる理由であり、誰かがあなたのコンピュータに直接接続するという考えが異質で、あるいは危険にさえ感じられる理由なのだ。

その仕組みは、ホームネットワークをデバッグしたことのある人なら誰でもおなじみだろう。デバイスがプライベート送信元IPでパケットを送信し、ルーターがそれをパブリックIPとポートに書き換え、応答は同じマッピングを通って戻ってくる。外部ホストが接続を開始したい瞬間に問題は明らかになる——ルーターはそれをどこに送ればいいのかわからない。それはバグではなく、設計なのだ。

回避策はすべて妥協だ

ポートフォワーディングは最も直接的な修正だが、一度に1つのパブリックIP+ポートを1つのデバイスにマッピングするため、CGNATや、変換デバイスを制御できない機関ネットワークでは機能しない。UPnPとその類縁はフォワーディングを自動化するが、誤ったセキュリティ上の懸念から無効にされることが多く、ISPがキャリアグレードNATを行っている場合にはやはり失敗する。

STUN、TURN、ICEはWebRTCを動かすP2Pスタックだ。STUNはコーンNATでのみ機能し、対称NAT（CGNATで一般的）ではマッピングが役に立たなくなる。TURNは単にサーバー経由でトラフィックを中継するだけで、目的を台無しにする。ICEはすべてを順番に試すが、それが今日のインターネットでできる最善のことだ——しかしそれは単純な直接接続を外部インフラに置き換えてしまった。

IPv6がこれを修正するはずだった

RFC 1631が参照していた長期的な解決策はIPv6であり、誰にでもグローバルに一意なアドレスを与え、NATを不要にする。しかし採用は停滞しており、IPv6が存在する場所でさえ、ISPや機関は慣性でNATを適用し続けている——文字通りユニークローカルアドレスでIPv6をNAT化することさえあり、それは不可解だ。

本当のコストは文化的なものだ

NATはホスティングを難しくしただけでなく、クライアント・サーバー型が自然だと思うように皆を訓練した。クラウド中心のメンタルモデル——私のデバイスがサーバーと通信し、そのサーバーが他のデバイスと通信する——はアドレス不足の産物であり、インターネットの根本的な性質ではない。さらに悪いことに、NATはセキュリティ機能として正常化され、それを修正するものに人々が抵抗するようになった。

NATはインターネットが壁に囲まれた庭園で満ちている唯一の理由ではないが、最初の理由だった。それは友人にファイルを送れない理由であり、自分のメールを運用しない理由であり、何かのサービスを運用するということは、すでに所有しているハードウェアを使う代わりにVPSを借りることを意味する理由なのだ。