IPv6への移行と運用の現実
久しぶりにIPv6スレを覗いてみると、IPv6への移行について興味深い講義がリンクされてた。
その講義のスライドをスレの253氏が全訳してくれた。超GJ。
IPv6の現実を知るための資料として、非常に有用なものの一つだと思うので、以下に全文転載する。
なお、読みやすさ等のため一部編集済み。
問題があるようなら御連絡下さい>253氏
ちなみにスピーカーはIIJのRandy Bush氏。
IPv6への移行と運用の現実 (1) 現実治療 (2) - IPv6への移行は行われる。 あきらめろ。 - 問題はいつ、どうやって - マーケティングの夢物語が実際の展開をはばんでいる - この発表は否定的に思われるかもしれないが、バラ色の眼鏡を 外す事で実際の展開のための選択を可能にするためと思って欲しい 概要 (3) - 戯言はもうやめろ （訳注：IPv6推進派に対して） - いい訳はもうやめろ（訳注：IPv6否定派に対して） - 黙って金を出せ （訳注： 下のLucy... のくだりは分からん） どうなるべきだったか (4) （訳注：グラフの解説） x座標は時系列。 右側に向かって未来で左の黒い縦線が「今」。 赤い線がIPv4の空きプールの在庫数で次第に現象。 IPv4の 展開は緑の線で次第の上昇。 紫の線はクラスCアドレスの 取得コストでこれも緩やかに上昇。 実際にはどうなってしまったか(5) （訳注：グラフの解説） IPv4の空きプールが急激に減少、IPv6の展開はずっと遅い。 このことから短期先の予測としてIPv4クラスCアドレスの 取得コストが指数関数的に上昇することが予想される。 なぜこうなってしまったのか(6) 移行計画の欠如 困難な部分が始まる前の勝利宣言 長期計画の欠如 現実的なコスト計算の欠如 現場の人間に対するサポートの欠如 来月には終わるよという態度 上記の項目は何を表しているでしょう？ a) イラク侵略 b) IPv6 c) DNSSec d) 全部 IPv6はIPv4と互換性がない(7) この馬鹿で短絡的な傲慢さは あきれて口も聞けない。 訳注： スライド8のジョークは解らん 合成写真で左はJack Abramoffという悪名高い 有罪判決になったロビイスト。右は IPv6エンジニアのJoel Jaeggli(Nokia?) 俗説をいくつか払い除けよう！(9) 俗説： IPv4は枯渇しつつある (10) - IPv4 非配当領域 (Free Pool) は数年で無くなる - Frank Solenskyが10年前の出した予測とほぼ一致 - IPv4は売買市場に移行する - レジストリはIPv4の割当人ではなく、登記所となる - RIR（訳注: Regional Internet Registry)はRIR, LIR (Local Internet Registry)をまたいでIPv4、IPv6アドレスの 登記情報の認証を行うオープンソースのシステムを 開発している 俗説： IPv6への移行は容易である (11) - IPv6は移行問題をまったくまじめに考えずに設計された - IPv6はIPv4と互換性の無いプロトコルである - 避ける事は可能だった。 例えば可変長アドレスにして IPv4は単に32bit版のアドレスと扱えた - 単純で、有効でスケーラブルな移行機構が全くない 俗説: IPv6でNATは無くなる(12) - IPv6のみのサイトはIPv4ソースアドレスを持たないので IPv4のみにサイトと交信出来ない - 多くのIPv4のみのサイトが10年かそれ以上存続し続ける - 全てのIPv6サイトはIPv4空間が必要でNATとALG (Application Level Gateway)を持つことになる - IPv6は短、中期（10年かそれ以上）に渡ってNATの使用を増加させる 俗説: IPv6はルーティンングの負荷を減らす(13) - IPv6のマルチホーミングはIPv4と全く同じで新たなルーティング モデルは存在しない - IPv6のトラフィック・エンジニアリング(TE)はIPv4と全く同じで 新たなTEモデルは存在しない - 企業は与えられた/32 IPv6アドレスを分割して支社などに割り当てるであろう - ルーティングテーブルは次第によりフラグメンテーション化していく 俗説： 移行はルーティングの負荷を軽減する(14) - 一つの可能性はBGPアドバタイズの市場モデル化 （訳註：たぶん ネットワークのアナウンスを受け取ってもらうのが有料になるというモデル） - 運営が複雑。 ルーティングはグローバルなのでどのように精算するか？ - コスト的な制約がフラグメーンテーションを押さえられるかもしれない - （訳注：最後の一文よく解らん）IPv4互換性をなしにネットワークを運用する コストよりも低くなるためにはアナウンスはいくら位になればいいのか（？？？） 俗説： IPv6空間は無限である (15) - 64 bitはLANに割り当てられる - bitの半分はもう使えない！ - /64をpoint to pointリンクに使っている連中もいる！ - RIRは/32を出しまくっている - 15年後にはこれらの割当はIPv4の初期の/8割当と同じように感じられるだろう。 俗説： IPv6でセキュリティーが良くなる(16) - IPv6は約束はしたが、IPv4で出来ない事はなにも実現してない - IPSecは両方で利用可能 - IPSecはIPv4/IPv6混在のネットワークでうまく機能しない (IPv4のみのホテルからIPv6のホストにVPN接続をする状況を想像してみなさい） - アドレススキャンがより難しくなることは事実であろう - （訳注：最後のジョークちょっとわからない）think ... in hot space 俗説： IPv6でバッテリーが長持ちする(17) (訳注：たぶん以下のプレゼンテーションに対する当てつけ？＿ http://72.34.43.90/IPV6/North_American_IPv6_Summit_2004/Thursday/PDFs/John_Loughney.pdf - 比較はNAT対非NAT - 比較するとしたら - 非NATのIPv4と非NATのIPv6 - NATのIPv4とNATのIPv6 - 結果は同じであっただろう - IPv6陣営の技術よりもマーケティングよりの正体をさらした一幕 俗説： 段階的な展開(18) - 企業においては全ての過程において： バックエンドのデーターベース、 アプリケーション、ファイアーウォール、エッジルーターまで全てが IPv6対応でなければ展開をしない - IPSは設定システム、監視、測定、課金... - そして全てのユーザーがベンダーからのサポートが必要 俗説： ルーターは完全にIPv6をサポートしている(19) - しかし100%ハードウェアでではない (訳注：フォワーディングハードウェアが 対応しておらず、ソフトウェアで行っているという事 == 遅い） - とくにACLを加えた場合（Access Control List) （訳注： ルールによるフィルタリング、 これもハードウェアで処理される） - いいIPv6のトラフィックテスト機器がないためにこれらの事実はよく知られてない - この問題を解決するためのASICを全てのベンダーが開発している訳ではない - IPv4の機能でまだIPv6上で機能しないものがある： MIB, SNMP 俗説： スタティックのアドレス割当が不要になる(20) - セキュリティー上の理由で企業はDHCP等による管理されたアドレスを好むので IPv6の自動アドレス割当は使われない - 同様にISPのバックボーンのアドレスや顧客のアドレスもロギングや監査、警察調査の 目的で知られたアドレスでなければならない 俗説： IPv6は展開されている(21) - 先駆者たちは未だに注意深く進行している - 初期採用者たちはやっと始めたばっかり - 実際に計測されるトラフィックは微々たるもの（それでルーターはトラフィックに 対処出来ている様に見せている）（訳注：括弧内ちょっと意味不明） - それでもいい逸話はある 俗説： IPv6はIPv4を置き換える(22) - バックエンド（アプリケーション）からエッジルーターまでのベンダーの全面的な サポートがない現在の状態では無理 - NATとIPv4を使う方がずっと簡単 - NATとIPv4の組み合わせなら新たな出費、移行、訓練が不要 - アーキテクチャー的には最低だが経済的な現実 現実(23) - 96増えたビット、魔法は無し -- Upadhaya, Gaurab Raj談 - けどビットは絶対にもっと必要 - 重要な問題はそれをどう使うか - 誰も、また何も失わずにどうやって移行出来るか？ 何が出来るか？(24) （訳注：グラフの解説） スライド５のグラフに追加。 IPv6展開の緑の線をもっと急に立ち上がる事を 容易になるように努力しましょう、と緑の矢印 どうやって？(25) - 現在の移行問題を同定する - 問題が修復されるまで追求する - IETFに既存のプロトコル問題を修正する様に要求する - ベンダーにIPv6をサポートする事を要求し、移行するためのツールを要求する - レジストリはIPv4とIPv6アドレス空間での権利書を発行する準備をする必要がある やるべきでないこと(26) - 移行問題が存在しない振りをすること。 あとでもっと悪くなる。 -IPv6を推奨するためにIPv6を妙な方法で割り当てる事。 IPv4の 枯渇が自然にIPv6を助成する - 永久につきあわなければならないゴタゴタを作る事 懸念される／研究されるべき領域 (27) - グローバルな問題 - 管理インフラ - レイア１と２ - バックボーン・エンジニアリング - ラストマイル - 自己インストースされた家庭／SOHOルーター - 企業 - サーバーファーム - キャンパス - 接続ポイント - アプリケーション - 電話 - もっと？ あなたも手伝える！ (28) RandyのIPv4/IPv4移行情報集のWikiサイトの画面 グローバル問題(29) - v6のみのサイトのユーザーはどうやってインターネットを、 例えばv4のみのサイトをアクセスするのか？ できない！ - どうやったら出来るだけ助ける事が出来るのか？ 管理インフラ(30) - DNS - BIND 9はV6をフルサポートしているようだ - レジストリはIPv6ネームサーバーの委託をサポートしなければならない - レジストリはIPv6 glue record（訳注：これって日本語あります？）をサポート しなければならない - RIR - RIRはリソースの所有権をX.509認証するオープンソースのパッケージを開発している レイア１と２(31) - ケーブルインターネットのDOCSIS 3.0規格 - MTU限界が1518 - CMTS (訳注：’Cable Modem Termination System - いわゆるケーブルモデム）がv6を良く サポートしてない - 802 (訳注： EthernetやWifi等を含めるIEEEのデータリンク規格集） - 全ての規格がIPv6をサポートしている - プロトコルが定義されているのと実装されているかどうかは別の話し バックボーン・エンジニアリング(32) - コアルータのデュアルスタックへの移行は遅い - 設定、アドレス設定、DNS - DHCPv6とDNSの統合 - v6上での監視と計測？ - 多くの場合新しいインターフェースカードが必要！ ラスト・キロ(33) (訳注： 普通ラストマイルだが、IIJに移籍したRandyがメートル法の国で働く事への 敬意の表れか単なるジョーク） - 認証とアドレス割り当て、 PPPoE, IPoE, DHCP - アドレス割当、バックエンドデーターベース、.. - どうやって安定したプレフィックスの委託を使いながらアドレス割り当て、ルーティングの 組み合わせを何百万もの顧客にスケーリング出来るか。（訳注：これは個人客へも IPv6ネットワークを割り当てるので、今までと違って家までルーティングを行わなければ ならなくなることでその情報管理のスケーラビリティーの事だと思います） 自己インストールされた家庭用CPE (34) (訳注：Customer Premises Equipment、顧客のサイトにインストールされる 機器を総称する業界用語） - 50ドルのDSLモデムはv6をサポートしない - 50ドルのファイアーウォールはv6をサポートしない - Teredo (訳注：マイクロソフトのIPv6/IPv4通信技術、 英文：http://www.microsoft.com/technet/network/ipv6/teredo.mspx 日本語解説どこかにある？）はスケーリングしない - shim6は企業や大きなサイトの問題は解決出来ず、セキュリティーや ルーティングの問題で展開不能） （訳注：マルチホーミング技術らしい http://www.shim6.org/） 企業 (35) - データベース、PeopleSoft (人事管理ソフト）, Siebold（知らん、 ぐぐっても分からん）、 ビジネスアプリケーション - ファイーウォール、VPN、外部アクセス - 内部開発の何百万行ものソフト - NFSアプライアンス、不明 - ビジネスアプリケーションのつながりのなかで１つでもv6に対応していなかったら 移行不能。 アプリケーション(36) - どこにプラットフォームごとのアプリケーションのv6対応状況の 表とその対応を有効にするための説明へのリンクがあるんだ？ - 多くのv6をサポートするアプリケーションはパフォーマンスの問題から 初期採用者たちはv6を無効にする様に言われる - (Windows) XPはv6を通してのDNSをサポートしないためにV6のみの環境 では使えない。 SMTP: 例 (37) - Eメール、SMTPは必須のアプリケーション - 誰でも、どのような受取手（自分以外全員）に対してメールが送れる 必要がある - しかしスパムのせいで誰もオープンなSMTPリレーを運用する事は 出来ない。 - よって全てのIPv6サイトはどのようなIPv4サイトに対してもSMTP 接続の出来る必要がある。 - よって全世界のSMTPサーバーがデュアルスタックになるまで、 全てのユーザーはプライベートのデュアルスタックのリレーが 必要になる。（Jeffrey Streiflingによる例） なぜ日本はいい状態なのか？(38) - 村井氏など、先見の明のある人たちが、IPv6への早期取り組みが 日本にとって有益あると政府を説得した - 政府はIPv6研究に投資している - 政府は業界やベンダーにおけるIPv6開発に投資している - v6互換になった企業に税金控除。 # すっごくヨイショしてますね 我々はなにが出来るか(39) 原則： １つのインターネット(40) - どんな状況に置いてもインターネットが分割されるのは防がなければならない - 移行過程において誰もが誰とでも通信が出来なければならない - End to Endの原則が出来るだけ維持され続ける事がのぞましい 原則： デュアルスタック(41) - 移行の全ての過程においてコアのルーターはデュアルスタックである必要がある。 そうで無い場合にはひどいハックがあふれかえる。 - デュアルスタックがよりエッジに近づくほど（企業、ネットワークサービス、 消費者）より楽になる。 - 設定、管理、測定は出来るだけ単純化されなければならない。 ５つの段階 (42) - 両「陣営」からの拒否反応 - アホなv6は無視出来る - v6は完璧だから欲張りな馬鹿どもは展開すればいいだけ - デュアルスタックでIPv4主体のネットワーク - デュアルスタックで両プロトコルが広く使われているネットワーク - デュアルスタックIPv6主体のネットワーク - IPv6ネットワーク（IPv10移転への準備開始;-) 原則： NAT (43) - End to Endの原則は望ましい - しかしipv6パケットはIPv4と互換性が無い - 移行中にはNATが使われる - あきらめろ - しかし、将来的に消え、永久に留まらないようなものにする必要がある NAT - PT (44) - エッジ、企業、家庭等においてはIPv6を走らす必要が有るがIPv4とIPv6の 両方のサービスをアクセスする必要がある - IPv6が大多数になってもIPv4ホストは主にV6となったインターネットを アクセスする必要がある - IETFはICMP, UDP, TCP, RTPの4/6 NATを標準化する必要がある。 また ALG（Application Level Gateway)とくにDNS AGLがどのようにプラグイン するかの定義をしてもいいかもしれない IVTFの現実 (45) (訳注：IETFの現状に対してRandyの皮肉、Internet Vendor Task Force http://rip.psg.com/~randy/051000.sigcomm-ivtf.pdf） - 2007年の7月にIVTFはRFC4966 - ネットワークアドレス変換 - プロトコル 変換 (NAT-PT)を歴史的地位に移行する理由」と発行した。 - この事がIVTFのネットワーク運用知識のレベル（の低さ）と いかにIPv6の展開よりも宗教を大切にしているかが明らかにされた NAT - PT とセキュリティー (46) - DNSsecは変換されるならNATで終端しなければならない - IPSecはNAT-PTを横切る事が出来る - DNS, SMTP, HTTP, SIP, RTPのALGが重要となる - IPsecはもっと容易になるべきである。 ルーティングへの圧力 (47) - IPv4アドレス空間の値段の上昇とそれの結果としてのNATは ルーティングに新たな圧力を加える。 - もし200百万の変動するルートを扱うのに１億ドルのルーターが 必要となったら96%のISPはつぶれ、企業のデフォルトフリーでの マルチホームは不可能になる - よって全てのサイズのルーターは200万の変動するルートを あつかえなくてはならない。 ハックするな！(48) - ルーティングのスケーリングの問題を迂回するために例えば 一億ドルのコアルーターに企業のエッジからトンネルするような ハックに走ってはいけない - TLA/NLAの事を考えておびえなさい （訳注：？ そういえば昔こんなものが ありましたね、結局早々に却下されたのでしたっけ？ http://www.isi.edu/in-notes/rfc2450.txt 上位のプレフィックスにTop Level Aggregation IdentifierとNext-Level Aggregation Identifierに分けて、 注意深く、トポロジーに一致する様にアドレスの割当をする、つまり Aggregate可能なアドレスの階層構造を組み込んでおくという考えでした。 最初の頃のIPv6のうたい文句としてこういうことをするアドレス空間の 余地があるからルーティングテーブルが小さくなるよというような 夢物語がありましたねえ。 けどこれどう訳すればいいのかちょっとニュアンス不明 :-)があるからジョークでしょうが - 10のISPの独占状態になることをとってもとっても憂慮しなければいけない フォワーディングは遅れている(49) - 顧客がないことから全ての大手メーカーがデュアルスタックをACL付きで ラインスピードでフォワーディング出来る様になるには５年はかかる - メーカーの一部は全てのプラットフォームやインターフェースカードの ASICを更新さえしてない - 特定メーカーの独占状態になるべきではないから全てのメーカーでサポート されなければならない - よって「当社は出来るが他社は出来ない」というような馬鹿げたマーケティング に興味はない いいIPv6テスト機器(50) - ルーター・スイッチメーカーは高い(IPv6)性能を謳っている - しかしいい（IPv6の)テスト・負荷機器の深刻な不足から（そのメーカーの主張を） 検証する事が出来ない (プロトコルの)機能追加をやめろ(51) - もっともっとセクシーな機能を追加する事でIPv6を推奨するのはやめろ - IPv4枯渇がIPv6を売るかIPv4 NATの世界が訪れる - 機能の追加がさらにオペレータとメーカーに（IPv6サポートを）遅らせる事の 言い訳を与える - 機能を固定して我々に展開するチャンスをあたえろ！ ' ULA: まずい概念(52) (訳注： Unique Local IPv6 Unicast Address http://tools.ietf.org/id/draft-ietf-ipv6-ula-central-02.txt いわゆるRFC1918のプライベートアドレスのIPv6版ですね。） - ULAはアドレスベースだから良くない - 境界ルーターはフィルタリングをしなければならない - もらさず、侵入させないためには発信元フィルタと受信先フィルタの両方をしなければならない - 特別なアドレス空間を作るな - 240/4の後始末をしなければならなかったことを思い出せ - IPv6は無限のはずだろう - 本当のIPv6を与えて単にDFZにアナウンスしなければいいだけ （訳注： アナウンスをしなくてももれるパケットは止めなければいけないから どっちみち境界でのソースフィルタリングはしなければいけないと思うけど） まとめ(53) - IETF - NAT-PT - 「機能」の追加（例: ULA）をもうやめろ - ルータ - ACL付きのデュアルスタックをファストパスで - 200万以上の動的経路を全てのルータで - ISP - 顧客のエッジにデュアルスタックを - 政府: 規制でなく補助しろ どのように手伝えるか(54) http://www.civil-tongue.net/clusterf/ 手伝えるなら randy@psg.comにメール下さい。 たのむ！
