Internet DRAFT - draft-aiello-dhc-appliance-class
draft-aiello-dhc-appliance-class
DHC Working Group
Internet Draft J. Aiello
Document: draft-aiello-dhc-appliance-class-01.txt Sylantro Systems
Expires: July 2001 January 2001
Appliance Class Identifier Option for DHCP
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 rendered obsolete 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.
Table of Contents
1. Abstract........................................................2
2. Conventions used in this document...............................2
3. DHCP Terminology................................................2
4. Overview........................................................2
5. The Appliance Class Identifier Option...........................3
7. Security Considerations.........................................4
9. Acknowledgements................................................5
10. Author's Addresses.............................................5
Aiello Expires July 2001 1
Appliance Class Identifier Option January 2001
1. Abstract
The Appliance Class Identifier option is used by a Dynamic Host
Configuration Protocol (DHCP) client to identify the type of
appliance it is. The information contained in this option is an
opaque field that represents the appliance class of which the client
belongs. Based on this class, a DHCP server selects the appropriate
address pool to assign an address and the appropriate configuration
parameters to the client. The value of this option should be
selected by the appliance manufacturer and included in the DHCP
Discover/Request messages. Multiple vendors may choose to use the
same appliance class identifier for like appliances (an IP phone for
example).
2. Conventions used in this document
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 RFC-2119 [1].
3. DHCP Terminology
- "DHCP client"
A DHCP client or "client" is an Internet host using DHCP to obtain
configuration parameters such as a network address.
- "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
- "Appliance"
An appliance is a DHCP client that not what is a special function
device such as an IP phone.
- "Appliance manufacturer"
The entity who manufacturers the appliance or has it manufactured in
their name.
4. Overview
New and emerging IP based appliances (devices) may need to be
identified by DHCP servers differently than other DHCP clients.
These new appliances may require IP addresses allocated from a
separate range or subnet, forward to a different gateway, need
unique DHCP supplied options than other DHCP clients. Network
devices such as routers and firewalls will need to associate the
Aiello Expires July 2001 2
Appliance Class Identifier Option January 2001
special handling policies needed by some appliances with their IP
addresses. Some appliances may exit a sub-network using a
specialized gateway. A local network may include both private and
public addresses. In order for DHCP to meet these specializations,
client side enhancements are needed to assure rejection of incorrect
information. Server side enhancements are needed to assure that
only appropriate clients receive appliance specific address
information.
For example, an IP phone (appliance) may require an IP address that
will not be translated by the router and may require unique options
such as a Call Agent server IP address or a DNS server IP address
used exclusively for Voice over IP networks. The appliance may exit
the subnet using a low latency gateway. On the same network,
lighting and heating appliances may need private addresses. Both
Appliance Classes need separate tftpboot servers. Appliances like
these need to have separate IP address pools allocated that may or
may not be shared with other appliances.
The DHCP client identifies itself as a specific appliance class, by
this new option, to the DHCP Server. The DHCP server shall issue an
IP address allocated for that appliance type from the DHCP server.
This ensures no computer, printer, etc. receives an IP address
allocated for another appliance type. The DHCP server should
support multiple Appliance Classes.
Appliance Class differs from Vendor Class (RFC 2132), Subnet
Selection (RFC 3011) and User Class (RFC 3004)in a number of ways.
Appliance class is not vendor specific. Multiple vendors may use
the same appliance class identifier. The DHCP Client does not need
to be a priori configured to know which subnet it is intended to
reside on. Appliance class is not user definable and does not
identify a class of users. Appliances can only have one appliance
class. Servers supporting appliance class must echo the appliance
class identifier on the DHCP Offer and DHCP ACK messages. DHCP
clients must reject the Offer if the appliance class is not echoed
back on the Offer/ACK. DHCP servers must allow address pool
selection based on matching appliance class criteria. The DHCP
server may relay individual DHCP requests to specific DHCP server
based on Appliance Class without effecting whether other requests
are relayed.
5. The Appliance Class Identifier Option
The code for this option is TBD.
The Appliance Class Identifier is used by the DHCP Client to
optionally identify the appliance class it represents. A DHCP
server uses the Appliance Class Identifier to choose the IP address
pool it allocates an IP address from and to select any other
appliance specific configuration option(s).
Aiello Expires July 2001 3
Appliance Class Identifier Option January 2001
This option carries only one Appliance Class Identifier.
The DHCP server MUST return the Appliance Class Identifier in the
DHCP offer-s.
The DHCP client must reject the DHCP offer if it does not contain
the Appliance Class Identifier. Upon rejection, the DHCP client may
make a DHCP address request that does not include The Appliance
Class identifier. Using this address, the client may act as its own
relay to contact a remote DHCP server.
The format of this option is as follows:
Code Len Value
+-----+-----+-------------------------------------+
| TBD | N | Appliance Class Data |
+-----+-----+-------------------------------------+
A server not equipped to interpret the appliance class should ignore
it. The server should report the unmatched class event.
6. IANA Considerations
Option TBD has been assigned by IANA for this option.
7. Security Considerations
DHCP currently provides no authentication or security mechanisms.
Potential exposures to attack are discussed is section 7 of the
protocol specification.
This lack of authentication mechanism means that a DHCP server cannot
check if a client or user is authorized to use a given appliance
class. This introduces an obvious vulnerability when using the
appliance class option. For example, if the appliance class is used
to give out a special parameter (e.g., a particular call agent
server), there is no way to authenticate a client and it is therefore
impossible to check if a client is authorized to use this parameter.
8. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
Aiello Expires July 2001 4
Appliance Class Identifier Option January 2001
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Stump, G., "User Class Option for DHCP", RFC 3004, November
2000.
[6] Waters, G., "IPv4 Subnet Selection Option for DHCP", RFC 3011,
November 2000
9. Acknowledgements
The author would like to thank Eric Nielson for his input and
contribution.
10. Author's Addresses
Joe Aiello
Sylantro Systems
910 East Hamilton, Suite 300 Phone: 1-408-626-2300
Campbell, CA USA Email: joe.aiello@Sylantro.com
Eric Neilson
Sylantro Systems
910 East Hamilton, Suite 300 Phone: 1-408-626-2300
Campbell, CA USA Email: joe.aiello@Sylantro.com
Aiello Expires July 2001 5
