無印吉澤（※新エントリはhatenablogに掲載中）

■[NAT][IPv6]NAT特集記事

Volume 7, Issue 3, September 2004 - The Internet Protocol Journal
http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_7-3/

最新のIPJにて、NAT関係の話題をまとめた特集記事が掲載されていたのでご紹介。最近発表されたInternet Draftの内容も含めて、NAT関係の話題は一通り網羅されているので、これからマジメにNAT問題に取り組みたい人には格好の入門になりそうです。

ところで、これを一通り読むと解るのですが、この文書ではNATを越えて通信する（NATトラバーサルとも言う）ための技術については概要しか書かれていなくて、むしろ「現在のNATはどういうものか」という説明にほとんどのページが割かれています。実際、最近のIETFでは「NAT越えのためにどういう技術が必要か」という点よりも「どういうNATならばNATトラバーサル技術を適用しやすいか」という点に着目し、application-friendlyなNATの振る舞いを標準化する方向に向かっているようです。

逆に言うと、ここ数年に渡って行われてきたNATトラバーサル技術の研究によって、現在のNAT実装が持つ問題点は一通り明らかになったので、

• 理想的なNATの振る舞いを標準化する
• NATトラバーサル可能なアプリケーションを作り込む

という2つの大きな流れが生まれていて、今まで行われていたNATトラバーサル技術の標準化ということはもうあまり流行っていないような印象を受けます。前者はbehaveワーキンググループのような活動で、後者はSkypeなどですね。

----

そういえば、今日ちょうどこのようなニュースが出ていました。

NAT越しにIP電話できるSIPソフト、フラクタリストが開発(IT Pro)
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20041122/152898/

一般に、異なるLANやISPの傘下にある機器同士は直接接続できないので、インターネット上に中継サーバーを用意する必要がある。この場合、すべてのデータが中継サーバーを通過するため、動画や音声を扱う場合には、負荷がかかる中継サーバーのコストが高くなりがちだった。そこで、SIP UA SDKは「セッション管理サーバー」でハンドシェイクを行った後、端末間で直接ピア・ツー・ピア通信する仕組みを採用した。

このフラクタリストの方には以前にP2P勉強会などの場でお話を聞かせて頂いたことがあるのですが、簡単に言うと、こちらの製品はSTUNのNAT識別プロセスを更に強力にしたようなものを実装することで、あらゆるNATをUDP hole punchingで越えられるようにしているそうです。市場に出回っているNAT製品全てに対してテストを行う事でNAT識別プロセスを作り込み、そのノウハウによって価値が生まれている製品と言えるでしょう。

一方、IP電話の世界ではセッションボーダコントローラ（Session Border Controller; SBC）という製品も出回っていて、こちらは全てのトラフィックをSBCでリレーすることでNAT越えを実現しています。そもそもNATはクライアント/サーバ型のネットワークを前提としているため、この方法なら確実にNATを越えられるわけです。こちらはNATの識別を完全に諦めて、SBC装置自体の処理能力を高めることで価値が生まれている製品です（SBCの場合、NATトラバーサル機能はあまり重視されていない気もするのですが、本題ではないので割愛）。

----

以上のようなことから、今後NATトラバーサル可能なアプリケーションを作るとしたら、アプリケーションの特徴によって「NAT識別」と「パケットのリレー」をどの程度使い分けるか決めて、実装を作り込むしかないのではないかなぁ……というのが僕個人の感想です。

その一方、NAT問題を解決するにはやはり一刻も早くIPv6を普及させるのが一番なので、以前から注目しているTeredoや、最近Internet Draftで検討されているSilkroadにも期待しています。Silkroadについては、また後日紹介しますのでお楽しみに。

Tunneling IPv6 with private IPv4 addresses through NAT devices
http://www.ietf.org/internet-drafts/draft-liumin-v6ops-silkroad-02.txt