Subject: DHCP Vendor Class question

From: Stuart Cheshire <[email-masked]>
Date: Wed, 3 Nov 1999 22:37:13 -0500 (EST)

Greetings,

The engineer at Apple who used to work on our DHCP client moved to a 
different company recently, and, for now, that responsibility has fallen 
to me. I've subscribed to this mailing list and I hope in future to keep 
Apple more in touch with what's going on with new DHCP work.

For now, I have a simple question. Mac OS does not currently put a vendor 
class identifier option in its DHCP packets. It seems to me that this 
would be a useful thing to do, both for the benefit of network 
administators, and for our benefit, so that when people complain that 
"DHCP doesn't work" and send us packet traces, we can tell what version 
of Open Transport (Apple's networking stack) was being used. From my 
reading RFC 2132 I believe that, like the client identifier option, the 
vendor class is an opaque string. I'm considering adding a vendor class 
identifier of the following form to all DHCP packets we send:

-------------------------------------------------------------
|60|27|M|a|c| |O|S| |O|p|e|n| |T|r|a|n|s|p|o|r|t| |2|.|5|.|3|
-------------------------------------------------------------

(i.e. option code 60, length 27, followed by 27 bytes of ascii text)

Is this acceptable, or have I misinterpreted RFC 2132?

>9.13. Vendor class identifier
>
>   This option is used by DHCP clients to optionally identify the vendor
>   type and configuration of a DHCP client.  The information is a string
>   of n octets, interpreted by servers.  Vendors may choose to define
>   specific vendor class identifiers to convey particular configuration
>   or other identification information about a client.  For example, the
>   identifier may encode the client's hardware configuration.  Servers
>   not equipped to interpret the class-specific information sent by a
>   client MUST ignore it (although it may be reported). Servers that
>   respond SHOULD only use option 43 to return the vendor-specific
>   information to the client.
>
>   The code for this option is 60, and its minimum length is 1.
>
>   Code   Len   Vendor class Identifier
>   +-----+-----+-----+-----+---
>   |  60 |  n  |  i1 |  i2 | ...
>   +-----+-----+-----+-----+---

Stuart Cheshire <[email-masked]>
 * <A HREF="http://ResComp.Stanford.EDU/~cheshire/">Web Page</A>
 * Wizard Without Portfolio, Apple Computer

---

From: "Paul Roberts" <[email-masked]>
Date: Thu, 4 Nov 1999 05:40:17 -0500 (EST)

Stuart,

I am glad you have taken the opportunity to announce your presence on
this list. My company has implemented DHCP at many organisations
throughout the UK and my experience has taught me that the Apple Open
Transport DHCP client has typically been the "poor relation" as far as
DHCP clients are concerned. I must admit, I am not up to date on the
features and functionality of the latest versions of the client and I
was wondering if you could tell me whether the client now has the
ability to send the client hostname in option 12 of the DHCP packet,
or whether this is an enhancement planned for the future?

The reason I ask this is that we do lots of work with DDNS too, and it
has always been difficult integrating Apple clients into a DHCP and
DDNS environment when the Apple clients do not supply a host name to
the DHCP server.

Regards,

Paul Roberts

+---------------------------------------------+
| Paul Roberts, Intranet & Intranet Solutions |
|  Tel: +44 1256 346344 Fax: +44 1256 346355  |
| E-mail: [email-masked] |
|   WWW: http://www.intranet-solutions.com    |
+---------------------------------------------+

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Nov 1999 13:13:26 -0500 (EST)

I would suggest being less verbose and more structured, but basically
I think you've got the right idea.   Instead of what you've done, I'd
suggest:

> -----------------------------------------------------
> |60|??|a|p|p|l|e|/|O|T|-|2|.|5|.|3|/|i|M|a|c|/|3|0|0|
> -----------------------------------------------------

In other words, start with "apple" (the vendor), then "OT-2.5.3" (the
relevant software version), then "iMac" (the type of computer), then
"300" (the model number, which I completely made up).   Try to be
terse so as not to waste bytes - there aren't that many to go around.
If Apple has a registry of unique model names and numbers, I'd suggest
using that and referencing it.   If getting the model number within
the OT stack is hard, maybe skip it, but it's a big win if you can
send it.

I would also suggest that you implement the user class option soon, if
you can - it's available in Win98SE, and I suspect people are going to
start making heavy use of it soon, so if you can provide the same
functionality, you'll be able to present the same feature set
Microsoft is presenting.

			       _MelloN_

---

From: C J Considine <[email-masked]>
Date: Thu, 4 Nov 1999 15:30:16 -0500 (EST)

Doesn't everything relevant have a 12 digit UPC?  Most computer 
resellers won't touch anything without one.

(UPC Council 513-435-3870.)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Nov 1999 16:45:31 -0500 (EST)

> resellers won't touch anything without one.

Probably, but that doesn't help unless we have a UPC to model+model
number table, which is probably more work to get than just having the
information right there where we need it.

			       _MelloN_

---

From: Nathan Lane <[email-masked]>
Date: Thu, 4 Nov 1999 18:07:16 -0500 (EST)

Actually, using the UPC tends to become very difficult.  The actual standards are VERY overloaded and there is definite talk of major change occuring in this arena very soon as the limitations of the current system become glaringly apparent, especially for someone like us.  Then you'd have to decide which UPC to use, which standard (UCC-12, UCC-18, etc.), which SKU it actually represented.  Let's not go there.

-Nathan Lane
Senior Network Engineer
Wal-Mart Stores, Inc.
(501) 277-5786

> -----Original Message-----
> From:	C J Considine [SMTP:[email-masked]]
> Sent:	Thursday, November 04, 1999 2:32 PM
> To:	Multiple recipients of list
> Subject:	Re: DHCP Vendor Class question
>

---

From: Nathan Lane <[email-masked]>
Date: Thu, 4 Nov 1999 18:13:14 -0500 (EST)

> From:	Ted Lemon [SMTP:[email-masked]]
> Sent:	Thursday, November 04, 1999 12:14 PM
	[Nathan Lane]  I LIKE THIS!  This is exactly the use of VID that gives me a great deal of information, works within my existing framework and lets me do very intelligent client selection... 

	However, let's make sure that if the Apple client does send this vendor identifier that it expects, uses and processes the possible return of option 43 data in a manner consistent with all of our interpretations of 2131 and 2132.  (I believe most of us feel that option 43 can be returned to the client, if asked for, on a per VID basis or simply ignored if the server is unprepared to handle it.  The client, though, should most definitely be able to function at the network layer in lieu of receipt of option 43.)
> functionality, you'll be able to present the same feature set
	[Now, I'd also really, really like to see user class option but the draft isn't far enough to tell my vendors "here, go read it and implement this for me before I'll let you put your product on my network".    I have seen the user class implemented, but it's not "enforcable" yet.

	-Nathan Lane

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 5 Nov 1999 02:29:46 -0500 (EST)

> (UPC Council 513-435-3870.)

nope.  not everything you could think of as a "vendor" is actually
*selling* something with a UPC code.. 

I.e., a free OS might want to use DHCP for autoconfiguration during
installation.

					- Bill

---

From: Rob Stevens <[email-masked]>
Date: Fri, 5 Nov 1999 14:10:31 -0500 (EST)

A
> > I think you've got the right idea.   Instead of what you've done, I'd

I am not very enthusiastic about constructing vendor-class IDs
with infra-structure like this, for the following reason.

Each unique vendor class can, in principle, define 256
entirely new options (which get encapsulated in super-option
#43). If, to take this specific case, Apple were to define
vendor-specific options then with each variant of the
vendor class they would have to publish some document
desccribing what the vendor options were for that specific
vendor class. The more sub-structure you put into the
vendor class, the more the burden of that paperwork.

Of course, If Apple really desired that each new release
of the OS defined completely new vendor options then
this would be OK. Or if Apple never defined any options
unique to them.

But generally it seems to me that the options that Apple
or any other vendor might define are likely to be identical
across a wide range of hardware and software.

Since there has lately been a flurry of discussion about interpreting
client identifiers, this might be a good time to think about
whether vendor class should also have a well-defined
canonical sub-structure. E.g. that the first sub-field (however
defined) would be what defined the syntax and semantics
of vendor specific options, and the whole field was used
as the key which servers used to determine their values.

Rob Stevens

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Nov 1999 15:49:41 -0500 (EST)

> vendor class, the more the burden of that paperwork.

Rob, what I described is the way that sun currently does vendor
classes, roughly (they use dots instead of slashes, and don't send a
transport version).   A DHCP server that's going to support vendor
classing needs to be able to say "the following vendor option code
space works for the following set of possible values of vendor class."
I do not suggest that Apple implement a completely different set of
options for each version of OT, or for each model of computer
supported, but being able to tell the DHCP server what model of
computer you are is a good thing, IMHO, and I really like the way Sun
did it.   I'm just suggesting that Apple should follow in Sun's
footsteps here.

I don't think that vendor class identifiers can or should have any
sort of well-defined substructure.   I am just suggesting that one
particular vendor, in choosing a substructure that *they* will use, do
it a certain way.

			       _MelloN_

---

From: "Henry, Mike" <[email-masked]>
Date: Fri, 5 Nov 1999 15:54:38 -0500 (EST)

Rob,

I agree completely.  The use of option 60 as suggested by Ted L. (and others
at different times) removes the distinction between "class" and "attribute".
It also begs the question of why option 60 should be considered "opaque".

Another way of looking at this is that including variant information in the
option class effectively makes this variant information ad hoc subtags. The
spec clearly states that option 43 is used to pass (variant) information to
clients and *servers*.  I am certainly not arguing that DHCP servers
actually do this (make use of option 43 info from clients), but it is what
the spec says.

 - Mike Henry

> From: Rob Stevens [mailto:[email-masked]]
> Sent: Friday, November 05, 1999 11:12 AM

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Fri, 5 Nov 1999 17:16:32 -0500 (EST)

> I agree completely.  The use of option 60 as suggested by Ted L. (and
> others at different times) removes the distinction between "class" and
> "attribute".  It also begs the question of why option 60 should be
> considered "opaque".
> 
> option class effectively makes this variant information ad hoc subtags.
> The spec clearly states that option 43 is used to pass (variant)
> information to clients and *servers*.  I am certainly not arguing that
> DHCP servers actually do this (make use of option 43 info from clients),
> but it is what the spec says.
> 
>  - Mike Henry
> 
> 
..while I agree that vendor class identifiers SHOULD contain sufficient
useful information to help us poor humans to easily differentiate them (and
maybe identify the product to which it applies) I also think that it should
be treated as an opaque string, without a defined structure.

If we don't, I'm afraid we'll simply have a repeat of the confusion
surrounding client identifiers.

That said, the "opaqueness" of a string is relative:  I believe the server
should not interpret the string, but I also believe it is much more
human-friendly for the string to be display characters.  That, however, is
merely my preference for ease in configuring servers to respond.

As for the use of option 43, I agree that the RFC currently says that the
server should use it as you describe, but I'm not sure that is the intended
behavior.  Hopefully we'll have a few moments to discuss this in the Working
Group meeting next week.

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Nov 1999 18:20:25 -0500 (EST)

> I believe the server should not interpret the string

Um.   What exactly is the server supposed to do, then?   It has to use
the vendor identifier to look up the information it needs to send back
vendor-specific options.   Isn't that interpreting the string?

The question is, is the string a key into a table of possible
vendor-specific option spaces, and is there just one such key per
vendor, or can the vendor stuff meaningful information into it in the
hopes that the server will allow the information to be used?

What the standard says now is that the contents are unspecified, not
that they can't contain information, or that the tag must be a key
into a table, with one possible value per vendor.

I think that the vendor should put into the vendor-identifier option
whatever information will help the DHCP server administrator to send
the right options to the client, and having the string vary depending
on the hardware type makes a great deal of sense to me.  This seems to
be how Sun interprets it, and I think Mike Carney might even have
written the specification.  Mike, can you comment on this?

			       _MelloN_

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Fri, 5 Nov 1999 18:22:32 -0500 (EST)

> vendor-specific options.   Isn't that interpreting the string?
What I was trying to say was that I don't believe that the vendor class
identifier should be interpreted any more by the server than is the client
identifier.

> hopes that the server will allow the information to be used?
While having the server interpret the identifier and base its response on
the contents has some appeal, how do we specify a general method that can be
easily implemented in the universe of clients and servers?  This MIGHT imply
that vendors should somehow supply "plug-ins" so that servers can act on the
identifier, or it may be that vendors would have to supply written
specifications so that administrators have to deal with vendor-specific
processing.  Check the Intel PXE spec for an example of how this could
happen.

> into a table, with one possible value per vendor.
Agreed.  I overlaid my expectations that there would not be a standardized
encoding of vendor class information, and that user-programmable response to
the contents of options 60 and 43 would not be common, onto the comment.

> on the hardware type makes a great deal of sense to me.  This seems to be
> how Sun interprets it, and I think Mike Carney might even have
If I gave the impression that I didn't expect the server to somehow use the
information in options 60 and 43 to form responses, I apologize.  What I had
intended to say is that (1) mandated structures for class identifiers
probably can't cover all cases of interest, and (2) suggested structures
often are subject to the vagaries of interpretation, so that I don't believe
an RFC ought to specify the contents or format of the class identifier.

You seem to be leaning in that direction by stating that [one of] the
purpose[s] of class identifiers is to provide the server administrator a way
to deliver the right options to a client.  Hey!  I agree with you, I just
don't think it's a good idea to specify a format, given that we can't
possibly foresee all the ways in which this might be used.

What I think we need in a client class identifier (both vendor and user
classes) is simply a way to supply servers (and clients) with a way to
identify which of the possible universes of option sets, or variations
within a [standard] set is [to be] used in replies.  If Mike Henry is
correct about option 43, then option 60 might be very simple indeed:  just a
string like "ISC," "H-P," or "Sun,"  while the versioning information could
be encoded in option 43.  I don't know that there is one best way, but I
think it deserves a wide airing to reach consensus.

I'm unhappy that I seemed to so poorly communicate my ideas, since we now
find ourselves vigorously discussing how much we agree with each other!

See you in DC!

--Barr

---

From: "Henry, Mike" <[email-masked]>
Date: Fri, 5 Nov 1999 19:02:42 -0500 (EST)

Normally I hang on every work that Ted speaks as gospel, but I have to
disagree on this point.  Exactly what defines a "vendor option code space"
embedded in a "vendor option"?  I doubt you mean the DHCP server has some
method of parsing the "vendor option code space" (in any general way) out of
the option code that also contains ad hoc fields of variant information with
no generally defined boundary between the two.

I really don't think you can have it both ways.  If the object is opaque you
cannot embed information. If you embed information it implies the server is
going to use it, or at least is potentially capable of using it. Unless of
course what you mean (and possibly what Barr Hibbs means) is that the option
is primarily for a human to look at. (Also, at the very least, the variant
information should live in defined fields if a computer is going to use the
information.)

I would suggest that Option 60 be used to indicate the user *class* and that
Option 43 be used to indicate *variant* information about that class. This
makes it possible for either a human or a computer to read the information.
This leaves Option 60 as an opaque identifier and the variant information in
Option 43. Use of Option 43 has the further advantage of providing the
structure of defined fields (that's structure, not content), which makes the
content parseable in general. Also, I think this is consistent with what the
spec currently says.

 - Mike Henry

Ted Lemon wrote>

---

From: Steve Gonczi <[email-masked]>
Date: Fri, 5 Nov 1999 19:04:37 -0500 (EST)

I expect one vendor to have many different keys. One per every device that
has some interesting requirements. It is pure optimism to hope that vendors
will follow some intelligent convention we can rely on to pull useful 
encoded information from a key.

sG

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Nov 1999 23:14:46 -0500 (EST)

> easily implemented in the universe of clients and servers?

Barr, I think that you have mistaken the context of the suggestion
that I made to the fellow at Apple.   I am most definitely _not_
saying we should write a standard that says Apple must do what I
suggested.   I am not saying we should specify what a server should do
if a vendor uses a format like the one I suggested.

What I am saying is that if Apple were to choose, like sun, to put
hardware identifiers in their vendor class identifiers, it could be
useful.   It causes no harm.   It could be useful.   I think it's good
advice.   I am not proposing a standard.

So I think we are loudly in agreement, but I just want to be clear
that I'm just giving the guy at Apple some advice based on my
experience, not trying to mandate a new standard.   :')

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Nov 1999 23:17:25 -0500 (EST)

> Exactly what defines a "vendor option code space"
> embedded in a "vendor option"?

Vendor option code space refers to the codes from zero to 255 that are
embedded in a vendor-specific encapsulated options.  The server should
encode the vendor-specific encapsulated options using a different code
space depending on the value of the vendor class identifier that the
client sends.

> I doubt you mean the DHCP server has some method of parsing the
> "vendor option code space" (in any general way) out of the option
> code that also contains ad hoc fields of variant information with no
> generally defined boundary between the two.

I am saying that the DHCP server administrator might choose to write
some configuration language that parses the vendor classes in use at a
particular site, if he or she chooses to do so.  I already have an
example of this in the ISC DHCP server's manual page using Sun
options, and I imagine Sun's DHCP server has some way of doing it too.

> If the object is opaque you cannot embed information. If you embed
> information it implies the server is going to use it, or at least is
> potentially capable of using it.

Right, in a completely ad hoc way.   Making it readable for humans
could come in handy too.

> I would suggest that Option 60 be used to indicate the user *class*
> and that Option 43 be used to indicate *variant* information about
> that class.

This sounds reasonable in theory, but it's a big pain to implement on
the client side if the client side doesn't actually need to send
encapsulated options otherwise.   Just sending what, to the client, is
a fixed string in the vendor class identifier is a lot easier.
Remember, I am not proposing that we specify this - the message I sent
that has attracted so much criticism is just advice for what I, the
author of a DHCP server who has dealt a _lot_ with real-world users,
think Apple, a vendor of a DHCP client, should do.   I am not saying
we should require such a thing of any vendor, including Apple - I'm
just suggesting.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Nov 1999 23:19:06 -0500 (EST)

> encoded information from a key.

Yup.   Although there's nothing wrong with being optimistic.

			       _MelloN_

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 15 Nov 1999 12:33:53 -0500 (EST)

yes, Ted, I think we are in agreement here:

(1) any class identifier (vendor or user) SHOULD be unambiguous, concise,
preferably a text string
(2) the format of a class identifier SHOULD NOT be specified by an RFC (that
is, it is an opaque string)
(3) the processing by clients and servers of class identifiers SHOULD NOT be
specified by an RFC -- however, the "promoter" of a class identifier MUST be
able to provide clear and complete guidance to administrators who must
configure their clients and servers to perform the intended processing

The latter point is the basis for differentiation among vendors of clients
and servers.  In the simplest case, class identifier "ZBT" might select one
or more option values to offer a client.  More complex cases could be built
if clients and servers had richer vocabularies of conditional actions for
processing requests and responses, but this should be entirely out of the
scope of an RFC, whose purpose is only to specify the code, length, and
description of a class identifier.

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Nov 1999 13:24:29 -0500 (EST)

> (1) any class identifier (vendor or user) SHOULD be unambiguous, concise,

Okay.

> is, it is an opaque string)

"Opaque string" != "not specified by RFC", which I think is one of the
causes of confusion over this point.   I think that it might be better
to say "is unspecified" than "is an opaque string".

> configure their clients and servers to perform the intended processing

mmm, I like this.   :')

			       _MelloN_

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 15 Nov 1999 13:25:59 -0500 (EST)

> to say "is unspecified" than "is an opaque string".
OKAY -- an important semantic point....  I was using the definition of
opaque string as "the contents and format of the string are not specified,"
so your clarification is right on target!

--Barr