Dynamic Host Configuration Protocol (DHCP) Leasequery
RFC 4388
Document | Type |
RFC - Proposed Standard
(February 2006; Errata)
Updated by RFC 6148
|
|
---|---|---|---|
Authors | Richard Woundy , Kim Kinnear | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4388 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Margaret Cullen | ||
Send notices to | (None) |
Network Working Group R. Woundy Request for Comments: 4388 Comcast Cable Category: Standards Track K. Kinnear Cisco Systems February 2006 Dynamic Host Configuration Protocol (DHCP) Leasequery Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided to DHCPv4 clients. Other processes and devices that already make use of DHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information. Woundy & Kinnear Standards Track [Page 1] RFC 4388 DHCP Leasequery February 2006 Table of Contents 1. Introduction ....................................................2 2. Terminology .....................................................5 3. Background ......................................................7 4. Design Goals ....................................................7 4.1. Broadcast ARP Is Undesirable ...............................7 4.2. SNMP and LDAP Are Not Appropriate ..........................8 4.3. DHCP Relay Agent Functionality Is Common ...................8 4.4. DHCP Servers Are a Reliable Source of Location Information ................................................9 4.5. Minimal Additional Configuration Is Required ...............9 5. Protocol Overview ...............................................9 6. Protocol Details ...............................................12 6.1. Definitions Required for DHCPLEASEQUERY Processing ........12 6.2. Sending the DHCPLEASEQUERY Message ........................14 6.3. Receiving the DHCPLEASEQUERY Message ......................15 6.4. Responding to the DHCPLEASEQUERY Message ..................16 6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN Message ..................................20 6.6. Receiving No Response to the DHCPLEASEQUERY Message .......21 6.7. Lease Binding Data Storage Requirements ...................22 6.8. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers ..............................................23 7. Security Considerations ........................................23 8. IANA Considerations ............................................24 9. Acknowledgements ...............................................24 10. References ....................................................25 10.1. Normative References .....................................25 10.2. Informative References ...................................25 1. Introduction A DHCPv4 server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Sometimes devices or other processes may need access to this information. In some cases, these devices or processes already have the capability to send and receive DHCP packets, and so the leasequery protocol is designed to give these processes and devices a low-overhead way to access such information. For example, access concentrators that act as DHCP relay agents sometimes derive information important to their operation by extracting data out of the DHCP packets they forward, a process known as "gleaning". Unfortunately, the typical access concentrator loses its gleaned information when the access concentrator is rebooted or is replaced. This memo proposes that when gleaned DHCP information is not available, the access concentrator/relay agent can obtain the Woundy & Kinnear Standards Track [Page 2] RFC 4388 DHCP Leasequery February 2006 location information directly from the DHCP server(s) using the DHCPLEASEQUERY message. To continue this example in more depth, in many broadband access networks, the access concentrator needs to associate an IP address lease to the correct endpoint location, which includes knowledge of the host hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the intervening subscriberShow full document text