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

From: [email-masked]
Date: Thu, 10 Jul 2003 14:38:12 +0800

After discussing several alternatives to solve the problem, servers including "client id" field in their replies seems to be the clean solution to it. 
If this is agreed upon, next thing is how to fix this in the protocol??

regards,
swamy.

> -----Original Message-----
> From: ext Bud Millwood [mailto:[email-masked]]
> Sent: Wednesday, July 09, 2003 2:19 PM
> To: Ted Lemon
> Cc: [email-masked]; Nelakuditi Narasimha (NET/Bangalore)
> Subject: Re: [dhcwg] "client identifier" in server replies
> 
> 
> On Tuesday 08 July 2003 20.44, Ted Lemon wrote:
> > On Tuesday 08 July 2003 07:49, Bud Millwood wrote:
> > > 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).
> >
> > Bud, there are some cases, particularly with firewire, 
> where there is no
> > way to fill out the hardware address.   Of course it needs 
> to be filled out
> > in other cases - the protocol requires it.
> 
> It would seem that if you do not have a hardware address, the 
> only way to 
> guarantee that a response is for you is if your client 
> identifier is in the 
> packet, since that's guaranteed to be unique on the "subnet" 
> ("segment" seems 
> a better word choice - 2131.2p5). And XID then only needs to 
> be unique across 
> DHCP transactions on the specific client.
> 
> I don't recall seeing anything that stated that chaddr *must* 
> be globally 
> unique for a given htype, so is it not possible to assume 
> that if your client 
> identifier is unique for your segment, that it could also 
> qualify as a 
> chaddr?
> 
> I can hear the groans now. :) 16 bytes is arbitrary, and this 
> makes a direct 
> link between chaddr and clientid, but only at the client 
> side, and only for 
> packet identification.
> 
> If not, Narasimha's proposal is the only solution I can see.
> 
> Bud Millwood
> Weird Solutions, Inc.
> http://www.weird-solutions.com
> tel: +46 8 758 3700
> fax: +46 8 758 3687
> mailto:[email-masked]
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Bud Millwood <[email-masked]>
Date: Thu, 10 Jul 2003 16:56:50 +0200

On Thursday 10 July 2003 08.38, [email-masked] wrote:

> After discussing several alternatives to solve the problem, servers
> including "client id" field in their replies seems to be the clean solution
> to it. If this is agreed upon, next thing is how to fix this in the
> protocol??

How many clients are going to discard valid server responses if they contain 
the clientid field? (i.e. how many working implementations will break?)

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?

If you can't cram it into 16 bytes, that's another issue. :)

Bud Millwood
Weird Solutions, Inc.

---

From: Thamer Al-Harbash <[email-masked]>
Date: Thu, 10 Jul 2003 08:42:59 -0400 (EDT)

On Thu, 10 Jul 2003 [email-masked] wrote:

> including "client id" field in their replies seems to be the clean
> solution to it.

I think Mr. Lemon already mentioned this, but if he didn't, how
does this solve the problem of two DHCP DISCOVER messages being
sent out from two clients with the same xid? How does the server
differentiate between them?

-- 
Thamer Al-Harbash

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Jul 2003 13:52:47 -0500

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.

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 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.

In response to the original question, I think the way to address this is to 
write up a draft and submit it to the working group.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Jul 2003 13:49:55 -0500

> differentiate between them?

The server probably doesn't even look at the xid - it just looks at the client 
identifier.   The xid is for the client.   (A server might use the xid as an 
efficiency hack to avoid responding to a retransmission of a message to which 
it's already responding, but it will behave correctly even if it never checks 
xid).

---

From: Bud Millwood <[email-masked]>
Date: Fri, 11 Jul 2003 11:22:30 +0200

> 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.

> 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
> 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.