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.
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
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
modem. This is particularly important when one or more IP subnets
are shared among many ports, circuits, and modems. Representative
cable and DSL environments are depicted in Figures 1 and 2 below.
+--------+ +---------------+
| DHCP | | DOCSIS CMTS |
| Server |-...-| or DVB INA |-------------------
+--------+ | (Relay Agent) | | |
+---------------+ +------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Host1| |Host2| |Host3|
+-----+ +-----+ +-----+
Figure 1: Cable Environment for DHCPLEASEQUERY
+--------+ +---------------+
| DHCP | | DSL Access | +-------+
| Server |-...-| Concentrator |-...-| DSLAM |
+--------+ | (Relay Agent) | +-------+
+---------------+ | |
+------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Host1| |Host2| |Host3|
+-----+ +-----+ +-----+
Figure 2: DSL Environment for DHCPLEASEQUERY
Knowledge of this location information can benefit the access
concentrator in several ways:
1. The access concentrator can forward traffic to the access
network using the correct access network port, down the
correct virtual circuit, through the correct modem, to the
correct hardware address.
2. The access concentrator can perform IP source address
verification of datagrams received from the access network.
The verification may be based on the datagram source hardware
address, the incoming access network port, the incoming
virtual circuit, and/or the transmitting modem.
3. The access concentrator can encrypt datagrams that can only be
decrypted by the correct modem, using mechanisms such as [BPI]
or [BPI+].
The access concentrator in this example obtains the location
information primarily from "gleaning" information from DHCP server
responses sent through the relay agent. When location information is
not available from "gleaning", e.g., because the access concentrator
has rebooted, the access concentrator can query the DHCP server(s)
for location information using the DHCPLEASEQUERY message defined in
this document.
The DHCPLEASEQUERY message is a new DHCP message type transmitted
from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware
relay agent sends the DHCPLEASEQUERY message when it needs to know
the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server
replies with a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN message. The DHCPLEASEACTIVE response to a
DHCPLEASEQUERY message allows the relay agent to determine the IP
endpoint location and the remaining duration of the IP address lease.
The DHCPLEASEUNASSIGNED is similar to a DHCPLEASEACTIVE message, but
indicates that there is no currently active lease on the resultant IP
address but that this DHCP server is authoritative for this IP
address. The DHCPLEASEUNKNOWN message indicates that the DHCP server
has no knowledge of the information specified in the query (e.g., IP
address, MAC address, or Client-identifier option).
The DHCPLEASEQUERY message does not presuppose a particular use for
the information it returns -- it is simply designed to return
information for which the DHCP server is an authoritative source to a
client that requests that information. It is designed to make it
straightforward for processes and devices that already interpret DHCP
packets to access information from the DHCP server.
This document specifies an extension specifically to the DHCPv4
protocol [RFC2131]. Given the nature of the DHCPv6 protocol
[RFC3315], there is no effective way to make the DHCPLEASEQUERY
message interaction common between DHCPv4 and DHCPv6 even should the
desire to do so exist.
The DHCPLEASEQUERY message was the result of a set of specific real-
world implementation needs that appeared many years after the DHCPv4
protocol was in wide use. Furthermore, at the time of this writing,
the DHCPv6 protocol has yet to be widely deployed. The needs of
access concentrators in yet to be determined DHCPv6 deployment
scenarios are difficult to estimate. If a DHCPLEASEQUERY-like
function is necessary in DHCPv6, many of the ideas of this document
will probably be applicable, while others may not. We have been
cautioned against designing protocol capabilities for which there is
only an imagined consumer, and that is all that exists today in the
realm of DHCPLEASEQUERY for DHCPv6.
Thus, this document applies only to DHCPv4, and for clarity we have
not appended DHCPv4 to every appearance of several common terms. In
this document, all references to IP addresses should be taken to mean
IPv4 addresses, and all references to DHCP servers and DHCP clients
should be taken to mean DHCPv4 servers and DHCPv4 clients.
2. 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 [RFC2119].
This document uses the following terms:
o "access concentrator"
An access concentrator is a router or switch at the broadband
access provider’s edge of a public broadband access network.
This document assumes that the access concentrator includes
the DHCP relay agent functionality.
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address.
o "DHCP relay agent"
A DHCP relay agent is a third-party agent that transfers
Bootstrap Protocol (BOOTP) and DHCP messages between clients
and servers residing on different subnets, per [RFC951] and
[RFC1542].
o "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
o "downstream"
Downstream is the direction from the access concentrator
towards the broadband subscriber.
o "gleaning"
Gleaning is the extraction of location information from DHCP
messages, as the messages are forwarded by the DHCP relay
agent function.
o "location information"
Location information is information needed by the access
concentrator to forward traffic to a broadband-accessible
host. This information 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 modem.
o "MAC address"
In the context of a DHCP packet, a MAC address consists of the
following fields: hardware type "htype", hardware length
"hlen", and client hardware address "chaddr".
o "stable storage"
Every DHCP server is assumed to have some form of what is
called "stable storage". Stable storage is used to hold
information concerning IP address bindings (among other
things) so that this information is not lost in the event of a
server failure that requires restart of the server.
o "upstream"
Upstream is the direction from the broadband subscriber
towards the access concentrator.
3. Background
The focus of this document is to enable processes and devices that
wish to access information from the DHCP server in a lightweight and
convenient manner. It is especially appropriate for processes and
devices that already interpret DHCP packets.
One important motivating example is that the DHCPLEASEQUERY message
allows access concentrators to send DHCPLEASEQUERY messages to DHCP
servers to obtain location information of broadband access network
devices.
This document assumes that many access concentrators have an embedded
DHCP relay agent functionality. Typical access concentrators include
DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB
Interactive Network Adapters (INAs) [EUROMODEM], and DSL Access
Concentrators.
The DHCPLEASEQUERY message is an extension to the DHCP protocol
[RFC2131].
The DHCPLEASEQUERY message is a query message only and does not
affect the state of the IP address or the binding information
associated with it.
4. Design Goals
The goal of this document is to provide a lightweight mechanism for
processes or devices to access information contained in the DHCP
server. It is designed to allow processes and devices that already
process and interpret DHCP messages to access this information in a
rapid and lightweight manner.
Some of this information might be acquired in a different way, and
the following sections discuss some of these alternative approaches.
4.1. Broadcast ARP Is Undesirable
The access concentrator can transmit a broadcast Address Resolution
Protocol (ARP) Request [RFC826], and observe the origin and contents
of the ARP Reply, to reconstruct the location information.
The ARP mechanism is undesirable for three reasons:
1. the burden on the access concentrator to transmit over
multiple access ports and virtual circuits (assuming that IP
subnets span multiple ports or virtual circuits),
2. the burden on the numerous subscriber hosts to receive and
process the broadcast, and
3. the ease by which a malicious host can misrepresent itself as
the IP endpoint.
4.2. SNMP and LDAP Are Not Appropriate
Access concentrator implementations typically do not have Simple
Network Management Protocol (SNMP) management client interfaces nor
Lightweight Directory Access Protocol (LDAP) client interfaces
(although they typically do include SNMP management agents). This is
one reason why this document does not leverage the proposed DHCP
Server MIB [DHCPMIB].
The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
and troubleshooting activities at large DHCP installations, and is
primarily intended as a method of gathering performance statistics
about servers the load presented to them.
Despite the presence in the proposed DHCPv4 server MIB of objects
that report configuration and status information, the MIB is intended
to provide more generic, server-wide aggregated or summarized data.
DHCPLEASEQUERY is intended to provide detailed, specific information
about individual leases at a level that would be difficult or
impossible to shoehorn into a MIB.
From an implementation standpoint, the DHCPLEASEQUERY message is not
required to be supported by all DHCPv4 servers. Since it appears
that defining optional MIB objects and objects for optional features
in a MIB is discouraged, trying to support DHCPLEASEQUERY
functionality optionally through a MIB would be similarly discouraged
from an SNMP MIB standpoint.
4.3. DHCP Relay Agent Functionality Is Common
Access concentrators commonly act as DHCP relay agents. Furthermore,
many access concentrators already glean location information from
DHCP server responses, as part of the relay agent function.
The gleaning mechanism as a technique to determine the IP addresses
valid for a particular downstream link is preferred over other
mechanisms (ARP, SNMP, LDAP) because of the lack of additional
network traffic, but sometimes gleaning information can be
incomplete. The access concentrator usually cannot glean information
from any DHCP unicast (i.e., non-relayed) messages due to performance
reasons. Furthermore, the DHCP-gleaned location information often
does not persist across access concentrator reboots (due to lack of
stable storage), and almost never persists across concentrator
replacements.
4.4. DHCP Servers Are a Reliable Source of Location Information
DHCP servers are the most reliable source of location information for
access concentrators, particularly when the location information is
dynamic and not reproducible by algorithmic means (e.g., when a
single IP subnet extends behind many broadband modems). DHCP servers
participate in all IP lease transactions (and therefore in all
location information updates) with DHCP clients, whereas access
concentrators sometimes miss some important lease transactions.
An access concentrator can be configured with the IP addresses of
multiple different DHCP servers, so that no one DHCP server is a
single point of failure.
4.5. Minimal Additional Configuration Is Required
Access concentrators can usually query the same set of DHCP servers
used for forwarding by the relay agent, thus minimizing configuration
requirements.
5. Protocol Overview
In the following discussion of the DHCPLEASEQUERY message, the client
of the message is assumed to be an access concentrator. Note that
access concentrators are not the only allowed (or required) consumers
of the information provided by the DHCPLEASEQUERY message, but they
do give readers a concrete feel for how the message might be used.
The access concentrator initiates all DHCPLEASEQUERY message
conversations. This document assumes that the access concentrator
gleans location information in its DHCP relay agent function.
However, the location information is usually unavailable after the
reboot or replacement of the access concentrator.
Suppose the access concentrator is a router, and further suppose that
the router receives an IP datagram to forward downstream to the
public broadband access network. If the location information for the
downstream next hop is missing, the access concentrator sends one or
more DHCPLEASEQUERY message(s), each containing the IP address of the
downstream next hop in the "ciaddr" field.
This query will then be answered by returning the information current
when this client’s lease was last granted or renewed, allowing the
access concentrator to forward the IP datagram.
An alternative approach is to send in a DHCPLEASEQUERY message with
the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen",
and "chaddr" fields) with a valid MAC address or a Client-identifier
option (option 61) appearing in the options area. In this case, the
DHCP server must return an IP address in the ciaddr if it has any
record of the client described by the Client-identifier or MAC
address. In the absence of specific configuration information to the
contrary (see Section 6.4), it SHOULD be the IP address with the
latest client-last-transaction-time associated with the client
described by the MAC address or Client-identifier option.
The DHCP servers that implement this protocol always send a response
to the DHCPLEASEQUERY message: either a DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN. The reasons why a
DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message
might be generated are explained in the specific query regimes,
below.
Servers that do not implement the DHCPLEASEQUERY message SHOULD
simply not respond.
The DHCPLEASEQUERY message can support three query regimes: A server
that implements the DHCPLEASEQUERY message must implement all three
query regimes.
o Query by IP address:
For this query, the requester supplies only an IP address in the
DHCPLEASEQUERY message. The DHCP server will return any
information that it has on the most recent client to have been
assigned that IP address.
The DHCP server replies with a DHCPLEASEUNASSIGNED or
DHCPLEASEACTIVE message if the IP address in the DHCPLEASEQUERY
message corresponds to an IP address about which the server has
definitive information (i.e., it is authorized to lease this IP
address). The server replies with a DHCPLEASEUNKNOWN message if
the server does not have definitive information concerning the
address in the DHCPLEASEQUERY message.
o Query by MAC address:
For this query, the requester supplies only a MAC address in the
DHCPLEASEQUERY message. The DHCP server will return any
information that it has on the IP address most recently accessed
by a client with that MAC address. In addition, it may supply
additional IP addresses that have been associated with that MAC
address in different subnets. Information about these bindings
can then be found using the Query by IP Address, described
above.
The DHCP server replies with a DHCPLEASEACTIVE message if the
MAC address in the DHCPLEASEQUERY message corresponds to a MAC
address with an active lease on an IP address in this server.
The server replies with a DHCPLEASEUNKNOWN message if the server
does not presently have an active lease by a client with this
MAC address in this DHCP server.
o Query by Client-identifier option:
For this query, the requester supplies only a Client-identifier
option in the DHCPLEASEQUERY message. The DHCP server will