キャリアグレードNATはIPv6を見限ったわけではない
日本に戻ってきた宮川さんは、NTTコミュニケーションズのR&D部門の一員としてIPv6化を推進する。とはいえ、インターネットのアドレス体系自体を抜本的に変更するIPv6への移行は一朝一夕では進まなかった。そのため並行して宮川さんが取り組んだのが、キャリア側でIPv4とIPv6のNATをかけることで、IPv4アドレスの延命を図る「キャリアグレードNAT」（RFC6888）だ。
「IPv4アドレスが本当に枯渇するという話になり、今まで以上にIPv6化を推進してきたんだけど、世の中そんなに簡単に変わるわけでもない。そこで、アドレス足りないなら、ケーブルTVさんのように、キャリア側で大きいNATをかけるという方法もありだよねという話になった。でも、そのときに僕が思ったのは各社が異なるNATを使うと、アプリケーションのNAT越えが大変になるということ。NAT越えが大変なのはスペックが揃ってないから。だからキャリアのNATはスペック揃えたほうがいいんじゃないかと思ったんです」
「キャリアのNATはスペック揃えたほうがいいんじゃないかと思ったんです」
そこで、キャリアグレードNATの仕様策定のために普段ライバルのキャリアと共同歩調をとる。お互いのノウハウを持ち寄って、IETFに提案し、世界で統一した規格を提案しようというわけだ。でも、IPv6推進論者からは当初さまざまな意見を受けたという。
「僕はNATを否定したIPv6の人として名が通っている。そのお前がNATの提案持ってくるってなにごとだって怒られるんです。まあ、当然ですよね。でも、僕は別にNATが好きなわけでも、IPv6がダメと言ってるわけでもない。NATが入るのであれば、仕様を決めておいたほうがよいとみんなを説得したんです」
「研究開発して明らかになったのは、キャリアグレードNAT使うと、悪いことがいっぱい起こるということ。たとえば、同じIPアドレスを複数の人が使うことになるので、ファイアウォールが難しくなる。同じ送信元が2つあったら、フィルタリングはできないから。あとセッション数の問題。TCP/IPはポート数が2バイトと決まっているので、おおざっぱに言えば、6万5536本のセッションを貼れることになる。でも、キャリアグレードNATの配下で僕が6万5536本までNATのエントリをキープしちゃったら、ほかは通信できなくなる」
こうした課題を受け、日本主導で進められたキャリアグレードNATのRFC6888では、あらかじめ利用できるセッション数に上限を設けたり、アプリケーション側からNAT越えをしやすいよう、アドレス交換の対称性を仕様として定めてある。一方、IPv4アドレスの枯渇が現実問題として顕在化してきた昨今、IPv6の普及も実は一気に進んでいる。最近では、GoogleやFacebook、CGN事業者のアカマイの3社など多くのクラウド事業者やサービスプロバイダーがIPv6に対応。この3社がIPv6対応したことで、もしもv4とv6が両方使えるならすぐにトラフィックの半分はIPv6化されるという。
SDN/NFVのような最新テクノロジーも妥当なところで使っている
もう1つの取り組みが、ご存じSDN/NFVだ。NTTコミュニケーションズは、世界に先駆けて商用サービスでいち早くSDN/NFVを取り込んでいるが、こうした取り組みの背後には宮川さんをはじめとしたR&Dの“目利き”がある。
「NFVという言葉が出てくるかなり以前に、シリコンバレーの友人から、今度ハイパーバイザーの上でジュニパーのOSが動くんだよねという話を聞いた。シスコもIOSも同じことになりそうだと。私も数年前からいじらせてもらったりして。結果的に去年出たSRX（ジュニパー）の仮想版のニュースリリースには私のコメントも載りました」
「SDNに関しても、Nicira（現VMware）のマーティン・カサド氏から直接話を聞いて、さんざん盛り上がった。ただ、最初はルーターによる分散は止めて、全部集中に戻すんだみたいな図を見たんで、これは嘘だろうと思った。SDNってデータセンターや局所的に使うのはとてもいいんだけど、インターネット全体をエンドツーエンドでSDN化して、パスを全部制御しようとするとスケールしないと考えた」
「分散化されたネットワークは、100台のルーターがルーティングテーブルをばらばらで持っていて、全体で1万のステータスを作る。でも、当初一部でいわれていたように1万のステータスを1台のルーターに持たせようとすると、割に合わない。100倍のメモリを積んでも、コストが全然合わないんです。適切に ステータスを分散するのがインターネットのキモなので、完全にセントラルなのはたぶんない。局所的にSDN化された雲がインターネット的にくっつき要所でキラッとした機能を魅せるというのがよいSDNだと思います」
「局所的にSDN化された雲がインターネット的にくっつくというSDNが僕の見解です」
現在のNTTコミュニケーションズのサービスでは、たとえばバックアップのためのトラフィックが流れると、ダイナミックに帯域を調達してくるといった制御にSDNが使われている。通信事業者の運用負荷を下げるというだけではなく、ユーザー側のベネフィットを考慮してサービスに盛り込んでいるのが特徴だ。
「自慢になってしまうけど、うちの会社はSDNの使い所をわかっていると思いますよ。現在、SDNはデータセンターを結ぶところで使っている。OCNでSDN同士をつないだり、データセンターとMPLSのVPNのつなぎ目をSDN化することはある。でも、OCNのバックボーンをSDN化すると言ったことはない。長い経験に裏打ちされているから、こういうところで使うといいよねというところにSDNとNFVを使っている。コスト面で妥当なところで使っているし、極論に走らない」
「今後はたとえばDDoS攻撃の防御に使うとか考えています。うちの会社のバックボーンはDDoS攻撃とおぼしき大量のパケットが来た時に回避できる仕掛けが入っている。今はBGPベースのリダイレクションで顧客への攻撃をひん曲げて、トラフィックをクリーンにして戻せるようになっている。こういうところでSDN使えないかなあとかは思ってますね」
ネットワークサービスを仮想化したNFVの次の使い所はデバイス管理？
一方で、NFVに関しては、従来アプライアンスが必要だったファイアウォールやWAN高速化などのサービスを仮想化することで、クラウド上にデプロイできるようになっている。NFVに関しては、より具体的なサービスのイメージが宮川さんの中にもあるようだ。
「NFVに関しては、お客様宅に置いてあるデバイスの管理に使えないかなあと。ブロードバンドで使うSOHOルーターって、みなさん秋葉原とか量販店とかで買ってくるけど、あれってみんなアップグレードしない。脆弱性があっても知らんと。この問題はキャリアにとってはけっこう頭が痛いんです。本当はネットワーク側から、ファームウェアアップデートしたいんだけど、お客様のものだからそれもできない。だから、お客様のところにはEthernetのブリッジとWi-Fiステーションだけで、うちらの設備側にお客様のNFV的なインスタンスを置ければいいなあと。これならお客様もコントロールできるし、 キャリアからアップデートや機能追加が可能になる」
実際こうしたネットワーク経由でのユーザーデバイスの管理は、一部のキャリアでスタートしているが、コスト面でのメリットが得にくかったり、ネットワーク障害時にIPアドレスの取得すらできなくなるといった課題があり、現実的にはまだ導入が難しい。これに対して、宮川さんはユーザー側にもハイパーバイザーとインスタンスを配布し、キャリア側のNFVとオーケストレーションさせるのはどうかと提案する。
古典的なインターネットの分散指向、キャリアとして進めたい集中管理のメリット、両者をいいとこ取りし、コスト面で現実的なところに落し込むというサービス論。異なる社内の意見をうまく取り込みながら、会社として、お客様にベストなものを追求していくというのが宮川さんの姿勢だ。
（次ページ、もうインフラはいいですよという若者は多いけど……）
