draft-ietf-dhc-leasequery-03.txt   draft-ietf-dhc-leasequery-04.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
March 2002 October 2002
Expires September 2002 Expires April 2003
DHCP Lease Query DHCP Lease Query
<draft-ietf-dhc-leasequery-03.txt> <draft-ietf-dhc-leasequery-04.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 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, DHCPACTIVE or DHCPUNKNOWN message. The replies with a DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN
DHCPACTIVE response to a DHCPLEASEQUERY message allows the relay message. The DHCPLEASEACTIVE response to a DHCPLEASEQUERY message
agent to determine the IP endpoint location, and the remaining dura- allows the relay agent to determine the IP endpoint location, and the
tion of the IP address lease. remaining duration of the IP address lease. The DHCPLEASEKNOWN is
similar to a DHCPLEASEACTIVE message but indicates that there is no
currently active lease on the resultant IP address. The DHCPLEASEUN-
KNOWN message indicates that the DHCP server has no knowledge of the
information specified in the query (e.g., IP address, MAC address, or
client-id option).
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 5, line 5 skipping to change at page 5, line 10
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" o "reservation"
At times it is convenient for an administrator to assign a fixed At times it is convenient for an administrator to assign a fixed
IP address to a particular DHCP client. The DHCP server must be IP address to a particular DHCP client. The DHCP server must be
configured with this DHCP client to IP address mapping, typi- configured with this DHCP client to IP address mapping, typi-
cally using the MAC address as the way to identify the client. cally using the MAC address as the way to identify the client. A
The DHCP client to IP address mapping, configured in the DHCP reservation defines a mapping between a client and an IP address
server, is called a reservation for the purposes of this docu- but doesn't establish or record a lease binding for the IP
ment. address. The DHCP client to IP address mapping, configured in
the DHCP server, is called a reservation for the purposes of
this document.
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-
skipping to change at page 5, line 44 skipping to change at page 5, line 51
3. Background 3. Background
The focus of this document is to enable access concentrators to send The focus of this document is to enable access concentrators to send
DHCPLEASEQUERY messages to DHCP servers, to obtain location informa- DHCPLEASEQUERY messages to DHCP servers, to obtain location informa-
tion of broadband access network devices. tion of broadband access network 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 Interac- DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB Interac-
tive Network Adapters (INAs) [EUROMODEM], and DSL Access Concentra- tive Network Adapters (INAs) [EUROMODEM], and DSL Access
tors. Concentrators.
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.
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 [RFC 3046]) in Failover BNDUPD messages to agent-information option [RFC 3046]) in Failover BNDUPD messages to
the secondary DHCP server, as recommended by section 7.1.1 of [FAIL- the secondary DHCP server, as recommended by section 7.1.1 of [FAIL-
OVER]. OVER].
The DHCPLEASEQUERY message is a query message only, and does not The DHCPLEASEQUERY message is a query message only, and does not
skipping to change at page 8, line 26 skipping to change at page 8, line 32
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 SHOULD return an IP address in the "ciaddr" if it has any DHCP server SHOULD 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 MUST be the IP address most recently 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 used by the client described by the MAC address or Client-identifier
option (or the client described by both, if both appear). option (or the 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 DHCPKNOWN, DHCPACTIVE or to the DHCPLEASEQUERY message: either a DHCPLEASEKNOWN, DHCPLEASEAC-
DHCPUNKNOWN (or in some cases, DHCPUNIMPLEMENTED). The reasons why a TIVE or DHCPLEASEUNKNOWN (or in some cases, DHCPUNIMPLEMENTED). The
DHCPKNOWN, DHCPACTIVE or DHCPUNKNOWN message might be generated are reasons why a DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN
explained in the specific query regimes, below. Servers which do not message might be generated are explained in the specific query
support the DHCPLEASEQUERY message SHOULD (and are expected to) drop regimes, below.
the DHCPLEASEQUERY message silently, although they MAY respond with a
DHCPUNIMPLEMENTED message. The DHCPLEASEQUERY message can support Servers which do not implement the DHCPLEASEQUERY message fall into
three query regimes: two classes. Those that simply do not know about the DHCPLEASEQUERY
message will simply not respond to it, so clients which send the
DHCPLEASEQUERY message MUST be prepared to deal with this behavior.
Servers which are aware of the DHCPLEASEQUERY message but do not
implement it SHOULD respond with a DHCPUNIMPLEMENTED message but MAY
simply not respond.
The DHCPLEASEQUERY message can support three query regimes:
o Query by IP address: o Query by IP address:
For this query, the "ciaddr" field MUST contain an IP address. For this query, the requester supplies only an IP address in the
It MUST NOT contain a MAC address or Client-identifier option DHCPLEASEQUERY message. The DHCP server will return any infor-
(option 61). The DHCP server will return any information that mation that it has on the most recent client to have been
it has on the most recent client to have been allocated that IP assigned that IP address.
address. Any server which supports the DHCPLEASEQUERY message
MUST support query by IP address.
The DHCP server replies to the DHCPLEASEQUERY message with a The DHCP server replies with a DHCPLEASEKNOWN or DHCPLEASEACTIVE
DHCPKNOWN or DHCPACTIVE message if the "ciaddr" corresponds to message if the IP address in the DHCPLEASEQUERY message
an IP address about which the server has definitive information corresponds to an IP address about which the server has defini-
(i.e., it is authorized to lease this IP address). The server tive information (ie., it is authorized to lease this IP
replies with a DHCPUNKNOWN message if the server does not have address). The server replies with a DHCPLEASEUNKNOWN message if
definitive location information concerning the lease implied by the server does not have definitive information concerning the
the "ciaddr". address in the DHCPLEASEQUERY message.
A server which implements the DHCPLEASEQUERY message MUST imple-
ment this capability.
o Query by MAC address: o Query by MAC address:
For this query, the "ciaddr" field MUST be zero and there MUST For this query, the requester supplies only a MAC address in the
be a MAC address is specified in the "htype", "hlen", and DHCPLEASEQUERY message. The DHCP server will return any infor-
"chaddr" fields. There MUST NOT be a Client-identifier option mation that it has on the IP address most recently accessed by a
(option 61) in the packet. The DHCP server looks up all IP client with that MAC address. In addition, it may supply addi-
addresses for which clients with this MAC address are the most tion IP addresses which have been associated with that MAC
recent user. In contrast to the query by IP address, there may address in different subnets. Information about these bindings
be multiple IP addresses which show the client specified by the can then be found using the Query by IP Address, described
MAC address as having been the most recent user. The DHCP server above.
places the IP address most recently accessed by a DHCP client
with this MAC address (unless specifically configured otherwise,
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.
The DHCP server replies to the DHCPLEASEQUERY message with a The DHCP server replies with a DHCPLEASEKNOWN or DHCPLEASEACTIVE
DHCPKNOWN or DHCPACTIVE message if the MAC address corresponds message if the MAC address in the DHCPLEASEQUERY message
to a DHCP client which was the most recent user of an IP address corresponds to an IP address about which the server has defini-
controlled by this DHCP server. The server replies with a tive information (ie., it is authorized to lease this IP
DHCPUNKNOWN message if the MAC address does not correspond to address). The server replies with a DHCPLEASEUNKNOWN message if
such an IP address. the server does not have definitive information concerning the
MAC address in the DHCPLEASEQUERY message.
A server which implements the DHCPLEASEQUERY message SHOULD
implement this capability. If it does not, it SHOULD respond
with a DHCPUNIMPLEMENTED message when it receives a query by MAC
address.
o Query by Client-identifier option: o Query by Client-identifier option:
For this query, the "ciaddr" field MUST be zero, there MUST be a For this query, the requester supplies only a client-id option
Client-identifier option (option 61) in the packet and there in the DHCPLEASEQUERY message. The DHCP server will return any
MUST NOT be a MAC address in the packet (i.e., the hlen, htype, information that it has on the IP address most recently accessed
and chaddr MUST all be zero). The DHCP server looks up all IP by a client with that client-id. In addition, it may supply
addresses for which a client with this Client-identifier is the addition IP addresses which have been associated with client-id
most recent user. In contrast to the query by IP address, there in different subnets. Information about these bindings can then
may be multiple IP addresses which show the client specified by be found using the Query by IP Address, described above.
this Client-identifier as having been the most recent user. The
DHCP server places the IP address most recently accessed by a The DHCP server replies with a DHCPLEASEKNOWN or DHCPLEASEACTIVE
DHCP client with this Client-identifier (unless specifically message if the client-id in the DHCPLEASEQUERY message
configured otherwise, see Section 6.4) in the "ciaddr" field, corresponds to an IP address about which the server has defini-
and returns other information associated with that IP address. tive information (ie., it is authorized to lease this IP
If requested, the DHCP server SHOULD return information on all address). The server replies with a DHCPLEASEUNKNOWN message if
of the IP addresses it found to be associated with the DHCP the server does not have definitive information concerning the
client with the Client-identifier in a single Requested IP client-id in the DHCPLEASEQUERY message.
address option (option 50) containing multiple IP addresses. A
server which implements the DHCPLEASEQUERY message SHOULD A server which implements the DHCPLEASEQUERY message SHOULD
implement this capability. If it does not, it MUST respond with implement this capability. If it does not, it SHOULD respond
a DHCPUNIMPLEMENTED message when it received a query by Client- with a DHCPUNIMPLEMENTED message when it receives a query by
identifier option address. 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 or DHCPACTIVE message reply MUST always contain the IP The DHCPLEASEKNOWN or DHCPLEASEACTIVE message reply MUST always con-
address in the ciaddr field and SHOULD contains the physical address tain the IP address in the ciaddr field and SHOULD contains the phy-
of the IP address lease owner in the "htype", "hlen", and "chaddr" sical address of the IP address lease owner in the "htype", "hlen",
fields. The Parameter Request List (option 55) can be used to request and "chaddr" fields. The Parameter Request List (option 55) can be
specific options to be returned about the IP address in the ciaddr. used to request specific options to be returned about the IP address
The reply often contains the time until expiration of the lease, and in the ciaddr. The reply often contains the time until expiration of
the original contents of the Relay Agent Information option [RFC the lease, and the original contents of the Relay Agent Information
3046]. The access concentrator uses the "chaddr" and Relay Agent option [RFC 3046]. The access concentrator uses the "chaddr" and
Information option to construct location information, which can be Relay Agent Information option to construct location information,
cached on the access concentrator until lease expiration. which can be cached on the access concentrator until lease expira-
tion.
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 (option 82) [RFC 3046] associated with every IP address which it
server which implements DHCPLEASEQUERY SHOULD also save the informa- serves. It is assumed that most clients which generate the DHCPLEASE-
tion on the most recent vendor-class-identifier, option 60, associ- QUERY message will ask for the Relay Agent Information option (option
ated with each IP address. 82) in the Parameter Request List (option 55), and so supporting the
DHCPLEASEQUERY message without having the Relay Agent Information
option around to return to the client is likely to be less than help-
ful.
A server which implements DHCPLEASEQUERY SHOULD also save the infor-
mation on the most recent Vendor class identifier, option 60, associ-
ated with each IP address, since this option is also a likely candi-
date to 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 [RFC 2131] and [RFC 2132]. 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 [RFC 2132] requires
five new values: The DHCPLEASEQUERY message itself and its five new values: The DHCPLEASEQUERY message itself and its
three possible responses DHCPKNOWN, DHCPACTIVE, DHCPUNKNOWN, three possible responses DHCPLEASEKNOWN, DHCPLEASEACTIVE,
and DHCPUNIMPLEMENTED. The values of these message types are DHCPLEASEUNKNOWN, and DHCPUNIMPLEMENTED. The values of these
shown below in a reproduction of the table from [RFC 2132]: message types are 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 DHCPLEASEKNOWN
TBD DHCPUNKNOWN TBD DHCPLEASEUNKNOWN
TBD DHCPACTIVE TBD DHCPLEASEACTIVE
TBD DHCPUNIMPLEMENTED 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 40 skipping to change at page 12, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 a new option, the client-last-transaction-time:
important information in a DHCPKNOWN response to a DHCPLEASE-
QUERY message -- 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 DHCPKNOWN messages from two different DHCP servers need to when DHCPLEASEKNOWN messages from two different DHCP servers
be compared, although it can be useful in other situations. need to be compared, although it can be useful in other situa-
The value is a duration in seconds from the current time into tions. The value is a duration in seconds from the current
the past when this IP address was most recently the subject of time into the past when this IP address was most recently the
communication between the client and the DHCP server. subject of communication between the client and the DHCP
server.
This MUST NOT be an absolute time. This MUST NOT be an abso- This MUST NOT be an absolute time. This MUST NOT be an abso-
lute number of seconds since Jan 1, 1970. Instead, this MUST lute number of seconds since Jan 1, 1970. Instead, this MUST
be an integer number of seconds in the past from the time the be an integer number of seconds in the past from the time the
DHCPKNOWN message is sent that the client last dealt with this DHCPLEASEKNOWN message is sent that the client last dealt with
server about this IP address. In the same way that the IP this server about this IP address. In the same way that the IP
Address Lease Time option (option 51) encodes a lease time Address Lease Time option (option 51) encodes a lease time
which is a number of seconds into the future from the time the 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 message was sent, this option encodes a value which is a number
of seconds into the past from when the message was sent. 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 TBD. 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 | | TBD | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
4. The Requested IP Address option is extended to allow for multi- 4. There in a second new option, the associated-ip option:
ple IP addresses in the option.
associated-ip
This option is used to return all of the IP addresses associ- This option is used to return all of the IP addresses associ-
ated with the DHCP client specified in a particular DHCPLEASE- ated with the DHCP client specified in a particular DHCPLEASE-
QUERY message. QUERY message.
The code for this option is 50, and its minimum length is 4 and The code for this option is TBD. The minimum length for this
its maximum length MUST be a multiple of 4. option is 4 octets, and the length MUST always be a multiple of
4.
Code Len Address 1 Address 2 Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+-----+--
| 50 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... | TBD | 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 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 DHCPKNOWN or DHCPUNKNOWN message from the DHCP of for the DHCPLEASEKNOWN or DHCPLEASEUNKNOWN message from the
server. DHCP server.
o The Parameter Request List SHOULD be set to the options of o The Parameter Request List option (option 55) SHOULD be set to
interest to the requester. The interesting options are likely the options of interest to the requester. The interesting
to include the IP Address Lease Time option (option 51) and the options are likely to include the IP Address Lease Time option
Relay Agent Information option (option 82). (option 51), the Relay Agent Information option (option 82) and
possibly the Vendor class identifier option (option 60). In the
absence of a Parameter Request List option, the server will
return the same options it would return for a DHCPREQUEST mes-
sage which didn't contain a DHCPLEASEQUERY message, which
includes those mandated by [RFC 2131, Section 4.3.1] as well as
any options which the server was configured to always return to
a client.
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 not used when [RFC 2131] and Section 6.1 of this document) is not used when
sending a DHCPLEASEQUERY message. sending a DHCPLEASEQUERY message.
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.
skipping to change at page 14, line 10 skipping to change at page 14, line 45
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 0.
The access concentrator SHOULD ensure that the "ciaddr" field men-
tioned in the DHCPLEASEQUERY message (if a query by IP address) is a
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 exactly 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-identifier. zero "htype"/"hlen"/"chaddr", or a Client-identifier.
The DHCP server which receives a DHCPLEASEQUERY message MUST base its The DHCP server which 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. response to the DHCPLEASEQUERY message. It MUST NOT be used to res-
trict the processing of the query in any way, and MUST NOT be used
locate a subnet to which the ciaddr (if any) must belong.
6.4. Responding to the DHCPLEASEQUERY Message 6.4. Responding to the DHCPLEASEQUERY Message
There are four possible responses to a DHCPLEASEQUERY message: There are four possible responses to a DHCPLEASEQUERY message:
o DHCPKNOWN o DHCPLEASEKNOWN
The DHCPKNOWN message indicates that the server knows about the
IP address or client specified in the DHCPLEASEQUERY message,
but there is no currently active lease for the IP address
returned in the "ciaddr" field of the DHCPKNOWN message. The R
(reservation) bit MAY be set in the case where there is a reser-
vation for this IP address by the client returned in the
DHCPKNOWN message, allowing the access concentrator to consider
a reservation equivalent to a currently active lease on the IP
address.
The server MUST respond with a DHCPKNOWN message if this server The server MUST respond with a DHCPLEASEKNOWN message if this
has information about the IP address or client in question, but server has information about the IP address or client in ques-
that there is no active lease for the IP address or client tion, but there is no active lease for the IP address or client
specified in the query. If the query was by IP address, then specified in the query. If the query was by IP address, then
the DHCPKNOWN message indicates that this server manages this IP the DHCPLEASEKNOWN message indicates that this server manages
address. If there is a reservation for this IP address, then this IP address. In the case where a client was specified either
the DHCP server MUST set the R (reservation) bit in the "flags" by Client-identifier or MAC address, then the DHCPLEASEKNOWN
field of the DHCP packet, and the DHCP server MUST return what- message indicates that the client is known to the DHCP server,
ever client information is known in the DHCPKNOWN message. and was the most recent client associated with a particular IP
address.
In the case where a client was specified either by Client- For any type of query, if the client specified in the DHCPLEASE-
identifier or MAC address, then the DHCPKNOWN message indicates KNOWN message has a reservation for the IP address specifed in
that the client is known to the DHCP server, and was the most the ciaddr, then the server MUST set the R (reservation) bit in
recent client associated with a particular IP address. In the the DHCPLEASEKNOWN message.
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.
o DHCPUNKNOWN o DHCPLEASEUNKNOWN
The DHCPKNOWN message indicates that the server knows nothing The DHCPLEASEKNOWN message indicates that the server knows noth-
about the IP address or client specified in the DHCPLEASEQUERY ing about the IP address or client specified in the DHCPLEASE-
message. QUERY message.
The server MUST response with a DHCPKNOWN message when this The server MUST response with a DHCPLEASEKNOWN message when this
server has no information about the IP address or client speci- server has no information about the IP address or client speci-
fied in the DHCPLEASEQUERY message. fied in the DHCPLEASEQUERY message.
When responding with a DHCPUNKNOWN, the DHCP server SHOULD NOT When responding with a DHCPLEASEUNKNOWN, the DHCP server SHOULD
include other DHCP options in the response. The R (reservation) NOT include other DHCP options in the response. The R (reserva-
bit MUST NOT be set in the "flags" field of the DHCP packet. tion) bit MUST NOT be set in the "flags" field of the DHCP
packet.
o DHCPACTIVE o DHCPLEASEACTIVE
The DHCPACTIVE message indicates that the server not only knows The DHCPLEASEACTIVE message indicates that the server not only
about the IP address and client specified in the DHCPACTIVE mes- knows about the IP address and client specified in the
sage but also that there is an active lease by that client for DHCPLEASEACTIVE message but also that there is an active lease
that IP address. by that client for that IP address.
In some cases, the DHCP server MAY be configured to return a In some cases, the DHCP server MAY be configured to return a
DHCPACTIVE message when there is no active lease but when there DHCPLEASEACTIVE message when there is no active lease but when
is a reservation by the specified client for the IP address in there is a reservation by the specified client for the IP
the "ciaddr" field of the DHCPACTIVE message. A server would be address in the "ciaddr" field of the DHCPLEASEACTIVE message. A
so configured when it was desired that the access concentrator server would be so configured when it was desired that the
would allow access to IP addresses which are not DHCP clients. access concentrator would allow access to IP addresses which are
In this case the DHCP server SHOULD NOT place an IP Address not DHCP clients. In this case the DHCP server SHOULD NOT place
Lease Time (option 51) in the DHCPACTIVE message, allowing the an IP Address Lease Time (option 51) in the DHCPLEASEACTIVE mes-
access concentrator to determine that this is a DHCPACTIVE mes- sage, allowing the access concentrator to determine that this is
sage for an IP address without a currently active lease. a DHCPLEASEACTIVE message for an IP address without a currently
active lease.
The server MUST respond with a DHCPACTIVE message when the IP The server MUST respond with a DHCPLEASEACTIVE message when the
address returned in the "ciaddr" field is currently leased. If IP address returned in the "ciaddr" field is currently leased.
the client returned in the DHCPACTIVE message has a reservation If the client returned in the DHCPLEASEACTIVE message has a
for that IP address recorded in the DHCP server, then the R reservation for that IP address recorded in the DHCP server,
(reservation) bit MUST be set in the "flags" field of the DHCP then the R (reservation) bit MUST be set in the "flags" field of
packet. the DHCP packet.
o DHCPUNIMPLEMENTED o DHCPUNIMPLEMENTED
The DHCPUNIMPLEMENTED message indicates that the particular form The DHCPUNIMPLEMENTED response to the DHCPLEASEQUERY message
of DHCPLEASEQUERY used is not implemented in this DHCP server. indicates that the particular form of DHCPLEASEQUERY used is not
It may mean that the DHCPLEASEQUERY message as a whole is not implemented in this DHCP server. It may mean that the DHCPLEASE-
implemented by this DHCP server although it is usually used to QUERY message as a whole is not implemented by this DHCP server
indicate that a query by Client-identifier or MAC address is not although it is usually used to indicate that a query by Client-
implemented by a DHCP server that otherwise supports a identifier or MAC address is not implemented by a DHCP server
DHCPLEASEQUERY by IP address. that otherwise supports a DHCPLEASEQUERY by IP address.
The DHCPUNIMPLEMENTED message can apply to any unimplemented
messages, and MAY be used to respond to messages other than
DHCPLEASEQUERY.
6.4.1. Determining the IP address to 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 to 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 may also be returned in mul- addresses for which a client has a lease must also be returned in the
tiple Requested IP address options (option 50). This is the only associated-ip option (Section 6.1, #4). This is the only information
information returned not directly associated with the IP address in returned not directly associated with the IP address in the "ciaddr"
the "ciaddr" field.) field.
6.4.1. Determining the IP address to which to respond
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
DHCPKNOWN message. DHCPLEASEKNOWN message.
If the IP address is not managed by the DHCP server, then a DHCPUN- If the IP address is not managed by the DHCP server, then a
KNOWN 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 which 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 DHCPLEASE- identical MAC address (if the MAC address fields in the DHCPLEASE-
QUERY message are non-zero). This client matching approach will, for QUERY message are non-zero). This client matching approach will, for
the purposes of this section, be described as "Client-identifier or the purposes of this section, be described as "Client-identifier or
MAC address". MAC address".
The Reservations bit (the R bit) has no meaning in the DHCPLEASEQUERY The Reservations bit (the R bit) has no meaning in the DHCPLEASEQUERY
message and is used only to indicate the existence of a reservation message and is used only to indicate the existence of a reservation
in a DHCPKNOWN or DHCPACTIVE message. in a DHCPLEASEKNOWN or DHCPLEASEACTIVE message.
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 the DHCPKNOWN or DHCPAC- IP address placed in the "ciaddr" field of the DHCPLEASEKNOWN or
TIVE message MUST be that of an IP address for which the client that DHCPLEASEACTIVE message MUST be that of an IP address for which the
most recently used the IP address matches the Client-identifier or client that most recently used the IP address matches the Client-
MAC address specified in the DHCPLEASEQUERY message. identifier or MAC address 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 which fulfills this criteria,
then it MUST be placed in the "ciaddr" field of the DHCPKNOWN or then it MUST be placed in the "ciaddr" field of the DHCPLEASEKNOWN or
DHCPACTIVE message. DHCPLEASEACTIVE message.
In the case where more than one IP has been accessed by the client In the case where more than one IP address has been accessed by the
specified by the MAC address or Client-identifier option, then the client specified by the MAC address or Client-identifier option, then
DHCP server MUST return the IP address returned to the client in the the DHCP server MUST return the IP address returned to the client in
most recent transaction with the client unless the DHCP server has the most recent transaction with the client unless the DHCP server
been configured by the server administrator to use some other prefer- has been configured by the server administrator to use some other
ence 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 DHCPKNOWN or DHCPACTIVE message, then a DHCPUN- "ciaddr" field of the DHCPLEASEKNOWN or DHCPLEASEACTIVE message, then
KNOWN message MUST be returned instead. a DHCPLEASEUNKNOWN message MUST be returned instead.
6.4.2. Building a DHCPKNOWN or DHCPACTIVE message once the "ciaddr" 6.4.2. Building a DHCPLEASEKNOWN or DHCPLEASEACTIVE message once the
field is set "ciaddr" field is set
Once the "ciaddr" field of the DHCPKNOWN or DHCPACTIVE message is Once the "ciaddr" field of the DHCPLEASEKNOWN or DHCPLEASEACTIVE mes-
set, the rest of the processing largely involves returning informa- sage is set, the rest of the processing largely involves returning
tion about the IP address specified in the "ciaddr" field. information about the IP address specified in the "ciaddr" field.
If the IP address in the "ciaddr" field of the DHCPKNOWN or DHCPAC- If the IP address in the "ciaddr" field of the DHCPLEASEKNOWN or
TIVE message is currently leased by the client specified in the DHCPLEASEACTIVE message is currently leased by the client specified
Client-identifier or MAC address returned in the DHCPKNOWN or DHCPAC- in the Client-identifier or MAC address returned in the DHCPLEASE-
TIVE message, then the message MUST be a DHCPACTIVE message, other- KNOWN or DHCPLEASEACTIVE message, then the message MUST be a
wise it MUST be a DHCPKNOWN message. DHCPLEASEACTIVE message, otherwise it MUST be a DHCPLEASEKNOWN mes-
sage.
It MAY be possible to configure a DHCP server to return a DHCPACTIVE It MAY be possible to configure a DHCP server to return a
message even though the IP address specified in the "ciaddr" field is DHCPLEASEACTIVE message even though the IP address specified in the
not currently leased if there is a reservation for that IP address by "ciaddr" field is not currently leased if there is a reservation for
the client specified in the Client-identifier or MAC address fields that IP address by the client specified in the Client-identifier or
of the DHCPACTIVE message. In this case, there MUST NOT be an IP MAC address fields of the DHCPLEASEACTIVE message. In this case,
Address Lease Time option (option 51) in the packet. 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 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 address in the "ciaddr" field is reserved for the client returned in
the MAC address or Client-identifier option. the MAC address or Client-identifier option.
The IP address in the "ciaddr" field of the DHCPKNOWN or DHCPACTIVE The IP address in the "ciaddr" field of the DHCPLEASEKNOWN or
message MUST be one for which this server is responsible (or a DHCPLEASEACTIVE message MUST be one for which this server is respon-
DHCPUNKNOWN message would be have already been returned early in the sible (or a DHCPLEASEUNKNOWN message would be have already been
processing described in the previous section). returned early in the processing described in the previous section).
The MAC address of the DHCPKNOWN or DHCPACTIVE message MUST be set The MAC address of the DHCPLEASEKNOWN or DHCPLEASEACTIVE message MUST
from the client associated with the IP address in the "ciaddr" field be set to the values which identify the client associated with the IP
of the DHCPKNOWN message. This may be derived from a real DHCP address in the "ciaddr" field of the DHCPLEASEKNOWN message. This
client or from reservation information configured into the DHCP may be derived from a real DHCP client or from reservation informa-
server. tion configured into the DHCP server.
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 DHCPKNOWN or DHCPACTIVE message. This field SHOULD be returned in the DHCPLEASEKNOWN or DHCPLEASEACTIVE
may be derived from a real DHPC client, or from reservation informa- message. This may be derived from a real DHCP client, or from reser-
tion configured into the DHCP server. vation information configured into the DHCP server.
In the case where more than one IP has been accessed by the client In the case where more than one IP address has been involved in a
specified by the MAC address and/or Client-identifier option, then DHCP message exchange with the client specified by the MAC address
the list of all of the IP addresses SHOULD be returned as multiple and/or Client-identifier option, then the list of all of the IP
Requested IP address options (option 50), if that option was addresses SHOULD be returned in the associated-ip option (option
requested as part of the Parameter Request List option. TBD), 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 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 Parameter Request List and if there is a currently valid lease for
the IP address specified in the ciaddr, then the DHCP server MUST 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 return this option in the DHCPLEASEKNOWN with its value equal to the
remaining until lease expiration. If there is no valid lease for the time remaining until lease expiration. If there is no valid lease
IP address, then the server MUST NOT return the IP Address Lease Time for the IP address, then the server MUST NOT return the IP Address
option (option 51). This allows the requester (i.e. the access con- Lease Time option (option 51).
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 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 "ciaddr" field, and if the "ciaddr" in the DHCPLEASEKNOWN message is
the DHCPKNOWN messages (i.e., if the sender of the DHCPLEASEQUERY currently reserved for the client specified by the client-id or MAC
message requested reservation information, and the "ciaddr" in the address, then the DHCP server MAY synthesize an IP Address Lease Time
DHCPKNOWN message was derived from reservation information), then the option for the DHCPLEASEKNOWN message if configured to do so. Typi-
DHCP server MAY synthesize an IP Address Lease Time option for the cally the value of this option would itself be a configuration param-
DHCPKNOWN message if configured to do so. Typically the value of eter of the DHCP server.
this option would itself be a configuration parameter of the DHCP
server.
A request for the Renewal (T1) Time Value option or the Rebinding A request for the Renewal (T1) Time Value option or the Rebinding
(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, then the DHCP server option is handled. If there is a valid lease, then the DHCP server
SHOULD return these options (when requested) with the remaining time SHOULD return these options (when requested) with the remaining time
until renewal or rebinding, respectively. If there is not currently until renewal or rebinding, respectively. If there is not currently
a valid lease for this IP address, the DHCP server MUST NOT return a valid lease for this IP address, the DHCP server MUST NOT return
these options. these options.
If the Relay Agent Information (option 82) is specified in the Param- If the Relay Agent Information (option 82) is specified in the Param-
eter Request List and if the DHCP server has saved the information eter Request List and if the DHCP server has saved the information
contained in the most recent Relay Agent Information option, the DHCP contained in the most recent Relay Agent Information option, the DHCP
server MUST include that information in a Relay Agent Information server MUST include that information in a Relay Agent Information
option in the DHCPKNOWN. option in the DHCPLEASEKNOWN.
The DHCPKNOWN or DHCPACTIVE message SHOULD include the values of all The DHCPLEASEKNOWN or DHCPLEASEACTIVE message SHOULD include the
other options not specifically discussed above that were requested in values of all other options not specifically discussed above that
the Parameter Request List of the DHCPLEASEQUERY message. The DHCP were requested in the Parameter Request List of the DHCPLEASEQUERY
server uses information from the lease binding database to supply the message. The DHCP server uses information from its lease binding
DHCPKNOWN or DHCPACTIVE option values. The values of the options database to supply the DHCPLEASEKNOWN or DHCPLEASEACTIVE option
that were returned to the DHCP client would generally be preferred, values. The values of the options that were returned to the DHCP
but in the absence of those, options that were sent in DHCP client client would generally be preferred, but in the absence of those,
requests would be acceptable. 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
(option 82) values to the secondary server via the DHCP Failover (option 82) values to the secondary server via the DHCP Failover
BNDUPD messages. BNDUPD messages.
6.4.3. Sending a DHCPKNOWN, DHCPACTIVE, or DHCPUNKNOWN message 6.4.3. Sending a DHCPLEASEKNOWN, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN
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, DHCPACTIVE or DHCPUNKNOWN message to the giaddr. casts the DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message
If the giaddr field is zero, then the DHCP server MUST NOT reply to to the giaddr. If the giaddr field is zero, then the DHCP server MUST
the DHCPLEASEQUERY message. NOT reply to the DHCPLEASEQUERY message.
6.5. Receiving a DHCPKNOWN, DHCPACTIVE, or DHCPUNKNOWN Message 6.5. Receiving a DHCPLEASEKNOWN, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN
Message
When a DHCPACTIVE message is received in response to the DHCPLEASE- When a DHCPLEASEACTIVE message is received in response to the
QUERY message it means that there is a currently active lease for DHCPLEASEQUERY message 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 DHCPLEASEACTIVE as well as any Relay Agent Information option
included in the packet to refresh its location information for this information included in the packet to refresh its location informa-
IP address. tion for this IP address.
When a DHCPKNOWN message is received in response to the DHCPLEASE- When a DHCPLEASEKNOWN message is received in response to the
QUERY message that means that there is no currently active lease for DHCPLEASEQUERY message that means that there is no currently active
the IP address present in the DHCP server. In this case, the access lease for the IP address present in the DHCP server. In this case,
concentrator SHOULD cache this information in order to prevent unac- the access concentrator SHOULD cache this information in order to
ceptable loads on the access concentrator and the DHCP server in the prevent unacceptable loads on the access concentrator and the DHCP
face of a malicious or seriously compromised device downstream of the server in the face of a malicious or seriously compromised device
access concentrator. downstream of the access concentrator. This cacheing could be as
simple as simply setting a bit saying that a response was received
from a server which 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 "gleaned" that a lease for this IP address
came into existance.
If the R (reservation) bit is set in the "flags" field of the If the R (reservation) bit is set in the "flags" field of the
DHCPKNOWN message, it means that a reservation exists in the DHCP DHCPLEASEKNOWN message, it means that a reservation exists in the
server for the IP address and associated client. The access concen- DHCP server for the IP address and associated client. The access
trator MAY be configured to allow the client access even though no concentrator MAY be configured to allow the client access even though
currently outstanding lease is in place for this no currently outstanding lease is in place for this
In either case, when a DHCPKNOWN or DHCPACTIVE message is received in In either case, when a DHCPLEASEKNOWN or DHCPLEASEACTIVE message is
response to a DHCPLEASEQUERY message, it means that the DHCP server received in response to a DHCPLEASEQUERY message, it means that the
which responded is a DHCP server which manages the IP address present DHCP server which responded is a DHCP server which manages the IP
in the ciaddr, and the Relay Agent SHOULD cache this information for address present in the ciaddr, and the Relay Agent SHOULD cache this
later use. information for later use.
When a DHCPUNKNOWN 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 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 does not have definitive information concerning the IP
contained in the "ciaddr" field of the DHCPLEASEQUERY message. If address contained in the "ciaddr" field of the DHCPLEASEQUERY mes-
there is no IP address in the "ciaddr" field of the DHCPLEASEQUERY sage. If there is no IP address in the "ciaddr" field of the
message, then a DHCPUNKNOWN message means that the DHCP server does DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means that
not have definitive information concerning the any DHCP client speci- the DHCP server does not have definitive information concerning the
fied in the "hlen", "htype", and "chaddr" fields or the Client- any DHCP client specified in the "hlen", "htype", and "chaddr" fields
identifier option of the DHCPLEASEQUERY message. or the Client-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" field responded to a DHCPLEASEQUERY message for a particular "ciaddr" field
with a DHCPUNKNOWN. with a DHCPLEASEUNKNOWN.
When a DHCPUNIMPLEMENTED message is received by an access concentra- When a DHCPUNIMPLEMENTED message is received by an access concentra-
tor, it means that the particular aspect of DHCPLEASEQUERY processing tor, it means that the particular aspect of DHCPLEASEQUERY processing
requested is not implemented in the responding server. It may or may requested is not implemented in the responding server. It may or may
not be the case that other aspects of DHCPLEASEQUERY processing are not be the case that other aspects of DHCPLEASEQUERY processing are
not implemented in that server. not implemented in that server.
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 DHCPKNOWN, DHCPACTIVE or o The DHCPLEASEQUERY or a corresponding DHCPLEASEKNOWN,
DHCPUNKNOWN were lost during transmission or the DHCPLEASEQUERY DHCPLEASEACTIVE or DHCPLEASEUNKNOWN were lost during transmis-
arrived at the DHCP server but it was dropped because the server sion or the DHCPLEASEQUERY arrived at the DHCP server but it was
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 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). does or does not support 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 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.
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 backs off exponentially to once a minute, and a 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-message backoff timer that also backs off to once a minute. The
per-server timer would start off expired, and in the expired state per-server timer would start off expired, and in the expired state
only one DHCPLEASEQUERY message would be queued for the associated only one DHCPLEASEQUERY message would be queued for the associated
server. This DHCPLEASEQUERY message would be sent with the backoff server. This DHCPLEASEQUERY message would be sent with the backoff
quickly moving to once a minute until a DHCPACTIVE, DHCPKNOWN, or quickly moving to once a minute until a DHCPLEASEACTIVE, DHCPLEASE-
DHCPUNKNOWN message reply was received. Whenever one of these mes- KNOWN, or DHCPLEASEUNKNOWN message reply was received. Whenever one
sages is received, the per-server timer is reset, and whenever the of these messages is received, the per-server timer is reset, and
per-server timer has not expired, more than one individual DHCPLEASE- whenever the per-server timer has not expired, more than one indivi-
QUERY messages can be outstanding to the DHCP server at one time. It dual DHCPLEASEQUERY messages can be outstanding to the DHCP server at
is recommended that this number be limited to a relatively small one time. It is recommended that this number be limited to a rela-
number, for example, 100 or 200, to avoid swamping the DHCP server. tively small number, for example, 100 or 200, to avoid swamping the
Each of these messages should have its own per-message retry timer. DHCP server. Each of these messages should have its own per-message
This would retransmit each message and backoff as discussed above. In retry timer. This would retransmit each message and backoff as dis-
the event the per-server timer goes off, then all outstanding mes- cussed above. In the event the per-server timer goes off, then all
sages SHOULD be dropped except for a single DHCPLEASEQUERY message outstanding messages SHOULD be dropped except for a single DHCPLEASE-
which is used to poll the server until such time as another DHCPAC- QUERY message which is used to poll the server until such time as
TIVE, DHCPKNOWN, or DHCPUNKNOWN message is received. another DHCPLEASEACTIVE, DHCPLEASEKNOWN, or DHCPLEASEUNKNOWN message
is received.
6.7. Using the DHCPLEASEQUERY message in a failover environment 6.7. Using the DHCPLEASEQUERY message in a failover environment
When using the DHCPLEASEQUERY message in an environment where multi- When using the DHCPLEASEQUERY message in an environment where multi-
ple DHCP server may contain authoritative information about the same ple DHCP server may contain authoritative information about the same
IP address (such as when failover [FAILOVER] is operating), there IP address (such as when failover [FAILOVER] is operating), there
could be some difficulty in deciding which results are the most use- could be some difficulty in deciding which results are the most use-
ful if two servers respond with DHCPKNOWN messages to the same query. ful if two servers respond with DHCPLEASEKNOWN 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.
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
tible to malicious hosts which masquerade as the intended IP end- susceptible to malicious hosts which masquerade as the intended IP
points. Thus, the DHCPLEASEQUERY message allows an access concentra- endpoints. Thus, the DHCPLEASEQUERY message allows an access concen-
tor to provide considerably enhanced security. trator 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 [RFC 3118]. 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 access concentrator and the DHCP server) is straightforward.
Alternatively, use of IPsec would also be a way to ensure security Alternatively, use of IPsec would also be a way to ensure security
between the relay agent and the DHCP server. 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 cacheing (i.e. cache both DHCPKNOWN and should employ negative cacheing (i.e. cache both DHCPLEASEKNOWN and
DHCPUNKNOWN responses to DHCPLEASEQUERY messages) and ciaddr restric- DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY messages) and ciaddr
tion (i.e. don't send a DHCPLEASEQUERY message with a ciaddr outside restriction (i.e. don't send a DHCPLEASEQUERY message with a ciaddr
of the range of the attached broadband access networks). Together, outside of the range of the attached broadband access networks).
these mechanisms limit the access concentrator to transmitting one Together, these mechanisms limit the access concentrator to transmit-
DHCPLEASEQUERY message (excluding message retries) per legitimate ting one DHCPLEASEQUERY message (excluding message retries) per legi-
broadband access network IP address after a reboot event. timate broadband access network IP address after a reboot event.
In some environments it may be appropriate to configure a DHCP server
with the IP addresses of the relay agents for which it may respond to
DHCPLEASEQUERY messages, thereby allowing it to respond only to to
requests from only a handful of relay agents. This does not provide
any true security, but may be useful to thwart unsophisticated
attacks of various sorts.
8. IANA Considerations 8. IANA Considerations
IANA has assigned seven values for this document. See Section 6.1 IANA has assigned seven values and one bit position for this docu-
for details. There are five new messages types, which are the value ment. See Section 6.1 for details. There are five new messages
of the message type option (option 53) from [RFC 2132]. The value types, which are the value of the message type option (option 53)
for DHCPLEASEQUERY is TBD, the value for DHCPKNOWN is TBD, the value from [RFC 2132]. The value for DHCPLEASEQUERY is TBD, the value for
for DHCPACTIVE is TBD, the value for DHCPUNKNOWN is TBD and the value DHCPLEASEKNOWN is TBD, the value for DHCPLEASEACTIVE is TBD, the
for DHCPUNIMPLEMENTED is TBD. There is a new bit defined for the value for DHCPLEASEUNKNOWN is TBD and the value for DHCPUNIMPLEMENTED
"flags" field of the DHCP packet (see Section 1, Figure 1 and Table 1 is TBD. There is a new bit defined for the "flags" field of the DHCP
of [RFC 2131]). The flag is called "R: RESERVATION flag", and its packet (see Section 1, Figure 1 and Table 1 of [RFC 2131]). The flag
value is TBD. Finally, there is one new DHCP option defined, which is called "R: RESERVATION flag", and its value is TBD. Finally,
is the client-last-transaction-time option, and its option code is there are two new DHCP option defined; the client-last-transaction-
TBD. time option -- option code TBD, and the associated-ip option --
option code TBD.
9. Acknowledgments 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.
10. References 10. References
skipping to change at page 24, line 24 skipping to change at page 25, line 20
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-10.txt, January 2002. draft-ietf-dhc-failover-10.txt, January 2002.
11. Author's information 11. Author's information
Rich Woundy Rich Woundy
AT&T Broadband
27 Industrial Ave.
Chelmsford, MA 01824
Phone: (978) 244-4010
EMail: rwoundy@broadband.att.com
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 497-8000 Phone: (978) 497-8000
EMail: rwoundy@cisco.com EMail: kkinnear@cisco.com
kkinnear@cisco.com
12. Intellectual Property Statement 12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any intel- 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 lectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document 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 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 be available; neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's procedures with identify any such rights. Information on the IETF's procedures with
respect to rights in standards-track and standards-related documentation respect to rights in standards-track and standards-related documentation
 End of changes. 

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