要約

  • NATはネットワーク境界でグローバルに一意なIPv4アドレスを節約できる。一方、アドレス値を前提とするアプリには、IPヘッダーの書き換えだけでは足りなかった。
  • RFC 2993が記録したのは、その後始末を誰が担うかだ。アプリケーション層ゲートウェイ、端末の協調更新、ローカルの名前管理とサポートであり、ルーター経路上の一台だけの問題ではない。

変換器が設定どおりにアドレスを書き換えても、アプリが接続できない場合がある。変換テーブルの誤りとは限らない。同じアドレスが私設ネットワーク内ではある端末を示し、外側では別の値に置き換わり、さらにアプリケーションのメッセージ本文に元のアドレスが残ることで食い違いが生じる。

この緊張は1994年の提案にも表れていた。RFC 1631は、IPv4アドレス不足への段階的な対応としてNetwork Address Translationを提示した。末端ネットワーク内でアドレスを再利用し、グローバルなアドレス空間へ出る通信だけを境界装置で変換する。文書は代価も認めている。IPアドレスが持つエンドツーエンドの意味は弱まり、その分の状態をネットワーク内に置く。出口が複数ある拠点では、各変換器が対応表について一貫した認識を持つ必要もあった。これは導入しやすい橋渡し策であって、費用のない設計ではない。

2000年11月、Tony Hainは、関心と導入が広がった6年間を踏まえてNATのアーキテクチャ上の影響を整理した。焦点は、ルーターが一つのアドレスを別の値に置き換えられるかだけではない。変換器が見ない場所にアドレスが現れたときも、サービスが成り立つかどうかだった。

答えはアプリごとに異なる。NATを一台だけ経由する二端末間の単純な通信なら、対処は比較的容易かもしれない。しかし、IPアドレスをペイロードに含むプロトコルや、チェックサム・認証・セキュリティ処理でヘッダーの一貫性を前提とする仕組みもある。ヘッダーしか見ない変換器では、そうした前提をすべて直せない。アプリケーション層ゲートウェイ（ALG）やプロキシが助けになる場合もあるが、それぞれが対象プロトコルを理解しなければならない。同年初めのRFC 2775も、アドレスに依存する新しいアプリが登場するたび、ALGやプロキシを更新する必要を指摘していた。

その結果、「透過的」という約束は条件付きになる。アプリが変換後のアドレスを外に出さず、それに依存もしなければ、境界の機能は気付かれないかもしれない。そうでなければ、アプリを動かす各地点で回避策を調整しなければならない。RFC 2993は、比較的単純な二端末のケースと、冗長なNAT経路や文書共有のような多地点アプリを対比した。そして、端末数が増えるにつれ調整の複雑さが幾何級数的に増すと記した。これは数式や実測コスト曲線ではない。アーキテクチャ上の拡張問題を表す記述である。

冗長構成は、別の状態依存も持ち込む。異なる経路にある二つの変換器が、ある端末のマッピングを整合させなければならない。接続状態が一方の経路に残ったまま通信が別経路へ移ると、そちらで異なるマッピングが作られることがある。元の経路へ戻っても、元の通信が復旧するとは限らない。パケット内のアドレスだけで状態全体を説明できず、変換器のマッピングと経路上の位置も重要になる。

負担は組織間で移ることもある。RFC 2993は、ISP管理のNATがISP側のサポートを簡素化する一方、ローカルなアドレス・名前管理を重くし得ると述べた。これは文書が指摘した負担の移転であり、総費用がどこでも必ず増えたという測定ではない。企業合併の後に重複した私設アドレスを整理したり、内外で異なるDNS応答を設計したり、以前はISPから見えなかったアプリの修正を各端末へ調整したりする仕事が、ローカル側へ移る可能性がある。

セキュリティは、変換と方針の違いをいっそう明確にした。RFC 2993は、とくにポート変換型NATが、ファイアウォールのような明示的なアクセス制御の意図を持たないまま、セキュリティ境界の印象を与える危険を指摘した。IPsec、DNSの動作、SNMPv3認証の互換問題も論じている。いずれもプロトコルや設定に依存する仕組みであり、すべてのNATがすべてのセキュリティプロトコルを壊すという証明ではない。変換器が変えるのはアドレスに依存する証拠であって、どの通信を許可するかという判断ではない。

後続文書は仕事を明文化したが、問題が消えたことまでは示さない。RFC 3022は2001年にRFC 1631を置き換え、伝統的なNATを記述した。2002年のRFC 3235は、アプリ設計者向けにNATと共存しやすい設計指針を示した。これらは、RFC 2993が特定の導入を引き起こしたことや、あらゆるソフトウェアが指針に従ったことの証明ではない。境界技術をめぐってアプリ設計の文献が形づくられたことは読み取れる。

RFC 2993の歴史的な意義は、NATは必ず失敗すると判定することではない。境界でのアドレス節約と、その上位層で必要になる互換性作業を分けて示した点にある。変換器は一つのゲートウェイに設置できても、修正は多数の端末へのアプリ更新、複数経路間の状態維持、ローカルな名前管理を要することがあった。ネットワークは仕事を消したのではない。誰がそれに気付き、調整するかを変えた。

出典