Re: NT 3.51 dhcp client and server ip address

[Ken Key <[e-mail]>]

> 
> > Pretty good, but the first sentence sounds like it only applies with the 
> > two entities are on the same "wire".
> 
> That's correct.
> 

But the SHOULD is applicable to both situations.  In both cases, it is
an implementation suggestion to minimize problems with multi-homed hosts
on partitioned networks.  It's not a MUST as your third sentence deals 
with what minimally is required to be functional.  However, it should 
be a SHOULD for the remote case as an explicit suggestion to implementors 
just like it should be a SHOULD for the local case.  My first crack and
rewriting the 1st sentence was to clone it for the remote case.

> > 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.
> 
> That's what the third sentence is for:
> 
> > >	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.   
> 

My parse on this is that the sentence describes the server identifier 
for the client to be able to communicate with the server.  It is applicable
to both scenarios (routing to the local wire is still routing).

However, it combines items from two realms.  The  Server Identifer, which 
I feel should be controlled at the Implementor's level, and the client's 
routing information which is at the Administrator's level.  Unless the 
server can learn the full routing topology (with filtering knowledge), 
the server cannot make the determination of the absolute proper Server ID
for itself.  Taken in the other direction, this means the administrator 
potentially has to be able to determine what the appropriate Server Identifier
 to use for each host that is being configured.  This is not something I 
would trust the Administrator to get consistantly right.  

By using the IP address of the interface that the remote packet comes in
on, we reduce the number of partitioned network scenarios where this is
the wrong choice and the administrator hoists themselves by their own
petard.  Sure, theres the scenario where the forwarder is filtered from
interface A and the client is filtered from interface B and other asymetric
routing/filtering situations.  However, in DHCP implementations, those are 
very minimal.

> > 	The Server Identifer SHOULD be the IP address of the interface
> > 	on which the DHCP Server heard the request.
> 
> I think this wording is too general.   

And my complaint was that the other wording was too specific :-)

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

It's the same decision as done at the local level, unless the listener
for forwarded packets uses a different mechanism that the listener
for local packets.  That's why I cover it with only a SHOULD.

> For some servers, this is probably a moot point, but for servers
> running on unix-like operating systems, we need to be more careful.

As I'm working on multi-homing my uni-homed only UNIX DHCP server, I believe
understand where you are coming from.  That's why I want it to just be 
SHOULD (just as I wanted the all-ones B'cast to just be SHOULD).  But I
do feel that it is generally preferable in the remote case to use the IP
address of the interface the request came in on, if possible, to minimize
the number of scenarios where the user can hurt themselves.  I have
problems just getting my users to understand BootP forwarding.

I've probably beaten up on this very minor point too much.  I'll be
quiet from now on.  Ted's wording is a good clarification.

See you folks in San Jose,
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.