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

2015年7月下旬にチェコ共和国のプラハで開催された、第93回IETFミーティン
グのレポートをvol.1333より連載でお届けしています。最終回の本号では、
IPv6関連WG報告として、6man、v6ops、sunset4の各WGの動向をご紹介します。

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

  □第93回IETF報告
    ○[第1弾] 全体会議報告 (vol.1333)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1333.html
    ○[第2弾] セキュリティ関連報告 (vol.1334)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1334.html

この第93回IETFについては、オンサイトでの報告会も来週8月27日(木)に開催
予定です。8月26日(水)の17時まで参加申し込みを受け付けておりますので、
ぜひご参加ください。

  □IETF報告会(93rdプラハ)プログラムのご案内
    https://www.nic.ad.jp/ja/topics/2015/20150818-02.html

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

2015年7月19日～24日にチェコのプラハにて、IETF 93が開催されました。筆
者が会合に参加したIPv6に関連するWorking Group (WG)の中から6man WG、
v6ops WG、sunset4 WGについて、主な議論の概要を報告いたします。なお、
今回はv6ops WGとsunset4 WGは合同でミーティングが開催されました。

◆6man WG (IPv6 Maintenance, Int Area)

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

最初にチェアから、前回のIETF 92(ダラス)から継続議論となっている、無線
環境などのようなパケットロスが多い環境における重複検出(DAD: Duplicate
Address Detection)の改善について、ML上でより活発に議論をして欲しいと
の呼びかけがありました。こちらについては継続的にウォッチしているため、
これまでの報告にも目を通していただければ幸いです。

  vol.1263 (IETF 91)
  https://www.nic.ad.jp/ja/mailmagazine/backnumber/2014/vol1263.html

  vol.1301 (IETF 92)
  https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1301.html

本稿では、ドラフト無しで提起された二つの議題について、取り上げて紹介
します。

1. Source Address Dependent Routing for IPv6 hosts analysis

IPv6アドレスを持つホストのソースアドレスに依存したルーティング(SADR:
source address dependent routing)について、6man WGとして取り組むべき
かどうか、という問題が、Brian Carpenter氏から提起されました。複数の
IPv6グローバルアドレス(GUA: Global Unicast Address)を持つホストにおい
て適切なGUAを選択しないと(あるいはルーティングによって適切な出口を選
択しないと)、上流のネットワークにおいてBCP38(送信元アドレスの検証:
Source Address Validation)が行われている場合、正しく通信ができないと
いう問題があります。この問題が既存のメカニズムによって解決されている
のであれば、特に新しいアクションは必要ないですが、もし未解決問題があ
るとすれば、6man WGで扱いたい、という趣旨です。

日本においては、ISPとNGNにおけるマルチプリフィクス問題と似た設定であ
ると考えることが可能であり、ソースアドレスの選択については、RFC6724の
Rule5.5が適応されていれば問題がないことが議論で指摘されました。しか
し、ISPに接続する前にルーティングドメインがあるHomenetのような状況で
は、ソースアドレスの選択だけでなく、ソースアドレスに依存したルーティ
ングが必要となることから、Homenet WG のメンバーからは、このドラフトを
支援することが表明されました。WGとしてこのドラフトを扱うことに強い同
意(Hum)が示されましたが、発表者が提案する解決方法については明確な同意
は得られず、他の解決策を模索する、として議論が終わりました。


2. IPv6 specifications to Internet Standard

チェアから、IPv6関連の仕様を記載した一連のRFCのカテゴリーをINTERNET
STANDARD(*1)としたい、という提起がされました。しかしこれは、RFCの複雑
に絡んだ系譜を解きほぐす、非常に手間のかかる作業となりそうです。DRAFT
STANDARDとなっているIPv6関連のRFCは、RFC2460 (Internet Protocol,
Version 6 (IPv6) Specification)やRFC4291 (IP Version 6 Addressing
Architecture)をはじめとして少なくとも九つ以上あり、さらにRFC2460だけ
でも、九つ以上のドキュメントによってアップデートされています。INTERNET
STANDARDになるためには、Errataが存在しないことや使われていない複雑な
仕様がないことなど厳しい条件があり、RFC2460をアップデートしているRFC
がすべてINTERNET STANDARDの基準を満たすとは限りません。

短期的にはRFC2460を改定するRFC2460bisを作成してINTERNET STANDARDとす
ることを目的とし、その後にその他のRFCに拡張していく方針となりました
が、標準文書を増やすことで市場に混乱を与えないように、明確な文書とな
ることを心がけるべき、などの意見が出ました。

(*1) RFCのカテゴリーは、従来のINTERNET STANDARD、DRAFT STANDARD、
     PROPOSED STANDARDの三つのレベルに分かれていたものが、RFC6410に
     よって、INTERNET STANDARDとPROPOSED STANDARDの二つに集約されてい
     ます。

今回は上記以外に九つの個人ドラフトの発表が用意されていましたが、時間
切れにより最初の四つのドラフトしか議論ができませんでした。発表されな
かったドラフトの中には、Google社のLorenzo Collitti氏による「ルータ広
告(RA)による電力消費計測(RA power measurements)」というものがあり、非
常に残念でした。次回のIETF 94横浜で発表があるかもしれないので注目して
います。


◆ v6ops WG (IPv6 Operations, Ops Area) & sunset4 WG (Sunsetting IPv4,
   Int Area)合同ミーティング

v6ops WGは、IPv6を全世界に展開するにあたっての緊急の課題、特に運用上
の課題に対処することに焦点を当てたWGです。また、新しいネットワークや
既存のIPv4ネットワークにIPv6を導入するためのガイドラインや、IPv4/IPv6
共存ネットワークの運用ガイドラインを作成することも目的としています。
sunset4 WGは、IPv6への完全な移行に向けて、アプリケーション・ホスト・
ネットワークがIPv4への依存無しに機能することを目指すWGです。他のWGに
対して、プロトコルの策定に際してIPv4に依存しないよう働きかけを行うこ
とも目標にしています。

今回合同でミーティングが行われた理由には、sunset4 WGの活動が活発では
ないということと、両者の取り扱う領域が一部重複しているため、v6ops WG
のCharterを更新するにあたって対象領域を整理したいということが挙げられ
ます。合同ミーティングは7月21日と24日の2回にわたって行われました。

1. v6ops WGの Charter更新について

最初にv6ops WGのCharter更新について報告します。議論の主なポイントは以
下の三つでした。

 - "IPv4/IPv6のインターネットの運用上の問題について解決策を決めるため
   に、オペレーターやユーザーからの情報提供を要請する"という元の文章
   に対し、対象をIPv6インターネットだけに限定するか否か？

 - 運用による解決策をInformational RFCまたはBCP RFCとしてまとめること
   をv6ops WGの仕事とするか？

 - IPv6オンリーのネットワークを展開するための運用上のロードマップをま
   とめることをv6ops WGの仕事とするか？

1点目に関して、IPv6だけに限定すべきという意見もありましたが、現在は両
方を残す案がチェアから提起されています。

2点目に関して、IPv6だけあるいは、IPv6/IPv4デュアルスタックの課題解決
策を考えることには賛成が多かったのですが、IPv4だけのトピックに関しては
スコープ外ということが確認されました。しかし、これを厳格にしてしまう
と、v6ops WGとsunset4 WGのどちらのWGでも拾えない領域が生まれてしまう
恐れがあるという意見もあり、オペレーターの便宜のためにデフォルトの受
け皿が必要だ、との意見もありました。

3点目に関して、これをv6ops WGの仕事とすると、必然的にデュアルスタック
からIPv6オンリーに移行する方法を検討することになるので、sunset4 WGの
範囲と重複してしまいます。sunset4 WGが休眠状態(dormant)になってしまう
と、IPv4を止めるときの諸課題に対処する議論をする場がなくなってしまう
ので、v6ops WGで引き取るべきだという意見と、今回のような合同ミーティ
ングを続けてはどうかという意見がありましたが、チェアが改訂案を提起し
て継続議論という結論となりました。


2. IPv6 and Appleについて

次に、Apple社のStuart Cheshire氏が発表した、"IPv6 and Apple"について
紹介します。

発表では、iOSとOS XなどほとんどのApple製品についてIPv6がサポートされ
ていることを紹介したあと、すべてのiOSのアプリケーションは、IPv6ネイ
ティブサポートとNAT64ネットワークで動作しなければならない(MUST)という
メッセージが打ち出されました。今年中にはアプリケーションを登録する上
での要求条件になる、とも伝えています。Verizon社、AT&T社、T-Mobile社な
どのキャリアでIPv6対応が進み、CGN越しにIPv4通信をするよりもIPv6で通信
をするインセンティブがあるため、新しいiOSとOS Xでは99%がIPv6通信にな
る挙動をするとのことです。

なぜNAT64なのか、ということで464XLATとNAT64/DNS64を比較していました
が、464XLATでは、IPv4のみのクライアントはIPv4サーバとしか通信ができな
いが、NAT64/DNS64では、IPv6のみのクライアントはIPv6/IPv4サーバ両方と
通信できることから、後者が良いと主張しました。それに関して、「DNSSEC
のvalidationの点でDNS64を用いない464XLATの方が良い」「IPv4リテラルへ
の対応はどうするのか」「464XLATでもクライアントはIPv6を持っていること
が仮定されているので変わらないのでは」などの意見が出ました。けれども、
今回のApple社の方向性が、開発者にIPv6でのアプリ開発を促すものになるの
で、支持する声が大きかったです。

発表では、開発者に向け、OS X 10.11 (El Capitan)のInternet Sharing機能
を用いて、NAT64/DNS64テストネットワークを作成し、モバイル端末のテスト
をする方法が紹介されました。テスト用のNAT64配下のIPv6ネットワークにつ
いては、Benchmark WGがRFC5180にて確保しているテスト用のアドレス帯
(2001:2::/48)から、2001:2:0:aab1/64が使われるだろうと、MLで議論されて
います。

99%がIPv6通信になるというiOS 9とOS X 10.11 (El Capitan)のHappy
Eyeballsの新しい実装(β版)については、"Apple and IPv6 - Happy
Eyeballs"という件名でv6ops MLに投稿されたメールで詳しく説明されていま
す。このHappy Eyeballsとは、IPv6/IPv4デュアルスタック環境において、
IPv6とIPv4の両方のプロトコルを用いて同時に接続を行い、先に成功した方
の結果を用いて、フォールバック問題を緩和する方法で、RFC6555にて標準化
されています。

拙訳を紹介します。
----------
 アップデートされた実装は、以下のように振る舞います。
    1. DNSリゾルバにAクエリとAAAAクエリを出します
       - もしDNSレコードがキャッシュに無い場合、リクエストはワイヤ上
         で連続して送信されます(AAAAが先)
  2-1. もし最初の応答がAAAAだった場合、IPv6のSYNを直ちに送ります
  2-2. もし最初の応答がAだった場合、AAAAを期待して、25msのタイマーを
       開始します
       - もしタイマーが切れたら、IPv4のSYNを送ります
       - もし25ms以内にAAAAを受け取ったら、アドレス選択に進みます
    3. IPアドレスのリストがある場合(DNSキャッシュからの場合か、IPv4と
       IPv6を近接して受け取った場合)、それらのソートのために、アドレ
       ス選択アルゴリズムを実施します。このアルゴリズムは、過去のRTT
       値のデータを用いて遅延の少ないアドレスを優先しますが、25msのゆ
       とりを持ちます。もし、過去のRTT値の差が25ms以内だった場合、
       RFC3484を使ってベストなアドレスを選択します
    4. リストがソートされたら、リストの1番目のアドレスにSYNを送りま
       す。また同時に、過去のTCPのRTT値の平均と分散をベースとしたタイ
       マーを開始します。大雑把に言えば、1番目のSYNの再送信と同じくら
       いの時間に2番目のアドレスのSYNを送ります
    5. 1番目のアドレスのSYN-ACK応答が競争に勝ったら、他のTCP接続の試
       みをキャンセルします
----------

こちらの挙動は、β版なので詳細は変更される可能性はありますが、将来の
アップル製品のIPv6トラフィックを飛躍的に増加させるものとして、成功が
期待されています。


3. OTEにおけるIPv6展開について

IPv4 as a Serviceプロジェクトの一環として、ギリシャのISPであるOTE
(Organismos Tilepikinonion Ellados)におけるIPv4 over IPv6サービス事例
が共有されました。Meetechoというツールを使って、ギリシャから遠隔で発
表するスタイルで行われました。今回のギリシャの事例では、Statelessであ
ることからMAPを当初検討していたが、シンプルなプロビジョニングを実現で
きることから、最終的にはLightweight 4 over 6を採用したことが説明され
ました。


4. ホストアドレスに複数のアドレスを利用することの推奨について

Google社の Lorenzo Colitti氏とVint Cerf氏、Apple社のStuart Cheshire氏
が筆者ということで、非常に注目を集めているドラフトです。MLに投稿され
た直後から、今でもずっと議論が続いています。

IPv6とIPv4の大きな違いは、ホストで複数のアドレスを持てることです。そ
のことがきちんと理解されていないということが、ドラフトを書いたモチベー
ションだと説明されました。複数のアドレスを持つことのメリットとして、
以下の利用方法が挙げられました。

 - IPv6プライバシーアドレス
 - ホスト内の複数のVirtual Machineやプロセッサへのアドレス付与
 - テザリング
 - IPv4 over IPv6技術
 - その他、将来のアプリケーション

これらの技術は、複数アドレスの恩恵を受けることができます。上記の一部
はNAT66によっても解決することができますが、NAT越えの問題やNATのキープ
アライブの問題(QUICは15秒間隔でキープアライブを実施)があるため、NAT66
は望ましくないとしています。

これらの主張に対して、内容をサポートする意見が多かったです。しかし、
ドラフトの内容はまだ問題を明確に記述することができていないため、それ
を確認するための質問が続きましたが、時間の関係で議論が途中で切り上げ
られてしまいました。ただ、WGドラフトとして扱うかどうかには同意(Hum)
が圧倒的に多かったため、今後はWGドラフトとなる可能性が非常に高いで
す。v6ops MLで盛り上がっている議論を、今後も注意深く追っていく必要が
あります。

その他、sunset4 WGとして二つ発表がありましたが、いずれも議論が活発で
ないために、継続してレビューを求む、となっています。また、v6ops WGと
して他に五つの発表がありました。その中で、前回の報告で紹介したSIIT-DC:
Stateless IP/ICMP Translation for IPv6 Data Centre Environments
(v6ops-siit-dc)と、SIIT-DC: Dual Translation Mode (siit-dc-2xlat)につ
いては、ドキュメントを整理した上で再提出された内容がよく精査されてい
たことから、WGラストコール(WGLC)を迎える予定となっています。また、
Sending Solicited RAs Unicast (v6ops-solicited-ra-unicast)については、
RAのマルチキャストがモバイルネットワークにおいて非効率である問題の解
決策について引き続き議論が行われましたが、WGドラフトとすることの同意
(Hum)が得られ、次からはWGドラフトとして再提出される予定です。


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

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1335/93aa6199f8cd991b19fb5881b2782303┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1335/05df31bcfb7cafab59b577fa3b69916e┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
╋■╋■━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                       https://blog.nic.ad.jp/
┏━┳━┳━┳━┳━┳━┳━┳━┳━┳━┳━┳━┳━┳━┳━┳━┳━┓
┃J ┃P ┃N ┃I ┃C ┃の┃B ┃L ┃O ┃G ┃は┃じ┃め┃ま┃し┃た┃!!┃
┗━┻━┻━┻━┻━┻━┻━┻━┻━┻━┻━┻━┻━┻━┻━┻━┻━┛
インターネットとJPNICを取り巻く状況についてカジュアルにお知らせします
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━■╋■╋
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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.1335 【臨時号】

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