RFCの記述のひどさによる問題・・・

インターネット・プロトコルの多くのものがRFC(Request for Comments)がバイブルになっているのですが、RFCの記述は実に曖昧なものが多いのが困ったものです。もともと他の標準化ドキュメントと異なり、RFCは公開してコメントを受け付けるため、という位置づけだったためなのか、あるいは、単に書き手のスキルの問題なのか・・・。

DHCPに関する記述は、一番中心となっているのが、RFC2131です。これは実際に読んでみるとわかるのですが、冗長な記述で、なおかつ曖昧で、しかも、抜けが多いのです。もともとDHCPの仕組み自体が、BOOTPの拡張であり、後付けでどんどん仕様が追加されたという背景が悪い面もありますが・・・。

DHCPで一番困るのが、サーバ･クライアントが同一セグメントの場合と、別セグメントの場合（リレーエージェントが介在）でかなり動きが異なる点です。一般家庭や小規模オフィスでは同一セグメントで運用することも多いと思いますが、回線事業者や大規模組織では多数のセグメントを1サーバで管理します。

私が開発･販売しているProDHCPは商用で使われることがほとんどで、大規模ユーザがほとんどなため、リレーエージェント経由の動きが重要なケースばかりです。大規模運用ではリレーエージェントに情報付加を行わせ、実に複雑な管理をするケースも良くあります。ケーブルTV網のネットワークなどはかなり複雑な運用をしています。

一方、ProDHCPをOEM提供している製品では、中・小規模向けの製品もあり、同一セグメントでの運用が中心になることもあります。

この二つの動きを両立させるために、実はソースが結構複雑になっている位なのです。。

それはさておき、そんな複雑なDHCPを、曖昧で難解なRFCを基準に各ベンダーがクライアントを作るため、どう考えてもRFCに合っていないリクエストを投げてくるクライアントや、動きが異なるクライアントが存在します。正しくなくても対応できないと困ると言われますので、DHCPサーバとしてもある程度曖昧さを許す作りにせざるを得ません。さらに困るのが、RFCで基準が示されていない場合です。実は上記のリレーエージェントが介在するパターンでは、リース延長に限って直接DHCPサーバにリクエストをすることもできるようになっています（IPv6ではなくなりました）。この動きに関する記述が少ないのです。エラー処理などではそもそも記述が全くない部分もあります。

もう少し何とかならないものですかねぇ・・・って、お前がやれ！って？？