Re: NT 3.51 dhcp client and server ip address

[Ted Lemon <[e-mail]>]

>   * Fixing will delay the advancement to Draft Standard, as it would
>     represent a fairly basic change to the behavior of clients and
>     servers.
>   * Leaving it leaves the problem with multiple identifiers for a single
>     server - as pointed out by Ted - unfixed.

I think it's too late at this point to undo the overloading.   There
are far too many dhcp clients out there which believe that the server
identifier is the address to which they should unicast DHCPREQUEST
messages.

Are you saying that adding language to make explicit the currently
implicit overloading of the server identifier option will delay the
advancement to Draft Standard, or are you saying that undoing the
overloading will delay it?  If the latter, and if we can add the
clarification without introducing a major delay, I think it's worth
doing.  When I read the protocol specification, I completely missed
the implicit overloading, so I would like to believe that it's not
obvious.  :')

I guess one question is, how do we want to fix this?   My first take
on a clarification which has minimal implementation implications is:

	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.

This avoids *requiring* that the Server Identifier be the most
directly reachable IP address belonging to the server, while
suggesting that it should be, which means that existing
implementations that do not do this are not non-conforming except when
run incompletely-connected networks.

I don't see any way to avoid requiring the DHCP Client to use the
Server Identifier for unicasts - as several people have pointed out,
using the IP source address won't work in the case that the request
has come through a BOOTP relay agent.

			       _MelloN_