DHC Markus Rentschler Internet Draft Hirschmann Electronics Expires: April 2004 November 2003 DHCP Discovery Extensions 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. This Internet-Draft will expire on April 30, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The discovery mechanism described here is built upon and coexists with BOOTP according to RFC 1542 and DHCP according to RFC 2131 and RFC 3203. It allows server-initiated communication to specific or all clients in the network, using the DHCP packet format and with that the relay agent functionality. The Discovery mechanism is a powerful and flexible extension to client-initiated DHCP that allows a variety of applications, for example: - Discovery and supervision of clients in the network - Server-initiated configuration of clients - DHCP server redundancy Rentschler Expires April 2004 [Page 1] Internet-Draft DHCP Discovery Extensions Nov 2003 Requirements terminology 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. Introduction Host Configuration using "traditional" DHCP according to RFC 2131 is based on host- (client-) initiated communication. If a network is booting, all the clients start sending DHCP requests until accepting an answer from a DHCP server. The server may either allocate IP addresses out of a pool of available adresses or, similar to BOOTP, pre-configured static IP addresses and configuration parameters for each known client. These concepts did not intend server-initiated and -controlled configuration or reconfiguration of clients. This capability was later partially added with RFC 3203, but the mechanism there does not allow to discover "silent" clients yet unknown to the server or trigger the configuration of such a client. This is especially limiting when a server is later plugged to an already configured network. These shortcomings will be overcome with the protocol extensions described in this document, which will provide useful functionality for centralized network administration: - scanning the network for clients even prior to their initialization with IP parameters. Building a database of all clients present in a network. - detecting and identifying duplicate network addresses - administrator controlled reconfiguration of certain clients - server redundancy mechanism The main goal of the discovery extension is to allow as much flexibility as possible for the server to communicate with the client(s) to allow a wide range of applications, which are not subject of this document. The DHCP discovery extensions may also be adopted for DHCPv6. Rentschler Expires April 2004 [Page 2] Internet-Draft DHCP Discovery Extensions Nov 2003 2. The DHCP Discovery Protocol One of the intentions of the DHCP Discovery Protocol Extension is to work with an inactive DHCP client (the client is not sending initial DHCPDISCOVER messages) to allow the configuration process be entirely performed and controlled by the administrator's management station, without having the network "spammed" with DHCPDISCOVER-Requests. The DHCP Discovery Protocol MUST also work with an active client (the client is sending initial DHCPDISCOVER messages). This server-initiated communication mechanism has basically the following modes of operation: The server sends the new DHCPNETSCAN message into the network, either as broadcast to all clients or directed to a certain client. The client responds with the new DHCPREPORT message containing the client's actual parameter settings. All servers that receive the DHCPREPORT message SHOULD use the information contained in this message to maintain their internal database (list of clients and leases). With this mechanism all available DHCP servers in the network can collect information about granted leases and can take over in the normal rebinding process if the granting server fails. For the configuration of a certain client the server sends the new DHCPCONFIGURE message to this client that MUST contains all parameters required to set the client's IP stack in operation. The client responds with a DHCPREPORT message back to the server(s) to indicate if it accepted the new configuration parameters. The DHCP client MUST maintain its internal database and MUST release an already existing lease by sending a DHCPRELEASE message, if it accepted new IP settings. The server that has granted a lease MUST be able to renew and rebind that lease. All other servers that have sufficient information about that lease in their database MAY rebind it as well to provide server redundancy. Rentschler Expires April 2004 [Page 3] Internet-Draft DHCP Discovery Extensions Nov 2003 3. New DHCP message types Three messages MUST be added to the set of existing DHCP messages: DHCPNETSCAN DHCPCONFIGURE DHCPREPORT The value of the message types -to be encoded in DHCP option 53- is left as TBD until assigned by IANA. Existing correct implementations of DHCP clients or servers SHOULD ignore and discard these new message types. To existing correct implementations of BOOTP relay agents these new message types SHOULD be transparent. 3.1 DHCPNETSCAN message The DHCPNETSCAN message is sent from a server to one client (unicast) or to all clients (broadcast). A broadcasted DHCPNETSCAN message SHOULD be broadcasted into a relay agent's other subnets. Its purpose is to request the client's actual parameter settings and report them to the server(s) by triggering a DHCPREPORT message. Field Contents ----- ------------ 'op' BOOTREPLY (RFC 2131: server to client direction) 'xid' 'xid' from server 'secs' 0 'flags' Set 'BROADCAST' flag if server requires broadcast reply 'ciaddr' 0 or client's network address 'yiaddr' 0 'siaddr' IP address of server 'giaddr' 0 or the target relay agent's interface IP adress 'chaddr' 0 or client's hardware address 'sname' unused 'file' unused 'options' 53: DHCP Message Type: DHCPNETSCAN 54: Server Identifier 55: Parameter Request List 82: Relay information option (MAY be used for path information, if a relay is involved in transportation to the client) Rentschler Expires April 2004 [Page 4] Internet-Draft DHCP Discovery Extensions Nov 2003 3.2 DHCPCONFIGURE message The DHCPCONFIGURE message is sent from a server to a certain client. Its purpose is to provide the client with new parameter settings. Field Contents ----- ------------ 'op' BOOTREPLY (RFC 2131: server to client direction) 'xid' 'xid' from server 'secs' 0 'flags' Set 'BROADCAST' flag if server requires broadcast reply 'ciaddr' 0 or client's network address 'yiaddr' IP address for client 'siaddr' IP address of server 'giaddr' 0 'chaddr' 0 or client's hardware address 'sname' Server host name or options 'file' Client boot file name or options 'options' 53: DHCP Message Type: DHCPCONFIGURE 54: Server Identifier 55: Parameter Request List additional any other option, which must then also be present in the parameter request list. It is recommended that upon ip configuration the following options SHOULD be included: 01: Subnet Mask 03: Router 51: IP address lease time 61: Client-Identifier For reconfiguration of single non-ip parameters, only the options representing these parameters are required to transmit. Rentschler Expires April 2004 [Page 5] Internet-Draft DHCP Discovery Extensions Nov 2003 3.3 DHCPREPORT message The purpose of this message is to report the client's actual parameter settings to one or all servers. It is the acknowledgement towards the server upon a DHCPNETSCAN or DHCPCONFIGURE request. The DHCPREPORT message is sent from a client to a server as broadcast or unicast, depending on the 'BROADCAST' flag in the original DHCPNETSCAN or DHCPCONFIGURE message and the state of the client's IP stack. A client that has not yet assigned a valid IP address SHOULD always broadcast this message, using 0.0.0.0 as source address and the limited broadcast address 255.255.255.255 as destination address. Field Contents ----- ------------ 'op' BOOTREQUEST (RFC 2131: client to server direction) 'xid' 'xid' from server 'secs' 0 or seconds since DHCP process started 'flags' flags from DHCPNETSCAN or DHCPNETCONIFG message 'ciaddr' 0 or client's network address 'yiaddr' IP address of client 'siaddr' 0 'giaddr' 0 'chaddr' client's hardware address 'sname' Server host name or options 'file' Client boot file name or options 'options' 53: DHCP Message Type: DHCPREPORT 54: Server Identifier 57: Maximum DHCP Message Size additional all supported options requested in DHCPNETSCAN or DHCPCONFIGURE. The client MUST omit any options it cannot provide. Rentschler Expires April 2004 [Page 6] Internet-Draft DHCP Discovery Extensions Nov 2003 4. The DHCP Server DHCP Server implementations MAY incorporate any administrative conrols or policies desired by network administrators that make use of the underlying protocol described in this and related documents. DHCP servers that support the protocol described in this document MUST be able to send DHCPNETSCAN and DHCPCONFIGURE messages, either automatically at startup, program controlled, in certain intervals and/or on manual requests. The content of the BROADCAST flag in the DHCPNETSCAN and DHCPCONFIGURE messages SHOULD be configurable and disabled by default. The DHCP server MUST be able to receive DHCPREPORT messages and SHOULD use them to verify the state of pending requests. The 'xid' field SHOULD be used by the server to match incoming DHCP messages with pending requests. Pending requests SHOULD be supervised using a timeout mechanism. The timeout value MUST be configurable and SHOULD have a default value of 4 seconds. A retransmission strategy for unacknowledged requests SHOULD be implemented. The server MAY use all received DHCPREPORT messages to build and maintain an internal database (based on IP addresses), that MAY contain all known leases in the network. This database MAY be periodically updated by sending DHCPNETSCAN messages. If a server receives a DHCPREPORT message for a lease that was granted by itself, the contents MUST be checked for consistency with the internal lease database. If any inconsistency is detected (i.e. unknown MAC address or wrong relay agent information option contents), these DHCPREPORTS MUST be ignored and their occurence MUST be reported to the administrator. It is RECOMMENDED that a timeout mechanism removes expired leases in this database. The server MUST be able to renew and rebind existing leases which were granted by itself. The server MAY be able to rebind existing leases which were not granted by itself, but are listed in its internal database as known leases. This feature should be configurable and disabled by default. If duplicate IP addresses are detected in the database, the server SHOULD report this to the administrator. If duplicate client identifiers (DHCP Option 61) are detected in the database, the server MAY report this to the administrator. Rentschler Expires April 2004 [Page 7] Internet-Draft DHCP Discovery Extensions Nov 2003 5. The DHCP Client The DHCP client needs to be modified to incorporate the handling of the new message types. The clients network interface MUST always be able to receive BOOTREPLY packets on its UDP client port (68), even if the local IP stack has not yet assigned a valid IP address. DHCPNETSCAN and DHCPCONFIGURE messages MUST always be processed, even if the local DHCP client is not active in terms of sending initial DHCPDISCOVER messages. It SHOULD be configurable whether a client is allowed to accept reconfiguration due to receipt of a DHCPCONFIGURE message from another than its initially lease-granting server. This feature SHOULD be enabled by default. It is RECOMMENDED that normal DHCP (sending initial DHCPDISCOVER messages) is enabled by default. The client MUST respond to a DHCPNETSCAN or DHCPCONFIGURE message with the message DHCPREPORT and return the requested parameters to the server. The Message DHCPREPORT contains always the client's current parameter settings. The client MUST omit any parameters it cannot provide. The sending of a broadcast DHCPREPORT message that was generated in response to a DHCPNETSCAN message SHOULD be delayed a random time interval up to 2 seconds to prevent broadcast storms on the network. DHCPNETSCAN messages that arrive in the meantime, SHOULD be silently discarded and not queued for processing. The client's handling of a received DHCPNETSCAN message SHOULD be the same in every state of the DHCP client's state machine. It SHOULD not affect the current state of the client's state machine. The receipt of a DHCPCONFIGURE message MUST result in the following actions: If the message and the parameters offered to the client are correct and acceptance of DHCPCONFIGURE is not disabled, the new parameters MUST be accepted. An existing lease MUST be terminated by sending a DHCPRELEASE message. Then the client's IP stack is initialized with the new parameters and the client sends a DHCPREPORT to the server, containing the new parameter settings. Then the DHCP client's state machine always enters the state BOUND and starts its timers T1 and T2 for the renewing/rebinding process. If any DHCP message received by the client contains a relay agent information option, this field MAY be examined for informational purposes. Rentschler Expires April 2004 [Page 8] Internet-Draft DHCP Discovery Extensions Nov 2003 6. The BOOTP Relay Agent DHCPNETSCAN messages that are received as IP broadcast on one of the relay's interfaces MUST be broadcasted in all other IP subnets accessible by this relay agent. This option SHOULD be configurable and disabled by default. DHCPNETSCAN messages that are received as IP unicast directed to one of the relay agent's IP interfaces and have the giaddr field set to the same interface address MUST be broadcasted only on the physical ports attached to this IP interface. This allows scanning of a specified subnet. This option SHOULD be configurable and disabled by default. If one of the above packets -directed to the client- has the relay agent information option present, this field SHOULD be examined. If the contents of the Agent Remote ID matches the relay agent's unique identifier (i.e. MAC, Client-Id or an IP address) AND the Agent Circuit ID suboption contains a valid physical port number, this information SHOULD be used to forward the DHCPNETSCAN message to the client. Rentschler Expires April 2004 [Page 9] Internet-Draft DHCP Discovery Extensions Nov 2003 7. Security Considerations In this section possible security attacks and prevention mechanisms will be discussed. - Denial of Service attacks through DHCPNETSCAN A bogus server may flood the network with broadcast DHCPNETSCAN messages at such a rate, that due to multiple client responses other communication will slow down. In order to keep damage low in case of such an attack, the client delays the generation of the DHCPREPORT message and discards DHCPNETSCAN messages that were received in the meantime. - Denial of Service attacks through DHCPCONFIGURE A bogus server may send DHCPCONFIGURE packets to misconfigure clients in the network. To prevent this the client incorporates a configurable mechanism that only allows reconfiguration by the initially lease-granting server. An authentication mechanism can be used to verify the integritiy of this server. - Denial of Service attacks through DHCPREPORT A bogus client may send DHCPREPORT packets into the network to misinform servers about existing leases in the network. A server that has granted a lease needs to check incoming DHCPREPORTS concerning this lease for consistency. 8. IANA Considerations The value for the new message types DHCPNETSCAN DHCPCONFIGURE DHCPREPORT must be assigned from the numbering space defined for message types in RFC 2939. Rentschler Expires April 2004 [Page 10] Internet-Draft DHCP Discovery Extensions Nov 2003 9. References RFC 1542 W. Wimer, October 1993, "Clarifications/Extensions for the Bootstrap Protocol", RFC 2131 R. Droms, March 1997, "The Dynamic Host Configuration Protocol", RFC 2939 R. Droms, September 2000, "Procedures an IANA guidelines for Definition of new DHCP Options and Message Types", RFC 3046, M. Patrick, January 2001, "DHCP Relay Agent Information Option", RFC 3118 R. Droms and W. Arbaugh, June 2001, "Authentication for DHCP Messages", RFC 3203, Y. T'Joens et. al., December 2001, "DHCP reconfigure extension", 10. Acknowledgments We Acknowledge the help of .... and all the members of the development department at Hirschmann Electronics GmbH & Co. KG. 11. Author's Address Markus Rentschler Hirschmann Electronics GmbH & Co. KG, Neckartenzlingen, Germany. Email: mrentsch@nt.hirschmann.de Full Copyright Statement Copyright (C) The Internet Society (2003). 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. Rentschler Expires April 2004 [Page 11]