(注) これは IP Meeting 98 の予稿に修正を加えた文章である。
単純な NAT ルータは外向きのパケットの始点アドレスに関し、 組織内の複数の IPv4 プライベート・アドレスを 組織に割り当てられた IPv4 グローバル・アドレスに対応付ける。 また、 割り当てられた IPv4 グローバル・アドレスが 1 つである場合に対応するため、 始点ポートを書き換える NAT ルータも存在する。 始点アドレスと終点アドレスの両方を変更する NAT ルータもある。 これらの対応関係は動的に生成されることが多い。
動的に変化する通信の識別子を組織の外から得る (たとえば DNS のような)一般的な手段は存在しない。 そのため、NAT では内向きの通信を実現できないことが多い。 この一方向性は、セキュリティ保全上便利であるので、 NAT がファイアウォールとして利用されてきたのである。
NAT が普及しすぎたためか、 NAT がファイアウォールに不可欠であると考えている人が多い。 しかし、NAT の持つ以下の 2 つの機能は 区別して議論されるべきである。
NAT はインターネットが本来提供していた双方向性を喪失させた。 これは、双方向性が不可欠である ホーム・ネットワークや複数のコネクションを必要とする通信など、 インターネットの可能性を制限しているといえる。
NAT ルータはアドレスの対応付けのために状態を持つ。 対応関係だけならば分散的な共有も不可能ではない。 しかし、アプリケーションによっては、 ペイロード中の IPv4 アドレスの書き換えや、 それに伴う TCP のシーケンス番号のずれの管理も必要になる。 この情報を分散的に共有することは難しいので、 NAT ルータを利用すると組織の出口は 1 つに制約されてしまう。 このことは、信頼性や性能の点で問題となる。 また、事故等によって NAT ルータが再起動した場合は 状態を取り戻せないので、これまでの通信が結果としてすべて切断されてしまう。
ストリーム系のアプリケーションでは、 ペイロード中に IPv4 アドレスを埋め込む独自のプロトコルを採用している ことが多い。 このプロトコルは非公開で仕様が手に入らない場合がほとんどである。 また、 ペイロード中の IPv4 アドレスを書き換えるよう実装すること自体が困難である。 つまり、NAT ルータは次々に生み出されるアプリケーション・プロトコルに 必ずしも対応できる訳ではない。
さらに、NAT は IPsec と相性が悪いことも特筆するべきであろう。 NAT ルータは IPv4 ヘッダを変換するので、 IPv4 ヘッダの完全性を保護する 認証ヘッダとは共存できない。 また、IPv4 ヘッダ以降が 暗号ペイロードにより暗号化されていれば、 TCP/UDP の始点ポートが参照不可能なので、 ポートを変換する NAT ルータは IPv4 ヘッダを変換できない。
このように NAT には欠点が多い。 インターネット本来のアーキテクチャを取り戻し、 さらに IPv4 アドレスの枯渇問題を解決するためには、 IPv6 に移行するべきであると筆者らは考えている。 IPv6 の環境では双方向性を基本とし、 一方向性が必要であればパケット・フィルタリングを用いればよい。
これまで NAT の欠点ばかりを説明してきたが、 実は NAT には捨てがたい魅力が 1 つある。 それは、マルチホーム を簡単に実現できることである。
たとえば、 組織の出口として NAT ルータが 1 つあり、 その NAT ルータが複数のプロバイダに接続を持つ環境を考えてみる。 複数のプロバイダから割り当てられたそれぞれの IPv4 アドレス空間は、 NAT ルータのみが保持する。 組織から出ていくパケットの始点アドレスは、 中継してもらうプロバイダに応じて、 そのプロバイダから割り当てられた IPv4 アドレスに書き換えられる。 よって、このパケットの返答が この組織に戻ってくることを期待できる。
IPsec のアーキテクチャで規定される SPD(Security Policy Database) はそもそもパケット・フィルターであるので、 IPsec はパケット・フィルターと相性がよい。 また、NAT を必要としない IPv6 とも IPsec は相性がよい。
IPsec 自体は、ベンダーに広く支持された。 今後の課題は、鍵交換プロトコルである。
まず、 自動車や携帯電話のようにグローバルな空間に置く必要があり 多量に存在する端末にとっては、 IPv6 の広大なアドレス空間が必要である。 また、ホーム・ネットワークや双方向に複数のコネクションを張る通信のためには、 双方向性が不可欠である。 このようなインターネットの可能性を制限しないためにも、 IPv6 を普及させるべきであろう。
通信メディアの MAC アドレスは 通常 6〜8 バイトである。 IPv6 アドレスは 16 バイトであるので、 MAC アドレスを埋め込むに十分な長さを持っている。 そこで、MAC アドレスから 8 バイトの ネットワーク・インターフェイス識別子を作り、 自動的にリンクローカル・アドレスを生成できる。 このため、通信メディアに IPv6 ホストを接続した時点で、 そのサブネット内での通信が可能になる。
また、ルータからプレフィックスを得られれば、 グローバル・アドレスを生成できる。 この時点で、インターネット上のホストとの通信が可能になる。 このように、IPv6 には自動設定機能が あらかじめ組み込まれている。 このため IPv6 では、ルータのアドレス設定を操作することによって、 組織内の全ホストに対するアドレスの付け換えを実施できる。 ルータのアドレス設定に対しては、 ICMP を使った方式が提案されている。
IPv4 の運用上の問題点として、 アドレスの取得の際に JPNIC などのレジストリにホストの増加予測を提出するなどの 繁雑な作業が必要なこと、 そしてサブネットに接続するホスト数を予測して適切な サブネット長を算出しなければならないことがある。 一方 IPv6 では、 アドレスは十分にあるのでレジストリのアドレス割り当てポリシは緩やかになるし、 プレフィックス長は 8 バイト固定であるので計算する必要はない。 (通常 IPv6 では 1 つのサブネットに 2^64 台ホストが収容可能で、 組織はこのサブネットを 2^16 個取得できる。)
IPv6 独自の特徴として、セキュリティ、マルチキャスト、 QoS、 そしてモバイルの問題が解決されるという認識を持つ人も多い。 しかし、これらの問題は IPv4 と IPv6 において本質的な差は存在しない。 一方で実現可能であれば他方でもそうであるし、 逆もまた真である。
トランスレータは IPv6 への移行後期で必要になると認識されていた。 なぜなら、これまでの IPv6 への移行戦略では、 移行初期の IPv6 ホストはデュアル・スタック・ホストであるので、 移行初期に IPv4 ホストと IPv6 ホストが混在することはないと考えられていたからである。 しかし、結局 IPv4 アドレスが不足しているので、 初めから(IPv4 アドレスを割り当てなくてよい) IPv6 ホストを 使いたいという要望を出す組織が出現した。 そこで、移行初期でも IPv4 ホストと IPv6 ホストが混在するので、 トランスレータが緊急に必要となった。
これまでの研究で、 組織内の IPv6 ホストが インターネットの IPv4 ホストに対し 外向きに TCP の通信を開始するための トランスレータは実装が容易であることが分かった。 このトランスレータの実装例は KAME に付属してフリーで配布されている。
一方、逆に内向きのトランスレータは アドレス空間の大小関係や DNS のキャッシュの問題により、 理論上実装不可能に近いと予測できる。 そこで、 インターネットに公開するサーバを デュアル・スタック・ホストにして、 IPv4 と IPv6 の両方のサービスを提供するという運用方針を 著者らは提案している。
トランスレータは IP の バージョン・フィールドも書き換える一種の NAT であるから、NAT と同じ問題点がある。 しかし、グローバルな通信が必要なホストが IPv6 に移行した後は、 トランスレータは不要である。
技術的にみても、インターネットの可能性を考慮しても、 NAT よりも 「IPv6 + IPsec + パケット・フィルタリング」の方が 優れていると考えられる。 この技術的な考察を踏まえて、 必要なコストと見比べながら IPv6 へ移行するかどうかを選択するべきである。