Subject: Re: README: changes to config, to support dump device configuration
To: Matthias Drochner <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 06/17/1997 02:08:14
First, I agree completely that the kernel default should be to
use only BOOTP-compatible requests. Does that make you happy?
>What's the advantage? BOOTP already supports a filename
>field. Do you see a use for the other DHCP extensions?
Yes, I do. First, DHCP supplants the earlier BOOTP standards and
extensions. It is pretty much completely an upwardly-compatible
extension. (In fact I would be suprised if the dhcp filename option
was different from the BOOTP option.)
If you *want* the client to use DHCP, you're probably better off with
the kernel getting a lease in the first place, rather than a bootp
address. This may be increasingly important as IPv6 continues to
underwhelm, and more sites insist that clients use DHCP leases, rather
than BOOTP fixed or addresses. *That* is the key point.
Also, are we talking about PROM boot code in ethernet cards, or the
in-kernel code for root-on-NFS that configures the kenerl's network
stack? Those aren't always the same.
Even if we configure a "filename" in the bootp/dhcp server, that may
not be the same name that the bootproms used. (For instance, they may
have used RARP/TFTP and a filename consed up from the RARP'ed IP
address, for all we know.)
>The BOOTP protocol is used here, isn't it?
>It's good that one server can handle both protocols,
>but if you really use the DHCP protocol for the requests,
>you _need_ a DHCP server. With BOOTP you have the
No, not really. You only have the choice of which *erver* to use. A
BOOTP client restricts you to using only BOOTP requests. If you're
stuck with a DHCP server that doesn't want to give out BOOTP-style
fixed addreesses, then your bootp client loses.
A well-behaved DHCP client can send either.
>I have good reasons to stick with a bootp server: ease of
>configuration, the bootfile name lookup semantics and
>a (self-made) special multi-subnet support which would
>be a hardship to port.
Martin, if your multi-subnet support can forward BOOTP requests and
responses, across multiple subnets, then it can forward DHCP requests
and responses. The packet formats are basically the same. The
forwarders need not know or care if they're forwarding bootp or dhcpd.
``Ease of configuration'' is subjective issue of personal taste.
>(And: DHCP smells like PC :-)
No, it doesn't smell like PC at all. DHCP smells like BOOTP, with
nearly a decade of experience and improvements and bugfixes. The I-D
process goes back years, before Microsoft's push with Win95. And the
dchpd in our tree smells, well, just like named, actually. (both are
from the ISC.)
I guess even the minons of His Gatesness sometime onto a good external
standard. Must be due to epilepsy.