A DHCP question from a PhD student...

[Yaron Weinsberg]

thanks for the quick response. I see your point but still
I am amazed by the fact that the RFC authors thought about
this few years before IEEE 1394...

thanks!

Yaron.


still, since DHCP RFC

On 1/5/06, David W. Hankins <David_Hankins at isc.org> wrote:
> On Thu, Jan 05, 2006 at 12:12:35PM +0200, Yaron Weinsberg wrote:
> > I hope you can help me out  here with the following question:
> > (I am a PhD student who teaches DHCP among other things)
> >
> > what is the purpose the transaction id in the DHCP packets?
> > the rfc say that it is used to correlate requests and replies but the client
> > can ALWAYS check the "chaddr" (client hardware address) to verify that
> > the reply is for him.  Even if a client sets the broadcast bit, the chaddr will
> > always contain the target mac address...
>
> Only where chaddr is relevant.
>
> Look at RFC2855 (DHCP for IEEE 1394).  The htype is 24, the hlen is
> required to be zero (I'm fuzzy on 1394 mechanics, so I'll leave why
> as an excercise for the reader).  Essentially, no address.
>
> In this case the client can only tell the difference between broadcast
> replies using the xid.
>
> The chaddr's relevancy is also diminished in the case where the client
> is not identified by it - when the client supplies a client identifier.
> If the client were to have more than one transaction in the air at a
> given time, each with a different client identifier, it could only
> segregate between responses from the server on the xid (the client
> identifier option is not usually echo'd back by the servers).
>
> --
> David W. Hankins                "If you don't do it right the first time,
> Software Engineer                       you'll just have to do it again."
> Internet Systems Consortium, Inc.               -- Jack T. Hankins
>
>