メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索

ニュースレターNo.50/2012年3月発行

第82回IETF報告
IPv6関連WG報告

2011年11月13日(日)から11月18日(金)まで、台湾、台北にて第82回IETFミーティングが開催されました。この時期、台北は雨期とのことで、ほぼ一週間雨のぱらつく曇り空でした。ソーシャルイベントのチケットとあわせて、アジアでも屈指の高さの、台北101の展望チケットが配られましたが、晴れた日に恵まれず、少々残念でした。

本稿では、会期中において、IPv6に特化した内容を議論するワーキンググループ(WG)での議論内容を中心に紹介します。

6man WG (IPv6 Maintenance WG)

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回は、会議の初っぱな、月曜日の朝一のコマにて開催されました。最近、6manのミーティングへの参加者はそれほど多くはなかったのですが、今回は大きめの部屋に、多数(200名以上)の参加者を集めたセッションとなりました。

ミーティングの冒頭にmif (Multiple Interfaces) WGのチェアより、mif WGにて議論されている関連ドラフト(draft-ietf-mif-dhcpv6-route-option)について、レビューの依頼がありました。このドラフトは、IPv6ノードにDHCPv6を利用して経路情報を配布するものです。同様の機能は、ルータ広告(RA)でもRFC4191にて定義されています。なお、このオプションについては、同等の機能を複数の手段で実現することの是非等についての活発な議論が、現在もメーリングリスト(ML)上で続いています。

この後、チェアによるアジェンダ確認があり、6man WGで取り組み中である、次の文書のステータス報告がありました。

  • IPv6フローラベル仕様に関するドラフト群
    RFC6437、RFC6436、RFC6438発行
  • IPv6ノードの要求仕様改版(draft-ietf-6man-node-req-bis)
    現在、RFC発行直前の状態ですが、RFC化されたフローラベル仕様について、文書に反映するかどうかの議論を実施しています(後述)。
  • RPL(低電力高損失ネットワーク用のIPv6ルーティングプロトコル)用のデータ転送オプション
    (draft-ietf-6man-rpl-option/draft-ietf-6man-rpl-routing-header)
    エリアディレクタ(AD)のアクション待ちとの報告がありました。(現在、改版ドラフトが必要とのステータスになっています)。
  • 回線IDオプション(draft-ietf-6man-lineid)
    ExperimentalステータスのRFC化に向けて、WGラストコール中(11/17まで)。現在、オプションのフィールド内のデータについて、議論中。

今回は、次のテーマが議論されています。

  1. IPv6ノードの要求仕様改版
    draft-ietf-6man-node-req-bis
  2. RFC3484 IPv6デフォルトアドレス選択機構の更新
    draft-ietf-6man-rfc3484-revise
    draft-ietf-6man-addr-select-opt
    draft-ietf-6man-addr-select-considerations
  3. UDP のチェックサム廃止
    draft-ietf-6man-udpzero
    draft-ietf-6man-udpchecksums
  4. エネルギー消費を考慮したIPv6近隣探索の最適化
    draft-chakrabarti-nordmark-energy-aware-nd
  5. MS/TP ネットワーク上でのIPv6転送
    draft-lynn-6man-6lobac
  6. IPv6オフセット指定オプション
    draft-zhang-6man-offset-option
  7. 重複アドレス検出の拡張
    draft-hsingh-6man-enhanced-dad

これらのトピックスの中から、いくつかをご紹介します。

  1. IPv6ノードの要求仕様改版
    draft-ietf-6man-node-req-bis

    このドラフトに、新たにRFC化されたフローラベルに関する記述を追記するかどうかが議論になりました。このドラフトは、RFC発行直前のステータスになっています。ミーティング中、ADからも、文書のとりまとめに時間がかかり、RFCとしての発行が遅れることに対する懸念や、通常であれば、今回のような大きな変更(旧来のスペックとの差が大きい変更)を実施する段階では既にないことが表明されました。RFCに取り込むテキストについては、11月2日(水)~17日(木)の予定で、WGラストコールが実施されています。ミーティングでのコンセンサスとして、フローラベルに関する記述を盛り込むことが合意されました。事後になりますが、WGラストコールを実施したテキストに特に大きな意見はなく、そのテキストを取り込んで、RFC化のプロセスを進めることとなっています。

  2. RFC3484 IPv6デフォルトアドレス選択機構の更新
    draft-ietf-6man-rfc3484-revise
    draft-ietf-6man-addr-select-opt
    draft-ietf-6man-addr-select-considerations

    IPv6のアドレス選択機構について、現行仕様の改版、アドレス選択ポリシーのDHCPv6による配布に関する提案です。提案者より、WGラストコール中のコメント対応として、過去にIPv6実験ネットワーク6boneにて利用されていたアドレス空間を、デフォルトのポリシーテーブルに取り込むことおよび、エニーキャストアドレスを始点アドレスにすることに関する制限の記述をなくす旨の説明がありました。会場より、この改版ドキュメントについての、旧文書との差分の度合いについてコメントがあり、変更が多い場合には、改版でなく、前の文書を無効として新たな文書を策定した方がいいのではないかという質問がありました。提案者より、マイナーな変更であり、改版で進めるとの回答がありました。

    また、アドレス選択のDHCPv6オプションについては、現在DHC WGへのレビュー依頼中である旨の紹介があり、レビュー終了後にWGラストコールを実施することとなりました。三つめのアドレス選択についての検討ドラフトについては、RFC化不要、という意見もありましたが、過去の議論結果を残すためにもRFC化を、という声が多く、WGラストコールを実施することになりました。

  1. IPv6オフセット指定オプション
    draft-zhang-6man-offset-option

    IPv6では、プロトコル自体を拡張可能とするために拡張ヘッダを定義しており、この拡張ヘッダは、先頭にあるIPv6ヘッダと、上位プロトコルペイロードの間に数珠つなぎ状に配置されます。上位プロトコルペイロードの内容を知るには、拡張ヘッダを前から順番にたどる必要があり、効率面等で問題があるため、上位ペイロードの位置を指し示すオプションを規定し、ヘッダチェーンの最初につけられるようにしよう、という提案です。会場から、セキュリティに関する懸念、このオプションの効果、フラグメントヘッダ等他のヘッダ等の混在に関する質問があり、議論となりました。

その他、前回のミーティングでも類似提案がありましたが、省エネルギーに関する提案、センサ等の省電力ネットワークにおけるIPv6転送等の提案が挙がっています。

□ 6man WG
https://datatracker.ietf.org/wg/6man/
□ 第82回IETF 6man WGのアジェンダ
http://www.ietf.org/proceedings/82/agenda/6man.html
画面:第82回IETF会合のWebサイト
第82回IETF会合のWebサイト

v6ops WG(IPv6 Operations WG)

v6opsはIPv6に関するオペレーション技術および、共存・移行技術に関する議論を実施するWGです。IPv6の普及を受け、このところ非常に提案数が多いセッションとなっていましたが、チェアからのミーティングでの提案発表には、MLでの議論が必要、とのコメントもあり、今回は2コマ、合計11件とかなりすっきりした構成となりました。実際に、チェアからのアジェンダ確認の後、会場から、チェアのアジェンダ構成に対する努力とその結果について、感謝の意が示されました。

ミーティングは、水曜午前および木曜午後一の2コマで実施されています。参加者は相変わらず多く、広めの部屋がほぼいっぱいとなっておりました。

今回、議論された項目は次のようになっています。

  1. IPv6カスタマーエッジルータに対する基本要求仕様
    draft-ietf-v6ops-6204bis
  2. 近隣探索の運用上の問題
    draft-ietf-v6ops-v6nd-problems
  3. ICMPv6パケットのステートレスな始点アドレスマッピング
    draft-ietf-v6ops-ivi-icmp-address
  4. 2011年秋WIDEキャンプにおけるIPv6 onlyネットワーク実験からの経験
    draft-hazeyama-widecamp-ipv6-only-experience
  5. 有線網におけるIPv6の段階的導入
    draft-kuarsingh-wireline-incremental-ipv6
  6. サーバのロードバランスへの、IPv6フローラベル使用
    draft-carpenter-v6ops-label-balance
  7. ULAの利用方法の現状と推奨
    draft-liu-v6ops-ula-usage-analysis
  8. インターネットコンテンツ&アプリケーションサービスプロバイダ向けIPv6ガイダンス
    draft-carpenter-v6ops-icp-guidance
  9. IPv4コンテンツのIPv6コンテンツへの手軽な移行方法
    draft-sunq-v6ops-contents-transition
  10. NAT64の運用に関する検討
    draft-chen-v6ops-nat64-cpe
  11. 6rdの廃止方法
    draft-townsley-v6ops-6rd-sunsetting

次に、議論されたいくつかのトピックについて、簡単に紹介します。

  1. IPv6カスタマーエッジルータに対する基本要求仕様
    draft-ietf-v6ops-6204bis

    RFC6204の改版を目的としたドラフト提案です。主な改版ポイントは、6rdやDS-Liteのような移行技術に関する記述を入れたことです。提案者より、LAN側の拡張機能についての議論は、homenet WGに譲ることとした旨のコメントがありました。ミーティングでは、DHCPv6に関する記述について、その普及状況や、ルータ広告中のM/Oビットに対する対応などをどのように記述すべきかが議論になりました。DHCPv6に関する詳細は、DHC WGに場所を移して議論をする方向となっています。このカスタマーエッジルータ仕様の改版トピックについては、v6ops MLでもかなりの議論が重ねられており、IPv6ディプロイメントにあわせ早急なRFC化が期待されています。

  1. ULAの利用方法の現状と推奨
    draft-liu-v6ops-ula-usage-analysis

    IPv6で、組織内で自由に利用可能なアドレスとして、ULA(Unique Local IPv6 Unicast Address)がRFC4193にて定義されています。このULAの現状の使われ方の調査および、推奨する使い方に関する提案です。ULAの利用方法に対するガイダンス等は有用との意見もありましたが、提案に対しては、NATに対するスタンスや、以前提案されていたULA-Central(レジストリ等が管理するULA)への対応等、かなり多くの意見が挙がり、提案内容については、さらなる検討が必要、とされました。

  1. 6rdの廃止方法
    draft-townsley-v6ops-6rd-sunsetting

    IPv4 ネットワーク上でIPv6サービスを提供できる手軽な移行技術として利用が進んでいる6rdについて、IPv6ネットワークが十分に行き渡った際に段階的に廃止し、IPv6ネイティブネットワークとする手法について、6rdの提案者からの提案が実施されています。本来、softwire WGでの議論内容ではありますが、CPEルータ文書に関連するため、v6ops WGでの議論を実施することにしたとの説明がありました。具体的な方法について確認の質問がいくつかあり、議論はMLで継続実施することとなっています。

□ v6ops WG
http://datatracker.ietf.org/wg/v6ops/charter/
□ 第82回IETF v6ops WGのアジェンダ
http://www.ietf.org/proceedings/82/agenda/v6ops.html

(NTT 情報流通プラットフォーム研究所 藤崎智宏)

このページを評価してください

このWebページは役に立ちましたか?
よろしければ回答の理由をご記入ください

それ以外にも、ページの改良点等がございましたら自由にご記入ください。

回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2024 Japan Network Information Center. All Rights Reserved.