draft-ietf-dhc-leasequery-06.txt   draft-ietf-dhc-leasequery-07.txt 
Dynamic Host Configuration Working Group Rich Woundy Dynamic Host Configuration Working Group Rich Woundy
INTERNET DRAFT Comcast Cable INTERNET DRAFT Comcast Cable
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems
October 2003 March 2004
Expires April 2004 Expires September 2004
DHCP Lease Query DHCP Lease Query
<draft-ietf-dhc-leasequery-06.txt> <draft-ietf-dhc-leasequery-07.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 38 skipping to change at page 1, line 38
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 (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
A DHCP server contains considerable authoritative information A DHCP server contains considerable authoritative information
concerning the IP addresses it has leased to DHCP clients. Other concerning the IP addresses it has leased to DHCP clients. Other
processes and devices, many that already send and receive DHCP format processes and devices, many that already send and receive DHCP format
packets, sometimes need to access this information. The leasequery packets, sometimes need to access this information. The leasequery
protocol is designed to give these processes and devices a protocol is designed to give these processes and devices a
lightweight way to access information that may be critical to their lightweight way to access information that may be critical to their
operation. operation.
Table of Contents
1. Introduction................................................. 2
2. Terminology.................................................. 5
3. Background................................................... 6
4. Design Goals................................................. 7
4.1. Broadcast ARP is Undesirable............................... 7
4.2. SNMP and LDAP Client Functionality is Lacking.............. 7
4.3. DHCP Relay Agent Functionality is Common................... 7
4.4. DHCP Servers as a Reliable Source of Location Information.. 8
4.5. Minimal Additional Configuration is Required............... 8
5. Protocol Overview............................................ 8
6. Protocol Details............................................. 11
6.1. Definitions required for DHCPLEASEQUERY processing......... 11
6.2. Sending the DHCPLEASEQUERY Message......................... 13
6.3. Receiving the DHCPLEASEQUERY Message....................... 15
6.4. Responding to the DHCPLEASEQUERY Message................... 15
6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or....... 19
6.6. Receiving no response to the DHCPLEASEQUERY Message........ 20
6.7. Lease binding data storage requirements.................... 21
6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 22
7. Security Considerations...................................... 22
8. IANA Considerations.......................................... 23
9. Acknowledgments.............................................. 23
10. References.................................................. 24
10.1. Normative References...................................... 24
10.2. Informative References.................................... 24
11. Author's information........................................ 25
12. Intellectual Property Statement............................. 25
13. Full Copyright Statement.................................... 26
1. Introduction 1. Introduction
A DHCP server contains considerable authoritative information A DHCP server contains considerable authoritative information
concerning the IP addresses it has leased to DHCP clients. Other concerning the IP addresses it has leased to DHCP clients. Sometimes
processes and devices, many that already send and receive DHCP format devices or other processes may need access to this information. In
packets, sometimes need to access this information. The leasequery some cases, these devices or processes already have the capability to
protocol is designed to give these processes and devices a send and receive DHCP packets, and so the leasequery protocol is
lightweight way to access information that may be critical to their designed to give these processes and devices a low overhead way to
operation. access such information.
For example, access concentrators that act as DHCP relay agents For example, access concentrators that act as DHCP relay agents
sometimes derive information important to their operation by sometimes derive information important to their operation by
extracting data out of the DHCP packets they forward, a process known extracting data out of the DHCP packets they forward, a process known
as "gleaning". Unfortunately, the typical access concentrator loses as "gleaning". Unfortunately, the typical access concentrator loses
its gleaned information when the access concentrator is rebooted or its gleaned information when the access concentrator is rebooted or
is replaced. This memo proposes that when gleaned DHCP information is replaced. This memo proposes that when gleaned DHCP information
is not available, the access concentrator/relay agent can obtain the is not available, the access concentrator/relay agent can obtain the
location information directly from the DHCP server(s) using the location information directly from the DHCP server(s) using the
DHCPLEASEQUERY message. DHCPLEASEQUERY message.
skipping to change at page 4, line 5 skipping to change at page 4, line 34
responses sent through the relay agent. When location information is responses sent through the relay agent. When location information is
not available from "gleaning", e.g. because the access concentrator not available from "gleaning", e.g. because the access concentrator
has rebooted, the access concentrator can query the DHCP server(s) has rebooted, the access concentrator can query the DHCP server(s)
for location information using the DHCPLEASEQUERY message defined in for location information using the DHCPLEASEQUERY message defined in
this document. this document.
The DHCPLEASEQUERY message is a new DHCP message type transmitted The DHCPLEASEQUERY message is a new DHCP message type transmitted
from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware
relay agent sends the DHCPLEASEQUERY message when it needs to know relay agent sends the DHCPLEASEQUERY message when it needs to know
the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server
replies with a DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN replies with a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or
message. The DHCPLEASEACTIVE response to a DHCPLEASEQUERY message DHCPLEASEUNKNOWN message. The DHCPLEASEACTIVE response to a
allows the relay agent to determine the IP endpoint location, and the DHCPLEASEQUERY message allows the relay agent to determine the IP
remaining duration of the IP address lease. The DHCPLEASEKNOWN is endpoint location, and the remaining duration of the IP address
similar to a DHCPLEASEACTIVE message but indicates that there is no lease. The DHCPLEASEUNASSIGNED is similar to a DHCPLEASEACTIVE
currently active lease on the resultant IP address but that this DHCP message but indicates that there is no currently active lease on the
server is authoritative for this IP address. The DHCPLEASEUNKNOWN resultant IP address but that this DHCP server is authoritative for
message indicates that the DHCP server has no knowledge of the this IP address. The DHCPLEASEUNKNOWN message indicates that the
information specified in the query (e.g., IP address, MAC address, or DHCP server has no knowledge of the information specified in the
client-id option). query (e.g., IP address, MAC address, or Client-identifier option).
The DHCPLEASEQUERY message does not presuppose a particular use for The DHCPLEASEQUERY message does not presuppose a particular use for
the information it returns -- it is simply designed to return the information it returns -- it is simply designed to return
information for which the DHCP server is an authoritative source to a information for which the DHCP server is an authoritative source to a
client which requests that information. It is designed to make it client which requests that information. It is designed to make it
straightforward for processes and devices which already interpret straightforward for processes and devices which already interpret
DHCP packets to access information from the DHCP server. DHCP packets to access information from the DHCP server.
2. Terminology 2. Terminology
skipping to change at page 5, line 32 skipping to change at page 6, line 12
This information includes knowledge of the host hardware This information includes knowledge of the host hardware
address, the port or virtual circuit that leads to the host, address, the port or virtual circuit that leads to the host,
and/or the hardware address of the intervening subscriber modem. and/or the hardware address of the intervening subscriber modem.
o "MAC address" o "MAC address"
In the context of a DHCP packet, a MAC address consists of the In the context of a DHCP packet, a MAC address consists of the
fields: hardware type "htype", hardware length "hlen", and fields: hardware type "htype", hardware length "hlen", and
client hardware address "chaddr". client hardware address "chaddr".
o "primary DHCP server"
The primary DHCP server in a DHCP Failover environment is
configured to provide primary service to a set of DHCP clients
for a particular set of subnet address pools.
o "secondary DHCP server"
The secondary DHCP server in a DHCP Failover environment is
configured to act as backup to a primary server for a particular
set of subnet address pools.
o "stable storage" o "stable storage"
Every DHCP server is assumed to have some form of what is called Every DHCP server is assumed to have some form of what is called
"stable storage". Stable storage is used to hold information "stable storage". Stable storage is used to hold information
concerning IP address bindings (among other things) so that this concerning IP address bindings (among other things) so that this
information is not lost in the event of a server failure which information is not lost in the event of a server failure which
requires restart of the server. requires restart of the server.
o "upstream" o "upstream"
skipping to change at page 6, line 28 skipping to change at page 6, line 43
allows access concentrators to send DHCPLEASEQUERY messages to DHCP allows access concentrators to send DHCPLEASEQUERY messages to DHCP
servers, to obtain location information of broadband access network servers, to obtain location information of broadband access network
devices. devices.
This document assumes that many access concentrators have an embedded This document assumes that many access concentrators have an embedded
DHCP relay agent functionality. Typical access concentrators include DHCP relay agent functionality. Typical access concentrators include
DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB
Interactive Network Adapters (INAs) [EUROMODEM], and DSL Access Interactive Network Adapters (INAs) [EUROMODEM], and DSL Access
Concentrators. Concentrators.
The DHCPLEASEQUERY message is an optional extension to the DHCP The DHCPLEASEQUERY message is an extension to the DHCP protocol [RFC
protocol [RFC 2131]. 2131].
The DHCPLEASEQUERY message is a query message only, and does not The DHCPLEASEQUERY message is a query message only, and does not
affect the state of the IP address or the binding information affect the state of the IP address or the binding information
associated with it. associated with it.
4. Design Goals 4. Design Goals
The goal of this document is to provide a lightweight mechanism for The goal of this document is to provide a lightweight mechanism for
processes or devices to access information contained in the DHCP processes or devices to access information contained in the DHCP
server. It is designed to allow processes and devices which already server. It is designed to allow processes and devices which already
skipping to change at page 8, line 39 skipping to change at page 9, line 9
However, the location information is usually unavailable after the However, the location information is usually unavailable after the
reboot or replacement of the access concentrator. reboot or replacement of the access concentrator.
Suppose the access concentrator is a router, and further suppose that Suppose the access concentrator is a router, and further suppose that
the router receives an IP datagram to forward downstream to the the router receives an IP datagram to forward downstream to the
public broadband access network. If the location information for the public broadband access network. If the location information for the
downstream next hop is missing, the access concentrator sends one or downstream next hop is missing, the access concentrator sends one or
more DHCPLEASEQUERY message(s), each containing the IP address of the more DHCPLEASEQUERY message(s), each containing the IP address of the
downstream next hop in the "ciaddr" field. downstream next hop in the "ciaddr" field.
This query will then be answered by, returning the information
current when this client's lease was last granted or renewed,
allowing the access concentrator to forward the IP datagram.
An alternative approach is to send in a DHCPLEASEQUERY message with An alternative approach is to send in a DHCPLEASEQUERY message with
the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen", the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen",
and "chaddr" fields) with a valid MAC address or a Client-identifier and "chaddr" fields) with a valid MAC address or a Client-identifier
option (option 61) appearing in the options area. In this case, the option (option 61) appearing in the options area. In this case, the
DHCP server SHOULD return an IP address in the "ciaddr" if it has any DHCP server must return an IP address in the "ciaddr" if it has any
record of the client described by the Client-identifier or MAC record of the client described by the Client-identifier or MAC
address. In the absence of specific configuration information to the address. In the absence of specific configuration information to the
contrary (see Section 6.4) it MUST be the IP address most recently contrary (see Section 6.4) it should 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 DHCPLEASEKNOWN, to the DHCPLEASEQUERY message: either a DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE or DHCPLEASEUNKNOWN (or in some cases, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN (or in some cases,
DHCPUNIMPLEMENTED). The reasons why a DHCPLEASEKNOWN, DHCPLEASEACTIVE DHCPUNIMPLEMENTED). The reasons why a DHCPLEASEUNASSIGNED,
or DHCPLEASEUNKNOWN message might be generated are explained in the DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message might be generated are
specific query regimes, below. explained in the specific query regimes, below.
Servers which do not implement the DHCPLEASEQUERY message fall into Servers which do not implement the DHCPLEASEQUERY message fall into
two classes. Those that simply do not know about the DHCPLEASEQUERY two classes. Those that simply do not know about the DHCPLEASEQUERY
message will simply not respond to it, so clients which send the message will simply not respond to it, so clients which send the
DHCPLEASEQUERY message MUST be prepared to deal with this behavior. DHCPLEASEQUERY message must be prepared to deal with this behavior.
Servers which are aware of the DHCPLEASEQUERY message but do not Servers which are aware of the DHCPLEASEQUERY message but do not
implement it SHOULD respond with a DHCPUNIMPLEMENTED message but MAY implement it should respond with a DHCPUNIMPLEMENTED message but may
simply not respond. simply not respond.
The DHCPLEASEQUERY message can support three query regimes: The DHCPLEASEQUERY message can support three query regimes: A server
which implements the DHCPLEASEQUERY message must implement all three
query regimes.
o Query by IP address: o Query by IP address:
For this query, the requester supplies only an IP address in the For this query, the requester supplies only an IP address in the
DHCPLEASEQUERY message. The DHCP server will return any DHCPLEASEQUERY message. The DHCP server will return any
information that it has on the most recent client to have been information that it has on the most recent client to have been
assigned that IP address. assigned that IP address.
The DHCP server replies with a DHCPLEASEKNOWN or DHCPLEASEACTIVE The DHCP server replies with a DHCPLEASEUNASSIGNED or
message if the IP address in the DHCPLEASEQUERY message DHCPLEASEACTIVE message if the IP address in the DHCPLEASEQUERY
corresponds to an IP address about which the server has message corresponds to an IP address about which the server has
definitive information (ie., it is authorized to lease this IP definitive information (ie., it is authorized to lease this IP
address). The server replies with a DHCPLEASEUNKNOWN message if address). The server replies with a DHCPLEASEUNKNOWN message if
the server does not have definitive information concerning the the server does not have definitive information concerning the
address in the DHCPLEASEQUERY message. address in the DHCPLEASEQUERY message.
A server which implements the DHCPLEASEQUERY message MUST
implement this capability.
o Query by MAC address: o Query by MAC address:
For this query, the requester supplies only a MAC address in the For this query, the requester supplies only a MAC address in the
DHCPLEASEQUERY message. The DHCP server will return any DHCPLEASEQUERY message. The DHCP server will return any
information that it has on the IP address most recently accessed information that it has on the IP address most recently accessed
by a client with that MAC address. In addition, it may supply by a client with that MAC address. In addition, it may supply
addition IP addresses which have been associated with that MAC addition IP addresses which have been associated with that MAC
address in different subnets. Information about these bindings address in different subnets. Information about these bindings
can then be found using the Query by IP Address, described can then be found using the Query by IP Address, described
above. above.
The DHCP server replies with a DHCPLEASEACTIVE message if the The DHCP server replies with a DHCPLEASEACTIVE message if the
MAC address in the DHCPLEASEQUERY message corresponds to an MAC MAC address in the DHCPLEASEQUERY message corresponds to a MAC
address with an active lease on an IP address in this server. address with an active lease on an IP address in this server.
The server replies with a DHCPLEASEUNKNOWN message if the server The server replies with a DHCPLEASEUNKNOWN message if the server
does not presently have an active lease by a client with this does not presently have an active lease by a client with this
MAC address in this DHCP server. MAC address in this DHCP server.
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 requester supplies only a client-id option For this query, the requester supplies only a Client-identifier
in the DHCPLEASEQUERY message. The DHCP server will return any option in the DHCPLEASEQUERY message. The DHCP server will
information that it has on the IP address most recently accessed return any information that it has on the IP address most
by a client with that client-id. In addition, it may supply recently accessed by a client with that Client-identifier. In
addition IP addresses which have been associated with client-id addition, it may supply additional IP addresses which have been
in different subnets. Information about these bindings can then associated with Client-identifier in different subnets.
be found using the Query by IP Address, described above. Information about these bindings can then be found using the
Query by IP Address, described above.
The DHCP server replies with a DHCPLEASEACTIVE message if the The DHCP server replies with a DHCPLEASEACTIVE message if the
client-id in the DHCPLEASEQUERY message currently has an active Client-identifier in the DHCPLEASEQUERY message currently has an
lease on an IP address in this DHCP server. The server replies active lease on an IP address in this DHCP server. The server
with a DHCPLEASEUNKNOWN message if the server does not have an replies with a DHCPLEASEUNKNOWN message if the server does not
active lease by a client with this client-id. have an active lease by a client with this Client-identifier.
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
Client-identifier option address.
Generally, the query by IP address is likely to be the most efficient For many DHCP servers, the query by IP address is likely to be the
and widely implemented form of leasequery, and it SHOULD be used if most efficient form of leasequery. This is the form of
at all possible. Use of the other two query formats SHOULD be DHCPLEASEQUERY that should be used if possible.
minimized, as they can potentially place a large load on some
servers.
The DHCPLEASEKNOWN or DHCPLEASEACTIVE message reply MUST always The DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message reply must always
contain the IP address in the ciaddr field. The DHCPLEASEACTIVE contain the IP address in the ciaddr field. The DHCPLEASEACTIVE
message SHOULD contains the physical address of the IP address lease message should contains the physical address of the IP address lease
owner in the "htype", "hlen", and "chaddr" fields. The Parameter owner in the "htype", "hlen", and "chaddr" fields. The Parameter
Request List (option 55) can be used to request specific options to Request List (option 55) can be used to request specific options to
be returned about the IP address in the ciaddr. The reply often be returned about the IP address in the ciaddr. The reply often
contains the time until expiration of the lease, and the original contains the time until expiration of the lease, and the original
contents of the Relay Agent Information option [RFC 3046]. The contents of the Relay Agent Information option [RFC 3046]. The
access concentrator uses the "chaddr" and Relay Agent Information access concentrator uses the "chaddr" and Relay Agent Information
option to construct location information, which can be cached on the option to construct location information, which can be cached on the
access concentrator until lease expiration. access concentrator until lease expiration.
Any DHCP server which supports the DHCPLEASEQUERY message SHOULD save Any DHCP server 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
(option 82) [RFC 3046] associated with every IP address which it (option 82) [RFC 3046] associated with every IP address which it
serves. It is assumed that most clients which generate the serves. It is assumed that most clients which generate the
DHCPLEASEQUERY message will ask for the Relay Agent Information DHCPLEASEQUERY message will ask for the Relay Agent Information
option (option 82) in the Parameter Request List (option 55), and so option (option 82) in the Parameter Request List (option 55), and so
supporting the DHCPLEASEQUERY message without having the Relay Agent supporting the DHCPLEASEQUERY message without having the Relay Agent
Information option around to return to the client is likely to be Information option around to return to the client is likely to be
less than helpful. less than helpful.
A server which implements DHCPLEASEQUERY SHOULD also save the A server which implements DHCPLEASEQUERY should also save the
information on the most recent Vendor class identifier, option 60, information on the most recent Vendor class identifier, option 60,
associated with each IP address, since this option is also a likely associated with each IP address, since this option is also a likely
candidate to be requested by clients sending the DHCPLEASEQUERY candidate to be requested by clients sending the DHCPLEASEQUERY
message. 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: one for the DHCPLEASEQUERY message itself and five new values: one for the DHCPLEASEQUERY message itself and
and one for each of its four possible responses DHCPLEASEKNOWN, and one for each of its four possible responses
DHCPLEASEACTIVE, DHCPLEASEUNKNOWN, and DHCPUNIMPLEMENTED. The DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, DHCPLEASEUNKNOWN, and
values of these message types are shown below in a reproduction DHCPUNIMPLEMENTED. The values of these message types are shown
of the table from [RFC 2132]: 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 DHCPLEASEKNOWN TBD DHCPLEASEUNASSIGNED
TBD DHCPLEASEUNKNOWN TBD DHCPLEASEUNKNOWN
TBD DHCPLEASEACTIVE TBD DHCPLEASEACTIVE
TBD DHCPUNIMPLEMENTED TBD DHCPUNIMPLEMENTED
2. There is a new option, the client-last-transaction-time: 2. There is a new option, the client-last-transaction-time:
client-last-transaction-time client-last-transaction-time
This option allows the receiver to determine the time of the This option allows the receiver to determine the time of the
most recent access of the client. It is particularly useful most recent access of the client. It is particularly useful
skipping to change at page 13, line 38 skipping to change at page 13, line 38
The DHCPLEASEQUERY message is typically sent by an access The DHCPLEASEQUERY message is typically sent by an access
concentrator. The DHCPLEASEQUERY message uses the DHCP message concentrator. The DHCPLEASEQUERY message uses the DHCP message
format as described in [RFC 2131], and uses message number TBD in the format as described in [RFC 2131], and uses message number TBD in the
DHCP Message Type option (option 53). The DHCPLEASEQUERY message has DHCP Message Type option (option 53). The DHCPLEASEQUERY message has
the following pertinent message contents: the following pertinent message contents:
o The giaddr MUST be set to the IP address of the requester (i.e. o The giaddr MUST be set to the IP address of the requester (i.e.
the access concentrator). The giaddr is independent of the the access concentrator). The giaddr is independent of the
"ciaddr" field to be searched -- it is simply the return address "ciaddr" field to be searched -- it is simply the return address
of for the DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN of for the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or
message from the DHCP server. DHCPLEASEUNKNOWN message from the DHCP server.
Note that this use of the giaddr is consistent with the
definition of giaddr in [RFC2131], where the giaddr is always
used as the return address of the DHCP response message. In
some (but not all) contexts in RFC2131 the giaddr is used as the
"key" to access the appropriate address pool. The
DHCPLEASEQUERY message is one of those cases where the giaddr
MUST NOT be used as such a "key".
o The Parameter Request List option (option 55) SHOULD be set to o The Parameter Request List option (option 55) SHOULD be set to
the options of interest to the requester. The interesting the options of interest to the requester. The interesting
options are likely to include the IP Address Lease Time option options are likely to include the IP Address Lease Time option
(option 51), the Relay Agent Information option (option 82) and (option 51), the Relay Agent Information option (option 82) and
possibly the Vendor class identifier option (option 60). In the possibly the Vendor class identifier option (option 60). In the
absence of a Parameter Request List option, the server will absence of a Parameter Request List option, the server SHOULD
return the same options it would return for a DHCPREQUEST return the same options it would return for a DHCPREQUEST
message which didn't contain a DHCPLEASEQUERY message, which message which didn't contain a DHCPLEASEQUERY message, which
includes those mandated by [RFC 2131, Section 4.3.1] as well as includes those mandated by [RFC 2131, Section 4.3.1] as well as
any options which the server was configured to always return to any options which the server was configured to always return to
a client. a client.
Additional details concerning different query types are: Additional details concerning different query types are:
o Query by IP address: o Query by IP address:
skipping to change at page 14, line 51 skipping to change at page 15, line 11
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 server which implements the DHCPLEASEQUERY message MUST implement
all three query regimes, query by IP address, query by MAC address,
and query by Client-identifier.
A DHCPLEASEQUERY message MUST have a non-zero giaddr. The A DHCPLEASEQUERY message MUST have a non-zero giaddr. The
DHCPLEASEQUERY message MUST have exactly one of: a non-zero ciaddr, DHCPLEASEQUERY message MUST have exactly one of: a non-zero ciaddr,
a non-zero "htype"/"hlen"/"chaddr", or a Client-identifier. a non-zero "htype"/"hlen"/"chaddr", or a Client-identifier option.
The DHCP server which receives a DHCPLEASEQUERY message MUST base its The DHCP server 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. It MUST NOT be used to response to the DHCPLEASEQUERY message. It MUST NOT be used to
restrict the processing of the query in any way, and MUST NOT be used restrict the processing of the query in any way, and MUST NOT be used
locate a subnet to which the ciaddr (if any) must belong. locate a subnet to which the ciaddr (if any) must belong.
Note that this use of the giaddr is consistent with the definition of
giaddr in [RFC2131], where the giaddr is always used as the return
address of the DHCP response message. In some (but not all) contexts
in RFC2131 the giaddr is used as the "key" to access the appropriate
address pool. The DHCPLEASEQUERY message is one of those cases where
the giaddr MUST NOT be used as such a "key".
6.4. Responding to the DHCPLEASEQUERY Message 6.4. Responding to the DHCPLEASEQUERY Message
There are four possible responses to a DHCPLEASEQUERY message: There are four possible responses to a DHCPLEASEQUERY message:
o DHCPLEASEKNOWN o DHCPLEASEUNASSIGNED
The server MUST respond with a DHCPLEASEKNOWN message if this The server MUST respond with a DHCPLEASEUNASSIGNED message if
server has information about the IP address, but there is no this server has information about the IP address, but there is
active lease for the IP address. The DHCPLEASEKNOWN message is no active lease for the IP address. The DHCPLEASEUNASSIGNED
only returned for a query by IP address, and indicates that the message is only returned for a query by IP address, and
server manages this IP address but there is no currently active indicates that the server manages this IP address but there is
lease on this IP address. no currently active lease on this IP address.
o DHCPLEASEUNKNOWN o DHCPLEASEUNKNOWN
The DHCPLEASEUNKNOWN message indicates that the server does not The DHCPLEASEUNKNOWN message indicates that the server does not
manage the IP address or the client specified in the manage the IP address or the client specified in the
DHCPLEASEQUERY message does not currently have a lease on an IP DHCPLEASEQUERY message does not currently have a lease on an IP
address. address.
When responding with a DHCPLEASEUNKNOWN, the DHCP server SHOULD When responding with a DHCPLEASEUNKNOWN, the DHCP server MUST
NOT include other DHCP options in the response. NOT include other DHCP options in the response.
o DHCPLEASEACTIVE o DHCPLEASEACTIVE
The DHCPLEASEACTIVE message indicates that the server not only The DHCPLEASEACTIVE message indicates that the server not only
knows about the IP address and client specified in the knows about the IP address and client specified in the
DHCPLEASEACTIVE message but also that there is an active lease DHCPLEASEACTIVE message but also that there is an active lease
by that client for that IP address. by that client for that IP address.
The server MUST respond with a DHCPLEASEACTIVE message when the The server MUST respond with a DHCPLEASEACTIVE message when the
IP address returned in the "ciaddr" field is currently leased. IP address returned in the "ciaddr" field is currently leased.
o DHCPUNIMPLEMENTED o DHCPUNIMPLEMENTED
The DHCPUNIMPLEMENTED response to the DHCPLEASEQUERY message The DHCPUNIMPLEMENTED response to the DHCPLEASEQUERY message
indicates that the particular form of DHCPLEASEQUERY used is not indicates that DHCPLEASEQUERY is not implemented by this DHCP
implemented in this DHCP server. It may mean that the server.
DHCPLEASEQUERY message as a whole is not implemented by this
DHCP server although it is usually used to 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.
The DHCPUNIMPLEMENTED message can apply to any unimplemented The DHCPUNIMPLEMENTED message can apply to any unimplemented
messages, and MAY be used to respond to messages other than messages, and MAY be used to respond to messages other than
DHCPLEASEQUERY. DHCPLEASEQUERY.
6.4.1. Determining the IP address to which to respond 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 must also be returned in the addresses for which a client has a lease must also be returned in the
associated-ip option (Section 6.1, #4). This is the only information associated-ip option (Section 6.1, #4). This is the only information
returned not directly associated with the IP address in the "ciaddr" returned not directly associated with the IP address in the "ciaddr"
field. field.
In the event that an IP address appears in the "ciaddr" field of a In the event that an IP address appears in the "ciaddr" field of a
DHCPLEASEQUERY message, if that IP address is one managed by the DHCP DHCPLEASEQUERY message, if that IP address is one managed by the DHCP
server, then that IP address MUST be set in the "ciaddr" field of a server, then that IP address MUST be set in the "ciaddr" field of a
DHCPLEASEKNOWN message. DHCPLEASEUNASSIGNED message.
If the IP address is not managed by the DHCP server, then a If the IP address is not managed by the DHCP server, then a
DHCPLEASEUNKNOWN message must be returned. DHCPLEASEUNKNOWN message must be returned.
If the "ciaddr" field of the DHCPLEASEQUERY is zero, then the If the "ciaddr" field of the DHCPLEASEQUERY is zero, then the
DHCPLEASEQUERY message is a query by Client-identifier or MAC DHCPLEASEQUERY message is a query by Client-identifier or MAC
address. In this case, the client's identity is any client which has address. In this case, the client's identity is any client 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 identical MAC address (if the MAC address fields in the
skipping to change at page 17, line 14 skipping to change at page 17, line 29
message. message.
In the case where more than one IP address has been accessed by the In the case where more than one IP address has been accessed by the
client specified by the MAC address or Client-identifier option, then client specified by the MAC address or Client-identifier option, then
the DHCP server MUST return the IP address returned to the client in the DHCP server MUST return the IP address returned to the client in
the most recent transaction with the client unless the DHCP server the most recent transaction with the client unless the DHCP server
has been configured by the server administrator to use some other has been configured by the server administrator to use some other
preference mechanism. preference mechanism.
If, after all of the above processing, no value is set in the If, after all of the above processing, no value is set in the
"ciaddr" field of the DHCPLEASEKNOWN or DHCPLEASEACTIVE message, then "ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message,
a DHCPLEASEUNKNOWN message MUST be returned instead. then a DHCPLEASEUNKNOWN message MUST be returned instead.
6.4.2. Building a DHCPLEASEKNOWN or DHCPLEASEACTIVE message once the 6.4.2. Building a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message once
"ciaddr" field is set the "ciaddr" field is set
Once the "ciaddr" field of the DHCPLEASEKNOWN or DHCPLEASEACTIVE Once the "ciaddr" field of the DHCPLEASEUNASSIGNED is set, the
message is set, the processing for a DHCPLEASEKNOWN message is processing for a DHCPLEASEUNASSIGNED message is complete.
complete.
For the DHCPLEASEACTIVE message, the rest of the processing largely For the DHCPLEASEACTIVE message, the rest of the processing largely
involves returning information about the IP address specified in the involves returning information about the IP address specified in the
"ciaddr" field. "ciaddr" field.
The IP address in the "ciaddr" field of the DHCPLEASEKNOWN or The IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED or
DHCPLEASEACTIVE message MUST be one for which this server is DHCPLEASEACTIVE message MUST be one for which this server is
responsible (or a DHCPLEASEUNKNOWN message would be have already been responsible (or a DHCPLEASEUNKNOWN message would be have already been
returned early in the processing described in the previous section). returned early in the processing described in the previous section).
The MAC address of the DHCPLEASEACTIVE message MUST be set to the The MAC address of the DHCPLEASEACTIVE message MUST be set to the
values which identify the client associated with the IP address in values which identify the client associated with the IP address in
the "ciaddr" field of the DHCPLEASEKNOWN message. the "ciaddr" field of the DHCPLEASEUNASSIGNED message.
If the Client-identifier option (option 61) is specified in the If the Client-identifier option (option 61) is specified in the
Parameter Request List option (option 55), then the Client-identifier Parameter Request List option (option 55), then the Client-identifier
(if any) of the client associated with the IP address in the "ciaddr" (if any) of the client associated with the IP address in the "ciaddr"
field SHOULD be returned in the DHCPLEASEACTIVE message. field SHOULD be returned in the DHCPLEASEACTIVE message.
In the case where more than one IP address has been involved in a In the case where more than one IP address has been involved in a
DHCP message exchange with the client specified by the MAC address DHCP message exchange with the client specified by the MAC address
and/or Client-identifier option, then the list of all of the IP and/or Client-identifier option, then the list of all of the IP
addresses SHOULD be returned in the associated-ip option (option addresses SHOULD be returned in the associated-ip option (option
skipping to change at page 18, line 20 skipping to change at page 18, line 34
(T2) Time Value option in the Parameter Request List of the (T2) Time Value option in the Parameter Request List of the
DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time
option is handled. If there is a valid lease and these times are not option is handled. If there is a valid lease and these times are not
yet in the past, then the DHCP server SHOULD return these options yet in the past, then the DHCP server SHOULD return these options
(when requested) with the remaining time until renewal or rebinding, (when requested) with the remaining time until renewal or rebinding,
respectively. If these times are already in the past, or if there is respectively. If these times are already in the past, or if there is
not currently a valid lease for this IP address, the DHCP server MUST not currently a valid lease for this IP address, the DHCP server MUST
NOT return these options. NOT return these options.
If the Relay Agent Information (option 82) is specified in the If the Relay Agent Information (option 82) is specified in the
Parameter Request List and if the DHCP server has saved the Parameter Request List then the information contained in the most
information contained in the most recent Relay Agent Information recent Relay Agent Information option received from the relay agent
option, the DHCP server MUST include that information in a Relay associated with this IP address MUST be included in the
Agent Information option in the DHCPLEASEACTIVE message. DHCPLEASEACTIVE message. The DHCP server MUST the Relay Agent
Information option that was received when from the relay agent
associated with this IP address.
The DHCPLEASEACTIVE message SHOULD include the values of all other The DHCPLEASEACTIVE message SHOULD include the values of all other
options not specifically discussed above that were requested in the options not specifically discussed above that were requested in the
Parameter Request List of the DHCPLEASEQUERY message. The DHCP Parameter Request List of the DHCPLEASEQUERY message. The DHCP
server uses information from its lease binding database to supply the server uses information from its lease binding database to supply the
DHCPLEASEACTIVE option values. The values of the options that were DHCPLEASEACTIVE option values. The values of the options that were
returned to the DHCP client would generally be preferred, but in the returned to the DHCP client would generally be preferred, but in the
absence of those, options that were sent in DHCP client requests absence of those, options that were sent in DHCP client requests
would be acceptable. would be acceptable.
In order to accommodate DHCPLEASEQUERY messages sent to a DHCP In some cases, the Relay Agent Information option in an incoming
Failover secondary server [FAILOVER] when the primary server is down, DHCPREQUEST packet is used to help determine the options returned to
the primary server MUST communicate the Relay Agent Information the DHCP client which sent the DHCPREQUEST. When responding to a
option (option 82) values to the secondary server via the DHCP DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay
Failover BNDUPD messages. Agent Information option just like it did when responding to the DHCP
client in order to determine the values of any options requested by
the DHCPLEASEQUERY message. The goal is to return the same option
values to the DHCPLEASEQUERY as those that were returned to the
DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise
specified, above).
6.4.3. Sending a DHCPLEASEKNOWN, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN In the event that two servers are cooperating to provide a high
message availability DHCP server, as supported by [RFC2131], they would have
to communicate some information about IP address bindings to each
other. In order to properly support the DHCPLEASEQUERY message,
these servers MUST ensure that they communicate the Relay Agent
Information option information to each other in addition to any other
IP address binding information.
6.4.3. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN message
The server expects a giaddr in the DHCPLEASEQUERY message, and The server expects a giaddr in the DHCPLEASEQUERY message, and
unicasts the DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN unicasts the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN
message to the giaddr. If the giaddr field is zero, then the DHCP message to the giaddr. If the giaddr field is zero, then the DHCP
server MUST NOT reply to the DHCPLEASEQUERY message. server MUST NOT reply to the DHCPLEASEQUERY message.
6.5. Receiving a DHCPLEASEKNOWN, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN 6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
Message DHCPLEASEUNKNOWN Message
When a DHCPLEASEACTIVE message is received in response to the When a DHCPLEASEACTIVE message is received in response to the
DHCPLEASEQUERY message it means that there is a currently active DHCPLEASEQUERY message it means that there is a currently active
lease for this IP address in this DHCP server. The access lease for this IP address in this DHCP server. The access
concentrator SHOULD use the information in the htype, hlen, and concentrator SHOULD use the information in the htype, hlen, and
chaddr fields of the DHCPLEASEACTIVE as well as any Relay Agent chaddr fields of the DHCPLEASEACTIVE as well as any Relay Agent
Information option information included in the packet to refresh its Information option information included in the packet to refresh its
location information for this IP address. location information for this IP address.
When a DHCPLEASEKNOWN message is received in response to the When a DHCPLEASEUNASSIGNED message is received in response to the
DHCPLEASEQUERY message that means that there is no currently active DHCPLEASEQUERY message that means that there is no currently active
lease for the IP address present in the DHCP server, but that this lease for the IP address present in the DHCP server, but that this
server does in fact manage that IP address. In this case, the access server does in fact manage that IP address. In this case, the access
concentrator SHOULD cache this information in order to prevent concentrator SHOULD cache this information in order to prevent
unacceptable loads on the access concentrator and the DHCP server in unacceptable loads on the access concentrator and the DHCP server in
the face of a malicious or seriously compromised device downstream of the face of a malicious or seriously compromised device downstream of
the access concentrator. This cacheing could be as simple as simply the access concentrator. This caching could be as simple as simply
setting a bit saying that a response was received from a server which setting a bit saying that a response was received from a server which
knew about this IP address but that there was no current lease. This knew about this IP address but that there was no current lease. This
would of course need to be cleared when the access concentrator next would of course need to be cleared when the access concentrator next
"gleaned" that a lease for this IP address came into existance. "gleaned" that a lease for this IP address came into existence.
In either case, when a DHCPLEASEKNOWN or DHCPLEASEACTIVE message is In either case, when a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message
received in response to a DHCPLEASEQUERY message, it means that the is received in response to a DHCPLEASEQUERY message, it means that
DHCP server which responded is a DHCP server which manages the IP 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 address present in the ciaddr, and the Relay Agent SHOULD cache this
information for later use. information for later use.
When a DHCPLEASEUNKNOWN message is received by an access concentrator When a DHCPLEASEUNKNOWN message is received by an access concentrator
which has sent out a DHCPLEASEQUERY message, it means that the DHCP 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 does not have definitive information concerning the IP DHCP server does not have definitive information concerning the IP
address contained in the "ciaddr" field of the DHCPLEASEQUERY address contained in the "ciaddr" field of the DHCPLEASEQUERY
message. If there is no IP address in the "ciaddr" field of the message. If there is no IP address in the "ciaddr" field of the
DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means that DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means that
the DHCP server does not have definitive information concerning the the DHCP server does not have definitive information concerning the
any DHCP client specified in the "hlen", "htype", and "chaddr" fields any DHCP client specified in the "hlen", "htype", and "chaddr" fields
or the Client-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, but only for a
relatively short lifetime, approximately 5 minutes.
Having cached this information, the access concentrator SHOULD only
infrequently direct a DHCPLEASEQUERY message to a DHCP server that infrequently direct a DHCPLEASEQUERY message to a DHCP server that
responded to a DHCPLEASEQUERY message for a particular "ciaddr" field responded to a DHCPLEASEQUERY message for a particular "ciaddr" field
with a DHCPLEASEUNKNOWN. with a DHCPLEASEUNKNOWN.
When a DHCPUNIMPLEMENTED message is received by an access When a DHCPUNIMPLEMENTED message is received by an access
concentrator, it means that the particular aspect of DHCPLEASEQUERY concentrator, it means that DHCPLEASEQUERY processing is not
processing requested is not implemented in the responding server. It implemented in the responding server. This information SHOULD be
may or may not be the case that other aspects of DHCPLEASEQUERY cached may not be the case that other aspects of DHCPLEASEQUERY
processing are not implemented in that server. processing are 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 DHCPLEASEKNOWN, o The DHCPLEASEQUERY or a corresponding DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE or DHCPLEASEUNKNOWN were lost during DHCPLEASEACTIVE or DHCPLEASEUNKNOWN were lost during
transmission or the DHCPLEASEQUERY arrived at the DHCP server transmission or the DHCPLEASEQUERY arrived at the DHCP server
but it was dropped because the server was too busy. but it was dropped because the server was too busy.
o The DHCP server doesn't support DHCPLEASEQUERY. o The DHCP server doesn't support DHCPLEASEQUERY.
In the first of the cases above, a retransmission of the In the first of the cases above, a retransmission of the
DHCPLEASEQUERY would be appropriate, but in the second of the two DHCPLEASEQUERY would be appropriate, but in the second of the two
cases, a retransmission would not be appropriate. There is no way to cases, a retransmission would not be appropriate. There is no way to
tell these two cases apart (other than, perhaps, because of a DHCP tell these two cases apart (other than, perhaps, because of a DHCP
skipping to change at page 20, line 42 skipping to change at page 21, line 24
send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per 70 send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per 70
seconds. seconds.
In practice this approach would probably best be handled by a per- In practice this approach would probably best be handled by a per-
server timer that is restarted whenever a response to a server timer that is restarted whenever a response to a
DHCPLEASEQUERY message is received, and expires after one minute. DHCPLEASEQUERY message is received, and expires after one minute.
The per-server timer would start off expired, and in the expired The per-server timer would start off expired, and in the expired
state only one DHCPLEASEQUERY message would be queued for the state only one DHCPLEASEQUERY message would be queued for the
associated server. associated server.
All DHCPLEASEQUERY messages SHOULD use the exponetial backoff All DHCPLEASEQUERY messages SHOULD use the exponential backoff
algorithm specified in RFC 2131, section 4.1 [RFC 2131]. algorithm specified in RFC 2131, section 4.1 [RFC 2131].
Thus, in the initial state, the per-server timer is expired, and a Thus, in the initial state, the per-server timer is expired, and a
single DHCPLEASEQUERY message is queued for each server. After the single DHCPLEASEQUERY message is queued for each server. After the
first response to a DHCPLEASEQUERY message, the per-server timer is first response to a DHCPLEASEQUERY message, the per-server timer is
started. At that time, multiple DHCPLEASEQUERY message can be sent started. At that time, multiple DHCPLEASEQUERY message can be sent
in parallel to the DHCP server, though the total number SHOULD be in parallel to the DHCP server, though the total number SHOULD be
limited to 100 or 200, to avoid swamping the DHCP server. Each of limited to 100 or 200, to avoid swamping the DHCP server. Each of
these messages uses the RFC 2131 exponential backoff algorithm. these messages uses the RFC 2131 exponential backoff algorithm.
Every time a response to any of these messages is received, the per- Every time a response to any of these messages is received, the per-
server timer is reset and starts counting again up to one minute. In server timer is reset and starts counting again up to one minute. In
the event the per-server timer goes off, then all outstanding the event the per-server timer goes off, then all outstanding
messages SHOULD be dropped except for a single DHCPLEASEQUERY message messages SHOULD be dropped except for a single DHCPLEASEQUERY message
which is used to poll the server at approximately 64 second intervals which is used to poll the server at approximately 64 second intervals
until such time as another (or the first) response to the until such time as another (or the first) response to the
DHCPLEASEQUERY is received. DHCPLEASEQUERY is received.
In the event that there is no DHCPLEASEQUERY traffic for one minute, In the event that there is no DHCPLEASEQUERY traffic for one minute,
then the per-server timer will expire. After that time, there will then the per-server timer will expire. After that time, there will
only be one DHCPLEASEQUERY message allowed to be outstanding to that only be one DHCPLEASEQUERY message allowed to be outstanding to that
server until a response to that message is recieved. server until a response to that message is received.
6.7. Using the DHCPLEASEQUERY message with multiple DHCP servers 6.7. Lease binding data storage requirements
DHCP server implementations that implement the DHCPLEASEQUERY
capability MUST save the most recent Relay Agent Information option
from the most recent DHCPREQUEST packet for two reasons. First, it
is almost certain to be requested by in the dhcp-parameter-request-
list option in any DHCPLEASEQUERY request. Second, the saved Relay
Agent Information option may be necessary to determine the value of
other options given to the DHCP client, if these are requested by the
dhcp-parameter-request list in the DHCPLEASEQUERY request.
Some of the clients of the DHCPLEASEQUERY capability will also
request the vendor-class-id of in the dhcp-parameter-request list,
and so a DHCP server SHOULD save that option in the lease binding
data storage.
These data storage requirements are minimally larger than those
required for normal operation of the DHCP protocol, as required to
properly implement [RFC2131].
6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers
When using the DHCPLEASEQUERY message in an environment where When using the DHCPLEASEQUERY message in an environment where
multiple DHCP servers may contain authoritative information about the multiple DHCP servers may contain authoritative information about the
same IP address (such as when failover [FAILOVER] is operating), same IP address (such as when two DHCP servers are cooperating to
multiple, possibly conflicting, responses might be received. provide a high availability DHCP service) multiple, possibly
conflicting, responses might be received.
In this case, some information in the response packet SHOULD be used In this case, some information in the response packet SHOULD be used
to decide among the various responses. The client-last-transaction- to decide among the various responses. The client-last-transaction-
time (if it is available) can be used to decide which server has more time (if it is available) can be used to decide which server has more
recent information concerning the IP address returned in the "ciaddr" recent information concerning the IP address returned in the "ciaddr"
field. field.
7. Security Considerations 7. Security Considerations
Access concentrators that use DHCP gleaning, refreshed with Access concentrators that use DHCP gleaning, refreshed with
skipping to change at page 21, line 47 skipping to change at page 22, line 51
only be decrypted by the intended access modem (e.g. [BPI] and only be decrypted by the intended access modem (e.g. [BPI] and
[BPI+]). As a result, the access concentrator does not need to [BPI+]). As a result, the access concentrator does not need to
depend on ARP broadcasts across the access network, which is depend on ARP broadcasts across the access network, which is
susceptible to malicious hosts which masquerade as the intended IP susceptible to malicious hosts which masquerade as the intended IP
endpoints. Thus, the DHCPLEASEQUERY message allows an access endpoints. Thus, the DHCPLEASEQUERY message allows an access
concentrator to provide considerably enhanced security. concentrator to provide considerably enhanced security.
DHCP servers SHOULD prevent exposure of location information DHCP servers SHOULD prevent exposure of location information
(particularly the mapping of hardware address to IP address lease, (particularly the mapping of hardware address to IP address lease,
which can be an invasion of broadband subscriber privacy) by which can be an invasion of broadband subscriber privacy) by
leveraging DHCP authentication [RFC 3118]. With respect to employing some form of relay agent authentication between the
authentication, the access concentrator acts as the "client". The DHCPLEASEQUERY client and the DHCP server.
use of "Authentication Protocol 0" (using simple unencoded
authentication token(s) between the access concentrator and the DHCP Clients of the DHCPLEASEQUERY message SHOULD ensure that their data
server) is straightforward. Alternatively, use of IPsec would also be path to the DHCP server is secure. Clients SHOULD use Relay Agent
a way to ensure security between the relay agent and the DHCP server. Information security as a way to achieve this goal. This will ensure
against the clients receiving false data, due perhaps to a third
party spoofing the reply from a DHCPLEASEQUERY message.
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 DHCPLEASEKNOWN, should employ negative caching (i.e. cache DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY
messages) and ciaddr restriction (i.e. don't send a DHCPLEASEQUERY messages) and ciaddr restriction (i.e. don't send a DHCPLEASEQUERY
message with a ciaddr outside of the range of the attached broadband message with a ciaddr outside of the range of the attached broadband
access networks). Together, these mechanisms limit the access access networks). Together, these mechanisms limit the access
concentrator to transmitting one DHCPLEASEQUERY message (excluding concentrator to transmitting one DHCPLEASEQUERY message (excluding
message retries) per legitimate broadband access network IP address message retries) per legitimate broadband access network IP address
after a reboot event. after a reboot event.
DHCP servers supporting the DHCPLEASEQUERY message SHOULD ensure that
they cannot be successfully attacked by being flooded with large
quantities of DHCPLEASEQUERY messages in a short time.
In some environments it may be appropriate to configure a DHCP server In some environments it may be appropriate to configure a DHCP server
with the IP addresses of the relay agents for which it may respond to with the IP addresses of the relay agents for which it may respond to
DHCPLEASEQUERY messages, thereby allowing it to respond only to to DHCPLEASEQUERY messages, thereby allowing it to respond only to to
requests from only a handful of relay agents. This does not provide requests from only a handful of relay agents. This does not provide
any true security, but may be useful to thwart unsophisticated any true security, but may be useful to thwart unsophisticated
attacks of various sorts. attacks of various sorts.
8. IANA Considerations 8. IANA Considerations
IANA has assigned seven values for this document. See Section 6.1 for IANA has assigned seven values for this document. See Section 6.1 for
details. There are five new messages types, which are the value of details. There are five new messages types, which are the value of
the message type option (option 53) from [RFC 2132]. The value for the message type option (option 53) from [RFC 2132]. The value for
DHCPLEASEQUERY is TBD, the value for DHCPLEASEKNOWN is TBD, the value DHCPLEASEQUERY is TBD, the value for DHCPLEASEUNASSIGNED is TBD, the
for DHCPLEASEACTIVE is TBD, the value for DHCPLEASEUNKNOWN is TBD and value for DHCPLEASEACTIVE is TBD, the value for DHCPLEASEUNKNOWN is
the value for DHCPUNIMPLEMENTED is TBD. Finally, there are two new TBD and the value for DHCPUNIMPLEMENTED is TBD. Finally, there are
DHCP option defined; the client-last-transaction-time option -- two new DHCP option defined; the client-last-transaction-time option
option code TBD, and the associated-ip option -- option code TBD. -- 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 23, line 49 skipping to change at page 25, line 13
2002. 2002.
[DOCSIS] CableLabs, "Data-Over-Cable Service Interface [DOCSIS] CableLabs, "Data-Over-Cable Service Interface
Specifications: Cable Modem Radio Frequency Interface Specifications: Cable Modem Radio Frequency Interface
Specification SP-RFI-I05-991105", November 1999. Specification SP-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.,
Rabil, G., Dooley, M., Kapur, A., "DHCP Failover Protocol",
draft-ietf-dhc-failover-12.txt, March 2003.
11. Author's information 11. Author's information
Rich Woundy Rich Woundy
Comcast Cable Comcast Cable
27 Industrial Ave. 27 Industrial Ave.
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 244-4010 Phone: (978) 244-4010
EMail: richard_woundy@cable.comcast.com EMail: richard_woundy@cable.comcast.com
skipping to change at page 24, line 40 skipping to change at page 26, line 4
to the implementation or use of the technology described in this to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or 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 might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards- procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to 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 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 license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the implementors or users of this specification can be obtained from the
IETF Secretariat. IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive standard. Please address the information to the IETF Executive
Director. Director.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or 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/