Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
Interpreting Client Options for the Dynamic Host Configuration
Protocol
<draft-ietf-dhc-client-options-00.txt>
Saved: Thursday, October 14, 1999, 2:24 PM
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
During the summer of 1999, a grand debate raged over the correct
interpretation of several DHCP client options as described in [RFC
2132], as well as the need for one option whose proposing
Internet-Draft expired.
As a result of that debate, the authors gained some insights into
the intended (or unintended!) interpretation of certain options
defined in [RFC 2132,] particularly the Vendor Class Identifier
(option 60) and Vendor Encapsulated Options (option 43.)
These insights are presented in this informational Internet-Draft,
whose reason for being is to act as an aid to implementers of the
DHC protocol, and to future editors of the underlying RFCs and
selected, current Internet-Drafts. This memo is not being
proposed as a standards-track document, but rather as an aid to
clarify existing and future RFCs.
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 1]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
Table of Contents
1. Introduction..................................................2
2. Overview......................................................2
3. Cases.........................................................3
3.1. Vendor Classing.............................................3
3.1.1. Classification Scheme.....................................3
3.1.2. Mode of Operation.........................................4
3.2. User Classing...............................................5
3.3 Client Identifiers...........................................6
3.4 Option Default Values........................................6
3.4.1 IP Stack Options...........................................7
3.4.2 Other Options..............................................7
3.5 Who Wins in a Conflict?......................................7
4. Discussion....................................................8
4.1 Vendor Classing..............................................8
4.2 User Classing...............................................22
4.3 Client Identifiers..........................................22
4.4 Option Default Values.......................................22
4.5 Who Wins in a Conflict?.....................................22
5. Acknowledgements.............................................22
6. Security Considerations......................................22
7. References...................................................23
8. Editors' Addresses...........................................23
9. Full Copyright Statement.....................................23
1. Introduction
This memo was produced by the DHCP Working Group and attempts to
identify and clarify a few specific cases where the use of client
options is not rigorously specified by the Dynamic Host
Configuration Protocol.
This memo does not cover every DHCP/BOOTP client option nor every
element of a DHCP/BOOTP request/response packet.
This memo is based on the Internet standards-track DHC protocol as
defined by documents [RFC2131 and RFC2132].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
document [RFC2119].
2. Overview
DHCP is widely used by many different vendors of computer and
networking hardware and software to provide a straightforward
means of supplying IP address and networking configuration data to
individual client hosts from DHCP servers. The Requests for
Comments (RFCs) that specify the protocol and the configuration
elements that may be specified by a DHCP message exchange have
grown significantly as the protocol has become more widely
deployed until we find ourselves in the situation we experience
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 2]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
today with nearly 100 options the network administrator can use to
perform semi-automatic configuration of client hosts. The
proliferation of options has led to a small number of cases where
the interaction among options is not rigorously specified, causing
confusion or interoperability failures. This RFC attempts to
identify some of these cases and clarify the expected behavior of
both client and server.
In this memo, the specific cases to be studied will be first
identified and, hopefully, clarified, then some of the discussion
that lead to the author's contentions about the correct use of the
client options will be presented to show the rationale for
inclusion.
At the time of writing, the authors do not know the eventual form
of the investigation that led to the production of this memo.
Three alternatives exist: (1) publication as an "informational"
RFC, (2) publication as a "best computing practices" (BCP) memo,
or (3) justification for revision of the basic DHCP RFCs. None of
these is preferred by the authors over any other. Presumably the
DHC Working Group will review and decide the best course for the
memo.
3. Cases
3.1. Vendor Classing
Vendor classing is provided through the use of options 60 (Vendor
Class Identifier) and 43 (Vendor Encapsulated Options), in
conjunction with option 55 (Parameter Request List.)
3.1.1. Classification Scheme
Vendor classing attempts to address the question of "How do I
classify a client such that the client receives appropriate
configuration data for their specific situation?" While every
deployment of DHCP will have its own unique characteristics,
consider a large organization with geographically-dispersed
locations where clients requiring DHC services may be in different
organizational entities, with different user processing functions,
and of different generations and types. It is likely that the
client population can be viewed a number of different ways, such
as:
1. Geographical ("Where is the client located?")
2. Organizational ("In which department is the client
located?")
3. Functional ("What job does the user perform?")
4. Regulatory ("What statutory constraints affect the user?")
5. Networking ("How is the client connected to other hosts?")
6. Environmental ("What software is the client using?")
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 3]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
7. Platform ("What hardware is the client using?")
Some organizations may have fewer, others more, than these
different views. Each view, especially the latter three given
above, may be further subdivided: for example, Environment might
have as many as four dimensions (operating system, TCP/IP network
stack, DHCP client, and principal application software) while
Platform most likely always has two (system manufacturer's model,
network interface vendor's model.) RFCs 2131 and 2132 do not
specifically address how many views a network administrator could
or should take of the environment under their purview, but the
underlying intent seems to be that all necessary and sufficient
information to permit informed configuration of client hosts ought
to be available for exchange and use by the clients and servers.
Where does the Vendor Class fit in the hierarchy of client views?
While it could legitimately be argued that any "vendor-supplied"
component of the client (either hardware or software) is a
candidate, one of the editors believes the proper fit is aligned
with either the TCP/IP stack or DHCP client based on the following
argument:
Network interfaces numbered in conformance with IEEE standards
contain a manufacturer's code as part of the interface's hardware
address, which is already carried in the 'chaddr' field of a BOOTP
packet. Assuming that Mike Henry's proposal for a Globally Unique
Identifier tied to specific host systems is accepted by systems
manufacturers there will be a way to completely identify [newer]
systems unambiguously. Having covered the two primary views of
the hardware platform, the remaining "vendor-supplied" components
are software (or, possibly, embedded firmware such as a writeable
control store or flash PROM.) It will be argued in the next
section that application software is a user, not vendor,
characteristic. As the underlying operating system software is
much less important for determining client networking behavior
than the choice of the TCP/IP stack or DHCP client, the editors
propose discounting operating system as a factor.
In some cases LAA devices, where the vendor's MAC address is
replaced with a Locally-Assigned Address from the range 400000
(assigned by the IEEE for local addressing), it may be necessary
to override the Globally Unique Identifier that Mike Henry is
proposing. In some environments LAAs are a requirement for in
order to effectively manage BOOTP devices. However, when talking
DHCP, we should REQUIRE the use of the Client Identifier in lieu
of the LAA, so the conflict may not be as great. (Should we also
require that the Client Identifier be configurable by an
administrator?)
3.1.2. Mode of Operation
The basic mode of operation for vendor classing is that during the
discovery phase the client broadcasts a DHCPDISCOVER message
containing Vendor Class Information (option 60) which the server
optionally uses to select an IP address and other configuration
information to offer to the client in a DHCPOFFER message. Note
the word "optionally." RFC2132 stops short of mandating any
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 4]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
specific kind of server behavior on receipt of this option. This
is not quite an oversight by the RFC editor: the editor had to
consider the possibility that any specific server might not be
configured to recognize a particular Vendor Class Identifier. As
that case is an implementation issue under control of the network
administrator, not the editor, any server response MUST be
optional.
Let's continue by assuming that the server has been configured to
recognize the Vendor Class Identifier sent by the client, and has
stored some specific data to be used to configure any client
belonging to that class. What does the server do? There are
essentially three approaches: use the Vendor Encapsulated Options
string (option 43) to return data to the client, return data in
one of the options specified in the "Host Requirements" RFC [must
supply RFC number here û ed.], or return data in some other
option.
Which approach is correct? Actually, all of them are! The one
chosen by a specific client-server pairing is a matter that SHOULD
be specified by the vendor who declares the need for vendor-
specific options data. While no hard and fast rules apply,
generally, if the data to be returned is covered by the Host
Requirements, it SHOULD be returned in the proper option. If not
covered by Host Requirements, but is covered by another, existing
option, that option should be used. The Vendor Encapsulated
Options string should be used for data that fits within the
limitations of a BOOTP/DHCP option field (0-255 octets) that
doesn't also fit any other existing option. Note that except for
options necessitated by the Host Requirements, the option number
of the correct option(s) MUST be included in the Parameter Request
List (option 55) or the server has no obligation to return it to
the client.
What about longer aggregations of configuration data than will fit
in a single option? The editors are not prepared to offer a
general solution to this problem but will suggest that it may be
possible to use existing protocol facilities, such as 'file' or
'sname' to accomplish transfer of larger amounts of configuration
data. Clearly, this is an area for more study.
3.2. User Classing
User classing is provided through the use of option NN (User Class
Identifier) in conjunction with option 55. While it basically
performs a similar function to vendor classing, it differs in one
major respect: there is no User Encapsulated Options data
specified for DHCP.
The history of User Classing is a bit murky. First proposed (if
our memory is correct!) by Glenn Stump, the Internet-Draft of this
option was allowed to expire, then it was resurrected to the
objections of some members of the Working Group, and has again
fallen into limbo. The editors believe it continues to have value
and should be reinstated. An example will hopefully illustrate:
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 5]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
Suppose your organization operates a large call center, large
enough to warrant its own tandem switch which contains an adjunct
processor that includes DNS service for client workstations
matching client telephone sets. Further, suppose that in order to
perform database lookup of customer data based on incoming
Automatic Number Identification data and answer incoming calls
with 400 milliseconds, there is an insufficient time budget to
perform certain functions such as dynamic DNS update or even
dynamic assignment of IP addresses for newly-activated clients.
This entire group of clients are a natural grouping whose user
characteristics differ considerably from all others within your
organization. At the very minimum, they should be associated with
the adjunct DNS server rather than your organization's primary DNS
servers. Perhaps they are to be given a unique Domain Name.
The editors are neutral as to whether or not the User Class
Identifier option should have a corresponding User Encapsulated
Options String option, similar to option 43, but do believe that
the User Class Identifier should be part of the DHCP options
universe.
3.3 Client Identifiers
The DHCP Client Identifier (option 63) is specified in RFC2131 as
the primary key for locating IP address leases by both client and
server, yet considerable misunderstanding remains about this
option. Specific issues concern the uniqueness of the Client
Identifier and how the uniqueness influences selection of an IP
address lease to offer a client.
An early design decision for DHCP was to require the Client
Identifier to be unique only within a network segment. This
design choice permits roaming by mobile clients among a group of
disjoint subnets, and is a major convenience for implementers of
DHCP. Enlarging the scope of uniqueness for the Client Identifier
would "break" many existing installations, so is considered to be
"out-of-bounds" for future discussion.
As mentioned in section 3.1, Mike Henry of Intel Corporation
proposed a Globally Unique Identifier to the DHC Working group for
those instances where a unique identifier with scope greater than
a network segment is required.
Also, as mentioned in section 3.1.1, the editors believe that
providing an administrator the ability to configure the Client
Identifier may be a desirable feature for clients, especially if
the Globally Unique Identifier (tied to non-accessible hardware
identification) is available, and User Classing is not. This
would permit finer control of DHCP-supplied client configurations
by permitting more precise identification of the group to which a
particular client belongs.
3.4 Option Default Values
What happens when either the client does not request an option
essential to its operation, or the server is not configured to
provide that data (through oversight or administrative error)?
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 6]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
Are there reasonable default values that can be recommended for
specific options? While some values may be suggested [or
required] by Host Requirements and other RFCs, the editors believe
than a generally-accepted set of defaults that may be assumed by a
client or server deserves some additional study.
3.4.1 IP Stack Options
The editors know of very few DHCP clients that actually request
"path-mtu-discovery", but the host requirements RFCs state a
"reasonable" default for this value. Here there is a conflict
between the virtues of brevity, that is, supplying clients with
the smallest set of options necessary to begin functioning as a
host on the network, and the desirability of requiring minimal
assumed values by clients. The editors have encountered several
clients that were badly implemented, calling for every option (all
254!) in a Parameter Request List because they made no attempt to
understand or resolve the Host Requirements.
A related question is whether a DHCP server SHOULD send options it
knows to be required for successful operation (e.g., Router
Address) even if the client does not request them? The editors
know that many servers do send a minimal list of options, but is
there any need for agreement as to what constitutes a minimum set?
3.4.2 Other Options
Aside for options whose presence is required by various RFCs
(e.g., DHCP Message Type) is there any need to identify a minimal
set of other options to provide a client? Is there any need to
codify default values for options not mandated by the RFCs?
3.5 Who Wins in a Conflict?
In many of the Internet protocols, there are well-established
rules for settling conflicts that may arise in operation, for
example, the "lowest bid wins" rule often applies for durations or
lifetimes. When considering DHCP client options, can a consistent
and defensible set of guidelines or rules be established to
determine whether the client or server "wins" when a conflict
arises?
Taking the example of lease duration, the server is required only
to offer a lease to a client that is of satisfactory duration to
the serverù if the client wants a longer lease, it merely chooses
not to request assignment of the offered lease. The assumption is
that the client can choose among competing offers, selecting the
one it prefers. Is there any need to recommend client behavior if
it should not like any of the offered leases.
The editors believe it is important to recommend client behavior
upon non-acceptance of an IP lease. Some sites have defined this
behavior for their clients, especially in reference to IPv4
autoconfiguration (not-enforceable until the clients actually
honor the new DHCP "do not autoconfigure" option), but is a
general policy appropriate?
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 7]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
The editors suggest the following client behavior: If a client is
offered a lease without acceptable parameters, but still allows
IP-level connectivity to function, the client MUST accept the. If
the client does not get a lease or if it is told not to configure
the IP stack, the client MAY continue trying at the standard
exponential backoff intervals as specified in RFC 2131.
For many administrators it is crucial that clients accept valid
leases offered to them: Failure to do so may result in a non-
functioning client. The editors are undecided if it is a good or
poor idea to permit clients to suggest values for options such as
the DNS Server, but we are in agreement that if a client were to
refuse all offered leases because a critical parameter didn't
satisfy the client's notion of what it was willing to accept, then
chaos would reign in the network.
4. Discussion
4.1 Vendor Classing
The following discussion took place on the ISC dhcp-server mailing
list during June, July and August of 1999, and has been edited
considerably to preserve the context of each comment while
eliminating unnecessary remarks:
[Bahman Sistany]
I have been looking for any "published" vendor-specific options by
vendors and I cannot find any. Does anyone know of a situation
where these options are being used (i.e., requested by a DHCP
client and their values returned by a DHCP server?)
The ISC dhcpd ignores any unrecognized options such as Vendor
Specific Options as the protocol suggests it can do. But if the
server were to return values for these options it would need to
know about them in advance. That's what I mean by "published"
above.
[Mike Henry]
The PXE specification from Intel addresses this area. At
http://developer.intel.com/ial/wfm/tools/index.htm you can find
specifications (including a generally useful set of vendor-
specific options), source code and binaries for the NT and Linux
environments to provide proxies for DHCP services not capable of
parsing Option 60, and the same for a boot service (daemon) to
allow a heterogeneous set of bootservers for the booting client to
choose from.
[unknown]
Sun JavaStations, the Solaris 7 boot system (I think), the Solaris
8 boot system (definitely), Sun workstation network boot ROMS....
You're probably seeing a pattern here. I think vendors other than
Sun are using vendor encapsulated options, but I don't know of any
off the top of my head.
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 8]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
[Nathan Lane]
Unfortunately, there is a great lack of understanding in the
industry what these options are for. I know of one thin client
vendor that packs in the parameter request list ALL 127 site-
specific options (128 through 254) then parses each one to see if
their magic cookie is in the data of each option. Just off the top
of my head, it looks to me like a vendor should send in the
parameter request list option 60, vendor class identifier and then
the server should respond with the information in option 43 (data
which is totally opaque to the server.) Is this everyone else's
understanding of how it should operate?
[Ted Lemon]
It's mine, anyway.
[Stuart Stevens]
It is my understanding that Windows 2000 will support 3 vendor
options (1-3) and the Windows 2000 DHCP server is already
programmed for these vendor options. I am not aware of these
options being published.
I thought that option 43 is more appropriate for the parameter
request list.
[Ted Lemon]
The client should send option 60 and request option 43 in the
parameter request list.
[unknown]
The ISC DHCP server needs to know about them before the first
client requests one, but since you can define them in the
configuration file, it's not the case that the server needs to
have them compiled in or anything like that.
[Nathan Lane]
[Client] behavior, at least to me, seems well-defined in RFCs
2131, 2132 and 1497. Our "site specific" option space, 128
through 254, is being polluted by vendors who don't understand or
won't use vendor specific codes.
[Barr Hibbs]
I've seen the "request all" behavior from both Linux and thin
clients, and I wonder why they are so clueless...
I'm not sure how the association between vendor class identifier
(60) and vendor encapsulated options (43) can be inferred -- I see
lots of clients send me option 43, but they almost never request
it!
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 9]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
I've also had thin client vendors tell me that I should "capture"
the data sent in option 43 and return it to them when requested!
This may be an area where the RFCs need to be reworded.
[Dave Gotwisner]
The only problem with using option 43 (or options 128-254) for the
vendor specific options, as I understand it, is that option 43 is
of the same format as the rest of the option space (i.e., a series
of option numbers, followed by lengths and data) and there is no
definition that states what vendors use what codes. If the DHCP
server is not smart enough to send different option 43's (or any
other option) based upon a vendor or client ID (note, this would
typically need to be a wild-carded selection, since otherwise you
hit the same problems of the old bootptab format -- proliferation
of entries because of MAC values). ISC MAY be smart enough to be
configured this way. Microsoft's DHCP server is not, at least
without having to do a lot of work to get around their UI.
As someone else said, Microsoft 2000 is using vendor options 1, 2,
and 3. Assuming this is correct, how do you deal with someone
else who is also defining their device to look for these options
(for completely different purposes), especially when both are
deployed in the corporate environment?
RFC 2132 says that options 128 to 254 are reserved for site
specific options. Vendors can read this two ways. I read it one
way, Nathan, another. Is the site specificity specifically for
the end user to use, or is it for manufacturers to provide
optional capabilities (outside of RFC 2132) which a site may use
if they want those capabilities? If I want to guarantee that I
don't step on another vendor's custom option, the only way I can
do it is to submit a set of options (via RFC) and go through the
review process. This may be the best way, but the under option
128 space is filling up, and I don't think it is appropriate for
each vendor to reserve blocks of a very limited space for their
stuff (just look at some of the options already reserved (10, 14,
16, 68, 75, and 76 all come to mind)). Novell submitted their own
set of options in RFC 2241 using 85 and 86.
We are a vendor. We make network terminals and Windows-based
terminals. We have several different product lines, all of which
want a different set of data for configuration. Our customer base
has stated that they want to use DHCP to be able to configure the
devices for ease of use. Many have also demanded plug and play
capability -- you connect the device to your network and turn it
on, everything that you need for running the device the way the
customer wants autoconfigures itself from the network.
Some of our products hard code the set of options (in 128-254)
that they use, and once the terminal comes up, you can configure
it. If our choice of defaults is acceptable (i.e., doesn't
conflict with other devices in the customer's environment) no
other configuration need be done with respect to the DHCP set of
options.
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 10]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
Our other products use string tags (TAG = value) with a custom tag
prefix, which we put anywhere in the 128-254 option space. This
allows the administrator to chose what options he/she wants to
support and to guarantee that there isn't a conflict with other
devices in the environment from the DHCP server side.
Unfortunately, this approach forced us to request (via option 43)
all options in 128-254.
Neither is a good solution. Unfortunately, there is no way to
really protect against two devices (from two different vendors)
from wanting the same option number for different purposes,
whether they are through option 60 (in encapsulated form) or in
128-254.
DHCP servers which are smart enough (or configurable enough) to
provide different data based upon Vendor ID, Client ID, or some
other tag would do a great deal to reduce the problem, but not all
DHCP server vendors do this.
Of course, servers which only support the minimum record size and
fail to support Option Overload further exacerbate the problem.
Also, clients which support option 18 (Extensions Path) would also
help, especially if the format of this option lent itself to
editing the file. Unfortunately, many clients fail to support it
without going outside the client.
[David Corlette]
Excellent points all, but it seems to me that there are lots of
ways around the problems stated. For instance, why not pick a
single option, register it so no other vendor "steps" on it, and
then have that option contain the address of a server that can
distribute configuration information for your terminals? As I
understand it, this is similar to the TFTP server option; indeed,
you could probably use that one if need be.
As for the configuration server, you could quite quickly write one
up, as all it really needs to do is be a FTP or TFTP server, maybe
with some custom code to detect what type of terminal is
requesting. Release the server as source code; it can run on
the same machine as the DHCP server, and you could provide
precompiled binaries for the major platforms.
This is how many other terminals and machines autoconfigure, why
not yours? I'm sure there are other ways to deal with the issue,
all of which avoid the overuse/misuse of the ill-defined vendor
option codes. I mention the above only as an example of how
simple it would be to limit your use of option codes to a single,
already defined one.
[Brian Murrell]
You have to tell the server [which clients] are what kind [of
devices]. This is how Merit RADIUS deals with the same problem in
the "vendor-defined attribute" space. You tell it that a device
is (say) a Livingston Portmaster and it uses the Livingston
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 11]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
attribute space. You tell it that a device is an Ascend TNT and
it uses the Ascend attribute space. This is quite manageable for
things like NAS. Doing the same in a DHCP environment does get a
whole lot uglier, I will admit. Perhaps the use of Client
Identifiers will help this situation out. Perhaps vendors should
be identifying themselves in the Client Identifier and that can be
keyed (via wild cards, perhaps) to a vendor option space.
How about clients that do the same thing [support only the minimum
packet size]?
[Ted Lemon]
The option codes in [option 43] are reserved for the vendor's use.
Every DHCP server of which I am aware, with one possible
exception, is capable of returning different values based on the
value in option 60 that the vendor sends.
[Dave Gotwisner]
If you can tailor option 43 based upon what option 60 sends, you
should also be able to tailor what other options get sent, since
you may want to use a different Boot File (option 13), swap server
(option 16), extensions path (option 18), maximum record size
(option 57), etc. Likewise, you should be able to send different
128-254 based upon option 60. Option 43 is limited in that it
can't span the standard space + sname + file space's, individual
options can span them.
[Ted Lemon]
This isn't a practical limitation, as long as you negotiate for a
large DHCP packet using the Maximum Message Size option. You
aren't hoping to stuff your complete terminal configuration into a
DHCP packet, I hope!
[Dave Gotwisner]
My issue is that [one vendor] uses vendor option 1, [a second]
uses vendor option 1, [a third] uses vendor option 1. Without a
smart server capable of triggering based upon option 60 (or
equivalent), a site that uses all three products may get incorrect
behavior on two of them, maybe even disastrous behavior making the
device unusable.
[Ted Lemon]
The protocol specifically states that option one in the vendor
option data is different for every vendor.
[Barr Hibbs]
Some of the problems [we've experienced with client
implementations include;]
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 12]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
1. Clients would send five or six options in the 128-254 range in
discover packets, and if we didn't return those in an ack
packet, they would immediately cycle back to discover, without
issuing a release, effectively abandoning the lease. Of
course, they were offered the same lease again, and so we
cycled endlessly, never committing a lease to the client....
2. If we didn't return options 58 and 59 (T1 and T2 values) they
dropped into INIT-REBOOT state every 60 seconds and sent a new
request packet.
3. Clients expected the TFTP server option to contain the address
of the Winterm server. Curious, but not really a problem, just
a misinformed use of the option.
4. lients complained when we didn't return hostname, even though
it wasn't in the parameter request list. [The vendor] never
budged on this one, completely ignoring the RFCs, including
host requirements.
5. [One vendor] insisted that RFC2131 wasn't compliant with
RFC1541 and refused to acknowledge that 2131 superseded 1541.
[Nathan Lane]
[One vendor] wouldn't use the "swap-server" option because they
felt it was reserved for use by Sun Microsystems. They wouldn't
use the "rootpath" option because it didn't exactly specify the
swap path file (wouldn't conventional use be to append rootpath
with "client-name.swapfile" or something like what Sun used to do
with that option?)
[Mike Henry]
Interesting -- the fuzziness in this area (option 60 and option
43) is surprising, but in retrospect it certainly explains a bit
of our confusion about guidance received in this area that didn't
seem to match our reading of the specification. But then, we
weren't very confident of our reading in the first place because
the spec did not seem to be completely clear.
My reading of the text for option 43 (see below) is that the
client is expected to use option 43 to send information about
itself to the DHCP server and the DHCP server is expected use
option 43 to send configuration information to the client that is
specific to the client's vendor class. In both cases, the
information in option 43 is specific to the vendor class indicated
in option 60. Is this interpretation incorrect? Are there DHCP
servers that actually parse incoming option 43?
The general direction we have been given is to embed client-
specific information in the Vendor Class Identifier (option 60).
This clearly can be made to work, but embedding a number of
attributes in option 60 leads to creation of ad hoc formats for
what amount to encapsulated options. Setting aside for a moment
current DHCP service implementation, it seems like it would be
more logical to put this "subclass" information into option 43 and
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 13]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
leave option 60 to define the general class. This seems to be
what option 43 text is saying. Am I misinterpreting the option 43
text?
Finally, taking the option 60 and option 43 text together, my
impression is that the DHCP service is supposed to know what to do
with option 60, but option 43 is opaque, to be interpreted by
vendor specific code. Does this imply that DHCP services should
have some means of plugging in vendor specific code to interpret
option 43 and, presumably, generate the option 43 response to the
client? Also, it seems to imply that the DHCP service should hand
off processing to the vendor supplied code if the DHCP service
sees an option 60!
[Bahman Sistany]
As far as I can tell, you are almost right. Here's my
correction(s). Someone else will correct me if I misunderstand
Vendor specific options as well. The client wants a specific
vendor's options, say, vendor1. Here is part of what he'll send
the server:
option code, length, value
60 7 vendor1
55 1 43
So this means I am [requesting vendor-specific options] for
vendor1. The server should have something like the following in
its config file:
vendor1 data1
vendor2 data2
...
When the server receives the request, it will send data1 in
encapsulated form using option 43:
option code, length, value
43 len(data1) data1
Note that like you said data1 is opaque as far as the server is
concerned and the client who asked for [the option data] should be
able to interpret [the option] on its own. The server doesn't
really care about this part though.
Here's a question on something related: My understanding is that
the client can ask for specific options using option 55 (parameter
request). The server doesn't have to supply those though. Also
the server can send arbitrary options (not requested by the
client) and the client can pick and choose among them or not use
any of them at all. Is this right?
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 14]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
[Mike Henry]
Thanks, but I am afraid you only addressed the well-known half of
the question. There is no doubt the DHCP service returns
information to the client in encapsulated options in Option 43.
However, the part I am really interested in is whether real "live"
DHCP services have the ability to make use of encapsulated options
within Option 43 that the client sends to the DHCP service. RFC
2132 seems to clearly say this is expected use of Option 43, but I
am not aware of a DHCP service actually capable of providing this
functionality.
Here is the 2132 text:
"This option is used by clients and servers to exchange vendor-
specific information. The information is an opaque object of n
octets, presumably interpreted by vendor-specific code on the
clients and servers."
[Bahman Sistany]
You are right in interpreting the protocol (I reread it again and
compared it to RADIUS which in a very limited sense is a similar
protocol). However, I have not heard of any DHCP servers that
would actually use vs. info sent by the client (they ignore it [as
permitted by the RFC.]) If a server has to use this info, then
like you said it would have to load some [vendor-specific] code
based on the value of option 60.
[Barr Hibbs]
Am I correct that what Mike and Bahman are asserting is that a
DHCP server should not only accept option 43 from a client but
should also do "something" with the received data? Does that
"something" specifically include, in your understanding, returning
the encapsulated data, verbatim, to the client if the client
requests that option 43 be returned by its inclusion in the
parameter request list?
While that is certainly possible, I wonder if that is the "right
thing" to do because of the Pandora's box that it opens: I've
already had problems, as Nathan has, with thin-client vendors who
think that a DHCP server should be an external data store for a
client. If your view of a server's role is to receive, store, and
replay encapsulated data using option 43, then I don't know how we
could prevent similar interpretations of a server's role for most
other options.
I also wonder how you might resolve potential configuration and
usage problems: suppose a server is configured with a specific
set of vendor-encapsulated options for a specific vendor-class
identifier and the client sends additional or different
encapsulated options to the server as part of the protocol
exchange -- what does the server do?
Finally, I wonder what was intended by the RFC text that Mike
quotes, as it does seem to imply that a server ought to be able to
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 15]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
take some action based on the receipt of vendor encapsulated
options.
[Kevin Bracey]
As I understand it, the logic looks like this: The client MAY
send option 60, vendor class. If it does, it may also send option
43, vendor specific options.
If the server gets option 60, and recognizes the vendor class:
1. Process the vendor specific options in a vendor-specific way
(specific to the vendor class of the client). This may affect
what is returned. For example, you might have a vendor specific
option for a device to specify its memory size, which might
lead the server to return a different boot file.
2. Return any standard options suitable for that vendor class.
3. Put any vendor-specific options for the client in option 43.
Option 43 can mean anything the client wants, in either direction
-- what it means depends on the vendor class. The suboptions
could be totally different in the two directions, although that
would probably be a bad design decision.
The behavior you describe of "storing" option 43 would be one
permissible use of it, as "vendor-specific" allows anything. It
would take more than a [server configuration] tweak to achieve
that though, and it would have to be a particular behavior invoked
only for certain known vendor classes.
[Barr Hibbs]
This gets to the heart of the issue that Mike Henry raised!
...just what does "Process the ... options ..." actually mean to
you (and anyone else who wishes to comment)? If you are
suggesting that an arbitrary server must somehow not only be
configured to identify the vendor class but also perform some
vendor-specific processing on the encapsulated options which may
have been sent by the client, just how does the vendor/ user/
administrator "know" what processing to perform? Do you imagine
that a vendor would develop "plug-ins" for popular DHCP servers?
Would DHCP servers be required to publish an API to permit plug-
ins? Do you expect that IETF would codify the interface in an
RFC? This gets nasty "real quick now!"
...I have no problem at all with option 43 containing opaque
values, which is the current state of RFC 2132, for the server to
return from its configuration to a client when requested, but if
you are suggesting that the server somehow accepts one set for
some purpose then returns another set, I really would have to see
a convincing argument to support that.... I think it would be an
implementation nightmare with very, very few benefits to offset
the monumental headaches.
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 16]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
...my specific objection to storing, then replaying, any option
(not just 43) is that such behavior turns the DHCP server from an
information provider to a limited file server or database system,
neither of which is an appropriate use for a service which is
intended only to provide the networking configuration for
acceptable clients. My servers support over 118,000 clients: if
I had to store up to 255 bytes of data for 254 options for all of
my clients, then the additional storage requirement for my servers
could be as great as 7.6 Gbytes! This is because I don't believe
you could prevent nearly every option from being used this way:
after all, why couldn't a client "suggest" which name servers or
routers it prefers to use?
This is a great deal more than merely tweaking [the server
configuration] -- it is, I believe, a complete change in the way
some of us believe a DHCP service should operate. If a client
really needs a file service to save data between reboots, then it
should do so with some server intended to be a data repository,
not try to piggy-back onto DHCP, which really is not intended for
that purpose. I also can't imagine how any DHCP server could
effectively implement per-vendor processing of options where the
server actually manipulates what is supposed to be opaque data
(option 43).
[Nathan Lane]
I can see this need [to process vendor-specific options in a
vendor-specific way.] I think there must be a better or different
way.
Yes, the DHCP server does indeed know how to process vendor class
options on a vendor by vendor basis and will pick a vendor
specific option 43 to send only to that vendor's product. It does
NOT get as complicated as you mention, though, in my opinion. The
server designer and implementer must actually communicate with the
developer implementing the device and get the specifications and
requirements from the vendor. No more can a device implementer
envision that DHCP only provides an IP address. It is the host
configuration protocol, so it reasons that one should use it to
configure as much as possible in the device that relates to its
network configuration and connectivity. It sure does make a
server implementer's job much more complex, but I think it is a
reasonable step to take. The device implementer's desires are for
"plug and play network". I feel DHCP's job is to facilitate that
idea.
I feel it is absolutely not the DHCP server's responsibility to
actually touch or process any data within option 43 and, according
to my interpretation of the RFCs, the client has no business even
sending an option 43.
[It should] not be necessary [that a vendor develop "plug-ins" for
popular DHCP servers.] A vendor class would become a fairly
overloaded field, but I think it is appropriate in this example. I
see the configuration like this (pseudo code):
if [ vendor-class-identifier = "SUN-JAVASTATION-8MB" ]
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 17]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
then send option-43
"sun-specific-data-for-an-8MB-javastation"
else
if ....
endif
endif
# resume normal option processing to build the
# rest of the response packet.
Yes, this would require most servers out there right now to be
modified and a scripting like language possibly be established.
It is not the IETF's job to specify any DHCP vendor's API or
interface [to a DHCP server to permit "plug-ins."] Perhaps the
IETF should specify how a DHCP server should make the information
available to an externalized process (I'm not using externalized
to mean a callout; just generically) or script language. I
believe the ISC server's direction is to make some kind of
embedded language available for just this type of thing. It is
nearing a requirement in my environment that servers do implement
some kind of regular expression pattern matching on DHCP input
packets and intelligently decide, via external policy lookups,
what should be done with the device. It is much more than just
"to give an IP or not to give an IP."
I really do not see option 43 as a bi-directional communications
channel. It is one way only.
No, I don't support [storing, then replaying any option] either. A
DHCP server is not a little 255 byte or so data store the client
can use to stash that information. However, if I have a vendor
class of "SUN-JAVASTATION," I DO want to be able to send a pre-
configured option 43 to the client.
Again, no way. I [also] couldn't support a client suggesting what
it wanted [for every option] -- that would be mighty presumptuous
of it!
I don't see the server as actually manipulating the opaque data.
I see the server intelligently choosing which set of opaque data
to send to which set of vendor classes.
I strongly think it is time to clarify the clarifications in
regards to vendor encapsulated options and their behavior. I
think we should take this to DHC and start working up a draft. I
have a good base for one that is an internal document I'm
completing describing our internal requirements for a DHCP client.
[Nicolas Williams]
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 18]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
DHCP's original purpose was to allow clients to obtain a
reasonably small set of configuration information needed to
connect to a network and where the clients know nothing more than
a simple Client Identifier which can be as simple as the vendor
provided hardware address of the vendor provided network
interface.
This "small set of configuration information" means network
address and routing configuration + name service configuration +
[optionally] boot file server and path. The client can go from
there.
It would be best if DHCP continued to do nothing more than that.
If any software on the client needs to be configured beyond the
above, then a different protocol should then be used to retrieve
the information from a configuration server; this is much easier
to do when a client has become a full-fledged node in a network
and there's no excuse for a client not to be able to do this today
via DHCP.
What's missing is an open protocol and data format standard for
storing, administering and obtaining post-DHCP configuration
information. Some platforms offer their own system to do this,
usually based on a proprietary name service system; I'm thinking
of NetInfo (for NextStep/OpenStep/MacOS), NIS/NIS+ (Sun et. al.),
Active Directory (Microsoft, Cisco), even flat files (for poor
administrators).
[It] is reasonable [not to expect the server as actually
manipulating opaque data,] but there will always be people for
whom it's not enough.
[Barr Hibbs]
The pseudo-code fragment from Nathan's note is a pretty concise
statement of how I believe that options 60 and 43 should interact.
Given that, I imagine that it is a vendor's responsibility to
offer network administrators something like the following:
"PDQ tiny-stations (tm) identify themselves to a DHCP server by
sending a vendor class identifier (option 60) that specifically
names the tiny-station sending the request. Series 100's send the
string 'pdq-tiny-station-100' while series 250's send the string
'pdq-tiny-station-250.' If your tiny-station series 100 contains
the optional writeable control store (model 103) your DHCP server
should return the hex value '30:cf:12:59:72:21' as a vendor
encapsulated option 43...."
Then it would be the responsibility of the network administration
to ensure that, like most other bits and pieces of configuration
data, the precise vendor encapsulated option (if any) for a
specific vendor class identifier is included in the server
configuration.
I also agree that the vendor class identifier could be used in
similar ways with other options, for example:
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 19]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
if [ vendor-class-identifier = "SONY Playstation SE"
then
send interface-mtu 768
endif
I believe that is a consistent use of the class identifier as
well.
I think we are actually closing on the essential points here.
I'll have to defer to Ralph about original purposes, but I do
generally concur that DHCP is not really intended to do anything
other than configure the networking software in a host computer.
Whatever the protocol options may have grown to include, the
process for getting there is well understood and very public, so
unless there is a compelling need such as inability to
interoperate or insufficient options to communicate required
information, we pretty much have to live with what we've got.
I'm all for (1) configuring the networking software, (2)
identifying servers which can provide extended system
configuration, and (3) identifying services location servers which
can locate applications or generally useful services for a host
computer. I think (2) and (3) are consistent with my
understanding of the purposes of DHCP. I'm not so keen on
providing application-specific configuration data or locating
individual application-specific configuration servers, but only
because I can imagine these growing in number almost without
limit. A lot of this discussion really should be moved to the
dhcpv4 mailing list, as most implementers follow that list.
I generally support the more general configuration of client
software beyond network configuration, although I would add the
restriction that some other source of this configuration
*referral* data other than the DHCP server be used. What I mean by
that is that instead of the DHCP server having an option for each
of the dozens or thousands of applications which might like to
receive configuration data from a server, that it might be a
better choice to devise something akin to the Service Location
protocol to provide the address of individual configuration
servers -- all the DHCP server would do is to identify the
"application configuration locator" server.
The proper forum for this is the DHC Working Group of IETF --
possibly a BOF session at the next working groups meeting to
determine if there is interest, then either the formation of a new
working group or incorporation of this work item into an existing
group's charter.
[Dave Gotwisner]
Nathan is dead on with [his contention that DHCP should be able to
be used to configure as much as possible in the client,] although
it isn't just the implementers who desire plug and play. Many of
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 20]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
our customers are requiring that DHCP be used in many different
methods to configure our devices so the user/ administrator does
not have to configure them once deployed. They want to turn on the
power and let DHCP provided all useful information to configure
the device. Unfortunately, with the UDP packet length, this can't
really happen on complex devices, but an appropriate sub-set can
be used. Other methods are better for plug and play configuration
in some ways and worse in some ways (SNMP comes to mind). With
plug-and-play of complex devices being configured through option
43, you run into two fundamental problems. First, the UDP maximum
record size (option 57 may allow an increase in size, but not
significantly). Second, option 43 is limited to 255 bytes in
length, and if you encapsulate several strings (such as network
pathnames) you will exceed this length for option 43.
My only other objection to option 43 (and option 18, for that
matter) is that it is a bear to create an opaque option containing
a heterogeneous set of option types. It makes perfect sense to
send it as encapsulated data, but the tools should be smarter in
how to deal with it, maybe as (expanding on Nathan's pseudo-code
below):
if [ vendor-class-identifier = "SUN-JAVASTATION-8MB" ]
then send option-43 {
send vendor-option-1
{ IP = 10.2.1.2,10.2.1.3 },
send vendor-option-2 { STR = "string-data"},
send vendor-option-3 { STR = "more-string-data" },
send vendor-option-30 { BOOL = True };
};
else
....
endif
This may be harder to parse, but it would make it a lot easier to
configure by a user.
I understand that option 43 should be [used for responses] as
illustrated above. What I don't understand is why you can't also
send different other options in this case also
send option-48 (X font server)
send option-49 (XDMCP addresses)
or other options as well, since you might want a different set of
fonts loaded (for example) based upon which manufacturer's X
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 21]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
terminal you are booting. Although the RFC says that an 43 should
be given based upon option 60, it does not say that other options
can't be given as well.
There are some options which a client can suggest (requested IP,
requested lease time, max record size, host name (only because the
server can also provide one), and option overload). I don't know
why a device which has no knowledge of it's global environment can
request DNS, routers, etc.
[Nathan Lane]
I should have put that (sending options other than 43) in my
example since Kevin specifically mentioned a different bootfile.
Do you think we should take this over to DHC and get something
going on it? We all have access to the same RFCs...I just wonder
why people have such a broad interpretation of how they should be
used.
[C. J. Consodine]
Any "intelligent" complication should be in the code TFTP'd to the
client, not in that executed by the DHCP server. Option 60 should
contain a UPC or other SKU or SKU class identifier. The logic
then is to add on additional options found via option 60,
subordinate to those options that would have been sent without it.
One needs but a single pass through the rule base. The
alternative is to add in CGI, Java or DLL like madness.
5. Acknowledgements
This document is the result of work undertaken the by DHCP working
group. The authors would like to particularly acknowledge the
development team from Carnegie-Mellon University whose work
creating a private MIB for their DHCP server inspired the
development of this proposal. In particular, many thanks to Ryan
Troll who provided a great deal of useful feedback during the
development of this MIB.
6. Security Considerations
Security considerations are not applicable, as this memo does not
specify the interoperation of network equipment or systems, merely
seeking to codify some elements of behavior not well specified by
the underlying protocol.
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 22]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
7. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
8. Editors' Addresses
Richard Barr Hibbs
Pacific Bell
666 Folsom Street, Room 1225
San Francisco, CA 94107-1384
USA
Phone: +1 415-545-1576
Fax: +1 415-543-3539
Email: rbhibbs@pacbell.com
Nathan Lane
Wal-Mart Stores, Inc.
702 SW 8th Street
Bentonville, AR 72716-8025
USA
Phone: +1 501-277-5786
Fax: +1 501-273-6879
Email: nathan@terminus.com
9. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 23]
Network Working Group R. B. Hibbs, Pacific*Bell
Internet-Draft N. Lane, Wal-Mart Stores
Category: Informational Oct 1999
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Hibbs & Lane Expires: Oct 1999 + 6 months [Page 24]
