JPNICJavaScriptが無効になっています。JavaScriptを有効にしてご利用いただくことで、より快適にご利用いただけます。vol.800に続き、2010年11月に中国の北京で開催された第79回IETFのレポート[第2弾]として、IPv6関連WG報告をお届けします。全体会議報告については、以下のURLからバックナンバーをご覧ください。2010年11月7日(日)から12日(金)まで、中国の北京にて第79回IETFミーティングが開催されました。調を崩した方が多かったように見受けられました。本稿では、会期中における、IPv6に特化した内容を議論するワーキンググループ(WG)での議論内容を中心に紹介します。WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回は、11月9日(火)の午後最初に1コマにて開催されました。WGで取り組み中である、以下の文書についてステータス報告がありました。最後の回線識別ドラフトに関しては、「技術的問題が多く、WGドラフトとする合意に達していないのでは」という指摘がありましたが、「まずはWGドラフトにしてから技術的課題を検討するのであって、RFCとして発行することとは別」というフォローがありました(WGドラフト化は、IETF79前に、WGドラフトとするかどうかの合意確認がMLで実施された結果です)。今回、以下のテーマが議論されています。時間の割には議題が非常に多いという印象でした。時間切れで議論できず。これらのアジェンダの中から、いくつかのトピックについてご紹介します。draft-ietf-6man-exthdr-00.txtIPv6拡張ヘッダの標準フォーマットを決めよう、という提案です。現在定義されている拡張ヘッダでは、フォーマットに統一性はありません。今後新たに拡張ヘッダを追加定義する際、新しい拡張ヘッダを認識できない古い機器がそのヘッダ部分をスキップすることができるよう、ヘッダの長さ情報等のフィールドを規定するなど、フォーマットに統一性を持たせることを提議しています。施することとなりました。算の省略を可能にしようという、ここ数回議論が続いている提案です。計算しない場合に関する考察である文書(draft-ietf-6man-udpzero)は、WGラストコールを実施することになり、実際の適用手法に関する提案(draft-eubanks-chimento-6man)が議論となりました。適用を特定の場合のみに限定することについては概ね賛同を得ましたが、IPv6の基本文書であるRFC2460への改変が必要という意見も上がっています。後者の文書についても、WGドラフトとして引き続き検討をすることに反対はありませんでした。draft-ietf-6man-RFC3484-reviseIPv6ノードおよび通信相手が複数のアドレスを持つ場合に、通信に使うアドレスペアを選択する必要があります。Addresses(RFC4193)等)が記載されていない問題等があるため、RFC3484を改版しようという提案です。等の意見があり、検討を継続することになりました。関連して、デフォルトルールをDHCPv6で配布し、変更できるようにするという提案(draft-fujisaki-6man-addr-select-opt)について、WGドラフトとして扱うことに対するコンセンサス確認が実施され、WGドラフトとして議論することになりました。draft-ietf-6man-prefixlen-p2p前回WGドラフトとなった、ルータ間のリンクに付与するアドレスとして、127ビットのプリフィクスを用いることを可能としよう、という提案についての議論です。討する必要があるのでは、といった意見が出されました。ミーティング後に、WGラストコールを実施し、より広い意見を集めることになりました(2010年12月6日までの期限でラストコールが実施されていました)。draft-gont-6man-teredo-loopsが適切なWGにて議論を継続、となっています。論を実施するWGです。IPv6の導入加速の世相を反映してか、今回も数多くの新提案がありました。認を実施せず、インターネット上に用意したサイトにて、賛同、不賛同を後ほど入力するような形式を取ることにする、という周知が事前にありました。ここでも、いくつかのトピックについて、簡単に紹介します。draft-baker-v6ops-session-start-timeIPv6/IPv4デュアルスタック環境では、通信相手がIPv4/IPv6両方のアドレスを持っている場合、ノードは、最初に選んだ通信プロトコルでの通信に支障が発生した場合に、もう一方の通信プロトコルに切り替えるという、いわゆるフォールバック、と呼ばれる動作をすることが一般的です。昨今の多くのデュアルスタック実装では、IPv6がIPv4よりも優先されるため、IPv6通信に支障があった場合にIPv4で再度試す、という動作をしますが、この切り替えに時間がかかり、ユーザーの利便性が損なわれる、という問題が発生しています。このようにデュアルスタック環境で発生する問題を、ユーザーの観点からいかに解決するかについて提案があり、議論が行われました。複数のTCPセッションを同時にスタートし、最初に通信できたセッションを利用する、といった解が提案されています。SCTPでの実装例や、アプリケーションとの関連に関するコメントが出されました。提案名が漠然とし過ぎていてすぐに提案内容を想像できないため、もっとわかりやすいものに変更すべき、という意見もありました。Practice)か)が、ML上で実施されています。draft-herbst-v6ops-cpeenhancements間もなくRFCとなる予定の、IPv6カスタマーエッジルータ基本仕様文書(draft-ietf-v6ops-ipv6-cpe-router)に対する、追加仕様の提案です。基本仕様と同時に議論されていたものを、分離して別文書として検討しています。今回は同時に、スマートメーター等で利用される省電力無線デバイス(IEEE802.15.4(Zigbee)等を利用したデバイス)と家庭用ルータの接続に関する提案も実施されています。CPE追加仕様については、6rd、DS-liteといった移行プロトコルの記述追加、家庭でのCPEのトポロジーに関する考察(多段ルータ環境を考慮するか)、ULAの利用方法などについて言及され、後者ではIEEE802.15.4の接続方法、ULAでの通信の必要性等が例として挙げられました。議論としては、マルチキャストDNSの利用の是非、まずはトポロジーは単一ルータ環境に限定すべきである、といった点が挙げられています。継続して議論していくこととなりました。投票の結果では、前者は65.2%、後者は36.8%が、WGドラフトとして議論をすべきという意見でした。draft-livingood-dns-whitelisting-implicationsキャッシュサーバからのクエリパケットのアドレスに基づき、DNS権威サーバにて、AAAAレコードを応答するかどうかを制御する、DNSホワイトリスティングに関する提案です。Eyeballsのドラフトにも関連しますが、この仕組みにより、クライアント(正確には、クライアントの利用するキャッシュサーバ)のIPv6アドレスごとに、自サイトにIPv6を利用してアクセスするかどうかを制御できます。性が良い相手からのみ、IPv6接続を利用可能とするような制御を実施しています。DNSの名前空間を分断することになり問題だ、DNS関連WGでも情報共有し議論をしてほしい、という意見が出されました。投票の結果では、67.9%が、WGドラフトとして議論をすべきという意見でした。アジェンダにはありませんでしたが、ミーティングの最後に、opsareaミーティングで話題に上がった、IPv4プライベートアドレス(RFC1918)の拡張に関する議論がありました(draft-weil-shared-transition-space-request)。こちらは、ISP共有アドレス空間として、2段NATの中間に使うための空間として利用したい、というものです。この用途として、IPv4の/10程度をリザーブしたい、という提案でしたが、賛成・反対共に多数の非常に激しい議論となりました。結果として、IETFではコンセンサスに至りませんでしたが、IPv4アドレス空間のIANA在庫が枯渇直前となり、このような空間を用意することは既に困難な状況になっていると思われます。draft-troan-multihoming-without-nat66について、ステータスレポートが実施されました。こちらについては、76%がWGドラフトとして議論をすべきという結果になっています。信の実現方式を検討するWGです。Deployment)といった、新しいIPv4とIPv6の共存環境を構築する方式も併せて検討されています。今回は、開始早々の月曜朝一のコマにも関わらず、100名を超える参加者を集めて開催されました。10件以上の新規提案があるなど議論アイテムも非常に多く、新規アイテムの提案については、「技術の説明で1スライド、問題点や必要性等で1スライド程度で説明することを話者に連絡済み」「なるべく時間を短く」とチェアより念押しがありました。このためか、ほとんどの新規アイテムで議論も質問もありませんでした。この後、チェアからDS-liteのステータスに関する説明がありました。DS-liteは、本体プロトコルと、必要なパラメータをDHCPで配布するDHCPオプション定義の二つの文書に分けられ、それぞれ個別に標準化が進められています。Director)のレビューは終了し、そのコメント対応中となっています。完全に限定されたドメイン名)とIPアドレスの両方ではなく、どちらか片方のみ指定することが議論され、その結果、最終的にはFQDNのみを指定するよう変更することになりました。正後、WGラストコール、IESGにレビューを再依頼の予定となっています。その他、以下のようなポイントが議論されています。う問いかけがありました。論でも意見が分かれました。