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

2015年3月下旬に米国のダラスにて開催された、第92回IETFミーティングのレ
ポートをvol.1298より連載にてお届けしています。[第3弾]となる本号では、
IPv6関連WG報告として、6man、v6ops、sunset4の各WGの動向をご紹介します。

これまでに発行した、全体会議および暗号技術に関する動向のレポートにつ
いては、下記のURLからバックナンバーをご覧ください。また、連載の最終回
となる[第4弾]では、DNS関連WGの報告をお届けする予定です。

□第92回IETF報告 特集
  ○[第1弾] 全体会議報告 (vol.1298)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1298.html
  ○[第2弾] IETFにおける暗号技術に関する動向(楕円曲線) (vol.1299)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1299.html

なお、今週4月24日(金)にISOC-JPとJPNICの主催で、東京・田町にて「IETF報
告会(92ndダラス)」も開催いたします。

報告会では、本連載で取り上げるエリア以外にも、より幅広いエリアの報告
がなされます。実際にIETFに参加されている方々と直接お話しをするよい機
会でもありますので、ご興味のある方はぜひご参加ください。参加申し込み
は23日(木)の17時までとなっております。

□IETF報告会(92ndダラス)開催のご案内
  https://www.nic.ad.jp/ja/topics/2015/20150409-02.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第92回IETF報告 [第3弾] IPv6関連WG報告
   ～6man WG、v6ops WG、sunset4 WG～
                                NTTコミュニケーションズ株式会社 西塚要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2015年3月22日(日)～27日(金)に米国のダラスにて、第92回IETFが開催されま
した。筆者が会合に参加したIPv6に関連するWorking Group (WG)の中から、
v6man WG、v6ops WG、sunset4 WGについて、主な議論の概要を報告いたしま
す。


◆ 6man WG (IPv6 Maintenance, Int Area)

6man WGは、IPv6の仕様およびアーキテクチャのメンテナンスと、最新化を行
うWGです。IETFにおけるIPv6関連トピックの受け皿となり、IPv6の仕様拡張
や変更に関して、責任を持っています。6man WGから以下のRFCが発行された
ことが、チェアから報告されました。

RFC7421 - Analysis of the 64-bit Boundary in IPv6 Addressing
https://tools.ietf.org/rfc/rfc7421.txt

IPv6ユニキャストアドレスのインタフェース識別子(IID)が64-bitで固定され
ていることの利点および可変にしたときの影響について、調査結果をまとめ
たInformational RFCです。

今回は一つのワーキンググループドラフト、11の個人ドラフト(そのうち四つ
が新規ドラフト)が話し合われましたが、特に議論を集めた3項目について紹
介いたします。

(1) Validation of IPv6 Neighbor Discovery Options
   (draft-ietf-6man-nd-opt-validation)

2015年3月にワーキンググループドラフトとして提出されたもので、IPv6近隣
探索(ND)におけるNDメッセージのオプション情報の評価について、推奨のルー
ルを決めています。Source Link-Layer Address (SLLA)オプションとTarget
Link-Layer Address (TLLA)オプションについて、オプション内のリンクレイ
ヤアドレスに、ブロードキャストアドレス・マルチキャストアドレスまたは
受信ノードのリンクレイヤアドレスが指定されている場合は、このオプショ
ンを無視しないと、パケットの転送を反復させる攻撃が可能となってしまい
ます。それ以外のオプションについての記述は、既存の文書(RFC4861、
RFC2464)と大きな変更が無いので、この二つのオプションの記述のみに絞る
べきかどうかが議論されています。

(2) A survey of issues related to IPv6 Duplicate Address Detection
   (draft-yourtchenko-6man-dad-issues, draft-nordmark-6man-dad-approaches)

前回の第91回IETF報告(*1)でも取り上げられた、近隣探索プロトコルの無線
環境における問題についての議論の一環です。重複検出(DAD)について、問題
点と解決に向けたアプローチが、それぞれまとめられています。「アドレス
重複が起こる確率は低いので、配慮する必要は無いのでは」という意見があ
る一方、「実際にアドレス重複が起きたらトラブルシュートするのは時間が
かかるので、解決手段を得るためには必要だ」という意見もありました。
こちらは多くの関心を集めており、引き続き議論されていく予定です。

(*1) https://www.nic.ad.jp/ja/mailmagazine/backnumber/2014/vol1263.html

(3) IPv6 Neighbor Discovery Optional Unicast RS/RA Refresh

こちらも近隣探索プロトコル(ND)に関連し、定期的なマルチキャストのルー
タ要請(RA)は無線環境には適さないことから、ユニキャストでルータ探索(RS)
を更新できるように、RSメッセージにR-flagを追加しようという提案です。
また、RAメッセージにオプションを追加して、ルータ側から更新時間を通知
できるようにします。この提案は「IPv6のRFC全体に影響を与えることから、
問題の解決策としてはよいアプローチではない」という意見が大勢を占めま
した。


◆ v6ops WG (IPv6 Operations, Ops Area)

v6ops WGは、IPv6を全世界に展開するにあたっての緊急の課題、特に運用上
の課題に対処することに焦点を当てたWGです。また、新しいネットワークや
既存のIPv4ネットワークにIPv6を導入するためのガイドラインや、IPv4/IPv6
共存ネットワークの運用ガイドラインを作成することも目的としています。

今回のv6ops WGでは、"IPv4 as a service"と呼ぶ、新しいプロジェクトを始
める提案がチェアからなされました。IPv6のネットワーク上において、IPv4
を必要なサービスとして提供する(ただし、徐々に減らしていく)というシナ
リオを前提として、IPv4 over IPv6技術の展開における運用ガイダンスを書
くというプロジェクトです。対象とする技術は、現在、以下の九つです。

  (1) 464XLAT (RFC 6877)
  (2) SIIT-DC (draft-anderson-v6ops-siit-eam,
      draft-ietf-v6ops-siit-dc, draft-ietf-v6ops-siit-dc-2xlat)
  (3) MAP-E encapsulation (draft-ietf-softwire-map)
  (4) MAP-T translation (draft-ietf-softwire-map-t)
  (5) RFC6145 translation (stateless translation to an IPv4-embedded
      IPv6 Address)
  (6) RFC6146 translation (stateful translation IPv6 clients->IPv4
      servers)
  (7) DS-LITE (RFC 6333)
  (8) Lightweight 4over6 (draft-ietf-softwire-lw4over6)
  (9) LISP (4 over 6, various RFCs and drafts)

これらの技術に関する経験の集約には、オペレーターからの意見が重要なの
で、各地のNOG (Network Operators Group)と連携しながら進めていきたいと
表明されました。これらの技術の利用が既に始まっている日本から、多くの
貢献ができるのではないかと筆者は考えています。

この提案に関連する形で、日本でのMAP-Eの利用状況について、日本ネット
ワークイネイブラー株式会社(JPNE)の中川あきら氏が発表を行いました。中
川氏の発表では、日本におけるIPv6普及状況とIPv6トラフィックが増加して
いること、JPNEがMAP-Eを選択した理由と現状で特に大きな問題が発生してい
ないことが報告されました。

JPNEがMAP-Eを選択した理由としては、「ステートレスであるためログ収集が
不要で運用が楽なこと」「カスタマサポートが容易なこと」「エンド-エンド
で通信が可能であること」が挙げられていました。

また、「速度測定結果ではIPv6通信とIPv4通信が同程度であること」「ポー
ト利用状況の統計データからユーザーに十分な数のポートが割り当てられて
いること」「接続判定ページが提供されており、トラブルシュートが容易に
なっていること」などの実用的な情報提供がされました。

会場の参加者は非常に興味を持っており、スライドの内容について詳しく知
りたいという内容の質問が相次ぎました。また、日本のIPv6の普及状況につ
いて、日本のコンテンツプロバイダに対してIPv6でのサービスを促してはど
うか、という突っ込んだ内容の発言もありました。

インドからは、MAP-Tのトライアルについての発表がありました。発表の構成
は中川氏とほぼ同様でしたが、MAP-TとMAP-Eを比較して、「MAP-TはQoS/SLA
など顧客単位のポリシー適合が容易であること」「DPI装置の利用が容易であ
ること」などが挙げられ、国が異なれば選択される技術が異なることが、興
味深かったです。

また、中国からは、CERNETとChina Telecom社における、MAP-TとMAP-Eの同時
提供のトライアルについての発表がありました。同一のBR (Border Relay)と
CPE (Customer Premises Equipment)で、MAP-TモードとMAP-Eモードを自動的
に変更できるという、非常にユニークな構成となっています。MAPによるアド
レス共有比率について実際のユーザーで試した結果、「1/256(1ユーザーあた
り255 port) はOK」「1/512(1ユーザーあたり127 port) では、一部のユー
ザーに影響があったかもしれない」など、興味深いデータが提供されていま
した。

2日目のv6ops WGでは、2件のドラフトが、WGLC (Last Call)となることの同
意が得られました。

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

IPv6ネットワークをデザインするにあたり、ルーティングに関してどのよう
な選択肢があり、それぞれにどのようなメリット・デメリットがあるのかを、
網羅的に調査したドラフトです。リンクローカルアドレスしか付与されてい
ないインタフェースについて、"unnumbered"と呼ぶか"link-local-only"と呼
ぶか(あるいはそれ以外か)という議論に、白熱するという一幕もありました
が、ミーティングでは後者に落ち着き、WGLCをすべきかの採決が行われ、賛
成多数となりました。

- Close encounters of the ICMP type 2 kind (near misses with ICMPv6
  PTB)
  (draft-jaeggli-v6ops-pmtud-ecmp-problem)

前々回の第90回IETF報告(*2)でも取り上げた、「ロードバランサ環境下で、
ICMPv6type 2 "Packet Too Big" (PTB)メッセージ応答が元のサーバに返らな
い」問題です。こちらもWGLCをすべきかの採決が行われ、賛成多数となりま
した。

(*2) https://www.nic.ad.jp/ja/mailmagazine/backnumber/2014/vol1223.html

また、データセンター内ネットワークのIPv6化に関して、以下のような注目
すべき発表が行われました。

- SIIT-DC
  (draft-anderson-v6ops-siit-eam, draft-ietf-v6ops-siit-dc, draft-ietf-v6ops-siit-dc-2xlat)

"IPv4 as a service"プロジェクトでも取り上げられている、IPv6で構成され
たデータセンター内ネットワークにおいて、IPv4での接続性を提供する方法
に関する一連のドラフトです。

draft-anderson-v6ops-siit-eamは、RFC6145にて定義され、464XLATではCLAT
側で使われている、ステートレスなIPv4/IPv6変換(Stateless IP/ICMP
Translation(SIIT))のアドレスマッピングルールを、緩和することを提案す
るものです。元は、draft-ietf-v6ops-siit-dcに含まれていた内容でしたが、
単体で有用と見なされ、切り出されました。

RFC6145では、IPv6アドレス(64:ff9b::/96)の中にIPv4アドレスを埋め込むな
ど、RFC6052で定義されたマッピングルールしか認めていません。しかし、
464XLATで利用するにはこの制約は不都合であるため、任意のIPv6アドレスに
静的にマッピングする方法が求められています。事実、Androidの464XLAT実
装では、RFC6052のルールを既に使っていないというコメントが会場から出さ
れました。そのため、このドラフトはRFC6145をアップデートするものとし
て、ワーキンググループドラフトとして採用される予定です。

draft-ietf-v6ops-siit-dcとdraft-ietf-v6ops-siit-dc-2xlatは、共に前回
のIETF91にて、ワーキンググループドラフトに採用されています。例えるな
らば、データセンター側にステートフルNAT64または464XLATを提供し、IPv4
ネットワークからIPv6データセンター内の、IPv6/IPv4サーバに接続できるよ
うにする提案です。特に、464XLATに類似した手法を使った場合、データセン
ター内でIPv4のみのソフトウェアやデバイスをサポートできるようになりま
す。これらの二つのドラフトは、利用形態やレファレンスが多く重複するこ
とから、一つのドラフトとしてまとめられることとなりました。


◆ sunset4 WG (Sunsetting IPv4, Int Area)

sunset4 WGは、IPv6への完全な移行に向けて、アプリケーション・ホスト・
ネットワークが、IPv4への依存無しに機能することをめざすWGです。他のWG
に対して、プロトコルの策定に際してIPv4に依存しないよう、働きかけを行
うことも目標にしています。

前回のIETF91ではミーティング自体が開催されず、MLの流量も少ないため、
残念ながらあまり活発ではなくなってしまったWGです。なぜこちらのWGを取
り上げたかというと、"IPv4 as a service"プロジェクトについて、v6ops
WGとsunset4 WGのどちらが適切か、という議論があったためです。しかし、
両者のWGの違いはどこなのか、という議論にすり替わり発散してしまったた
め、特に決定事項はありませんでした。

ワーキンググループドラフトとして、IPv6移行の最終段階においてIPv4を実
際に無効化するときの難しさについて列挙した
draft-ietf-sunset4-gapanalysisが残っており、MLで引き続き議論をしてい
くことが確認されました。


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

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1301/49c08c58d68d2d522f33f3c95cfeceee┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1301/6d84f89fc5e35f65dae6833581653af1┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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.1301 【臨時号】

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