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
- [dhcwg] "client identifier" in server replies narasimha.nelakuditi
- RE: [dhcwg] "client identifier" in server replies narasimha.nelakuditi
- Re: [dhcwg] "client identifier" in server replies Bud Millwood
- RE: [dhcwg] "client identifier" in server replies narasimha.nelakuditi
- Re: [dhcwg] "client identifier" in server replies Bud Millwood
- Re: [dhcwg] "client identifier" in server replies Ted Lemon
- Re: [dhcwg] "client identifier" in server replies Thamer Al-Harbash
- Re: [dhcwg] "client identifier" in server replies Ted Lemon
- Re: [dhcwg] "client identifier" in server replies Thamer Al-Harbash
- Re: [dhcwg] "client identifier" in server replies Ted Lemon
- Re: [dhcwg] "client identifier" in server replies John Schnizlein
- Re: [dhcwg] "client identifier" in server replies Bud Millwood
- RE: [dhcwg] "client identifier" in server replies narasimha.nelakuditi
- RE: [dhcwg] "client identifier" in server replies narasimha.nelakuditi
- Re: [dhcwg] "client identifier" in server replies Bud Millwood
- RE: [dhcwg] "client identifier" in server replies narasimha.nelakuditi
- RE: [dhcwg] "client identifier" in server replies Thamer Al-Harbash
- Re: [dhcwg] "client identifier" in server replies Ted Lemon
- Re: [dhcwg] "client identifier" in server replies Ted Lemon
- Re: [dhcwg] "client identifier" in server replies Bud Millwood
- Re: [dhcwg] "client identifier" in server replies Sanjeev Verma