Dynamic Host Configuration Protocol (DHCP) Leasequery
RFC 4388

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 09

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 subscriber