DHC Markus Rentschler Internet Draft Hirschmann Electronics Expires: May 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. 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 Extensons are a powerful and flexible add-on to client-initiated DHCP that allow a variety of applications. Rentschler Expires May 2004 [Page 1] Internet-Draft DHCP Discovery Extensions Dec 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 a 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, for example: - 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 May 2004 [Page 2] Internet-Draft DHCP Discovery Extensions Dec 2003 2. The DHCP Discovery Protocol The Discovery Extensions provide a server-initiated communication mechanism that work as follows: 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. A server that receives the DHCPREPORT message SHOULD use the information contained in this message to maintain its internal database (list of clients and leases). For the configuration of a certain client the server sends the new DHCPCONFIGURE message to this client that contains all parameters that the server wishes to transfer to the client. 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 -if it accepted new IP settings- terminate an already existing lease by sending a DHCPRELEASE message towards the initially lease granting server. One of the intentions of the DHCP Discovery Extension is to work with an inactive DHCP client (in terms that 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 flooded with DHCPDISCOVER-Requests at powerup. This mode shall be referred to as SILENT MODE. In SILENT MODE The client is always ready to receive and processs the new DHCPNETSCAN and DHCPDISCOVER messages according to the procedures described in this document. In this mode the Authentication Option [RFC 3118] from a server MAY be ignored. The SILENT MODE is however only an optional mode of operation that MAY be configured on the client. Clients with limited resources MAY only implement the Discovery Extensions, therefore not supporting full DHCP functionality according to RFC 2131. The DHCP Discovery Extensions MUST also work with an active client that is sending initial DHCPDISCOVER messages. This mode shall be referred to as NORMAL MODE. In NORMAL MODE the Discovery Extensions MUST only be enabled through the DHCP Server by the new "Discovery Option" that MAY be transferred for this purpose from the server to the client. If in this mode the authentication mechanism according to RFC 3118 is used, authentication MUST also be applied to the new Discovery Extension messages. The NORMAL MODE is RECOMMENDED as default setting on the client. Rentschler Expires May 2004 [Page 3] Internet-Draft DHCP Discovery Extensions Dec 2003 3. New DHCP message types and options 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. The usage of the 'Parameter Request List' Option gets extended within the scope of this document. RFC 2131 and RFC 2132 limit the use of this option in direction from client to server. The new message types defined in this document are allowed to transfer the 'Parameter Request List' option also from server to client. 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 May 2004 [Page 4] Internet-Draft DHCP Discovery Extensions Dec 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 12: Hostname For reconfiguration of single non-ip parameters, only the options representing these parameters are required to transmit. Rentschler Expires May 2004 [Page 5] Internet-Draft DHCP Discovery Extensions Dec 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 May 2004 [Page 6] Internet-Draft DHCP Discovery Extensions Dec 2003 3.4 Discovery Option The purpose of this option is to configure and report the state of the Discovery Extensions on the client. The Discovery Option is an 8-bit number. Code Len Value +-----+-----+-----+ | TBD | 1 | a | +-----+-----+-----+ The code for this option is TBD, and its length is 1. The Discovery Option uses the following values: DiscoveryDisabled 0 DiscoveryEnabled 1 DiscoveryOnly 2 Clients that support the Discovery Extensions MUST add the Discovery Option to the list of options included in its DHCPDISCOVER and DHCPREQUEST messages. An absence of this option indicates that the client does not support the Discovery Extensions. If this option is requested by the server in a DHCPNETSCAN or DHCPCONFIGURE message, it MUST be included in the DHCPREPORT message. The server MAY include the Discovery Option in a DHCPACK message or a DHCPCONFIGURE message to configure the Discovery Extensions on the client. The value DiscoveryOnly(3) MUST be transferred from client to server to indicate that only the Discovery Extensions are supported on this client, but not full RFC 2131 functionality. In this case a server MUST always assign infinite leases. In SILENT MODE the client MAY ignore the Discovery Option sent from a server. Rentschler Expires May 2004 [Page 7] Internet-Draft DHCP Discovery Extensions Dec 2003 4. Extended DHCP state diagram +--------+ +------+ | Init / | +-->+ Init +<---------------+-------------------+ | Reboot | | +--+---+ | | +---+----+ DHCPNAK/ -/Send DHCPDISCOVER | | | Restart | (broadcast) | | | | v v-------------+ | | -/Send DHCPREQUEST| +----+------+ DHCPOFFER/DHCPDECLINE | | (broadcast)| | Selecting |----------+ | | v | +----+------+ | | +---+----+ | DHCPOFFER/DHCPREQUEST | | | Reboot +---------+ (broadcast) | | +---+----+ v | | | +----+-------+ DHCPNAK /halt network | + Requesting | | lease expired DHCPACK/ +----+-------+ | | Record lease | | | set timers DHCPACK/Record lease | | | v Set T1 & T2 | | | +--+----+DHCPFORCE +---+---+ +----+---+ +----------------->+ BOUND +---------->+ Renew +--------->+ Rebind | +--+-+--+T1 expires +-+-+---+T2 expires+----+---+ ^ /DHCPREQUEST | | /broadcast | DHCPACK to leasing | | DHCPREQUEST | | server | | | +----------------------------------------+ +----------+ +------------>+ Discover | | +-----+----+ | | | DHCPNETSCAN/Send DHCPREPORT | | | | | | | DHCPCONFIGURE/Send DHCPRELEASE if appropriate | | Send DHCPREPORT | | Record lease | | Set T1 & T2 | | Set main state = BOUND | | +-------------------+ Note: The "Discover" state is a parallel state that runs independently from the DHCP main state machine. Rentschler Expires May 2004 [Page 8] Internet-Draft DHCP Discovery Extensions Dec 2003 5. The DHCP Server DHCP Server implementations MAY incorporate any administrative controls 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 SHOULD report this to the administrator. Rentschler Expires May 2004 [Page 9] Internet-Draft DHCP Discovery Extensions Dec 2003 6. The DHCP Client The DHCP client needs to be modified to incorporate the handling of the new message types. In NORMAL MODE the use of message authentication following the procedures described in RFC 3118 is RECOMMENDED. If authentication is used, the DHCPNETSCAN and DHCPCONFIGURE messages MUST also be authenticated by the client. If the Discovery Extensions are enabled and -if applicable- proper authentication took place, the client MUST process received DHCPNETSCAN and DHCPCONFIGURE messages as described in this document. It answers these messages from the server with the message DHCPREPORT and return in it the requested parameters to the server. 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 Discovery Extensions run in their own parallel state 'Discover', that is not influenced by the client's main state. 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 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 main state machine is set to the state BOUND and starts its timers T1 and T2 for the renewing/rebinding process. Rentschler Expires May 2004 [Page 10] Internet-Draft DHCP Discovery Extensions Dec 2003 7. 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 May 2004 [Page 11] Internet-Draft DHCP Discovery Extensions Dec 2003 8. Security Considerations In this section possible security attacks and prevention mechanisms will be discussed. - Distributed 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. In NORMAL MODE an authentication mechanism [RFC 3118] SHOULD be used to verify the integrity of the server. - Denial of Service attacks through DHCPCONFIGURE A bogus server may send DHCPCONFIGURE packets to misconfigure clients in the network. In Normal MODE an authentication mechanism [RFC 3118] SHOULD be used to verify the integrity of the 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. If authentication [RFC 3118] is used, the integrity of such bogus messages can be checked and subsequently discarded. 9. IANA Considerations The value for the new message types DHCPNETSCAN DHCPCONFIGURE DHCPREPORT and the new "Discovery Option" must be assigned from the numbering space defined for message types ond options in RFC 2939. Rentschler Expires May 2004 [Page 12] Internet-Draft DHCP Discovery Extensions Dec 2003 10. 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", 11. Acknowledgments We Acknowledge the help of .... and all the members of the development department at Hirschmann Electronics GmbH & Co. KG. 12. 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 May 2004 [Page 13]