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

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

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索
===================================
    __
    /P▲         ◆ JPNIC News & Views vol.573【臨時号】2008.9.5 ◆
  _/NIC
===================================
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.573 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号では、vol.571、vol.572に引き続き、第72回IETFのレポート[第3弾]とし
て、IPv6関連WGの動向についてお届けします。

□第72回IETF報告 特集
○[第1弾] 全体会議報告 (vol.571)
  http://www.nic.ad.jp/ja/mailmagazine/backnumber/2008/vol571.html
○[第2弾] DNS関連WG報告 (vol.572)
  http://www.nic.ad.jp/ja/mailmagazine/backnumber/2008/vol572.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第72回IETF報告 [第3弾]  IPv6関連WG報告
                                    NTT情報流通プラットフォーム研究所
                                   JPNIC IPアドレス検討委員会メンバー
                                                             藤崎智宏
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2008年7月27日(日)から8月1日(金)まで、アイルランドのダブリンにて、2008
年夏のIETFが開催されました。ダブリンは日本に比べ、かなり涼しく過ごしや
すかったのですが、会場および投宿ホテルがダブリン郊外のゴルフリゾートで
あり、食事等でダウンタウンまで出るのにバスで30分ほどかかるため、場所的
には少々不便を感じました。

本稿では、会期中に議論された、IPv6に関連したトピックスをいくつか紹介し
ます。

◆IEPGミーティング(Internet Engineering and Planning Group)

IETFミーティングは、正式には日曜日の正午から始まります。IEPGミーティン
グは毎回その直前、日曜日の午前中に開催されています。

今回は、IPv6に直接関係のあるトピックスとしては、APNICのGeorge
Michaelson氏が発表した6to4のDNS逆引きサーバの登録状況紹介のみでした。
6to4は、IPv4からIPv6への移行プロトコルとしてIETFで標準化され、Windows
XP以降やApple社のAirMac Extremeに実装されています。このプロトコルを用
いることで、IPv6 over IPv4トンネルを利用し、IPv4のみの環境からIPv6イン
ターネットにアクセスすることができます。この発表では、6to4のDNS逆引き
登録状況について紹介があり、2005年初頭に始まったこの試行サービスの登録
数は線形に増加しており、現在は900以上の登録があること、米国、欧州が大
部分を占めていることが述べられました。6to4は、IPv4からIPv6への過渡期に
利用される移行プロトコルの一つではありますが、Windows OSに実装されたこ
ともあり、実際の利用者は多いと思われます。

その他、IPv6には直接関係はありませんが、Randy Bush氏より、ISP網に導入
される可能性のあるキャリアグレードNAT(CGN)について、否定的な見解が述べ
られました。CGNは、IPv4アドレスの在庫枯渇に対する一つの対応方法として
検討が進められており、今回のIETFでも実装方法の提案や、導入に関するプレ
ゼンテーションが実施されています。

□IEPGのWebページ
  http://www.iepg.org/


◆6man WG(IPv6 Maintenance WG)

6manワーキンググループ(WG)は、IPv6のプロトコル自体のメンテナンスを実施
するWGです。チャーターには、「IPv6プロトコルに対するマイナーな変更のみ
扱う」、と明記されています。今回は、水曜日の午前中にミーティングが開催
されましたが、6man WGのチェアでIPv6プロトコルの提案者の一人として有名
なRobert Hinden氏は、所用により欠席で、もう一人のチェアである Brian
Haberman氏が全て取り仕切るミーティングとなりました。

今回の議題は、

  ・ PMIP6 向けのルータ広告改訂(PMIP6 Indication and Discovery)
            draft-damic-netlmm-pmip6-ind-discover
  ・ IPv6 複数アドレス選択およびRFC3484の改訂
            draft-arifumi-6man-rfc3484-revise
            draft-6man-addr-select-sol
  ・ ルータ広告のMフラグとOフラグの扱い
            draft-cha-ipv6-ra-mo
  ・ 断片化ヘッダの問題(Overlapping Fragments)
            draft-krishnan-6man-overlap-fragment
  ・ 拡張ヘッダの標準フォーマット
            draft-krishnan-ipv6-exthdr

の5点、となっています。

「PMIP6向けのルータ広告改訂」は、現在netlmn WGで標準化の進んでいる
PMIP6(Proxy Mobile IPv6)に関連し、ネットワークがPMIP6をサポートしてい
るかどうかを判断するために、IPv6のルータ要請/広告に手を入れたい、とい
う提案です。これに対して、今後提案される可能性のある、いろいろなプロト
コルについてアドレス割り当てレベルで機能を導入するようなことは困難であ
るという指摘等がありました。この提案は、6man WGのミーティング時点では
netlmn WGでもまだ議論中ということであり、そちらでの議論が終わり、本提
案の内容にnetlmn WGとして合意が得られた時点で再度検討することになりま
した。

「IPv6複数アドレス選択およびRFC3484の改訂」では、アップリンクから割り
当てられた複数のIPv6アドレスを持つノードにおいて、通信の際に通信相手に
応じた適切なIPv6アドレスを始点アドレスとして選択する機構に関する議論お
よび、現在標準化されているアドレス選択に関する標準であるRFC3484の改訂
に関する議論が実施されました。これは、RFC3484には、ノードが複数IPv6ア
ドレスを保有する場合や、通信相手が複数のアドレスを持つ場合に、どのアド
レスを利用するかの選択アルゴリズムが記述されていますが、標準化当初にデ
フォルトとして定義された条件が、その後追加定義されたULA等の新たな特殊
用途アドレスに対応していない、等の問題点が指摘され、現在の状況に合わせ
て改訂しようというものです。また、あらゆる環境をカバーするような条件を
作ることは不可能なため、デフォルトを変更するためのアドレス選択ポリシー
を配布しよう、という提案に関しても議論されました。その結果、アドレス選
択条件を動的に変更できるようにすることが必要だ、という合意が得られ、今
後、アドレス選択ポリシーの配布をどのように実施するかを検討するチームを
作り、議論を実施することになっています。

「ルータ広告のMフラグとOフラグの扱い」では、ルータ広告メッセージ中の、
アドレス割り当て方式を制御するビットの扱いに対する改訂の提案です。Mフ
ラグとOフラグの扱いについては、6man WGの前身であるIPv6 WGでもかなり長
い間議論され、現在の仕様に落ち着いた、という経緯があります。議論の中で、
提案者が述べている問題が、本当に一般的な問題で多くの人が困る事象なのか、
どこまでが仕様で、どこからが実装に依存するものであるのかの線引きの問題
ではないか等の意見が出されました。この両フラグについて、問題を明確にす
るために、メーリングリストで議論を継続することとなりました。

「断片化ヘッダの問題」は、IPv6の拡張ヘッダの一つである断片化ヘッダに、
IPv4の断片化でも問題になった、"重複断片の扱い(Overlapping fragments)" 
に関するセキュリティ的問題があるため、この対処が必要というものです。
IPv4におけるこの問題は、RFC1858に述べられています。同様の問題がIPv6で
も起こることはRFC4962に書かれていますが、現状、対処がなされておらず、
また、IPv4で起こりうる問題よりも、IPv6の方がより深刻であるということが
指摘されました。この問題に早急に取り組むことになり、提案ドラフトをWGア
イテムとすること、および早急にRFC2460の改訂を図る方向で進めることにな
りました。

「拡張ヘッダの標準フォーマット」は、IPv6拡張ヘッダは、基本フォーマット
が定義されておらず、新規に定義された場合には、既存実装では拡張ヘッダの
サイズがわからない可能性があります。これを防ぐため、標準的な、TSVフォー
マット(Type/Size/Value)を導入しようというものです。前回のIETFに引き続
き議論されました。メーリングリストでも多くの意見があり、それらに対応し
てドラフトがアップデートされましたが、標準フォーマットを決めることの意
義や、ヘッダ設計の概念的な部分に踏み込んでしまう可能性、また、決めたと
しても、それをどのように周知していくのか等の指摘がなされました。ミーティ
ングでは、賛同が多く、メーリングリストで意見を募集し、WGとして引き続き
検討していく方向となっています。

□6man WG
  http://www.ietf.org/html.charters/6man-charter.html

□第72回 IETF 6man WGのアジェンダ
  http://www3.ietf.org/proceedings/08jul/agenda/6man.html


◆v6ops WG(IPv6 Operations WG)

v6opsは、IPv6とIPv4の共存技術、IPv6のディプロイメントに関する話題を扱
うWGです。今回は1コマのミーティングを予定していましたが、直前に1コマ追
加となり、月曜日の午前中と、木曜日の午後一番の2スロットで議論が開催さ
れました。

一コマ目のミーティングでは、NAT-PTに変わるIPv6の移行技術に関する話題、
IPv6のCPEルータに対する要求条件の話が実施されました。前回と同様、
NAT-PTに変わる技術は多くの人がIPv6の導入に必要だと考えているためか、参
加者が非常に多く、用意された席数では足りず、立ち見が出てしまうほど盛況
なセッションでした。前回のミーティングにて、v6ops WGでは移行プロトコル
に対する要求条件を中心に扱う方向になっており、今回のミーティングでも要
求条件の議論に多くの時間を費やしました。IPv4/IPv6のプロトコル変換機構
が持つべき必須の基本機能、推奨機能に関する提案として、既存ノードへの変
更許容の是非、ネイティブ接続の優先、DNSとの連携時におけるDNSのセマンティ
クス変更不可、サポートする上位層プロトコル、NATの標準化を実施する、
behave WGの定義した要求条件への準拠の必要性などについて議論されました
が、意見が百出し、議論時間が足りず、メーリングリストで引き続き議論を実
施することとなりました。

この他にIPv6を利用したIPv4 NATを実施するプロトコルとして、
  ・draft-despres-v6ops-apbp(GAPプロトコル)
  ・draft-durand-dual-stack-lite(464変換)
について、概略の説明が実施されました。それぞれ、プロトコル自体は別WGで
議論をすることになります(behave WGにて、IPv4/IPv6変換プロトコルについ
ての提案が実施され、議論されています)。

IPv6のCPEルータに対する要求条件は、ケーブルTVネットワークにおけるケー
ブルモデム/ホームルータの標準である、eRouter仕様に対応するようなIPv6
CPEルータの仕様を記述することを目的とした提案です。CPEルータの持つべき
機能として、ISPとの接続機能、ファイアウォール機能、宅内機器へのアドレ
ス付与機能等があげられています。ミーティングにおいて、このようなドキュ
メントの必要性についてはコンセンサスを得られましたが、ドラフト自体には
まだ不足点も多く、引き続きメーリングリストで議論を実施することになりま
した。

二コマ目のセッションでは、一コマ目に予定されていましたが時間切れで先送
りされたルータ広告に関するセキュリティの議論、アドレス割り振りのガイド
ライン(RFC3177)に関する議論、トンネルプロトコルのセキュリティに関する
議論、および、ブロードバンドネットワークにおけるIPv6実装に関する議論が
実施されました。

不正なルータ広告の扱いに関する議論は、ここ数回継続して実施されています。
今回は、不正なルータ広告の扱いに関する要求条件ドラフトと、それに対する
解としてのRA Guardについてのプレゼンテーションが実施されました。要求条
件ドラフトに対しては、過去にあった不正なDHCPサーバや、不正な無線アクセ
スポイントに関する議論を参照するとよい、といったコメントがありました。
不正なルータ広告に関するドラフトは、今後v6opsのWGアイテムとして議論さ
れることになり、RA Guardに関してはRFC化に向けてWGラストコールをかける
ことになりました。この他、アドレス割り振りのガイドラインについては、前
回議論が再開され、今回v6opsのWGアイテムとして検討を実施することとなり
ました。また、トンネルプロトコルのセキュリティについては、前回まで
Teredoのセキュリティ、として提案されていたものをトンネル一般の話として
書き直したため、IPv6に特化した内容で無くなりました。そのため、今後
v6opsでなくintareaにて議論を継続することになりました。最後に、ブロード
バンドフォーラムとのリエゾンとして、ブロードバンドネットワークにおける
IPv6実装についてのプレゼンテーションがあり、この内容についてはメーリン
グリストでコメントを募集することとなりました。

今回のv6ops WGは議論の内容が多岐にわたり、それぞれ非常に活発に議論され、
多くがメーリングリストでの継続議論となっています。IPv4アドレス在庫枯渇
に関連して、IPv6への注目が高まっていることが伺えました。

□v6ops WG
  http://www.ietf.org/html.charters/v6ops-charter.html
  http://www.6bone.net/v6ops/

□第72回 IETF v6ops WG のアジェンダ
  http://www3.ietf.org/proceedings/08jul/agenda/v6ops.html

この他に、IPv6への移行に関し、全体セッションでもパネル討論が実施されて
います。

第72回IETFミーティングの各種情報は、以下のURLより参照可能です(議事録も
今後掲載される予定です)。

□全体プログラム、WGアジェンダ、発表資料
  https://datatracker.ietf.org/meeting/72/materials.html

□録音
  http://videolab.uoregon.edu/events/ietf/


     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       わからない用語については、【JPNIC用語集】をご参照ください。
            http://www.nic.ad.jp/ja/tech/glossary.html
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
___________________________________
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  :::::  http://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト ::::  http://www.nic.ad.jp/member/(PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
===================================
 JPNIC News & Views vol.573 【臨時号】

 @ 発行         社団法人 日本ネットワークインフォメーションセンター
                 101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F
 @ 問い合わせ先   jpnic-news@nic.ad.jp
===================================
___________________________________
           本メールを転載・複製・再配布・引用される際には
       http://www.nic.ad.jp/ja/copyright.html をご確認ください
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
登録・削除・変更   http://www.nic.ad.jp/ja/mailmagazine/


■■◆                          @ Japan Network Information Center
■■◆                                     @  http://www.nic.ad.jp/
■■

Copyright(C), 2008 Japan Network Information Center

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

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

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

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

ロゴ:JPNIC

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