＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1117【臨時号】2013.9.3 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
---------- PR --------------------------------------------------------
■【クラウド】の【監視・運用・バックアップ】まで一手にお任せ下さい！■
御社のサービスエンジニアとなって、クラウド環境の構築から運用・管理まで
ワンストップで行います。　エンジニアは「雇う」から「利用する」時代へ
●株式会社ディーネット
●詳細はこちら ⇒http://www.cloudserv.jp/
----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1117 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号では昨日発行したvol.1116に続いて、2013年7月28日から8月2日にドイツ
のベルリンで開催された、第87回IETFミーティングのレポート[第2弾]とし
て、IPv6関連WGの動向についてご紹介します。

第87回IETFの全体報告については、下記のURLからバックナンバーをご覧くだ
さい。また、次号以降では、セキュリティ関連WG報告、DNS関連WG報告などを
お届けする予定です。

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

□IETF報告会(87thベルリン)開催のご案内
  https://www.nic.ad.jp/ja/topics/2013/20130827-01.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第87回IETF報告 [第2弾]  IPv6関連WG報告
   ～6man WG、softwire WG、behave WG、v6ops WG、sunset4 WGについて～
                                               富士通株式会社 松平直樹
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ドイツのベルリンで開催された、第87回IETF会合におけるIPv6関連のWGとし
て、6man WG、softwire WG、behave WG、v6ops WG、sunset4 WGの五つのWGに
おける議論の概要と、SA46T/SA46T-PR/SA46T-PT提案について報告いたしま
す。

◆ 6man WG (IPv6 Maintenance WG)

6man WGは、IPv6の基本仕様のメンテナンスを行うWGです。IPv6アドレスのプ
ライバシーに関連する議論や、連鎖可能な最大拡張ヘッダ数に関する議論の
ほか、IPv6フラグメントヘッダの廃止についての興味深い議論が行われまし
た。特に、IPv6フラグメントヘッダの廃止は重要なテーマですので、少し長
くなりますが、詳しく報告します。

インターネットは、さまざまな種類のデータリンクを相互接続して構成され
ますが、最大フレーム長はデータリンクにより異なります。そのため、大き
いフレームを扱えるリンクから、それより小さいフレームしか扱えないリン
クにパケットを転送する際、サイズが超過し転送できない場合があります。
その際、小さいフレームにパケットを分割して転送します。この分割の処理
を、フラグメンテーションと呼びます。

IPv4では、当初、ルータにてフラグメンテーションを行う仕様でしたが、ネッ
トワークの高速化に対応するために、PMTUD (Path MTU Discovery)という、
パケットを発信するホストでフラグメンテーションを行う仕様が追加されま
した。ルータでのフラグメンテーションとPMTUDのどちらを用いるかは、パ
ケットを発信するホストが選択します。IPv6では、後者のPMTUDが前提となっ
ており、ルータはフラグメンテーションを行いません。

PMTUDでは、パケットを次ホップに転送できなかった場合、そのルータはパ
ケットを廃棄し、ICMPエラーメッセージに、転送可能な最大フレーム長(MTU)
を格納して発信ホストに返信します。以後、このホストは、通知されたMTUに
合わせてパケットをフラグメンテーションして送信します。

ところで、インターネット上にはICMPメッセージをフィルタ、つまり廃棄す
るネットワークが存在すると言われています。ICMPをフィルタしてしまうと、
PMTUDで用いられるICMPエラーメッセージもホストに返信されなくなります。
よって、ホストはいつまでたっても廃棄されることになるパケット長で送信
を繰り返し、それがルータで廃棄されますので、いつまでたっても通信は成
功しません。このような状態をPMTUDブラックホールと呼びます。

この問題を回避するために、現在のIPv4環境では、TCP MSS (Maximum Segment
Size)と呼ぶ、上位のトランスポート層であるTCPでのデータ長のネゴシエー
ション機能を操作するか、もしくはルータでフラグメンテーションをさせ、
PMTUDを用いない制御を行うといった、先祖帰りのような方法が採られていま
す。前者はTCPには有効ですが、UDPやGRE (Generic Routing Encapsulation)
トンネルには効果はありません。しかも、IPv4だけでなくIPv6にも影響しま
す。また、後者の対応はIPv6では規定されていませんので、取りようがあり
ません。なお、IPv4では機能したとしても、性能が劣化することになると考
えられます。

また、v6ops WGにて議論されている、"Why Operators Filter Fragments and
What It Implies"によると、IPv6のフラグメント化されたパケット、つまり
フラグメントヘッダが付いているパケットすら、廃棄するネットワークが存
在するようです。これは厳密には、PMTUDが機能しても、フラグメント化され
たパケットは廃棄されるという別の問題ですが、フラグメンテーションが機
能するための環境が、思いのほか厳しいものであると言えそうです。

今回行われた議論は、「機能しないなら、いっそのことネットワーク層の機
能として廃止してしまえ」というものです。フラグメンテーションは必要で
すので、もし廃止されてしまえば、そのしわ寄せは上位層、つまり、トラン
スポート層もしくはアプリケーションに向かうことになります。RFC4821の
"Packetization Layer Path MTU Discovery"はその候補です。

6man WGにおけるこの検討はIPv6のみに限定していますが、IPv6の通信だけで
はなく、カプセル化やIPv4-IPv6変換などの移行技術にも関連します。そし
て、実はIPv4環境でもUDPは対応できませんので、DNSSECの普及にも影響する
可能性がありそうです。

ところで、筆者はSA46Tを提案しており、実験等を行いますが、実際、通信で
きないサイトに出くわすことがあります。TCP MSSを操作することにより通信
できるようになるので、このサイト、もしくは、このサイトの経路上のネッ
トワークで、ICMPエラーがフィルタされているものと推測しています。もち
ろん、TCP MSSを操作しなくても通信できるサイトもたくさんありますので、
ICMPエラーがきちんと返送されるサイトもしくはネットワークも存在します。
ICMPエラーの廃棄は、推測の域を出ませんが、しかし、実際に出くわす現象
です。

このように、フラグメンテーションはIPv6だけではなく、IPv4にも影響を及
ぼす、インターネット全体に関わる問題ですので、IETFのような標準技術の
開発コミュニティだけではなく、運用コミュニティとの連携など、業界を挙
げた問題解決が必要なのではないかと思います。私自身はやはり、PMTUDがき
ちんと動作することがインターネット全体の利益になると思いますし、TCP 
MSSによる解決策は、抜本解というより緊急避難的なものに思えます。このフ
ラグメントヘッダの廃止提案は、建設的な提案というより悲鳴に聞こえまし
た。この解釈は人によって異なるかもしれません。何が問題なのかの整理が
必要になっていそうです。並行して、実態の把握が必要でしょうし、なぜ
PMTUDに関連するICMPエラーが廃棄されるかについても、原因の調査が必要で
しょう。原因が分かれば対処できるかもしれません。もし、どうしてもICMP
エラーをフィルタしたいなら、少なくとも、1500ByteのIPパケットの転送を
保証すべきというような解決策もあり得るかもしれません。

繰り返しになりますが、この問題に関しては、問題をきちんと定義し、実態
を把握し、原因を突き止め、問題を解決していく必要があると思います。イ
ンターネットをきちんと動かし続けるためには、業界連携、つまり業界の果
たすべき役割があるように思えます。いかがでしょうか。ご意見をお待ちし
ています。


◆ softwire WG (softwire WG)

今回は、MAP-Eに関する議論は行われず、LW4o6、4rd、MAP-Tについての提案
が行われたほか、DHCP関連の提案がなされました。大きな流れとしては、
unified CPEの標準化に焦点が移っているように感じます。

なお、筆者の提案である、SA46T、SA46T-PR、SA46T-PTがアジェンダに含まれ
ていましたが、アジェンダの消化率が65%でした。そのためほかの多くの提案
同様、議論に至らずミーティングが終了しました。


◆ behave WG (Behavior Engineering for Hindrance Avoidance WG)

今回、IPv4 onlyクライアントから、IPv6 onlyサーバにアクセス可能とする、
NAT46の提案がなされました。この前提は、サーバに割り振るIPv4アドレスが
枯渇し、一方クライアント側は依然としてIPv4アドレスを利用している状況
に対応するものです。筆者もこのような状況を想定し、SA46T-AS (SA46T 
Address Sharing)を提案しています。

検討が一段落したためか、しばらくWGの開催はありませんでしたが、今回の
会議では、提案が増えてきていると感じました。なお、前回のオーランド会
議で、筆者はSA46T-AT (SA46T Address Translator)という技術の提案を行っ
ています。


◆ v6ops WG (IPv6 Operation WG)

Teredoサーバの停止に関する報告や、Happy Eyeballsの効果測定、NAT64の運
用に関する報告などが行われました。また、慶應義塾大学の中村修先生が、
NAT64環境を想定し、URLでのIPv4アドレス表記に関する提案を行いました。


◆ sunset4 WG (Sunsetting IPv4 WG)

奈良先端科学技術大学院大学の櫨山寛章先生が、IPv6 onlyネットワーク環境
での利用を想定した、DNS Aレコードのフィルタリングに関する提案を行いま
した。この提案は、WIDE合宿での実験をベースにしており、説得力があり、
多くの方から興味を持たれました。

また今回は、DHCP WGとのjoint meetingが開催され、DHCPv6を用いてIPv4を
停止する提案、DHCPv4 over DHCPv6などの議論がなされました。


◆ SA46T/SA46T-PR/SA46T-PT提案について

今回のSA46T/SA46T-PR/SA46T-PT提案のスライドは、以下のURLにて参照でき
ます。

http://tools.ietf.org/agenda/87/slides/slides-87-softwire-20.pdf

SA46T-PRとSA46T-PTは、今回はじめてIETFに提案しましたが、一足早く、
Interop 2013 Tokyoにてデモンストレーションを通じてご紹介いたしました
ので、既にご存知の方もいらっしゃるかと思います。

今回のIETFでの提案に関し、実は、富士通は特許の扱いに関する方針転換を
行いました。SA46Tに関しては特許が成立しており、IETFへの提案に際し「妥
当で公平なライセンス」であるRAND (Reasonable and Non Discriminatory 
Licensing)条件のStatementを提出していました。これに対し「RAND条件では
IETFでの標準採用は難しいのでは」というアドバイスをいただくなどしてい
たため、今般、Non-assertion条件に変更を行いました。興味のある方は、
IETFに提出されているPatent Statementをご覧ください。


◆ アジェンダおよびプレゼンテーション資料について

今回ご紹介した、IPv6関連WGのアジェンダおよびプレゼンテーション資料は、
WGごとに以下のURLにまとめられています。

□6man WG
  http://tools.ietf.org/wg/6man/agenda?item=agenda-87-6man.html

□softwire WG
  http://tools.ietf.org/wg/softwire/agenda?item=agenda-87-softwire.html

□behave WG
  http://tools.ietf.org/wg/behave/agenda?item=agenda-87-behave.html

□v6ops WG
  http://tools.ietf.org/wg/v6ops/agenda?item=agenda-87-v6ops.html

□sunset4 WG
  http://tools.ietf.org/wg/sunset4/agenda?item=agenda-87-sunset4.html


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

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

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