ニュースレターNo.62/2016年3月発行

第94回IETF報告　IPv6関連WG報告

6man WG (IPv6 Maintenance WG)

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。 今回は、11月4日(水)の朝一のコマ(9:00-13:00)にて開催されました。 前日の夜に盛大なソーシャルイベントがあったにも関わらず、 100名程度の参加者を集め、活発な議論が実施されました。

ミーティングは、いつも通りチェアによるアジェンダ、 Note Well (権利等の注意事項)の確認、 およびWGの関連文書ステータス報告より始まりました。 ミーティングの時点で、WG文書のうちRFC発行待ちの文書が2件、 WGラストコール中の文書が1件、 WGラストコール待ちの文書が1件存在しています。 また、WGで議論中の文書が6件、 WGの議論文書とするかどうか検討中の文書が3件となっており、 IPv6のプロトコル自体の検討も継続的に実施されていることがわかります。 この後、チェアより、他のWG (conex (Congestion Exposure) WG, ippm (IP Performance Metrics) WG)における議論内容で、 IPv6プロトコルに関連して6man WGに照会があった、 2件の案件対応について報告がありました。 2件とも拡張ヘッダに関するものですが、他のWGにおいても、 拡張ヘッダを使用したIPv6自体の機能拡張が検討されているようです。

今回のミーティングでは、次のWGドラフト2件、 個別ドラフト5件について議論されました。

アジェンダには、以下の3件の個別ドラフト(うち、 新規2件)が上がっていましたが、 時間切れで次回送り(プレゼンテーションスライドはプロシーディングに収録)となりました。

議論されたアイテムの中から、いくつかを紹介します。

Host routing in a multi-prefix network (マルチプリフィクスネットワークにおけるホストルーティング),draft-ietf-6man-multi-homed-host

複数のアップリンクを持つネットワークにおける、 ホストの動作についての変更提案です。 特に、同一リンク上に複数のルータがある場合のホストと、 複数のアップリンクを持つホスト(スマートフォン等)を対象にしています。 前者の場合、現在の仕様では、 複数のルータにおいてステートレスアドレス自動設定(StateLess Address AutoConfiguration: SLAAC)を利用した場合に、 ホストがどのルータをパケット送出先として選択するかについての、 明確な規定がありませんでした。 このため、ホストが選んだルータによっては、 BCP38に定義されており多くのISPで採用されている、 送信元アドレス詐称を防ぐためのイングレスフィルタリング^※1により、 通信ができない可能性があります。

後者の場合でも、 ホストが選んだルータと送信元アドレスの組み合わせによっては、 通信に失敗します。 また、現状のICMPv6リダイレクトの仕様では、 複数のアップリンクをホストが持つ場合(無線LANとLTE回線に接続されるスマートフォン等が想定されています)、 ルーティング最適化のために片方のアップリンクルータが、 ホストにICMPリダイレクトを送信するような場合に対応できないことを問題としています。

これらの状況を改善するため、送信元アドレスにより、 転送するルータを選択する(SLAACによりアドレスを付与したルータに、 対応した送信元アドレスを持つパケットを送信する)こと、 およびホストがリンクの違うアップリンクルータから受け取ったリダイレクトを処理するよう、 ホストの動作を変更する提案です。 複数のルータからのSLAACに対応する変更には、 いくつかの賛成が表明されましたが、 ICMPリダイレクトに関する動作については、 否定的な意見も提起されました。 このドラフトについては、MLでの議論の後、 WGラストコールに向けて調整が実施されることになっています。

IPv6 specifications to Internet Standard (IPv6仕様の“インターネット標準”化), draft-ietf-6man-rfc2460bis,draft-hinden-6man-rfc4291bis

現在のIPv6の基本仕様は、 1998年に発行されたRFC2460にて規定されており、 この文書はDraft Standardという位置づけになっています。 従来より6man WGにおいて、 「IPv6の仕様をインターネット標準仕様の最終段階である“インターネット標準(Internet Standard)”に昇格させ、 IPv6の仕様は完全にできあがったことを世の中に知らしめ、 普及の後押しをすべきだ」という議論がありましたが、 なかなか作業が先には進みませんでした。 しかしながら、IETFにおける標準化プロセスの見直しにより、 Draft Standardカテゴリが廃止(RFC6410)されてから数年がたち、 従来Draft Standard カテゴリにあったRFCのカテゴリ見直しが必要になったこともあり、 IPv6仕様の“インターネット標準”化を本格的に実施することとなり、 その作業が進んでいます。

今回のミーティングでは、 前回の議論に基づき実施された改版の状況や、 作業を進める上での留意点、今後の方針が議論になりました。 現在、改版が進んでいる文書は以下の2文書です。

• RFC2460 (draft-ietf-6man-rfc2460bis) : IPv6の基本仕様
  RFC2460を更新している文書および訂正(Errata)の取り込み、内容の更新等
• RFC4291 (draft-hinden-6man-rfc4291bis) : IPv6アドレス構造
  RFC4291を更新している文書および訂正(Errata)の取り込み、参照の更新等

今後、RFC2460の改版文書については、 WGラストコールを実施予定となっています。 RFC4291の改版ドラフトについては、 WGアイテムとすることがミーティングでは同意を得て、 MLにおいてWGアイテム化の最終確認を実施することになっています。

その他、“インターネット標準”化に向けたプロセスを進めるため、 “RFC1981-IPv6パスMTU探索”のレビュアー募集等が実施されています。

IPv6標準仕様群の“インターネット標準”化は着実に進行しており、 IPv6のさらなる普及に向けた動きも活発化しそうです。

□6man WG

http://datatracker.ietf.org/wg/6man/charter/

□第94回 IETF 6man WGのアジェンダ

http://www.ietf.org/proceedings/94/6man.html

v6ops WG (IPv6 Operations WG)

v6opsは、IPv6に関するオペレーション技術および共存・移行技術に関する議論を実施するWGです。 IPv6の普及を受け、提案数が多いセッションとなっており、 このところ毎回2コマを使っての開催となっています。 今回も、月曜の朝一(9:00-11:30)、 月曜の最終(17:10-19:10)の2コマにて開催されています。

参加者もそれぞれ150名程度で、 IPv6の実利用について多くの人が興味を持っていることがうかがえます。

ミーティングは、 チェアによるNote Wellの確認およびアジェンダの紹介から始まりました。 今回のミーティングでは、次の項目が議論されました。

これらのトピックスの中から、いくつかを紹介します。

Identifier-locator addressing for network virtualization (ネットワーク仮想化のための識別子-ロケータ分離アドレス構造), draft-herbert-nvo3-ila

ネットワークの仮想化を実施するために、IPv6を利用する提案です。 Facebook社では、 IPv4アドレスの不足やネットワーク構築の柔軟性等の理由から、 同社のデータセンター内でIPv6の利用を進めています。 IPv6のアドレス空間の広大さを有効活用し、 従来からのホストに対するアドレスでなく、 データセンター内でネットワーク上を移動するタスクごとにIPv6アドレスを付与することで、 ネットワーク仮想化を実現するというものです。 この機構を実現するため、 IPv6のアドレスをネットワーク上での位置情報を示すロケータ部と識別子部分に分離し、 外部との通信にはDNSを用いてアドレスマッピングを実施します。 実現には、nvo3 (Network Virtualization Overlays) WGで議論されている、プラットフォームを利用できるとしています。

参加者からは、 「この機構をインターネットワイドで利用する予定なのか」「機構自体はモバイルIPv6と同等だが、 そちらの利用は検討したのか」「特にアドレスマッピングの際のセキュリティ課題の解決が重要であり、 モバイルIP機構にはその検討も織り込んである」等の意見が挙げられました。

本件については、議論を継続することとなりました。

Some Design Choices for IPv6 Networks (IPv6ネットワークの設計),draft-ietf-v6ops-design-choices

午後のセッションで実施の予定でしたが、 時間の関係から午前中のセッションにて実施されることになりました。

IPv6ネットワークを構築する際に参考にできる、 設計方針に関するドラフトです。 これまで議論を重ねてきており、今回すぐに合意ができるだろう、 という著者の導入から議論が始まりました。 前回からの変更点として、 企業ネットワークに関する扱いの変更(別文書にするべきという意見があったが、 記述を継続)や、 企業ネットワークで利用するアドレス種別についての詳述、 組織内で利用する経路制御プロトコルに関するサーベイ結果の追加等が説明されました。

会場から、「企業ネットワークにおいては、 その規模や形態によって要求条件がまちまちであり、 サンプルとできる設計指針を決めることが困難であること」「NAT66を推奨すべきかの合意が無いこと」等、 非常に白熱した議論になりました。 かなりの時間を使いましたが議論が収束せず、 午後のセッションに持ち越しとなりました。

2コマ目のセッションは、 “Some Design Choices for IPv6 Networks”の議論の続きから始まりました。 午前中のセッションでの議論を受け、ドラフトの著者より、 IPv4関連の記述をなくすことおよびNAT66/NAPT66に関するコメントを追加することが述べられました。 これらの変更を織り込んだドラフトを発行後、 WGラストコールを実施することとなりました。

IP/ICMP Translation Algorithm (rfc6145bis)(IP/ICMP変換アルゴリズム), draft-bao-v6ops-rfc6145bis

IPv4とIPv6間の変換についてはRFC6145にて記述されており、 これはNAT64 (RFC6146)や、 464XLAN (RFC6877)の構成要素の一つとなっています。 このRFCについて、6man WGで議論されRFC化された、 フラグメントに関する変更、RFC発行後の訂正(Errata)、 アドレスマッピングアルゴリズムの更新を取り込み、 改版しようという提案です。 マッピングアルゴリズムの更新に関するコメント等がありました。 このドラフトはWGドラフトではありませんが、 この後のプロセスを進めることも鑑み、 WGドラフトにした後でWGラストコールを実施し、 プロセスを進めることとなりました。

□v6ops WG

http://datatracker.ietf.org/wg/v6ops/charter/

□第94回 IETF v6ops WGのアジェンダ

http://www.ietf.org/proceedings/94/v6ops.html

(NTTネットワーク基盤技術研究所 藤崎智宏)

---

※1 イングレスフィルタリング

RFC2827 (BCP 38)で解説されている、送信元を偽装したIPパケットの転送を防ぐ手法の一つです。