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

Bud Millwood <budm@weird-solutions.com> Fri, 11 July 2003 11:25 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 HAA25158; Fri, 11 Jul 2003 07:25:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aw1O-000076-MS; Fri, 11 Jul 2003 07:25:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19au52-0007Pe-O4 for dhcwg@optimus.ietf.org; Fri, 11 Jul 2003 05:20:41 -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 FAA22502 for <dhcwg@ietf.org>; Fri, 11 Jul 2003 05:20:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19au4z-000412-00 for dhcwg@ietf.org; Fri, 11 Jul 2003 05:20:37 -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 19au4y-00040q-00 for dhcwg@ietf.org; Fri, 11 Jul 2003 05:20:36 -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 1538256; Fri, 11 Jul 2003 11:20:33 +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: Ted Lemon <mellon@fugue.com>
Subject: Re: [dhcwg] "client identifier" in server replies
Date: Fri, 11 Jul 2003 11:22:30 +0200
User-Agent: KMail/1.4.3
References: <79A2DB53BC51BD448F0D19A86FB1DB637F1FF9@siebe002.apac.nokia.com> <200307101656.50160.budm@weird-solutions.com> <200307101352.47190.mellon@fugue.com>
In-Reply-To: <200307101352.47190.mellon@fugue.com>
Cc: narasimha.nelakuditi@nokia.com
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200307111122.30161.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 Thursday 10 July 2003 20.52, you wrote:
> On Thursday 10 July 2003 09:56, Bud Millwood wrote:
> > If your wire protocol has absolutely no way of identifying nodes on that
> > wire, the only way to use DHCP is for each node to be able to uniquely
> > identify itself. Whether your node or your wire-level protocol generates
> > the unique identifier, that identifier should serve as your hw address,
> > IMHO. Is there anything wrong with this line of thought?
>
> Yes, the chaddr field in the packet is used to set the address on the frame
> being sent by the DHCP server or relay agent to the client.   So you can't
> just stuff some random value in there.

OK, I think the difference here is that I am suggesting that for certain hw 
types, the server should never attempt to frame with chaddr. Having spent the 
better part of the morning thinking about this, though, it seems that putting 
clientid in all server responses is just simpler.

> I don't know why the restriction on sending client-identifier back to the
> client is in place in the protocol - can anyone explain this?

I could have sworn that originally the spec did not call for removal of 
clientid on any server response. If that's so, there should be something in 
the list archives. Maybe I just missed it originally. :)

> I have
> difficulty believing that a client would reject a packet containing a
> client-identifier option - clients generally just discard options they
> aren't expecting.   A way to resolve this would be to send the client
> identifier only if it appears in the parameter-request-list, though - then
> a client that wasn't expecting it would never see it.

I have seen one that complained. Can't recall if it dropped the responses, 
though. I like the param-req-list idea.

- Bud

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