Re: NT 3.51 dhcp client and server ip address

[Shawn Mamros <[e-mail]>]

>A simple way to rephrase the question would be: should the client
>unicast DHCPREQUEST packets to the IP address in the Server Identifier
>option, or should it unicast these packets to the IP source address
>from which the last DHCPACK came?

It should - no, make that MUST - use the IP address in the Server
Identifier option.

The IP source address is *not* always reliable.  Think about the case
of a relay agent implementation that isn't a router.  I don't think
there's any requirement anywhere that a relay agent must preserve the
server's IP source address.

Yes, this ultimately does mean that a multihomed DHCP server MUST be aware
of all of its interfaces, and MUST keep track of which interface a request
is received on, so that it can put the proper IP address into the Server
Identifier option for the reply.  It's the same issue that a relay agent
faces when it has to figure out which address to write into giaddr, and
it's not altogether unrelated to the issue of what a DHCP server has to
do to support multiple logical IP networks on a single physical LAN.
And it's not as if DHCP is the only type of service that has to be aware
of the possibility of a multihomed server; if I'm not mistaken, the BIND
implementation of a DNS server also keeps track of all of its interfaces,
so that it sends its replies from the proper interface.

In terms of the client being able to get its unicasts back to the server:
ideally, the configuration information that is delivered back to the
client SHOULD provide for a route that allows unicasts to the Server
Identifier address.  I say SHOULD, not MUST, because even in the worst
case of a client being unable to successfully unicast back to the server,
it will ultimately revert to Rebind state and begin broadcasting instead.
In fact, a good client implementation arguably SHOULD check to see if a
route is available when unicasting (either beforehand, or as a result of
a Host Unreachable/Network Unreachable type error return from a unicast
attempt), and if there is none, broadcast the renewal instead.

As for the language in the RFCs/drafts that we have: indeed, if the
language isn't clear, let's make it clear.  I'm going to spend some
time this morning looking at the existing draft language, and will
write back with what I find.

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