Subject: How does a client tell the DHCP server what it can do?

From: Kim Kinnear <[email-masked]>
Date: Fri, 11 Dec 1998 13:42:52 -0500 (EST)

We need some advice.  I beleive that the issue I'm about to raise is 
substantially similar to the one that Burcak Beser raised toward the end of 
the DHC WG meeting on Wednesday in Orlando.

Perhaps there was a concensus answer to his question, but I didn't hear one 
-- and now some folks with whom I work have what appears to be the same 
problem.

The Problem:
------------

There are a number of different kinds of cable modem devices out there and 
for a variety of good reasons, the DHCP server needs to know what kind of 
device with which it is dealing.

Now, these devices are all more or less standard, but there are several 
variants. The variations run like the following (but there are considerably 
more than 3, but probably less than 10 or so different binary possibilities).

	cable modem 
	cable modem with telephone
	telephone

The DHCP server needs to take different actions based on what sort of device 
is present out there.

How should these devices make their capabilities known to the DHCP server 
on the DHCP DISCOVER?

The Current Solutions:
---------------------- 

1. They should encode this in the client-id somehow.  This is considered a 
bad idea for a variety of reasons.

2. They should use the parameter-request-list and request different 
"phantom" options as a way of saying that they have this or that capability 
-- where the presence of an phantom option in the parameter request list 
would indicate that the device has a particular capability. (Hey, it wasn't 
my idea!)

I don't much like this one, but I have heard it suggested.

3. The device should encode its capabilities in the vendor-class-id option 
(Option 60) in some unlikely-to-be-randomly-duplicated way.

One approach to this might look like the following (if it was string and not 
binary based):

DOCSIS: 374 | Your favorite vendor and model number

Where the 374 would be the decimal encoding of some sort of 32 bit quantity 
which would be a capabilities mask.  The idea here would be to put the 
"standardized" part of the vendor-class-id first, with the more traditional 
free-form vendor class stuff at the end.

4. Use the dhcp option for "host system characteristics" that was proposed 
by Mike Henry and Eric Dittert of Intel.

This draft is gone from www.ietf.org, but lives on in Ralph's www.dhcp.org.

They were proposing this for network computers, but it could certainly be 
easily extended for these cable modem and voice over IP clients.

------------------------

Any suggestions?

I find the use of vendor-class-id to be a little strange, but on the other 
hand, the option is already approved and it isn't *wrong* to use it this way.

I find using the not-yet-approved host system configuration option to 
be a bit less hacked up than the vendor-class-id, but I know that some
people didn't like the host-system-config option and said that the 
vendor-class-id was the way to solve that problem, and I sort of agree
with them.

Ideas, anyone?

Time is of the essence here, since there are multiple other standards bodies 
who *are* going to standardize on *something* real soon now, and if we want 
to have any input, now is the time!

Thanks -- Kim

---

From: "Lalwaney, Poornima (SD-EX)" <[email-masked]>
Date: Fri, 11 Dec 1998 14:29:41 -0500 (EST)

Kim,

We are also interested in a solution to this. What I heard as another
potential approach besides what you propose was the use of the SLP option.

This issue was cited as an example of a case for implementing policy at the
server.

Can you elaborate on your comment that  the client-ID (or a combination of
client-ID and user-class-ID) representing the client's capabilities and type
is a bad idea for a variety of reasons?

Thanks..
Poornima

---------------------------------------
Poornima Lalwaney
General Instrument
---------------------------------------

> -----Original Message-----
> From:	Kim Kinnear [SMTP:[email-masked]]
> Sent:	Friday, December 11, 1998 10:43 AM
> To:	Multiple recipients of list
> Subject:	How does a client tell the DHCP server what it can do?
> 
>

---

From: "Hibbs, R BARR (PB-rbhibbs)" <[email-masked]>
Date: Fri, 11 Dec 1998 15:20:52 -0500 (EST)

Poornima, Kim, et al.--

Yes, SRVLOC was offered as a potential for implementing policies, but I
don't understand enough about either the mechanism or the Policy WG's
efforts to comment intelligently about either (I guess I have some reading
to do this weekend!)

Anyway, I'm not sure that a "policy" -- at least as far as I understand the
common meaning of the term -- addresses the issue Kim raised.  It still
seems to me that we are trying to determine to which of a set of potentially
overlapping classes a particular client belongs in order to offer that
client an appropriate configuration.

Given that there exists multiple classes into which a client might be
categorized, a "policy" would only provide the rules for discriminating
among alternatives based on knowledge the server possesses about the client.
Also, the existence of multiple classes, a priori, suggests some policy was
used to determine the need for multiple classes....

I can imagine different client configurations based on many distinguishing
characteristics, for example:

HARDWARE

NIC type
Host platform type
Network type (e.g., Ethernet v. FDDI)

SOFTWARE/FIRMWARE

Client stack
Operating System

USER

Organization
Language
Job Function
Location

.., etc.

A policy tells how to account for multiple characteristics when constructing
classes, and how to assign a client to a class, but the use of an external
policy source that is determined through interaction with other services
troubles me a bit.  Would that mean that my server's rules for determining
which options and values for those options to offer a client could be
altered by some policy mechanism separate from whatever means is utilized to
configure the server?  That by itself is a huge topic for discussion....

(I guess that means a couple more working groups/forums to monitor!)

--Barr

----------
From:  Lalwaney, Poornima (SD-EX) [SMTP:[email-masked]]
Sent:  Friday, December 11, 1998 11:30 AM

---

From: "Hibbs, R BARR (PB-rbhibbs)" <[email-masked]>
Date: Fri, 11 Dec 1998 15:19:41 -0500 (EST)

Kim, et al.--

I think the problem is broader than considerations for cable modems....

We are currently planning to deploy "thin client" workstations whose DHCP
client does NOT request either option 58 or 59 (renewal and rebinding times)
BUT if it does not receive them defaults to a renewal period of one minute.
As the client is burned into ROM, the vendor does not want to change.  (No
lectures, please, about broken clients, as we've already determined that the
vendor must change it's clients' behavior.)

What this did was to raise the issue "Can we somehow alter the options
payload to deliver these options only to these particular clients?"

I believe this is highly similar to what Kim inquired about.

My initial thoughts were to ensure that the processing of vendor-class
identifiers by our server would be able to add options to the list of
"mandatory" ones based on the value of the vendor-class identifier.
(Speculation about the vendor client in question suggests that including a
vendor-class identifier in all request messages would be simpler to
implement in a limited code space than fixing the client to calculate the
renewal and rebinding times from the offered lease time.)

I don't understand why you think that using vendor-class in the situation
you described is "weird."  (Maybe that's just me....)

Cable modems in particular pose some interesting problems...

..it seems to me that configurations such as the following are possible:

     +-------+   +----------+
     | Cable |   | Set-top  |
-----+ Modem +---+   Box /  +----> Video, Audio gear
     |       |   | Splitter |
     +-------+   +---+--+---+
                     |  |
                     |  +------> Telephone
                     +---------> Computer/Data gear

(Mike Patrick and you other cable-familiar guys please correct me here.)

In this configuration, how many IP addresses must be assigned?  Are all of
them private address spaces (e.g., net 10, with upstream proxies translating
for any devices that need access outside of the cable system) or are some
public addresses?

Or, are we asking that one DHCP request somehow configure multiple devices,
or that the cable modem or set-top box act as a relay agent?  (While I don't
think that's what's intended, I just want to get this clarified.)

The problem being to provide different configurations based on devices
(hardware types?  stack types?  NIC types?  OS types?) that present a
request.

In a private conversation with Ralph, I had offered to author an
Internet-Draft on the subject of how to apply (potentially) overlapping sets
of configuration classes to generate an appropriate response to a client,
which partially covers Kim's inquiry, but Kim seems to be asking the
slightly larger question of "What do we do when we have (potentially) more
classes to describe a client than we have options for that purpose?"

In his approach (3), Kim repeats the suggestion that we somehow encode
multiple classes in the vendor-class identifier.  On Wednesday we started to
open this one for discussion and recognized quickly that it was too big an
issue to settle in the WG meeting.

Approach (2) suggests "phantom" options for communicating the
differentiating characteristics.  Couldn't we suggest that the use of
"site-local" options 128-254 be used to communicate these characteristics?
Of course, that could easily lead to anarchy if multiple vendors suggest the
same option number for different characteristics, but in the case of a cable
system, wouldn't the system effectively be closed to non-standard vendors?

I agree that client identifier (approach (1)) should not be used to
communicate host system characteristics.

As for Mike Henry's Host System Characteristics option proposal, approach
(4), I'll have to go re-read it first, but I think we may simply have a
problem where we can't yet tell how big it is (i.e., don't know how many
different characteristics are important in configuring a client) so maybe we
have to attempt first to size the problem.

--Barr

----------

The Problem:
------------

Now, these devices are all more or less standard, but there are several 
variants. The variations run like the following (but there are considerably 
more than 3, but probably less than 10 or so different binary
possibilities).

	cable modem 

is present out there.

The Current Solutions:
---------------------- 

binary based):

------------------------

Any suggestions?

I find the use of vendor-class-id to be a little strange, but on the other 
hand, the option is already approved and it isn't *wrong* to use it this
way.

Ideas, anyone?

Thanks -- Kim

---

From: "Hibbs, R BARR (PB-rbhibbs)" <[email-masked]>
Date: Fri, 11 Dec 1998 17:14:05 -0500 (EST)

Kim--

I appreciate the thought you've put into your questions to the list and
largely agree with your response to my questions.

--Barr

1. I believe that we are talking only about determining
information and configuration parameters for the device
sending in the DISCOVER: the cable modem, cable modem/phone,
or phone.  It has a MAC address of type, and needs an
IP address and some considerable other configuration
information.  

--I also think we are talking about the requesting device -- i.e., the one
sending the DISCOVER message -- regardless of where or what it is.  I just
wanted to be absolutely certain that Burcak wasn't thinking that a request
message from a piece of downstream equipment wasn't being altered by the
cable modem (or any other intermediate system) on its way upstream to a DHCP
server so that it (the cable modem) could get some little piece of data it
needed for configuration.  That would certainly be a cause for concern.

2. I think using the vendor class is "weird" (not too
precise a term, I suppose) because a vendor class is supposed
to used as a "key" into the set of vendor supplied options
sets.  Encoding system characteristics in this key
then means that either you have to decode it (the likely
case) or have a set of vendor supplied options for every
possible combination of characteristics, which can get
very large very fast.  Also, standardizing a sort of
freeform field for a set of devices poses some risks
of overlap (though I don't think they are significant).
I'm overall a little uncomfortable with this approach,
but it may well be the best and I'm getting used to 
it. That's why I'm asking the list -- is this
reasonable or a *really* bad idea?

--Again, I agree that attempting to code/encapsulate multiple bits of
discrete data into a single option is generally a bad idea because it
confuses the purpose of the concept of multiple options:  include only the
data needed.  I'm just not convinced that a single vendor-class-like option
(or, for that matter, a single user-class-like option) is adequate.  In my
response to Poornima I enumerated a brief list of multiple candidates for
each, and believe that there may be several more commonly used in a typical
organization.  If we need to encode lots of identifiers or characteristics
to enable a server to offer appropriate configuration data to its clients,
maybe we need to identify all likely characteristics (and maybe classes) and
propose options for each -- then, if the working group agrees to their
general usefulness they will become standard options, otherwise they'll be
rejected as standards and left to individual organizations to use them as
site-specific options.

3. Seems to me, Barr, that you are suggesting that
we somehow might use the userclass option to send in
this information?  I'm uncomfortable with
that, since I think that one might imagine one of
these devices which is in a user class but *also*
wanted to tell the DHCP server something about what
kind of device it was - and you couldn't really
do both.  But it is something to consider, certainly.

--No, I'm sorry if I gave that impression.  I was trying to point to the
similarities between vendor-class identifiers and user-class identifiers:
in both cases the working group has apparently embraced the concept without
realizing how large the problem of distinguishing among groups/classes
really was.  In our case, we very much wish to identify classes of users
(which unfortunately overlap to a large extent) in some expedient fashion
and offer different values for options (and in some cases, entirely
different options) based on these classes.  Yet I don't particularly wish to
encode or encapsulate the various class identifiers into a single option.

To give a very specific example, we have a large class of users ("service
representatives") that use a private (that is, specific for service
representatives, no data for others) Domain Name server.  For this
user-class, I want to be able to specify that they are to use their private
DNS server.  What complicates this is that service representatives often
share subnetworks with non-service-representative users who should be
directed to an entirely different name server.  Selection based on
subnetwork address doesn't work, and generally the host systems of a service
representative are indistinguishable (same hardware configuration) from
those of non-service-representative users.   But here's the rub:  service
representatives are also aggregated geographically, by serving telephone
central office, so a single user-class identifier ("service representative"
v. "non-service representative") doesn't work -- I have overlapping user
classses!  (Bring on the Venn diagrams!)

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 11 Dec 1998 17:13:19 -0500 (EST)

Barr,

Thanks for your response.

A couple of points...

1. I belive that we are talking only about determining

Thanks for the ideas,

Cheers -- Kim

---

From: "Henry, Mike" <[email-masked]>
Date: Sat, 12 Dec 1998 00:32:07 -0500 (EST)

Kim,

This answer may be a little lengthy, I hope you will bear with me.

First, the host systems characteristics ID Eric Dittert and I wrote has not
disappeared from the ID directory. It is under "Individual Submissions" at 
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-dittert-host-sys-cha
r-02.txt.

The problem you describe is the class of problem we set out to address with
this draft. While we did not specifically anticipate the case of cable
modems you describe, we did provide an option to allow the client to
identify its type of network interface in some detail. 

In the draft we proposed three new options:

	93 - Client System Architecture
	94 - Network Device Interface
	97 - Unique Client Identifier

I believe the proposed "Option 94" directly addresses the problem you
describe. 

The text for this option is:

===========================================================================
2.2 Client Network Device Interface Option
   .
   ...

   Three types of network device specifications are defined for use with 
   this option: 
       * devices that support the Universal Network Driver Interface
         (UNDI), as described in "Network PC System Design Guidelines: A
         Reference for Designing Net PC Systems for Use with the
         Microsoft Windows and Windows NT Operating Systems" [3]
       * Plug-and-Play devices [4]
       * PCI devices [5]

   Each device that supports (UNDI) MUST be specified as an UNDI 
   device, regardless of whether it is also a Plug-and-Play device or a 
   PCI device.  To specify an UNDI device, the option contains a type 
   code of 1 and the major and minor UNDI version numbers:

     Code  Len   Type  Major Minor
    +-----+-----+-----+-----+-----+
    | 94  |  3  |  1  | m1  | m2  |
    +-----+-----+-----+-----+-----+

   To specify a PCI network device, a type code of 2 is used, and the 
   vendor ID, device ID, class code, and revision are included:

     Code  Len   Type  Vendor ID   Device ID   Class code        Rev
    +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
    | 94  |  9  |  2  | v1  | v2  | d3  | d4  | c1  | c2  | c3  | r1  |
    +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

   To specify a Plug-and-Play network device, a type code of 3 is used, 
   and the EISA device ID and the class code are included:

     Code  Len   Type  EISA device ID          Class code
    +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
    | 94  |  8  |  3  | e1  | e2  | e3  | e4  | c1  | c2  | c3  |
    +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
===========================================================================

During the spring '98 DHCP WG meeting some support was expressed for the
Client Network Device Interface Option (opt 94). Perhaps this option would
be useful in solving this problem.

I propose that simply defining, say, type 4, as cable modem, and further
defining the field following to indicate the various cable modem subtypes
would be useful. For example, the option could be extended by the following
text:

   To specify a Cable Modem device, a type code of 4 is used, further
defined by a subtype field. 
   The subtypes are IANA controlled:

     Code  Len   Type  SubType  
    +-----+-----+-----+-------+
    | 94  |  2  |  4  |   st  | 
    +-----+-----+-----+-------+

Before going on, it's probably worthwhile reviewing the current status and
history of options 93, 94, and 97, and our motivation for presenting them in
the first place.

These options are in use in production machines. They are currently deployed
in most recently produced "Office" class PCs that contain a network
interface. Use of the options is required by the PC98 and PC99
specifications for this class of
machine.(ftp://download.intel.com/design/pc98/pc99/Pc_99_1.pdf). These
specifications were co-authored by Microsoft and Intel.

The options were first defined in March, 1997 in the first version of the
ID. Objections to use of the options were raised in the spring 1998 IETF
DHCP WG meeting. Primarily (at the risk of putting words in other folks'
mouths) I believe the primary objection was that the options were
unnecessary, as the same functionality could be obtained from existing
options (specifically option 60 and option 61). 

In the Aug. 1998 IETF WG meeting we agreed to publish the use of options 93.
94, and 97 as an Informational RFC, and to phase out use of the option
numbers within the next 6 years. Instead of using these option numbers, we
agreed to migrate to use of Option 60 (Class Identifier "PXEClient:xxx:yyy")
to cover network interface type and client system architecture type, and
option 61 to provide a UUID client identifier. The latest version of the PXE
specification (http://developer.intel.com/ial/wfm/wfmspecs.htm) requires
both the use of options 93, 94, and 97, and the use of options 60 and 61
(which include the same information as 93, 94, and 97). Future versions of
the specification will drop the use of 93, 94, and 97. (Why not drop them
immediately? Because they are being used, and time must be allowed for
existing client PC and boot server turnover- 6 years is adequate for this.).
The informational RFC will be presented to the working group for review this
month.

OK, I'm now going to go out on a limb just a bit and assert that this
particular problem - the need to provide specific configuration information
based on client characteristics - points out, I believe, a significant
weakness with reliance on option 60 for client differentiation (i.e.,
differentiation beyond that provided by option 61 or "chaddr"). I do not
believe (and I could be mistaken about this) that it is proper to use option
60 twice. If this is true, then how would a cable modem indicate that it was
also a "PXEClient:xxx:yyy"? (This is an entirely likely possibility; the
current difficulty with remote boot over modems is bandwidth, a problem
solved with cable modems.) At the very least, the cable modem specification
and the PXE specification would have to coordinate to agree to a common
field definition for the embedded fields in the Option 60 string. Given that
a system using a cable modem might or might not also include a PXE remote
boot capability through the cable modem, what would the encoding scheme look
like that accounted for all three possibilities (i.e., cable modem only, PXE
only, PXE enabled cable modem)? Spec coordination would also be required on
use of option 43 subtags. Certainly, in this specific case, it is
conceivable that with great difficulty and gnashing of teeth something could
be worked out, but what about the next instance of a client requiring DHCP
response differentiation based on the client's properties? Three way spec
coordination?  

Again, if option 60 could be used more than once, the above would not be an
issue if DHCP servers (realistically) will notice both instances, and will
find the correctly corresponding option 43 subtags for each option 60 use,
and will provide back the configuration requested by each option 60. (But,
how will DHCP vendors and/or administrators know about the increasing number
of more or less standard Option 60s? After all, the information is being
presented so the DHCP server can do something about it.)

I would like to ask everyone to consider the general problem of providing an
arbitrarily extensible method for a booting client to make its properties
known to the DHCP service. (This is exactly the inverse of the problem that
DHCP solves, i.e., an arbitrarily large amount of configuration information
can be presented to the client through the use of an arbitrary number of
specific option tags.) I submit that a solution (not necessarily "the"
solution) would be to allow the definition of client characteristic tags on
an as needed basis, with the expectation that DHCP servers will respond to
these tags as appropriate. 

It also seems to me that SLP offers a solution, on the assumption that the
cable modem does not need the configuration information to effectively
communicate with the DA and SA, and that SLP is widely enough deployed that
its presence can be assumed.

Given that time is of the essence, and further, that anything that hinders
the simultaneous use of PXE and network interface devices of any kind is
extremely undesirable from our standpoint, I think careful consideration
should be given to the use of Option 94 - Client Network Device Interface,
along the lines described above.

Thanks,

 - Mike H.

   Michael D. Henry
   Intel Architecture Lab / MPL, Intel Corp.
   (503) 264-9689
   (503) 804-8011
   [email-masked]

> From: Kim Kinnear [mailto:[email-masked]]
> Sent: Friday, December 11, 1998 10:43

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Thu, 17 Dec 1998 20:21:28 -0500 (EST)

Hi folks,
	
Like Barr, I'm assuming that devices Kim speaks of are DHCP clients
themselves, not entities that tack on / remove DHCP data as the packets fly by
from DHCP clients to/from DHCP server, as is the case with the Motorola cable
modems.

Some history regarding the Vendor class identifier option and encapsulated
vendor option:

These options are a matched set, and are intended as a general purpose,
flexible mechanism for DHCP client vendors to use to return parameters
specific to the client OS/platform. It was designed such that if a client
vendor stuck to the default option types for encoding their vendor specific
information, any DHCP server which supported vendor classing could be
configured to support their client's needs. The Vendor class identifier +
encapsulated vendor option functionality is intended to be a replacement for
the BOOTP magic cookie functionality (see rfc951).

The Vendor class identifier and encapsulated vendor option used to be well
defined in RFC 1541, however, this tight specification was watered down in RFC
2131, to the point that confusion in its use is not surprising. Here's the
text from RFC 1541 that used to describe it:

"A new option, called 'vendor specific information', has been added to allow
for expansion of the number of options that can be supported [2].  Options
encapsulated as 'vendor specific information' must be carefully defined and
documented so as to allow for interoperability between clients and servers
from diferent vendors.  In particular, vendors defining 'vendor specific
information' MUST document those options in the form of the DHCP Options
document, MUST choose to represent those options either in data types already
defined for DHCP options or in other well-defined data types, and MUST choose
options that can be readily encoded in configuration files for exchange with
servers provided by other vendors.  Options included as 'vendor specific
options' MUST be readily supportable by all servers."

A client vendor may include exactly one vendor class identifier, as the
specification of multiple identifiers would quickly cause collisions in any
present encapsulated vendor options (ie, we all use code 1, but for different
things). Unfortunately, the information regarding of the Vendor class
identifier and encapsulated vendor option in RFC 2131 and 2132 isn't as clear
as it ought to be. I've attached a mail message I sent out in march that
includes a discussion of the relationship between the Vendor class identifier
and the encapsulated vendor option. These options are used today by vendors
for delivering OS/platform specific boot information.

On to Kim's specific issue. All of the devices could identify themselves by
using a vendor class id. If they required vendor-specific information, then
the vendors could define a set of default type options to use for carrying
this data from the server to the device.

Kim's proposed solutions:

1) encode in client-id somehow. Yep, I agree with the consensus - this is a
bad idea.

2) use the parameter-request list w/ phantom options - I also think this is a
bad idea. This changes the meaning of the parameter-request list and thus the
protocol.

3) Encode in Vendor class id. Today, the Vendor class id string is opaque to
the DHCP server; see my attached mail for recommendations on preventing name
collisions. Such names are intended to be human-readable. Having the DHCP
server parse the contents of a Vendor class id changes the opaque nature of
the option, in a non-backward compatible way. However, if the Vendor class id
is still treated as an opaque string by the server, then it sounds like a
possible solution, provided the device vendors agree to give up ownership of
their vendor class id space.

4) Host system characteristics option (s)

This is an interesting proposal. Kim, you are missing some information in your
original mail - what sort of characteristics do the devices you mention need
to be considered by the DHCP server?

In response to Mike's message regarding the use of Option 60 (Vendor class
identifier) - You're right, only one Vendor class identifier is expected
within a request. A Vendor class identifier identifies the platform such that
the correct parameters (such as boot images) can be selected and delivered to
the appropriate client. Details such as NIC card type were historically
consider irrelavent, as the NIC was onboard, and the OS image was expected to
have the appropriate drivers to deal with it.

The question I think we're (Mike, Kim, others) are trying to answer is how to
provide a finer granularity of the definition of a platform than the Vendor
class identifier can provide.

Before I can comment on Mike's suggestion to use option 94 to identify the
modem's characteristics, I need to know more about the characteristics that
Kim needs the DHCP server to be aware of. Perhaps modems need an option of
their own in which the modem vendors would agree on the format and contents.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.