第2回 IPv6オペレーションズフォーラム

9月4日に第2回IPv6オペレーションズフォーラムが開催されました。

「JPIX : 第2回 IPv6 オペレーションズフォーラム 開催のご案内」

発表資料：IPv6オペレーションズフォーラム第2回 発表資料PDF

2009年3月4日に開催された第1回と同じ品川イーストワンタワーでの開催でした。 今回はNGN＋IPv6に関しての議論が前回と比べて落ち着きつつあることもあり、記事掲載許可を頂けたので内容を紹介したいと思います。

超満員

前回の主題は日本国内におけるNGNとIPv6に関してでした。 その頃は、NGNとIPv6の関係がどうなるのかに関して非常に流動的な時期であり、方向性によっては日本国内のインターネット事業者の構成(プレイヤー)が大きく変わってしまうという懸念があったため、非常に大量の参加者が集まっていました。 (あまり参考にならないかも知れませんが、2月頃に書いた記事です「2009年度はIPv6移行がリアルになってくると予想」)。

第一回は、140席の会場が開場後すぐに満席となり、立ち見や座り込みが発生する状況でした。 インターネット通信インフラに関連する企業の方々が非常に多く居たと思われます。 例えば、ISP、通信機器メーカ、IX、DNS関連、学術機関などですかね。

前回がそのような状況だったこともあり、今回はかなり多くの参加者が早めに会場へ行ったため会場時間頃には既に席がなくなるような状況でした。 今回は、前回よりも参加者が多いぐらいだったかも知れません。 今のところあまり記事として公開されていないように思えますが、非常に参加者が多いフォーラムだったと思います。 なお、次回は半年後ぐらいになるそうです。

プログラム

以下、JANOGメーリングリストに流れていたプログラムです。

●プログラムタイトル及び発表者

 タイトル : IPv6への取り組みと、今後のサービス計画
   発表者 : 小山 海平 (株式会社倉敷ケーブルテレビ)

 タイトル : マルチプレフィックス問題は終息せず
            −ＮＡＴ６６に関わる諸問題−
   発表者 : 石田 慶樹 (日本インターネットエクスチェンジ株式会社)
            印南 鉄也 (ソフトバンクBB株式会社)

 タイトル : IPv4/IPv6デュアルスタック考察
            −Dual-Stack Lite、6to4、Teredo、6RD−
   発表者 : 河野 美也（ジュニパーネットワークス株式会社）
            谷津 航 (Tokyo6to4プロジェクト)
            土屋 獅子生 (シスコシステムズ合同会社)

 タイトル : IPv6/IPv4デュアルスタックの見える化監視に関する取り組みと、
            開発におけるごまめの歯ぎしり
   発表者 : 衣笠 学 (株式会社クラウド・スコープ・テクノロジーズ)
            林 經正 (株式会社クラウド・スコープ・テクノロジーズ)

 タイトル : IPv6サイト構築
   発表者 : 水越 一郎 (NTT東日本)

 タイトル : IPv6逆引き自動生成DNSサーバ
   発表者 : 藤原 和典 (株式会社日本レジストリサービス)

ラフなログを取ったので参考にならないかも知れませんが、よろしければご覧下さい。

• IPv6への取り組みと、今後のサービス計画
• マルチプレフィックス問題は終息せず −ＮＡＴ６６に関わる諸問題−
• IPv4/IPv6デュアルスタック考察 −Dual-Stack Lite、6to4、Teredo、6RD−
• Tokyo6to4の紹介
• IPv6 Rapid Deployment on IPv4 infrastructures(6rd)
• IPv6/IPv4デュアルスタックの見える化監視に関する取り組みと、開発におけるごまめの歯ぎしり
• Dual stackやめませんか？
• IPv6逆引き自動生成DNSサーバ

以下、各発表の概要です。

1. IPv6への取り組みと、今後のサービス計画 -株式会社倉敷ケーブルテレビ-

倉敷ケーブルテレビ社における顧客回線へのIPv6提供に関しての説明でした。 数年前からIPv6に取り組むと同時に、他のケーブルテレビネットワークも参考にできるようにノウハウ等を公開していく(している)とのことでした。 基本的に「しれっとIPv6を提供する」という方針で来年始めぐらいのサービスインを予定しているそうです。

「どのような形でIPv6サービスを開始するか？」というのは実は大きな課題の一つだと思います。 例えば、ある日を境に多くの回線にIPv6を提供し始めるか、申し込んだユーザに順次提供して行くかなどがありそうです。

IPv6を導入したからといってユーザとして新しい事が出来るというわけでもない場合が多く、付加サービスとして課金しにくい一方で、IPv4の枯渇を考えると対応しないわけにもいかないという苦悩がありそうだと個人的に感じました。

発表の中に、ケーブルテレビのネットワークを利用して通信を行う業界標準な技術仕様であるDOCSISについての解説や、IPv6とDOCSISの関連などが解説されていました。 DOCSIS 3.0からチャンネルボンディング、DES→AES、IPv6対応などが規定されたそうですが、現在モデム端末の8割がDOCSIS 2.0で、残りの2割が1.1や3.0との事でした。 昔であればユーザの家庭に入っている端末を交換するなどの対応をしていたそうですが、昨今は信用してもらえなかったり家に上げてもらえないなど色々大変だそうです。

そこで、DOCSIS 2.0の端末のファームウェアだけをアップグレードしてDOCSIS 3.0化しようとしているとのことでした。 USのラボでは「恐らく動くと思う」というような返事をもらっているようです。 ファームエェアをあらかじめアップデートしておき、モデムをリセットしたところで3.0に変わっているという感じだそうです。

Q&Aの時に「IPv6化のコストは？」というような質問がでていました。 現状では設備面でのコスト増はないとのことで、主なIPv6化のコストは人件費だそうです。

あまり本筋とは関係がありませんが、個人的に「なるほど」と思ったのが、ハウジング事業にも力を入れているという部分です。 ユーザに対してインターネット接続性を提供しているCATV網でのトラフィックは下り方向が多く、CATVから外部へ出て行くトラフィックが少ない傾向があるので、ハウジング事業を同時に提供することが効率的なんですね。

2. マルチプレフィックス問題は終息せず −ＮＡＴ６６に関わる諸問題−

2つ目の発表はNGN＋IPv6に関する話題です。

まず最初にマルチプレフィックス問題の解説が行われていました。 最近話題なのはNTT-NGNにおいて発生するマルチプレフィックス問題であり、昔から指摘されているマルチプレフィックス問題は別の話であるという事を指摘しながらの解説でした。

そもそものマルチプレフィックス問題とは、IPv6の仕様によって発生する問題です。 IPv6では複数のプレフィックスが設定可能であり、あるエンドノードがパケットを出す場合にパケットにつけるソースアドレスをどれにするかという話です。 付けたソースアドレスによって通る上流ASが変化します。

この問題は、各ユーザがポリシーテーブルを自分で書けば解決します。 例えば、Vistaならばprefixpolicyを書けば大丈夫です。 ただ、それを普通のコンシューマユーザに求めるのかどうかという別の問題があります。

またクローズドな環境内だけで使うDNSと一般のインターネット用のDNSを併用したいときに発生する問題もマルチプレフィックス問題としてあるという話がされていました。

次に、NTT-NGNにおけるマルチプレフィックス問題が解説されていました。 NTT-NGN問題は、ネットワークトポロジの問題です。 閉域網であるNTT-NGNが存在しており、そこでマルチプレフィックス問題が発生することがわかっており、ビジネスがかかったプレイヤーが非常に多く、時間的なリミットが先に決定しているところなどに難しさがあるとのことでした。 特に、IPv4アドレス枯渇の時期が差し迫っているためにデッドラインが決まっていたことによって問題が複雑になっていたそうです。

NTT-NGN問題では、現在4つあった案のうち、案2と案4が利用されることになったそうです。 発表では、案1〜4までをそれぞれ解説していましたが、案2の説明が多く行われていました。

案2はユーザの宅内にNAT66を行うアダプタを設置し、従来のフレッツサービスと同じトンネルを利用する形になるそうです。 トンネル装置はNTT東西が用意するとのことでした。

そのとき、NGN独自サービスを利用する場合にはNGN内にあるDNSを利用するそうですが、毎回どのDNSを使うべきかはアダプタがしかるべき対処をするそうです。 当初はHome Gatewayに追加という形での提案だったそうですが、費用面などの問題でアダプタを配下に収容という形で進んでいるとのことでした。 なお、将来的にはHGWとの一体型が登場し、秋葉原等でも購入出来るようになると言われているそうです。

案4は3つの組織に対してIPv6アドレス持ち込みを許可するという方式です。 ネイティブ方式と呼ばれています。 この方式では、トンネルを有せずにnativeにIPv6が使えます。 ユーザが特別に望まない限りはグローバルIPv6アドレスはISP持ち込みのものだけがつきます。 案4を実現するには、NTT-NGN独自サービスはエンドユーザが利用するDNSに対して細工をする必要があるそうです。

これら案2と案4が認可され、NTT-NGNのIPv6外部接続方式は、これらの2方式になったそうです。

その後、NAT66に関して「本当に問題は無いの？」という発表がありましたが、質疑応答でも「考え過ぎではないか」など色々な意見があったので、今回ここで内容を書くのは割愛させて頂きたいと思います。

3. IPv4/IPv6デュアルスタック考察 −Dual-Stack Lite、6to4、Teredo、6RD−

3つ目の発表はIPv4とIPv6のデュアルスタックネットワークをどのように構築するのかという解説でした。 主に、今ある手法の解説です。

はじめにJuniper Networksの河野氏が、どのような技術提案が行われているかに関する紹介を行い、それに続いてTokyo6to4、6rdの紹介が行われるという形態でした。

全体の紹介では、NAT444, DS-Lite, DS-Lite＋A+P, 64変換, 6to4, 6rdが紹介され、利点/欠点なども紹介されました。 詳しくは発表資料をご覧下さい。

4. Tokyo6to4の紹介

Tokyo6to4の説明と「AS38646 (Tokyo6to4)とピアリングしましょう！」というお誘いでした。

Tokyo6to4は、日本国内でのIPv6普及を促進する一助になれたら嬉しいというモチベーションのもとで運用が行われているようです。 6to4とは、カプセル化技術を利用してIPv4接続性しかないユーザにIPv6インターネットに到達できる方法を提供するものです。 具体的には、IPv6パケットをIPv4パケットでカプセル化して6to4 relayに投げて、6to4 relayがIPv4ヘッダを取り除くという単純な仕組みです。

現在、DIX-IEとJPIXに6to4 relayが置いてあるそうです。 発表では、現在運用上困っているバグに関しての説明などもありました。

5. IPv6 Rapid Deployment on IPv4 infrastructures(6rd)

Ciscoの土屋氏による6rdの解説でした。 個人的に、この6rdという技術は面白そうだと思いました。 でも、恐らく良く理解できていません。。。 もうちょっと真面目に勉強しなければならないですね。。。

6to4技術は技術的には新しくは無く、RFCも2001年4月に出ています。RFC3056("Connection of IPv6 Domains via IPv4 Clouds")。

RFC3056の6to4技術には以下のような特徴があります。

• ステートを持たなくて良い
• オートマチックトンネル
• 6to4用にv6 prefixがアサインされている(2002::/16)。これを皆で使う感じ
• サイトのPublic IPv4アドレスより16進変換され、/48のIPv6 Prefixを作成
• 6to4のanycastアドレスなので、行きと帰りが違ったりする

6rdの特徴としては、各プロバイダに割り当てられたIPv6 prefixを利用する事で、より柔軟なルーティングコントロールが可能になるそうです。さらに、Provisioning,Security,プライベートアドレスも考慮されているとの事でした。 例えば、6rdでは、プライベートIPv4アドレス空間で存在しない筈のサブネットがソースとなるパケットを受け取ってもdropします。 IPv4プライベートアドレスを考慮しているというのは、LSNが強く意識されているのだろうと思います。

なお、Q&Aでの「Q: 6rdを実装している機器はどれですか？」という質問に対して

8月にやっとstandard trackなので、今の時点ではcoming soonですね。ただ、イイ感じには来ています。新しいルータや弊社で言うとISRルータなどありますので、そこら辺でサポートしないといけない技術だと考えています。今言えるのはそれぐらいですかね。恐らく来年ぐらいには製品名やロードマップが言えると思います。

という感じの回答がされていました。 個人的な感想としては、この6rdは実は結構使われるかも知れない技術かも知れないと思いました。

6. IPv6/IPv4デュアルスタックの見える化監視に関する取り組みと、開発におけるごまめの歯ぎしり

IPv4とIPv6を管理するための管理ソフトウェアの紹介が行われていました。 詳細は発表資料をご覧下さい。

7. Dual stackやめませんか？

時間がおしていたこともあり、非常に駆け足でプレゼンは終わってしまいましたが、「なるほど！」と思える発表でした。 個人的には、コロンブスの卵的な発想だと感じた面白い内容でした。

最初に結論を言ってしまえば「Webサーバのデュアルスタック化なんてやめてIPv6だけで運用しちゃいましょうよ！」という感じです。

まず、プレゼンの前半で今後IPv4とIPv6のデュアルスタック化するWebサーバやロードバランサの説明がありましたが、その後、次のように「異議あり！！」というスライドが出てきました。

どういう異議なのかと思ったら「新しいコードはv6だけに対応しよう」という話でした。 「何それ？どんだけ無理言ってるんだ。。。」と最初はちょっと思いました。 それだけを見ると暴論のように思えるかもしれませんが、その後の内容を見るとかなり納得できました。

この発表の前提として、大規模Webサーバの運用にロードバランサが使われているという現状があります。 ロードバランサによってNAT(NAPT)が行われているわけですが、IPv6対応のために6to4機能とロードバランサを組み合わせてしまうというソリューションを実現した製品などが世の中にあります。

これを逆手にとって、「Webサーバ側はデュアルスタックにするよりも全部IPv6にした方が楽なんじゃない？」という提案でした。 確かに、今後LSNなどが使われるようになる事を考えると、IPv4での運用にIPv4アドレスだけではなくポーと番号も同時にログに保存しなければならなくなります。 それなら、いっその事、IPv4アドレスとポート番号情報を4to6変換してIPv6アドレスの中に埋め込んで使ってしまえば良いという提案でした。

凄く面白い発表でした。 今後、IPv4アドレス枯渇やIPv6への移行が本格化すると同時に、こういった細かいノウハウが徐々に出てくるのだろうと思います。

8. IPv6逆引き自動生成DNSサーバ

ISPが提供しているアクセス回線に対してIPv6の逆引きをどうやって登録するか？ もしくは、そもそも登録する必要ってあるの？という話題です。 前回のIPv6オペレーションズフォーラムで非常に盛り上がったネタです。

現在、多くのISPでは、ユーザに割り当てる全てのIPv4アドレスにISPのドメイン名がついた逆引きを設定しています。 これは、送信元IPアドレスを元にDNS逆引きを行い、さらにそのホスト名でDNSに問い合わせを行って同じIPアドレスになるかどうかを確認する逆正一致チェック(PARANOID check)を通過させるためです。

ただ、IPv6はアドレス空間がIPv4とは比べ物にならないぐらい多いので、可能性がある全てのIPv6アドレスに対してあらかじめ逆引き用の設定を行うことができません。 IPv6の/64のアドレス数は2の64乗個であり、それは約1.8*10の19乗 → 約1800京 → 約18E(エクサ)です。 例えばこの/64をゾーンファイルに書くと、一行100バイトで1800エクサバイトになります。 これは現実的な値とは言えません。

これをどうするかに関してはIETFなどで議論されておりドラフトもあるようですが、JPRSの藤原さんが実験的にperlで逆引き自動生成プログラムを作って今回のフォーラムで発表されていました。 詳細は発表資料PDFを見て頂くのが良いと思いますが、「ユーザに割り当てたIPv6アドレスの逆引きとして、IPv4のときのような機械的なホスト名を自動生成することは可能である」「応答性能については、Cで実装すれば十分な性能が得られる」という結論に達していました。

さて、このIPv6の逆引き設定問題は今後どのような対応が国際的な標準運用になっていくのでしょうか。。。

まとめ

IPv6オペレーションズフォーラムは、IPv6を専門で語り合うネットワーク技術者の会合としては、国内最大規模のフォーラムなのかも知れません。 来年前半ぐらいから徐々にISPがIPv6対応サービスを発表しはじめる気がしますが、その後、IPv6はどのような方向に進むのかに非常に興味があります。

IP層の話なので、ユーザが全く気がつかないのが理想ではありますが、これから2年ぐらいは、インターネットインフラそのものが今とは全て大きく変わるかも知れない時期なのかも知れません。

関連

IPv4アドレス枯渇/IPv6関連記事一覧

最近のエントリ

• 「ピアリング戦記」の英訳版EPUBを無料配布します！
• IPv4アドレス移転の売買価格推移および移転組織ランキング100
• 例示用IPv6アドレス 3fff::/20 が新たに追加
• ShowNet 2024のL2L3
• ShowNet 2024 ローカル5G
• ShowNetのローカル5G企画（2022年、2023年）

過去記事

過去記事一覧