draft-ietf-dhc-leasequery-09.txt   rfc4388.txt 
Dynamic Host Configuration Working Group Rich Woundy Network Working Group R. Woundy
INTERNET DRAFT Comcast Cable Request for Comments: 4388 Comcast Cable
Category: Standards Track K. Kinnear
Kim Kinnear
Cisco Systems Cisco Systems
February 2006
October 2005 Dynamic Host Configuration Protocol (DHCP) Leasequery
Expires April 2006
DHCP Lease Query
<draft-ietf-dhc-leasequery-09.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Status of This Memo
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html 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 Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
Abstract Abstract
A DHCPv4 server is the authoritative source of IP addresses that it A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is
has provided to DHCPv4 clients. Other processes and devices that the authoritative source of IP addresses that it has provided to
already make use of DHCPv4 may need to access this information. The DHCPv4 clients. Other processes and devices that already make use of
leasequery protocol provides these processes and devices a DHCPv4 may need to access this information. The leasequery protocol
lightweight way to access IP address information. provides these processes and devices a lightweight way to access IP
address information.
Table of Contents Table of Contents
1. Introduction................................................. 2 1. Introduction ....................................................2
2. Terminology.................................................. 5 2. Terminology .....................................................5
3. Background................................................... 7 3. Background ......................................................7
4. Design Goals................................................. 7 4. Design Goals ....................................................7
4.1. Broadcast ARP is Undesirable............................... 7 4.1. Broadcast ARP Is Undesirable ...............................7
4.2. SNMP and LDAP Not Appropriate.............................. 8 4.2. SNMP and LDAP Are Not Appropriate ..........................8
4.3. DHCP Relay Agent Functionality is Common................... 8 4.3. DHCP Relay Agent Functionality Is Common ...................8
4.4. DHCP Servers as a Reliable Source of Location Information.. 9 4.4. DHCP Servers Are a Reliable Source of Location
4.5. Minimal Additional Configuration is Required............... 9 Information ................................................9
5. Protocol Overview............................................ 9 4.5. Minimal Additional Configuration Is Required ...............9
6. Protocol Details............................................. 12 5. Protocol Overview ...............................................9
6.1. Definitions required for DHCPLEASEQUERY processing......... 12 6. Protocol Details ...............................................12
6.2. Sending the DHCPLEASEQUERY Message......................... 14 6.1. Definitions Required for DHCPLEASEQUERY Processing ........12
6.3. Receiving the DHCPLEASEQUERY Message....................... 15 6.2. Sending the DHCPLEASEQUERY Message ........................14
6.4. Responding to the DHCPLEASEQUERY Message................... 16 6.3. Receiving the DHCPLEASEQUERY Message ......................15
6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or....... 20 6.4. Responding to the DHCPLEASEQUERY Message ..................16
6.6. Receiving no response to the DHCPLEASEQUERY Message........ 21 6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
6.7. Lease binding data storage requirements.................... 22 DHCPLEASEUNKNOWN Message ..................................20
6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 23 6.6. Receiving No Response to the DHCPLEASEQUERY Message .......21
7. Security Considerations...................................... 23 6.7. Lease Binding Data Storage Requirements ...................22
8. IANA Considerations.......................................... 24 6.8. Using the DHCPLEASEQUERY Message with Multiple
9. Acknowledgments.............................................. 24 DHCP Servers ..............................................23
10. References.................................................. 25 7. Security Considerations ........................................23
10.1. Normative References...................................... 25 8. IANA Considerations ............................................24
10.2. Informative References.................................... 25 9. Acknowledgements ...............................................24
11. Author's information........................................ 26 10. References ....................................................25
12. Intellectual Property Statement............................. 26 10.1. Normative References .....................................25
13. Full Copyright Statement.................................... 27 10.2. Informative References ...................................25
1. Introduction 1. Introduction
A DHCPv4 server contains considerable authoritative information A DHCPv4 server contains considerable authoritative information
concerning the IP addresses it has leased to DHCP clients. Sometimes concerning the IP addresses it has leased to DHCP clients. Sometimes
devices or other processes may need access to this information. In devices or other processes may need access to this information. In
some cases, these devices or processes already have the capability to some cases, these devices or processes already have the capability to
send and receive DHCP packets, and so the leasequery protocol is send and receive DHCP packets, and so the leasequery protocol is
designed to give these processes and devices a low overhead way to designed to give these processes and devices a low-overhead way to
access such information. access such information.
For example, access concentrators that act as DHCP relay agents For example, access concentrators that act as DHCP relay agents
sometimes derive information important to their operation by sometimes derive information important to their operation by
extracting data out of the DHCP packets they forward, a process known extracting data out of the DHCP packets they forward, a process known
as "gleaning". Unfortunately, the typical access concentrator loses as "gleaning". Unfortunately, the typical access concentrator loses
its gleaned information when the access concentrator is rebooted or its gleaned information when the access concentrator is rebooted or
is replaced. This memo proposes that when gleaned DHCP information is replaced. This memo proposes that when gleaned DHCP information
is not available, the access concentrator/relay agent can obtain the is not available, the access concentrator/relay agent can obtain the
location information directly from the DHCP server(s) using the location information directly from the DHCP server(s) using the
skipping to change at page 4, line 8 skipping to change at page 3, line 48
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|Host1| |Host2| |Host3| |Host1| |Host2| |Host3|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 2: DSL Environment for DHCPLEASEQUERY Figure 2: DSL Environment for DHCPLEASEQUERY
Knowledge of this location information can benefit the access Knowledge of this location information can benefit the access
concentrator in several ways: concentrator in several ways:
1. The access concentrator can forward traffic to the access 1. The access concentrator can forward traffic to the access
network using the correct access network port, down the correct network using the correct access network port, down the
virtual circuit, through the correct modem, to the correct correct virtual circuit, through the correct modem, to the
hardware address. correct hardware address.
2. The access concentrator can perform IP source address 2. The access concentrator can perform IP source address
verification of datagrams received from the access network. verification of datagrams received from the access network.
The verification may be based on the datagram source hardware The verification may be based on the datagram source hardware
address, the incoming access network port, the incoming virtual address, the incoming access network port, the incoming
circuit, and/or the transmitting modem. virtual circuit, and/or the transmitting modem.
3. The access concentrator can encrypt datagrams which can only be 3. The access concentrator can encrypt datagrams that can only be
decrypted by the correct modem, using mechanisms such as [BPI] decrypted by the correct modem, using mechanisms such as [BPI]
or [BPI+]. or [BPI+].
The access concentrator in this example obtains the location The access concentrator in this example obtains the location
information primarily from "gleaning" information from DHCP server information primarily from "gleaning" information from DHCP server
responses sent through the relay agent. When location information is responses sent through the relay agent. When location information is
not available from "gleaning", e.g. because the access concentrator not available from "gleaning", e.g., because the access concentrator
has rebooted, the access concentrator can query the DHCP server(s) has rebooted, the access concentrator can query the DHCP server(s)
for location information using the DHCPLEASEQUERY message defined in for location information using the DHCPLEASEQUERY message defined in
this document. this document.
The DHCPLEASEQUERY message is a new DHCP message type transmitted The DHCPLEASEQUERY message is a new DHCP message type transmitted
from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware
relay agent sends the DHCPLEASEQUERY message when it needs to know relay agent sends the DHCPLEASEQUERY message when it needs to know
the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server
replies with a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or replies with a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN message. The DHCPLEASEACTIVE response to a DHCPLEASEUNKNOWN message. The DHCPLEASEACTIVE response to a
DHCPLEASEQUERY message allows the relay agent to determine the IP DHCPLEASEQUERY message allows the relay agent to determine the IP
endpoint location, and the remaining duration of the IP address endpoint location and the remaining duration of the IP address lease.
lease. The DHCPLEASEUNASSIGNED is similar to a DHCPLEASEACTIVE The DHCPLEASEUNASSIGNED is similar to a DHCPLEASEACTIVE message, but
message but indicates that there is no currently active lease on the indicates that there is no currently active lease on the resultant IP
resultant IP address but that this DHCP server is authoritative for address but that this DHCP server is authoritative for this IP
this IP address. The DHCPLEASEUNKNOWN message indicates that the address. The DHCPLEASEUNKNOWN message indicates that the DHCP server
DHCP server has no knowledge of the information specified in the has no knowledge of the information specified in the query (e.g., IP
query (e.g., IP address, MAC address, or Client-identifier option). address, MAC address, or Client-identifier option).
The DHCPLEASEQUERY message does not presuppose a particular use for The DHCPLEASEQUERY message does not presuppose a particular use for
the information it returns -- it is simply designed to return the information it returns -- it is simply designed to return
information for which the DHCP server is an authoritative source to a information for which the DHCP server is an authoritative source to a
client which requests that information. It is designed to make it client that requests that information. It is designed to make it
straightforward for processes and devices which already interpret straightforward for processes and devices that already interpret DHCP
DHCP packets to access information from the DHCP server. packets to access information from the DHCP server.
This document specifies an extension specifically to the DHCPv4 This document specifies an extension specifically to the DHCPv4
protocol [RFC2131]. Given the nature of the DHCPv6 protocol [RFC protocol [RFC2131]. Given the nature of the DHCPv6 protocol
3315], there is no effective way to make the DHCPLEASEQUERY message [RFC3315], there is no effective way to make the DHCPLEASEQUERY
interaction common between DHCPv4 and DHCPv6 even should the desire message interaction common between DHCPv4 and DHCPv6 even should the
to do so exist. desire to do so exist.
The DHCPLEASEQUERY message was the result of a set of specific real- The DHCPLEASEQUERY message was the result of a set of specific real-
world implementation needs that appeared many years after the DHCPv4 world implementation needs that appeared many years after the DHCPv4
protocol was in wide use. Furthermore, at the time of this writing, protocol was in wide use. Furthermore, at the time of this writing,
the DHCPv6 protocol has yet to be widely deployed. The needs of the DHCPv6 protocol has yet to be widely deployed. The needs of
access concentrators in yet to be determined DHCPv6 deployment access concentrators in yet to be determined DHCPv6 deployment
scenarios are difficult to estimate. If a DHCPLEASEQUERY-like scenarios are difficult to estimate. If a DHCPLEASEQUERY-like
function is necessary in DHCPv6, many of the ideas of this document function is necessary in DHCPv6, many of the ideas of this document
will probably be applicable, while others may not. We have been will probably be applicable, while others may not. We have been
cautioned against designing protocol capabililties for which there is cautioned against designing protocol capabilities for which there is
only an imagined consumer, and that is all that exists today in the only an imagined consumer, and that is all that exists today in the
realm of DHCPLEASEQUERY for DHCPv6. realm of DHCPLEASEQUERY for DHCPv6.
Thus, this document applies only to DHCPv4, and for clarity we have Thus, this document applies only to DHCPv4, and for clarity we have
not appended DHCPv4 to every appearance of several common terms. In not appended DHCPv4 to every appearance of several common terms. In
this document all references to IP addresses should be taken to mean this document, all references to IP addresses should be taken to mean
IPv4 addresses, and all references to DHCP servers and DHCP clients IPv4 addresses, and all references to DHCP servers and DHCP clients
should be taken to mean DHCPv4 servers and DHCPv4 clients. should be taken to mean DHCPv4 servers and DHCPv4 clients.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the following terms: This document uses the following terms:
o "access concentrator" o "access concentrator"
An access concentrator is a router or switch at the broadband An access concentrator is a router or switch at the broadband
access provider's edge of a public broadband access network. access provider's edge of a public broadband access network.
This document assumes that the access concentrator includes the This document assumes that the access concentrator includes
DHCP relay agent functionality. the DHCP relay agent functionality.
o "DHCP client" o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
o "DHCP relay agent" o "DHCP relay agent"
A DHCP relay agent is a third-party agent that transfers BOOTP A DHCP relay agent is a third-party agent that transfers
and DHCP messages between clients and servers residing on Bootstrap Protocol (BOOTP) and DHCP messages between clients
different subnets, per [RFC 951] and [RFC 1542]. and servers residing on different subnets, per [RFC951] and
[RFC1542].
o "DHCP server" o "DHCP server"
A DHCP server is an Internet host that returns configuration A DHCP server is an Internet host that returns configuration
parameters to DHCP clients. parameters to DHCP clients.
o "downstream" o "downstream"
Downstream is the direction from the access concentrator towards Downstream is the direction from the access concentrator
the broadband subscriber. towards the broadband subscriber.
o "gleaning" o "gleaning"
Gleaning is the extraction of location information from DHCP Gleaning is the extraction of location information from DHCP
messages, as the messages are forwarded by the DHCP relay agent messages, as the messages are forwarded by the DHCP relay
function. agent function.
o "location information" o "location information"
Location information is information needed by the access Location information is information needed by the access
concentrator to forward traffic to a broadband-accessible host. concentrator to forward traffic to a broadband-accessible
This information includes knowledge of the host hardware host. This information includes knowledge of the host
address, the port or virtual circuit that leads to the host, hardware address, the port or virtual circuit that leads to
and/or the hardware address of the intervening subscriber modem. the host, and/or the hardware address of the intervening
subscriber modem.
o "MAC address" o "MAC address"
In the context of a DHCP packet, a MAC address consists of the In the context of a DHCP packet, a MAC address consists of the
fields: hardware type "htype", hardware length "hlen", and following fields: hardware type "htype", hardware length
client hardware address "chaddr". "hlen", and client hardware address "chaddr".
o "stable storage" o "stable storage"
Every DHCP server is assumed to have some form of what is called Every DHCP server is assumed to have some form of what is
"stable storage". Stable storage is used to hold information called "stable storage". Stable storage is used to hold
concerning IP address bindings (among other things) so that this information concerning IP address bindings (among other
information is not lost in the event of a server failure which things) so that this information is not lost in the event of a
requires restart of the server. server failure that requires restart of the server.
o "upstream" o "upstream"
Upstream is the direction from the broadband subscriber towards Upstream is the direction from the broadband subscriber
the access concentrator. towards the access concentrator.
3. Background 3. Background
The focus of this document is to enable processes and devices which The focus of this document is to enable processes and devices that
wish to access information from the DHCP server in a lightweight and wish to access information from the DHCP server in a lightweight and
convenient manner. It is especially appropriate for processes and convenient manner. It is especially appropriate for processes and
devices which already interpret DHCP packets. devices that already interpret DHCP packets.
One important motivating example is that the DHCPLEASEQUERY message One important motivating example is that the DHCPLEASEQUERY message
allows access concentrators to send DHCPLEASEQUERY messages to DHCP allows access concentrators to send DHCPLEASEQUERY messages to DHCP
servers, to obtain location information of broadband access network servers to obtain location information of broadband access network
devices. devices.
This document assumes that many access concentrators have an embedded This document assumes that many access concentrators have an embedded
DHCP relay agent functionality. Typical access concentrators include DHCP relay agent functionality. Typical access concentrators include
DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB
Interactive Network Adapters (INAs) [EUROMODEM], and DSL Access Interactive Network Adapters (INAs) [EUROMODEM], and DSL Access
Concentrators. Concentrators.
The DHCPLEASEQUERY message is an extension to the DHCP protocol [RFC The DHCPLEASEQUERY message is an extension to the DHCP protocol
2131]. [RFC2131].
The DHCPLEASEQUERY message is a query message only, and does not The DHCPLEASEQUERY message is a query message only and does not
affect the state of the IP address or the binding information affect the state of the IP address or the binding information
associated with it. associated with it.
4. Design Goals 4. Design Goals
The goal of this document is to provide a lightweight mechanism for The goal of this document is to provide a lightweight mechanism for
processes or devices to access information contained in the DHCP processes or devices to access information contained in the DHCP
server. It is designed to allow processes and devices which already server. It is designed to allow processes and devices that already
process and interpret DHCP messages to access this information in a process and interpret DHCP messages to access this information in a
rapid and lightweight manner. rapid and lightweight manner.
Some of this information might be acquired in a different way, and Some of this information might be acquired in a different way, and
the following sections discuss some of these alternative approaches. the following sections discuss some of these alternative approaches.
4.1. Broadcast ARP is Undesirable 4.1. Broadcast ARP Is Undesirable
The access concentrator can transmit a broadcast ARP Request [RFC The access concentrator can transmit a broadcast Address Resolution
826], and observe the origin and contents of the ARP Reply, to Protocol (ARP) Request [RFC826], and observe the origin and contents
reconstruct the location information. of the ARP Reply, to reconstruct the location information.
The ARP mechanism is undesirable for three reasons: The ARP mechanism is undesirable for three reasons:
1. the burden on the access concentrator to transmit over multiple 1. the burden on the access concentrator to transmit over
access ports and virtual circuits (assuming that IP subnets multiple access ports and virtual circuits (assuming that IP
span multiple ports or virtual circuits), subnets span multiple ports or virtual circuits),
2. the burden on the numerous subscriber hosts to receive and 2. the burden on the numerous subscriber hosts to receive and
process the broadcast, and process the broadcast, and
3. the ease by which a malicious host can misrepresent itself as 3. the ease by which a malicious host can misrepresent itself as
the IP endpoint. the IP endpoint.
4.2. SNMP and LDAP Not Appropriate 4.2. SNMP and LDAP Are Not Appropriate
Access concentrator implementations typically do not have SNMP Access concentrator implementations typically do not have Simple
management client interfaces nor LDAP client interfaces (although Network Management Protocol (SNMP) management client interfaces nor
they typically do include SNMP management agents). This is one Lightweight Directory Access Protocol (LDAP) client interfaces
reason why this document does not leverage the proposed DHCP Server (although they typically do include SNMP management agents). This is
MIB [DHCPMIB]. 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 The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
and troubleshooting activities at large DHCP installations, and is and troubleshooting activities at large DHCP installations, and is
primarily intended as a method of gathering performance statistics primarily intended as a method of gathering performance statistics
about servers the load presented to them. about servers the load presented to them.
Despite the presence in the proposed DHCPv4 server MIB of objects Despite the presence in the proposed DHCPv4 server MIB of objects
that report configuration and status information, the MIB is intended that report configuration and status information, the MIB is intended
to provide more generic, server-wide aggregated or summarized data. to provide more generic, server-wide aggregated or summarized data.
DHCPLEASEQUERY is intended to provide detailed, specific information DHCPLEASEQUERY is intended to provide detailed, specific information
about individual leases at a level that would be difficult or about individual leases at a level that would be difficult or
impossible to shoehorn into a MIB. impossible to shoehorn into a MIB.
From an implementation standpoint, the DHCPLEASEQUERY message is not From an implementation standpoint, the DHCPLEASEQUERY message is not
required to be supported by all DHCPv4 servers. Since it appears required to be supported by all DHCPv4 servers. Since it appears
that defining optional MIB objects and objects for optional features that defining optional MIB objects and objects for optional features
in a MIB is discouraged, trying to support DHCPLEASEQUERY in a MIB is discouraged, trying to support DHCPLEASEQUERY
functionality optionally through a MIB would be similarly discouraged functionality optionally through a MIB would be similarly discouraged
from an SNMP MIB standpoint. from an SNMP MIB standpoint.
4.3. DHCP Relay Agent Functionality is Common 4.3. DHCP Relay Agent Functionality Is Common
Access concentrators commonly act as DHCP relay agents. Furthermore, Access concentrators commonly act as DHCP relay agents. Furthermore,
many access concentrators already glean location information from many access concentrators already glean location information from
DHCP server responses, as part of the relay agent function. DHCP server responses, as part of the relay agent function.
The gleaning mechanism as a technique to determine the IP addresses The gleaning mechanism as a technique to determine the IP addresses
valid for a particular downstream link is preferred over other valid for a particular downstream link is preferred over other
mechanisms (ARP, SNMP, LDAP) because of the lack of additional mechanisms (ARP, SNMP, LDAP) because of the lack of additional
network traffic, but sometimes gleaning information can be network traffic, but sometimes gleaning information can be
incomplete. The access concentrator usually cannot glean information incomplete. The access concentrator usually cannot glean information
from any DHCP unicast (i.e. non-relayed) messages due to performance from any DHCP unicast (i.e., non-relayed) messages due to performance
reasons. Furthermore, the DHCP-gleaned location information often reasons. Furthermore, the DHCP-gleaned location information often
does not persist across access concentrator reboots (due to lack of does not persist across access concentrator reboots (due to lack of
stable storage), and almost never persists across concentrator stable storage), and almost never persists across concentrator
replacements. replacements.
4.4. DHCP Servers as a Reliable Source of Location Information 4.4. DHCP Servers Are a Reliable Source of Location Information
DHCP servers are the most reliable source of location information for DHCP servers are the most reliable source of location information for
access concentrators, particularly when the location information is access concentrators, particularly when the location information is
dynamic and not reproducible by algorithmic means (e.g. when a dynamic and not reproducible by algorithmic means (e.g., when a
single IP subnet extends behind many broadband modems). DHCP servers single IP subnet extends behind many broadband modems). DHCP servers
participate in all IP lease transactions (and therefore in all participate in all IP lease transactions (and therefore in all
location information updates) with DHCP clients, whereas access location information updates) with DHCP clients, whereas access
concentrators sometimes miss some important lease transactions. concentrators sometimes miss some important lease transactions.
An access concentrator can be configured with the IP addresses of An access concentrator can be configured with the IP addresses of
multiple different DHCP servers, so that no one DHCP server is a multiple different DHCP servers, so that no one DHCP server is a
single point of failure. single point of failure.
4.5. Minimal Additional Configuration is Required 4.5. Minimal Additional Configuration Is Required
Access concentrators can usually query the same set of DHCP servers Access concentrators can usually query the same set of DHCP servers
used for forwarding by the relay agent, thus minimizing configuration used for forwarding by the relay agent, thus minimizing configuration
requirements. requirements.
5. Protocol Overview 5. Protocol Overview
In the following discussion of the DHCPLEASEQUERY message, the client In the following discussion of the DHCPLEASEQUERY message, the client
of the message is assumed to be an access concentrator. Note that of the message is assumed to be an access concentrator. Note that
access concentrators are not the only allowed (or required) consumers access concentrators are not the only allowed (or required) consumers
of the information provided by the DHCPLEASEQUERY message, but they of the information provided by the DHCPLEASEQUERY message, but they
do give reader a concrete feel for how the message might be used. do give readers a concrete feel for how the message might be used.
The access concentrator initiates all DHCPLEASEQUERY message The access concentrator initiates all DHCPLEASEQUERY message
conversations. This document assumes that the access concentrator conversations. This document assumes that the access concentrator
gleans location information in its DHCP relay agent function. gleans location information in its DHCP relay agent function.
However, the location information is usually unavailable after the However, the location information is usually unavailable after the
reboot or replacement of the access concentrator. reboot or replacement of the access concentrator.
Suppose the access concentrator is a router, and further suppose that Suppose the access concentrator is a router, and further suppose that
the router receives an IP datagram to forward downstream to the the router receives an IP datagram to forward downstream to the
public broadband access network. If the location information for the public broadband access network. If the location information for the
downstream next hop is missing, the access concentrator sends one or downstream next hop is missing, the access concentrator sends one or
more DHCPLEASEQUERY message(s), each containing the IP address of the more DHCPLEASEQUERY message(s), each containing the IP address of the
downstream next hop in the "ciaddr" field. downstream next hop in the "ciaddr" field.
This query will then be answered by, returning the information This query will then be answered by returning the information current
current when this client's lease was last granted or renewed, when this client's lease was last granted or renewed, allowing the
allowing the access concentrator to forward the IP datagram. access concentrator to forward the IP datagram.
An alternative approach is to send in a DHCPLEASEQUERY message with An alternative approach is to send in a DHCPLEASEQUERY message with
the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen", the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen",
and "chaddr" fields) with a valid MAC address or a Client-identifier and "chaddr" fields) with a valid MAC address or a Client-identifier
option (option 61) appearing in the options area. In this case, the 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 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 record of the client described by the Client-identifier or MAC
address. In the absence of specific configuration information to the address. In the absence of specific configuration information to the
contrary (see Section 6.4) it SHOULD be the IP address with the contrary (see Section 6.4), it SHOULD be the IP address with the
latest client-last-transaction-time associated with the client latest client-last-transaction-time associated with the client
described by the MAC address or Client-identifier option (or the described by the MAC address or Client-identifier option.
client described by both, if both appear).
The DHCP servers that implement this protocol always send a response The DHCP servers that implement this protocol always send a response
to the DHCPLEASEQUERY message: either a DHCPLEASEUNASSIGNED, to the DHCPLEASEQUERY message: either a DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE or DHCPLEASEUNKNOWN. The reasons why a DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN. The reasons why a
DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message
might be generated are explained in the specific query regimes, might be generated are explained in the specific query regimes,
below. below.
Servers which do not implement the DHCPLEASEQUERY message SHOULD Servers that do not implement the DHCPLEASEQUERY message SHOULD
simply not respond. simply not respond.
The DHCPLEASEQUERY message can support three query regimes: A server The DHCPLEASEQUERY message can support three query regimes: A server
which implements the DHCPLEASEQUERY message must implement all three that implements the DHCPLEASEQUERY message must implement all three
query regimes. query regimes.
o Query by IP address: o Query by IP address:
For this query, the requester supplies only an IP address in the For this query, the requester supplies only an IP address in the
DHCPLEASEQUERY message. The DHCP server will return any DHCPLEASEQUERY message. The DHCP server will return any
information that it has on the most recent client to have been information that it has on the most recent client to have been
assigned that IP address. assigned that IP address.
The DHCP server replies with a DHCPLEASEUNASSIGNED or The DHCP server replies with a DHCPLEASEUNASSIGNED or
DHCPLEASEACTIVE message if the IP address in the DHCPLEASEQUERY DHCPLEASEACTIVE message if the IP address in the DHCPLEASEQUERY
message corresponds to an IP address about which the server has message corresponds to an IP address about which the server has
definitive information (ie., it is authorized to lease this IP definitive information (i.e., it is authorized to lease this IP
address). The server replies with a DHCPLEASEUNKNOWN message if address). The server replies with a DHCPLEASEUNKNOWN message if
the server does not have definitive information concerning the the server does not have definitive information concerning the
address in the DHCPLEASEQUERY message. address in the DHCPLEASEQUERY message.
o Query by MAC address: o Query by MAC address:
For this query, the requester supplies only a MAC address in the For this query, the requester supplies only a MAC address in the
DHCPLEASEQUERY message. The DHCP server will return any DHCPLEASEQUERY message. The DHCP server will return any
information that it has on the IP address most recently accessed information that it has on the IP address most recently accessed
by a client with that MAC address. In addition, it may supply by a client with that MAC address. In addition, it may supply
addition IP addresses which have been associated with that MAC additional IP addresses that have been associated with that MAC
address in different subnets. Information about these bindings address in different subnets. Information about these bindings
can then be found using the Query by IP Address, described can then be found using the Query by IP Address, described
above. above.
The DHCP server replies with a DHCPLEASEACTIVE message if the The DHCP server replies with a DHCPLEASEACTIVE message if the
MAC address in the DHCPLEASEQUERY message corresponds to a MAC MAC address in the DHCPLEASEQUERY message corresponds to a MAC
address with an active lease on an IP address in this server. address with an active lease on an IP address in this server.
The server replies with a DHCPLEASEUNKNOWN message if the server The server replies with a DHCPLEASEUNKNOWN message if the server
does not presently have an active lease by a client with this does not presently have an active lease by a client with this
MAC address in this DHCP server. MAC address in this DHCP server.
o Query by Client-identifier option: o Query by Client-identifier option:
For this query, the requester supplies only a Client-identifier For this query, the requester supplies only a Client-identifier
option in the DHCPLEASEQUERY message. The DHCP server will option in the DHCPLEASEQUERY message. The DHCP server will
return any information that it has on the IP address most return any information that it has on the IP address most
recently accessed by a client with that Client-identifier. In recently accessed by a client with that Client-identifier. In
addition, it may supply additional IP addresses which have been addition, it may supply additional IP addresses that have been
associated with Client-identifier in different subnets. associated with Client-identifier in different subnets.
Information about these bindings can then be found using the Information about these bindings can then be found using the
Query by IP Address, described above. Query by IP Address, described above.
The DHCP server replies with a DHCPLEASEACTIVE message if the The DHCP server replies with a DHCPLEASEACTIVE message if the
Client-identifier in the DHCPLEASEQUERY message currently has an Client-identifier in the DHCPLEASEQUERY message currently has an
active lease on an IP address in this DHCP server. The server active lease on an IP address in this DHCP server. The server
replies with a DHCPLEASEUNKNOWN message if the server does not replies with a DHCPLEASEUNKNOWN message if the server does not
have an active lease by a client with this Client-identifier. have an active lease by a client with this Client-identifier.
For many DHCP servers, the query by IP address is likely to be the For many DHCP servers, the query by IP address is likely to be the
most efficient form of leasequery. This is the form of most efficient form of leasequery. This is the form of
DHCPLEASEQUERY that SHOULD be used if possible. DHCPLEASEQUERY that SHOULD be used if possible.
The DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message reply must always The DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message reply must always
contain the IP address in the ciaddr field. The DHCPLEASEACTIVE contain the IP address in the "ciaddr" field. The DHCPLEASEACTIVE
message SHOULD contain the physical address of the IP address lease message SHOULD contain the physical address of the IP address lease
owner in the "htype", "hlen", and "chaddr" fields. The Parameter owner in the "htype", "hlen", and "chaddr" fields. The Parameter
Request List (option 55) can be used to request specific options to Request List (option 55) can be used to request specific options to
be returned about the IP address in the ciaddr. The reply often be returned about the IP address in the ciaddr. The reply often
contains the time until expiration of the lease, and the original contains the time until expiration of the lease, and the original
contents of the Relay Agent Information option [RFC 3046]. The contents of the Relay Agent Information option [RFC3046]. The access
access concentrator uses the "chaddr" and Relay Agent Information concentrator uses the "chaddr" field and Relay Agent Information
option to construct location information, which can be cached on the option to construct location information, which can be cached on the
access concentrator until lease expiration. access concentrator until lease expiration.
Any DHCP server which supports the DHCPLEASEQUERY message SHOULD save Any DHCP server that supports the DHCPLEASEQUERY message SHOULD save
the information from the most recent Relay Agent Information option the information from the most recent Relay Agent Information option
(option 82) [RFC 3046] associated with every IP address which it (option 82) [RFC3046] associated with every IP address that it
serves. It is assumed that most clients which generate the serves. It is assumed that most clients that generate the
DHCPLEASEQUERY message will ask for the Relay Agent Information DHCPLEASEQUERY message will ask for the Relay Agent Information
option (option 82) in the Parameter Request List (option 55), and so option (option 82) in the Parameter Request List (option 55), and so
supporting the DHCPLEASEQUERY message without having the Relay Agent supporting the DHCPLEASEQUERY message without having the Relay Agent
Information option around to return to the client is likely to be Information option around to return to the client is likely to be
less than helpful. less than helpful.
A server which implements DHCPLEASEQUERY SHOULD also save the A server that implements DHCPLEASEQUERY SHOULD also save the
information on the most recent Vendor class identifier, option 60, information on the most recent Vendor class identifier, option 60,
associated with each IP address, since this option is also likely to associated with each IP address, since this option is also likely to
be requested by clients sending the DHCPLEASEQUERY message. be requested by clients sending the DHCPLEASEQUERY message.
6. Protocol Details 6. Protocol Details
6.1. Definitions required for DHCPLEASEQUERY processing 6.1. Definitions Required for DHCPLEASEQUERY Processing
The operation of the DHCPLEASEQUERY message requires the definition The operation of the DHCPLEASEQUERY message requires the definition
of the following new and extended values for the DHCP packet beyond of the following new and extended values for the DHCP packet beyond
those defined by [RFC 2131] and [RFC 2132]. See also Section 8, IANA those defined by [RFC2131] and [RFC2132]. See also Section 8, IANA
considerations. Considerations.
1. The message type option (option 53) from [RFC 2132] requires 1. The message type option (option 53) from [RFC2132] requires
four new values: one for the DHCPLEASEQUERY message itself and four new values: one for the DHCPLEASEQUERY message itself and
and one for each of its three possible responses one for each of its three possible responses
DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, DHCPLEASEUNKNOWN. The DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, DHCPLEASEUNKNOWN. The
values of these message types are shown below in a reproduction values of these message types are shown below in an extension
of the table from [RFC 2132]: of the table from section 9.6 of [RFC2132]:
Value Message Type Value Message Type
----- ------------ ----- ------------
1 DHCPDISCOVER 10 DHCPLEASEQUERY
2 DHCPOFFER 11 DHCPLEASEUNASSIGNED
3 DHCPREQUEST 12 DHCPLEASEUNKNOWN
4 DHCPDECLINE 13 DHCPLEASEACTIVE
5 DHCPACK
6 DHCPNAK
7 DHCPRELEASE
8 DHCPINFORM
TBD DHCPLEASEQUERY
TBD DHCPLEASEUNASSIGNED
TBD DHCPLEASEUNKNOWN
TBD DHCPLEASEACTIVE
2. There is a new option, the client-last-transaction-time: 2. There is a new option, the client-last-transaction-time:
client-last-transaction-time client-last-transaction-time
This option allows the receiver to determine the time of the This option allows the receiver to determine the time of the
most recent access of the client. It is particularly useful most recent access of the client. It is particularly useful
when DHCPLEASEACTIVE messages from two different DHCP servers when DHCPLEASEACTIVE messages from two different DHCP servers
need to be compared, although it can be useful in other need to be compared, although it can be useful in other
situations. The value is a duration in seconds from the situations. The value is a duration in seconds from the
current time into the past when this IP address was most current time into the past when this IP address was most
recently the subject of communication between the client and recently the subject of communication between the client and
the DHCP server. the DHCP server.
This MUST NOT be an absolute time. This MUST NOT be an This MUST NOT be an absolute time. This MUST NOT be an
absolute number of seconds since Jan 1, 1970. Instead, this absolute number of seconds since Jan. 1, 1970. Instead, this
MUST be an integer number of seconds in the past from the time MUST be an integer number of seconds in the past from the time
the DHCPLEASEACTIVE message is sent that the client last dealt the DHCPLEASEACTIVE message is sent that the client last dealt
with this server about this IP address. In the same way that with this server about this IP address. In the same way that
the IP Address Lease Time option (option 51) encodes a lease the IP Address Lease Time option (option 51) encodes a lease
time which is a number of seconds into the future from the time time that is a number of seconds into the future from the time
the message was sent, this option encodes a value which is a the message was sent, this option encodes a value that is a
number of seconds into the past from when the message was sent. number of seconds into the past from when the message was
sent.
The code for the this option is TBD. The length of the this The code for the this option is 91. The length of the this
option is 4 octets. option is 4 octets.
Code Len Seconds in the past Code Len Seconds in the past
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD | 4 | t1 | t2 | t3 | t4 | | 91 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
3. There in a second new option, the associated-ip option: 3. There in a second new option, the associated-ip option:
associated-ip associated-ip
This option is used to return all of the IP addresses This option is used to return all of the IP addresses
associated with the DHCP client specified in a particular associated with the DHCP client specified in a particular
DHCPLEASEQUERY message. DHCPLEASEQUERY message.
The code for this option is TBD. The minimum length for this The code for this option is 92. The minimum length for this
option is 4 octets, and the length MUST always be a multiple of option is 4 octets, and the length MUST always be a multiple
4. of 4.
Code Len Address 1 Address 2 Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+-----+--
| TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | ... | 92 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+-----+--
6.2. Sending the DHCPLEASEQUERY Message 6.2. Sending the DHCPLEASEQUERY Message
The DHCPLEASEQUERY message is typically sent by an access The DHCPLEASEQUERY message is typically sent by an access
concentrator. The DHCPLEASEQUERY message uses the DHCP message concentrator. The DHCPLEASEQUERY message uses the DHCP message
format as described in [RFC 2131], and uses message number TBD in the format as described in [RFC2131], and uses message number 10 in the
DHCP Message Type option (option 53). The DHCPLEASEQUERY message has DHCP Message Type option (option 53). The DHCPLEASEQUERY message has
the following pertinent message contents: the following pertinent message contents:
o The giaddr MUST be set to the IP address of the requester (i.e. o The giaddr MUST be set to the IP address of the requester (i.e.,
the access concentrator). The giaddr is independent of the the access concentrator). The giaddr is independent of the
"ciaddr" field to be searched -- it is simply the return address "ciaddr" field to be searched -- it is simply the return address
of for the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or of the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN
DHCPLEASEUNKNOWN message from the DHCP server. message from the DHCP server.
Note that this use of the giaddr is consistent with the Note that this use of the giaddr is consistent with the
definition of giaddr in [RFC2131], where the giaddr is always definition of giaddr in [RFC2131], where the giaddr is always
used as the return address of the DHCP response message. In used as the return address of the DHCP response message. In some
some (but not all) contexts in RFC2131 the giaddr is used as the (but not all) contexts in RFC 2131, the giaddr is used as the
"key" to access the appropriate address pool. The "key" to access the appropriate address pool. The DHCPLEASEQUERY
DHCPLEASEQUERY message is one of those cases where the giaddr message is one of those cases where the giaddr MUST NOT be used
MUST NOT be used as such a "key". as such a "key".
o The Parameter Request List option (option 55) SHOULD be set to o The Parameter Request List option (option 55) SHOULD be set to
the options of interest to the requester. The interesting the options of interest to the requester. The interesting
options are likely to include the IP Address Lease Time option options are likely to include the IP Address Lease Time option
(option 51), the Relay Agent Information option (option 82) and (option 51), the Relay Agent Information option (option 82), and
possibly the Vendor class identifier option (option 60). In the possibly the Vendor class identifier option (option 60). In the
absence of a Parameter Request List option, the server SHOULD absence of a Parameter Request List option, the server SHOULD
return the same options it would return for a DHCPREQUEST return the same options it would return for a DHCPREQUEST message
message which didn't contain a DHCPLEASEQUERY message, which that didn't contain a DHCPLEASEQUERY message, which includes
includes those mandated by [RFC 2131, Section 4.3.1] as well as those mandated by Section 4.3.1 of [RFC2131] as well as any
any options which the server was configured to always return to options that the server was configured to always return to a
a client. client.
Additional details concerning different query types are: Additional details concerning different query types are:
o Query by IP address: o Query by IP address:
The values of htype, hlen, and chaddr MUST be set to 0. The values of htype, hlen, and chaddr MUST be set to zero.
The "ciaddr" field MUST be set to the IP address of the lease to The "ciaddr" field MUST be set to the IP address of the lease to
be queried. be queried.
The Client-identifier option (option 61) MUST NOT appear in the The Client-identifier option (option 61) MUST NOT appear in the
packet. packet.
o Query by MAC address: o Query by MAC address:
The values of htype, hlen, and chaddr MUST be set to the value The values of htype, hlen, and chaddr MUST be set to the value
skipping to change at page 15, line 28 skipping to change at page 15, line 22
The Client-identifier option (option 61) MUST NOT appear in the The Client-identifier option (option 61) MUST NOT appear in the
packet. packet.
o Query by Client-identifier option: o Query by Client-identifier option:
There MUST be a Client-identifier option (option 61) in the There MUST be a Client-identifier option (option 61) in the
DHCPLEASEQUERY message. DHCPLEASEQUERY message.
The "ciaddr" field MUST be set to zero. The "ciaddr" field MUST be set to zero.
The values of htype, hlen, and chaddr MUST be set to 0. The values of htype, hlen, and chaddr MUST be set to zero.
The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is
known to possess authoritative information concerning the IP address. known to possess authoritative information concerning the IP address.
The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, The DHCPLEASEQUERY message MAY be sent to more than one DHCP server,
and in the absence of information concerning which DHCP server might and in the absence of information concerning which DHCP server might
possess authoritative information concerning the IP address, it possess authoritative information concerning the IP address, it
SHOULD be sent to all DHCP servers configured for the associated SHOULD be sent to all DHCP servers configured for the associated
relay agent (if any are known). relay agent (if any are known).
Any device expecting to use a DHCPLEASEQUERY message SHOULD ensure Any device expecting to use a DHCPLEASEQUERY message SHOULD ensure
that the Relay Agent Info option that it uses contains information that the Relay Agent Info option that it uses contains information
that unambiguously identifies the device. that unambiguously identifies the device.
6.3. Receiving the DHCPLEASEQUERY Message 6.3. Receiving the DHCPLEASEQUERY Message
A server which implements the DHCPLEASEQUERY message MUST implement A server that implements the DHCPLEASEQUERY message MUST implement
all three query regimes, query by IP address, query by MAC address, all three query regimes: query by IP address, query by MAC address,
and query by Client-identifier. and query by Client-identifier.
A DHCPLEASEQUERY message MUST have a non-zero giaddr. The A DHCPLEASEQUERY message MUST have a non-zero giaddr. The
DHCPLEASEQUERY message MUST have exactly one of: a non-zero ciaddr, DHCPLEASEQUERY message MUST have exactly one of the following: a
a non-zero "htype"/"hlen"/"chaddr", or a Client-identifier option. non-zero ciaddr, a non-zero htype/hlen/chaddr, or a Client-identifier
option.
The DHCP server which receives a DHCPLEASEQUERY message MUST base its The DHCP server that receives a DHCPLEASEQUERY message MUST base its
response on the particular data item used in the query. response on the particular data item used in the query.
The giaddr is used only for the destination address of any generated The giaddr is used only for the destination address of any generated
response and, while required, is not otherwise used in generating the response and, while required, is not otherwise used in generating the
response to the DHCPLEASEQUERY message. It MUST NOT be used to response to the DHCPLEASEQUERY message. It MUST NOT be used to
restrict the processing of the query in any way, and MUST NOT be used restrict the processing of the query in any way, and MUST NOT be used
locate a subnet to which the ciaddr (if any) must belong. locate a subnet to which the ciaddr (if any) must belong.
Note that this use of the giaddr is consistent with the definition of Note that this use of the giaddr is consistent with the definition of
giaddr in [RFC2131], where the giaddr is always used as the return giaddr in [RFC2131], where the giaddr is always used as the return
address of the DHCP response message. In some (but not all) contexts address of the DHCP response message. In some (but not all) contexts
in RFC2131 the giaddr is used as the "key" to access the appropriate in RFC 2131, the giaddr is used as the "key" to access the
address pool. The DHCPLEASEQUERY message is one of those cases where appropriate address pool. The DHCPLEASEQUERY message is one of those
the giaddr MUST NOT be used as such a "key". cases where the giaddr MUST NOT be used as such a "key".
6.4. Responding to the DHCPLEASEQUERY Message 6.4. Responding to the DHCPLEASEQUERY Message
There are three possible responses to a DHCPLEASEQUERY message: There are three possible responses to a DHCPLEASEQUERY message:
o DHCPLEASEUNASSIGNED o DHCPLEASEUNASSIGNED
The server MUST respond with a DHCPLEASEUNASSIGNED message if The server MUST respond with a DHCPLEASEUNASSIGNED message if
this server has information about the IP address, but there is this server has information about the IP address, but there is
no active lease for the IP address. The DHCPLEASEUNASSIGNED no active lease for the IP address. The DHCPLEASEUNASSIGNED
message is only returned for a query by IP address, and message is only returned for a query by IP address, and
indicates that the server manages this IP address but there is indicates that the server manages this IP address, but there is
no currently active lease on this IP address. no currently active lease on this IP address.
o DHCPLEASEUNKNOWN o DHCPLEASEUNKNOWN
The DHCPLEASEUNKNOWN message indicates that the server does not The DHCPLEASEUNKNOWN message indicates that the server does not
manage the IP address or the client specified in the manage the IP address or the client specified in the
DHCPLEASEQUERY message does not currently have a lease on an IP DHCPLEASEQUERY message does not currently have a lease on an IP
address. address.
When responding with a DHCPLEASEUNKNOWN, the DHCP server MUST When responding with a DHCPLEASEUNKNOWN, the DHCP server MUST
NOT include other DHCP options in the response. NOT include other DHCP options in the response.
o DHCPLEASEACTIVE o DHCPLEASEACTIVE
The DHCPLEASEACTIVE message indicates that the server not only The DHCPLEASEACTIVE message indicates that the server not only
knows about the IP address and client specified in the knows about the IP address and client specified in the
DHCPLEASEACTIVE message but also that there is an active lease DHCPLEASEACTIVE message, but also knows that there is an active
by that client for that IP address. lease by that client for that IP address.
The server MUST respond with a DHCPLEASEACTIVE message when the The server MUST respond with a DHCPLEASEACTIVE message when the
IP address returned in the "ciaddr" field is currently leased. IP address returned in the "ciaddr" field is currently leased.
6.4.1. Determining the IP address to which to respond 6.4.1. Determining the IP address about Which to Respond
Since the response to a DHCPLEASEQUERY request can only contain full Since the response to a DHCPLEASEQUERY request can only contain full
information about one IP address -- the one that appears in the information about one IP address -- the one that appears in the
"ciaddr" field -- determination of which IP address to which to "ciaddr" field -- determination of which IP address about which to
respond is a key issue. Of course, the values of additional IP respond is a key issue. Of course, the values of additional IP
addresses for which a client has a lease must also be returned in the addresses for which a client has a lease must also be returned in the
associated-ip option (Section 6.1, #4). This is the only information associated-ip option (Section 6.1, #3). This is the only information
returned not directly associated with the IP address in the "ciaddr" returned not directly associated with the IP address in the "ciaddr"
field. field.
In the event that an IP address appears in the "ciaddr" field of a In the event that an IP address appears in the "ciaddr" field of a
DHCPLEASEQUERY message, if that IP address is one managed by the DHCP DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
server, then that IP address MUST be set in the "ciaddr" field of a server, then that IP address MUST be set in the "ciaddr" field of a
DHCPLEASEUNASSIGNED message. DHCPLEASEUNASSIGNED message.
If the IP address is not managed by the DHCP server, then a If the IP address is not managed by the DHCP server, then a
DHCPLEASEUNKNOWN message must be returned. DHCPLEASEUNKNOWN message must be returned.
If the "ciaddr" field of the DHCPLEASEQUERY is zero, then the If the "ciaddr" field of the DHCPLEASEQUERY is zero, then the
DHCPLEASEQUERY message is a query by Client-identifier or MAC DHCPLEASEQUERY message is a query by Client-identifier or MAC
address. In this case, the client's identity is any client which has address. In this case, the client's identity is any client that has
proffered an identical Client-identifier option (if the Client- proffered an identical Client-identifier option (if the Client-
identifier option appears in the DHCPLEASEQUERY message), or an identifier option appears in the DHCPLEASEQUERY message), or an
identical MAC address (if the MAC address fields in the identical MAC address (if the MAC address fields in the
DHCPLEASEQUERY message are non-zero). This client matching approach DHCPLEASEQUERY message are non-zero). This client matching approach
will, for the purposes of this section, be described as "Client- will, for the purposes of this section, be described as "Client-
identifier or MAC address". identifier or MAC address".
If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the
IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message
MUST be that of an IP address for which the client that most recently MUST be that of an IP address for which the client that most recently
used the IP address matches the Client-identifier or MAC address used the IP address matches the Client-identifier or MAC address
specified in the DHCPLEASEQUERY message. specified in the DHCPLEASEQUERY message.
If there is only a single IP address which fulfills this criteria, If there is only a single IP address that fulfills this criteria,
then it MUST be placed in the "ciaddr" field of the DHCPLEASEACTIVE then it MUST be placed in the "ciaddr" field of the DHCPLEASEACTIVE
message. message.
In the case where more than one IP address has been accessed by the In the case where more than one IP address has been accessed by the
client specified by the MAC address or Client-identifier option, then client specified by the MAC address or Client-identifier option, then
the DHCP server MUST return the IP address returned to the client in the DHCP server MUST return the IP address returned to the client in
the most recent transaction with the client unless the DHCP server the most recent transaction with the client unless the DHCP server
has been configured by the server administrator to use some other has been configured by the server administrator to use some other
preference mechanism. preference mechanism.
If, after all of the above processing, no value is set in the If, after all of the above processing, no value is set in the
"ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message, "ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message,
then a DHCPLEASEUNKNOWN message MUST be returned instead. then a DHCPLEASEUNKNOWN message MUST be returned instead.
6.4.2. Building a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message once 6.4.2. Building a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE Message Once
the "ciaddr" field is set the "ciaddr" Field Is Set
Once the "ciaddr" field of the DHCPLEASEUNASSIGNED is set, the Once the "ciaddr" field of the DHCPLEASEUNASSIGNED is set, the
processing for a DHCPLEASEUNASSIGNED message is complete. No other processing for a DHCPLEASEUNASSIGNED message is complete. No other
options returned for the DHCPLEASEUNASSIGNED message. options are returned for the DHCPLEASEUNASSIGNED message.
For the DHCPLEASEACTIVE message, the rest of the processing largely For the DHCPLEASEACTIVE message, the rest of the processing largely
involves returning information about the IP address specified in the involves returning information about the IP address specified in the
"ciaddr" field. "ciaddr" field.
The IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED or The IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED or
DHCPLEASEACTIVE message MUST be one for which this server is DHCPLEASEACTIVE message MUST be one for which this server is
responsible (or a DHCPLEASEUNKNOWN message would be have already been responsible (or a DHCPLEASEUNKNOWN message would be have already been
returned early in the processing described in the previous section). returned early in the processing described in the previous section).
The MAC address of the DHCPLEASEACTIVE message MUST be set to the The MAC address of the DHCPLEASEACTIVE message MUST be set to the
values which identify the client associated with the IP address in values that identify the client associated with the IP address in the
the "ciaddr" field of the DHCPLEASEUNASSIGNED message. "ciaddr" field of the DHCPLEASEUNASSIGNED message.
If the Client-identifier option (option 61) is specified in the If the Client-identifier option (option 61) is specified in the
Parameter Request List option (option 55), then the Client-identifier Parameter Request List option (option 55), then the Client-identifier
(if any) of the client associated with the IP address in the "ciaddr" (if any) of the client associated with the IP address in the "ciaddr"
field SHOULD be returned in the DHCPLEASEACTIVE message. field SHOULD be returned in the DHCPLEASEACTIVE message.
In the case where more than one IP address has been involved in a In the case where more than one IP address has been involved in a
DHCP message exchange with the client specified by the MAC address DHCP message exchange with the client specified by the MAC address
and/or Client-identifier option, then the list of all of the IP and/or Client-identifier option, then the list of all of the IP
addresses MUST be returned in the associated-ip option, whether or addresses MUST be returned in the associated-ip option, whether or
skipping to change at page 19, line 9 skipping to change at page 19, line 11
(T2) Time Value option in the Parameter Request List of the (T2) Time Value option in the Parameter Request List of the
DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time
option is handled. If there is a valid lease and these times are not option is handled. If there is a valid lease and these times are not
yet in the past, then the DHCP server SHOULD return these options yet in the past, then the DHCP server SHOULD return these options
(when requested) with the remaining time until renewal or rebinding, (when requested) with the remaining time until renewal or rebinding,
respectively. If these times are already in the past, or if there is respectively. If these times are already in the past, or if there is
not currently a valid lease for this IP address, the DHCP server MUST not currently a valid lease for this IP address, the DHCP server MUST
NOT return these options. NOT return these options.
If the Relay Agent Information (option 82) is specified in the If the Relay Agent Information (option 82) is specified in the
Parameter Request List then the information contained in the most Parameter Request List, then the information contained in the most
recent Relay Agent Information option received from the relay agent recent Relay Agent Information option received from the relay agent
associated with this IP address MUST be included in the associated with this IP address MUST be included in the
DHCPLEASEACTIVE message. The DHCP server MUST the Relay Agent DHCPLEASEACTIVE message.
Information option that was received when from the relay agent
associated with this IP address.
The DHCPLEASEACTIVE message SHOULD include the values of all other The DHCPLEASEACTIVE message SHOULD include the values of all other
options not specifically discussed above that were requested in the options not specifically discussed above that were requested in the
Parameter Request List of the DHCPLEASEQUERY message and that are Parameter Request List of the DHCPLEASEQUERY message and that are
acceptable to return based on the list of "non-senstive options", acceptable to return based on the list of "non-sensitive options",
discussed below. discussed below.
DHCP servers SHOULD be configurable with a list of "non-sensitive DHCP servers SHOULD be configurable with a list of "non-sensitive
options" that can be returned to the client when specified in the options" that can be returned to the client when specified in the
Parameter Request List of the DHCPLEASEQUERY message. Any option not Parameter Request List of the DHCPLEASEQUERY message. Any option not
on this should SHOULD NOT be returned to a client, even if requested on this list SHOULD NOT be returned to a client, even if requested by
by that client. that client.
The DHCP server uses information from its lease binding database to The DHCP server uses information from its lease binding database to
supply the DHCPLEASEACTIVE option values. The values of the options supply the DHCPLEASEACTIVE option values. The values of the options
that were returned to the DHCP client would generally be preferred, that were returned to the DHCP client would generally be preferred,
but in the absence of those, options that were sent in DHCP client but in the absence of those, options that were sent in DHCP client
requests would be acceptable. requests would be acceptable.
In some cases, the Relay Agent Information option in an incoming In some cases, the Relay Agent Information option in an incoming
DHCPREQUEST packet is used to help determine the options returned to DHCPREQUEST packet is used to help determine the options returned to
the DHCP client which sent the DHCPREQUEST. When responding to a the DHCP client that sent the DHCPREQUEST. When responding to a
DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay
Agent Information option just like it did when responding to the DHCP Agent Information option just like it did when responding to the DHCP
client in order to determine the values of any options requested by client in order to determine the values of any options requested by
the DHCPLEASEQUERY message. The goal is to return the same option the DHCPLEASEQUERY message. The goal is to return the same option
values to the DHCPLEASEQUERY as those that were returned to the values to the DHCPLEASEQUERY as those that were returned to the
DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise
specified, above). specified, above).
In the event that two servers are cooperating to provide a high In the event that two servers are cooperating to provide a high-
availability DHCP server, as supported by [RFC2131], they would have availability DHCP server, as supported by [RFC2131], they would have
to communicate some information about IP address bindings to each to communicate some information about IP address bindings to each
other. In order to properly support the DHCPLEASEQUERY message, other. In order to properly support the DHCPLEASEQUERY message,
these servers MUST ensure that they communicate the Relay Agent these servers MUST ensure that they communicate the Relay Agent
Information option information to each other in addition to any other Information option information to each other in addition to any other
IP address binding information. IP address binding information.
6.4.3. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 6.4.3. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN message DHCPLEASEUNKNOWN Message
The server expects a giaddr in the DHCPLEASEQUERY message, and The server expects a giaddr in the DHCPLEASEQUERY message, and
unicasts the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN unicasts the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
message to the giaddr. If the giaddr field is zero, then the DHCP DHCPLEASEUNKNOWN message to the giaddr. If the "giaddr" field is
server MUST NOT reply to the DHCPLEASEQUERY message. zero, then the DHCP server MUST NOT reply to the DHCPLEASEQUERY
message.
6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN Message DHCPLEASEUNKNOWN Message
When a DHCPLEASEACTIVE message is received in response to the When a DHCPLEASEACTIVE message is received in response to the
DHCPLEASEQUERY message it means that there is a currently active DHCPLEASEQUERY message, it means that there is a currently active
lease for this IP address in this DHCP server. The access lease for this IP address in this DHCP server. The access
concentrator SHOULD use the information in the htype, hlen, and concentrator SHOULD use the information in the "htype", "hlen", and
chaddr fields of the DHCPLEASEACTIVE as well as any Relay Agent "chaddr" fields of the DHCPLEASEACTIVE as well as any Relay Agent
Information option information included in the packet to refresh its Information option information included in the packet to refresh its
location information for this IP address. location information for this IP address.
When a DHCPLEASEUNASSIGNED message is received in response to the When a DHCPLEASEUNASSIGNED message is received in response to the
DHCPLEASEQUERY message that means that there is no currently active DHCPLEASEQUERY message, that means that there is no currently active
lease for the IP address present in the DHCP server, but that this lease for the IP address present in the DHCP server, but that this
server does in fact manage that IP address. In this case, the access server does in fact manage that IP address. In this case, the access
concentrator SHOULD cache this information in order to prevent concentrator SHOULD cache this information in order to prevent
unacceptable loads on the access concentrator and the DHCP server in unacceptable loads on the access concentrator and the DHCP server in
the face of a malicious or seriously compromised device downstream of the face of a malicious or seriously compromised device downstream of
the access concentrator. This caching could be as simple as simply the access concentrator. This caching could be as simple as simply
setting a bit saying that a response was received from a server which setting a bit saying that a response was received from a server that
knew about this IP address but that there was no current lease. This knew about this IP address but that there was no current lease. This
would of course need to be cleared when the access concentrator next would, of course, need to be cleared when the access concentrator
"gleaned" that a lease for this IP address came into existence. next "gleaned" that a lease for this IP address came into existence.
In either case, when a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message In either case, when a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message
is received in response to a DHCPLEASEQUERY message, it means that is received in response to a DHCPLEASEQUERY message, it means that
the DHCP server which responded is a DHCP server which manages the IP the DHCP server that responded is a DHCP server that manages the IP
address present in the ciaddr, and the Relay Agent SHOULD cache this address present in the ciaddr, and the Relay Agent SHOULD cache this
information for later use. information for later use.
When a DHCPLEASEUNKNOWN message is received by an access concentrator When a DHCPLEASEUNKNOWN message is received by an access concentrator
which has sent out a DHCPLEASEQUERY message, it means that the DHCP that has sent out a DHCPLEASEQUERY message, it means that the DHCP
server contacted supports the DHCPLEASEQUERY message but that the server contacted supports the DHCPLEASEQUERY message but that the
DHCP server does not have definitive information concerning the IP DHCP server does not have definitive information concerning the IP
address contained in the "ciaddr" field of the DHCPLEASEQUERY address contained in the "ciaddr" field of the DHCPLEASEQUERY
message. If there is no IP address in the "ciaddr" field of the message. If there is no IP address in the "ciaddr" field of the
DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means that DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means that
the DHCP server does not have definitive information concerning the the DHCP server does not have definitive information concerning the
any DHCP client specified in the "hlen", "htype", and "chaddr" fields DHCP client specified in the "hlen", "htype", and "chaddr" fields or
or the Client-identifier option of the DHCPLEASEQUERY message. the Client-identifier option of the DHCPLEASEQUERY message.
The access concentrator SHOULD cache this information, but only for a The access concentrator SHOULD cache this information, but only for a
relatively short lifetime, approximately 5 minutes. relatively short lifetime, approximately 5 minutes.
Having cached this information, the access concentrator SHOULD only Having cached this information, the access concentrator SHOULD only
infrequently direct a DHCPLEASEQUERY message to a DHCP server that infrequently direct a DHCPLEASEQUERY message to a DHCP server that
responded to a DHCPLEASEQUERY message for a particular "ciaddr" field responded to a DHCPLEASEQUERY message for a particular "ciaddr" field
with a DHCPLEASEUNKNOWN. with a DHCPLEASEUNKNOWN.
6.6. Receiving no response to the DHCPLEASEQUERY Message 6.6. Receiving No Response to the DHCPLEASEQUERY Message
When an access concentrator receives no response to a DHCPLEASEQUERY When an access concentrator receives no response to a DHCPLEASEQUERY
message, there are several possible reasons: message, there are several possible reasons:
o The DHCPLEASEQUERY or a corresponding DHCPLEASEUNASSIGNED, o The DHCPLEASEQUERY or a corresponding DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE or DHCPLEASEUNKNOWN were lost during DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN was lost during transmission
transmission or the DHCPLEASEQUERY arrived at the DHCP server or the DHCPLEASEQUERY arrived at the DHCP server but it was
but it was dropped because the server was too busy. dropped because the server was too busy.
o The DHCP server doesn't support DHCPLEASEQUERY. o The DHCP server doesn't support DHCPLEASEQUERY.
In the first of the cases above, a retransmission of the In the first of the cases above, a retransmission of the
DHCPLEASEQUERY would be appropriate, but in the second of the two DHCPLEASEQUERY would be appropriate, but in the second of the two
cases, a retransmission would not be appropriate. There is no way to cases, a retransmission would not be appropriate. There is no way to
tell these two cases apart (other than, perhaps, because of a DHCP tell these two cases apart (other than, perhaps, because of a DHCP
server's response to other DHCPLEASEQUERY messages indicating that it server's response to other DHCPLEASEQUERY messages indicating that it
does or does not support the DHCPLEASEQUERY message). does or does not support the DHCPLEASEQUERY message).
An access concentrator which utilizes the DHCPLEASEQUERY message An access concentrator that utilizes the DHCPLEASEQUERY message
SHOULD attempt to resend DHCPLEASEQUERY messages to servers which do SHOULD attempt to resend DHCPLEASEQUERY messages to servers that do
not respond to them using a backoff algorithm for the retry time that not respond to them using a backoff algorithm for the retry time that
approximates an exponential backoff. The access concentrator SHOULD approximates an exponential backoff. The access concentrator SHOULD
adjust the backoff approach such that DHCPLEASEQUERY messages do not adjust the backoff approach such that DHCPLEASEQUERY messages do not
arrive at a server which is not otherwise known to support the arrive at a server that is not otherwise known to support the
DHCPLEASEQUERY message at a rate of more than approximately one DHCPLEASEQUERY message at a rate of more than approximately one
packet every 10 seconds, and yet (if the access concentrator needs to packet every 10 seconds, and yet (if the access concentrator needs to
send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per 70 send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per 70
seconds. seconds.
In practice this approach would probably best be handled by a per- In practice, this approach would probably best be handled by a per-
server timer that is restarted whenever a response to a server timer that is restarted whenever a response to a
DHCPLEASEQUERY message is received, and expires after one minute. DHCPLEASEQUERY message is received, and expires after one minute.
The per-server timer would start off expired, and in the expired The per-server timer would start off expired, and in the expired
state only one DHCPLEASEQUERY message would be queued for the state only one DHCPLEASEQUERY message would be queued for the
associated server. associated server.
All DHCPLEASEQUERY messages SHOULD use the exponential backoff All DHCPLEASEQUERY messages SHOULD use the exponential backoff
algorithm specified in RFC 2131, section 4.1 [RFC 2131]. algorithm specified in Section 4.1 of [RFC2131].
Thus, in the initial state, the per-server timer is expired, and a Thus, in the initial state, the per-server timer is expired, and a
single DHCPLEASEQUERY message is queued for each server. After the single DHCPLEASEQUERY message is queued for each server. After the
first response to a DHCPLEASEQUERY message, the per-server timer is first response to a DHCPLEASEQUERY message, the per-server timer is
started. At that time, multiple DHCPLEASEQUERY message can be sent started. At that time, multiple DHCPLEASEQUERY messages can be sent
in parallel to the DHCP server, though the total number SHOULD be in parallel to the DHCP server, though the total number SHOULD be
limited to 100 or 200, to avoid swamping the DHCP server. Each of limited to 100 or 200, to avoid swamping the DHCP server. Each of
these messages uses the RFC 2131 exponential backoff algorithm. these messages uses the [RFC2131] exponential backoff algorithm.
Every time a response to any of these messages is received, the per- Every time a response to any of these messages is received, the per-
server timer is reset and starts counting again up to one minute. In server timer is reset and starts counting again up to one minute. In
the event the per-server timer goes off, then all outstanding the event the per-server timer goes off, then all outstanding
messages SHOULD be dropped except for a single DHCPLEASEQUERY message messages SHOULD be dropped except for a single DHCPLEASEQUERY message
which is used to poll the server at approximately 64 second intervals that is used to poll the server at approximately 64-second intervals
until such time as another (or the first) response to the until such time as another (or the first) response to the
DHCPLEASEQUERY is received. DHCPLEASEQUERY is received.
In the event that there is no DHCPLEASEQUERY traffic for one minute, In the event that there is no DHCPLEASEQUERY traffic for one minute,
then the per-server timer will expire. After that time, there will then the per-server timer will expire. After that time, there will
only be one DHCPLEASEQUERY message allowed to be outstanding to that only be one DHCPLEASEQUERY message allowed to be outstanding to that
server until a response to that message is received. server until a response to that message is received.
6.7. Lease binding data storage requirements 6.7. Lease Binding Data Storage Requirements
DHCP server implementations that implement the DHCPLEASEQUERY DHCP server implementations that implement the DHCPLEASEQUERY
capability MUST save the most recent Relay Agent Information option capability MUST save the most recent Relay Agent Information option
from the most recent DHCPREQUEST packet for two reasons. First, it from the most recent DHCPREQUEST packet for two reasons. First, it
is almost certain to be requested by in the dhcp-parameter-request- is almost certain to be requested by in the dhcp-parameter-request-
list option in any DHCPLEASEQUERY request. Second, the saved Relay list option in any DHCPLEASEQUERY request. Second, the saved Relay
Agent Information option may be necessary to determine the value of Agent Information option may be necessary to determine the value of
other options given to the DHCP client, if these are requested by the other options given to the DHCP client, if these are requested by the
dhcp-parameter-request list in the DHCPLEASEQUERY request. dhcp-parameter-request list in the DHCPLEASEQUERY request.
skipping to change at page 23, line 5 skipping to change at page 23, line 5
o client-last-transaction-time of last client interaction: MUST o client-last-transaction-time of last client interaction: MUST
store with binding. store with binding.
o vendor-class-id: SHOULD store with binding. o vendor-class-id: SHOULD store with binding.
These data storage requirements are minimally larger than those These data storage requirements are minimally larger than those
required for normal operation of the DHCP protocol, as required to required for normal operation of the DHCP protocol, as required to
properly implement [RFC2131]. properly implement [RFC2131].
6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 6.8. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers
When using the DHCPLEASEQUERY message in an environment where When using the DHCPLEASEQUERY message in an environment where
multiple DHCP servers may contain authoritative information about the multiple DHCP servers may contain authoritative information about the
same IP address (such as when two DHCP servers are cooperating to same IP address (such as when two DHCP servers are cooperating to
provide a high availability DHCP service) multiple, possibly provide a high-availability DHCP service), multiple, possibly
conflicting, responses might be received. conflicting, responses might be received.
In this case, some information in the response packet SHOULD be used In this case, some information in the response packet SHOULD be used
to decide among the various responses. The client-last-transaction- to decide among the various responses. The client-last-transaction-
time (if it is available) can be used to decide which server has more time (if it is available) can be used to decide which server has more
recent information concerning the IP address returned in the "ciaddr" recent information concerning the IP address returned in the "ciaddr"
field. field.
7. Security Considerations 7. Security Considerations
Access concentrators that use DHCP gleaning, refreshed with Access concentrators that use DHCP gleaning, refreshed with
DHCPLEASEQUERY messages, will maintain accurate location information. DHCPLEASEQUERY messages, will maintain accurate location information.
Location information accuracy ensures that the access concentrator Location information accuracy ensures that the access concentrator
can forward data traffic to the intended location in the broadband can forward data traffic to the intended location in the broadband
access network, can perform IP source address verification of access network, can perform IP source address verification of
datagrams from the access network, and can encrypt traffic which can datagrams from the access network, and can encrypt traffic that can
only be decrypted by the intended access modem (e.g. [BPI] and only be decrypted by the intended access modem (e.g., [BPI] and
[BPI+]). As a result, the access concentrator does not need to [BPI+]). As a result, the access concentrator does not need to
depend on ARP broadcasts across the access network, which is depend on ARP broadcasts across the access network, which is
susceptible to malicious hosts which masquerade as the intended IP susceptible to malicious hosts that masquerade as the intended IP
endpoints. Thus, the DHCPLEASEQUERY message allows an access endpoints. Thus, the DHCPLEASEQUERY message allows an access
concentrator to provide considerably enhanced security. concentrator to provide considerably enhanced security.
DHCP servers SHOULD prevent exposure of location information DHCP servers SHOULD prevent exposure of location information
(particularly the mapping of hardware address to IP address lease, (particularly the mapping of hardware address to IP address lease,
which can be an invasion of broadband subscriber privacy) by which can be an invasion of broadband subscriber privacy) by
employing the techniques detailed in [RFC 3118], "Authentication for employing the techniques detailed in [RFC3118], "Authentication for
DHCP Messages". DHCP Messages".
This RFC describes how a DHCP client interacts with a DHCP server. This RFC describes how a DHCP client interacts with a DHCP server.
Access concentrators that send the DHCPLEASEQUERY message are Access concentrators that send the DHCPLEASEQUERY message are
essentially DHCP clients for the purposes of the DHCPLEASEQUERY essentially DHCP clients for the purposes of the DHCPLEASEQUERY
message, even though they perform the functions of a DHCP relay agent message, even though they perform the functions of a DHCP relay agent
as well. Thus, [RFC 3118] is an appropriate mechanism for as well. Thus, [RFC3118] is an appropriate mechanism for
DHCPLEASEQUERY messages. DHCPLEASEQUERY messages.
Since [RFC 3118] discusses the normal DHCP client interaction, Since [RFC3118] discusses the normal DHCP client interaction,
consisting of a DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, it consisting of a DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, it
is necessary to transpose the operations described in [RFC 3118] to is necessary to transpose the operations described in [RFC3118] to
the DHCPLEASEQUERY domain. The operations described in [RFC 3118] the DHCPLEASEQUERY domain. The operations described in [RFC3118] for
for DHCPDISCOVER are performed for DHCPLEASEQUERY, and the operations DHCPDISCOVER are performed for DHCPLEASEQUERY, and the operations
described for DHCPOFFER are performed for DHCPLEASEUNASSIGNED, described for DHCPOFFER are performed for DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE, DHCPLEASEUNKNOWN messages. DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN messages.
Access concentrators SHOULD minimize potential denial of service Access concentrators SHOULD minimize potential denial of service
attacks on the DHCP servers by minimizing the generation of attacks on the DHCP servers by minimizing the generation of
DHCPLEASEQUERY messages. In particular, the access concentrator DHCPLEASEQUERY messages. In particular, the access concentrator
SHOULD employ negative caching (i.e. cache DHCPLEASEUNASSIGNED, SHOULD employ negative caching (i.e., cache DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY
messages) and ciaddr restriction (i.e. don't send a DHCPLEASEQUERY messages) and ciaddr restriction (i.e., don't send a DHCPLEASEQUERY
message with a ciaddr outside of the range of the attached broadband message with a ciaddr outside of the range of the attached broadband
access networks). Together, these mechanisms limit the access access networks). Together, these mechanisms limit the access
concentrator to transmitting one DHCPLEASEQUERY message (excluding concentrator to transmitting one DHCPLEASEQUERY message (excluding
message retries) per legitimate broadband access network IP address message retries) per legitimate broadband access network IP address
after a reboot event. after a reboot event.
DHCP servers supporting the DHCPLEASEQUERY message SHOULD ensure that DHCP servers supporting the DHCPLEASEQUERY message SHOULD ensure that
they cannot be successfully attacked by being flooded with large they cannot be successfully attacked by being flooded with large
quantities of DHCPLEASEQUERY messages in a short time. quantities of DHCPLEASEQUERY messages in a short time.
In some environments it may be appropriate to configure a DHCP server In some environments, it may be appropriate to configure a DHCP
with the IP addresses of the relay agents for which it may respond to server with the IP addresses of the relay agents for which it may
DHCPLEASEQUERY messages, thereby allowing it to respond only to to respond to DHCPLEASEQUERY messages, thereby allowing it to respond
requests from only a handful of relay agents. This does not provide only to requests from only a handful of relay agents. This does not
any true security, but may be useful to thwart unsophisticated provide any true security, but may be useful to thwart
attacks of various sorts. unsophisticated attacks of various sorts.
8. IANA Considerations 8. IANA Considerations
IANA has assigned seven values for this document. See Section 6.1 for IANA has assigned six values for this document. See Section 6.1 for
details. There are four new messages types, which are the value of details. There are four new messages types, which are the value of
the message type option (option 53) from [RFC 2132]. The value for the message type option (option 53) from [RFC2132]. The value for
DHCPLEASEQUERY is TBD, the value for DHCPLEASEUNASSIGNED is TBD, the DHCPLEASEQUERY is 10, the value for DHCPLEASEUNASSIGNED is 11, the
value for DHCPLEASEACTIVE is TBD, and the value for DHCPLEASEUNKNOWN value for DHCPLEASEUNKNOWN is 12, and the value for DHCPLEASEACTIVE
is TBD. Finally, there are two new DHCP option defined; the client- is 13. Finally, there are two new DHCP option defined; the client-
last-transaction-time option -- option code TBD, and the associated- last-transaction-time option -- option code 91, and the associated-ip
ip option -- option code TBD. option -- option code 92.
9. Acknowledgments 9. Acknowledgements
Jim Forster, Joe Ng, Guenter Roeck, and Mark Stapp contributed Jim Forster, Joe Ng, Guenter Roeck, and Mark Stapp contributed
greatly to the initial creation of the DHCPLEASEQUERY message. greatly to the initial creation of the DHCPLEASEQUERY message.
Patrick Guelat suggested several improvements to support static IP Patrick Guelat suggested several improvements to support static IP
addressing. Thomas Narten made many suggestions for improvements. addressing. Thomas Narten made many suggestions for improvements.
Russ Housely pressed effectively for increased security capabilities Russ Housley pressed effectively for increased security capabilities,
and Ted Hardie suggested ways to minimize undesired information and Ted Hardie suggested ways to minimize undesired information
leakage. Bert Wijnen suggested we clarify our focus to DHCPv4 and leakage. Bert Wijnen suggested we clarify our focus to DHCPv4 and
distinguish our approach from that of the DHCP MIB. R. Barr Hibbs, distinguish our approach from that of the DHCP MIB. R. Barr Hibbs,
one of the authors of the DHCP MIB, supplied information to one of the authors of the DHCP MIB, supplied information to
effectively distinguish that effort from DHCPLEASEQUERY. effectively distinguish that effort from DHCPLEASEQUERY.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
[RFC 3118] Droms, R., Arbaugh, W., "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
10.2. Informative References 10.2. Informative References
[RFC 826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address converting network protocol addresses to 48.bit Ethernet
for transmission on Ethernet hardware", RFC 826, November 1982. address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC [RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
951, September 1985. September 1985.
[RFC 1542] Wimer, W., "Clarifications and Extensions for the [RFC1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993. Bootstrap Protocol", RFC 1542, October 1993.
[RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Extensions", RFC 2132, March 1997. Vendor Extensions", RFC 2132, March 1997.
[RFC 3315] Droms, R., Bound J., Volz B., Lemon T., Perkins C., Carney [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
M., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC and M. Carney, "Dynamic Host Configuration Protocol for
3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[BPI] CableLabs, "Baseline Privacy Interface Specification", SP-BPI- [BPI] SCTE Data Standards Subcommittee, "Data-Over-Cable
I02-990319, March 1999, available at http://www.cablemodem.com/. Service Interface Specifications: DOCSIS 1.0 Baseline
Privacy Interface Specification SCTE 22-2 2002", 2002,
available at http://www.scte.org/standards/.
[BPI+] CableLabs, "Baseline Privacy Plus Interface Specification", [BPI+] CableLabs, "Data-Over-Cable Service Interface
SP-BPI+-I04-000407, April 2000, available at Specifications: Baseline Privacy Plus Interface
http://www.cablemodem.com/. Specification CM-SP-BPI+_I12-050812", August 2005,
available at http://www.cablemodem.com/.
[DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol [DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration
(DHCP) Server MIB", draft-ietf-dhc-server-mib-10.txt, February Protocol (DHCP) Server MIB", Work in Progress, February
2004. 2004.
[DOCSIS] CableLabs, "Data-Over-Cable Service Interface [DOCSIS] SCTE Data Standards Subcommittee, "Data-Over-Cable
Specifications: Cable Modem Radio Frequency Interface Service Interface Specifications: DOCSIS 1.0 Radio
Specification SP-RFI-I05-991105", November 1999. Frequency Interface Specification SCTE 22-1 2002", 2002,
available at http://www.scte.org/standards/.
[EUROMODEM] ECCA, "Technical Specification of a European Cable Modem [EUROMODEM] ECCA, "Technical Specification of a European Cable Modem
for digital bi-directional communications via cable networks", for digital bi-directional communications via cable
Version 1.0, May 1999. networks", Version 1.0, May 1999.
11. Author's information Authors' Addresses
Rich Woundy Rich Woundy
Comcast Cable Comcast Cable
27 Industrial Ave. 27 Industrial Ave.
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 244-4010 Phone: (978) 244-4010
EMail: richard_woundy@cable.comcast.com
EMail: richard_woundy@cable.comcast.com Kim Kinnear
Cisco Systems
1414 Massachusetts Ave
Boxborough, MA 01719
Kim Kinnear Phone: (978) 936-0000
Cisco Systems EMail: kkinnear@cisco.com
1414 Massachusetts Ave
Boxborough, MA 01719
Phone: (978) 936-0000 Full Copyright Statement
EMail: kkinnear@cisco.com Copyright (C) The Internet Society (2006).
12. Intellectual Property Statement This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
The IETF takes no position regarding the validity or scope of any This document and the information contained herein are provided on an
intellectual property or other rights that might be claimed to pertain "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
to the implementation or use of the technology described in this OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
document or the extent to which any license under such rights might or ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
might not be available; neither does it represent that it has made any INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
effort to identify any such rights. Information on the IETF's INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
procedures with respect to rights in standards-track and standards- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.
The IETF invites any interested party to bring to its attention any Intellectual Property
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.
13. Full Copyright Statement The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copyright (C) The Internet Society (2005). This document is subject to Copies of IPR disclosures made to the IETF Secretariat and any
the rights, licenses and restrictions contained in BCP 78, and except as assurances of licenses to be made available, or the result of an
set forth therein, the authors retain all their rights. attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
This document and the information contained herein are provided on an The IETF invites any interested party to bring to its attention any
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR copyrights, patents or patent applications, or other proprietary
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET rights that may cover technology that may be required to implement
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, this standard. Please address the information to the IETF at
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE ietf-ipr@ietf.org.
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 183 change blocks. 
442 lines changed or deleted 428 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/