Re: NT 3.51 dhcp client and server ip address

[Ken Key <[e-mail]>]

Greetings!

> There should be no tacit design decisions in a protocol specification.

I completely agree.  As we've all found out in implementing via the RFC's
there are a number of situations that weren't covered, hence why we
are working on the new draft.  I don't see anything on this particular 
issue in the -08 draft.  Ralph, are we too far along in the IESG 
approval process to try to add clarifying language to the -08 draft?  
I think we but I am not up to date with the current IESG approval process.

> If the server has multiple IP addresses, either because it is
> multihomed, because it has aliases, or because it is operating on a
> physical network with multiple logical subnets, there is no
> unambiguous way to interpret the protocol specification.

Very true.

> It is not always safe to assume that one IP subnet is reachable from
> another.   What if the DHCP server is also a firewall, but serves
> clients on both sides of the firewall?   Which of the firewall's two
> (or more) IP addresses should be used in the server identifier?
> 

I contend that it should be "the" IP address of the interface it is going 
out of.  There is still the issue of multiple logical interfaces on 
a single physical interface.  This is very similar to the giaddr issue
with BootP forwarders.  One possible solution is that the server can 
pick a "primary" interface.  Another is that it can pick which logical
interface is proper interface based on the offered IP address and pool.

> If the IP address of the interface through which the packet is being
> sent must be used as the server identifier, then the specification
> should say so.   There are very strong reasons for wanting to
> use a consistent server identifier on a multi-homed DHCP server.   

I have some ideas where a singular server identifier might make developing
a server redundancy protocol easier, but nothing that I can catagorize
as strong.  What sort of things am I missing?

> If
> this is not permissible, or not recommended, the specification should
> say so.

Agreed.

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.