ニュースレターNo.59/2015年3月発行
第91回IETF報告 IPv6関連WG報告
本稿では、第91回IETFにおけるIPv6関連のWGについて、6man WG、v6ops WG、6lo WG、Homenet WGの議論を中心に報告します。
6man WG（IPv6 Maintenance, Int Area）
6man WGのワーキンググループでは、IPv6プロトコルの基本仕様そのものについてのメンテナンス（見直しや拡張）を議論しています。
ワーキンググループ文書として議論進行中のもの（Working Group Draft）のうち、二つに関して取り上げられました。すでにこのWGで取り上げられている個人文書（Individual Draft）七つについて継続議論があり、今回初めて投稿された文書（new Individual Draft）五つについての発表が予定されていましたが、Atomic Fragmentやv6GEOといった最初の提案で時間がかかってしまい、新しく投稿された5文書については、時間切れで議論されませんでした。
本稿では、議論のあった中からいくつかを取り上げます。なお、今回問題提起された、個人文書の一つ「Deprecating the Generation of IPv6 Atomic Fragments」が会期後、WGドキュメントに「昇格」しました。
1. Efficient ND Design Team報告
前々回のミーティングでも議論された「Efficient ND」は、第89回IETF報告で「無線LAN環境での近隣探索プロトコル（ND）の問題についての議論」として解説された問題点※の改善策を検討するものです。今回、デザインチームが発足し、まとまった報告がされました。
プロトコルに手を入れるにしろ、環境にあったオプションの運用を提示するにしろ、まずは問題分析をきちんとするところから出発しているようです。そのため、このデザインチームのカバー範囲は、近隣探索プロトコルのトラフィック計測から機能ごとの問題分析、問題改善として使えそうなテクニックやオプションの検討と広範囲になっています。6man WG単体ではなく、v6ops WGと共同での検討事項となっています。
問題フィールド特定のための計測結果は、マルチキャスト通信の影響やバッテリへのインパクトについてまとめた二つの文書として書き起こされています。
- draft-vyncke-6man-mcast-not-efficient
- draft-desmouceaux-ipv6-mcast-wifi-powerusage
また、重複検出（DAD）については、別の文書に課題整理がされています。
- draft-yourtchenko-6man-dad-issues
マルチキャストのRS（ルータ探索）と定期的なRA（ルータ広告）、リンクアドレス解決のためのNS（近隣者発見）とNA（近隣者要請）、DAD、Wi-Fiと携帯電話網の混在環境、軽量端末などの端末側のパケット送出特性、mDNS（マルチキャストDNS）のトラフィックボリュームなどが改善対象として選ばれていました。デザインチームからは、主にRS/RAとDADの改良点として、RAの送出に関してタイマーを設けて間隔を長くできるようにすることや、RAにリフレッシュオプションを設けること、DADに関しては手動設定の場合にのみ実施することやさらに手を加える道など四つのアプローチが提示され、議論がされました。レビュー対象の文書は、次の三つとなっています。
- draft-yourtchenko-6man-dad-issues
- draft-krishnan-6man-maxra
- draft-nordmark-6man-rs-refresh
参加者からはデザインチームの活動報告に賛同するコメントが得られ、引き続きデザインチームによる検討が継続されます。
2. Recommendation on Stable IPv6 Interface Identifiers（draft-ietf-6man-default-iids）
セキュリティとプライバシーへの配慮のため、MACアドレス由来のインタフェースID（IID）からRFC7217で定義されている隠ぺいされたIIDの適用を促す文書です。これが必須のものとして採用されると、主にIPv6をトンネルで運搬する技術の実装に影響が出ます。セキュリティとプライバシーは守るべきですが、運用上は特定ができると都合が良い場合もあるなど、柔軟性を求める声もあり慎重な議論がされていました。これも継続議論となっています。
余談ですが、この議論の途中で使われた“ambiguous”という単語がなぜかはやり出し、IPv6系の人が集まるWGやBoFのそこかしこで使われていました。
3. Deprecating the Generation of IPv6 Atomic Fragments（draft-gont-6man-deprecate-atomfrag-generation）
IPv4ノードとIPv6ノードがSIIT（Stateless IP/ICMP Translation Algorithm） を使って通信している際の、IPv6のAtomic Fragmentについてです。問題指摘と廃止の提案については、現状の運用観測に基づいたものですが、実装側や運用を正すべきであるといった意見や、Atomic Fragmentを必要とするMANET（Mobile Ad hoc NETwork）の例などがあげられ、簡単に廃止できるものではないことから、コンセンサスには至らず、継続議論となりました。
4. Including Geolocation Information in IPv6 Packet Headers（IPv6 GEO）（draft-skeen-6man-ipv6geo）
データリンクに使われるプロトコルは多種多様で、必ずしも位置情報を含むように作られていませんが、その上位レイヤのIPは共通利用されています。そこで、IPv6ヘッダに位置情報を含めるようにしようという提案です。位置情報についてもプライバシーへの配慮が必要であるため、これを利用する際には暗号化を必須とするべきであるといった意見が寄せられ、この提案も継続議論となっています。
v6ops WG（IPv6 Operations、OPs & Mgmt Area）
v6ops WGでは、文字通り、IPv6ネットワークの運用管理に関する事項やIPv4ネットワークへの導入、共存技術など幅広い事項を扱っています。今回も午前と午後に二つのセッション枠が確保され、6to4の廃止、ULAの利用考察、マルチプリフィクスの運用ガイド、拡張ヘッダの利用状況調査、DNS64/NAT64環境で利便性を高めるための専用TLDの提案など、さまざまな提案や報告がされました。
なかでも、6to4プロトコルの廃止については、運用被害を防ぐ方向で議論が白熱しています。運用サイドの意見を取り入れるため、チェアからNANOGなどの運用者向けメーリングリストにも議事録が共有され、意見が募られました。
1. Deprecating Connection of IPv6 Domains via IPv4 Clouds（6to4）（draft-ietf-v6ops-6to4-to-historic）
IPv4上でIPv6の通信を行えるようにする6to4技術について、そろそろ役目を終えて廃止にする時期なのではという提案です。Windows OSなどで参照されるアドレスポリシーテーブルでも、Teredoには規定があるが6to4はなくなっているという指摘を受けて、Teredoも廃止してもいいのではという意見も出たりしていました。
アドレスポリシーテーブルでは、6to4はNativeのIPv6より優先度を下げるといった評価のための参照がされているため、テーブルから削除すると問題が起きるだろうという指摘や、6to4のために予約されているアドレス（192.88.99.0/24）をフィルタすれば廃止と同じ意味合いとなるといった意見があり、
- 6to4の廃止
- RFC3068（6to4リレールータのためのエニーキャストプリフィクス）をhistoricステータスにする
- 192.88.99.0/24をフィルタする
という三つの内容に分割して、それぞれ議論することになりました。
2. IPv6 Extension Headers in the Real World（draft-gont-v6ops-ipv6-ehs-in-real-world）
IPv6の拡張ヘッダは、フィルタされて運用に支障をきたす場合が見られます。SI6 Tool Kitの作者である本文書の筆者は、このツールを用いてパブリックなインターネットにおけるIPv6拡張ヘッダの扱い、フィルタ状況について調査を実施し、まとめました。拡張ヘッダの種類ごとの状況はなかなか興味深いものがあります。調査方法とその結果について、質疑がたくさんありました。
最終的には、実装と運用のガイドとなる文書作成をめざしているようですが、ガイドラインの作成には、実装に関する部分があたかも第2の拡張ヘッダの提案をしているように見受けられる部分があるなど問題があるため、待ったがかけられ、調査結果部分を一つの文書として分離してまとめることになりました。
ICMPv6の安易なフィルタも同様ですが、フィルタすることによってブラックホールとなるといった、どういう問題が起きるかを本文書で確認しておくと、健全な運用のイメージがわいて良いのではないかと思います。
3. Design Choices for IPv6 Networks（draft-ietf-v6ops-design-choices）
IPv4とIPv6のdual-stackネットワークやIPv6 onlyのネットワーク構築時の、「デザインチョイス」についてのガイドライン文書です。外部接続や経路制御の手法選択がメインであるため、現在のもっと広範な設計を予想させるようなタイトルから、範囲を絞ったもっとわかりやすいタイトルに変更した方がいいという指摘が出ていました。
その一方で、DHCPやSLAAC（StateLess Address AutoConfiguration）など内部の運用術に関して扱った方が良いという「広範」をめざすべきという意見も出ていました。また、いずれにしてもセキュリティに関してはしっかり書いておくべきだろうといった意見もあり、引き続き内容を厚くしていくことになりました。
4. A Special Purpose TLD to resolve IPv4 Address Literal on DNS64/NAT64 environments（draft-osamu-v6ops-ipv4-literal-in-url）
DNS64/NAT64を運用している環境で、IPv6端末がIPv4のみのアプリケーションサーバに明示的にアクセスする場合のURLとして、「.v4」をTLDとして指定するとIPv6アドレスにIPv4アドレスをマッピングする仕組みの提案が継続議論されています。
この仕組みの有用性は多くの参加者から賛同されているようでしたが、新しいTLDを作ることに難色を示す人が多かったように思われます。代わりに、「v4only.arpa」はどうかといった提示もされていました。また、DNSSECやcookieがうまく動作しないのでは、ということも指摘されていました。指摘事項に関して文書を更新するとともに、DNSOPSでも議論するということになりました。
今回の私の参加目的として、v6opsでの発表というのがありました。15分ほど時間をもらえ、国内で実施している中小規模の組織向けルータのIPv6に関するセキュリティテストについて報告をしました。“Introducing IPv6 vulnerability test program in Japan, <draft-jpcert-ipv6vullnerability-check>”という文書名で公開されていますので、ぜひご一読いただき、コメントをいただければと思います。
6lo WG（IPv6 over Networks of Resource-constrained Nodes WG）
6lo WGでは、省電力で低電力な軽量端末が接続されるIPv6ネットワークの技術について議論をしています。
IoTという言葉の盛り上がりも見られる中、粛々と軽量クライアントのための近隣探索や、おサイフケータイなどでも使われているNFC上のIPv6パケットの転送技術などが話し合われています。こちらでも、RFC7217ベースのインタフェースIDの利用に関する議論がされました。
“IPv6 mapping to non-IP protocols”については、6man WGのチェアとも相談するようにという指示が出ていました。
Homenet WG（Home Networking WG）
Homenet WGでは、最近の多種多様なデバイスとそれが属する多様な通信網を念頭においた家庭内ネットワークの接続手法や、管理手法が議論されています。
- Routing
- Addressing / Configuration
- Naming
- Service Discovery
- Security / Border Discovery
のカテゴリが提示されており、これに従って議論が開始されましたが、最初のルーティングに関する議論だけでほぼ一つのセッション枠を使い切ってしまう事態になり、急遽空いている部屋を探して、別の日にも議論がされました。家庭内のデバイス管理のために、.homeというTLDを使う提案などもされていました。
IPv6のプロトコルを基盤とした次の展開に向けた議論が多数行われていることを、あらためて感じたIETF91のオンサイトミーティングでした。
（株式会社インテック 廣海緑里）
- ※ JPNICニュースレター No.57「第89回IETF報告 IPv6関連WG報告」
- https://www.nic.ad.jp/ja/newsletter/No57/0650.html
