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

2014年7月20日(日)から25日(金)までカナダのトロントで開催された、第90回
IETFミーティングのレポートを連載していますが、第2弾として、「IPv6関連
WG」の報告をお送りします。執筆者の西塚要氏には、今回初めてIETFの動向
をご執筆いただき、IPv6関連WGのエッセンスをまとめていただきました。

なお、昨日発行の全体会議報告のバックナンバーは、以下のURLからご覧くだ
さい。以後、DNS関連WG、セキュリティ関連WGと、順次ご報告していきます。

□第90回IETF報告 特集
  ○[第1弾] 全体会議報告 (vol.1222)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2014/vol1222.html

また、8月25日(月)の13時半から、ISOC Japan ChapterとJPNICとの共催で、
恒例の「IETF報告会」を開催します。そこでは、このメールマガジンでは紹介
していないワーキンググループの模様も報告されますので、お時間のある方は
ぜひご参加ください。

□IETF報告会(90thトロント)開催のご案内
  https://www.nic.ad.jp/ja/topics/2014/20140808-01.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第90回IETF報告 [第2弾] IPv6関連WG報告
                                NTTコミュニケーションズ株式会社 西塚要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2014年7月20日(日)～25日(金)にカナダのトロントにて開催された第90回IETF
のWorking Group (WG)のうち、筆者が会合に参加したIPv6に関連するWGの中
からv6ops WGとhomenet WGについて、主な議論の概要をご紹介したいと思い
ます。なお、今回のIETFでは、6man WG (IPv6 Maintenance WG)は開催されま
せんでした。

◆ v6ops WG (IPv6 Operations WG)

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

今回のv6ops WGでは、2014年7月17日(木)～18日(金)に香川県高松市で開催さ
れた、JANOG34で行われたIPv6 ULA (Unique Local Address)に関する実験
(*1)の結果について、NTTコミュニケーションズ株式会社の小原泰弘氏が発表
を行いました。

IPv6 ULA (fc00::/7)は、IPv4におけるプライベートアドレス(*2)に相当する
アドレスです。ただし、下記2点のような違いがあり、IPv4におけるプライ
ベートアドレスと完全に一致しているわけではありません。

- IPv6では一つのIFがULA (Unique Local Address)とGUA (Global Unicast
  Address)の両方のアドレスを持てる点

- ランダムに生成することが推奨されている40bitのフィールドをprefixに含
  んでいることから、実質上はグローバルにユニークであることが期待され
  ている点

当初、IPv6におけるプライベートネットワーク用としては site-local
addresses (fec0::/10)が予約されていましたが、定義が曖昧だったことから
非推奨となり、代わりにIPv6 ULAが、2005年にRFC4193 (*3)において定義さ
れました。

  (*1) http://www.janog.gr.jp/meeting/janog34/network/
  (*2) RFC1918 http://tools.ietf.org/rfc/rfc1918.txt
  (*3) RFC4193 http://tools.ietf.org/rfc/rfc4193.txt

IPv6 ULAの利用シーンとしてさまざまな構成が考えられるため、それぞれの
構成の利点と欠点を明確にするためのドラフト
(draft-ietf-v6ops-ula-usage-recommendations-02)が提出されており、
v6ops WGのメーリングリスト(ML)では、このドラフトについて現在も活発に
議論がされています。

JANOG34では、ドラフトに記載されている利用シーンのうち、以下の二つのシ
チュエーションを構築して実験を行いました。

- ULA along with GUA: IPv6 ULA + GUAで構成したネットワーク(IPv4アドレ
  スはあり)。IPv6サイトへはGUA(またはULA+NPTv6)、IPv4サイトへはNAT44
  で通信を行う。

- ULA-only Deployment: IPv6 ULAのみで構成したネットワーク(IPv4アドレ
  スは無し)。IPv6サイトへはNPTv6、IPv4サイトへはNAT64/DNS64で通信を行
  う。

前者のケースでは、さまざまなアプリケーションで通信にまったく問題が無
かったこと、ソースアドレスとしてULAを選択した通信が発生しなかったこと
(Neighbor DiscoveryとmDNS通信を除く)が報告されました。また、後者のケー
スでも、IPv4アドレスが無いと動作しないSkypeを除き、ほとんどのアプリ
ケーションで問題が無かったことが報告されました。

会場からは、実験内容の詳細について尋ねる質問が多かったですが、マイク
に立った質問者全員が、コメントの冒頭で、貴重な実験結果を共有したこと
に対しての感謝の意を述べていました。

今回の実験では、ほとんどの場合で通信に影響が無いという良好な結果でし
たが、アプリケーションに依存して、または、端末のソースアドレスセレク
ションのルールに依存して、通信への影響が発生することが想定されるため、
「次はもっとアプリケーションと端末のバリエーションを増やして実験をし
て欲しい」というコメントが、大勢を占めていました。

今回の発表は、JANOG34の会場ネットワークでULAに関する実験を発案した、
シスコシステムズ合同会社の土屋師子生氏が、v6ops WGのMLに実験内容につ
いて投稿したことがきっかけで実現しました。IETFでは現在、IETFの上位組
織であるISOC (Internet Society)におけるDeploy360 (*4)という取り組みの
中で、運用者の意見をプロトコルの標準化に積極的に取り込んでいこうとい
う試み「Operators And The IETF」(*5)を行っています。日本の運用者の意
見が集約されるJANOGから、IETFの場に意見をインプットしていくことは非常
に重要であり、今後も継続していくべきと感じました。

  (*4) http://www.internetsociety.org/deploy360/
  (*5) http://www.internetsociety.org/deploy360/projects/operators-and-the-ietf/

v6ops WGでは他にも、以下のような注目すべき発表が行われました。

  - DHCPv6/SLAAC Address Configuration Interaction Problem Statement
    (DHCPv6/SLAACアドレス構成対応問題に関するステートメント)
    (draft-ietf-v6ops-dhcpv6-slaac-problem)

  JPNICニュースレター56号(*6)で「DHCPv6/SLAACアドレス構成対応問題」と
  して取り上げられているので、詳細はこちらをご参照ください。今回の進
  捗としては、文章の細かい修正を経て、内容に技術的な間違いが無いこと
  が確認されたため、WGLC (Last Call)をすべきかの採決が行われ、賛成多
  数となりました。

  (*6) https://www.nic.ad.jp/ja/newsletter/No56/0640.html

  - Close encounters of the ICMP type 2 kind (near misses with ICMPv6
    PTB)
    (ICMP type2 パケットとの遭遇(ICMPv6 Packet-Too-Big パケットのニア
    ミス問題))
    (draft-jaeggli-v6ops-pmtud-ecmp-problem)

  ロードバランサやAnycastを用いている環境で、サーバからサイズの大きい
  パケットを送った際に、ICMPv6 type 2 "Packet Too Big" (PTB)メッセー
  ジ応答が、元のサーバに返らない問題をドラフト化したものです。Fastly
  社のJoel Jaeggli氏が発表を行いましたが、この問題は日本国内では既に
  指摘されている事象です。特定の状況で起こる事象ですが、v6ops WGとし
  て解決すべき問題という位置付けとするかどうかの採決が行われ、賛成が
  多い結果となりました。今後、WGドラフトとなるための協力を求むとして、
  発表は終わりました。

  ちなみに、この一風変わったドラフトタイトルは、「未知との遭遇」(原
  題:Close Encounters of the Third Kind)をもじったものです。

  - Power consumption due to IPv6 multicast on WiFi devices
    (Wi-FiデバイスにおけるIPv6マルチキャストパケットによる電池消費)
    (draft-desmouceaux-ipv6-mcast-wifi-power-usage)

  IPv6のWi-Fiに接続した時に、マルチキャストパケットによって端末の電池
  の消耗が早くなってしまう可能性について、実測した結果について述べた
  発表です。同じ発表が、intarea WG (Internet Area WG)においても行われ
  ました。実験結果から、IPv6のWi-Fiネットワークに所属しただけで、少な
  くとも4パケット、可能性としては20パケット以上のマルチキャストパケッ
  トが発生するなど、興味深い知見が得られています。v6ops WGの反応として
  は、電池の消耗を比較するのであれば、他の場合と慎重に比較すべきだ、と
  の意見がありました。

  - IPv4 Address Literal in URL
    (URLにおけるIPv4アドレス表記)
    (draft-osamu-v6ops-ipv4-literal-in-url)

  NAT64/DNS64環境においては、通常では"http://192.0.2.10/index.html"の
  ような、IPv4リテラル表記が含まれるURLを持つIPv4サイトには到達するこ
  とができません。これは、IPv4アドレスをマッピングしたIPv6アドレスを
  通じて、外部のIPv4サイトと接続する必要があるためです。このようなIPv6
  マッピングアドレスを得るために、「<ipv4-address-literal>.TLD」をDNS
  に登録(あるいはホストに登録)する手法について、奈良先端科学技術大学
  院大学の櫨山寛章氏が発表を行いました。また、IPv4リテラルに自動的に
  suffixを付与し、名前として解釈するGoogle Chromeのplug-in を開発し、
  問題なく動作したことが紹介されました。

  チェアであるFred Baker氏は、このことは解決すべき問題であると会場に
  対し表明し、賛同を得ました。しかし、TLD (Top Level Domain)を使うア
  プローチであることから、他の実装との干渉を心配する会場の声も多く、
  標準化にあたっては注意深く手順を踏んで欲しいという意見が、参加者か
  ら複数ありました。


◆ homenet WG

homenet WGは、家庭内が複数のセグメントに分かれ、複数の上流ISPを持つ
(来るべき)状況を想定し、ルーティング(Interior Gateway Protocol; IGP)、
アドレス選択、DNSキャッシュサーバ選択、セキュリティ、境界検出(border 
discovery)、それらの自動設定に関する問題の解決を目的としたWGです。

今回は、ルーティングプロトコルをどのように標準化するかについて、時間
を20分取ってじっくりと議論が行われました。チェアの1人であるMark
Townsley氏のスライドにおいて、IETF 89で示された三つの方向性についての
再確認が行われました。

 1) ルーティングプロトコル無しで実装する(HNCP (Home Networking
    Control Protocol)フォールバックを用いる)

 2) 一つのルーティングプロトコルを選択する(OSPF (Open Shortest Path
    First)、IS-IS (Intermediate System to Intermediate System)、
    etc..)

 3) 二つ以上のルーティングプロトコルを選択する

これまでの議論をまとめると、1)、2)に対しては賛成多数であるが、3)に対
しては賛成少数という状況です。チェアは、ルーティングプロトコルを一つ
に絞りきれなければ、Coin-flip (コイントス)による決定も考えていると表
明しました。会場からは、1)と2)の意見が半々といった状況でした。既存の
ルーティングプロトコルに依存せずに1)で進めたい意見がある一方、1)では
結局homenet WGで新しいルーティングプロトコルを生み出すことが必要とな
り、難しいのではないかという反対派もおり、結局何も決まらないままタイ
ムアップとなってしまいました。

続いて、IS-IS Implementation Reportでは、ルーティングプロトコルとして
IS-ISを用いたhomenetの実装(送信元/先のアドレスの組を用いたルーティン
グ)の報告が行われました。現在、homenetにおいて利用可能なルーティング
プロトコルとして、IS-IS、OSPF、Babelの三つの実装が存在することとなり
ました。

その他、下記を含む多岐にわたる提案が、十分な議論の時間が取れないまま
大量に行われました。最終日である金曜日の午前に行われたため、一部参加
者のフライトスケジュールに配慮した都合によって、時間を巻いて行われた
という側面もあります。

・上流ISPから割り当てられたアドレスを、自動的にhomenet内の複数セグメ
  ントにfloodingする方法の提案
  (draft-pfister-homenet-prefix-assignment)
・homenet内のノードの名前解決をインターネット上のサードパーティーDNS
  にアウトソースする方法の提案
  (draft-mglt-homenet-front-end-naming-delegation)
・homenetに適したPCP(Port Control Protocol) proxyの実装の提案
  (draft-stenberg-homenet-minimalist-pcp-proxy-00)
  など

homenet WGは、家庭内に小規模なマルチホームネットワークを丸ごと作るこ
とを課題設定としているため、必然的に他のエリアやWGに関わる提案が多く
なります。ルーティングエリアとのコンフリクトを懸念したり、チェアや参
加者から他のWGでも議論するよう求められたりと、標準化における難しいプ
ロセスを、これから先、いくつもクリアしていく必要がありそうです。


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

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

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