| キーマンに訊くIPv6の過去、現在、未来 連載:IPv6 Trend Review(6) 将来を見据えたIPv6導入 〜デュアル・スタックによる IPv6全社導入への道のり 電通国際情報サービス e-テクノロジー統括部 先端技術研究グループ 主幹研究員 熊谷誠治 2002/7/16 |
![]() |
今回は、全社ネットワークへの完全IPv6導入を実現したユーザーとして有名な、電通国際情報サービスの熊谷誠治氏に登場していただいた。これまで、開発者やサービス提供者の方々にインタビューを繰り返してきたが、ユーザー側の登場としては初となる。導入までの経緯や問題点などを中心に、これからIPv6導入を考えている人たちに向けて、アドバイスとなるような内容をまとめてみた。
(聞き手:@IT 鈴木淳也)
| デュアル・スタックで実現したIPv6全社導入 |
――全社レベルでのIPv6導入を考えた経緯を教えてください。
2001年に全社的にネットワークのリプレイスを行う機会があったのですが、そのタイミングを利用して一気に入れ替えを行いました。ネットワーク・インフラというのは、一度導入すると4〜5年はずっと使い続けるものですから、2001年に導入したとして2005年。そのときにネットワークに必要なものを考えると、自然にIPv6導入となったわけです。
――導入の最初のプランはいつぐらいに考えられたのですか?
最初のプランは、2000年の終わりごろだったと思います。2001年7月にネットワーク関連機器のリース切れが待っていましたので、それを目標に、2001年4月から入れ替え作業を行いました。最初のプランを思いついた2000年末には、ちょうど大阪でIPv6 Summit in Japanというカンファレンスがあったのですが、ここでは「IPv4からIPv6にどうやって切り替えるのか?」といった感じで「IPv4をばっさり切り捨てる」ような論調が主流でした。私は、「なんで、IPv6のデュアル・スタックを使わないのだろう」という考えでしたから、「みんないろいろ苦労しているけど、ひょっとしたらデュアル・スタックならいけるかも」と思ったわけです。そして、全社導入の際には、デュアル・スタックでIPv4とIPv6の両方を使えるようにしたのです。
――デュアル・スタック以外の方法、例えばトランスレーションみたいな選択肢は考えられなかったのですか?
トランスレーションについては、まったく考えていませんでした。ただ、企業によってはIPv4からIPv6への移行末期に、IBMのホスト系マシンといった古い資産がどうしても残った場合など、トンネリングなどの手法と合わせて使用することは考えられます。
――コスト的には、やはり一度にリプレイスを完了させてしまったほうが安上がりなのですか?
そうだと思います。「この部分はIPv4だからトンネルを……」といったことを考えるよりも、一度にすべての機器をIPv6対応のデュアル・スタックにしてしまったほうが、手間も掛からず、安上がりになるでしょう。
![]() |
IPv6導入に際しては、
デュアル・スタック以外の選択肢 は考えていませんでした |
――リプレイスの際に、苦労された点などありますか?
ネットワークが高速化してくると、バックエンドからエッジまでスイッチの導入が増えてきます。ところが現状、レイヤ3スイッチでIPv6に対応したものはほとんどない状況ですから、どうやってルーティングを処理しようかと悩みました。ルータでIPv6のルーティングを行うという方法もあると思いますが、今回、IPv6については透過的に処理して、レイヤ2でのスイッチングにまかせる方法を取りました。
――ファイアウォールについてはどのように処理しているのですか?
現状でIPv6対応のファイアウォールはありませんから、IPv4の通信はファイアウォールを経由して、IPv6の通信についてはパケット・フィルタリングのみということで対応しています。IPv4での接続先が商用ISPで、IPv6での接続先がWIDEというように、インターネットへの接続経路が2種類ある形になっています。
| 将来を見据えた導入例を |
――企業へのIPv6の本格的な導入は、どのくらいから始まると考えていますか?
私の予想では、5年はかからないけど2〜3年は先、ぐらいだと考えています。それよりはむしろ、個人用途での導入が先行すると思っています。現状では、IPv6導入の明らかなメリットが少ない状態ですから、3カ月単位で予算を管理している企業などでは、やはり長期的な投資は難しいでしょう。
――「NATがあるからこそセキュリティが強固に実現できている」という意見もありますが、これについてはどのように考えますか?
外からのアクセスを遮断することが重要であって、決してNATだからというわけではないと思います。NATを使う理由は、IPv4のグローバルIPアドレスが高価だからであって、セキュリティ上の理由からではありません。実際、NATがあれば完ぺきというわけでもなく、弊社の例では内部からのアクセスもプロキシ経由で制御していますし。
将来的に、現在のファイアウォール(NAT)の仕組みを維持していくのは難しくなってくると思います。というのは、数Gbpsクラスのブロードバンド接続が当たり前になってくると、複雑な動作を要求するファイアウォールなどでは、それ自身がボトルネックになる可能性があるからです。そこで、通す/通さないの制御のみファイアウォールに任せて、エンド側の端末に「ゲートウェイ・キーパー」みたいなエージェントを仕掛け、セキュリティが保たれているかを監視するのです。
――水際監視モデルではなく、ゲートウェイとエンド側の端末の両方を監視することで、End-to-Endの通信を実現するのですね。
そうです。IPv6に限らず、IPv4でもブロードバンド接続が当たり前になってくると、このような両方の監視を行うモデルが重要になってくると思います。
|
使いたい時に使える環境
それが重要です |
![]() |
――これからIPv6導入を考えている企業に対して、何かアドバイスみたいなものはありますか?
先ほどもお話ししましたが、現状ではレイヤ3スイッチのIPv6対応がまだまだですので、これをルーティングするためにどのような方法をとるかです。ソフトウェア・ベースのルータを使う方法も考えられますが、将来的な拡張を考えると、レイヤ2スイッチをベースにして環境を組み立てることが考えられます。IPv6を使うための機器を導入することは重要ですが、IPv6を妨げない機器を考えることです。使おうと思ったときに使える環境、それが重要だと思います。
私たちが実験した例なのですが、あるプリンタ・サーバではIPv6パケットを受信すると誤動作し、あるレイヤ2スイッチではIPv6パケットを受信するとブロードキャストしてしまう、といった現象を確認しています。
――レイヤ2スイッチが、IPv6パケットを受信して誤動作するのですか?
おそらく、MACアドレス以外の部分も見ているのでしょうね。主に、レイヤ3スイッチの機能を持った製品でレイヤ2スイッチの機能のみを働かせようとすると起こる現象のようです。こういった例もありますから、「IPv6が動作しない機器のリスト」「IPv6が問題なく動作する機器のリスト」といったものがあったら便利だと思いますね。
――IPv6導入のコツみたいなものはありますか?
例えば、シェアード・ハブの環境にいきなりIPv6を導入しようとすると高いコストがつきますが、これを「レイヤ2スイッチ」「QoS」「マルチキャスト」といった要素ごとに分解して導入を行っていくと、IPv6への敷居はぐっと低くなります。ここまで導入すれば、ほとんどIPv6の持つ機能と等価になるからです。
導入におけるケースは、ユーザーにより千差万別である。だが、実例として参考にできる部分も多々あるだろう。今回のインタビューをご覧になって、何か得られるものがあっただろうか。ぜひ今後来るだろう、IPv6導入の時に向けて。
次回は、IPv6普及のカギを握るといわれている、クライアントOSベンダの最大手に登場してもらおう。マイクロソフトの及川氏に、今後の展望などについて語っていただく予定だ。
| 「Master of IP Network総合インデックス」 |
TechTargetジャパン
- 「ネットワーク仮想化」がもたらすもの (2012/5/25)
キャリアイーサネット網で展開されているVPNサービスをSPBに置き換えると、どんな変化が起こるのか - 「Meteor」で来れ、1億総Webアプリ開発者の時代 (2012/5/16)
文系人間の筆者でも、「これならWebアプリ開発、できるかも」と思わせてくれるフレームワーク、Meteorの可能性を予想してみたい - ついに来た? 「真のIPv4アドレス在庫枯渇」 (2012/5/14)
IANAやAPNIC/JPNICが管理するIPv4アドレスの在庫が枯渇してから1年。いま、水面下で「真の枯渇」が始まりつつあります - SLB-PTでWebサーバをさくっとIPv6対応に (2012/4/26)
いくつか存在するIPv6移行ソリューションの中から、SLB-PTを用いて、さくっとWebサーバをv6対応させる方法を説明
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -



