＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲         ◆ JPNIC News & Views vol.772【臨時号】2010.8.27 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.772 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2010年7月25日から30日の6日間にわたり、オランダのマーストリヒトで開催
された第78回IETFのレポートを、本号より連載でお届けします。

まず連載の第1弾として、本号では「IPv6関連WG報告」をお送りします。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第78回IETF報告 [第1弾]  IPv6関連WG報告
                  NTT情報流通プラットフォーム研究所 藤崎智宏／松本存史
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2010年7月25日(日)から30日(金)まで、オランダのマーストリヒトにて第78回
IETFミーティングが開催されました。同時期、日本は酷暑でしたが、現地は
最高気温が摂氏25度程度で、カラっとした過ごしやすい陽気の中でのミーティ
ングでした。今回の参加者は、267人の新規参加者を含み、合計1,153名でし
た。また、参加者の内訳は、米国からが最も多く、続いて中国、日本、ドイ
ツ、といった様子だったようです(プレナリにおけるIETFチェア発表より)。

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

◆6man WG (IPv6 Maintenance WG)

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回
は、7月27日(火)の午後最後のコマと、26日(水)午前2コマ目の、合計2コマ開
催されています。

最初にいつもの通り、6man WGで取り組み中である以下の文書について、ス
テータス確認が行われました。

・IPv6拡張ヘッダの統一フォーマット(WGドラフトの初版発行)
・IPv6サブネットモデル(RFC5942として発行)
・IANA経路制御ヘッダ(RFC5871として発行)
・IPv6推奨アドレス表記(RFCエディタ発行待ち)
    ※ミーティング後、メーリングリスト(ML)上で議論あり
・DNS RA(Router Advertisement)オプション(IESG(Internet Engineering 
  Steering Group)評価、AD(Area Director)フォローアップ中)


今回のミーティングでは、以下のアイテム/テーマについて議論されました。

2010年7月27日(火)：
・ノード要求仕様の更新
    draft-ietf-6man-node-req-bis
・IPv6アドレス選択
    draft-ietf-6man-addr-select-considerations
    draft-arifumi-6man-rfc3484-revise
・P2Pリンク上におけるIPv6プリフィクス長/127の利用
    draft-kohno-ipv6-prefixlen-p2p

2010年7月28日(水)：
・UDPゼロチェックサムの検討
    draft-ietf-6man-udpzero
・IPv6フローラベル仕様の更新
    draft-carpenter-6man-flow-update
・IPv6フローラベルを用いたECMP(Equal-Cost Multi-Path)
    draft-carpenter-flow-ecmp
・RPL(IPv6 Routing Protocol for Low power and Lossy Networks)での
  IPv6経路制御ヘッダの利用
    draft-hui-6man-rpl-routing-header
・データプレーンデータグラムでのRPL情報運搬のためのRPLオプション
    draft-hui-6man-rpl-option

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

・ノード要求仕様の更新

IPv6ノードが実装すべき仕様(RFC)を定義する文書の更新に関する議論です。
最新ドラフトでの変更点についての説明、および以下の点に関する議論が実
施されました。

 - 設定方法：RAとDHCP
    設定方法の柔軟性を上げるために両方で同じ項目を設定できた方がよい、
    という意見と、両方が使用された場合に、ホストが得た情報に矛盾があっ
    た場合の対処の困難性が指摘されました。

 - DNS設定
    RAによるDNS設定の配布方法が標準(Standards Track)になることを受け、
    RAによる配布を必須とすべきかについて議論されました。RAも必須とす
    べきという意見が多く、MLで確認することとなっています。

 - アドレス設定
    現在のRFCでは、DHCPによるアドレス配布の実装は「MAY」となっていま
    す。企業等はRAよりDHCPを使うだろうという意見もあり、これを
    「SHOULD」とする方向になりました。

 - IPsecとIKEv2に関する記述
    現在のRFCでは、IPsecの実装は「MUST」となっています。IKEv2と合わ
    せ、これを「SHOULD」とする方向になりました(会場では、"strong 
    SHOULD"と言われていました)。

・IPv6アドレス選択

IPv6ノードが複数のアドレスを持った場合のアドレス選択手法について、6man
WGではデザインチーム(DT)を構成して議論を続けてきました。今回、デザイ
ンチームから、議論となっていたアドレス選択ポリシーの配布方法としては
DHCPが適していること、複数の矛盾するアドレス選択ポリシーを受信した場
合の扱いについては、別途検討を進めるべきであること等の、議論結果の報
告がありました。この報告を受け、アドレス選択手法を定義しているRFC3484
の改版提案およびDHCPによるアドレス選択機構の提案について、前者はWGド
ラフトとして進めていくこと、後者については、さらにMLで議論を実施する
こととなっています。

・UDPゼロチェックサムの検討

現状「MUST」となっているIPv6のUDPにおけるチェックサム計算について、UDP
をトンネルのトランスポートとして利用する場合には、これを不要とする提
案です。前回のIETFにて、WGとしてこの問題に取り組むこととなり、今回、
WGアイテムとして議論されました。UDPチェックサムが'0'となった場合の影
響について、中間ノード(ルータ等)や、エンドノードの観点でどうなるかに
関する調査の必要性や、そもそもチェックサムが'0でよい場合かどうかの区
別ができるのか、という問題が提起されており、MLで継続議論となっていま
す。

・IPv6フローラベル仕様の更新

IPv6の特徴の一つとしてあげられることの多い、フローラベルの仕様更改に
関し、前回のIETFに引き続き議論が行われています。今回は、フローラベル
を経路の途中で変更可能とするかどうかが、主な議論になりました。現在の
仕様では、フローラベルは経路途中で変更してはいけないことになっていま
すが、これを変更可能とすることで、AS内等でローカルに利用できるように
なります。しかしながら、フローラベル値は変更されたかどうか検知ができ
ないため、情報として信用できるのか、という問題があります(IPsecでもフ
ローラベルは保護されていません)。会場では、変更可能とすべき、という意
見の方がやや多かったものの、結論は出ませんでした。

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

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


◆savi WG (Source Address Validation Improvements WG)

savi WGは、LAN環境において、始点アドレスの詐称を防ぐ機構について検討
するWGです。今回は、7月26日(月)朝一番のコマにて、開催されました。参加
者は20～30名と、それほど多くない人数での議論となっています。今回は、
主にSAVIの解としてのステートレスアドレス自動設定(SLACC)における詐称防
止(IPv6)、DHCP環境における詐称防止(IPv4/IPv6)について、議論が実施され
ました。ポイントとしては、

・SLACCにおける、savi機構のライフタイムの扱い
・savi装置のポートにおいて扱わなければならないIPv6アドレス数
・SLACCとDHCPv6が同時に使われた場合の扱いの問題

等が、特に時間を割いて議論されていました。

saviの機構はスイッチ、またはルータに実装されることになりますが、既に
多くのベンダー(主に中国ベンダー)にて実装されており、運用実験等が進ん
でいる、という報告もありました。

□savi WG
  https://datatracker.ietf.org/wg/savi/

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


◆v6ops WG (IPv6 Operations WG)

v6opsは、IPv6に関するオペレーション技術や、移行技術に関する議論を実施
するWGです。今回は、7月26日(月)と30日(金)に2時間ずつ、合計2コマにて議
論が実施されてました。今回も、数々の新提案があり、内容も多岐にわたっ
ていました。いくつかのトピックについて、簡単に紹介します。

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

従来IPv4で行われてきた、NATを用いた複数サイト帰属(マルチホーミング)
を、IPv6においてNATを用いずに実現する方法について提案したものです。そ
もそも、家庭ユーザーなど小規模サイトでの複数サイト帰属は、複数のISPに
接続するケースや、ISP接続とVPN接続の併用といった場合にNATを用いて行わ
れています。IPv6のend-to-end原理を実現するためには、NATを使わずにこう
いった複数サイト帰属を実現する必要があります。その方法として、それぞ
れの上流ネットワークから付与されたIPv6アドレスを、サイト内の端末に付
与し、その結果ユーザー端末に複数のアドレスを付与するマルチプリフィク
ス環境を構築し、そこで経路選択情報とDNSサーバ選択情報、アドレス選択情
報の三つの情報を、ホームゲートウェイやユーザー端末に配布する必要があ
る、という発表がなされました。また、この提案については、BBF(BroadBand 
Forum)において既に必要であるという合意がなされ、今回IETFへのリエゾン
文書が送付されています。

・IPv6対応ISPのリスト化についての基本ガイドライン
  (draft-kawamura-ipv6-isp-listings)

ユーザーがIPv6対応のISPを選定する際に、IPv6対応をうたっていてもISPご
とに対応度合いがまちまちであり、明確な基準がなくユーザーに混乱をもた
らす、といった問題への対処方法として、明確なIPv6対応項目リストを提示
したものです。現在のドラフトでは、既存のIPv6対応ISPリストの情報を収集
し、それらのチェック項目の詳細内容についてまとめ、新たなチェックを行
う場合の判断基準について提案しています。今回のセッションでは、判断基
準の妥当性や、Basic、Advancedといった判断基準をクラス分けする際のネー
ミングについて、活発な議論が行われました。

・IPv6でのCIDRによるアドレス集約 (draft-azinger-cidrv6)

IPv6における将来的な経路表爆発問題が発生するという可能性を示唆し、そ
の対策についての提案を行ったものです。近年IPv6のDFZ(Default Free Zone)
において、IPv6 PIアドレスをはじめとした小さなアドレスブロックが広告さ
れており、それによって将来IPv6もIPv4と同様に経路表爆発の問題が発生す
るとし、その推移の予想などを行っています。

またその対策として、できる限り集約した経路を広告するなどの手法がまと
められたRFC4692を遵守することを提案し、さらにアドレスを配布するIR
(Internet Registry)に対しては、/32以上の大きなアドレスブロックを極力
配布し、/48などの現在IPv6 PIとして配布している小さいアドレスブロック
の配布は制限するか廃止することを推奨する、としています。セッションで
は、RFC4692で述べられた手法の有効性や、IETFがアドレス配布といったIRの
役割について踏み込むことの是非などについて議論が行われ、今後はIRと一
緒に議論すべきであるなどの提案がなされました。

・エンドサイトへのIPv6アドレス割り当て
  (draft-narten-ipv6-3177bis-48boundary)

既存のRFC3177に記述された、/48をエンドサイトに割り当てるという推奨文
章を更新する件について提案がなされました。現在のIRでの、エンドサイト
へのアドレス配布ポリシーでは、家庭ユーザーなどのエンドサイトに対して
/56を割り当てることを想定した、割り振りアドレスサイズの検討が行われて
おり、既にRFC3177に記述された状況との乖離が発生しています。このためRFC
3177をアップデートすることで、乖離の解消を目的とした提案になっており、
/64から/48の間に明確な境界を設けないこと、また/128単位でのアドレス配
布は推奨されないことなどが盛り込まれています。セッションでの議論とし
ては、そもそもエンドサイトに対して複数の/64を割り当てることの必要性な
ど、基本的な部分の議論から行われ、必要以上にアドレスを付与してもかえっ
て有害であるだとか、IPv6版NATの必要性を排除するためにも、潤沢なアドレ
スを付与することが必要だといった意見が出され、継続して議論を行うこと
になっています。

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

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


◆softwire WG (Softwires WG)

softwire WGでは、トンネルを用いてIPv4 over IPv6、またはIPv6 over IPv4
通信を実現する方式を検討するWGです。IPv4 over IPv6やIPv6 over IPv4の
汎用的なトンネル方式以外に、昨今さまざまなISPで導入が検討されている、
DS-Lite(Dual Stack Lite)や6rd(IPv6 Rapid Deployment)といった、新しい
IPv4とIPv6の共存環境を構築する方式が検討されています。

6rdはつい先日RFC5969として公開されました。DS-Liteは現在ADによるレ
ビューが行われています。

・6rd+(draft-despres-softwire-6rdplus)
・6rd over UDP(draft-lee-softwire-6rd-udp)

今回のセッションでは6rdやDS-Liteへの拡張提案が主に議論され、まず6rdの
拡張方式として、6rdをUDPでカプセリングすることで、CPEなどのNAT装置が
6rdに対応していない環境において、ホストが6rdを終端し、IPv6アドレスを
取得して利用する方式が提案されました。しかし、IPv4ネットワークを介し
て、ユーザーにIPv6接続性を提供する方法としては、既にTeredoやL2TPといっ
た複数の方式が確立されており、既存の方式でカバーされていない部分は何
なのかといった部分を詰める必要がある、という議論が行われました。

・DS-Lite RADIUSアトリビュート
  (draft-maglione-softwire-dslite-radius-ext)
・DS-Liteでのフローラベル利用 (draft-donley-softwire-dslite-flowlabel)

また、DS-Liteの拡張提案も複数議論され、DS-Liteにおけるトンネルアドレ
スのRADIUSアトリビュートについての提案や、DS-Liteのトンネルについて
IPv6ヘッダのフローラベルを用いたQoS制御の提案などがありました。前者の
必要性については賛同者多数でしたが、後者については、やはりフローラベ
ルの仕様変更を含む提案であり、問題提起と要件定義というフレームワーク
を築いた上で議論を慎重に進めるべきである、という意見が多数ありました。

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

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


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

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