進化するインターネット技術／IETFトピックス2016-17

第4回

20歳を超えたIPv6の現状、修正版RFCで廃止／アップデートされる仕様も

西塚要（NTTコミュニケーションズ株式会社）

2017年6月16日 06:00

インターネット技術の普及に向け、IPv6、DNS、HTTPなど基本となるプロトコルを定めてきたIETF（The Internet Engineering Task Force）。今年11月には、100回目の会合（IETF 100）がシンガポールにて開催される予定である。IETFがこれまで手がけてきたインターネット技術も、技術の進歩と普及により、現在も多くの分野において議論が継続され、まだまだ目が離せない状況が続いている。本連載では、インターネットの普及と発展を目的に日ごろIETFを中心に活動を行っているISOC-JP（Internet Society Japan chapter）メンバー有志が、ここ最近のIETFでの活動状況について紹介していく。

「IETFトピックス2016-17」連載記事一覧

　IPv6は、最初のRFC（RFC1883: IPv6 Specification）が発行されてから、2015年12月に20周年を迎えた。そして2016年には、Googleによる統計で普及率が10％を超え（「Celebrating New Year 2016 with 10% IPv6!」）、Apple StoreにおいてIPv6対応がiOSアプリの必須要件（「Supporting IPv6-only Networks」）になるなど、IPv6に関する話題が多く取り上げられた。

　また、日本におけるIPv6の普及率については、先日、IPv6普及・高度化推進協議会により更新された情報（「アクセス網におけるIPv6の普及状況調査」）によると、GoogleサービスへのIPv6アクセスでは、総じて10％を超える結果となっている。

IPv6普及・高度化推進協議会「アクセス網におけるIPv6の普及状況調査」より

　IPv6の普及が着々と進む一方、IETFではIPv6のコアな仕様を「Draft Standard（DS）」から最上位の「Internet Standard（STD）」に位置付けるための整理が行われており、IPv6の最新仕様についての議論が終盤を迎えている。

　IPv6の現状について、今回と次回の2回にわたり紹介する。

IETFとIPv6

　IPv6は、IETFを代表するプロトコルの1つである。

　IPv6の歴史は古く、1994年に発足したipng WGにおける次世代インターネットプロトコル（IPng）候補の検討に端を発する。冒頭で述べたRFC 1883は、ipng WGにおける成果の1つである。

　現在は、IPv6仕様のメンテナンスと最新化を行う6man WGと、IPv6を展開するにあたっての緊急の課題、特に運用上の課題に対処することに焦点を当てたv6ops WGを柱とし、その他、IPv6移行・IPv6/IPv4共存技術を検討するsoftwire WGとbehave WG（2013年に終了）、マルチホーム環境を検討するhomenet WG、IoT分野・センサーネットワークにおけるIPv6利用を検討する6lo WG（旧6lowpan WG）と6tisch WGなど、関連WGが多く存在する。

ISOC-JP IETF 94報告会「IPv6関連WG 変遷」より

　2015年には、AppleのiOS 9/OS X El CapitanにおいてIPv6を優先して最初に通信を試み、IPv4には25msの待ち時間を課すという動作の詳細が「Apple and IPv6 - Happy Eyeballs」というタイトルでv6ops WGのMLに投稿された。その後も、2016年のIETF 96では、IETFと同時開催されるIRTF（Internet Research Task Force）のmaprg（Measurement and Analysis for Protocols Proposed Research Group）において、iOS 10（β）とmacOS Sierraでの最新測定データ（IPv4/IPv6デュアルスタック環境では、87％がIPv6を選択）が提供された。

　さらに今年に入り、IETF 98（2017年3月）においても、Appleのエンジニアから、iOS/OS X端末において、IPv6通信を優先する挙動（Happy Eyeballs）について25msの待ち時間を50msに拡大する最新の実装が提案されるなど、20年を経た今も、IETFは、IPv6の仕様や実装に関する最新情報を提供する場として機能し続けている。

IPv6仕様の再整理

　従来、標準化を目指すスタンダードトラックのRFCは、標準化過程のレベルに応じて「Proposed Standard（PS）」「Draft Standard（DS）」「Internet Standard（STD）」の3ステージに分類されてきた。しかし、RFC6410 により、RFCの標準化過程のシンプル化のため、PSとSTDの2ステージへと変更された。

　IPv6の仕様を決めたRFCの一部は、消滅するDSに位置付けられているため、そのままだと自動的にPSに再分類されることとなる。しかし、IPv6の普及が進んできた今、より上位のステージであるSTDに位置付けた方がよいとのことで、STDのレベルを満たすために文章を整理することとなった。

ISOC-JP IETF 93報告会「IPv6関連WG 報告」より

　対象となっているのは、IPv6のコアな仕様を定めている以下の5つのRFCである。

RFC2460: Internet Protocol, Version 6（IPv6）Specification（インターネットプロトコルバージョン6（IPv6）の仕様）
RFC4291: IP Version 6 Addressing Architecture（IPv6アドレス体系）
RFC1981: Path MTU Discovery for IP version 6（IPv6用経路MTU探索）
RFC3596: DNS Extensions to Support IP Version 6（IPv6をサポートするためのDNS拡張）
RFC4443: Internet Control Message Protocol（ICMPv6）for the Internet Protocol Version 6（IPv6）Specification（IPv6仕様のためのインターネットコントロールメッセージプロトコル（ICMPv6））

　このうち、RFC3596、RFC4443については、文面の大きな変更なくSTDに再分類されることがIESGによって承認された（5月26日）。

　他方、RFC2460・RFC4291・RFC1981について、他のRFCによって更新（Update）や訂正（Errata）がされている点、実装上の曖昧な記述が残っている点から、修正版のRFCの策定が進められている。修正版では、文言の修正だけでなく、他のRFCやIANAレジストリへのリファレンスが最新化されており、複雑に絡み合ったIPv6関連のRFCを読み解くにあたってかなりの改善がされている。

　これらの修正版は、2017年2月1日にまとめてIESGのラストコールとなった。しかし、ラストコール以後も6man WGのMLにて数百通を超す議論の応酬が続いており、順調に修正版RFC発行とはいかなかった。RFC2460修正版については、さらにいくつもの文章変更を加え、RFCとして発行される見込みとなったが、RFC4291修正版・RFC1981修正版は予断を許さない状況だ（2017年5月29日現在）。

廃止またはアップデートされる予定の主な仕様

　ここでは、修正版のRFCで取り上げられている主な仕様の変更を紹介する。なお、修正版のRFCは、議論が続いているため、確定したRFCではないことを注意されたい。議論が続いているものについては、その点にも触れて紹介している。

IPv6のタイプ0経路制御ヘッダーの記述の削除（RFC2460の修正）

　RFC2460に記述のあった、タイプ0経路制御ヘッダー（RH0）は、拡張ヘッダーの1つである。RH0を使って、遠隔地の経路のトラフィック増幅ができ、DoS攻撃が成立することが2007年に指摘されており、RFC5095（Deprecation of Type 0 Routing Headers in IPv6）によってすでに廃止されていた。

　このように、廃止された仕様の記述が削除されることによって、修正版のRFCは読みやすいものになっている。

フラグメントIDの予測可能性に関する記述の追加（RFC2460の修正）

　IPv6においては、フラグメント時のフラグメントIDを予測することにより、IPv4における識別番号と同様に、トラフィック量などの情報を第三者が窃取する攻撃が成り立つことが指摘されている。対策のために、予測を困難にするアルゴリズムの例として、2016年に成立したRFC7739（Security Implications of Predictable Fragment Identification Values）への参照が追加されている。

　ただし、IPv4における識別番号はすべてのIPv4ヘッダーに含まれるのに対して、IPv6のフラグメントIDはフラグメントパケットにしか存在しないため、攻撃される可能性はIPv4よりも低いと考えられる。

　また、ここでは紹介しきれないが、フラグメントパケットの仕様に関する記述も大幅に改められている。

UDPチェックサムに関する要求レベルの緩和（RFC2460の修正）

　IPv6ノード発のUDPパケットにおいて、UDPチェックサム計算が必須とされていたが、デフォルト動作であるという記述に緩和された。例外として、トンネリング時のカプセル化処理の際にゼロチェックサムモードが必要とされることが記述されている。これは、現実の問題から広がっている実装に合わせて、仕様が修正されたと言える。

　ゼロチェックサムモードが使われる際のガイドラインは、RFC6936（Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums）にまとまっている。

拡張ヘッダーおよびホップ・バイ・ホップ・オプションの扱いについて（RFC2460の修正）

　拡張ヘッダーは、IPv6に特徴的な仕様だ。IPv6の基本ヘッダーは40バイトの固定長だが、その代わりIPv4でヘッダーに含まれていたいくつかのフィールドが拡張ヘッダーに移されている。だが、ルーターやファイアウォールなどのネットワーク機器において、特定の拡張ヘッダーが含まれていたり拡張ヘッダーが複数個チェインしているパケットが破棄される事象が実インターネット上で観測されているため、その扱いが大きな問題になってきた。

　これらの積年の議論を受け、今回の修正版のRFCでは、

ホップ・バイ・ホップ・オプションの挙動（中継ルーターによる拡張ヘッダーの処理）をする新しい拡張ヘッダーを定義してはいけない
新しい拡張ヘッダーの定義は推奨されない。新しい機能が欲しい場合は、既存の宛先オプションヘッダの利用を推奨する

などの踏み込んだ記述が提案されている。

　中継ノードによる拡張ヘッダーの挿入については、IPSecにおける認証の整合性やPath MTU Discovery（PMTUD）を壊し、深刻な問題を起こす可能性があるため、禁止すべきなどの意見があったが、セグメントルーティングではすでに使われているという背景もあり、IETF 97での投票（ハミング）により、問題があることを指摘する文章にとどまっている。

　また、RFC2460ではホップ・バイ・ホップ・オプションヘッダーを持つパケットは、すべてのルーターで処理されなければいけないという記述だったが、「ルーターにそのようにコンフィグされている場合は」という表現が加えられており、事実上の緩和となっている。

　最終的に、拡張ヘッダーについては、元のRFC2460の理念を踏襲し、中継ノードでは挿入されないという記述になった上で修正版RFCとして発行される予定だが、他のWGからのフィードバックもあり、今後も議論が続くものと予想される。

IPv6のセキュリティ（RFC2460の修正）

　IPv6のセキュリティ面の性質はIPv4と同等であると明記されるようになった。IPv6に関するセキュリティ上のリスクについてよく記述されており、大変よいドキュメントとなっている。また、改ざんや傍受のリスクに対してはIPSecの利用によって緩和されると記述されている。

　なお、IPv6におけるIPSecの利用は、従来MUST（必須）とされてきたが、2011年のRFC6434によってSHOULD（推奨）に格下げされている。

IPv6アドレスの推奨表記（RFC4291の修正）

　IPv6アドレスの表記方法として、a～fのアルファベットを小文字にすることが推奨されているため、ドラフト内のIPv6アドレスの表記がすべて小文字に変更されている。

　また、IPv6アドレスを出力するときの形式として推奨をまとめたRFC5952（A Recommendation for IPv6 Address Text Representation）の内容も、修正版のRFCに含まれている。

サイトローカルアドレスの削除およびユニークローカルアドレスの追記（RFC4291の修正）

　サイトローカルアドレスについては、使用範囲が不明として、元のRFC4291でも「RFC3879によって廃止された」と書いてあったが、修正版のRFCでは、節ごとまるごと削除されるようになった。また、RFC4193で定義されているユニークローカルアドレスについての記載が新たに加わっている。

EUI-64によるアドレス生成の非推奨（RFC4291の修正）

　元のRFCでは、EUI-64によるMACアドレスの生成方法が詳細に記載されていた。しかし、現在ではこの方法は非推奨である。IPv6の特徴としてよく説明に使われてきた仕様であるので、今後のドキュメントには注意を要する。インターフェースID（IID）を利用した端末のトラッキングなどの脅威が想定されており、IIDは、第三者がアドレスを見ても、何も情報が得られないような意味不明なビット列であることが推奨される。

　これらのプライバシーにかかわるIPv6アドレスの新しい仕様は、

RFC7721: Security and Privacy Considerations for IPv6 Address Generation Mechanisms
RFC7217: A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration（SLAAC）

などの新しいRFCにまとまっている。

/64境界に関する記述（RFC4291の修正）

　IPv6ユニキャストアドレスのインターフェースID（IID）が64ビットで固定されていることの利点および可変にしたときの影響について、調査結果が、RFC7421（Analysis of the 64-bit Boundary in IPv6 Addressing）としてまとめられている。この調査を受けて、修正版のRFCでは、「ポイントツーポイントのリンクを除き、すべてのユニキャストアドレス（ただし000で始まるものを除く）のIIDは64ビットの長さであることを要求する」と書かれている。

　しかし、64ビット以外の長さのときにどのような影響があるのか、ポイントツーポイントのリンクでは127ビット長を推奨しているが、過去、64ビット長や126ビット長を推奨するRFCが現れては消えしているので、本当に推奨できるものなのか、などの意見があり、こちらも議論が続いている状況である。