第91回IETF報告 [第2弾] IPv6関連WG報告～6man、v6ops、6lo、Homenet WG～

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

2014年11月9日(日)から14日(金)までハワイのホノルルで開催された、第91回
IETFミーティングのレポートを、前号より連載にてお届けしています。第2弾
となる本号では、IPv6関連WGの動向をお伝えします。次号は、セキュリティ
関連WGのご報告をする予定です。

  □第91回IETF報告 [第1弾] 全体会議報告 (vol.1262)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2014/vol1262.html

なお、本日の14時半からJPNICにて、この第91回IETFのオンサイトでの報告会
も開催します。ISOC Japan ChapterとJPNICとの共催の会合です。このメール
マガジンでは紹介していないWGの模様も報告されますので、お時間のある方
はぜひご参加ください(申し込みされていない方は、直接会場受付にお越し
ください)。

  □IETF報告会(91stホノルル)開催のご案内
    https://www.nic.ad.jp/ja/topics/2014/20141209-01.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第91回IETF報告 [第2弾] IPv6関連WG報告
   ～6man、v6ops、6lo、Homenet WG ～
                                           株式会社インテック 廣海緑里
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

第91回IETFにおけるIPv6関連のWGについて、6man WG、v6ops、6lo、Homenet
WGの議論を中心に報告します。

◆6man WG(IPv6 Maintenance, Int Area)

6man WGのワーキンググループでは、IPv6プロトコルの基本仕様そのものにつ
いてのメンテナンス(見直しや拡張)を議論しています。

ワーキンググループ文書として議論進行中のもの(Working Group Draft)のう
ち、二つに関して取り上げられました。すでにこのWGで取り上げられている
個人文書(Individual Draft)七つについて継続議論があり、今回初めて投稿
された文書(new Individual Draft)五つについての発表が予定されていまし
たが、Atomic Fragmentやv6GEOといった最初の提案で時間がかかってしまい、
新しく投稿された5文書については、時間切れで議論されませんでした。

本稿では、議論のあった中からいくつかを取り上げます。

なお、今回問題提起された、個人文書の一つ「Deprecating the Generation
of IPv6 Atomic Fragments」が会期後、WGドキュメントに「昇格」しました。

1. Efficient ND Design Team報告

   前々回のミーティングでも議論された「Efficient ND」は、本メールマガ
   ジンvol.1183【臨時号】で「無線LAN環境での隣接探索プロトコル(ND)の
   問題についての議論」として解説された問題点の改善策を検討するもので
   す。今回、デザインチームが発足され、まとまった報告がされました。

 ・第89回IETF報告 [第2弾]  IPv6関連WG報告 ～6man、v6ops、softwire WG～
   https://www.nic.ad.jp/ja/mailmagazine/backnumber/2014/vol1183.html

   プロトコルに手を入れるにしろ、環境にあったオプションの運用を提示す
   るにしろ、まずは問題分析をきちんとするところから出発しているようで
   す。そのため、このデザインチームのカバー範囲は、近隣探索プロトコル
   のトラフィック計測から機能ごとの問題分析、問題改善として使えそうな
   テクニックやオプションの検討と広範囲になっています。6man WG単体で
   はなく、v6ops WGと共同での検討事項となっています。

   問題フィールド特定のための計測結果は、マルチキャスト通信の影響や
   バッテリへのインパクトについてまとめた二つの文書として書き起こされ
   ています。
   - draft-vyncke-6man-mcast-not-efficient
   - draft-desmouceaux-ipv6-mcast-wifi-powerusage

   また、重複検出(DAD)については、別の文書に課題整理がされています。
   - draft-yourtchenko-6man-dad-issues

   マルチキャストのRS(ルータ探索)と定期的なRA(ルータ広告)、リンクアド
   レス解決のためのNS(近隣者発見)とNA(近隣者要請)、DAD、Wi-Fiと携帯電
   話網の混在環境、軽量端末などの端末側のパケット送出特性、mDNS(マル
   チキャストDNS)のトラフィックボリュームなどが改善対象として選ばれて
   いました。デザインチームからは、主にRS/RAとDADの改良点として、RAの
   送出に関してタイマーを設けて間隔を長くできるようにすることや、RAに
   リフレッシュオプションを設けること、DADに関しては手動設定の場合に
   のみ実施することやさらに手を加える道など四つのアプローチが提示さ
   れ、議論がされました。

   レビュー対象の文書は、以下三つとなっています。
   - draft-yourtchenko-6man-dad-issues
   - draft-krishnan-6man-maxra
   - draft-nordmark-6man-rs-refresh

   参加者からはデザインチームの活動報告に賛同するコメントが得られ、引
   き続きデザインチームによる検討が継続されます。

2. Recommendation on Stable IPv6 Interface Identifiers
   (draft-ietf-6man-default-iids)

   セキュリティとプライバシーへの配慮のため、MACアドレス由来のインタ
   フェースID(IID)からRFC7217で定義されている隠ぺいされたIIDの適用を
   促す文書です。これが必須のものとして採用されると、主にIPv6をトンネ
   ルで運搬する技術の実装に影響が出ます。セキュリティとプライバシーは
   守るべきですが、運用上は特定ができると都合が良い場合もあるなど、柔
   軟性を求める声もあり慎重な議論がされていました。これも継続議論と
   なっています。

   余談ですが、この議論の途中で使われた"ambiguous"という単語がなぜか
   はやり出し、IPv6系の人が集まるWGやBoFのそこかしこで使われていまし
   た。

3. Deprecating the Generation of IPv6 Atomic Fragments
   (draft-gont-6man-deprecate-atomfrag-generation)

   IPv4ノードとIPv6ノードがSIIT(Stateless IP/ICMP Translation 
   Algorithm) を使って通信している際の、IPv6のAtomic Fragmentについて
   です。問題指摘と廃止の提案については、現状の運用観測に基づいたもの
   ですが、実装側や運用を正すべきであるといった意見や、Atomic Fragment
   を必要とするMANET (Mobile Ad hoc NETwork)の例などがあげられ、簡単
   に廃止できるものではないことから、コンセンサスには至らず、継続議論
   となりました。

4. Including Geolocation Information in IPv6 Packet Headers (IPv6 GEO)
   (draft-skeen-6man-ipv6geo)

   データリンクに使われるプロトコルは多種多様で、必ずしも位置情報を含
   むように作られていませんが、その上位レイヤのIPは共通利用されていま
   す。そこで、IPv6ヘッダに位置情報を含めるようにしようという提案で
   す。位置情報についてもプライバシーへの配慮が必要であるため、これを
   利用する際には暗号化を必須とするべきであるといった意見が寄せられ、
   この提案も継続議論となっています。


◆v6ops WG (IPv6 Operations、OPs & Mgmt Area)

v6ops WGでは、文字通り、IPv6ネットワークの運用管理に関する事項やIPv4
ネットワークへの導入、共存技術など幅広い事項を扱っています。今回も午前
と午後に二つのセッション枠が確保され、6to4の廃止、ULAの利用考察、マル
チプリフィクスの運用ガイド、拡張ヘッダの利用状況調査、DNS64/NAT64環境
で利便性を高めるための専用TLDの提案など、さまざまな提案や報告がされま
した。

なかでも、6to4プロトコルの廃止については、運用被害を防ぐ方向で議論が
白熱しています。運用サイドの意見を取り入れるため、チェアからNANOGなど
の運用者向けメーリングリストにも議事録が共有され、意見が募られました。

1. Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)
   (draft-ietf-v6ops-6to4-to-historic)

   IPv4上でIPv6の通信を行えるようにする6to4技術について、そろそろ役目
   を終えて廃止にする時期なのではという提案です。Windows OSなどで参照
   されるアドレスポリシーテーブルでも、Teredoには規定があるが6to4はな
   くなっているという指摘を受けて、Teredoも廃止してもいいのではという
   意見も出たりしていました。

   アドレスポリシーテーブルでは、6to4はNativeのIPv6より優先度を下げる
   といった評価のための参照がされているため、テーブルから削除すると問
   題が起きるだろうという指摘や、6to4のために予約されているアドレス
   (192.88.99.0/24)をフィルタすれば廃止と同じ意味合いとなるといった意
   見があり、
      (1)6to4の廃止
      (2)RFC3068(6to4リレールータのためのエニーキャストプリフィクス)
         をhistoricステータスにする
      (3)192.88.99.0/24をフィルタする
   という三つの内容に分割して、それぞれ議論することになりました。

2. IPv6 Extension Headers in the Real World
   (draft-gont-v6ops-ipv6-ehs-in-real-world)

   IPv6の拡張ヘッダは、フィルタされて運用に支障をきたす場合が見られま
   す。SI6 Tool Kitの作者である本文書の筆者は、このツールを用いてパブ
   リックなインターネットにおけるIPv6拡張ヘッダの扱い、フィルタ状況に
   ついて調査を実施し、まとめました。拡張ヘッダの種類ごとの状況はなか
   なか興味深いものがあります。調査方法とその結果について、質疑がたく
   さんありました。

   最終的には、実装と運用のガイドとなる文書作成をめざしているようです
   が、ガイドラインの作成には、実装に関する部分があたかも第2の拡張ヘッ
   ダの提案をしているように見受けられる部分があるなど問題があるため、
   待ったがかけられ、調査結果部分を一つの文書として分離してまとめるこ
   とになりました。

   ICMPv6の安易なフィルタも同様ですが、フィルタすることによってブラッ
   クホールとなるといった、どういう問題が起きるかを本文書で確認してお
   くと、健全な運用のイメージがわいて良いのではないかと思います。

3. Design Choices for IPv6 Networks
   (draft-ietf-v6ops-design-choices)

   IPv4とIPv6のdual-stackネットワークやIPv6 onlyのネットワーク構築時
   の、「デザインチョイス」についてのガイドライン文書です。外部接続や
   経路制御の手法選択がメインであるため、現在のもっと広範な設計を予想
   させるようなタイトルから、範囲を絞ったもっとわかりやすいタイトルに
   変更した方がいいという指摘が出ていました。

   その一方で、DHCPやSLAAC (StateLess Address AutoConfiguration)など
   内部の運用術に関して扱った方が良いという「広範」をめざすべきという
   意見も出ていました。また、いずれにしてもセキュリティに関してはしっ
   かり書いておくべきだろうといった意見もあり、引き続き内容を厚くして
   いくことになりました。

4. A Special Purpose TLD to resolve IPv4 Address Literal on
   DNS64/NAT64 environments(draft-osamu-v6ops-ipv4-literal-in-url)

   DNS64/NAT64を運用している環境で、IPv6端末がIPv4のみのアプリケーショ
   ンサーバに明示的にアクセスする場合のURLとして、「.v4」をTLDとして
   指定するとIPv6アドレスにIPv4アドレスをマッピングする仕組みの提案が
   継続議論されています。

   この仕組みの有用性は多くの参加者から賛同されているようでしたが、新
   しいTLDを作ることに難色を示す人が多かったように思われます。代わり
   に、「v4only.arpa」はどうかといった提示もされていました。また、
   DNSSECやcookieがうまく動作しないのでは、ということも指摘されていま
   した。指摘事項に関して文書を更新するとともに、DNSOPSでも議論すると
   いうことになりました。

   今回の私の参加目的として、v6opsでの発表というのがありました。15分
   ほど時間をもらえ、国内で実施している中小規模の組織向けルータのIPv6
   に関するセキュリティテストについて報告をしました。
   "Introducing IPv6 vulnerability test program in Japan,
   <draft-jpcert-ipv6vullnerability-check>"という文書名で公開されてい
   ますので、ぜひご一読いただき、コメントをいただければと思います。


◆6lo WG (IPv6 over Networks of Resource-constrained Nodes WG)

6lo WGでは、省電力で低電力な軽量端末が接続されるIPv6ネットワークの技
術について議論をしています。

IoTという言葉の盛り上がりも見られる中、粛々と軽量クライアントのための
近隣探索や、おサイフケータイなどでも使われているNFC上のIPv6パケットの
転送技術などが話し合われています。こちらでも、RFC7217ベースのインタ
フェースIDの利用に関する議論がされました。

"IPv6 mapping to non-IP protocols"については、6man WGのチェアとも相談
するようにという指示が出ていました。

◆Homenet WG (Home Networking WG)

Homenet WGでは、最近の多種多様なデバイスとそれが属する多様な通信網を
念頭においた家庭内ネットワークの接続手法や、管理手法が議論されていま
す。

   1. Routing
   2. Addressing / Configuration
   3. Naming
   4. Service Discovery
   5. Security / Border Discovery

のカテゴリが提示されており、これに従って議論が開始されましたが、最初
のルーティングに関する議論だけでほぼ一つのセッション枠を使い切ってし
まう事態になり、急遽空いている部屋を探して、別の日にも議論がされまし
た。家庭内のデバイス管理のために、.homeというTLDを使う提案などもされ
ていました。

IPv6のプロトコルを基盤とした次の展開に向けた議論が多数行われているこ
とを、あらためて感じたIETF91のオンサイトミーティングでした。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1263/77755ddf8f2d76d00a40bf9782f5a0e9┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1263/cac3cfc5ed349224882b6e94d01f53c2┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
 JPNIC News & Views vol.1263 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先  jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■     News & ViewsはRSS経由でも配信しています！    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  https://www.nic.ad.jp/
■■

Copyright(C), 2014 Japan Network Information Center
このページを評価してください
