Subject: siaddr vs sname vs option 66

From: [email-masked]
Date: Thu, 6 Apr 2000 12:02:36 -0700

i think i have discovered an error in rfc 2132, in the section on 
option 66. there's an inconsistancy, at any rate.

here's what 2132 has to say:

> 9.4 TFTP server name
> 
>    This option is used to identify a TFTP server when the 'sname'
>    field in the DHCP header has been used for DHCP options
> 
>    The code for this option is 66, and its minimum length is 1.

it seems that the intent is to provide a way to communicate the 
information that the sname field carries when sname has been 
overloaded using option 52.

however, the quote above also implies that sname, when not 
overloaded, carries the name of the tftp server. this does not agree 
with what other rfcs have to say on the subject. rfc 2131 says this:

> 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.

seems pretty clear that siaddr is supposed to be the tftp server 
name. 2131 doesn't really say anything about the meaning of 
sname when it's not overloaded, however, the original bootp rfc 
(951) says:

> If the client wishes to restrict booting to a particular server
> name, it may place a null-terminated string in 'sname'.  The
> name used should be any of the allowable names or nicknames of
> the desired host.

sname is for client-to-server communication, to restrict booting to a 
particular host. i can find no mention of any meaning for this field if 
it's set in a packet sent by the server.

so given all this, i have the following questions:

what field should contain the tftp server name/address: siaddr or 
sname?

if not blank or overloaded, what is the meaning of sname in a dhcp 
discover or dhcp request?

if not blank or overloaded, what is the meaning of sname in a dhcp 
offer or dhcp ack?

is option 66 supposed to be a replacement for sname if sname is 
overloaded? or is it supposed to really be the tftp server name, as 
described in the first quote above?

if option 66 really is the tftp server name, is this meant to replace 
siaddr? if both are set in a dhcp ack, which should the client use?

"For, I say fortunately, I always carry a spare set 
of feathers."
  --Foghorn Leghorn

---

From: [email-masked] (Greg Rabil)
Date: Thu, 6 Apr 2000 15:47:19 -0400

Clausen,
As I've been down this road myself, let me try to explain what I've found...

Regards,
Greg

A. Gregory Rabil
Team Leader - Network Services Development
IP Services Product Group
Lucent Technologies, InterNetworking Systems
[email-masked] [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Thursday, April 06, 2000 3:03 PM
> To: DHCPv4 discussion list
> Subject: siaddr vs sname vs option 66
>
>

Nearly all clients that I know of will look in the siaddr for the address of
the TFTP server.  This includes Bootp clients as well as newer DHCP clients
that also require TFTP images for bootstrap.

> discover or dhcp request?

Nothing that I know of.  I don't think this value will ever be filled in by
a client or relay agent.

> if not blank or overloaded, what is the meaning of sname in a dhcp

That's a good question.  Typically, I put the _name_ of the TFTP server,
just to be "compliant" with how I understand the field to be in the protocol
(which you've discussed above).

> described in the first quote above?

Option 66 is _supposed_ to be the sname, if the sname field has been
overloaded with options.  However, Microsoft's server will always put the
TFTP server name in option 66, so many client vendors have coded to this.

> siaddr? if both are set in a dhcp ack, which should the client use?

Again, I've yet to see a client that actually uses the sname, they all seem
to rely on siaddr, or option 66 in the case where they've only tested with
MS-DHCP.