Re: NT 3.51 dhcp client and server ip address

[Shawn Mamros <[e-mail]>]

After reading through draft-ietf-dhc-dhcp-08.txt and the other relevant
RFCs w.r.t. how a DHCPv4 client determines the server's IP address for
use in later unicasts for renewal DHCPREQUESTs, and what a multihomed
DHCPv4 server should use for the Server Identifier option, I have to
conclude that the language is not entirely clear, though there are
some "hints" as to what the behavior needs to be, IMO.

The dhcp-08 draft does include the same language which Matt Crawford
noted from RFC 1541, w.r.t. what should be placed in the Server Identifier
option:

2. Protocol Summary
[...]
   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).  A DHCP server always returns its own address in the 'server
   identifier' option.

No mention is made of *which* of its own addresses a multihomed server
should use.  The only mention anywhere in the draft of the possibility
of a multihomed server comes later:

4.1 Constructing and sending DHCP messages
[...]
   DHCP uses UDP as its transport protocol.  DHCP messages from a client
   to a server are sent to the 'DHCP server' port (67), and DHCP
   messages from a server to a client are sent to the 'DHCP client' port
   (68). A server with multiple network address (e.g., a multi-homed
   host) MAY use any of its network addresses in outgoing DHCP messages.

I suppose one could read this and conclude that it doesn't matter which
address is used, though that isn't explicitly stated as such either.

In terms of what the client uses for the destination address in a unicast,
there is no language anywhere that explicitly states what that should be.
However, the client is required to use the Server Identifier option for
other purposes:

4.4 DHCP client behavior
[...]
4.4.1 Initialization and allocation of network address
[...]
   The client collects DHCPOFFER messages over a period of time, selects
   one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
   messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
   from the previously used server) and extracts the server address from
   the 'server identifier' option in the DHCPOFFER message.  The time
   over which the client collects messages and the mechanism used to
   select one DHCPOFFER are implementation dependent.
[...]
   If the parameters are acceptable, the client records the address of
   the server that supplied the parameters from the 'server identifier'
   field and sends that address in the 'server identifier' field of a
   DHCPREQUEST broadcast message.  [...]

Note how mention is made of the "server address" here, though the only
use of it is for the subsequent DHCPREQUEST broadcast accepting the OFFER
in question.  However, I suspect that most client implementors (myself
included :-) are using this address as the destination address for
renewal unicasts as well.  After all, why scrounge around in the IP header
for an address, when you already have what should be "the" server address
in the Server Identifier option?  The client neither knows or cares
whether the server is multihomed.

Indeed, if one does try to use the source IP address from the server's
message as the destination address for a unicast, that is not guaranteed
to be the same as the server's IP address, due to the potential presence
of a relay agent.  The governing document for relay agent behavior is
RFC 1542, section 4, which does not state anywhere that the source IP
address has to be preserved; it only guarantees that the "BOOTP fields"
must be preserved intact, not the IP header.  One could envision a
simple-minded, non-router relay agent that fully complies with RFC 1542,
yet which is unable to stamp a relayed server reply with any source IP
address other than the relay agent's own.

Certainly, adding language to the DHCP draft which clarifies all of
this couldn't hurt.  I'd like to see a new section added for "Use
of DHCP in servers with multiple interfaces", just as there is one
for clients (section 3.6 in the dhcp-08 draft), and some clarifying
text in section 4.4.4 ("Use of broadcast and unicast", under "DHCP client
behavior") that states how a client should derive the destination address
for unicast renewal messages.

-Shawn Mamros
E-mail to: [e-mail]