Google は、社内エンジニアの予想よりも時間がかかったプロジェクトで、社内従業員ネットワーク全体に IPv6 を展開しています。
Googleのネットワークエンジニアであるイレーナ・ニコロバは、今週ボストンで開催されたUsenix Large Installation System Administration（LISA）カンファレンスで、全社的な導入について説明しました。ニコロバは、他の組織が自社のネットワークを次世代インターネットプロトコル（IP）に移行する際に役立つであろう教訓をいくつか共有しました。
Googleは、この経験から、IPv6への移行にはソフトウェアとハードウェアのアップデートだけでは不十分であることを学びました。経営陣やスタッフ、特に既に多くの業務を抱えている管理者の協力も不可欠です。また、早期導入企業にとっては、バグや未完成のコードを修正してもらうためにベンダーと多大な協力が必要になります。「サポートされていると宣言されているからといって、必ず動作すると期待すべきではありません」と、プレゼンテーションに付随する資料は結論づけています。
「IPv6への移行を試みた人は皆、私たちと同じ問題に遭遇したと思います」とニコロバ氏は語った。
約4年間にわたって進められてきたこのプロジェクトは、エンジニアリングチームの予想を上回る大規模な取り組みとなりました。まだ半分しか終わっていませんが、この間に同社は大きな成果を上げました。現在、Googleのエンジニアの約95%がIPv6アクセスを利用できます。最終的には、IPv6専用ネットワークを構築する予定です。
このプロジェクトは2008年にGoogleのエンジニア数名によって開始されました。その一部は、Googleがエンジニアに割り当てている勤務時間の20%を、各自のプロジェクトに費やして開発に取り組みました。ニコロバ氏によると、目標は「IPv6 Everywhere」でした。
アップグレードへの関心の一部は実用性にありました。プライベートネットワークではありましたが、Googleの社内ネットワークはパブリックIPアドレスを使用しており、社内IPv4アドレスが不足していました。また、Googleのエンジニアは自社ツールやアプリケーションのIPv6版を開発しており、一般公開前に社内でソフトウェアをテストする必要がありました。
最後に、Googleのエンジニアたちは、IPv6の導入において「鶏が先か卵が先か」という問題に直面していることに気づきました。多くの組織と同様に、GoogleもIPv6の導入が遅れているのは、IPv6で動作するサードパーティ製アプリケーションが不足しているためです。そして、IPv6ネットワークを運用している組織が少ないため、サードパーティ製アプリケーションも不足しています。
Googleの社内ネットワークは世界200以上のオフィスに広がり、約3万人の従業員にサービスを提供しています。このネットワークは、Cisco Systems、Juniper Networks、Aruba Networksなどの企業が提供する多種多様なデバイス、数百もの市販および自社開発のアプリケーション、そしてLinux、Mac OS X、Microsoft Windowsを含む幅広いオペレーティングシステムで構成されています。
エンジニアたちは、ルーティングとトラフィックフローをほぼ同一に保つため、IPv6ネットワークを既存のIPv4ネットワークに可能な限り忠実にモデル化しました。当初は、トンネリングと呼ばれるプロセスを用いて、IPv4ネットワーク上でIPv6を動作させました。その後、実現可能な場合は、IPv4とIPv6を並行して動作させるデュアルスタックを構築しました。最終的には、ネットワークをIPv6のみにすることを計画しています。
IPv6 番号をデバイスに割り当てるために、Google はインターネット技術特別調査委員会の RFC 5375 のガイドラインに従いました。各キャンパスまたはオフィスには /48 のアドレス ブロックが割り当てられました。これは、2 の 80 乗個のアドレスが割り当てられたことを意味します。次に、各建物にはそれらのアドレスの /56 ブロック (約 2 の 72 乗個のアドレス) が割り当てられ、各 VLAN (仮想ローカル エリア ネットワーク) には /64 ブロック (約 2 の 64 乗個のアドレス) が割り当てられました。特定のデバイスに番号を割り当てるために、エンジニアはステートレス アドレス自動構成機能 (SLAAC) を使用しました。これにより、デバイスが自身に番号を割り当てることができます。このアプローチにより、各デバイスに手動で番号を割り当てる必要がなくなりました。また、少なくとも一部のオペレーティング システムでは、IPv6 ネットワーク用の動的ホスト構成プロトコル サーバーベースのアドレス指定メカニズムのバージョンである DHCPv6 がまだサポートされていないという点でも、このアプローチが必要でした。
ニコロバ氏は、大きな問題の一つは、ネットワーク機器やソフトウェアにおける IPv6 のサポートが不十分だったと述べた。
現在、多くのネットワークデバイスはIPv6をソフトウェアでのみサポートしており、トラフィック処理の大部分はカスタマイズされたハードウェアではなく、ソフトウェアで実行されます。その結果、IPv6ネットワークの処理は、IPv4の処理よりも多くのプロセッササイクルを消費します。少なくとも1つの無線機器ベンダーは、ACL（アクセス制御リスト）をサポートしていませんでした。また、ネットワークのWAN（広域ネットワーク）アクセラレーションデバイスは、使用されているプロトコルであるWCCP（Web Cache Control Protocol）がまだIPv6で動作しないため、IPv6トラフィックを暗号化できません。ネットワーク機器に加えて、プリンターも依然として問題を抱えており、多くのプリンターがIPv6を完全にサポートしていません。
アプリケーションとOSの互換性も課題となりました。同社はIPv6をサポートしていないアプリケーションを段階的に廃止してきましたが、データベースや課金アプリケーションなど、多くの重要なツールは容易に変更・アップグレードできないため、現在も運用が続いています。また、ほとんどのOSの現行バージョンはIPv6をサポートしていますが、デフォルトではサポートされていないため、管理者とユーザーに余分な作業が発生しています。
「技術的な問題に関しては、新しい、未検証の、したがってバグのあるコードが多数存在し、すべてが IPv6 をサポートするようにベンダーを調整することが課題となっていることが確認できます」と Google の文書には記されている。
Googleは、Googleのオフィスにネットワーク接続を提供するサービスプロバイダとの連携にも課題を抱えていました。SLA（サービスレベル契約）は、IPv4サービスのSLAほど厳格ではありませんでした。IPv6の個別ポイントへの接続は、IPv4ピアリングセッションよりも時間がかかりました。Google自身も、自社のネットワーク監視ツールをIPv6対応に書き換える必要がありました。
こうした障害にもかかわらず、ニコロバ氏はチームが Google のオフィス内に完全な IPv6 ネットワークを実装するという目標を達成できると確信しています。
「ある時点で、私たちは IPv6 を「新しいプロトコル」と呼ぶのをやめ、IPv4 を「古いプロトコル」と呼ぶようになりました」とニコロバ氏は語った。
ジョアブ・ジャクソンは、IDGニュースサービスでエンタープライズソフトウェアとテクノロジー全般の最新ニュースを担当しています。Twitterで@Joab_Jacksonをフォローしてください。ジョアブのメールアドレスは[email protected]です。
