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

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

本稿では、 IPv6の普及に伴い新たな利用方法が生まれつつあるDHCP (Dynamic Host Configuration Protocol)について、検討を行っているdhc WGを中心にIETFでの議論の動向をご紹介します。

IPv6時代のDHCP

DHCPは、インターネットの初期から使われている「枯れた」プロトコルですが、最近ではIPv6の普及に応じた新しい利用法が注目されています。今回の報告でもご紹介する、一種の移行技術としてのDHCP 4o6がその一例です。また、IPv6の広大なアドレス空間を活かすために、末端のホストにもDHCPでプリフィクスを配布するという利用方法も提案されています。

IETFでのDHCP関連の議論は、 dhc (Dynamic Host Configuration) WGで行われています。現在、dhc WGは主にIPv6用のプロトコルである、 DHCPv6の拡張機能の標準化について議論しています。具体的には、現状の基本プロトコル仕様であるRFC3315に、 ISP等から家庭やオフィスネットワークにプリフィクスを自動配布する仕組みとして使われているprefix delegation (RFC3633)を統合した形の改訂仕様策定、冗長化のためのフェイルオーバー機能の標準化、セキュリティやプライバシー改善のための拡張機能の標準化などが対象となっています。

以降では、このdhc WGの議論を中心に、 DHCP関連の動向をご紹介します。

DHCP 4o6 Hackathon

IETF Hackathonは、IETF直前の土日を使って、策定中の最新プロトコル機能を集中的に開発するという派生イベントで、第92回IETFから継続的に開催されています。 dhc WGとしては前回に続いての2回目の開催で、今回は、 IPv4のホスト設定プロトコルとしてのDHCPv4を、 DHCPv6のオプションとして定義することでIPv6ネットワーク上で動作させるという、 DHCP 4o6プロトコル(RFC7341)がテーマとして選ばれました。筆者もこのイベントに参加し、Hackathonで開発の主対象であった、 Internet Systems Consortium (ISC)が従来のISC DHCPサーバに替わる新たなDHCPサーバとして開発中の、 Keaサーバの開発を手伝ったほか、自作のクライアント実装を用いてKeaとの相互接続性も検証しました。短時間でしたが、最低限の相互接続性まで確認でき、また個人的に以前から興味のあったKeaサーバの実装や設定方法などの理解が深まったこともあり、 WGとしても個人としても有意義なイベントになったと思います。

“running code”を重んじるというのが建前だったはずのIETFも、仕様先行の悪癖が目立って久しくなっていますが、このHackathonのようなイベントや、ドラフト仕様への実装状況の記載を推奨する動き(RFC6982)など、 IETFを「手を動かす」エンジニアの集まりとして再構築しようとする試みは、筆者自身も開発者なので嬉しく思います。

dhc WGミーティング

次に、11月5日(木)午後に開催された、 dhc WGのミーティングの概要をご紹介します。まず、もっとも時間をかけて議論された、 2件の発表について詳述します。

1. Relay Initiated Release

この提案は、米Juniper社のSunil Gandhewar氏によるもので、 DHCP (IPv6とIPv4の両方)のクライアントが、アドレスその他のネットワーク資源を割り当てられたまま移動してしまったような場合に、クライアントに代わってリレーエージェントから、それらの資源を解放できるようにするというものです。これにより、 (特にIPv4の場合)割り当て用アドレスプールの利用効率を上げたり、サーバが管理する状態を減らして、負荷を下げたりすることを目的としています。今回のIETFに先立って、個人ドラフトからWGドラフトとしての採択の是非がMLで議論されている中での発表となりました。

当初ML上では、おそらくすでにこの機能を独自仕様として用いている製品のユーザーと思われる人たちからの賛成が相次ぎ、そのまますんなりと採択されるかのように見えました。しかし、資源の「リース」という、 DHCPにおける根本的な概念の性質(リースは有効期限で管理され、その間割り当てを受けたクライアントはその資源を利用できると仮定できる)を覆す提案であることから、提案への懸念を表明する声も多く上がるようになりました。

ミーティングにおける発表と質疑応答でも、相反する二つの立場がぶつかる形となりました。提案の著者は、独自に集計した統計情報などから、サーバが保持するクライアントの状態数が膨大になり得ることや、自ら解放メッセージを出すクライアントがほとんど存在しないことなどを理由として、提案の必要性を訴えました。一方、この拡張の悪影響を懸念する人からは、クライアントが実際にリソースを保持している期間などの統計がなければ、リレーエージェントによる解放が安全かどうかはわからないといった指摘が挙がり、結局、明確な合意は得られませんでした。なお、会合後に現時点ではWGドラフトとしての採択は見送るとの結論が、 WGのチェアからMLにて通知されました。

2. Moving forward on Secure DHCPv6

Secure DHCPv6とは、公開鍵方式によるDHCPv6クライアント・サーバ間の認証プロトコルです。 RFC3315で規定されている、共有鍵方式のプロトコルの置き換えとして提案、議論されてきました。なお、筆者もこのドラフトに共著者として関わっています。 Secure DHCPv6のドラフトは、すでにWGのラストコールを終え、 IESGでのレビューにかけられる直前の状態となっていたのですが、この段階で担当のarea directorやセキュリティの専門家による事前レビューで多くの懸念が指摘され、差し戻された形になっていました。指摘事項は主に、このプロトコルの利用シナリオが不明確であること、厳密な安全性を犠牲にして利便性を求める“TOFU (Trust on First Use)”モードが安易に導入されていること、の2点でした。

一方、 IETF全体でプライバシーを重視する動きが高まっているのに呼応する形で、 DHCPv6に暗号化機能を導入する提案も、独立した個人ドラフトとして提出されていました。この提案は、Secure DHCPv6のオプションを一部利用しており、その意味では関連する技術となっています。

そこで、WGのミーティング前に、これらのドラフトの著者、 WGチェア、セキュリティ技術の専門家などの関係者による小規模な非公式ミーティングを開き、今後の方向性を話し合いました。その結果、このグループ内では以下の方針で合意されました。

認証と暗号化機能を単一ドラフトに集約し、(このプロトコル内では)暗号化を必須とする
TOFUモードはこの単一ドラフトの対象外とする
利用シナリオはプロトコルとは別なドラフトで扱う

公式のWGミーティングでは、チェアがこの経緯を説明し、暗号化ドラフトの著者である清華大学のLishan Li氏が、統合プロトコルの概要を紹介しました。参加者からは大きな反対の表明や問題点の指摘もなく、提案した方向性はすんなりと受け入れられました。 DHCPv6のプロトコルそのものとはやや独立した話題のため、そもそもあまり興味を持たれていなかったという面もありそうですが、チェアを含めて「声の大きい」人を交えて事前に意見のすり合わせをしていたのが、奏功した例だと言えるでしょう。 IETFのミーティングは議論に十分な時間が与えられないことも多く、また単純な誤解などから大きく「炎上」してしまうようなことも珍しくないので、このように事前に話を付けておくという手法はしばしば取られています。

3. その他の発表

前記2点の発表以外に、 dhc WGミーティングでは以下の発表が行われました。タイトルと概要をそれぞれご紹介します。

YANG Data Model for DHCPv6 Configuration:
DHCPv6の設定情報を、IETFの標準モデル言語であるYANG (Yet Another Next Generation)を使って記述するという提案です。現状では、基本的に進捗報告のみです。
DHCPv6 Failover Update:
DHCPv6サーバ冗長化のための、フェイルオーバープロトコルの仕様ドラフトです。 80ページに及ぶ大きなドキュメントで、レビューの負荷が問題になりそうです。
DHCPv6 Prefix Length hint issues:
prefix delegationでクライアントから通知する、プリフィクス長の扱いの曖昧さに伴う問題を指摘して、処理の指針を提案しています。 WGドラフトとして採択されそうです。
DHCPv6bis update & issues discussion:
RFC3315の改訂仕様(前述)の現状報告です。改定項目はWeb上のissue管理ページにまとめられていて、随時MLなどでWGとして議論して改訂が進められています。