Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

イケてないIPv6とどう付き合う?

14,599 views

Published on

社内勉強会資料。
IPv6がどうイケてないか、IPv6とどう付き合うべきか、というのを説明した資料。

Published in: Internet

イケてないIPv6とどう付き合う?

  1. 1. イケてないIPv6と どう付き合う? 2014/11/4 DMM.comラボネットワーク部勉強会資料
  2. 2. 本日のプレゼン資料について いつもどうでも良い写真が多すぎる、 と言われたので、 今回は文字だけプレゼンに挑戦!!! けっして手抜きじゃありません。
  3. 3. V6を語るときに知っておきたい知識
  4. 4. V6 〜 V型6気筒エンジン 直列4気筒に次いで広く自動車用エンジンに用いられてい る。 ... V6ではその片側バンクに相当する直列3気筒と同様に、1 次・2次振動は共にバランスするがエンジン全体を揺り動か す偶力振動が発生する。 ... 90°バンクV6は『6気筒エンジンパッケージとしては、スペー ス及び効率面が起因する妥協の産物』と評するものもいる。 wikipedia: V型6気筒 http://ja.wikipedia.org/wiki/V%E5%9E%8B6%E6%B0%97%E7%AD%92 wikipedia: 直列3気筒 http://ja.wikipedia.org/wiki/%E7%9B%B4%E5%88%973%E6%B0%97%E7% AD%92
  5. 5. V6 〜 ジャニーズのアイドルユニット 20th Century (年長組、トニセン) ●坂本昌行 (1971年生) ●長野博 (1972年生) ● 井ノ原快彦 (1976年生) Coming Century (年少組、カミセン) ●森田剛 (1979年生) ●三宅健 (1979年生) ●岡田准一 (1980年生)
  6. 6. V6メンバーの年代に対応する将棋プロ棋士 (トニセン) 羽生世代 (1969年度から1971年度生まれ) (カミセン) 渡辺明 (1984年生まれ) 山崎隆之 (1981年生まれ) 飯島栄治 (1979年生まれ) 橋本崇載 (1983年生まれ) 松尾歩 (1980年生まれ) 阿久津主税 (1982年生まれ) 宮田敦史 (1981年生まれ) 片上大輔 (1981年生まれ) ※メンバーは抜粋してます。
  7. 7. 突然だけど、 IPv4、IPv6が、 いつ誕生したか知ってる?
  8. 8. IPv6 の歴史(Wikipediaより) 1981年9月 RFC 791として、現在のIPv4のもととなる仕様が公開される。 1991年7月 「IPv4アドレスが不足する」という研究を受けてIETFが調査を開始した[3]。 1992年11月 RFC 1380という形で調査結果をまとめ、次世代ネットワークの議論が始ま る。 1993年12月 RFC 1550としてIPngの名称で機能要求をまとめる。 1995年1月 RFC 1752としてSIPPをベースにアドレスを128bit化、同時に名称をIPngか らIPv6に正式に改名。 1995年12月 RFC 1884 IPv6 Addressing ArchitectureとしてIPv6の最初の仕様を決 定。 1998年7月 RFC 2373として仕様を大幅修正。同時期にIPv6関係RFCも大幅に改定。 1998年12月 RFC 2460 Internet Protocol, Version 6 (IPv6) Specificationとして主な 仕様が確定する。 1999年07月 IANAによるIPv6アドレスの割り振りが開始される。 http://ja.wikipedia.org/wiki/IPv6より抜粋
  9. 9. IPv4 → カミセン → 将棋棋士だと山崎世代 IPv6 → 1990年代 → 将棋棋士だと豊島以降
  10. 10. 豊島より若いプロ棋士一覧 豊島将之 (1990年生まれ) 澤田真吾 (1991年生まれ) 永瀬拓矢 (1992年生まれ) 菅井竜也 (1992年生まれ) 石井健太郎 (1992年生まれ) 黒沢怜生 (1992年生まれ) 高見泰地 (1993年生まれ) 斎藤慎太郎 (1993年生まれ) 三枚堂達也 (1993年生まれ) 三枚堂達也 (1993年生まれ) 佐々木勇気 (1994年生まれ) 阿部光瑠 (1994年生まれ) 八代弥 (1994年生まれ) 千田翔太 (1994年生まれ) 増田康宏 (1997年生まれ) ※豊 島世代、という言い方はまだ確立していないが、豊島世代というと、豊島より少し上 の年代も含むことが多い。 具体的には、豊島と同時期にプロ入りした、糸谷、中村大地、佐藤天彦、稲葉、等も同 世代とされることが多い。 ちなみに豊島は16歳でプロ入りしている。
  11. 11. まとめ UNIX → トニセン → 将棋棋士だと羽生世代 IPv4 → カミセン → 将棋棋士だと山崎世代 IPv6 → 1990年代 → 将棋棋士だと豊島以降 歴史を考える際に、同時代のものを並べてみると意外と面白 かったりする。
  12. 12. というのはさておき、 今日はIPv6の話をするんだったね。 そろそろ真面目にいくよ
  13. 13. まずは、OSI参照モデル wikipedia: OSI参照モデル http://ja.wikipedia.org/wiki/OSI%E5%8F%82%E7%8 5%A7%E3%83%A2%E3%83%87%E3%83%AB 7 アプリケーション層 6 プレゼンテーション層 5 セッション層 4 トランスポート層 3 ネットワーク層 2 データリンク層 1 物理層 レイヤ構造を取ることにより、各レイヤを柔軟に変更可能。 インターネットのプロトコルもこのモデルで考えれば良かったん だけど、、、、、
  14. 14. インターネットでの実装はこんな風に作られることが多くて、、、、 wikipedia: インターネット・プロトコル・スイート http://ja.wikipedia.org/wiki/インターネット・プロトコル・スイート 4 アプリケーショ ン DNS、FTP、HTTP、SMTP、TELNET等 3 トランスポートTCP、UDP 2 インターネットIPv4、IPv6 1 リンクイーサネット、WiFi、PPP等 なんと4層しか考えてない!! しかも、2つめのレイヤは、IPv4、IPv6の2つしかない!! アプリケーションは、IPを直に見る必要がある!!
  15. 15. リンク層は柔軟に交換可能 アプリケーションは、リンク層は直に見る必要はない。 リンク層はインターネット層(IP)とのバインドさえできれば柔軟に 交換していくことができた。 10BASE-T→100BASE-TX→1000BASE-T→10GBASE-T 時代に合わせて高速化
  16. 16. ところがIP層は、、、、 IPの層を交換しようとすると、そこに紐付いているアプリケーショ ンのバインドを変更する必要がある。 アプリケーションの数は膨大にあるので変更はかなり大変。 4 アプリケーションDNS、FTP、HTTP、SMTP、TELNET等 3 トランスポートTCP、UDP 2 インターネットIPv4、IPv6 1 リンクイーサネット、WiFi、PPP等
  17. 17. 3.5層を作れば良いのでは? 3層と4層の間に、3.5層のようなものを入れればIP層の交換は簡 単になるんじゃ? 具体的にはDNSによる名前解決をちゃんと入れれば良い? 4 アプリケーションDNS、FTP、HTTP、SMTP、TELNET等 3 トランスポートTCP、UDP 2 インターネットIPv4、IPv6 1 リンクイーサネット、WiFi、PPP等 アプリケーションをちゃんと書こう、って言ってる人の多くはこのやり方を支 持している。
  18. 18. そんなに甘くない たとえば、、、、 DNSを引くのはちょっと時間がかかるよね? IPアドレスはハードウェア処理できるけどDNSはハードウェア処 理できないよね?処理コストが高い。 というか、そもそもカプセル化されてないのでレイヤーになってな いじゃん。。。 DNSを引いても、実際へのアクセスはIPでやってるわけで。。。 実際にはDNSでは役不足。 とはいえ、3.5層を真面目に実装する、というのはアリ
  19. 19. たとえばこんな3.5層を実装すれば良くね? Service UUID(SUUID)とかいう層を作ってやる。 パケットはこんなの↓ Ether IP TCP SUUID DATA SUUIDが固定長ならハードウェア処理も可能。 DNSは、SUUIDを引くシステムとして利用するとか。 というかこういう構造は様々なアプリやフレームワークも作ってる。OS側で真 面目に面倒を見る層をちゃんと定義すれば良いんじゃね???
  20. 20. UUIDの規格 Wikipedia: UUID http://ja.wikipedia.org/wiki/UUID RFC 4122 - A Universally Unique IDentifier (UUID) URN Namespace http://tools.ietf.org/html/rfc4122 ちゃんと3.5層にUUIDを実装すれば、LocationとIDentifierを無 理矢理IPv6パケット内に実装するような不恰好なやり方をしな いで済むはず。 3.5層を実装すれば、IP層を適切に交換していけるはず。 IPv12とか作りたいよね??
  21. 21. そもそも何でIPv6を作ろうと思ったのか? そもそもの動機 1.IPアドレスが足りなくなる 2.経路増加対策 ところが、、 1.IPアドレスが足りないのはNATでなんとかなるんじゃね? 2.経路が増えてもハードウェアの進歩でなんとか頑張れたよ と、そもそもの問題には別の解決方法で対応できた。
  22. 22. それでもIPv6をやる理由 IPv6で同時に実現したかったこと 1.IPsec 2.自動設定 3.シンプルなヘッダ構造 4.簡便なエラー処理 欲張った結果、、、、、、 IPv6はIPv4との互換性がなくなった。。。。
  23. 23. IPv6は、IPv4とは別のネットワークである IPv4からIPv6へ移行しなきゃいけない、と言ってる人がいるけど、 ● さまざまな大人の事情でそう言ってる ● 良くわかってなくて流されて言ってる このどちらか。 そういうことを言われたら残念な顔をしてスルーすればOK。
  24. 24. 我々がやらなきゃいけないこと IPv6への移行 ではなくて 新しいネットワークの構築 新しいアーキテクチャの構築 新しいシステムの構築 だって非互換なんだもん。。。。
  25. 25. 一般的なウェブシステムの構成をIPv6化 ファイアウォールファイアウォール ロードバランサロードバランサ ウェブサーバ ウェブサーバ ウェブサーバ ウェブサーバ ウェブサーバ ウェブサーバ データベースデータベースデータベース アプライアンスはIPv6でちゃ んと動くの?? 機器の冗長化はどうやって取 るの?VRRPはgarpを使うけ ど、IPv6はarpを使わない。 今まで通りNATで良いの? IPv6ではNATを使わないで みたいなことを言ってるけど。 データベース等のバックエン ドはIPv6でもちゃんと動くの? MySQLですら5.5でやっと IPv6に対応。 DNSの逆引きとかどうすん の? 疑問がいっぱい
  26. 26. これからのアーキテクチャ ● そもそも対応するアプリケーションを絞るべき? ● 3層と4層の間に、ちゃんとした3.5層のようなものを入れるべき? ● すべてフラットなネットワークで接続して、SDN的な仕組みでアクセ スルールを作っていく?。CISCO ACIとかね。 ● 進化可能なアーキテクチャという視点で構築していくべき? ● セキュリティも考えなきゃねえ。 ● ハードウェアの進化に合わせてアーキテクチャも変化できるように。 ● そもそもやりたいことは何だっけ?そこがぶれないように。 こういうことを考えながら作っていく必要がある。 IPv4時代の定番アーキテクチャを超えた考え方も必要
  27. 27. 単純にIPv6を使うと良いところもあって、、、、 ● アドレス数が単純に多い → IoT なんかで便利、携帯端末なん かにも便利 ●自動設定が楽 → クラウド基盤等に便利、IoTなんかでも便利 ●費用が安い → アドレスが安い、トランジット費用が安い ●新しいアドレスを取るのが楽 → 事業のスピードアップ このへんのメリットがあるところから、IPv6は確実に広まっていくはず。 ユーザ向けのアクセス回線のIPv6化は急速に進むと予想される。 東南アジア等、急速にインターネットが普及している地域では標準的な接続 がIPv6になる可能性はある。 ユーザに配られるアドレスはIPv6になっていく?
  28. 28. ユーザに配られるアドレスがIPv6になった場合、 IPv4のネットワークにはどうやって繋がるのか? おそらくISP側で、IPv4のネットワークに繋がるトランスレータを準備するは ず。(速度が遅かったりする可能性はある) Googleは、Google Cacheで頑張るはず。(Googleの独自プロキシ、Google のフィルターがかかる)
  29. 29. DMMでやらなきゃいけなさそうなこと ● とりあえず勉強はしとかないといけない。 ● ユーザにIPv6アドレスが配られた場合のアクセスに対応できるように準備 しておく ● ログをどう取得していくか等は早急に考える必要がある。 ● キャリアグレードNATからのアクセスとかでもログをどう取得するかは 考えなきゃいけないしね ● 自前でIPv6でサービスを行なうことを検討する ● 自前でやるなら当座はトランスレータで対応するのが楽かな? ただし、IPv6化をすることで問題が発生する可能性はあるので、そこは注意 が必要。 IPv6化しない選択肢もあり。
  30. 30. IPv6ネットワークへのサービス提供のあたって予 想されるリスク ● 接続に時間がかかる ● 特定のサービスが動かない ● 障害対応時間の増加 ● 開発工数の増大(主にテスト工数) リスクへの対応策は決めてからIPv6化は進めたい。 障害対応時間の短縮、テストの自動化等は、IPv6へのサービス提供するし ないにかかわらず進めていきたい。
  31. 31. まとめ IPv6はなぜいけてないのか? インターネット・プロトコル・スイートがそもそもいけてない。IP層が交換可能 になるように作られていない。 IPv6で解決したかった問題は他の手段で解決済み。空振りな感じ。 IPv4と互換性がないので、まったく別のネットワークを作らなきゃいけない。 別のネットワークでは今までのやり方が適用できない可能性がある。 別の考え方が必要になる。 それでもIPv6化は進む。 メリットがないわけじゃないので。
  32. 32. さて、どうしよっか??? ● 面白そうだからIPv6化をガンガンやる? ● まだIPv4だけで頑張る? ● 実験的にIPv6化したサービスを作っていく? ● これからのアーキテクチャの検討もちゃんとしとく? ● クラウドの内部ネットワーク作るのに便利かもしれないから、そこは積極的 に導入してみる? ● 社内からもIPv6でアクセスできるようにする? ● 3.5層を真面目に作ってIPv12に備える?IPv12も作っちゃう? まあ何か作ってみないと、勉強にならんかなあ。 どうしようね?? YouがCanならDoしちゃいなよ!(ジャニーさんの名言)(ジャニーズネタ回収)
  33. 33. V12 〜 V型12気筒エンジン エンジンの振動の面から見ても、カウンターウエイトやバラン スシャフトを用いずとも一次振動・二次振動および偶力振動 を完全に打ち消すことができる構成であり、直6のバランス の良さがもたらす滑らかさは、「シルキースムーズ」とも例え られている。 林義正は、レシプロエンジンでは振動がなくパワーも出せる 直列6気筒がベストであり、理想のエンジンを作るなら直6 かV12の2形式以外ありえないとしている wikipedia: V型12気筒 http://ja.wikipedia.org/wiki/V%E5%9E%8B12%E6%B0%97%E7%AD%92 wikipedia: 直列6気筒 http://ja.wikipedia.org/wiki/%E7%9B%B4%E5%88%976%E6%B0%97%E7% AD%92
  34. 34. でも、IPv12の名前は使えないかも IPv12という名前を使って本を書いてる人がすでにいるんだよねえ。 Internet Protocol v12(IPv12) by Dr.A.B.Rajib Hazarika,PhD,FRAS,AES http://ja.scribd.com/doc/119298172/Internet-Protocol-v12-IPv12-by -Dr-A-B-Rajib-Hazarika-PhD-FRAS-AES
  35. 35. おしまい

×