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

2017年3月26日(日)～31日(金)にかけて、米国のシカゴにて開催された第98回
IETFミーティングの報告を、vol.1492より連載にてお届けしています。本号
ではその第3弾として、IPv6関連WGについてプロトコルおよび運用に関する諸
問題の議論を中心にご紹介します。

次号となる第4弾では、セキュリティに関する動向をお届けする予定です。ま
た、第1弾の全体会議報告および第2弾のトランスポートエリア関連報告につ
いては、下記のURLからバックナンバーをご覧ください。

  □第98回IETF報告

    ○[第1弾] 全体会議報告 (vol.1492)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2017/vol1492.html

    ○[第2弾] トランスポートエリア関連報告 (vol.1493)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2017/vol1493.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第98回IETF報告 [第3弾]  IPv6関連WG報告
                                               Infoblox, Inc. 神明達哉
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本稿では、IETF 98で開催されたIPv6関連のワーキンググループ(WG)ミーティ
ングにおける主な議論内容を紹介します。

WGミーティングは多くの議題を扱いますが、本稿では、全体的な傾向と、注
目すべき発表や議論に絞って詳しく説明します。それ以外の発表や議論につ
いては、IETFのミーティング資料のページ(*1)をご参照ください。

(*1) https://datatracker.ietf.org/meeting/98/materials

IPv6関連の二つのWGに共通して、IPv6が徐々にではありながら実運用で広く
使われつつあることに付随した問題点が浮上してきているという印象を持ち
ました。米Apple社による、iOSの実装と運用からのフィードバック提案(後述)
はその典型と言えるかと思います。また、IPv6特有の機能や思想を積極的に
仕様に記述したいと考える人と、特にIPv4運用との整合性などの観点からそ
れを押し付けだとして反対する人との対立も目立ちました。IETFでは、こう
した場合に議論が膠着して何も進展しなくなることが多々あるため、今後の
展開がやや心配です。


■6man WG (IPv6 Maintenance WG)

6manはIPv6関連のプロトコルを扱うWGです。3月30日(木)の9:00～11:30の一
コマでミーティングが開催されました。最近話題のQUIC WGのミーティングと
重なったせいか、広い部屋が割り当てられていた割には参加者はまばらな印
象でした。

ミーティングのほとんどの時間は、基本プロトコル仕様のInternet Standard
への格上げに関する議論に費やされました。本稿でもその内容に絞って説明
します。

この議論はInternet AreaのIESG (Internet Engineering Steering Group)メ
ンバであるSuresh Krishnan氏が取りまとめました。6man WGは現在、RFC1981、
2460、3595、4291、4443の五つを格上げしようとしています。その中で、特
に基本プロトコル仕様のRFC2460と、アドレスアーキテクチャを規定する
RFC4291が激しい議論を引き起こしています。

RFC2460については、パケットの送信ノード以外はIPv6の拡張ヘッダをパケッ
トに挿入できないとする仮定を、文面として明記するかどうかで意見が分か
れています。これは、RFC2460の著者を含めてIPv6の標準策定に関わった多く
の人が暗黙的に認めていた仮定のため、RFCでは「挿入」という言葉が明示的
に使われていませんでした。これに対し、Segment Routing (SR)というプロ
トコルの一部実装では、パケットを転送するルータが拡張ヘッダを挿入する
挙動になっています。仕様へのこのような「誤解」を受けて、6man WGでの
RFC2460の格上げにあたって本来の仮定を明記して曖昧さを解消しようとした
のですが、SRを実装、運用するベンダやオペレータからこの修正が将来の拡
張を阻害するものとして強い反対が示されました。WGの議論およびIETFでの
ラストコールを経て、Krishnan氏は、将来の拡張を否定するものではないと
した上で曖昧さを解消する文面を提案しましたが、ミーティングの場でもこ
れは実運用を無視した純粋主義だとする強い抗議がありました。本稿執筆時
点ではIESGの承認プロセスに入っていますが、この問題を解決するまでは承
認すべきでないとするIESGメンバもおり、今後どうなるかはやや不透明な状
況です。

RFC4291については、現状使われているグローバルアドレスのサブネット長お
よびインタフェースID長を64ビットに固定するという記述を、残すか緩める
かについて対立しています。RFC4291では、アドレスアーキテクチャの一部と
してインタフェースID長を固定しています。これは、おそらくはステートレ
スアドレス自動構成(RFC4862)との整合性を考慮した結果だと思われます。
しかし、特にISPのコアネットワーク内などでは、アドレスを手動設定した上
でサブネット長も手動で変えることが多いのが実情で、基本仕様としてこれ
を固定するのは、実運用を無意味に規定違反とするだけで有害だとする意見
が運用者を中心にあがっています。一方、一部のホスト実装者は、事実上無
限と言えるだけのID空間を取ることによる将来的な拡張の可能性や、それを
固定することで実装を簡潔にする効果などの点で、現状の仕様のままとすべ
きだと主張しています。Krishnan氏は、この対立点について両者の意見の隔
たりが大きく、IESGでの承認プロセスにかけるのは時期尚早だとして、議論
をWGに差し戻しました。ミーティングの場でも両者がそれぞれの立場を再度
主張し合う議論になりましたが、この短時間で結論が出るはずもありません。
当面はML上での継続審議ということになるでしょう。


■v6ops WG (IPv6 Operations WG)

v6ops WGでは、IPv6の運用に関する諸問題を議論しています。実装を伴うプ
ロトコルの議論は扱わないのが原則です。ミーティングは3月29日(水)の
13:00～15:00の一コマで開催されました。6manとは逆に小さめの部屋でした
が、ほぼ一杯になって息苦しくなるほどでした。米Apple社による発表など、
注目を集めた議題によるものかと思われます。

ミーティングの冒頭で、WGチェアから設立書(charter)の更新に関する提案が
あり、今後、IPv6のみのネットワークに関する問題を取り上げるか、またイ
ンターネットのさまざまな用途の違いを考慮した提言をしていくか、という
問いかけがありました。特に前者については、参加者から積極的に肯定する
意見が目立ちました。

以下、特に注目を集めた発表2件について説明します。

- On the Dynamic/Automatic Configuration of IPv6 Hosts

Fernando Gont氏による遠隔の発表です。現状、IPv6ホストがDNSサーバアド
レスやドメイン名サーチリストなどの設定情報を取得するためのプロトコル
として、DHCPv6による方法とルータ通知(Router Advertisement、RA)による
方法があります。ただ、これらのプロトコルの実装状況は、ホストやルータ
によってまちまちであり、任意のホストが任意のネットワークで設定情報を
自動取得できるとは限らないという状況が続いています。このドラフトでは、
その問題をあらためて指摘するとともに、最大限の相互接続性を確保するた
めに、ホスト実装が両方のプロトコルに対応するように求めています。この
問題が難しいのは、これが単なる実装の不備ではなく、IPv6ネットワーク運
用の考え方についての、根本的な見解の相違に根付いているというところで
す。一方では、DHCPv6は柔軟さに欠ける劣ったプロトコルだとして実装を拒
否するグループがあり、他方ではIPv4からの継続性や、より集中的な管理の
ためにDHCPv6以外での運用を拒否するグループがあります。そのため、どち
らかの方式の実装を"MUST"として強制したり、両方の実装を要求したりする
といった提案が合意に至る見込みが立っていません。

今回のミーティングでも、いつものように議論は平行線気味で、結局ドラフ
トもWGドキュメントとして採択されるには至らず、MLでの継続議論というこ
とになりました。ミーティングが終わった本稿執筆時点でも、MLのトラフィッ
クの多くがこの議論に費やされていますが、残念ながら合意が得られそうに
は見えません。

- An Update to Happy Eyeballs

米Apple社のDavid Schinazi氏による、iOSの開発・運用経験を元にしたHappy
Eyeballs (HE)アルゴリズムに対する改善提案です。RFC6555で規定されるHE
は、IPv6/IPv4のデュアルスタックホストにおいて、TCPコネクション接続先
の候補が複数ある場合に、複数候補についてある程度並行してコネクション
確立を試みることで、特定のアドレスへの接続性が悪くても長いタイムアウ
トを待たずに済むようにするというアルゴリズムです。RFCで規定されるアル
ゴリズムでは、TCPコネクション確立に先立って、IPv6とIPv4アドレスの双方
についてDNSによる名前解決(それぞれAAAAとAレコードの取得)を完了させる
のが前提になっています。このドラフトでは、DNSの名前解決においても、
AAAAまたはAの一方の問い合わせだけに長い時間がかかる場合がしばしばある
として、名前解決を非同期にする(どちらかの問い合わせが完了した時点で、
他方の応答を待ちつつコネクション確立を開始する)必要があるとしています。
ミーティングでの発表においては、iOSデバイスで取得した統計情報を元にこ
うした事情が説明されており、説得力がありました。また、こうした実際の
運用データを元にした細かなタイムアウト値の計算方法なども示されていて、
興味深い発表でした。実際、この発表には参加者から多くのコメントがあり
ました。IETFの発表では、特に議論を呼ぶような発表に対してコメントする
人がマイクの前に長い列を作るという光景がときどき見られますが、この発
表に対する反応はその典型的なケースでした。APNICのブログ(*2)に、その様
子を撮った写真が掲載されています。

(*2)IETF 98 Chicago: New energy in the IPv6 Operations WG
    https://blog.apnic.net/2017/03/31/ietf-98-chicago-new-energy-ipv6-operations-wg/

コメントは、従来の「同期的」名前解決に対する考え方、TCP SYNのタイムア
ウトに対する考察、APIの標準化に関する助言、あるいはそもそもHEは問題を
隠蔽するもので推奨すべきでないとの意見など、多岐にわたりましたが、全
体としてはおおむね肯定的でした。本稿執筆時点で、RFC6555の後継とするた
めのWGドラフトとして採択されています。


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

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

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