draft-ietf-dhc-leasequery-08.txt   draft-ietf-dhc-leasequery-09.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
February 2005 October 2005
Expires August 2005 Expires April 2006
DHCP Lease Query DHCP Lease Query
<draft-ietf-dhc-leasequery-08.txt> <draft-ietf-dhc-leasequery-09.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
A DHCPv4 server contains considerable authoritative information A DHCPv4 server is the authoritative source of IP addresses that it
concerning the IP addresses it has leased to DHCP clients. Other has provided to DHCPv4 clients. Other processes and devices that
processes and devices, many that already send and receive DHCP format already make use of DHCPv4 may need to access this information. The
packets, sometimes need to access this information. The leasequery leasequery protocol provides these processes and devices a
protocol for DHCPv4 is designed to give these processes and devices a lightweight way to access IP address information.
lightweight way to access information that may be critical to their
operation.
Table of Contents Table of Contents
1. Introduction................................................. 2 1. Introduction................................................. 2
2. Terminology.................................................. 5 2. Terminology.................................................. 5
3. Background................................................... 6 3. Background................................................... 7
4. Design Goals................................................. 7 4. Design Goals................................................. 7
4.1. Broadcast ARP is Undesirable............................... 7 4.1. Broadcast ARP is Undesirable............................... 7
4.2. SNMP and LDAP Client Functionality is Lacking.............. 8 4.2. SNMP and LDAP Not Appropriate.............................. 8
4.3. DHCP Relay Agent Functionality is Common................... 8 4.3. DHCP Relay Agent Functionality is Common................... 8
4.4. DHCP Servers as a Reliable Source of Location Information.. 8 4.4. DHCP Servers as a Reliable Source of Location Information.. 9
4.5. Minimal Additional Configuration is Required............... 9 4.5. Minimal Additional Configuration is Required............... 9
5. Protocol Overview............................................ 9 5. Protocol Overview............................................ 9
6. Protocol Details............................................. 12 6. Protocol Details............................................. 12
6.1. Definitions required for DHCPLEASEQUERY processing......... 12 6.1. Definitions required for DHCPLEASEQUERY processing......... 12
6.2. Sending the DHCPLEASEQUERY Message......................... 13 6.2. Sending the DHCPLEASEQUERY Message......................... 14
6.3. Receiving the DHCPLEASEQUERY Message....................... 15 6.3. Receiving the DHCPLEASEQUERY Message....................... 15
6.4. Responding to the DHCPLEASEQUERY Message................... 16 6.4. Responding to the DHCPLEASEQUERY Message................... 16
6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or....... 20 6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or....... 20
6.6. Receiving no response to the DHCPLEASEQUERY Message........ 21 6.6. Receiving no response to the DHCPLEASEQUERY Message........ 21
6.7. Lease binding data storage requirements.................... 22 6.7. Lease binding data storage requirements.................... 22
6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 23 6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 23
7. Security Considerations...................................... 23 7. Security Considerations...................................... 23
8. IANA Considerations.......................................... 24 8. IANA Considerations.......................................... 24
9. Acknowledgments.............................................. 24 9. Acknowledgments.............................................. 24
10. References.................................................. 24 10. References.................................................. 25
10.1. Normative References...................................... 24 10.1. Normative References...................................... 25
10.2. Informative References.................................... 25 10.2. Informative References.................................... 25
11. Author's information........................................ 25 11. Author's information........................................ 26
12. Intellectual Property Statement............................. 26 12. Intellectual Property Statement............................. 26
13. Full Copyright Statement.................................... 26 13. Full Copyright Statement.................................... 27
1. Introduction 1. Introduction
A DHCPv4 server contains considerable authoritative information A DHCPv4 server contains considerable authoritative information
concerning the IP addresses it has leased to DHCP clients. Sometimes concerning the IP addresses it has leased to DHCP clients. Sometimes
devices or other processes may need access to this information. In devices or other processes may need access to this information. In
some cases, these devices or processes already have the capability to some cases, these devices or processes already have the capability to
send and receive DHCP packets, and so the leasequery protocol is send and receive DHCP packets, and so the leasequery protocol is
designed to give these processes and devices a low overhead way to designed to give these processes and devices a low overhead way to
access such information. access such information.
skipping to change at page 5, line 24 skipping to change at page 5, line 6
query (e.g., IP address, MAC address, or Client-identifier 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.
This document specifies an extension specifically to the DHCPv4 This document specifies an extension specifically to the DHCPv4
protocol [RFC2131]. protocol [RFC2131]. Given the nature of the DHCPv6 protocol [RFC
3315], there is no effective way to make the DHCPLEASEQUERY message
interaction common between DHCPv4 and DHCPv6 even should the desire
to do so exist.
The DHCPLEASEQUERY message was the result of a set of specific real-
world implementation needs that appeared many years after the DHCPv4
protocol was in wide use. Furthermore, at the time of this writing,
the DHCPv6 protocol has yet to be widely deployed. The needs of
access concentrators in yet to be determined DHCPv6 deployment
scenarios are difficult to estimate. If a DHCPLEASEQUERY-like
function is necessary in DHCPv6, many of the ideas of this document
will probably be applicable, while others may not. We have been
cautioned against designing protocol capabililties for which there is
only an imagined consumer, and that is all that exists today in the
realm of DHCPLEASEQUERY for DHCPv6.
Thus, this document applies only to DHCPv4, and for clarity we have
not appended DHCPv4 to every appearance of several common terms. In
this document all references to IP addresses should be taken to mean
IPv4 addresses, and all references to DHCP servers and DHCP clients
should be taken to mean DHCPv4 servers and DHCPv4 clients.
2. Terminology 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 8, line 4 skipping to change at page 8, line 8
reconstruct the location information. reconstruct the location information.
The ARP mechanism is undesirable for three reasons: The ARP mechanism is undesirable for three reasons:
1. the burden on the access concentrator to transmit over multiple 1. the burden on the access concentrator to transmit over multiple
access ports and virtual circuits (assuming that IP subnets access ports and virtual circuits (assuming that IP subnets
span multiple ports or virtual circuits), span multiple ports or virtual circuits),
2. the burden on the numerous subscriber hosts to receive and 2. the burden on the numerous subscriber hosts to receive and
process the broadcast, and process the broadcast, and
3. the ease by which a malicious host can misrepresent itself as 3. the ease by which a malicious host can misrepresent itself as
the IP endpoint. the IP endpoint.
4.2. SNMP and LDAP Client Functionality is Lacking 4.2. SNMP and LDAP Not Appropriate
Access concentrator implementations typically do not have SNMP Access concentrator implementations typically do not have SNMP
management client interfaces nor LDAP client interfaces (although management client interfaces nor LDAP client interfaces (although
they typically do include SNMP management agents). This is a primary they typically do include SNMP management agents). This is one
reason why this document does not leverage the proposed DHCP Server reason why this document does not leverage the proposed DHCP Server
MIB [DHCPMIB]. MIB [DHCPMIB].
The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering
and troubleshooting activities at large DHCP installations, and is
primarily intended as a method of gathering performance statistics
about servers the load presented to them.
Despite the presence in the proposed DHCPv4 server MIB of objects
that report configuration and status information, the MIB is intended
to provide more generic, server-wide aggregated or summarized data.
DHCPLEASEQUERY is intended to provide detailed, specific information
about individual leases at a level that would be difficult or
impossible to shoehorn into a MIB.
From an implementation standpoint, the DHCPLEASEQUERY message is not
required to be supported by all DHCPv4 servers. Since it appears
that defining optional MIB objects and objects for optional features
in a MIB is discouraged, trying to support DHCPLEASEQUERY
functionality optionally through a MIB would be similarly discouraged
from an SNMP MIB standpoint.
4.3. DHCP Relay Agent Functionality is Common 4.3. DHCP Relay Agent Functionality is Common
Access concentrators commonly act as DHCP relay agents. Furthermore, Access concentrators commonly act as DHCP relay agents. Furthermore,
many access concentrators already glean location information from many access concentrators already glean location information from
DHCP server responses, as part of the relay agent function. DHCP server responses, as part of the relay agent function.
The gleaning mechanism as a technique to determine the IP addresses The gleaning mechanism as a technique to determine the IP addresses
valid for a particular downstream link is preferred over other valid for a particular downstream link is preferred over other
mechanisms (ARP, SNMP, LDAP) because of the lack of additional mechanisms (ARP, SNMP, LDAP) because of the lack of additional
network traffic, but sometimes gleaning information can be network traffic, but sometimes gleaning information can be
skipping to change at page 9, line 50 skipping to change at page 10, line 24
DHCP server must return an IP address in the "ciaddr" if it has any DHCP server must return an IP address in the "ciaddr" if it has any
record of the client described by the Client-identifier or MAC record of the client described by the Client-identifier or MAC
address. In the absence of specific configuration information to the address. In the absence of specific configuration information to the
contrary (see Section 6.4) it SHOULD be the IP address with the contrary (see Section 6.4) it SHOULD be the IP address with the
latest client-last-transaction-time associated with the client latest client-last-transaction-time associated with the client
described by the MAC address or Client-identifier option (or the described by the MAC address or Client-identifier option (or the
client described by both, if both appear). client described by both, if both appear).
The DHCP servers that implement this protocol always send a response The DHCP servers that implement this protocol always send a response
to the DHCPLEASEQUERY message: either a DHCPLEASEUNASSIGNED, to the DHCPLEASEQUERY message: either a DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE or DHCPLEASEUNKNOWN (or in some cases, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN. The reasons why a
DHCPUNIMPLEMENTED). The reasons why a DHCPLEASEUNASSIGNED, DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message
DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message might be generated are might be generated are explained in the specific query regimes,
explained in the specific query regimes, below. below.
Servers which do not implement the DHCPLEASEQUERY message fall into Servers which do not implement the DHCPLEASEQUERY message SHOULD
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. simply not respond.
The DHCPLEASEQUERY message can support three query regimes: A server The DHCPLEASEQUERY message can support three query regimes: A server
which implements the DHCPLEASEQUERY message must implement all three which implements the DHCPLEASEQUERY message must implement all three
query regimes. query regimes.
o Query by IP address: o Query by IP address:
For this query, the requester supplies only an IP address in the For this query, the requester supplies only an IP address in the
DHCPLEASEQUERY message. The DHCP server will return any DHCPLEASEQUERY message. The DHCP server will return any
skipping to change at page 11, line 50 skipping to change at page 12, line 17
(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 likely to
candidate to be requested by clients sending the DHCPLEASEQUERY 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 four new values: one for the DHCPLEASEQUERY message itself and
and one for each of its four possible responses and one for each of its three possible responses
DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, DHCPLEASEUNKNOWN, and DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, DHCPLEASEUNKNOWN. The
DHCPUNIMPLEMENTED. The values of these message types are shown values of these message types are shown below in a reproduction
below in a reproduction of the table from [RFC 2132]: 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 DHCPLEASEUNASSIGNED TBD DHCPLEASEUNASSIGNED
TBD DHCPLEASEUNKNOWN TBD DHCPLEASEUNKNOWN
TBD DHCPLEASEACTIVE TBD DHCPLEASEACTIVE
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
when DHCPLEASEACTIVE messages from two different DHCP servers when DHCPLEASEACTIVE messages from two different DHCP servers
need to be compared, although it can be useful in other need to be compared, although it can be useful in other
situations. The value is a duration in seconds from the situations. The value is a duration in seconds from the
current time into the past when this IP address was most current time into the past when this IP address was most
skipping to change at page 16, line 8 skipping to change at page 16, line 21
Note that this use of the giaddr is consistent with the definition of Note that this use of the giaddr is consistent with the definition of
giaddr in [RFC2131], where the giaddr is always used as the return giaddr in [RFC2131], where the giaddr is always used as the return
address of the DHCP response message. In some (but not all) contexts address of the DHCP response message. In some (but not all) contexts
in RFC2131 the giaddr is used as the "key" to access the appropriate in RFC2131 the giaddr is used as the "key" to access the appropriate
address pool. The DHCPLEASEQUERY message is one of those cases where address pool. The DHCPLEASEQUERY message is one of those cases where
the giaddr MUST NOT be used as such a "key". 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 three possible responses to a DHCPLEASEQUERY message:
o DHCPLEASEUNASSIGNED o DHCPLEASEUNASSIGNED
The server MUST respond with a DHCPLEASEUNASSIGNED message if The server MUST respond with a DHCPLEASEUNASSIGNED message if
this server has information about the IP address, but there is this server has information about the IP address, but there is
no active lease for the IP address. The DHCPLEASEUNASSIGNED no active lease for the IP address. The DHCPLEASEUNASSIGNED
message is only returned for a query by IP address, and message is only returned for a query by IP address, and
indicates that the server manages this IP address but there is indicates that the server manages this IP address but there is
no currently active lease on this IP address. no currently active lease on this IP address.
skipping to change at page 16, line 39 skipping to change at page 17, line 5
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
The DHCPUNIMPLEMENTED response to the DHCPLEASEQUERY message
indicates that DHCPLEASEQUERY is not implemented by this DHCP
server.
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 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.
skipping to change at page 19, line 15 skipping to change at page 19, line 17
If the Relay Agent Information (option 82) is specified in the If the Relay Agent Information (option 82) is specified in the
Parameter Request List then the information contained in the most Parameter Request List then the information contained in the most
recent Relay Agent Information option received from the relay agent recent Relay Agent Information option received from the relay agent
associated with this IP address MUST be included in the associated with this IP address MUST be included in the
DHCPLEASEACTIVE message. The DHCP server MUST the Relay Agent DHCPLEASEACTIVE message. The DHCP server MUST the Relay Agent
Information option that was received when from the relay agent Information option that was received when from the relay agent
associated with this IP address. 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 or specifically excluded by options not specifically discussed above that were requested in the
being configured as "sensitive options" that were requested in the Parameter Request List of the DHCPLEASEQUERY message and that are
Parameter Request List of the DHCPLEASEQUERY message. The DHCP acceptable to return based on the list of "non-senstive options",
server uses information from its lease binding database to supply the discussed below.
DHCPLEASEACTIVE option values. The values of the options that were
returned to the DHCP client would generally be preferred, but in the
absence of those, options that were sent in DHCP client requests
would be acceptable.
DHCP servers SHOULD be configurable with a list of "sensitive DHCP servers SHOULD be configurable with a list of "non-sensitive
options" that will not be returned to the client even if specified in options" that can be returned to the client when specified in the
the Parameter Request List of the DHCPLEASEQUERY message. Parameter Request List of the DHCPLEASEQUERY message. Any option not
on this should SHOULD NOT be returned to a client, even if requested
by that client.
The DHCP server uses information from its lease binding database to
supply the DHCPLEASEACTIVE option values. The values of the options
that were returned to the DHCP client would generally be preferred,
but in the absence of those, options that were sent in DHCP client
requests would be acceptable.
In some cases, the Relay Agent Information option in an incoming In some cases, the Relay Agent Information option in an incoming
DHCPREQUEST packet is used to help determine the options returned to DHCPREQUEST packet is used to help determine the options returned to
the DHCP client which sent the DHCPREQUEST. When responding to a the DHCP client which sent the DHCPREQUEST. When responding to a
DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay
Agent Information option just like it did when responding to the DHCP Agent Information option just like it did when responding to the DHCP
client in order to determine the values of any options requested by client in order to determine the values of any options requested by
the DHCPLEASEQUERY message. The goal is to return the same option the DHCPLEASEQUERY message. The goal is to return the same option
values to the DHCPLEASEQUERY as those that were returned to the values to the DHCPLEASEQUERY as those that were returned to the
DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise
skipping to change at page 21, line 8 skipping to change at page 21, line 13
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, but only for a The access concentrator SHOULD cache this information, but only for a
relatively short lifetime, approximately 5 minutes. relatively short lifetime, approximately 5 minutes.
Having cached this information, the access concentrator SHOULD only Having cached this information, the access concentrator SHOULD only
infrequently direct a DHCPLEASEQUERY message to a DHCP server that infrequently direct a DHCPLEASEQUERY message to a DHCP server that
responded to a DHCPLEASEQUERY message for a particular "ciaddr" field responded to a DHCPLEASEQUERY message for a particular "ciaddr" field
with a DHCPLEASEUNKNOWN. with a DHCPLEASEUNKNOWN.
When a DHCPUNIMPLEMENTED message is received by an access
concentrator, it means that DHCPLEASEQUERY processing is not
implemented in the responding server. This information SHOULD be
cached may not be the case that other aspects of DHCPLEASEQUERY
processing are not implemented in that server.
6.6. Receiving no response to the DHCPLEASEQUERY Message 6.6. Receiving no response to the DHCPLEASEQUERY Message
When an access concentrator receives no response to a DHCPLEASEQUERY When an access concentrator receives no response to a DHCPLEASEQUERY
message, there are several possible reasons: message, there are several possible reasons:
o The DHCPLEASEQUERY or a corresponding DHCPLEASEUNASSIGNED, o The DHCPLEASEQUERY or a corresponding DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE or DHCPLEASEUNKNOWN were lost during DHCPLEASEACTIVE or DHCPLEASEUNKNOWN 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.
skipping to change at page 23, line 37 skipping to change at page 23, line 37
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
employing some form of relay agent authentication between the employing the techniques detailed in [RFC 3118], "Authentication for
DHCPLEASEQUERY client and the DHCP server. DHCP Messages".
Clients of the DHCPLEASEQUERY message SHOULD ensure that their data This RFC describes how a DHCP client interacts with a DHCP server.
path to the DHCP server is secure. Clients SHOULD use Relay Agent Access concentrators that send the DHCPLEASEQUERY message are
Information security as a way to achieve this goal. This will ensure essentially DHCP clients for the purposes of the DHCPLEASEQUERY
against the clients receiving false data, due perhaps to a third message, even though they perform the functions of a DHCP relay agent
party spoofing the reply from a DHCPLEASEQUERY message. as well. Thus, [RFC 3118] is an appropriate mechanism for
DHCPLEASEQUERY messages.
Since [RFC 3118] discusses the normal DHCP client interaction,
consisting of a DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, it
is necessary to transpose the operations described in [RFC 3118] to
the DHCPLEASEQUERY domain. The operations described in [RFC 3118]
for DHCPDISCOVER are performed for DHCPLEASEQUERY, and the operations
described for DHCPOFFER are performed for DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE, DHCPLEASEUNKNOWN messages.
Access concentrators SHOULD minimize potential denial of service Access concentrators SHOULD minimize potential denial of service
attacks on the DHCP servers by minimizing the generation of attacks on the DHCP servers by minimizing the generation of
DHCPLEASEQUERY messages. In particular, the access concentrator DHCPLEASEQUERY messages. In particular, the access concentrator
SHOULD employ negative caching (i.e. cache DHCPLEASEUNASSIGNED, SHOULD employ negative caching (i.e. cache DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY
messages) and ciaddr restriction (i.e. don't send a DHCPLEASEQUERY messages) and ciaddr restriction (i.e. don't send a DHCPLEASEQUERY
message with a ciaddr outside of the range of the attached broadband message with a ciaddr outside of the range of the attached broadband
access networks). Together, these mechanisms limit the access access networks). Together, these mechanisms limit the access
concentrator to transmitting one DHCPLEASEQUERY message (excluding concentrator to transmitting one DHCPLEASEQUERY message (excluding
skipping to change at page 24, line 23 skipping to change at page 24, line 32
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 four new messages types, which are the value of
the message type option (option 53) from [RFC 2132]. The value for the message type option (option 53) from [RFC 2132]. The value for
DHCPLEASEQUERY is TBD, the value for DHCPLEASEUNASSIGNED is TBD, the DHCPLEASEQUERY is TBD, the value for DHCPLEASEUNASSIGNED is TBD, the
value for DHCPLEASEACTIVE is TBD, the value for DHCPLEASEUNKNOWN is value for DHCPLEASEACTIVE is TBD, and the value for DHCPLEASEUNKNOWN
TBD and the value for DHCPUNIMPLEMENTED is TBD. Finally, there are is TBD. Finally, there are two new DHCP option defined; the client-
two new DHCP option defined; the client-last-transaction-time option last-transaction-time option -- option code TBD, and the associated-
-- option code TBD, and the associated-ip option -- option code TBD. 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. Thomas Narten made many suggestions for improvements.
Russ Housely pressed effectively for increased security capabilities
and Ted Hardie suggested ways to minimize undesired information
leakage. Bert Wijnen suggested we clarify our focus to DHCPv4 and
distinguish our approach from that of the DHCP MIB. R. Barr Hibbs,
one of the authors of the DHCP MIB, supplied information to
effectively distinguish that effort from DHCPLEASEQUERY.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
[RFC 3118] Droms, R., Arbaugh, W., "Authentication for DHCP
Messages", RFC 3118, June 2001.
10.2. Informative References 10.2. Informative References
[RFC 826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC 826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address converting network protocol addresses to 48.bit Ethernet address
for transmission on Ethernet hardware", RFC 826, November 1982. for transmission on Ethernet hardware", RFC 826, November 1982.
[RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC [RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC
951, September 1985. 951, September 1985.
[RFC 1542] Wimer, W., "Clarifications and Extensions for the [RFC 1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993. Bootstrap Protocol", RFC 1542, October 1993.
[RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC 3118] Droms, R., Arbaugh, W., "Authentication for DHCP [RFC 3315] Droms, R., Bound J., Volz B., Lemon T., Perkins C., Carney
Messages", RFC 3118, June 2001. M., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC
3315, July 2003.
[BPI] CableLabs, "Baseline Privacy Interface Specification", SP-BPI- [BPI] CableLabs, "Baseline Privacy Interface Specification", SP-BPI-
I02-990319, March 1999, available at http://www.cablemodem.com/. I02-990319, March 1999, available at http://www.cablemodem.com/.
[BPI+] CableLabs, "Baseline Privacy Plus Interface Specification", [BPI+] CableLabs, "Baseline Privacy Plus Interface Specification",
SP-BPI+-I04-000407, April 2000, available at SP-BPI+-I04-000407, April 2000, available at
http://www.cablemodem.com/. http://www.cablemodem.com/.
[DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol [DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol
(DHCP) Server MIB", draft-ietf-dhc-server-mib-06.txt, February (DHCP) Server MIB", draft-ietf-dhc-server-mib-10.txt, February
2002. 2004.
[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.
11. Author's information 11. Author's information
 End of changes. 34 change blocks. 
90 lines changed or deleted 128 lines changed or added

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