how is the client identifer used in other DHCP servers.

[Ralph Blach]

Ok, so ether it matches of it does not.
Any comments of RFC 4361 which seems to change this?

Thanks

Chip

On 3/22/06, David W. Hankins <David_Hankins at isc.org> wrote:
>
> 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
>
>