draft-ietf-dhc-leasequery-02.txt   draft-ietf-dhc-leasequery-03.txt 
Dynamic Host Configuration Working Group Rich Woundy Dynamic Host Configuration Working Group Rich Woundy
INTERNET DRAFT Kim Kinnear INTERNET DRAFT Kim Kinnear
Cisco Systems Cisco Systems
July 2001 March 2002
Expires January 2002 Expires September 2002
DHCP Lease Query DHCP Lease Query
<draft-ietf-dhc-leasequery-02.txt> <draft-ietf-dhc-leasequery-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
Access concentrators that act as DHCP relay agents need to determine Access concentrators that act as DHCP relay agents need to determine
the endpoint locations of IP addresses across public broadband access the endpoint locations of IP addresses across public broadband access
networks such as cable, DSL, and wireless networks. Because ARP networks such as cable, DSL, and wireless networks. Because ARP
broadcasts are undesirable in public networks, many access broadcasts are undesirable in public networks, many access
concentrator implementations "glean" location information from DHCP concentrator implementations "glean" location information from DHCP
messages forwarded by its relay agent function. Unfortunately, the messages forwarded by its relay agent function. Unfortunately, the
typical access concentrator loses its gleaned information when the typical access concentrator loses its gleaned information when the
skipping to change at page 3, line 34 skipping to change at page 3, line 34
DHCP server responses sent through the relay agent. When location DHCP server responses sent through the relay agent. When location
information is not available from "gleaning", e.g. due to reboot, information is not available from "gleaning", e.g. due to reboot,
the access concentrator can query the DHCP server(s) for location the access concentrator can query the DHCP server(s) for location
information using the DHCPLEASEQUERY message. The DHCPLEASEQUERY information using the DHCPLEASEQUERY message. The DHCPLEASEQUERY
mechanism is the focus of this document. mechanism is the focus of 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. The DHCPLEASEQUERY-aware from a DHCP relay agent to a DHCP server. The 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 DHCPKNOWN or DHCPUNKNOWN message. The DHCPKNOWN replies with a DHCPKNOWN, DHCPACTIVE or DHCPUNKNOWN message. The
response to a DHCPLEASEQUERY message allows the relay agent to deter- DHCPACTIVE response to a DHCPLEASEQUERY message allows the relay
mine the IP endpoint location, and the remaining duration of the IP agent to determine the IP endpoint location, and the remaining dura-
address lease. tion of the IP address lease.
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 [RFC 2119].
This document uses the following terms: This document uses the following terms:
o "access concentrator" o "access concentrator"
skipping to change at page 4, line 49 skipping to change at page 4, line 49
information includes knowledge of the host hardware address, the information includes knowledge of the host hardware address, the
port or virtual circuit that leads to the host, and/or the port or virtual circuit that leads to the host, and/or the
hardware address of the intervening subscriber modem. 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 fields: hardware type "htype", hardware length "hlen", and
client hardware address "chaddr". client hardware address "chaddr".
o "reservation"
At times it is convenient for an administrator to assign a fixed
IP address to a particular DHCP client. The DHCP server must be
configured with this DHCP client to IP address mapping, typi-
cally using the MAC address as the way to identify the client.
The DHCP client to IP address mapping, configured in the DHCP
server, is called a reservation for the purposes of this docu-
ment.
o "primary DHCP server" o "primary DHCP server"
The primary DHCP server in a DHCP Failover environment is con- The primary DHCP server in a DHCP Failover environment is con-
figured to provide primary service to a set of DHCP clients for figured to provide primary service to a set of DHCP clients for
a particular set of subnet address pools. a particular set of subnet address pools.
o "secondary DHCP server" o "secondary DHCP server"
The secondary DHCP server in a DHCP Failover environment is con- The secondary DHCP server in a DHCP Failover environment is con-
figured to act as backup to a primary server for a particular figured to act as backup to a primary server for a particular
skipping to change at page 5, line 47 skipping to change at page 6, line 10
The DHCPLEASEQUERY message is an optional extension to the DHCP pro- The DHCPLEASEQUERY message is an optional extension to the DHCP pro-
tocol [RFC 2131]. Unlike previous DHCP message types, the DHCP relay tocol [RFC 2131]. Unlike previous DHCP message types, the DHCP relay
agent originates and sends the DHCPLEASEQUERY message to the DHCP agent originates and sends the DHCPLEASEQUERY message to the DHCP
server, and processes the reply from the DHCP server (a DHCPKNOWN or server, and processes the reply from the DHCP server (a DHCPKNOWN or
DHCPUNKNOWN). DHCPUNKNOWN).
In a DHCP Failover environment [FAILOVER], the DHCPLEASEQUERY message In a DHCP Failover environment [FAILOVER], the DHCPLEASEQUERY message
can be sent to the primary or secondary DHCP server. In order for the can be sent to the primary or secondary DHCP server. In order for the
secondary DHCP server to answer DHCPLEASEQUERY messages, the primary secondary DHCP server to answer DHCPLEASEQUERY messages, the primary
DHCP server must send "interesting options" (such as the relay- DHCP server must send "interesting options" (such as the relay-
agent-information option) in Failover BNDUPD messages to the secon- agent-information option [RFC 3046]) in Failover BNDUPD messages to
dary DHCP server, as recommended by section 7.1.1 of [FAILOVER]. the secondary DHCP server, as recommended by section 7.1.1 of [FAIL-
OVER].
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 associ- affect the state of the IP address or the binding information associ-
ated with it. ated with it.
4. Design Goals 4. Design Goals
The core requirement of this document is to provide a lightweight The core requirement of this document is to provide a lightweight
mechanism for access concentrator implementations to obtain location mechanism for access concentrator implementations to obtain location
information for broadband access network devices. The specifics of information for broadband access network devices. The specifics of
the broadband environment that drove the approach of this document the broadband environment that drove the approach of this document
follow. follow.
4.1. Broadcast ARP is Undesirable 4.1. Broadcast ARP is Undesirable
The access concentrator can transmit a broadcast ARP Request [RFC 826], The access concentrator can transmit a broadcast ARP Request [RFC
and observe the origin and contents of the ARP Reply, to reconstruct the 826], and observe the origin and contents of the ARP Reply, to recon-
location information. struct 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 multiple
access ports and virtual circuits (assuming that IP subnets span access ports and virtual circuits (assuming that IP subnets
multiple ports or virtual circuits), span multiple ports or virtual circuits),
2. the burden on the numerous subscriber hosts to receive and process 2. the burden on the numerous subscriber hosts to receive and pro-
the broadcast, and cess the broadcast, and
3. the ease by which a malicious host can misrepresent itself as the 3. the ease by which a malicious host can misrepresent itself as
IP endpoint. the IP endpoint.
4.2. SNMP and LDAP Client Functionality is Lacking 4.2. SNMP and LDAP Client Functionality is Lacking
Access concentrator implementations typically do not have SNMP manage- Access concentrator implementations typically do not have SNMP
ment client interfaces nor LDAP client interfaces (although they typi- management client interfaces nor LDAP client interfaces (although
cally do include SNMP management agents). This is a primary reason why they typically do include SNMP management agents). This is a primary
this document does not leverage the proposed DHCP Server MIB [DHCPMIB] reason why this document does not leverage the proposed DHCP Server
nor leverage the proposed DHCP LDAP schema [DHCPSCHEMA]. MIB [DHCPMIB].
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 DHCP many access concentrators already glean location information from
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
mechanisms (ARP, SNMP, LDAP) because of the lack of additional net-
work traffic, but sometimes gleaning information can be incomplete.
The access concentrator usually cannot glean information from any
DHCP unicast (i.e. non-relayed) messages due to performance reasons.
Furthermore, the DHCP-gleaned location information often does not
persist across access concentrator reboots (due to lack of stable
storage), and almost never persists across concentrator replacements.
valid for a particular downstream link is preferred over other mechan- 4.4. DHCP Servers as a Reliable Source of Location Information
isms (ARP, SNMP, LDAP) because of the lack of additional network
traffic, but sometimes gleaning information can be incomplete. The
access concentrator usually cannot glean information from any DHCP uni-
cast (i.e. non-relayed) messages due to performance reasons. Further-
more, the DHCP-gleaned location information often does not persist
across access concentrator reboots (due to lack of stable storage), and
almost never persists across concentrator replacements.
4.4. DHCP Servers Are Most 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 single dynamic and not reproducible by algorithmic means (e.g. when a sin-
IP subnet extends behind many broadband modems). DHCP servers partici- gle IP subnet extends behind many broadband modems). DHCP servers
pate in all IP lease transactions (and therefore in all location infor- participate in all IP lease transactions (and therefore in all loca-
mation updates) with DHCP clients, whereas access concentrators some- tion information updates) with DHCP clients, whereas access concen-
times miss some important lease transactions. trators sometimes miss some important lease transactions.
In a DHCP Failover environment [FAILOVER], the access concentrator can In a DHCP Failover environment [FAILOVER], the access concentrator
query either the primary or secondary DHCP server, so that no one DHCP can query either the primary or secondary DHCP server, so that no one
server is a single point of failure. DHCP server is a 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 used Access concentrators can usually query the same set of DHCP servers
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
The access concentrator initiates all DHCPLEASEQUERY message conver- The access concentrator initiates all DHCPLEASEQUERY message conver-
sations. This document assumes that the access concentrator gleans sations. This document assumes that the access concentrator gleans
location information in its DHCP relay agent function. However, the location information in its DHCP relay agent function. However, the
location information is usually unavailable after the reboot or location information is usually unavailable after the reboot or
replacement of the access concentrator. 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 pub- the router receives an IP datagram to forward downstream to the pub-
lic broadband access network. If the location information for the lic 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.
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 and/or a client-id 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 SHOULD return an IP address in the "ciaddr". It MUST be DHCP server SHOULD return an IP address in the "ciaddr" if it has any
the IP address most recently used by the client described by the MAC record of the client described by the Client-identifier or MAC
address or client-id option (or both, if both appear). address. In the absence of specific configuration information to the
contrary (see Section 6.4) it MUST be the IP address most recently
used by the client described by the MAC address or Client-identifier
option (or the client described by both, if both appear).
The DHCP servers that implement this protocol always sends a response The DHCP servers that implement this protocol always send a response
to the DHCPLEASEQUERY message: either a DHCPKNOWN or DHCPUNKNOWN. The to the DHCPLEASEQUERY message: either a DHCPKNOWN, DHCPACTIVE or
DHCP server replies to the DHCPLEASEQUERY message with a DHCPKNOWN DHCPUNKNOWN (or in some cases, DHCPUNIMPLEMENTED). The reasons why a
message if the "ciaddr" corresponds to an IP address about which the DHCPKNOWN, DHCPACTIVE or DHCPUNKNOWN message might be generated are
server has definitive information (i.e., it is authorized to lease explained in the specific query regimes, below. Servers which do not
this IP address). The server replies with a DHCPUNKNOWN message if support the DHCPLEASEQUERY message SHOULD (and are expected to) drop
the server does not have definitive location information concerning the DHCPLEASEQUERY message silently, although they MAY respond with a
the lease implied by the "ciaddr". Note that non-DHCPLEASEQUERY- DHCPUNIMPLEMENTED message. The DHCPLEASEQUERY message can support
literate DHCP servers SHOULD (and are expected to) drop the three query regimes:
DHCPLEASEQUERY message silently. The DHCPLEASEQUERY message can sup-
port three different query regimes:
o Query by IP address: o Query by IP address:
For this query, the client passes in an IP address and the DHCP For this query, the "ciaddr" field MUST contain an IP address.
server the IP address and returns any information that it has on It MUST NOT contain a MAC address or Client-identifier option
the most recent client to utilized that IP address. Any server (option 61). The DHCP server will return any information that
which supports the DHCPLEASEQUERY message MUST support query by it has on the most recent client to have been allocated that IP
IP address. If an IP address appears in the "ciaddr" field, address. Any server which supports the DHCPLEASEQUERY message
then the query MUST be by IP address regardless of the contents MUST support query by IP address.
of the MAC address or client-id option (if any).
The DHCP server replies to the DHCPLEASEQUERY message with a
DHCPKNOWN or DHCPACTIVE message if the "ciaddr" corresponds to
an IP address about which the server has definitive information
(i.e., it is authorized to lease this IP address). The server
replies with a DHCPUNKNOWN message if the server does not have
definitive location information concerning the lease implied by
the "ciaddr".
o Query by MAC address: o Query by MAC address:
For this query, the MAC address is specified in the "htype", For this query, the "ciaddr" field MUST be zero and there MUST
"hlen", and "chaddr" fields and no IP address is given in the be a MAC address is specified in the "htype", "hlen", and
"ciaddr" field. The DHCP server looks up all IP addresses for "chaddr" fields. There MUST NOT be a Client-identifier option
which clients with this MAC address are the most recent acces- (option 61) in the packet. The DHCP server looks up all IP
sor. It returns information associated with the IP address most addresses for which clients with this MAC address are the most
recently accessed by a DHCP client with this MAC address. If recent user. In contrast to the query by IP address, there may
requested, the DHCP server SHOULD return information on all of be multiple IP addresses which show the client specified by the
the IP addresses it found to be associated with the DHCP client MAC address as having been the most recent user. The DHCP server
with the MAC address in multiple Requested IP address options places the IP address most recently accessed by a DHCP client
(option 50) [RFC 2132]. A server which implements the with this MAC address (unless specifically configured otherwise,
DHCPLEASEQUERY message SHOULD implement this capability. see Section 6.4) in the "ciaddr" field, and returns other infor-
mation associated with that IP address. If requested, the DHCP
server SHOULD return information on all of the IP addresses it
found to be associated with the DHCP client with the MAC address
in a single Requested IP address option (option 50) [RFC 2132]
with multiple IP addresses in it. A server which implements the
DHCPLEASEQUERY message SHOULD implement this capability. If it
does not, it MUST respond with a DHCPUNIMPLEMENTED message when
it receives a query by MAC address.
o Query by client-id option: The DHCP server replies to the DHCPLEASEQUERY message with a
DHCPKNOWN or DHCPACTIVE message if the MAC address corresponds
to a DHCP client which was the most recent user of an IP address
controlled by this DHCP server. The server replies with a
DHCPUNKNOWN message if the MAC address does not correspond to
such an IP address.
This query is similar to the query by MAC address, except that a o Query by Client-identifier option:
client-id option is present in the DHCPLEASEQUERY packet. In
this case, information on the IP address most recently accessed For this query, the "ciaddr" field MUST be zero, there MUST be a
by a client with the included client-id will be returned in the Client-identifier option (option 61) in the packet and there
DHCPACK. If no MAC address is given in the DHCPLEASEQUERY MUST NOT be a MAC address in the packet (i.e., the hlen, htype,
request, then all IP addresses which have been accessed by any and chaddr MUST all be zero). The DHCP server looks up all IP
client with the included client-id SHOULD be returned in multi- addresses for which a client with this Client-identifier is the
ple Requested IP address options (option 50) [RFC 2132]. If a most recent user. In contrast to the query by IP address, there
MAC address is present in the DHCP packet, then the client-id may be multiple IP addresses which show the client specified by
and the MAC address both must match the client information for this Client-identifier as having been the most recent user. The
an IP address for information about that IP address to be DHCP server places the IP address most recently accessed by a
returned either in the "ciaddr" or in one of the Requested IP DHCP client with this Client-identifier (unless specifically
address options. configured otherwise, see Section 6.4) in the "ciaddr" field,
and returns other information associated with that IP address.
If requested, the DHCP server SHOULD return information on all
of the IP addresses it found to be associated with the DHCP
client with the Client-identifier in a single Requested IP
address option (option 50) containing multiple IP addresses. A
server which implements the DHCPLEASEQUERY message SHOULD
implement this capability. If it does not, it MUST respond with
a DHCPUNIMPLEMENTED message when it received a query by Client-
identifier option address.
Generally, the query by IP address is likely to be the most efficient Generally, the query by IP address is likely to be the most efficient
and widely implemented form of leasequery, and it SHOULD be used if and widely implemented form of leasequery, and it SHOULD be used if
at all possible. Use of the other two query formats SHOULD be minim- at all possible. Use of the other two query formats SHOULD be minim-
ized, as they can potentially place a large load on some servers. ized, as they can potentially place a large load on some servers.
The DHCPKNOWN message reply MUST always contain the IP address in the The DHCPKNOWN or DHCPACTIVE message reply MUST always contain the IP
ciaddr field and SHOULD contains the physical address of the IP address in the ciaddr field and SHOULD contains the physical address
address lease owner in the "htype", "hlen", and "chaddr" fields. The of the IP address lease owner in the "htype", "hlen", and "chaddr"
dhcp-parameter-request option can be used to request specific options fields. The Parameter Request List (option 55) can be used to request
to be returned about the IP address in the ciaddr. The reply often specific options to be returned about the IP address in the ciaddr.
contains the time until expiration of the lease, and the original The reply often contains the time until expiration of the lease, and
contents of the Relay Agent Information option [RFC 3046]. The the original contents of the Relay Agent Information option [RFC
access concentrator uses the "chaddr" and Relay Agent Information 3046]. The access concentrator uses the "chaddr" and Relay Agent
option to construct location information, which can be cached on the Information option to construct location information, which can be
access concentrator until lease expiration. cached on the access concentrator until lease expiration.
Any DHCP server which supports the DHCPLEASEQUERY message SHOULD save Any DHCP server which 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
[RFC 3046] associated with every IP address which it serves. A [RFC 3046] associated with every IP address which it serves. A
server which implements DHCPLEASEQUERY SHOULD also save the informa- server which implements DHCPLEASEQUERY SHOULD also save the informa-
tion on the most recent vendor-class-identifier, option 60, associ- tion on the most recent vendor-class-identifier, option 60, associ-
ated with each IP address. ated with each IP address.
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 values for the DHCP packet beyond those defined of the following new and extended values for the DHCP packet beyond
by [RFC 2131]. those defined by [RFC 2131] and [RFC 2132]. See also Section 8, IANA
considerations.
1. The message type option (option 53) from [RFC 2132] requires 1. The message type option (option 53) from [RFC 2132] requires
three new values: The DHCPLEASEQUERY message itself and its five new values: The DHCPLEASEQUERY message itself and its
two responses DHCPKNOWN and DHCPUNKNOWN. The values of these three possible responses DHCPKNOWN, DHCPACTIVE, DHCPUNKNOWN,
message types are shown below in a reproduction of the table and DHCPUNIMPLEMENTED. The values of these message types are
from [RFC 2132]: shown below in a reproduction of the table from [RFC 2132]:
Value Message Type Value Message Type
----- ------------ ----- ------------
1 DHCPDISCOVER 1 DHCPDISCOVER
2 DHCPOFFER 2 DHCPOFFER
3 DHCPREQUEST 3 DHCPREQUEST
4 DHCPDECLINE 4 DHCPDECLINE
5 DHCPACK 5 DHCPACK
6 DHCPNAK 6 DHCPNAK
7 DHCPRELEASE 7 DHCPRELEASE
8 DHCPINFORM 8 DHCPINFORM
TBD DHCPLEASEQUERY TBD DHCPLEASEQUERY
TBD DHCPKNOWN TBD DHCPKNOWN
TBD DHCPUNKNOWN TBD DHCPUNKNOWN
TBD DHCPACTIVE
TBD DHCPUNIMPLEMENTED
2. There is a new bit defined in the flags field of the DHCP 2. There is a new bit defined in the "flags" field of the DHCP
packet (see Section 1, Figure 1 and Table 1 of [RFC 2131]). It packet (see Section 1, Figure 1 and Table 1 of [RFC 2131]). It
is called the R: RESERVATION flag. The revised Figure 2 from is called the R: RESERVATION flag. The revised Figure 2 from
[RFC 2131] is show here: [RFC 2131] is show here:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| tbd MBZ | |B| tbd MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag B: BROADCAST flag
R: RESERVATION FLAG R: RESERVATION FLAG
MBZ: MUST BE ZERO (reserved for future use) MBZ: MUST BE ZERO (reserved for future use)
Revised Figure 2 from RFC2131: Revised Figure 2 from RFC2131:
Format of the 'flags' field Format of the 'flags' field
3. There is one new option defined which can be used to return 3. There is one new option defined which can be used to return
important information in a DHCPKNOWN response to a DHCPLEASE- important information in a DHCPKNOWN response to a DHCPLEASE-
QUERY message -- the client-last-transaction-time. See Section QUERY message -- the client-last-transaction-time.
6.8 for details.
The client-last-transaction-time is necessary in order to allow client-last-transaction-time
an entity that receives multiple DHCPKNOWN messages from dif- This option allows the receiver to determine the time of the
ferent DHCP servers to compare the results and extract the most most recent access of the client. It is particularly useful
recently used IP address from among the multiple replies. when DHCPKNOWN messages from two different DHCP servers need to
be compared, although it can be useful in other situations.
The value is a duration in seconds from the current time into
the past when this IP address was most recently the subject of
communication between the client and the DHCP server.
This MUST NOT be an absolute time. This MUST NOT be an abso-
lute number of seconds since Jan 1, 1970. Instead, this MUST
be an integer number of seconds in the past from the time the
DHCPKNOWN message is sent that the client last dealt with this
server about this IP address. In the same way that the IP
Address Lease Time option (option 51) encodes a lease time
which is a number of seconds into the future from the time the
message was sent, this option encodes a value which is a 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
option is 4 octets.
Code Len Seconds in the past
+-----+-----+-----+-----+-----+-----+
| TBD | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
4. The Requested IP Address option is extended to allow for multi-
ple IP addresses in the option.
This option is used to return all of the IP addresses associ-
ated with the DHCP client specified in a particular DHCPLEASE-
QUERY message.
The code for this option is 50, and its minimum length is 4 and
its maximum length MUST be a multiple of 4.
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 50 | 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 concentra- The DHCPLEASEQUERY message is typically sent by an access concentra-
tor. The DHCPLEASEQUERY message uses the DHCP message format as tor. The DHCPLEASEQUERY message uses the DHCP message format as
described in [RFC 2131], and uses message number TBD in the DHCP Mes- described in [RFC 2131], and uses message number TBD in the DHCP Mes-
sage Type option (option 53). The DHCPLEASEQUERY message has the sage Type option (option 53). The DHCPLEASEQUERY message has the
following pertinent message contents: following pertinent message contents:
o The giaddr MUST be set to the IP address of the requestor (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 to be searched -- it is simply the return address of for "ciaddr" field to be searched -- it is simply the return address
the DHCPKNOWN or DHCPUNKNOWN message from the DHCP server. of for the DHCPKNOWN or DHCPUNKNOWN message from the DHCP
server.
o The Parameter Request List SHOULD be set to the options of o The Parameter Request List SHOULD be set to the options of
interest to the requestor. The interesting options are likely interest to the requester. The interesting options are likely
to include the IP Address Lease Time option (option 51) and the to include the IP Address Lease Time option (option 51) and the
Relay Agent Information option (82). Relay Agent Information option (option 82).
o The Reservation bit in the "flags" field of the DHCP packet (see o The Reservation bit in the "flags" field of the DHCP packet (see
[RFC 2131] and Section 6.1 of this document) is used to specify [RFC 2131] and Section 6.1 of this document) is not used when
if the response should include information encoded into reserva- sending a DHCPLEASEQUERY message.
tions.
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 0.
The ciaddr MUST be set to the IP address of the lease to be The "ciaddr" field MUST be set to the IP address of the lease to
queried. be queried.
The client-id option (option 61) MUST NOT appear in the packet. The Client-identifier option (option 61) MUST NOT appear in the
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
of the MAC address to search for. of the MAC address to search for.
The ciaddr MUST be set to zero. The "ciaddr" field MUST be set to zero.
The client-id option (option 61) MUST NOT appear in the packet. The Client-identifier option (option 61) MUST NOT appear in the
packet.
o Query by client-id option: o Query by Client-identifier option:
There MUST be a client-id option (option 61) in the DHCPLEASE- There MUST be a Client-identifier option (option 61) in the
QUERY message. DHCPLEASEQUERY message.
The ciaddr MUST be set to zero. The "ciaddr" field MUST be set to zero.
The values of htype, hlen, and chaddr MAY be set to the value of The values of htype, hlen, and chaddr MUST be set to 0.
the MAC address to search for. In this case, the search MUST
match both the values in the client-id option and the MAC
address specified in the "htype", "hlen", or "chaddr".
The access concentrator SHOULD ensure that the ciaddr mentioned in The access concentrator SHOULD ensure that the "ciaddr" field men-
the DHCPLEASEQUERY message (if a query by IP address) is a local sub- tioned in the DHCPLEASEQUERY message (if a query by IP address) is a
net of the interface specified for the client. local subnet of the interface specified for the client.
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).
6.3. Receiving the DHCPLEASEQUERY Message 6.3. Receiving the DHCPLEASEQUERY Message
A DHCPLEASEQUERY message MUST have a non-zero giaddr. The DHCPLEASE- A DHCPLEASEQUERY message MUST have a non-zero giaddr. The DHCPLEASE-
QUERY message MUST have at least one of: a non-zero ciaddr, a non- QUERY message MUST have exactly one of: a non-zero ciaddr, a non-
zero "htype"/"hlen"/"chaddr", or a client-id. It MAY have more than zero "htype"/"hlen"/"chaddr", or a Client-identifier.
one.
The DHCP server which receives a DHCPLEASEQUERY message MUST base its The DHCP server which receives a DHCPLEASEQUERY message MUST base its
response (if any) on the IP address represented by the ciaddr in the response on the particular data item used in the query.
DHCPLEASEQUERY message if one is given.
If an IP address is not given, then the receiving DHCP server MUST
base its response on the client-id and any MAC address contained in
the "htype", "hlen", and "chaddr" fields of the DHCP packet.
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. response to the DHCPLEASEQUERY message.
6.4. Responding to the DHCPLEASEQUERY Message 6.4. Responding to the DHCPLEASEQUERY Message
The DHCP server MUST respond to a DHCPLEASEQUERY message with a There are four possible responses to a DHCPLEASEQUERY message:
DHCPKNOWN message if the ciaddr corresponds to an IP address which is
managed by the DHCP server or if there is an IP address which has
most recently been acccess by any DHCP client described by any
client-id option and/or MAC address information in the "htype",
"hlen", and "chaddr" fields of the DHCPLEASEQUERY request.
In the event that an IP address appears in the "ciaddr" field, then o DHCPKNOWN
the information returned should be about that IP address regardless
of the values of the MAC address and/or client-id option.
If the Reservation bit is not set in the "flags" field of the DHCP The DHCPKNOWN message indicates that the server knows about the
packet (see [RFC 2131]), then the DHCP server SHOULD NOT respond to a IP address or client specified in the DHCPLEASEQUERY message,
DHCPLEASEQUERY message with a DHCPKNOWN if the "ciaddr" corresponds but there is no currently active lease for the IP address
to an IP address about which the DHCP server has definitive informa- returned in the "ciaddr" field of the DHCPKNOWN message. The R
tion but which has no DHCP client information associated with it. As (reservation) bit MAY be set in the case where there is a reser-
well, if the "ciaddr" does not contain an IP address and there is a vation for this IP address by the client returned in the
MAC address or client-id in the DHCPLEASEQUERY request, if the Reser- DHCPKNOWN message, allowing the access concentrator to consider
vation bit is not set then the DHCP server SHOULD NOT respond with a a reservation equivalent to a currently active lease on the IP
DHCPKNOWN unless the client specified in the DHCPLEASEQUERY has address.
accessed an IP address.
Conversely, if the Reservation bit is set in the "flags" field of the The server MUST respond with a DHCPKNOWN message if this server
DHCP packet, then the DHCP server SHOULD respond with information has information about the IP address or client in question, but
contained in the reservation associated with either the IP address that there is no active lease for the IP address or client
specified in the "ciaddr" or the client specified in the MAC adddress specified in the query. If the query was by IP address, then
and/or client-id if there is no actual usage information concerning the DHCPKNOWN message indicates that this server manages this IP
the association of the IP address or specified client. address. If there is a reservation for this IP address, then
the DHCP server MUST set the R (reservation) bit in the "flags"
field of the DHCP packet, and the DHCP server MUST return what-
ever client information is known in the DHCPKNOWN message.
If the DHCP server uses reservation information to fill in the infor- In the case where a client was specified either by Client-
mation of a DHCPKNOWN message (other than using it to include an IP identifier or MAC address, then the DHCPKNOWN message indicates
address in a Requested IP option), the DHCP server MUST set the that the client is known to the DHCP server, and was the most
Reservation bit in the "flags" field of the DHCPKNOWN message. recent client associated with a particular IP address. In the
case where the client specified has a reservation for the IP
address returned in the ciaddr, the R (reservation) bit is set
in the "flags" field of the DHCP packet.
Thus, a DHCP server SHOULD, but doesn't have to implement reservation o DHCPUNKNOWN
support if it implements support for the DHCPLEASEQUERY message, but
if it does, it MUST set the Reservation bit in the "flags" field
whenever the primary information it returns in the DHCPKNOWN message
is based on a reservation.
The DHCP server MUST respond to the DHCPLEASEQUERY with a DHCPUNKNOWN The DHCPKNOWN message indicates that the server knows nothing
if the DHCP server supports the DHCPLEASEQUERY message but does not about the IP address or client specified in the DHCPLEASEQUERY
have definitive information concerning the IP address in the ciaddr message.
(if any) or if it does not have definitive information concerning the
DHCP client specified in the "htype", "hlen", and "chaddr" fields or
the client-id option. When responding with a DHCPUNKNOWN, the DHCP
server SHOULD NOT include other DHCP options in the response.
A DHCP server which does not support the DHCPLEASEQUERY message MUST The server MUST response with a DHCPKNOWN message when this
NOT respond to the DHCPLEASEQUERY message. server has no information about the IP address or client speci-
fied in the DHCPLEASEQUERY message.
When responding to a DHCPLEASEQUERY message with a DHCPKNOWN: When responding with a DHCPUNKNOWN, the DHCP server SHOULD NOT
include other DHCP options in the response. The R (reservation)
bit MUST NOT be set in the "flags" field of the DHCP packet.
o In the case where more than one IP has been accessed by the o DHCPACTIVE
client specified by the MAC address and/or client-id option,
then the IP address most recently the involved in a DHCP client
message by that client SHOULD be used as the IP address to place
into the "ciaddr". The DHCP server SHOULD be configurable to
return other than the IP address with the most recent client-
last-transaction-time, for instance the IP address with the
longest lease time.
In this case, all of the IP addresses which are recorded as hav- The DHCPACTIVE message indicates that the server not only knows
ing been accessed by this client should be returned in Requested about the IP address and client specified in the DHCPACTIVE mes-
IP address options (option 50) if that option is included in the sage but also that there is an active lease by that client for
dhcp-parameter-request-list option in the request. They should that IP address.
appear in order of increasing age of access in that option.
o If the IP Address Lease Time option (option 51) is specified in In some cases, the DHCP server MAY be configured to return a
the Parameter Request List and if there is a currently valid DHCPACTIVE message when there is no active lease but when there
lease for the IP address specified in the ciaddr, then the DHCP is a reservation by the specified client for the IP address in
server MUST return this option in the DHCPKNOWN with its value the "ciaddr" field of the DHCPACTIVE message. A server would be
equal to the time remaining until lease expiration. If there is so configured when it was desired that the access concentrator
no valid lease for the IP address, then the server MUST NOT would allow access to IP addresses which are not DHCP clients.
return the IP Address Lease Time option (option 51). This In this case the DHCP server SHOULD NOT place an IP Address
allows the requestor (i.e. the access concentrator) to deter- Lease Time (option 51) in the DHCPACTIVE message, allowing the
mine if there is currently a valid lease for the IP address as access concentrator to determine that this is a DHCPACTIVE mes-
well as the time until the lease expiration. sage for an IP address without a currently active lease.
A request for the Renewal (T1) Time Value option or the Rebind- The server MUST respond with a DHCPACTIVE message when the IP
ing (T2) Time Value option in the Parameter Request List of the address returned in the "ciaddr" field is currently leased. If
DHCPLEASEQUERY message MUST be handled like the IP Address Lease the client returned in the DHCPACTIVE message has a reservation
Time option is handled. If there is a valid lease, then the for that IP address recorded in the DHCP server, then the R
DHCP server SHOULD return these options (when requested) with (reservation) bit MUST be set in the "flags" field of the DHCP
the remaining time until renewal or rebinding, respectively. If packet.
there is not currently a valid lease for this IP address, the
DHCP server MUST NOT return these options.
o If the DHCP server has information about the most recent device o DHCPUNIMPLEMENTED
associated with the IP address specified in the ciaddr, then the
DHCP server MUST encode the physical address of that device in
the htype, hlen, and chaddr fields. Otherwise, the values of
htype, hlen, and chaddr MUST be set to 0 in the DHCPKNOWN. If
the IP Address Lease Time (option 51) is returned in the
DHCPKNOWN (indicating a currently valid lease by some device for
this IP address), the DHCP server MUST encode the physical
address of the device which owns the lease in the htype, hlen,
and chaddr fields.
o If the Relay Agent Information (option 82) is specified in the The DHCPUNIMPLEMENTED message indicates that the particular form
Parameter Request List and if the DHCP server has saved the of DHCPLEASEQUERY used is not implemented in this DHCP server.
information contained in the most recent Relay Agent Information It may mean that the DHCPLEASEQUERY message as a whole is not
option, the DHCP server MUST include that information in a Relay implemented by this DHCP server although it is usually used to
Agent Information option in the DHCPKNOWN. indicate that a query by Client-identifier or MAC address is not
implemented by a DHCP server that otherwise supports a
DHCPLEASEQUERY by IP address.
In environments with non-DHCP-enabled devices, when the DHCP Since the response to a DHCPLEASEQUERY request can only contain full
server knows the network access information (perhaps through information about one IP address -- the one that appears in the
server configuration), the DHCP server MAY generate its own "ciaddr" field -- determination of which IP address to which to
Relay Agent Information option value in the DHCPKNOWN; in such respond is a key issue. (Of course, the values of additional IP
cases, the DHCP server MUST generate an option value that the addresses for which a client has a lease may also be returned in mul-
access concentrator can process. tiple Requested IP address options (option 50). This is the only
information returned not directly associated with the IP address in
the "ciaddr" field.)
o The DHCPKNOWN message SHOULD include the values of all other 6.4.1. Determining the IP address to which to respond
options not specifically discussed above that were requested in
the Parameter Request List of the DHCPLEASEQUERY message.
The DHCP server uses information from the lease binding database to In the event that an IP address appears in the "ciaddr" field of a
supply the DHCPKNOWN option values. 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
DHCPKNOWN message.
If the IP address is not managed by the DHCP server, then a DHCPUN-
KNOWN message must be returned.
If the "ciaddr" field of the DHCPLEASEQUERY is zero, then the
DHCPLEASEQUERY message is a query by Client-identifier or MAC
address. In this case, the client's identity is any client which has
proffered an identical Client-identifier option (if the Client-
identifier option appears in the DHCPLEASEQUERY message), or an
identical MAC address (if the MAC address fields in the DHCPLEASE-
QUERY message are non-zero). This client matching approach will, for
the purposes of this section, be described as "Client-identifier or
MAC address".
The Reservations bit (the R bit) has no meaning in the DHCPLEASEQUERY
message and is used only to indicate the existence of a reservation
in a DHCPKNOWN or DHCPACTIVE message.
If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the
IP address placed in the "ciaddr" field of the DHCPKNOWN or DHCPAC-
TIVE message 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 specified in the DHCPLEASEQUERY message.
If there is only a single IP address which fulfills this criteria,
then it MUST be placed in the "ciaddr" field of the DHCPKNOWN or
DHCPACTIVE message.
In the case where more than one IP has been accessed by the 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
most recent transaction with the client unless the DHCP server has
been configured by the server administrator to use some other prefer-
ence mechanism.
If, after all of the above processing, no value is set in the
"ciaddr" field of the DHCPKNOWN or DHCPACTIVE message, then a DHCPUN-
KNOWN message MUST be returned instead.
6.4.2. Building a DHCPKNOWN or DHCPACTIVE message once the "ciaddr"
field is set
Once the "ciaddr" field of the DHCPKNOWN or DHCPACTIVE message is
set, the rest of the processing largely involves returning informa-
tion about the IP address specified in the "ciaddr" field.
If the IP address in the "ciaddr" field of the DHCPKNOWN or DHCPAC-
TIVE message is currently leased by the client specified in the
Client-identifier or MAC address returned in the DHCPKNOWN or DHCPAC-
TIVE message, then the message MUST be a DHCPACTIVE message, other-
wise it MUST be a DHCPKNOWN message.
It MAY be possible to configure a DHCP server to return a DHCPACTIVE
message even though the IP address specified in the "ciaddr" field is
not currently leased if there is a reservation for that IP address by
the client specified in the Client-identifier or MAC address fields
of the DHCPACTIVE message. In this case, there MUST NOT be an IP
Address Lease Time option (option 51) in the packet.
The R (reservation) bit must be set in the "flags" field if the IP
address in the "ciaddr" field is reserved for the client returned in
the MAC address or Client-identifier option.
The IP address in the "ciaddr" field of the DHCPKNOWN or DHCPACTIVE
message MUST be one for which this server is responsible (or a
DHCPUNKNOWN message would be have already been returned early in the
processing described in the previous section).
The MAC address of the DHCPKNOWN or DHCPACTIVE message MUST be set
from the client associated with the IP address in the "ciaddr" field
of the DHCPKNOWN message. This may be derived from a real DHCP
client or from reservation information configured into the DHCP
server.
If the Client-identifier option (option 61) is specified in the
Parameter Request List option (option 55), then the Client-identifier
(if any) of the client associated with the IP address in the "ciaddr"
field SHOULD be returned in the DHCPKNOWN or DHCPACTIVE message. This
may be derived from a real DHPC client, or from reservation informa-
tion configured into the DHCP server.
In the case where more than one IP has been accessed by the client
specified by the MAC address and/or Client-identifier option, then
the list of all of the IP addresses SHOULD be returned as multiple
Requested IP address options (option 50), if that option was
requested as part of the Parameter Request List option.
If the IP Address Lease Time option (option 51) is specified in the
Parameter Request List and if there is a currently valid lease for
the IP address specified in the ciaddr, then the DHCP server MUST
return this option in the DHCPKNOWN with its value equal to the time
remaining until lease expiration. If there is no valid lease for the
IP address, then the server MUST NOT return the IP Address Lease Time
option (option 51). This allows the requester (i.e. the access con-
centrator) to determine if there is currently a valid lease for the
IP address as well as the time until the lease expiration.
If there is no currently valid lease on the IP address in the
"ciaddr" field, and if the R bit is set in the DHCPLEASEQUERY and in
the DHCPKNOWN messages (i.e., if the sender of the DHCPLEASEQUERY
message requested reservation information, and the "ciaddr" in the
DHCPKNOWN message was derived from reservation information), then the
DHCP server MAY synthesize an IP Address Lease Time option for the
DHCPKNOWN message if configured to do so. Typically the value of
this option would itself be a configuration parameter of the DHCP
server.
A request for the Renewal (T1) Time Value option or the Rebinding
(T2) Time Value option in the Parameter Request List of the
DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time
option is handled. If there is a valid lease, then the DHCP server
SHOULD return these options (when requested) with the remaining time
until renewal or rebinding, respectively. If there is not currently
a valid lease for this IP address, the DHCP server MUST NOT return
these options.
If the Relay Agent Information (option 82) is specified in the Param-
eter Request List and if the DHCP server has saved the information
contained in the most recent Relay Agent Information option, the DHCP
server MUST include that information in a Relay Agent Information
option in the DHCPKNOWN.
The DHCPKNOWN or DHCPACTIVE message SHOULD include the values of all
other options not specifically discussed above that were requested in
the Parameter Request List of the DHCPLEASEQUERY message. The DHCP
server uses information from the lease binding database to supply the
DHCPKNOWN or DHCPACTIVE option values. The values of the options
that were returned to the DHCP client would generally be preferred,
but in the absence of those, options that were sent in DHCP client
requests would be acceptable.
In order to accommodate DHCPLEASEQUERY messages sent to a DHCP Fail- In order to accommodate DHCPLEASEQUERY messages sent to a DHCP Fail-
over secondary server [FAILOVER] when the primary server is down, the over secondary server [FAILOVER] when the primary server is down, the
primary server MUST communicate the Relay Agent Information option primary server MUST communicate the Relay Agent Information option
(82) values to the secondary server via the DHCP Failover BNDUPD mes- (option 82) values to the secondary server via the DHCP Failover
sages. BNDUPD messages.
6.4.3. Sending a DHCPKNOWN, DHCPACTIVE, or DHCPUNKNOWN message
The server expects a giaddr in the DHCPLEASEQUERY message, and uni- The server expects a giaddr in the DHCPLEASEQUERY message, and uni-
casts the DHCPKNOWN or DHCPUNKNOWN to the giaddr. If the giaddr casts the DHCPKNOWN, DHCPACTIVE or DHCPUNKNOWN message to the giaddr.
field is zero, then the DHCP server does not reply to the DHCPLEASE- If the giaddr field is zero, then the DHCP server MUST NOT reply to
QUERY message. the DHCPLEASEQUERY message.
6.5. Receiving a DHCPKNOWN or DHCPUNKNOWN response to the DHCPLEASE- 6.5. Receiving a DHCPKNOWN, DHCPACTIVE, or DHCPUNKNOWN Message
QUERY Message
When a DHCPKNOWN message is received in response to the DHCPLEASE- When a DHCPACTIVE message is received in response to the DHCPLEASE-
QUERY message and the DHCPKNOWN has an IP Address Lease Time option QUERY message it means that there is a currently active lease for
value that is non-zero, it means that there is a currently active this IP address in this DHCP server. The access concentrator SHOULD
lease for this IP address in this DHCP server. The access concentra- use the information in the htype, hlen, and chaddr fields of the
tor SHOULD use the information in the htype, hlen, and chaddr fields DHCPACTIVE as well as any Relay Agent Information option information
of the DHCPKNOWN as well as any Relay Agent Information option infor- included in the packet to refresh its location information for this
mation included in the packet to refresh its location information for IP address.
this IP address.
When a DHCPKNOWN message is received in response to the DHCPLEASE- When a DHCPKNOWN message is received in response to the DHCPLEASE-
QUERY message and the DHCPKNOWN has no IP Address Lease Time option QUERY message that means that there is no currently active lease for
(though one was requested in the Parameter Request List), that means the IP address present in the DHCP server. In this case, the access
that there is no currently active lease for the IP address present in concentrator SHOULD cache this information in order to prevent unac-
the DHCP server. In this case, the access concentrator SHOULD cache ceptable loads on the access concentrator and the DHCP server in the
this information in order to prevent unacceptable loads on the access face of a malicious or seriously compromised device downstream of the
concentrator and the DHCP server in the face of a malicious or access concentrator.
seriously compromised device downstream of the access concentrator.
In either case, when a DHCPKNOWN message is received in response to a If the R (reservation) bit is set in the "flags" field of the
DHCPLEASEQUERY message, it means that the DHCP server which responded DHCPKNOWN message, it means that a reservation exists in the DHCP
is a DHCP server which manages the IP address present in the ciaddr, server for the IP address and associated client. The access concen-
and the Relay Agent SHOULD cache this information for later use. trator MAY be configured to allow the client access even though no
currently outstanding lease is in place for this
In either case, when a DHCPKNOWN or DHCPACTIVE message is received in
response to a DHCPLEASEQUERY message, it means that the DHCP server
which responded is a DHCP server which manages the IP address present
in the ciaddr, and the Relay Agent SHOULD cache this information for
later use.
When a DHCPUNKNOWN message is received by an access concentrator When a DHCPUNKNOWN message is received by an access concentrator
which has sent out a DHCPLEASEQUERY message, it means that the DHCP which 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 not have definitive information concerning the IP address DHCP server not have definitive information concerning the IP address
contained in the ciaddr of the DHCPLEASEQUERY message. If there is contained in the "ciaddr" field of the DHCPLEASEQUERY message. If
no IP address in the ciaddr of the DHCPLEASEQUERY message, then a there is no IP address in the "ciaddr" field of the DHCPLEASEQUERY
DHCPUNKNOWN message means that the DHCP server does not have defini- message, then a DHCPUNKNOWN message means that the DHCP server does
tive information concering the any DHCP client specified in the not have definitive information concerning the any DHCP client speci-
"hlen", "htype", and "chaddr" fields or the client-id option of the fied in the "hlen", "htype", and "chaddr" fields or the Client-
DHCPLEASEQUERY message. identifier option of the DHCPLEASEQUERY message.
The access concentrator SHOULD cache this information, and only The access concentrator SHOULD cache this information, and 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 with a responded to a DHCPLEASEQUERY message for a particular "ciaddr" field
DHCPUNKNOWN. with a DHCPUNKNOWN.
6.6. Receiving the no response to the DHCPLEASEQUERY Message When a DHCPUNIMPLEMENTED message is received by an access concentra-
tor, it means that the particular aspect of DHCPLEASEQUERY processing
requested is not implemented in the responding server. It may or may
not be the case that other aspects of DHCPLEASEQUERY processing are
not implemented in that server.
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 DHCPKNOWN or DHCPUNKNOWN o The DHCPLEASEQUERY or a corresponding DHCPKNOWN, DHCPACTIVE or
were lost during transmission or the DHCPLEASEQUERY arrived at DHCPUNKNOWN were lost during transmission or the DHCPLEASEQUERY
the DHCP server but it was dropped because the server was too arrived at the DHCP server but it was dropped because the server
busy. 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 DHCPLEASE- In the first of the cases above, a retransmission of the DHCPLEASE-
QUERY would be appropriate, but in the second of the two cases, a QUERY would be appropriate, but in the second of the two cases, a
retransmission would not be appropriate. There is no way to tell retransmission would not be appropriate. There is no way to tell
these two cases apart (other than, perhaps, because of a DHCP 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
supports the DHCPLEASEQUERY message). supports the DHCPLEASEQUERY message).
An access concentrator which utilizes the DHCPLEASEQUERY message An access concentrator which utilizes the DHCPLEASEQUERY message
SHOULD attempt to resend DHCPLEASEQUERY messages to servers which do SHOULD attempt to resend DHCPLEASEQUERY messages to servers which 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 which is not otherwise known to support the
DHCPLEASEQUERY message at a rate of not 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 send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per
minute. minute.
6.7. Utilizing the DHCPLEASEQUERY message in a failover environment In practice this approach would probably best be handled by a per-
server timer that backs off exponentially to once a minute, and a
per-message backoff timer that also backs off to once a minute. The
per-server timer would start off expired, and in the expired state
only one DHCPLEASEQUERY message would be queued for the associated
server. This DHCPLEASEQUERY message would be sent with the backoff
quickly moving to once a minute until a DHCPACTIVE, DHCPKNOWN, or
DHCPUNKNOWN message reply was received. Whenever one of these mes-
sages is received, the per-server timer is reset, and whenever the
per-server timer has not expired, more than one individual DHCPLEASE-
QUERY messages can be outstanding to the DHCP server at one time. It
is recommended that this number be limited to a relatively small
number, for example, 100 or 200, to avoid swamping the DHCP server.
Each of these messages should have its own per-message retry timer.
This would retransmit each message and backoff as discussed above. In
the event the per-server timer goes off, then all outstanding mes-
sages SHOULD be dropped except for a single DHCPLEASEQUERY message
which is used to poll the server until such time as another DHCPAC-
TIVE, DHCPKNOWN, or DHCPUNKNOWN message is received.
When utilizing the DHCPLEASEQUERY message in an environment where multi- 6.7. Using the DHCPLEASEQUERY message in a failover environment
ple DHCP server may contain authoritative information about the same IP
address (such as when failover [FAILOVER] is operating), there could be When using the DHCPLEASEQUERY message in an environment where multi-
some difficulty in deciding which results are the most useful if two ple DHCP server may contain authoritative information about the same
servers respond with DHCPKNOWN messages to the same query. IP address (such as when failover [FAILOVER] is operating), there
could be some difficulty in deciding which results are the most use-
ful if two servers respond with DHCPKNOWN messages to the same query.
In this case, the client-last-transaction-time can be used to decide In this case, the client-last-transaction-time can be used to decide
which server has more recent information concerning the IP address which server has more recent information concerning the IP address
returned in the "ciaddr" field. returned in the "ciaddr" field.
6.8. New option defined for responding to DHCPLEASEQUERY messages.
There is one new option defined for responding to DHCPLEASEQUERY mes-
sages: client-last-transaction time.
6.8.1. client-last-transaction-time
This option SHOULD record the time of the most recent access of the
client. It is particularly useful when DHCPLEASEQUERY responses from
two different DHCP servers need to be compared, although it can be
useful in other situations. The value is a duration in seconds in
the past from when this IP address was most recently the subject of
communication between the client and the DHCP server.
The code for the this option is TBD. The length of the this option is
4 octets.
Code Len Seconds in the past
+-----+-----+-----+-----+-----+-----+
| TBD | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
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 which 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 suscep- depend on ARP broadcasts across the access network, which is suscep-
tible to malicious hosts which masquerade as the intended IP end- tible to malicious hosts which masquerade as the intended IP end-
points. Thus, the DHCPLEASEQUERY message allows an access concentra- points. Thus, the DHCPLEASEQUERY message allows an access concentra-
tor to provide considerably enhanced security. tor to provide considerably enhanced security.
DHCP servers SHOULD prevent exposure of location information (partic- DHCP servers SHOULD prevent exposure of location information (partic-
ularly the mapping of hardware address to IP address lease, which can ularly the mapping of hardware address to IP address lease, which can
be an invasion of broadband subscriber privacy) by leveraging DHCP be an invasion of broadband subscriber privacy) by leveraging DHCP
authentication [DHCPAUTH]. With respect to authentication, the authentication [RFC 3118]. With respect to authentication, the
access concentrator acts as the "client". The use of "Authentication access concentrator acts as the "client". The use of "Authentication
Protocol 0" (using simple unencoded authentication token(s) between Protocol 0" (using simple unencoded authentication token(s) between
the access concentrator and the DHCP server) is straightforward. The the access concentrator and the DHCP server) is straightforward.
use of "Authentication Protocol 1" (using "delayed authentication") Alternatively, use of IPsec would also be a way to ensure security
is under investigation, since it requires two message round trips. between the relay agent and the DHCP server.
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 both DHCPKNOWN and should employ negative cacheing (i.e. cache both DHCPKNOWN and
DHCPUNKNOWN responses to DHCPLEASEQUERY messages) and ciaddr restric- DHCPUNKNOWN responses to DHCPLEASEQUERY messages) and ciaddr restric-
tion (i.e. don't send a DHCPLEASEQUERY message with a ciaddr outside tion (i.e. don't send a DHCPLEASEQUERY message with a ciaddr outside
of the range of the attached broadband access networks). Together, of the range of the attached broadband access networks). Together,
these mechanisms limit the access concentrator to transmitting one these mechanisms limit the access concentrator to transmitting one
DHCPLEASEQUERY message (excluding message retries) per legitimate DHCPLEASEQUERY message (excluding message retries) per legitimate
broadband access network IP address after a reboot event. broadband access network IP address after a reboot event.
8. Acknowledgments 8. IANA Considerations
IANA has assigned seven values for this document. See Section 6.1
for details. There are five new messages types, which are the value
of the message type option (option 53) from [RFC 2132]. The value
for DHCPLEASEQUERY is TBD, the value for DHCPKNOWN is TBD, the value
for DHCPACTIVE is TBD, the value for DHCPUNKNOWN is TBD and the value
for DHCPUNIMPLEMENTED is TBD. There is a new bit defined for the
"flags" field of the DHCP packet (see Section 1, Figure 1 and Table 1
of [RFC 2131]). The flag is called "R: RESERVATION flag", and its
value is TBD. Finally, there is one new DHCP option defined, which
is the client-last-transaction-time option, and its option code is
TBD.
9. Acknowledgments
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. addressing.
9. References 10. References
[RFC 826] Plummer, D., "Ethernet Address Resolution Protocol: Or con- [RFC 826] Plummer, D., "Ethernet Address Resolution Protocol: Or con-
verting network protocol addresses to 48.bit Ethernet address for verting network protocol addresses to 48.bit Ethernet address for
transmission on Ethernet hardware", RFC 826, November 1982. transmission on Ethernet hardware", RFC 826, November 1982.
[RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC [RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC
951, September 1985. 951, September 1985.
[RFC 1542] Wimer, W., "Clarifications and Extensions for the [RFC 1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993. Bootstrap Protocol", RFC 1542, October 1993.
skipping to change at page 19, line 20 skipping to change at page 23, line 40
[RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
[RFC 3118] Droms, R., Arbaugh, W., "Authentication for DHCP Mes-
sages", RFC 3118, June 2001.
[BPI] CableLabs, "Baseline Privacy Interface Specification", SP-BPI- [BPI] CableLabs, "Baseline Privacy Interface Specification", SP-BPI-
I02-990319, March 1999, available at http://www.cablemodem.com/. I02-990319, March 1999, available at http://www.cablemodem.com/.
[BPI+] CableLabs, "Baseline Privacy Plus Interface Specification", [BPI+] CableLabs, "Baseline Privacy Plus Interface Specification",
SP-BPI+-I04-000407, April 2000, available at SP-BPI+-I04-000407, April 2000, available at
http://www.cablemodem.com/. http://www.cablemodem.com/.
[DHCPAUTH] Droms, R., Arbaugh, W., "Authentication for DHCP Mes-
sages", draft-ietf-dhc-authentication-14.txt, July 2000.
[DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol [DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol
(DHCP) Server MIB", draft-ietf-dhc-server-mib-05.txt, November (DHCP) Server MIB", draft-ietf-dhc-server-mib-06.txt, February
2000. 2002.
[DHCPSCHEMA] Bennett, A., Volz, B., "DHCP Schema for LDAP", draft-
ietf-dhc-schema-02.txt, March 2000.
[DOCSIS] CableLabs, "Data-Over-Cable Service Interface Specifica- [DOCSIS] CableLabs, "Data-Over-Cable Service Interface Specifica-
tions: Cable Modem Radio Frequency Interface Specification SP- tions: Cable Modem Radio Frequency Interface Specification SP-
RFI-I05-991105", November 1999. RFI-I05-991105", November 1999.
[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 networks",
Version 1.0, May 1999. Version 1.0, May 1999.
[FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., [FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S.,
Rabil, G., Dooley, M., Kapur, A., "DHCP Failover Protocol", Rabil, G., Dooley, M., Kapur, A., "DHCP Failover Protocol",
draft-ietf-dhc-failover-09.txt, July 2001. draft-ietf-dhc-failover-10.txt, January 2002.
10. Author's information 11. Author's information
Rich Woundy Rich Woundy
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 244-8000 Phone: (978) 497-8000
EMail: rwoundy@cisco.com EMail: rwoundy@cisco.com
kkinnear@cisco.com kkinnear@cisco.com
11. Full Copyright Statement 12. Intellectual Property Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. The IETF takes no position regarding the validity or scope of any intel-
lectual property 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; neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's procedures with
respect to rights in standards-track and standards-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
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this stan-
dard. Please address the information to the IETF Executive Director.
13. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to oth- This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis- assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations, references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/