Subject: Possible ambiguity in definition of DHCP client identifier option.

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Nov 1999 17:37:42 -0500 (EST)

I'm pretty sure it's not what's intended, but because of the way the
parts of the client identifier option are labeled, it's possible for
somebody to interpret the definition of the client-identifier option
in the following way:

  Btw, I just read Ted's latest e-mail, and the impression I get is that the
  server is using the type as part of the client identifier, which I believe
  is in violation of RFC 2132's description of option 61, which puts the type
  separate from what it calls the client identifier.  I want to make sure that
  people understand how I am interpreting client identifier so that we
  understand each other.  Ted, are you including the type as part of the
  client identifier?  If so, why do you think that's valid (given the diagram
  describing option 61 in 2132).

Here's the text from the RFC:

   For correct identification of clients, each client's client-
   identifier MUST be unique among the client-identifiers used on the
   subnet to which the client is attached.  Vendors and system
   administrators are responsible for choosing client-identifiers that
   meet this requirement for uniqueness.

   The code for this option is 61, and its minimum length is 2.

   Code   Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+---
   |  61 |  n  |  t1 |  i1 |  i2 | ...
   +-----+-----+-----+-----+-----+---

As you can see, it's not clear whether the phrase "client identifier"
in the opening paragraph is referring to the entire contents of the
option, or the contents that are labeled "Client-Identifier" in the
diagram.   I have always interpreted this as the contents of the
option from the first byte of payload to the last, not just the part
following the type code.

Any clues?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Nov 1999 10:47:27 -0500 (EST)

> I think the draft is reasonably clear on this point, but that
> doesn't mean that it couldn't be made even more clear -- which
> would probably be a good idea.

Yup.  Basically, the goal of making a change would be to help people
who don't already have a good understanding of the DHCP protocol that
has evolved over time.   This is one of those cases where although
it's obvious to a seasoned DHCP hacker what the text means, it's not
so obvious to a neophyte, and it's to everybody's advantage to make
sure that neophytes have the information they need.   :')

BTW, I don't know if it's possible at this late date, but I'd really
like to see the text "the client MAY choose to explicitly provide the
identifier through the 'client identifier' option" to "the client
SHOULD choose to explicitly provide the identifier through the 'client
identifier' option".   Right now I think client implementors tend to
read this as saying that the client identifier is optional (that's
certainly how I read it) and may not feel any real motivation to use a
client identifier.   To say the least, the way client identifiers are
currently handled is quite a bummer.   If I had my druthers, even
though the ISC DHCP client doesn't currently implement it, I'd change
this to a MUST, with a caveat that servers should allow for clients
that don't supply client identifiers for backward compatibility.

			       _MelloN_