Re: NT 3.51 dhcp client and server ip address

[Ken Key <[e-mail]>]

Hi Folks

Ted writes:
> 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.

I have to agree (but then I'm biased as I've already got code in the field).

> 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.  

Agreed.  If just adding clarifying text means we get reset back to Proposed 
standard and have to go through that long IESG review again then I have to 
agree with Mike and address this in a clarifications document.

> When I read the protocol specification, I completely missed
> the implicit overloading, so I would like to believe that it's not
> obvious.  :')

It's not obvious on the server side.  On the client side, the implementor 
gets left scratching his/her head wondering what to use to unicast to 
the server and the connection gets made.  I got lucky and implemented 
a client first  :-)

> 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.
> 

Pretty good, but the first sentence sounds like it only applies with the 
two entities are on the same "wire".  The firewall scenario you raised
suggests that needing to use the IP address on the interface it comes 
in on is true with remote forwarded requests as well.  How about a first 
sentence that was just the following and we keep the rest of the paragraph
intact?

	The Server Identifer SHOULD be the IP address of the of interface
	on which the DHCP Server heard the request.

> 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.

Sound like a good answer to me.

regards,
K^2
--
Ken Key    ([e-mail])  | cisco Systems, Inc.   | (Formerly TGV, Inc.)  
[phone] (voice) | 101 Cooper St.        | We are Borg of cisco.
[phone] (fax)   | Santa Cruz, CA  95060 | Prepare to be assimilated.