JPNIC News & Views vol.737【臨時号】

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

本号では、vol.736に続き、2010年3月にアメリカのアナハイムで開催された
第77回IETFのレポート[第2弾]として、「IPv6関連WG報告」の後編をお届け
します。

後編となる本号は、6man WG、behave WGのご報告です。

なお、第1弾の[IPv6関連WG報告」前編は、以下のURLからご覧ください。

□第77回IETF報告
  ○[第1弾] IPv6関連WG報告(vol.736)
    ～v6ops WGについて～
    http://www.nic.ad.jp/ja/mailmagazine/backnumber/2010/vol736.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第77回IETF報告 [第2弾]  IPv6関連WG報告
   ～6man WG、behave WGについて～
                  NTT情報流通プラットフォーム研究所 藤崎智宏／松本存史
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆6man WG (IPv6 Maintenance WG)

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回
のミーティングは、3月24日(水)の午後の2コマ(13:00-16:10)にて開催され
ました。途中、2コマ目はDS-Liteや6rdを扱っているWGとして最近注目を集
めているsoftwire WGと時間帯が重なってしまったため、多くの参加者が途
中退出する様子も見受けられました。

まず、6man WGで取り組み中である、以下の文書のステータス確認が行われ
ました。

   ・経路制御ヘッダー(RFC出版準備中)
   ・IPv6サブネットモデル(IESGレビュー中)
   ・IPv6推奨アドレス表記(IESGレビュー中)
   ・フラグメント重複問題(RFCとして出版)

アジェンダには下記のアイテム/テーマが掲載されていました。

   ・ノード要求仕様の更新
        draft-ietf-6man-node-req-bis
   ・RFC5006(RAでのDNS情報配布)をStandard Trackへ
   ・UDPゼロチェックサム
        draft-fairhurst-tsvwg-6man-udpzero
   ・IPv6フローラベルの使用法に関して
   ・IPv6フローラベルを用いたECMP(Equal-Cost Multi-Path)
        draft-carpenter-flow-ecmp
   ・IPv6フローラベル仕様の更新
        draft-carpenter-6man-flow-update
   ・IPv6フローラベルを用いたトランスポート層シグナリング
        draft-donley-6man-flowlabel-transport-sig
   ・DHCPv6経路情報オプション
        draft-dec-dhcpv6-route-option
   ・ユニークIPv4射影アドレス
        draft-thaler-6man-unique-v4mapped
   ・ルータ間リンクでの127ビットプリフィクス
        draft-kohno-ipv6-prefixlen-p2p
   ・アドレス選択
        draft-ietf-6man-addr-select-considerations
        draft-ietf-6man-addr-select-sol
   ・データプレーンデータグラムにおいてRPL情報を伝達するためのRPLオ
     プション
        draft-hui-6man-rpl-option
   ・近隣探索ベンダー固有オプション
        draft-gundavelli-6man-ipv6-nd-vendor-spec-options
   ・RS(ルータ要請)のマーキング
        draft-krishnan-6man-rs-mark

この中で、DHCPv6経路情報オプションについては、既に行われたmif WGのセッ
ションにおいて、mif WGで扱われることがほぼ確定したため、本セッション
での発表はありませんでした。これらのアジェンダの中から、いくつかのト
ピックについてご紹介します。


○RFC5006(RAでのDNS情報配布)をStandard Trackへ

RFC5006で定められた、RAを用いたDNS情報配布オプションを、これまでの
Experimental(実験的)のステータスから、Standard Track(標準としての提
案)に変更しようというテーマについての議論が行われました。このアイテ
ムについては、月曜日に行われたv6ops WGのセッションや、v6ops WGのメー
リングリスト上で、支持者が大勢を占めるという状況になっており、標準化
を進めることについての合意はほぼ形成されていましたが、6man WGが実際
のプロトコル策定を行うWGということもあり、ここでも再度発表が行われま
した。

このセッションでは、DNS関連のオプションとしてはDomain Search Pathオ
プション等も存在するが、これらは必要ではないのか、という疑問に対して、
Domain Searh Pathは通信のために必須ではないが、DNSサーバアドレス情報
は通信のために必須であるから、RAに含めるべきだ、といった意見が出され
ました。

また、他にもlifetimeオプションは有用ではないか、Domain Nameオプショ
ンはあった方がいい、といった意見は出されましたが、このアイテムについ
て標準化を進めることはほぼ合意が取れていることが確認されました。


○IPv6フローラベルの使用法に関して

IPv6ヘッダー中にフローラベルという20ビットのフィールドがあり、
RFC3697でこの使用法について規定されています。しかし、現在このフィー
ルドは広く利用されているとは言えず、RFC3697で定められた、途中のルー
タでこのフィールドを変更してはならない、といった規定がその利用を制限
しているためこれを緩和しようという提案がなされました。

提案内容としては、現在のフローラベルの1ビット目が1にセットされていた
場合に、それ以降の19ビットはRFC3697の規定が適用されず、サイト等のロー
カルドメインで利用してよい、というものです。

また、フローラベルの具体的な利用法についても提案があり、ECMP
(Equal-Cost Multi-Path)というトラフィックの負荷分散や、QoS(Quality of
Service)の実現等が提案されました。これらの利用例は、上記のフローラベ
ルの規定が変更されなければ実現が難しく、現在の規定の制限を受けている
ものとして説明されました。

この発表に関する議論としては、実際にフローラベルがどの程度、どのよう
に利用されているのかという疑問が投げかけられ、それを調査してから仕様
変更に着手するべきである、といった慎重な意見も出されました。また、実
際にフローラベルが使われている例についても紹介がありました。仕様を変
更することで、ローカルドメインにおける新たな使用法が可能になるため、
ぜひ使用を変更するべきであるという意見と、それによってこれまでの使用
法が不可能になってしまうという意見があり、議論は平行線となりました。


○ルータ間リンクでの127ビットプリフィクス

ルータ間に付与するアドレスとして、パケットのループ(ping-pong)や、近
隣探索キャッシュ溢れ等の問題の発生を防ぐために、127ビットのプリフィ
クスを用いることが有用です。しかし、IPv6ではサブネットエニーキャスト
アドレスが存在するため、これを利用することができないという問題が提起
され、ルータ間リンクではこのアドレスを無効にしようという提案がなされ
ました。

Point-to-Pointリンクが利用できるのではないか、また、ホームゲートウェ
イのWAN側でも利用できるようにするのか、といった議論が行われ、WGアイ
テムとしての採用はこれらの議論を行ってから、ということになりました。


○アドレス選択

IPv6のアドレス選択方式については、複数の送信元アドレスと送信先アドレ
スのペアが存在するときに、短時間で一斉にこれらのペアについて通信を試
みる、アグレッシブモードと呼ぶ方式と、従来方式との棲み分けについての
提案がなされました。提案内容としては、どちらの方式を採用した場合でも、
サイトのポリシーを適用することは必要であり、このポリシーを配布し適用
する方法については、アグレッシブモードと従来方式とで、別々に分けて議
論を行うことが可能であり、そのように進めようというものでした。

その後の議論では、アグレッシブモードの有用性が思ったほど大きくない研
究結果の紹介があったり、アグレッシブモードについては後で検討を進めれ
ば良いといった意見が出されたりしました。また実際のポリシー配布の方法
については、実際の配布する情報の選定がまだ議論が十分し尽くされていな
いという意見があり、メーリングリストで引き続き検討を続けるということ
になっています。

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

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


◆behave WG (Behavior Engineering for Hindrance Avoidance WG)

behaveは主にNATの挙動に関して扱うWGですが、その技術的な関連性から
IPv6-IPv4変換についての議論も行われています。今回は、3月25日(木)と26 
日(金)に合わせて5時間以上ものスロットを用いて、現在のWGアイテムのス
テータス紹介と、今後のアクションアイテムの選定が行われました。

IPv6-IPv4変換の基本方式については、以下の文書がIESG(Area Director)の
レビュー段階となっており、Transport AreaのArea Directorである、Magnus
Westerlund氏からいくつかのコメントや質問が行われました。なお、この基
本方式では、IPv6ホストからIPv4ホストへの通信は1対多の変換、逆にIPv4
ホストからIPv6ホストへの通信は1対1の変換について定めたものとなってい
ます。

       draft-ietf-behave-address-format-04
       draft-ietf-behave-dns64-07
       draft-ietf-behave-v6v4-framework-07
       draft-ietf-behave-v6v4-xlate-stateful-09
       draft-ietf-behave-v6v4-xlate-10

上位層のプロトコルの扱いに関して、トランスレータが上位層のプロトコル
に対応していない場合に、そのパケット転送を必須(MUST)とするかどうかと
いう質問が行われました。会場からの反応としては、ステートフルモードで
は転送はできない、MUSTではなくSHOULDにするべきだ、等の意見がありまし
た。またIPv4ヘッダーのIP IDフィールドの扱いについて明記することが必
要であるとの意見が述べられました。

続いて、behave WGの今後のアクションアイテム選定と、マイルストーンの
設定をするべく、さまざまな方式提案の発表が行われました。主に以下のテー
マについて議論が行われました。

   ・IPv4ネットワークから、IPv6インターネットへの通信(シナリオ3)
   ・IPv4インターネットから、IPv6ネットワークへの通信(シナリオ4)
   ・マルチキャストパケットのIPv6/IPv4変換
   ・IPv6-onlyホストでのIPv4アドレスの扱い
   ・デュアルスタックホストでのNAT64利用を避けるための方式
   ・NATのハイアベイラビリティ、負荷分散方式
   ・ラージスケールNAT

これらのうち、いくつかのトピックについて概況をご紹介します。


○IPv4ネットワークから、IPv6インターネットへの通信(シナリオ3)
○IPv4インターネットから、IPv6ネットワークへの通信(シナリオ4)

IPv4からIPv6への変換については、トランスレータをIPv6サーバ側に設置し
てIPv4クライアントからのIPv4での通信をIPv6に変換するシナリオ4と、
IPv4クライアント側に設置してIPv4クライアントがIPv6インターネットに接
続できるようにするシナリオ3とが既にチャーターに掲載されています。し
かし、これらの方式はDNSへの依存度の高さ等、以前廃止されたNAT-PTでの
問題点をクリアすることが難しく、WGでの標準化マイルストーンも設定され
ていないという状況になっています。

今回も中国勢をはじめ、両方のシナリオについてさまざまな提案がなされま
した。シナリオ4については、IPv4-IPv6変換にIPv4アドレスのポート部分を
用いてアルゴリズミックに行うことでステートレスに近づけたもの、シナリ
オ3については、NAT-PTのIPv4-IPv6変換方式そのままのもの、BIS(Bump In
the Stack)と呼ばれるホスト内で変換を行うもの、等が提案され活発な議論
が行われました。

NAT-PTでの問題の多くが解決されていなかったとしても、移行にはトランス
レータが必要であり、これらの技術が必要である等の肯定的な意見も複数あ
り、またこれらのシナリオは緊急性がそれほど高くはなく、必要になってか
ら議論すべきだ、との意見も出されました。これらの議論を踏まえて、次の
ステップについてはチェアとADとの協議で決定することになりました。


○NATのハイアベイラビリティ、負荷分散方式

NATのハイアベイラビリティや、負荷分散方式については、これまでの議論
のサマリー等が提示され、これら方式の標準化の是非について、議論が行わ
れました。ベンダーからの意見と利用者(キャリア)からの意見が大きく異なっ
ており、マルチベンダー環境でも使えるようにすべく、標準化が必要だとい
うキャリアからの意見と、L2スイッチ等でもベンダー独自方式でやっている
ように、こういった技術については標準化は難しくベンダーでの独自方式で
進めるべきだとのベンダーの意見で対立した状況となりました。


○ラージスケールNAT

ISP等においてNATを行う、ラージスケールNATについても発表がありました。
ラージスケールNATに関連する各文書の位置づけや、改訂内容について説明
があった後、数名から支持を表明するコメントがありました。特に反対意見
や質問等は挙げられなかったため、今後behaveのWGアイテムとして標準化が
進むものと思われます。

また、上記以外のトピックとして、今回IETF77の会場ネットワークで運用さ
れていたNAT64トランスレータの実験について報告がありました。カナダの
VIAGENIE社のオープンソース実装を用いた実験で、専用のSSIDを用いて実験
が行われていました。実験の参加ホスト数は34と、あまり多くはなかったも
のの、いくつかのバグや、各種OSやソフトウェアの問題等が発見され、有意
義な実験となったようです。

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

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


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

 ＠ 発行         社団法人 日本ネットワークインフォメーションセンター
                 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
このページを評価してください
