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

2016年4月上旬に、アルゼンチンで開催された第95回IETFミーティングの様子
を、vol.1398より連載でお届けしています。GWを挟んで連載第3弾となる本号
では、IPv6関連WGの動向をご紹介します。

なお、これまでに発行した、全体会議およびセキュリティ関連の報告記事に
ついては、下記のURLからバックナンバーをご覧ください。

  □第95回IETF報告

    ○[第1弾] 全体会議報告 (vol.1398)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1398.html
    ○[第2弾] セキュリティおよび暗号技術に関する動向 (vol.1399)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1399.html

またこの第95回IETFミーティングについては、オンサイトでの報告会も明日
5月10日(火)に開催します。本日の17時まで参加申し込みを受け付けておりま
すので、こちらもぜひご参加ください。

    IETF報告会(95thブエノスアイレス)開催のご案内
    https://www.nic.ad.jp/ja/topics/2016/20160421-01.html

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

2016年4月3日(日)～8日(金)にアルゼンチンのブエノスアイレスにて、第95回
IETFが開催されました。筆者が会合に参加したIPv6に関連するWorking Group
(WG)の中から、6man WG、v6ops WG、sunset4 WGについて、主な議論の概要を
報告いたします。

なお、今回v6ops WGは4日(月)と5日(火)の2セッションある予定でしたが、1
セッション目ですべてのアジェンダを消化したため、火曜日のセッションは
キャンセルとなりました。


◆ 6man WG (IPv6 Maintenance, Int Area)

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

最初にチェアから、インターネットエリアのエリアディレクターであった
Brian Haberman氏の引退について、感謝が述べられました。氏は、2003年か
ら(当時の)IPv6 WGおよび後継の6man WGのチェアの1人を務め、2012年にエリ
アディレクターに就任しました。後任は、Ericsson社のSuresh Krishnan氏が
務めます。

1. 最新RFC

前回のIETF 94横浜から今回までの間に、二つの文書がRFC化されました。

 * RFC7721: Security and Privacy Considerations for IPv6 Address
   Generation Mechanisms (IPv6アドレス自動生成メカニズムに関するセキュ
   リティ・プライバシー上の考慮事項)

 * RFC7739: Security Implications of Predictable Fragment
   Identification Values (予測可能なフラグメント識別値に関するセキュ
   リティ上の示唆)

前者は、IPv6アドレスのインタフェース識別子(IID)の生成メカニズムについ
て、セキュリティ上の懸念事項を調査したInformational RFCです。後者は、
IPv6パケットのFragment Header内の、Identification Fieldの予測可能性に
ついて調査したInformational RFCです。

IPv4において、Fragment ID (IP ID)を利用したポートスキャンが可能なこと
が知られており、IPv6でもIdentification Fieldの予測ができると同様の攻
撃が可能です。ただし、IPv6においてはフラグメント発生時にしか
Identification Fieldを持たないため、より複雑な手法が必要だと分析され
ています。

2. IPv6 Hop-by-Hop Options Extension Header (IPv6ホップバイホップオプ
   ション拡張ヘッダ)

IPv6拡張ヘッダの内、ホップバイホップ(HBH)オプションで運ばれる情報は、
パケットが通るパス上の、すべてのルータで処理されなければならないとさ
れています(RFC2460)(*1)。しかし、現実世界でのIPv6拡張ヘッダを持つパ
ケットの、破棄状況の観測(I-D.ietf-v6ops-ipv6-ehs-in-real-world)(*2)に
よると、(測定結果の解釈によりますが)インターネット上の事業者の40%ほど
がHBHオプションヘッダを含むパケットを廃棄しており、残りは転送はするが
無視している状況と考えられています。

発表では、その理由はHBHの処理がコントロールプレーンに渡されるため、脆
弱性になり得るとネットワークオペレータが理解しているからと考察されて
います。6manのMLではそのような状況を受けて、「HBH廃止？」というタイト
ルで活発に議論されています。しかしドラフトでは、HBHの処理をすべての
ルータに必須とするのではなく、同意しているルータだけ処理をすればよい、
そうすればHBHオプションを使う新しいサービスをインターネット上で使える
余地が生まれる、と提案しています。

会場では、このアプローチに対しては賛成する人が多く、HBH利用同意を可能
とするパケットフォーマットと、ルータでの実装方法について、具体的に議
論されました。もしこの提案が採用された場合には、RFC2460に対して、「中
継するルータはコンフィグされたHBHオプションだけ処理すること」という変
更が加わることになります。

(*1) https://www.ietf.org/rfc/rfc2460.txt
(*2) https: //tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world-02

3. IPv6仕様のインターネット標準(Internet Standard)化

IPv6のコアとなる仕様を定めるRFCを、インターネット標準(Internet
Standard)にすることをゴールとする提案です。

従来、IPv6の仕様はドラフト標準(Draft Standard)のカテゴリに分類されて
いましたが、RFC6410(*3)によってこのカテゴリ自体が廃止されました。その
ため、IPv6仕様がより技術的に成熟したものと示す、すなわちインターネッ
ト標準となる基準を満たしていることを確認し、足りないものがあれば修正
するという作業です。より詳しい背景については、第94回IETFのIPv6関連WG
報告(*4)をご参照ください。

(*3) https://www.ietf.org/rfc/rfc6410.txt
(*4) https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1367.html

対象となるIPv6のコアとなる仕様は、以下の六つのRFCです。

 1. RFC2460: Internet Protocol, Version 6(IPv6) Specification (イン
             ターネットプロトコルバージョン6 (IPv6)の仕様)
 2. RFC4291: IP Version 6 Addressing Architecture (IPv6アドレス体系)
 3. RFC1981: Path MTU Discovery for IP version 6 (IPv6用経路MTU探索)
 4. RFC3596: DNS Extensions to Support IP Version 6 (IPv6をサポートす
             るためのDNS拡張)
 5. RFC4941: Privacy Extensions for Stateless Address
             Autoconfiguration in IPv6 (IPv6ステートレスアドレス自動
             設定(SLAAC)のプライバシー拡張)
 6. RFC4443: Internet Control Message Protocol (ICMPv6) for the
             Internet Protocol Version 6 (IPv6) Specification (IPv6仕
             様のためのインターネットコントロールメッセージプロトコル
             (ICMPv6))

タイトルを見ればわかるかもしれませんが、1番目のRFCはIPv6の一番基本と
なる仕様、2番目のRFCはIPv6のアドレッシングについての仕様、3番目のRFC
はPath MTU Discoveryの仕様について定めたものです。この三つのRFCについ
ては、他のRFCによって更新(Update)や訂正(Errata)がされていたり、実装上
の曖昧な記述が残っており、そのままではインターネット標準となる基準を
満たしていません。そのため、それぞれRFC2460bis、RFC4291bis、RFC1981bis
という名称で、それらを修正する形で文書に変更が加えられます。

4番目のRFCはIPv6をサポートするためのDNS拡張の仕様、5番目のRFCはSLAAC
(StateLess Address AutoConfiguration)利用時のインタフェース識別子(IID)
を一時的なものにするための拡張の仕様、6番目のRFCはICMPv6の仕様につい
て定めたものです。

後半の三つのRFCについては、文書の変更はなくそのままIESG (Internet
Engineering Steering Group)のプロセスに回され、インターネット標準とな
る見込みです。

しかし会場では、特に拡張ヘッダの扱いやHBHヘッダに関する記述
(RFC2460bis)などについて、曖昧さが残るとして議論が白熱し、ML上で継続
議論となっています。この六つのRFCが揃ってインターネット標準となった際
には、新たにIPv6の仕様として読み直す必要が出てくるでしょう。この作業
が終わった後には、Informational RFCですが、RFC6343: IPv6 Node
Requirementsを更新してはどうかと提案がなされ、著者募集中の状況となっ
ています。


◆ v6ops WG(IPv6 Operations, Ops Area)

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

今回の発表は3件のみと少なかったですが、その中から6man WGと関連するIPv6
拡張ヘッダの議論と、LACNIC地域のIPv6ディプロイ状況についての発表を紹
介します。

1. Operational Implications of IPv6 Packets with Extension Headers
   (拡張ヘッダを持つIPv6パケットに関する運用上の示唆)

先ほど紹介した、IPv6拡張ヘッダを持つパケットの破棄状況の観測を受けて、
同じ著者が、それらのパケットが破棄される運用上やセキュリティ上での理
由を解明しようと試みたドラフトです。

IPv6拡張ヘッダを持つパケットが破棄される理由として、IPv6拡張ヘッダの
チェーンが長く続くとルータのハードウェア処理の限界となってしまうこと、
そのためソフトウェア処理となってルータに負荷を与えてしまうこと、など
が挙げられています。

著者は同じ内容をNANOGやRIPEなどで話しているため、オペレータからの
フィードバックも十分に受けており、説得力のある内容となっています。会
場でも、多くの参加者に好意的に受け止められました。

著者は、アクションプランとして以下の3点を提起しています。

 1. IPv6拡張ヘッダをフィルタリングする粒度を高める実装を要求する
 2. フィルタリング方法についてアドバイスを広める
 3. IPv6拡張ヘッダのチェーンの上限数について考える

1、2点目については賛成の意見が多かったのですが、3点目について、ルータ
のアーキテクチャやハードウェアの制約についての議論は、ここですべきで
はないという意見や、IPv6拡張ヘッダの将来の利用について制限を与えてし
まうのではないか、という危惧の意見がありました。

意外なことにチェアのFred Baker氏は、このドキュメントはWGドラフトとす
るまでの合意が得られていないと表明しました。会場からの反対意見もあり
ましたが、先ほど述べたように、6man WGではIPv6拡張ヘッダの問題を解決す
るためにプロトコル仕様を策定している一方、v6ops WGではそのプロトコル
をフィルタする(壊そうとしている、という過激な意見もありました)ことを
推奨しているという矛盾した状態であるので、これを解決しなければいけな
いのも事実です。チェアは、IPv6拡張ヘッダのチェーンの上限数を決めるべ
きではないと言い含めた上で、MLで継続議論としました。

2. IPv6 deployment in LAC: successful and not so successful stories
   (ラテンアメリカおよびカリブ地域のIPv6展開: 成功とそれほど成功しな
   かった事例)

LACNICが、ラテンアメリカおよびカリブ地域の、IPv6ディプロイ状況を調査
した結果について発表しました。興味深いことに、調査はBanco CAFというラ
テンアメリカ地域の政策投資銀行から、ファンドを受けて行われたとのこと
です。

調査には、ICAv6 (Indicador Clave de Avance IPv6/Key IPv6 Deployment
Progress Indicator)という独自指標が用いられました。Cisco社が出してい
るIPv6ディプロイの指標と比べ、プランニング部分に重きを置いているとの
ことで、他の地域と比べてLACNIC地域ではIPv6ディプロイがまだ途上であり、
多くの国でプランニングフェーズであるということがわかります。

発表では、成功しているモデル国としてボリビア、ペルー、エクアドル、ブ
ラジルの事例が紹介されました。IPv6 capableなユーザーの比率は、これら
の4ヶ国中の最小で3.7%(ボリビア)、最大で16%(ペルー)であり、いずれの国
も堅調に増えています。IPv4の在庫枯渇状況は国ごとに大きく異なるとのこ
とで、ペルーのTelefonica社では2008年の時点ですでに枯渇状態だったよう
です。

IPv6移行モデルは、すべてIPv6-Native + IPv4-CGN/NAT444とのことで、
MAP/DS-lite/464XLATなどのIPv4 over IPv6技術を採用している/しようとし
ている事業者がいない、というのも興味深い結果でした。


◆ sunset4 WG (Sunsetting IPv4, Int Area)

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

普段はMLの流量が少なく、ミーティングが開催されないこともあるsunset4
WGですが、今回はTime Warner Cable社のLee Howard氏が提出した"IPv4
Declared Historic (IPv4の歴史的宣言)" というドラフトについて、実に1時
間半も議論されました。

このドラフトは500ワード程度しかなく、一言でまとめるならば「IPv4
(RFC791)は"Historic"(歴史的)だ」ということです。IETFにおける
"Historic"の定義は「他のプロトコルに置き換えられていること」とRFC2026
に書かれており、それに従えば、IPv4はIPv6に置き換えられているため
Historicということになります。確かにHistoricの定義に当てはまるし、い
つかはそうなるだろうという賛成意見もありましたが、

 - IPv6移行技術はどうなるのか。Historicとすることで技術の発展を阻害し
   てしまうかもしれない
 - プライベートアドレスは枯渇しないし企業は使い続ける
 - IETFは世間とずれていると言われるかもしれない

といった慎重な意見も多く見られました。全体として時期尚早といった感で
すが、デュアルスタックをずっと続けるのは辛い、というのも実感としてあ
るようです。

技術というよりはメタな議論が多く、会場やJabberルームでの議論が盛り上
がりましたが、結論はなくMLで継続議論となっています。

最後に会場では、NAT64やIPv6オンリーのWi-Fiに繋げている人がどのくらい
いるのかという挙手が行われましたが、ほとんどおらず、「IETFでもdefault
networksはIPv6-onlyではないのに、全世界ではどうなのか」といったコメン
トが笑いをとっていました。これに関しては、IPv6オンリーかつNAT64+DNS64
の環境をデフォルトで提供した、日本での先行事例であるCEDEC (Computer
Entertainment Developers Conference)(*5)が参考になると思います。

(*5) http://www.janog.gr.jp/meeting/janog37/program/cedec


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

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

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