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

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. 

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