Re: NT 3.51 dhcp client and server ip address

[David Lapp <[e-mail]>]

Ralph wrote:
..
> We can either fix it or leave it:
> 
..
> 
> Discussion?
> 
I think that we should "leave it". So far I haven't heard many 
arguements for fixing it (by changing the protocol) beyond that it
makes the implementation of redundant servers easier. I don't see this
as a strong enough reason to make a fundamental change to the protocol
at this time.

Obviously, we need to clarify this detail but I agree with Mike, if 
that means reseting the clock on issuing a new RFC then lets put it 
in a seperate clarification RFC. At the very least it has been a long
time since the "current" RFCs were issued. There are people out
there who seem oblivious to the IETF, its standards process and
its working groups. They are using the existing RFCs to implement
DHCP. draft-08 is much changed and much improved over the RFC.
Even without this clarification I think it is better to have a 
new RFC out there for people to use.

If we can change the current draft and still issue it as an RFC
what should it say ?

_MelloN_ has suggested:
>
>       If the DHCP Server and the DHCP Client are connected to the
>       same subnet, the Server Identifier SHOULD be the IP address
>       the server is using for communication on that subnet.   If the
>       server is using multiple IP addresses on that subnet, any such
>       address may be used.   The Server Identifier MUST be an IP
>       address to which the client may unicast a TCP packet using
>       routing information it has obtained using the DHCP routers
>       option.   DHCP Clients MUST use the IP address provided in
>       the Server Identifier option for any unicast requests to the
>       DHCP Server.
>
and Ken Key suggests changing the first sentence to:
>
>       The Server Identifer SHOULD be the IP address of the of interface
>       on which the DHCP Server heard the request.
>
to which _MelloN_ responded:
> I think this wording is too general.   By having different wording for
> locally-connected clients and clients on subnets to which the server
> is not directly connected, we avoid implying that the DHCP server
> needs to be making general routing decisions.   The DHCP server
> already needs to make rudimentary routing decisions for
> locally-connected clients, but currently can safely punt routing
> decisions for remote clients through the standard kernel IP layer.

I think that I must have missed your point. Doesn't "The Server 
Identifier MUST be an IP address ... routers option." imply that 
the server is making some general routing decisions and further
more making them from the client's point of view ? I think that the 
server can stick to choosing the identifier based on the interface
on which it recieves a request. I'd suggest something like:

	When selecting a Server Identifier to place in a DHCPOFFER
	the server SHOULD use the IP address which it uses for
	communication on the subnet connected to the interface on
	which it received the request. If the server is using multiple
	addresses on that interface and the address being offered to
	the client is in the same subnet as one of those addresses
	then the server SHOULD use that address in the Server Identifier.
	If the server is using multiple addresses on that interface and
	the address being offered to the client is not in the same subnet
	as one of those addresses then the server MAY use any of the
	addresses for that interface.  DHCP Clients MUST use the IP 
	address provided in the Server Identifier option for any 
	unicast requests to the DHCP Server.
	
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.

Dave Lapp