IPv4とIPv6は異なるプロトコルであるため、
第12回は、
IPv6のコンサルティングとは？
- ──IPv6コンサルティングをされているとのことですが、
具体的な内容を教えてください。 私の仕事をご紹介させていただくと、
私はコンサルティングを行っています。まずお客様の現状を把握することを行いますが、 それにはネットワーク全部のことを伺います。そのうえで、 考えられる手法をいくつかご紹介しますと、 いまいただいたご質問のように、 「で、 どれがいいのでしょうか？」 と言われます。 次はネットワークで利用されている機械を全て把握していき、
それらをIPv6化していくにはいくらかかるかのコスト計算を行います。コスト計算をふまえつつ、 場合によっては一部を中抜きするなど予算に内容を詰めて行くというのが実際です。 最初からジャンプできるかというと、
難しい場合が多いのですが、 とはいえ 「いやいや、 ジャンプしないと困るんですよ」 という方々もいっぱいいらっしゃいます。 - ──どういったコンサルティングをされているのでしょうか？
6rd
（IPv6 rapid deployment） を説明してくださいとか、 MAP （Mapping of Address and Port） を説明してくださいというような案件であれば、 弊社にはタレントが多いので、 そういった説明が得意な社員が説明に伺います。ざっくりと 「IPv6したい」 というようなご相談をいただくと、 私のところに回ってくることが多いです。 「とにかく全部を聞きたい」 という感じなのですが、 ご説明が終わると 「ああ、 そうだよね」 となることが多いです。 - ──そういった案件は多くあるのでしょうか？ 各お客様は、
どうして 「IPv6をしたい」 となるのでしょうか？ 割とありますね。
IPv6が必ず必要となるネットワーク。たとえばモバイルキャリアさんなどで、
LTEが導入される前の検討段階で相談いただいた事もありました。モバイルネットワークがIPv6化されると、 それに伴いデータセンターもIPv6化される必要があります。 あとは、
エンタープライズのお客様でも、 「ざっくりと聞きたい」 というのはあります。 「どうやればいいのか」 という問い合わせは多いです。 エンタープライズネットワークは、
新しくネットワークを組み直すときには2年ぐらいかけて準備したりします。まず、 検討や設計を開始してからデプロイするので、 結構時間をかけます。最初にめぼしいところを聞いておいて、 それからプロジェクトを走らせます。 - ──問い合わせ件数は最近増えていますか？
前からあるのですが、
最近増えたという感想は特にないです。同じぐらいといった感じです。 頻度としては変わらないのですが、
質問をしてくる方々が変わったような印象はあります。エンタープライズの方々でも、 それまでそういった分野にあまり積極的ではなかったように思える方々からのお問い合わせをいただくことも増えました。現時点では、 まだあたりをつけているだけの可能性もありますが。 あとは、
メディアで記事が出るとお問い合わせいただくことがあります。 「IPv4枯渇大丈夫か？」 のような方向性の記事が出た時が顕著です。そうなると、 社内の偉い人に言われて調べるという流れのお問い合わせが多いです。記事が出ると影響があります。
IPネットワークv6化で問題となるのは「人的コスト」
- ──既存のIPネットワークをIPv6化する手法について教えてください。
すべての機械をアップデートするのが非常に大変なので、
それをふまえて、 どうやってやっていくのかということを考察することが多いです。 JANOG 29.
5とJANOG 30で発表させていただいた資料 （参考1） があるのですが、 これをもとにお客様に説明させていただくこともあります。この資料では、 概要を説明するために非常にざっくり簡単に3種類にまとめてはいますが、 本当はもう少し細かく分かれるとは思います。 JANOGの会場はISPに勤める方々が多いので、
特に発言する方々はコア系の方々が多いこともあり、 「もうデュアルスタック化は終わったよ」 というおっしゃる方々が多いです。しかし、 IPv4アドレスの在庫が枯渇し、 エンタープライズの方々やモバイルキャリアの方々とお話をさせていただくと、 「これから検討したいから、 どうやってやればいいのか、 ざっくり教えて」 という質問をいただくことが多いです。 このように、
JANOGにいらっしゃる方々と若干離れている部分を感じたので、 そういったお話を今年4月に行われたJANOG 29. 5で5分LTを行い、 JANOG 30でプレゼンを行わせていただいたという感じです。 当時、
事前アンケートをとったのですが、 聞きたい人が100％だった一方、 話したい人は誰もいなかったので、 何人かの方々にお願いをしてパネルセッションという形で発表を行いました。 JANOG 29.
5でのLTを行おうと思ったきっかけとなったのが、 APRICOT （Asia Pacific Regional Internet Conference on Operational Technologies） で行われていた発表です。今年の2月21から3月2日までインドのニューデリーで開催されていたAPRICOTで、 APNICのPhilip Smith氏が、 「IPv6に関してはOSPFよりもIS-ISの方が良いから、 そっちに移行しよう」 というプレゼンテーション （参考2） を行っていました。 APRICOTで行われたOSPFからIS-ISへの移行の背景としてあったのが、
OSPFがIPv4とIPv6で異なるプロトコルであるという事実です。IPv4とIPv6のデュアルスタックネットワークでOSPFを使うには、 IPv4でOSPF v2を利用し、 IPv6はOSPF v3を利用するという運用になります。OSPF v3は、 IPv6専用のものです。 ただ、
APRICOTの発表を聞きながら 「本当かなぁ？」 と思いました。OSPFからIS-ISに移行することに対して機械にかかるコストは特に発生しない場合が多いからです。 たとえば、
弊社の機器であれば、 IS-ISはサポートしています。昔であれば、 IPv6用のライセンスフィーをいただくというのがあったのですが、 2009年から弊社では全社的に 「IPv4とIPv6を同等にしよう」 という取り組みを行っており、 全プラットフォーム的に追加コスト無しでIPv6も使えるようになっています。 しかし、
人的な工数、 作業工数という意味でのコストは非常に多くかかります。既存のIPv4ネットワークが複雑であるのかどうかにも依存します。 IS-ISでOSIのルーティングドメインで障害が発生すると、
IPv4とIPv6の両方で同時に障害が発生します。これは、 IPv4とIPv6を両方同時に扱えるIS-ISがルータ内で単一のプロセスとして動作しており、 そのルーティングプロセスで障害が発生するとIPv4とIPv6の両方が停止してしまうためです。 一方、
OSPF v2とOSPF v3は全く別のものであるため、 ルータ内でも異なるプロセスとして運用されています。そのため、 どちから片方だけの障害で済む場合もあります。このように、 単純にデュアルスタックでIPv4とIPv6と言っても、 運用形態によっていろいろ変わってきます。
参考1
JANOG30: さあ、参考2
OSPF to ISIS migration参考3
1.OSPFによるv6運用 3つの形態
- ──で、
JANOG 29. 5と30への発表となったわけですね。その発表の概要を教えてください。 JANOG 30での発表で私が行った運用形態の分類が、
次の3種類です。 最初は、
デュアルプロセス・ シングルトポロジです。これは、 OSPF v2とOSPF v3を共存させて同じようなネットワークトポロジで運用するというものです。なお、 この 「プロセス」 というのは、 各ルータ内でのルーティングプロセスのことです。 次はシングルプロセス・
シングルトポロジです。これは、 OSIのIS-ISで作るというようなものです。MPLSで組むのも、 この方式になります。MPLSでやる場合には、 まずOPSF v2を利用しルーティングテーブルを作成します。その後LDPやRSVPによりラベルアロケーションを行い、 IPv4やIPv6を別々のアプリケーションとして扱います。IPv6をMPLSバックボーンに統合する手法としてはIPv6 over MPLSである6PEという技術でつなげることが可能です （参考4）。 3つめが、
デュアルプロセス・ デュアルトポロジです。OSPF v2とOSPF v3で別々のトポロジにすることも可能なので、 L3スイッチなどをコアに入れたりしているので、 OSPF v3だけ中抜きしてしまってセントライズドトポロジにしてしまうことも可能です。 - ──3つのパターンをそれぞれ詳しく教えてください。
まずはデュアルプロセス・
シングルトポロジですが、 たとえば弊社機器であればIPv4とIPv6両方ともに利用可能なので、 IPv4のシングルプロセス・ シングルトポロジな環境をデュアルプロセス・ シングルトポロジの環境に変更する機器コストはかかりません。問題は、 それを実現するための工数です。 私が知る中では、
日本ではIIJさんの、 デュアルプロセス・ シングルトポロジでの運用が凄いです。JANOG 30では、 IIJの津辻さんにそこら辺の話を発表していただきました。 図1 デュアルプロセス・ シングルトポロジ 
次にシングルプロセス・
シングルトポロジですが、 コアはIPv4のままでエッジのみIPv6というものです。たとえば、 DMVPN （Dynamic Multipoint VPN） を利用してIPv4 VPNでIPv6を運ぶという手法があります。6rdと組み合わせるというのもあります。 図2 シングルプロセス・ シングルトポロジ 
コアを変更するという方法は、
コアをMPLSやIS-ISに変更してしまうというものです。MPLSは6PEを利用すればいいですし、 IS-ISはOSIのマルチプロトコル対応ルーティングプロトコルなのでOSPF v2とOSPF v3のように別々のプロセスで運用する必要がありません。 非常に先進的でカッコイイと個人的に思うのが、
コアをIPv6のみにしてしまうという方法です。現時点では、 エンタープライズでは、 ほとんど出会ったことがない手法ですが、 コアでOSPF v3のアドレスファミリを規定したRFC5838を行います。 ここで紹介しているデュアルスタック・
シングルトポロジの手法は、 コアがIPv4、 コアがMPLSかIS-IS、 コアがIPv6という違いがあります。とはいっても、 IPv6だけのネットワークという意味では日本国内でのNGNもありますし、 中国のCERNETもあります。そういったところでは、 現在IETFで標準化が行われているMAPというのも近い将来の選択肢としてあり得るかも知れないと思います。 JANOG 30では、
デュアルスタック・ シングルトポロジということで、 ソフトバンクテレコムの工藤さんにトンネル活用事例をご紹介いただきました。 - ──多少話がズレるのですが、
MAPは御社でサポートされますか？ 現時点ではありませんが、
近いうちに出ます。 - ──MAP-E
（Encapsulation） ですか？ いいえ。違います。まずは、
MAP-T （Translation） です （※）。 - ──エンキャプスレーションの方が仕組み的には素直だと思いますが、
トランスレーションが先なんですか？ 実はそうなんです。日本のベンダだと4rd
（Unifiedではない旧4rd） を作成しているのでMAP-Eの方が簡単だと思われますが、 弊社はすでにNAT64を実装していたので、 MAP-Tの方が簡単です。MAP-Eも当然、 今後にはなりますがサポートして行きます。 - ──中断してしまってすみません、
3つ目のパターンを教えてください。 最後は、
デュアルプロセス・ デュアルトポロジですが、 コアがL3スイッチであることを活かしてIPv4とIPv6で異なるトポロジで構築してしまうというものです。 こういった事例は結構あります。
図3 デュアルプロセス・ デュアルトポロジ 
障害の範囲を最小限に抑えるには、
こういった形でアドレスファミリ毎にトポロジの形を変えてしまうというのは有効な手段だと思います。アドレスのアサインメント、 すなわちアドレス設計を考えると、 IPv4ホスト数とIPv6ホスト数が全く違うことが多いので、 こういったトポロジを取りたくなりがちです。 - ──IPv4しか扱えないような機器が残っているような
「歴史的経緯」 によって、 デュアルプロセス・ デュアルトポロジが選択されるというのもありますか？ IPv6もMPLSも扱えないようなノードが残っているという状況は、
結構ありそうですね。そういった環境において、 早くIPv6化するということを考えると、 デュアルプロセス・ デュアルトポロジが選択されるかも知れません。 今のところは、
できる範囲でやってしまって、 将来的に一気にという考え方もあります。たとえば、 今できる範囲でIPv6化をやってしまって、 最終的には最近流行のバーチャルスイッチなどによる一元管理に移行してしまうという方法もありますね。
参考4
RFC4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)
- ※）
- 2012年12月14日にIOS-XR 4.
3.0 がリリースされ、MAP-Tがサポートされました。
データセンターのLAN内でのIPルーティングは不要に？
- ──最近流行の一元管理というと、
ファブリックPathのような手法ですか？ はい。ファブリックPathやCisco VSS
（バーチャルスイッチ） やロジカルスイッチといった手法です。こういった手法はブロードキャストが大きくなってしまって、 センター側が大量のARPやNDPを管理しなければならないという課題はあります。データセンターであれば、 こういうのが流行っています。 一方で、
センター側での集中を嫌ってオーバーレイモデルであるVxLANも流行っています。センター側で集中するモデルは、 「流行だけどもやることを躊躇する」 という話もあるようです。こういった手法の利点としては、 インテリジェントノードが減るので管理コストが少なくなる点が挙げられます。 管理コストを重視する方は、
今後はクラスタリングやバーチャルスイッチなど、 全てを1台のスイッチに見せるような方向へと向かって行くものと予想しています。 - ──それって、
要は 「LAN内にIPルーティングは必要ない」 って言ってますよね？ はい。そうですね。ローカルの中はL3ルーティングを減らしていく流れになっているとは思います。少なくとも、
業界の話を聞いていると、 これで行きたくなるというのはあると思います。 - ──それは、
突き詰めると実は最終的にはIS-ISでやっているという話になりますか？ （笑） ファブリックPathがL2レベルのルーティングをIS-ISで行っているという意味では、 そういう見方もできそうですね。中は、 そうですね。内部パケットとしてはですが （笑）。
JANOG 30その他の話題
- ──JANOG 30で、
その後会場を含めた議論があったと思うのですが、 その結果はどうでしたか？ そこでの議論では、
やっぱりケースバイケースという話になってました。たとえば、 セッションで発表していただいたIIJさんとソフトバンクテレコムさんだけ見てもまったく違います。 ISP系のキャリアだとデュアルスタックは、
デュアルプロセス・ シングルトポロジというのを割とやっています。MPLSを中心にオペレーションを行っているキャリア系だと、 そっちに慣れているのでやりやすいようです。既存網の特徴や、 お金の話もあると思います。 その他、
JANOG 30の時に、 OSPFでのmax metricの話がありました。OSPF v2でメトリックを最大にして、 ノード迂回をさせる方法ですが、 弊社の機器では当時OSPF v3 max-metricを実装していませんでした。そもそもOSPFv2 max-metricはOSPFv2がプロトコルとしてこの迂回機能をサポートしていなかったために、 必要となった機能です。 OSPF v3ではRビットというのが新しくできていて、
Rビットが0だとスタブと判断して迂回されます。つまり元々プロトコルとして全然違うので、 max metricが必要ないと言われてました。こういったプロトコルの違いが弊社の実装の遅れの原因でもありました。 現時点ではmax metricはOSPF v3でも有効な機能として認識されています。
ただ、
そのときに、 会場は割とキョトンとしていました。その反応から、 ひょっとして、 シングルスタックのIGP設計の時点で改善できる部分も多い可能性も感じました。 使われてないので気づかれていないという意味では、
たとえば、 IPv4の便利な機能がIPv6だとプロトコルの違い上実現できないものを事前にお客様にお伝えしてあったとしても、 実際にデプロイを開始されてから 「あれ？ 無い！？ 無い？ 聞いてないよー」 と言われて、 「いやいや、 最初に無いってお伝えしたじゃないですかー」 という感じです。 その後、
「いやぁ、 でもいままでIPv4で使ってたのでどうにか……」 となり、 「わかりますけど……」 と。 - ──実際に使う人が増えないといろいろと認識されない部分が多いということですかね。
そうですね。やはり、
使われて行かないとバグも潰されていかないと思います。 - ──ギャップを埋めて行かないといけないですね。
IPv4とIPv6は違うものだと認識していただくことは重要ですね。
「OSPF v2とv3は一緒だよねー」 という認識だと深みにハマることがあります。 - ──ありがとうございました。