Re: NT 3.51 dhcp client and server ip address

[Kim Kinnear <[e-mail]>]

 

Ralph asked for discussion, so ...

It seems to me that "fixing" (as implicitly defined by Ralph below)
requires some addition to the protocol (e.g. a "return address"
field).  Such a "fix" will not only delay advancement to draft
standard, but create what I could only describe as a "mess" in the
field.  There exist a considerable number of implementations of both
DHCP clients and servers -- it will take years for their respective
owners to update them to the new behavior.

The alternative to the above --  what Ralph called "leaving it" --
involves adding some words to the RFC describing behavior that many
(perhaps even most) implementations have already adopted -- and which
isn't a big problem in any case.

In our DHCP server implementation we did exactly what Mike Carney of
Sun did -- we send back as a server identifier the IP address of the
interface from which we received the request.  We also will recognize
as "us" *any* of the interfaces to which we are connected when we
receive a server identifier in a client request.

Adding words to the RFC to make this the defined behavior seems
straightforward and far from terrible.

The behavior we and Mike have described will have to remain even if we
were to change the RFC (i.e.  "fixing" it), until all of the clients
are updated to the newly standard behavior.

>From my standpoint, the fix is worse than the problem  -- since we
would have to support both approaches simultaneously.

While having multiple server identifiers *could* complicate the
server-server protocol spec, now that we are forewarned about this
issue, I would think that we could work around that problem.


Cheers -- Kim


> 
> At 6:54 PM 12/3/96, Ted Lemon wrote:
> >In general, it just seems like a bad idea to
> >have multiple identifiers referring to the same object.
> 
> Yeah - looks like we blew it by overloading the "identifier" field to also
> act as the "return address" field.
> 
> We can either fix it or leave it:
> 
>   * 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.
> 
> Discussion?
> 
> - Ralph
> 
> 
> 
>