Re: NT 3.51 dhcp client and server ip address

["John M. Wobus" <[e-mail]>]

David Lapp writes:
>...	
>No matter how hard we try the possibility will always exist that the 
>client's unicast messages won't be able to reach the server. There 
>is *some* guarantee that the client's broadcast renewal will reach 
>the server. After all its initial broadcast DISCOVER did. 
>
>The one thing that the server knows about the client's connectivity is 
>that the client's request somehow reached the server on a particular
>interface. I think that the best that we can do is attempt to point 
>the client to that interface/subnet.
>

I agree.  It seems that DHCP relaying will only work in a subset of IP
environments, but one which includes a very large majority of IP
networks.  Thus the "right" way to allow DHCP servers to function
without being "route/network omniscent" is to specify that "subset of
IP networks that supports DHCP relaying" in a practical manner.  In
other words, if the RFC says the server places in the siaddr field, the
IP address of the interface through which it received the relayed
request, then ideally the RFC should also say something like this:

 The DHCP relay function presumes that when the DHCP/BOOTP relay relays
 a DHCP packet to the DHCP server, the packet's destination address is
 one that the client can use to reach the DHCP server.

I leave it to Ralph to judge whether it makes more sense to defer such
a clarification to a subsequent RFC.

I suppose firewalls might be a source of such concerns.  Another
problem configuraton would be a multi-homed non-routing BOOTP relay
with a connection to a multi-homed non-routing DHCP server via a
separate IP network.  I suspect other examples might be constructed.

-John Wobus