how is the client identifer used in other DHCP servers.

[David W. Hankins]

On Wed, Mar 22, 2006 at 04:27:45PM -0500, Ralph Blach wrote:
> Ok, I meant option 61 type code 0.

Yes.

> I know Internet Systems Consortium DHCP Distribution version 3,
> will accept a string if the option is 61 and the type of the option is 0.

Doesn't matter what the first byte is.  It's an opaque blob.  We don't
touch it, we don't look inside it except to compare its contents against
other option 61s provided in other packets.

It's either a 1:1 match bit for bit, or it is not.

I consider the fact that the first byte is often called the 'type'
to be a convention, not a standard.  Or, at least the use of 'type
zero' to indicate a string is a convention.

Not a bad one, but just a convention.

I know it's confusing because the figure (ascii text) for the
option in 2132 includes the 'type' field, but this is describing
the optional (and in my opinion, incorrect) behaviour directly
above it ("MAY").  This is the proper line in rfc2132 to read on
the subject of option 61:

   Identifiers SHOULD be treated as opaque objects by DHCP servers.

See also RFC2131.

   reply messages and as a client identifier.  The 'client identifier'
   is an opaque key, not to be interpreted by the server; for example,
   the 'client identifier' may contain a hardware address, identical to
   the contents of the 'chaddr' field, or it may contain another type of
   identifier, such as a DNS name.  The 'client identifier' chosen by a

Naught else matters.

As I've voiced, I tend to prefer rfc2131's interpretation over
rfc2132's.

> How do other DHCP servers react to option 61, type 0?

As far as I am aware, in the exact same way.  I think all the server
manufacturers know that doing anything different would probably result
in incompatible and broken behaviours.

At least I hope they do.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins