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

Bud Millwood <budm@weird-solutions.com> Tue, 08 July 2003 09:26 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15692; Tue, 8 Jul 2003 05:26:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZojY-0007Wj-Fv; Tue, 08 Jul 2003 05:26:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zoil-0007Vr-PL for dhcwg@optimus.ietf.org; Tue, 08 Jul 2003 05:25:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15633 for <dhcwg@ietf.org>; Tue, 8 Jul 2003 05:25:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zoih-0000Az-00 for dhcwg@ietf.org; Tue, 08 Jul 2003 05:25:07 -0400
Received: from webmail.mail.se.dataphone.net ([212.37.1.50] helo=intermail.se.dataphone.net) by ietf-mx with esmtp (Exim 4.12) id 19Zoig-0000Aw-00 for dhcwg@ietf.org; Tue, 08 Jul 2003 05:25:06 -0400
Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.0.5) with ESMTP id 1525296; Tue, 08 Jul 2003 11:25:04 +0200
Content-Type: text/plain; charset="iso-8859-1"
From: Bud Millwood <budm@weird-solutions.com>
Reply-To: Bud Millwood <budm@weird-solutions.com>
Organization: Weird Solutions, Inc.
To: narasimha.nelakuditi@nokia.com
Subject: Re: [dhcwg] "client identifier" in server replies
Date: Tue, 08 Jul 2003 11:27:00 +0200
User-Agent: KMail/1.4.3
References: <79A2DB53BC51BD448F0D19A86FB1DB637F1FF6@siebe002.apac.nokia.com>
In-Reply-To: <79A2DB53BC51BD448F0D19A86FB1DB637F1FF6@siebe002.apac.nokia.com>
Cc: dhcwg@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200307081127.00251.budm@weird-solutions.com>
Content-Transfer-Encoding: quoted-printable
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

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