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

If client-id is stored in h/w addr field, we can't store client-id of more than 16-bytes as you pointed out. 
If servers check for the validity of h/w type and corresponding h/w length, then one has to pad client-id to next valid length (by the way, is server supposed to validate h/w type and h/w len values?).

Apart from firewire case, another case in which valid h/w value is not available for clients is if DHCP is used to allocate IP addresses for mobiles. 

regards,
swamy.

> -----Original Message-----
> From: ext Bud Millwood [mailto:budm@weird-solutions.com]
> Sent: Thursday, July 10, 2003 8:27 PM
> To: Nelakuditi Narasimha (NET/Bangalore); mellon@nominum.com
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] "client identifier" in server replies
> 
> 
> On Thursday 10 July 2003 08.38, narasimha.nelakuditi@nokia.com 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.
> 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