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