＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲         ◆ JPNIC News & Views vol.801【臨時号】2010.12.10 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
---------- PR --------------------------------------------------------
◆━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【ＷＡＮ】【インターネット】【オンラインストレージ】【レンタルサーバ】
　　(((　あなたの企業ネットワークの最適化をお手伝い　)))
　　　北陸通信ネットワーク株式会社　http://www.htnet.co.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・
----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.801 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号では、vol.800に続き、2010年11月に中国の北京で開催された第79回IETF
のレポート[第2弾]として、IPv6関連WG報告をお届けします。

なお、全体会議報告については、以下のURLからバックナンバーをご覧くださ
い。

□第79回IETF報告 特集
  ○[第1弾] 全体会議報告 (vol.800)
    http://www.nic.ad.jp/ja/mailmagazine/backnumber/2010/vol800.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第79回IETF報告 [第2弾]  IPv6関連WG報告
                            NTT情報流通プラットフォーム研究所 藤崎智宏
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2010年11月7日(日)から12日(金)まで、中国の北京にて第79回IETFミーティン
グが開催されました。同時期の日本より少々寒く、また乾燥等のためか、体
調を崩した方が多かったように見受けられました。

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

◆6man WG (IPv6 Maintenance WG)

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回
は、11月9日(火)の午後最初に1コマにて開催されました。

セッション開始後、チェアより6man WGで取り組み中である、以下の文書につ
いてステータス報告がありました。

・IPv6推奨アドレス表記(RFC5952として発行済み)
・DNS RAオプション(IESG承認、RFCエディタ発行準備中)
  ※2010年11月末に、RFC 6106(Standard Track)として発行
・ルータ要請メッセージでの回線識別(draft-krishnan-6man-rs-mark-08):
  WGドラフトとして登録

最後の回線識別ドラフトに関しては、「技術的問題が多く、WGドラフトとす
る合意に達していないのでは」という指摘がありましたが、「まずはWGドラ
フトにしてから技術的課題を検討するのであって、RFCとして発行することと
は別」というフォローがありました(WGドラフト化は、IETF79前に、WGドラフ
トとするかどうかの合意確認がMLで実施された結果です）。

今回、以下のテーマが議論されています。時間の割には議題が非常に多いと
いう印象でした。

・IPv6拡張ヘッダの統一フォーマット
    draft-ietf-6man-exthdr
・UDPゼロチェックサムの検討
    draft-ietf-6man-udpzero、draft-eubanks-chimento-6man
・RFC3848 IPv6デフォルトアドレス選択の更新
    draft-ietf-6man-RFC3484-revise
・P2Pリンク上におけるIPv6プリフィクス長 /127の利用
    draft-ietf-6man-prefixlen-p2p
・重複アドレス選択プロキシ
    draft-costa-6man-dad-proxy
・アドレス登録に関する要求条件
    draft-jiang-6man-addr-registration-req
・IPv6フローラベル仕様の更新
    draft-carpenter-6man-flow-update、draft-carpenter-flow-ecmp
・IPv6フローラベルに関するセキュリティ評価
    draft-gont-6man-flowlabel-security
・Teredo ループ攻撃の緩和
    draft-gont-6man-teredo-loops
(・エンドポイント識別子(EID)オプションの廃止
    draft-gont-6man-obsolete-eid-option) → 時間切れで議論できず。

これらのアジェンダの中から、いくつかのトピックについてご紹介します。

・IPv6拡張ヘッダの統一フォーマット
    draft-ietf-6man-exthdr-00.txt

IPv6拡張ヘッダの標準フォーマットを決めよう、という提案です。現在定義
されている拡張ヘッダでは、フォーマットに統一性はありません。今後新た
に拡張ヘッダを追加定義する際、新しい拡張ヘッダを認識できない古い機器
がそのヘッダ部分をスキップすることができるよう、ヘッダの長さ情報等の
フィールドを規定するなど、フォーマットに統一性を持たせることを提議し
ています。会場から、中間ノードが知らない拡張ヘッダに遭遇した場合に取
るアクション(そのまま通過させる/パケットを落とす)を定めるビットを設け
るべき、という意見があり、このビット追加を反映後、WGラストコールを実
施することとなりました。

・UDPゼロチェックサムの検討
    draft-ietf-6man-udpzero、draft-eubanks-chimento-6man

IPv6では必須となっているUDPでのチェックサムについて、IPv4と同様に、計
算の省略を可能にしようという、ここ数回議論が続いている提案です。計算
しない場合に関する考察である文書(draft-ietf-6man-udpzero)は、WGラスト
コールを実施することになり、実際の適用手法に関する提案
(draft-eubanks-chimento-6man)が議論となりました。適用を特定の場合のみ
に限定することについては概ね賛同を得ましたが、IPv6の基本文書であるRFC
2460への改変が必要という意見も上がっています。後者の文書についても、WG
ドラフトとして引き続き検討をすることに反対はありませんでした。

・RFC3848 IPv6デフォルトアドレス選択の更新
    draft-ietf-6man-RFC3484-revise

IPv6ノードおよび通信相手が複数のアドレスを持つ場合に、通信に使うアド
レスペアを選択する必要があります。この選択方法については、RFC3848に記
載されていますが、デフォルトのルールに最新のアドレス情報(ULA; Unique 
Local IPv6 Unicast Addresses(RFC4193)等)が記載されていない問題等があ
るため、RFC3484を改版しようという提案です。本提案には、アドレスペアを
選択する際の優先度に関して、ULA空間の優先度を引き下げるという提案が含
まれていましたが、これに対して「自分が使っているULA空間は優先すべき」
等の意見があり、検討を継続することになりました。関連して、デフォルト
ルールをDHCPv6で配布し、変更できるようにするという提案
(draft-fujisaki-6man-addr-select-opt)について、WGドラフトとして扱うこ
とに対するコンセンサス確認が実施され、WGドラフトとして議論することに
なりました。

・P2Pリンク上におけるIPv6プリフィクス長 /127の利用
    draft-ietf-6man-prefixlen-p2p

前回WGドラフトとなった、ルータ間のリンクに付与するアドレスとして、127
ビットのプリフィクスを用いることを可能としよう、という提案についての
議論です。この文書中に挙げられている問題の一部は、より広い範囲でも検
討する必要があるのでは、といった意見が出されました。ミーティング後に、
WGラストコールを実施し、より広い意見を集めることになりました(2010年12
月6日までの期限でラストコールが実施されていました)。

今回の議論で、上記以外に、

・重複アドレス選択プロキシ   draft-costa-6man-dad-proxy
・IPv6フローラベル仕様の更新 draft-carpenter-6man-flow-update、
                             draft-carpenter-flow-ecmp

がWGドラフトとして採用の方向、

・Teredoループ攻撃の緩和     draft-gont-6man-teredo-loops

が適切なWGにて議論を継続、となっています。

□6man WG
  https://datatracker.ietf.org/wg/6man/

□第79回 IETF 6man WGのアジェンダ
  http://www.ietf.org/proceedings/79/agenda/6man.html


◆v6ops WG (IPv6 Operations WG)

v6opsは、IPv6に関するオペレーション技術および共存・移行技術に関する議
論を実施するWGです。今回は、11月10日(水)と12日(金)の2コマにて議論が実
施されました。

IPv6の導入加速の世相を反映してか、今回も数多くの新提案がありました。
チェアの方でも、議論時間を極力短縮するため、おのおの発表では合意の確
認を実施せず、インターネット上に用意したサイトにて、賛同、不賛同を後
ほど入力するような形式を取ることにする、という周知が事前にありました。

ここでも、いくつかのトピックについて、簡単に紹介します。

・Happy Eyeballs: デュアルスタックホストにおいて通信を成功させるために
    draft-wing-v6ops-happy-eyeballs-ipv6
・複雑な環境でのTCPセッションの開始
    draft-baker-v6ops-session-start-time

IPv6/IPv4デュアルスタック環境では、通信相手がIPv4/IPv6両方のアドレス
を持っている場合、ノードは、最初に選んだ通信プロトコルでの通信に支障
が発生した場合に、もう一方の通信プロトコルに切り替えるという、いわゆ
るフォールバック、と呼ばれる動作をすることが一般的です。昨今の多くの
デュアルスタック実装では、IPv6がIPv4よりも優先されるため、IPv6通信に
支障があった場合にIPv4で再度試す、という動作をしますが、この切り替え
に時間がかかり、ユーザーの利便性が損なわれる、という問題が発生してい
ます。このようにデュアルスタック環境で発生する問題を、ユーザーの観点
からいかに解決するかについて提案があり、議論が行われました。複数のTCP
セッションを同時にスタートし、最初に通信できたセッションを利用する、
といった解が提案されています。SCTPでの実装例や、アプリケーションとの
関連に関するコメントが出されました。提案名が漠然とし過ぎていてすぐに
提案内容を想像できないため、もっとわかりやすいものに変更すべき、とい
う意見もありました。

ミーティング後に公表された投票の結果、それぞれ78.8%、63.2%がWGドラフ
トとして扱うべき、ということになり、特にHappy Eyeballs については、出
版ステータスの確認(InformationalかBCP(Best Current Practice)か)が、ML
上で実施されています。

・IPv6カスタマーエッジルータの高度要求仕様
    draft-wbeebee-v6ops-ipv6-cpe-router-bis

・IPv6普及におけるCPEに関する考察
    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ドラフトとして議論をす
べきという意見でした。

・IPv6 AAAA DNSホワイトリスティングの影響
  draft-livingood-dns-whitelisting-implications

キャッシュサーバからのクエリパケットのアドレスに基づき、DNS権威サーバ
にて、AAAAレコードを応答するかどうかを制御する、DNSホワイトリスティン
グに関する提案です。上記Happy Eyeballsのドラフトにも関連しますが、こ
の仕組みにより、クライアント(正確には、クライアントの利用するキャッ
シュサーバ)のIPv6アドレスごとに、自サイトにIPv6を利用してアクセスする
かどうかを制御できます。Googleでは実際にこの仕組みを使い、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在庫が枯渇直前となり、このような空間を用意することは
既に困難な状況になっていると思われます。

その他、前回のレポートでご紹介した、

・NATを用いないIPv6マルチホーミング方式
    draft-troan-multihoming-without-nat66

について、ステータスレポートが実施されました。こちらについては、76%が
WGドラフトとして議論をすべきという結果になっています。

□v6ops WG
 http://datatracker.ietf.org/wg/v6ops/charter/

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


◆softwire WG (Softwires WG)

softwire WGは、トンネルを用いたIPv4 over IPv6、またはIPv6 over IPv4通
信の実現方式を検討するWGです。昨今、さまざまなISPで導入が検討されてい
る、DS-lite(Dual Stack Lite)や6rd(IPv6 Rapid Deployment)といった、新
しいIPv4とIPv6の共存環境を構築する方式も併せて検討されています。今回
は、開始早々の月曜朝一のコマにも関わらず、100名を超える参加者を集めて
開催されました。

10件以上の新規提案があるなど議論アイテムも非常に多く、新規アイテムの
提案については、「技術の説明で1スライド、問題点や必要性等で1スライド
程度で説明することを話者に連絡済み」「なるべく時間を短く」とチェアよ
り念押しがありました。このためか、ほとんどの新規アイテムで議論も質問
もありませんでした。

この後、チェアからDS-liteのステータスに関する説明がありました。DS-lite
は、本体プロトコルと、必要なパラメータをDHCPで配布するDHCPオプション
定義の二つの文書に分けられ、それぞれ個別に標準化が進められています。
本体となるDS-lite(draft-ietf-softwire-dual-stack-lite)ですが、AD(Area 
Director)のレビューは終了し、そのコメント対応中となっています。DHCPオ
プションのドラフト(draft-ietf-softwire-ds-lite-tunnel-option)では、
IESGレビューでコメントが付き、トンネル終点の指定に、FQDN(Fully 
Qualified Domain Name; 完全に限定されたドメイン名)とIPアドレスの両方
ではなく、どちらか片方のみ指定することが議論され、その結果、最終的に
はFQDNのみを指定するよう変更することになりました。こちらはドラフト修
正後、WGラストコール、IESGにレビューを再依頼の予定となっています。

その他、以下のようなポイントが議論されています。

・今回のIETFよりWG化されたPCP(Port Control Protocol) WGより、PCPのプ
  ロトコルトランスポートとしてIPv6とIPv4のどちらを利用すべきか、とい
  う問いかけがありました。特にDS-liteでの利用の場合を想定しているとの
  ことです。チェアからの双方ともに得失があるとの説明通り、その後の議
  論でも意見が分かれました。

・draft-ietf-softwire-dslite-radius-ext
  draft-guo-softwire-6rd-radius-attrib

  softwireのチャーター内のアイテムとして6rdやDS-liteのradius属性定義
  の提案がありました。それぞれ、WGドラフトとして議論していくことになっ
  ています。ISPでこれらのプロトコルを使用するには必須な部分であり、実
  導入に向けて検討が進んでいることがうかがえます。

□softwire WG
 http://datatracker.ietf.org/wg/softwire/charter/

□第79回 IETF softwire WGのアジェンダ
 http://www.ietf.org/proceedings/79/agenda/softwire.txt


IETFミーティングのすべての資料、Jabberログ、オーディオ録音等は、以下
のページより参照可能です。

 http://tools.ietf.org/agenda/79/


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【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.801 【臨時号】

 ＠ 発行         社団法人 日本ネットワークインフォメーションセンター
                 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), 2010 Japan Network Information Center