Re: Re: Re: [Etherboot-users] [PATCH] ISC dhcpd siaddr (next-server) zero default change in 3.0.2

On Sep 16, 2005, at 7:28 AM, Geert Stappers wrote:
> On Thu, Sep 15, 2005 at 06:11:23PM +0200,  
> [email protected] wrote:
>>> On Sep 14, 2005, at 7:35, Marty Connor wrote:
>>>> On Sep 14, 2005, at 8:36 AM, Harald Welte wrote:
>> RFC2131 (http://rfc.net/rfc2131.html) says:
>>>   DHCP clarifies the interpretation of the 'siaddr' field as the
>>>   address of the server to use in the next step of the client's
>>>   bootstrap process.  A DHCP server may return its own address in  
>>> the
>>>   'siaddr' field, if the server is prepared to supply the next
>>>   bootstrap service (e.g., delivery of an operating system  
>>> executable
>>>   image).

Note that is says "A DHCP server may return its own address..."

I believe that the the word "may" in RFCs means that it "may" or "may  
not".  If it had said "A DHCP server must return its own address..."   
that would mean that all conforming DHCP servers were required to to  
so.  That is my interpretation of the intent.

> Thanks for posting  it here ( I didn't have time to review RFC 2131 )
>> So the main question is: What is meant by "next step of the client's
>> bootstrap process"?
> Example given: Delivery of an operating system executable.
>> I guess the correct behavior would be using 'siaddr' for the TFTP- 
>> Server
>> but not for the DHCP-Server. I don't think it would make sense to  
>> send
>> DHCPREQUEST (Reply to DHCPOFFER) to the server in 'siaddr' which  
>> could
>> be another machine than the sender of DHCPOFFER. This message should
>> IMHO always be sent to the DHCP-Server in 'server identifier'.
>>
>> Later, after finishing DHCP, the next step in the bootstrap process
>> is TFTP. So 'siaddr' should be used here.
>>
>> This is necessary if the DHCP and the TFTP server are different
>> hardware.

> Please implement the proposal that was posted in another message
>  Drop the DHCP offer and wait for DHCP offer that a non-zero siaddr.

I recommend that he do what he believes is correct for his particular  
situation, and for his user community.

>> I think defaulting to the DHCP server is much more convenient.

We may well do this.  I'd like to talk to a few more people before  
committing to it.

> And I think it is a lie to say in a poor configurated DHCP server
> that the same hardware is also a TFTP server. The right thing is
> to tell in the DHCP server where the TFTP server is.
  ...
> So doing the right thing is this time easy  :-)

A well-established behavior and convention was suddenly changed,  
affecting a large installed base of clients.  We need to proceed  
cautiously.

What we implement in Etherboot, once flashed into firmware (or  
committed to any media) becomes harder for people to update, so we  
should be a bit careful.

I appreciate your firm opinions on this, but let's take a little time  
to decide this carefully.

Marty




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php