No more NAT!

--- IPv6 + IPsec + filtering ---

山本和彦、IIJ 技術研究所
加藤朗、東京大学

作成:1998年12月
改訂:2001年12月17日

(注) これは IP Meeting 98 の予稿に修正を加えた文章である。


概要

「NAT があれば IPv6 は不要である」という意見が多く聞かれる。 本稿では、 NAT がアドレス不足を緩和する一時的な対処策にすぎず、 長期的な視点でみるとインターネットの可能性を制限していることを述べる。 そして、インターネットの本来のアーキテクチャとして、 「IPv6 + IPsec + フィルタリング」が相応しいと主張する。

NAT は必要悪

IPv4 アドレスの枯渇問題を緩和する方法として、 これまでグローバルのみであった IPv4 アドレス空間の 一部を プライベートとして利用することが 1996 年に提案された。 IPv4 プライベート・アドレスを割り当てられた 組織内のホストは、 インターネットのホストと直接通信できない。 そこで、直接の通信を可能にするために、 NATが提案された。 セキュリティに対する認識が高まった時期と重なったためか、 NAT はファイアウォールと同一視されて普及していった。

単純な NAT ルータは外向きのパケットの始点アドレスに関し、 組織内の複数の IPv4 プライベート・アドレスを 組織に割り当てられた IPv4 グローバル・アドレスに対応付ける。 また、 割り当てられた IPv4 グローバル・アドレスが 1 つである場合に対応するため、 始点ポートを書き換える NAT ルータも存在する。 始点アドレスと終点アドレスの両方を変更する NAT ルータもある。 これらの対応関係は動的に生成されることが多い。

動的に変化する通信の識別子を組織の外から得る (たとえば DNS のような)一般的な手段は存在しない。 そのため、NAT では内向きの通信を実現できないことが多い。 この一方向性は、セキュリティ保全上便利であるので、 NAT がファイアウォールとして利用されてきたのである。

NAT が普及しすぎたためか、 NAT がファイアウォールに不可欠であると考えている人が多い。 しかし、NAT の持つ以下の 2 つの機能は 区別して議論されるべきである。

IPv4 アドレス不足の問題は、 本質的には空間を大きくして解決するべきであり、 IPv6 が技術的に自然なアプローチである。 また、一方向性は NAT 以外にも、 たとえばパケット・フィルタリングでも実現できる。 このように、 IPv6 へ移行すれば NAT が必ずしも必要ではないことが分かる。 以下では、さらに NAT の欠点を考察していく。

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

「IPsec は結局 VPN(Virtual Private Network)にしか使えない」とか 「SSH があれば IPsec は不要」 といった意見も多く聞かれる。 しかし、IPsec は以下のようにさまざまな用途に有効である。 ネットワーク全体の通信保護はまさに VPN である。 ホスト全体の通信保護は、 出張先で自分の携帯端末から 会社のコンピュータにアクセスするときなどに利用できる。 SSH は対話的な TCP コネクションの保護に適している。 一方、IPsec は任意の TCP コネクションを保護できる。 たとえば、BGP の経路交換に使う TCP コネクションの 認証といった用途も考えられる。 さらに、 IP spoofing 攻撃や TCP コネクション・リセット攻撃のように IPsec でなければ防止できない攻撃も存在する。 もちろん、IPsec で防止できない攻撃も多く存在する。

IPsec のアーキテクチャで規定される SPD(Security Policy Database) はそもそもパケット・フィルターであるので、 IPsec はパケット・フィルターと相性がよい。 また、NAT を必要としない IPv6 とも IPsec は相性がよい。

IPsec 自体は、ベンダーに広く支持された。 今後の課題は、鍵交換プロトコルである。


IPv6 の真の姿

IPv6 の本質はアドレスの拡張である。 アドレスの拡張から派生する特徴のみが IPv6 が IPv4 に対して優れている点だといえる。

まず、 自動車や携帯電話のようにグローバルな空間に置く必要があり 多量に存在する端末にとっては、 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 への移行に関する技術革新を 2 つ紹介しておこう。 1 つは IPsec で BITS(Bump In The Stack)と呼ばれる 技術を IPv6 に応用した技術、 もう 1 つは IPv4 と IPv6 との通訳をするトランスレータ である。 BITS とは、 動的に入れ換え可能なデバイス・ドライバーを更新することで、 新たなネットワーク・スタックをそのホストに追加する技術である。 OS の入れ換えが無理な場合に適している。 BITS を使えば IPv4 ホストを IPv6 機能も持った デュアル・スタック・ホストに変更できる。 日立製作所から実装例がフリーで配布されているので参照されたい

トランスレータは IPv6 への移行後期で必要になると認識されていた。 なぜなら、これまでの IPv6 への移行戦略では、 移行初期の IPv6 ホストはデュアル・スタック・ホストであるので、 移行初期に IPv4 ホストと IPv6 ホストが混在することはないと考えられていたからである。 しかし、結局 IPv4 アドレスが不足しているので、 初めから(IPv4 アドレスを割り当てなくてよい) IPv6 ホストを 使いたいという要望を出す組織が出現した。 そこで、移行初期でも IPv4 ホストと IPv6 ホストが混在するので、 トランスレータが緊急に必要となった。

これまでの研究で、 組織内の IPv6 ホストが インターネットの IPv4 ホストに対し 外向きに TCP の通信を開始するための トランスレータは実装が容易であることが分かった。 このトランスレータの実装例は KAME に付属してフリーで配布されている。

一方、逆に内向きのトランスレータは アドレス空間の大小関係や DNS のキャッシュの問題により、 理論上実装不可能に近いと予測できる。 そこで、 インターネットに公開するサーバを デュアル・スタック・ホストにして、 IPv4 と IPv6 の両方のサービスを提供するという運用方針を 著者らは提案している。

トランスレータは IP の バージョン・フィールドも書き換える一種の NAT であるから、NAT と同じ問題点がある。 しかし、グローバルな通信が必要なホストが IPv6 に移行した後は、 トランスレータは不要である。


結論

NAT は IPv4 にとって必要悪であり、 NAT を利用しなくてもすむ IPv6 へ移行することが望ましいと述べた。 インターネット本来のアーキテクチャを取り戻せる IPv6 は、 IPsec と相性がよい。 セキュリティ保全のために一方向性が必要であれば、 パケット・フィルタリングで実現できる。 パケット・フィルタリングも IPsec と相性がよい。

技術的にみても、インターネットの可能性を考慮しても、 NAT よりも 「IPv6 + IPsec + パケット・フィルタリング」の方が 優れていると考えられる。 この技術的な考察を踏まえて、 必要なコストと見比べながら IPv6 へ移行するかどうかを選択するべきである。


謝辞

以上の考察は、 主に KAME のコア・メンバーと何度も議論を重ねた結果である。 議論に付き合って頂いた KAME のコア・メンバーに感謝する。
Email: kazu@mew.org
URL: http://www.mew.org/~kazu/