キャリアグレードNATと家庭用NATの違い

昨日「IPv4アドレス枯渇とIPv6化に向けての464NAT提案」という記事を書いたのですが、TwitterにてTomo's HotlineのTomoさんから「4-4-4も4-6-4-NATもインターネットドラフトが出ています。4-4-4は私が書いています。」との情報提供を頂けました。

早速教えていただいたinternet draft「Carrier Grade Network Address Translator (NAT) Behavioral Requirements for Unicast UDP, TCP and ICMP, draft-nishitani-cgn-00」を拝見しました。 キャリアグレードNAT(CGN)に関する非常に興味深い内容でした。 恐らく今月のIETF(アイルランド)にてTomoさんが発表されると思われます。

以下、internet draftに記述してある内容等などからキャリアグレードNATと通常NATで違いそうなところに関して書いてみました。 間違いや勘違い等、ご指摘頂ければ幸いです。

キャリアグレードNATでの違い

ポート割り当てテーブルをCPE(Customer Premises Equipment)毎に個数制限しなければならない

通常NATであれば、ノード毎のセッション数制限は必要ありません。 SOHOルータでは、全員が一つのNAT変換テーブルを共有しています。

キャリアグレードNATでは、複数のCPEで同一IPアドレスをシェアする必要があります。 UDPやTCPのポート数は宛先/送信元各16ビット長と有限であるため、この有限であるポート数を公平に使えるようにする必要があります。 例えば、100人で1つのIPアドレスをシェアしているのに一人だけ数万ポートを使い、そのために他のユーザが通信できないような事態が発生すると不公平になります。

また、この不公平を放置すると、DoSが容易に行えるようになってしまいます。 これらの理由により、CPE毎にセッション数制限を設ける必要があります。

CPEに対して割り当てられるIPアドレスは同一でなければならない

SOHOルータであれば、一つに対して複数のIPアドレスが割り当てられる事はないので、こんな事を考えなくても良いのですが、キャリアグレードNATになるとこれも考えなければいけません。 キャリアグレードNATのように多数のユーザを前提としてNATであれば、単一のグローバルIPアドレスではポート番号というプロトコル上有限な資源が足りなくなる可能性もあるため、複数のグローバルIPアドレスを管理しながら運営が行われると思われます。

例えば、キャリアグレードNATの下にいるクライアントが、グローバルなIPアドレスを持つサーバに対して2本のTCPセッションを張った時に、1本目と2本目でIPアドレスが異なってしまうと動作しないプロトコルやアプリケーションがあるかも知れません。

ただ、この「同一IPアドレスを可能な限り割り当てる」というのは管理を困難にするかも知れません。 (次の項目参照)

各セッションの生存期間と同一IPアドレスを割り当てる事

特定のCPEに対して特定のグローバルIPアドレスを割り当ててしまうと、グローバルIPアドレスの利用効率が落ちてしまう可能性があります。 そのため、CPEへのグローバルIPアドレス区分は、ある程度動的に行いたくなります。

しかし、何らかのセッションが発生している間はCPEのグローバルIPアドレス区分を変更できません。 変更してしまうと「同一IPアドレスを割り当てる事」ができなくなります。

恐らく、CPEから全くセッションが発生しない状態が一定期間以上になれば、グローバルIPアドレス割り当て区分を変えても良いという形になると予想しています。 ただ、常に(もしくは定期的に)何らかのセッションを発生させ続けるユーザがどれだけいるかで、グローバルIPアドレス毎に稼働率が微妙に変わってきてしまい、そのCPEを使っているユーザのトラフィック特性とグローバルIPアドレスのbindingという細かいケアが必要になる場合もあるのかも知れないと、妄想してみました。

一度NAT変換テーブルに割り当てたポートは決められた期間有効でなければならない

一見当たり前に思えますが、これってかなり厳しい要求だと思います。 なぜ、厳しいかというのは次の項目をご覧下さい。

ファームウェアアップグレードどうするんだろう？

ルータ内部のソフトウェアがアップデートする事があります。 機能が増えるということでバージョンアップすることもありますし、セキュリティ上の理由でバージョンアップすることもあります。

一般的には、例えばルータのOSがアップグレードしたらOSを再起動しなければなりません。 再起動をすると保持している情報は消えてしまいます。 家庭のNATであればユーザが好きな時に再起動できますが、キャリアグレードNATではそれは許されません。

経路等をできるだけ落とさないようにするためのISSU (In Service System Upgrade)という仕組みがありますが、同様の事をNATの変換テーブルに対してもやらなければならないのではないでしょうか。 ただ、無数のユーザが任意のタイミングで発生させるトランザクションに対するNAT用変換テーブルを保持しながら、ルータのOSを再起動する手法って気が遠くなりそうですね。。。

障害対策

ルータも壊れることがあります。 ファンや電源が故障することがありますし、その他理由で動作しなくなる場合もあります。 ソフトウェアのバグでルータが落ちる可能性もゼロではありません。 また、古くなった製品を新しく置き換えなければならない場合もあります。

今までのルータ等の故障であれば経路情報等を共有していれば、切り替え時にパケットが数個落ちる程度まで改善できているとおもいます。 これは、ルータがセッションのステートを保持しておらず、各セッションの状態を保持しているのがエンドノードであったからです。 ルータが途中でパケットを落としても、エンドノードでTCPがカバーしてくれたりするのであまり問題にはならないことも多いです。

しかし、キャリアグレードNATではルータが状態(ステート)を持ってしまっています。 そこがいきなり落ちると、既存のセッションが全部落ちます。 そのため、通常のルータよりも障害対策難易度が上がると思われます。

番外編

内部からステルススキャンをする人がいると性能が落ちる？

一度NAT変換テーブルに乗ったセッションに対するNATの処理はASICを使って転送効率を上昇させていると思うのですが、まだ確立していないセッションのためにはルータのCPUを使った処理を行うのではないでしょうか。 例えば、ステルススキャンを内部からバシバシ行うと、その分CPUを使ってしまいます。 ASICに行く前のCPUでの処理ばかりになってしまうためです。 もちろん何らかの対策はするのでしょうが、色々難しそうですよね。

感染した人が外と通信できなくなるウィルスが作成できてしまう？

ISP全体がNATを行う環境では、 UDPでランダムなIPアドレスに対してランダムなポートを使ってパケットを送りまくるウィルスに感染すると、ユーザは一定期間外と通信できなくなるかも知れません。 例えば、SQL Slammerのようなウィルスに感染すると、即座にキャリアグレードNAT内におけるNAT変換テーブルを制限一杯までUDPホールパンチングしてしまい、それ以上外と通信できなくなってしまいます。 プロトコル毎に制限数を別に設けたりするだとうとは思いますが、TCPセッションを無駄に張り続けるウィルスによってTCPの変換テーブルを浪費させてしまう事も同様に可能です。

SIPの処理？

プロトコル内部にIPアドレス等がアスキーで埋め込まれているような物を変換しなければならないと思うのですが、例えばプロトコル内部の特定のフィールドに書かれた文字列の置き換えを数十Gbpsの回線で行えるようにするためのチューニングってどれだけ大変なんだろう。。。と思ってしまいます。 全部のパケットに対してやるわけではないのですが、そのような細々とした処理をアプリケーション毎(ALG毎)にやるとして、何種類のALGを有効にして稼動させるのだろう、など色々と妄想してしまいました。

大変そうですね

キャリアグレードNATって本当に大変そうですね。。。 導入当初はかなり色々苦労がありそうだと思った今日この頃でした。

追記：2008年7月10日

internet draftの最後にICMPに関しての記述があります。

「NAT Behavioral Requirements for ICMP protocol(ietf-behave-nat-icmp)」と同様に、ポート数制限に達してUDP/TCPによる通信ができない場合には、ICMP destination unreachable messageを code 13(Communication administratively prohibited)で送信すべきであると記述されています。

エンドノード側はICMPを監視していればNATにおいてポート数制限に達した事がわかるという仕様ですね。 将来的にはキャリアグレードと家庭用の両方に付属される機能になると思われますが、面白い仕様だと思ったので追記しました。

最近のエントリ

過去記事

過去記事一覧