Re: [dhcwg] "client identifier" in server replies

On Tuesday 08 July 2003 12.01, narasimha.nelakuditi@nokia.com wrote:

> Choosing random xid may reduce the chances of clashing, but won't eliminate
> the problem. I feel, to ensure correct protocol operation, DHCP servers
> should return "client id" also in their replies.

Filling out chaddr and htype *will* eliminate the problem. As long as client 
id is also present, the device will be identified with client id (which is 
the preferred identifier).

Barring that (and it shouldn't be barred), randomizing xid is not the only way 
to reduce clashes. Timing & relay segmentation further reduce the probability 
of a clash. And unicast responses, when received, are guaranteed to be for 
you.

Instead of changing DHCPV4, change the client to use both client id *and* 
htype/chaddr.

- Bud

> regards,
> swamy.
>
> > -----Original Message-----
> > From: ext Bud Millwood [mailto:budm@weird-solutions.com]
> > Sent: Tuesday, July 08, 2003 2:57 PM
> > To: Nelakuditi Narasimha (NET/Bangalore)
> > Cc: dhcwg@ietf.org
> > Subject: Re: [dhcwg] "client identifier" in server replies
> >
> > On Tuesday 08 July 2003 06.39, narasimha.nelakuditi@nokia.com wrote:
> > > Hi Thamer, I was discussing the case in which client fills
> >
> > "Client ID"
> >
> > > field but NOT "Client Hardware addr(MAC)". This is possible
> >
> > as servers
> >
> > > identify clients using EITHER "Client ID" OR "Client HW
> >
> > addr". Coming back
> >
> > > to 'xid', I think checking 'xid' alone is not a good idea,
> >
> > considering
> >
> > > erroneous servers, multiple clients using same xids etc.
> >
> > If the client is on the local segment and the server is
> > capturing packets with
> > raw frames, the server will know the hw addr of the client.
> > In this case the
> > combination of xid and unicast is pretty tight. If the server is not
> > capturing raw frames, it has no way to know the client's hw
> > addr (client id
> > is opaque, last I checked), so you will probably get a
> > broadcast only if
> > there's no hw addr (chaddr) defined. In this case, xid is the
> > only thing you
> > can use.
> >
> > Same goes for a relay agent.
> >
> > If you're a client using xid to identify responses to you:
> > Use a random XID
> > such that it will likely be unique across the entire network. The two
> > constraints that help further minimize xid clashes are 1) the
> > xid only really
> > needs to be unique on your segment, not the entire network and 2) the
> > duration of your query. This is assuming that you're not
> > filling out the
> > chaddr field, which you *should* be if you can.
> >
> > I think those three (randomness, segment subset and query
> > duration) give you a
> > high probability of identifying responses intended for you if
> > you're not
> > using the hwaddr field.
> >
> > Note that if the client *does* fill out the hw addr field,
> > you're basically
> > guaranteed that a response is for you.
> >
> > Regards,
> >
> > Bud Millwood
> > Weird Solutions, Inc.
> > http://www.weird-solutions.com
> > tel: +46 8 758 3700
> > fax: +46 8 758 3687
> > mailto:budm@weird-solutions.com
> >
> > > regards,
> > > swamy.
> > >
> > > > -----Original Message-----
> > > > From: ext Thamer Al-Harbash [mailto:tmh@whitefang.com]
> > > > Sent: Monday, July 07, 2003 11:30 PM
> > > > To: Nelakuditi Narasimha (NET/Bangalore)
> > > > Cc: dhcwg@ietf.org
> > > > Subject: Re: [dhcwg] "client identifier" in server replies
> > > >
> > > > On Mon, 7 Jul 2003 narasimha.nelakuditi@nokia.com wrote:
> > > > > Hi, If the client is setting "client identifier" but not
> > > >
> > > > "client hardware addr" in the messages that it is sending to
> > > > server, server is supposed to identify it with "client
> > > > identifier". But as per RFC2131, server MUST NOT fill "client
> > > > identifier" option in OFFER and ACK messages. If this is the
> > > > case, how is client supposed to validate the response (as
> > > > 'xid' alone is not sufficient)???
> > > >
> > > > Why? An xid is a 32-bit unsigned integer. That's about as many IP
> > > > addresses as are possibly with IPv4. Unless you're picking your
> > > > xid badly, this shouldn't be a problem.
> > > >
> > > > Also, unless the client requests broadcasts with the broadcast
> > > > bit, the server will be unicasting replies to it. The MAC
> > > > addresses with the xid should be sufficient.
> > > >
> > > > --
> > > > Thamer Al-Harbash
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:budm@weird-solutions.com

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg