[linux-users:85026] Re: セグメント内に存在するDHCPサーバの検出方法

[Naoto Shimazaki <igy _at_ xxxxxxxx>]

> > RFC1541には、ちゃんと図入りの説明がありま。
> >
> >   ftp://ftp.ring.gr.jp/pub/doc/RFC/rfc1541.txt
> 
> 　出た頃に、一度ざっと見ました。
> でも、実装って、必ずしも　RFC通りに出来てるとは限らないのですよ。
> 大昔、bindが　RFC通りでなくて、驚いた事があります。

未知のバグを持つ実装を想定した議論ではなかったはず。
特定の実装のバグの話をしてたんでもなかったはず。

仕様から導けることがらの議論とバグや仕様違反からくる
ことがらの議論は明示的に分離すべきです。

この件の場合、

1. 仕様通りの動きをする無法 DHCP サーバを見付ける問題。
2. 既知のバグをもつ無法 DHCP サーバを見付ける問題。
3. 未知のバグをもつ無法 DHCP サーバを見付ける問題。

は各々別々の議論になります。まぜちゃだめ。


もう一度考え直してください。

1. DHCPDISCOVER が送信されました。

2. オフィシャルサーバが DHCPOFFER を返します。これ OK。

3. 無法 DHCP サーバが DHCPOFFER を出さなかったら？
	問題発生せず

   では DHCPOFFER を出したら？ (これが問題)
	必ず「DHCPOFFER from 無法サーバ」パケットが
	クライアントと同じコリジョンドメインで見える。
	MAC のソースアドレスがオフィシャルサーバと違うから
	すぐに見分けが付く。
	(ついでに server identifier でも見分けが付く。)

4. クライアントが無法 DHCP サーバに答えて DHCPREQUEST を出したら？
	被害が発生したケース
	DHCPREQUEST はブロードキャストされ、かつ
	server identifier を含むので、これまた見分けが付く。
	しかもこのパケットはブロードキャストドメインで見える。

結論。
問題のあるケースでは無法サーバは必ず尻尾を出す。

つまり、既に提案された方法で十分な効果が期待できる。



あ、それと、

> でも、実装って、必ずしも　RFC通りに出来てるとは限らないのですよ。

ここまで考えるつもりなら、せめて RFC で定義している
用語を使ってくださいな。「確保通知」などの言葉では
バグ持ちの実装を念頭に置く議論をするには曖昧すぎます。

--
Naoto Shimazaki