■ IPv6導入に向けたネットワーク運用の課題 IIJ 松崎さん □Path MTU discovery 通信するときは一番大きなパケットサイズを見つけて効率よく 通信したい IPv6では"SHOULD"なので乗せなくても良い 普通のOSには乗っている 利用しない場合には1280が最小MTUサイズ パケットが大きい場合にはICMPエラーで送信元に通知してMTUサイズを調整する - 失敗事例: ICMPエラーを出さない PathMTU ブラックホールルータ - 失敗事例2:フィルター ICMP処理ミス ホスト側でICMPエラーを処理できない 普通は大丈夫だけどファイアウォールがはじいているとか インターフェースが入りと出るので違ったり ICMPをフィルタしちゃという安易なポリシが流行った時期があった 何故だろう - 失敗事例3: 制限 ICMPにレートリミットがある ICMPのトータル量で制限がかかっちゃう ICMPメッセージを生成する性能 ちゃんと考えて設定している人がどれだけいるのか？ ぼくはこれを考えて設定してなかったなぁという反省を含めて Cisco IOSは1秒間に2パケット ip icmp rate-limit unreachable デフォルト値はこんな感じ: IPv4だと1秒に2発 IPv6だと1秒に10発 Juniper Junos はpacket rate 1秒間に1000パケット JuniperだとICMPという広い括りでrate limitがかかっている 誰かがドワーっとやると、それにひっかかる - 失敗事例から考えると… Path MTU discoveryは動いていないのではないか 皆が使うとICMP生成の負荷が大きくなる 最初の人しか成功しない 運が良い人しか成功しない 失敗する人がいるというより、成功する人も居るぐらいかもしれない - IPv4の事例に学ぶなら ほとんどのブロードバンドルータがTCP MSSに関する機能を持つ OS類もトンネルをはるものはできる みんな自力でフォールバックを避けている みんなが頑張っているので、なんとかできる ユーザからWebが見られないというのは、MTUを疑うことはなくなってきた - IPv6でどんな選択肢があるか？ 案1: RAという自動制御の仕組みでMTUを通知 小さめのところで抑制しようという試み 家庭でもGbEで、jumbo frameを設定している人もいる IPv6使うと遅くなるというのが発生することがある 案2: TCP MSSをIPv6でも使う IPv4で動いているのであれば、それをもってきてしまえばいい どうせ多くはTCP でも、DNSSECというのが最近はあるんですって 大きなUDPパケットが返って来る可能性があるんですって ・考えどころ TCPはMSS調整で救うのが無難 TCP以外の通信にPath MTU Discovery 他の通信でも上手くいくんですよね？を保証するためにPath MTU Discoveryが必要です ICMPどれぐらい返せるんだろうかと、気にしてください とある所の設定では、さきほどの設定をさらに落として設計 している方もいらっしゃるようです ベンダの方と一緒に、どのぐらい必要なのというのを 共有できれば。 □分散した拠点とprefix ・分割広報vs経路フィルタ - IPv6アドレスはまだまだ割り当てられてない空間が膨大にある 今だったら、ポータブルアロケーションがまだあるので、 これをもらって運用するのがまだ可能 せっかくAS 4octetになったので、新たなASをもらう方法も - 広告分割＋経路フィルタ 経路集約は地道な活動 まだまだ残りの部分がいっぱいある いまから割って使ってると、すごい大変 AS番号も山のように在庫が増えた 4 octetって大きい AS何個までルータっていけるの？ 経路集約はやっといた方が無難 - 妥協点 今のところ、少なくとも割り振られたブロックをそのまま広報しましょう 最低限、割り振られたブロックサイズで広報 分割広報しても受け取ってもらえない可能性がある - 考えどころ 分割広報するなら必要な範囲のみで 必要な範囲でトラフィックエンジニアリングできれば 考えてるのは、日本のISPで合意して、俺たちの範囲で 通じるBGP communityを作って、分割広報の影響範囲を しまいこむとかをやっていきたい それをしないと、ルータベンダに高いメモリを積んでもらう 必要がますます出てしまう 皆で合意したBGP communityは次回とか次次回に話せれば □/127動向 - IETFに行くたびに大議論になる draft-kohno-ipv6-prefixlen-p2p /127を見ると嫌なひとがいる 6 man working group IETFに行く度に大議論 プロトコル仕様の琴線に触れる - 最近の論点 /64以外のPrefixをRFCに入れたくない！とか off-linkモデル使えばいいじゃない？ 実インターフェースに紐つかないアドレス 相手からRAを聞いてdefaultを向ければ通信可能 君の環境では動くけど、僕の環境では使えない。 インターネットバックボーンでdefaultは使えない 妥協点が見いだせてないのが現状 運用方面からは理解を得られている 僕たちはつかいたいんだと言っている 直感的に/31と同じなので、使えば動くのはわかる わかるし必要だと言われる UCR2010の2010年版 www.disa.mil いままで３回発表し、議論し、象牙の棟の方々に美しくないと言われています 今後も6manでがんばります 有用だと思われる方はご協力を。 - IRSとはあんまり関係ないけど... プロトコル検討してる人が目指したところと運用側では意見が ちょっと違う。IETFで良く感じる リンクローカルは便利だけど、バックボーンでいるかというといらない 必須ではないかなぁと - IPv6 anycast IPv4 anycastだとrouting的に一番近い所 IPv6でも同様のことはできる 予約済みAnycastというのが潜んでる subnet router anycastとか誰もつかってないのでは。 subnet router anycast, iid all 0 RFC2526 reserved ipv6 subnet anycast address いまのところ、reservedで割り当てられてるのは、 モバイルIPのエージェントだっけ 知らない間に勝手に現れて何かされちゃうのは嫌だなあ。 - VLSM IPv4ではもはや当たり前 IPv4ではとっても良く動いた longest matchの単純なルール でも、/64を心から守りたい実装もある ルータによっては、細かい経路がFIBにのらない 128だけは特別にのるみたい 僕は好きなprefixで動いて欲しい - 仕様 vs 運用 プロトコル屋さんと運用側にはかなり考え方にギャップがある こんなに強烈に象牙の塔が立っているとは思わなかった IPv4の経験は使えるが、IPv6の思いは違うかも プロトコル屋さんたちが潜ませた罠に注意 IPv6で賢く解決しようとした仕様はトラブる multi prefix 環境でのNDとか ホストとルータの定義とか この辺をもうちょっとわかりあっておかないと プロトコルを作る人には仕様を通すのが仕事の人もいるらしい ので、(なんでもかんでも仕様にいれちゃうのでは無くて) 必要ない部分は入れてもらわず、必要とする部分を仕様に 入れてもらいたい 運用側ももっと声をあげないといけない DHCPとかもさっさとこれでいくんだとか、決めて頂かないと これはどうかなというのは、いわなきゃいけないんだなと いうのを、最近学んでいます Q: エッジのASの人間としてやはり分割広報したいと思ってしまう。いままでと 同じノリでいきたいなぁと思うんですが、でも細かくちぎって出すのはいや だと。でもNO_EXPORTつければいいのかなとか、分割条件下ではOKという条件 になりそうなんでしょうか？ ASと上流ASがよろしくサブプレフィックスの調整をしなければならないので 技術的な落とし所は何かありますか。 A: それで行くと、出口ごとに分割広報したいと。一つのASで複数でトラフィッ クエンジニアリングしたいというのであれば C: 日本国内ルールみたいのを作るといいのかなぁというのを日々考えていたり するんですけど無理がでているところを、みんなで考えるとうれしいです