draft-ietf-dhc-leasequery-01.txt   draft-ietf-dhc-leasequery-02.txt 
Dynamic Host Configuration Working Group Rich Woundy Dynamic Host Configuration Working Group Rich Woundy
INTERNET DRAFT Kim Kinnear INTERNET DRAFT Kim Kinnear
Cisco Systems Cisco Systems
March 2001 July 2001
Expires September 2001 Expires January 2002
DHCP Lease Query DHCP Lease Query
<draft-ietf-dhc-leasequery-01.txt> <draft-ietf-dhc-leasequery-02.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 8, line 43 skipping to change at page 8, line 43
o Query by MAC address: o Query by MAC address:
For this query, the MAC address is specified in the "htype", For this query, the MAC address is specified in the "htype",
"hlen", and "chaddr" fields and no IP address is given in the "hlen", and "chaddr" fields and no IP address is given in the
"ciaddr" field. The DHCP server looks up all IP addresses for "ciaddr" field. The DHCP server looks up all IP addresses for
which clients with this MAC address are the most recent acces- which clients with this MAC address are the most recent acces-
sor. It returns information associated with the IP address most sor. It returns information associated with the IP address most
recently accessed by a DHCP client with this MAC address. If recently accessed by a DHCP client with this MAC address. If
requested, the DHCP server SHOULD return information on all of requested, the DHCP server SHOULD return information on all of
the IP addresses it found to be associated with the DHCP client the IP addresses it found to be associated with the DHCP client
with the MAC address in the associated-ip option (option TBD). with the MAC address in multiple Requested IP address options
A server which implements the DHCPLEASEQUERY message SHOULD (option 50) [RFC 2132]. A server which implements the
implement this capability. DHCPLEASEQUERY message SHOULD implement this capability.
o Query by client-id option: o Query by client-id option:
This query is similar to the query by MAC address, except that a This query is similar to the query by MAC address, except that a
client-id option is present in the DHCPLEASEQUERY packet. In client-id option is present in the DHCPLEASEQUERY packet. In
this case, information on the IP address most recently accessed this case, information on the IP address most recently accessed
by a client with the included client-id will be returned in the by a client with the included client-id will be returned in the
DHCPACK. If no MAC address is given in the DHCPLEASEQUERY DHCPACK. If no MAC address is given in the DHCPLEASEQUERY
request, then all IP addresses which have been accessed by any request, then all IP addresses which have been accessed by any
client with the included client-id SHOULD be returned in the client with the included client-id SHOULD be returned in multi-
associated-ip option (option TBD). If a MAC address is present ple Requested IP address options (option 50) [RFC 2132]. If a
in the DHCP packet, then the client-id and the MAC address both MAC address is present in the DHCP packet, then the client-id
must match the client information for an IP address for informa- and the MAC address both must match the client information for
tion about that IP address to be returned either in the "ciaddr" an IP address for information about that IP address to be
or the associated-ip option. returned either in the "ciaddr" or in one of the Requested IP
address options.
Generally, the query by IP address is likely to be the most efficient Generally, the query by IP address is likely to be the most efficient
and widely implemented form of leasequery, and it SHOULD be used if and widely implemented form of leasequery, and it SHOULD be used if
at all possible. Use of the other two query formats SHOULD be minim- at all possible. Use of the other two query formats SHOULD be minim-
ized, as they can potentially place a large load on some servers. ized, as they can potentially place a large load on some servers.
The DHCPKNOWN message reply MUST always contain the IP address in the The DHCPKNOWN message reply MUST always contain the IP address in the
ciaddr field and SHOULD contains the physical address of the IP ciaddr field and SHOULD contains the physical address of the IP
address lease owner in the "htype", "hlen", and "chaddr" fields. The address lease owner in the "htype", "hlen", and "chaddr" fields. The
dhcp-parameter-request option can be used to request specific options dhcp-parameter-request option can be used to request specific options
skipping to change at page 10, line 38 skipping to change at page 10, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag B: BROADCAST flag
R: RESERVATION FLAG R: RESERVATION FLAG
MBZ: MUST BE ZERO (reserved for future use) MBZ: MUST BE ZERO (reserved for future use)
Revised Figure 2 from RFC2131: Revised Figure 2 from RFC2131:
Format of the 'flags' field Format of the 'flags' field
3. There are three new options defined which can be used to return 3. There is one new option defined which can be used to return
important information in a DHCPKNOWN response to a DHCPLEASE- important information in a DHCPKNOWN response to a DHCPLEASE-
QUERY message: associated-ip, client-last-transaction-time, and QUERY message -- the client-last-transaction-time. See Section
client-requested-host-name. See Section 6.8 for details. 6.8 for details.
DISCUSSION:
The associated-ip option is necessary to support returning
multiple IP addresses in a single DHCPKNOWN message.
The client-last-transaction-time is necessary in order to
allow an entity that receives multiple DHCPKNOWN messages
from different DHCP servers to compare the results and
extract the most recently used IP address from among the
multiple replies.
The client-requested-host-name is distinguished from the The client-last-transaction-time is necessary in order to allow
host-name option in that the client-requested-host-name an entity that receives multiple DHCPKNOWN messages from dif-
option is used to return the name that the client requested ferent DHCP servers to compare the results and extract the most
by either the host-name (option 12) or client-FQDN option recently used IP address from among the multiple replies.
(option 81). It is different from the actual host-name
given to the client, which would be returned in the host-
name option. This may be a distinction which is not
interesting in general, and we might want to drop the
requirement for allocating an option for this purpose.
6.2. Sending the DHCPLEASEQUERY Message 6.2. Sending the DHCPLEASEQUERY Message
The DHCPLEASEQUERY message is typically sent by an access concentra- The DHCPLEASEQUERY message is typically sent by an access concentra-
tor. The DHCPLEASEQUERY message uses the DHCP message format as tor. The DHCPLEASEQUERY message uses the DHCP message format as
described in [RFC 2131], and uses message number TBD in the DHCP Mes- described in [RFC 2131], and uses message number TBD in the DHCP Mes-
sage Type option (option 53). The DHCPLEASEQUERY message has the sage Type option (option 53). The DHCPLEASEQUERY message has the
following pertinent message contents: following pertinent message contents:
o The giaddr MUST be set to the IP address of the requestor (i.e. o The giaddr MUST be set to the IP address of the requestor (i.e.
skipping to change at page 13, line 46 skipping to change at page 13, line 30
Conversely, if the Reservation bit is set in the "flags" field of the Conversely, if the Reservation bit is set in the "flags" field of the
DHCP packet, then the DHCP server SHOULD respond with information DHCP packet, then the DHCP server SHOULD respond with information
contained in the reservation associated with either the IP address contained in the reservation associated with either the IP address
specified in the "ciaddr" or the client specified in the MAC adddress specified in the "ciaddr" or the client specified in the MAC adddress
and/or client-id if there is no actual usage information concerning and/or client-id if there is no actual usage information concerning
the association of the IP address or specified client. the association of the IP address or specified client.
If the DHCP server uses reservation information to fill in the infor- If the DHCP server uses reservation information to fill in the infor-
mation of a DHCPKNOWN message (other than using it to include an IP mation of a DHCPKNOWN message (other than using it to include an IP
address in an associated-ip option), the the DHCP server MUST set the address in a Requested IP option), the DHCP server MUST set the
Reservation bit in the "flags" field of the DHCPKNOWN message. Reservation bit in the "flags" field of the DHCPKNOWN message.
Thus, a DHCP server SHOULD, but doesn't have to implement reservation Thus, a DHCP server SHOULD, but doesn't have to implement reservation
support if it implements support for the DHCPLEASEQUERY message, but support if it implements support for the DHCPLEASEQUERY message, but
if it does, it MUST set the Reservation bit in the "flags" field if it does, it MUST set the Reservation bit in the "flags" field
whenever the primary information it returns in the DHCPKNOWN message whenever the primary information it returns in the DHCPKNOWN message
is based on a reservation. is based on a reservation.
The DHCP server MUST respond to the DHCPLEASEQUERY with a DHCPUNKNOWN The DHCP server MUST respond to the DHCPLEASEQUERY with a DHCPUNKNOWN
if the DHCP server supports the DHCPLEASEQUERY message but does not if the DHCP server supports the DHCPLEASEQUERY message but does not
skipping to change at page 14, line 21 skipping to change at page 14, line 7
the client-id option. When responding with a DHCPUNKNOWN, the DHCP the client-id option. When responding with a DHCPUNKNOWN, the DHCP
server SHOULD NOT include other DHCP options in the response. server SHOULD NOT include other DHCP options in the response.
A DHCP server which does not support the DHCPLEASEQUERY message MUST A DHCP server which does not support the DHCPLEASEQUERY message MUST
NOT respond to the DHCPLEASEQUERY message. NOT respond to the DHCPLEASEQUERY message.
When responding to a DHCPLEASEQUERY message with a DHCPKNOWN: When responding to a DHCPLEASEQUERY message with a DHCPKNOWN:
o In the case where more than one IP has been accessed by the o In the case where more than one IP has been accessed by the
client specified by the MAC address and/or client-id option, client specified by the MAC address and/or client-id option,
then the IP address most recently accessed by that client SHOULD then the IP address most recently the involved in a DHCP client
be used as the IP address to place into the "ciaddr". message by that client SHOULD be used as the IP address to place
into the "ciaddr". The DHCP server SHOULD be configurable to
return other than the IP address with the most recent client-
last-transaction-time, for instance the IP address with the
longest lease time.
In this case, all of the IP addresses which are recorded as hav- In this case, all of the IP addresses which are recorded as hav-
ing been most recently been accessed by this client should be ing been accessed by this client should be returned in Requested
returned in the associated-ip option (option TBD) if that option IP address options (option 50) if that option is included in the
is included in the dhcp-parameter-request-list option in the dhcp-parameter-request-list option in the request. They should
request. They should appear in order of increasing age of appear in order of increasing age of access in that option.
access in that option.
o If the IP Address Lease Time (option 51) is specified in the o If the IP Address Lease Time option (option 51) is specified in
Parameter Request List and if there is a currently valid lease the Parameter Request List and if there is a currently valid
for the IP address specified in the ciaddr, then the DHCP server lease for the IP address specified in the ciaddr, then the DHCP
MUST return this option in the DHCPKNOWN with its value equal to server MUST return this option in the DHCPKNOWN with its value
the time remaining until lease expiration. If there is no valid equal to the time remaining until lease expiration. If there is
lease for the IP address, then the server MUST NOT return the IP no valid lease for the IP address, then the server MUST NOT
Address Lease Time option (option 51). This allows the reques- return the IP Address Lease Time option (option 51). This
tor (i.e. the access concentrator) to determine if there is allows the requestor (i.e. the access concentrator) to deter-
currently a valid lease for the IP address as well as the time mine if there is currently a valid lease for the IP address as
until the lease expiration. well as the time until the lease expiration.
A request for the Renewal (T1) Time Value option or the Rebind- A request for the Renewal (T1) Time Value option or the Rebind-
ing (T2) Time Value option in the Parameter Request List of the ing (T2) Time Value option in the Parameter Request List of the
DHCPLEASEQUERY message MUST be handled like the IP Address Lease DHCPLEASEQUERY message MUST be handled like the IP Address Lease
Time option is handled. If there is a valid lease, then the Time option is handled. If there is a valid lease, then the
DHCP server SHOULD return these options (when requested) with DHCP server SHOULD return these options (when requested) with
the remaining time until renewal or rebinding, respectively. If the remaining time until renewal or rebinding, respectively. If
there is not currently a valid lease for this IP address, the there is not currently a valid lease for this IP address, the
DHCP server MUST NOT return these options. DHCP server MUST NOT return these options.
skipping to change at page 15, line 51 skipping to change at page 15, line 39
casts the DHCPKNOWN or DHCPUNKNOWN to the giaddr. If the giaddr casts the DHCPKNOWN or DHCPUNKNOWN to the giaddr. If the giaddr
field is zero, then the DHCP server does not reply to the DHCPLEASE- field is zero, then the DHCP server does not reply to the DHCPLEASE-
QUERY message. QUERY message.
6.5. Receiving a DHCPKNOWN or DHCPUNKNOWN response to the DHCPLEASE- 6.5. Receiving a DHCPKNOWN or DHCPUNKNOWN response to the DHCPLEASE-
QUERY Message QUERY Message
When a DHCPKNOWN message is received in response to the DHCPLEASE- When a DHCPKNOWN message is received in response to the DHCPLEASE-
QUERY message and the DHCPKNOWN has an IP Address Lease Time option QUERY message and the DHCPKNOWN has an IP Address Lease Time option
value that is non-zero, it means that there is a currently active value that is non-zero, 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 concentra-
concentrator SHOULD use the information in the htype, hlen, and tor SHOULD use the information in the htype, hlen, and chaddr fields
chaddr fields of the DHCPKNOWN as well as any Relay Agent Information of the DHCPKNOWN as well as any Relay Agent Information option infor-
option information included in the packet to refresh its location mation included in the packet to refresh its location information for
information for this IP address. this IP address.
When a DHCPKNOWN message is received in response to the DHCPLEASE- When a DHCPKNOWN message is received in response to the DHCPLEASE-
QUERY message and the DHCPKNOWN has no IP Address Lease Time option QUERY message and the DHCPKNOWN has no IP Address Lease Time option
(though one was requested in the Parameter Request List), that means (though one was requested in the Parameter Request List), that means
that there is no currently active lease for the IP address present in that there is no currently active lease for the IP address present in
the DHCP server. In this case, the access concentrator SHOULD cache the DHCP server. In this case, the access concentrator SHOULD cache
this information in order to prevent unacceptable loads on the access this information in order to prevent unacceptable loads on the access
concentrator and the DHCP server in the face of a malicious or seri- concentrator and the DHCP server in the face of a malicious or
ously compromised device downstream of the access concentrator. seriously compromised device downstream of the access concentrator.
In either case, when a DHCPKNOWN message is received in response to a In either case, when a DHCPKNOWN message is received in response to a
DHCPLEASEQUERY message, it means that the DHCP server which responded DHCPLEASEQUERY message, it means that the DHCP server which responded
is a DHCP server which manages the IP address present in the ciaddr, is a DHCP server which manages the IP address present in the ciaddr,
and the Relay Agent SHOULD cache this information for later use. and the Relay Agent SHOULD cache this information for later use.
When a DHCPUNKNOWN message is received by an access concentrator When a DHCPUNKNOWN message is received by an access concentrator
which has sent out a DHCPLEASEQUERY message, it means that the DHCP which has sent out a DHCPLEASEQUERY message, it means that the DHCP
server contacted supports the DHCPLEASEQUERY message but that the server contacted supports the DHCPLEASEQUERY message but that the
DHCP server not have definitive information concerning the IP address DHCP server not have definitive information concerning the IP address
skipping to change at page 16, line 51 skipping to change at page 16, line 39
When an access concentrator receives no response to a DHCPLEASEQUERY When an access concentrator receives no response to a DHCPLEASEQUERY
message, there are several possible reasons: message, there are several possible reasons:
o The DHCPLEASEQUERY or a corresponding DHCPKNOWN or DHCPUNKNOWN o The DHCPLEASEQUERY or a corresponding DHCPKNOWN or DHCPUNKNOWN
were lost during transmission or the DHCPLEASEQUERY arrived at were lost during transmission or the DHCPLEASEQUERY arrived at
the DHCP server but it was dropped because the server was too the DHCP server but it was dropped because the server was too
busy. 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 DHCPLEASE-
DHCPLEASEQUERY would be appropriate, but in the second of the two QUERY would be appropriate, but in the second of the two cases, a
cases, a retransmission would not be appropriate. There is no way to retransmission would not be appropriate. There is no way to tell
tell these two cases apart (other than, perhaps, because of a DHCP these two cases apart (other than, perhaps, because of a DHCP
server's response to other DHCPLEASEQUERY messages indicating that it server's response to other DHCPLEASEQUERY messages indicating that it
supports the DHCPLEASEQUERY message). supports the DHCPLEASEQUERY message).
An access concentrator which utilizes the DHCPLEASEQUERY message An access concentrator which utilizes the DHCPLEASEQUERY message
SHOULD attempt to resend DHCPLEASEQUERY messages to servers which do SHOULD attempt to resend DHCPLEASEQUERY messages to servers which do
not respond to them using a backoff algorithm for the retry time that not respond to them using a backoff algorithm for the retry time that
approximates an exponential backoff. The access concentrator SHOULD approximates an exponential backoff. The access concentrator SHOULD
adjust the backoff approach such that DHCPLEASEQUERY messages do not adjust the backoff approach such that DHCPLEASEQUERY messages do not
arrive at a server which is not otherwise known to support the arrive at a server which is not otherwise known to support the
DHCPLEASEQUERY message at a rate of not more than approximately one DHCPLEASEQUERY message at a rate of not more than approximately one
skipping to change at page 17, line 33 skipping to change at page 17, line 21
When utilizing the DHCPLEASEQUERY message in an environment where multi- When utilizing the DHCPLEASEQUERY message in an environment where multi-
ple DHCP server may contain authoritative information about the same IP ple DHCP server may contain authoritative information about the same IP
address (such as when failover [FAILOVER] is operating), there could be address (such as when failover [FAILOVER] is operating), there could be
some difficulty in deciding which results are the most useful if two some difficulty in deciding which results are the most useful if two
servers respond with DHCPKNOWN messages to the same query. servers respond with DHCPKNOWN messages to the same query.
In this case, the client-last-transaction-time can be used to decide In this case, the client-last-transaction-time can be used to decide
which server has more recent information concerning the IP address which server has more recent information concerning the IP address
returned in the "ciaddr" field. returned in the "ciaddr" field.
6.8. New options defined for responding to DHCPLEASEQUERY messages. 6.8. New option defined for responding to DHCPLEASEQUERY messages.
Three new options are defined for responding to DHCPLEASEQUERY mes-
sages:
1. client-last-transaction-time
2. associated-ip
3. client-requested-host-name There is one new option defined for responding to DHCPLEASEQUERY mes-
sages: client-last-transaction time.
6.8.1. client-last-transaction-time 6.8.1. client-last-transaction-time
This option SHOULD record the time of the most recent access of the This option SHOULD record the time of the most recent access of the
client. It is particularly useful when DHCPLEASEQUERY responses from client. It is particularly useful when DHCPLEASEQUERY responses from
two different DHCP servers need to be compared, although it can be two different DHCP servers need to be compared, although it can be
useful in other situations. The value is a duration in seconds in useful in other situations. The value is a duration in seconds in
the past from when this IP address was most recently accessed by the the past from when this IP address was most recently the subject of
client specified. communication between the client and the DHCP server.
The code for the this option is TBD. The length of the this option is The code for the this option is TBD. The length of the this option is
4 octets. 4 octets.
Code Len Seconds in the past Code Len Seconds in the past
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD | 4 | t1 | t2 | t3 | t4 | | TBD | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
6.8.2. associated-ip
The code for this option is TBD. The minimum length for this option
is 4 octets, and the length MUST always be a multiple of 4.
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
6.8.3. client-requested-host-name
This option SHOULD contain the value of the host name requested by
the client in the host-name option (option 12) or the FQDN option
(option 81).
This option specifies the name of the client. The name may or may
not be qualified with the local domain name.
The code for this option is TBD, and its minimum length is 1.
Code Len Host Name
+-----+-----+-----+-----+-----+-----+-----+-----+--
| TBD | n | h1 | h2 | h3 | h4 | h5 | h6 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
7. Security Considerations 7. Security Considerations
Access concentrators that use DHCP gleaning, refreshed with Access concentrators that use DHCP gleaning, refreshed with
DHCPLEASEQUERY messages, will maintain accurate location information. DHCPLEASEQUERY messages, will maintain accurate location information.
Location information accuracy ensures that the access concentrator Location information accuracy ensures that the access concentrator
can forward data traffic to the intended location in the broadband can forward data traffic to the intended location in the broadband
access network, can perform IP source address verification of access network, can perform IP source address verification of
datagrams from the access network, and can encrypt traffic which can datagrams from the access network, and can encrypt traffic which can
only be decrypted by the intended access modem (e.g. [BPI] and only be decrypted by the intended access modem (e.g. [BPI] and
[BPI+]). As a result, the access concentrator does not need to [BPI+]). As a result, the access concentrator does not need to
skipping to change at page 20, line 47 skipping to change at page 19, line 47
[DOCSIS] CableLabs, "Data-Over-Cable Service Interface Specifica- [DOCSIS] CableLabs, "Data-Over-Cable Service Interface Specifica-
tions: Cable Modem Radio Frequency Interface Specification SP- tions: Cable Modem Radio Frequency Interface Specification SP-
RFI-I05-991105", November 1999. RFI-I05-991105", November 1999.
[EUROMODEM] ECCA, "Technical Specification of a European Cable Modem [EUROMODEM] ECCA, "Technical Specification of a European Cable Modem
for digital bi-directional communications via cable networks", for digital bi-directional communications via cable networks",
Version 1.0, May 1999. Version 1.0, May 1999.
[FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., [FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S.,
Rabil, G., Dooley, M., Kapur, A., "DHCP Failover Protocol", Rabil, G., Dooley, M., Kapur, A., "DHCP Failover Protocol",
draft-ietf-dhc-failover-08.txt, November 2000. draft-ietf-dhc-failover-09.txt, July 2001.
10. Author's information 10. Author's information
Rich Woundy Rich Woundy
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 244-8000 Phone: (978) 244-8000
EMail: rwoundy@cisco.com EMail: rwoundy@cisco.com
kkinnear@cisco.com kkinnear@cisco.com
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to oth- This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis- assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations, references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
skipping to change at page 21, line 44 skipping to change at line 923
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
NESS FOR A PARTICULAR PURPOSE. NESS FOR A PARTICULAR PURPOSE.
Open Issues
These issues need to be resolved by the working group:
1. Should the DHCPLEASEQUERY message be extended to find lease
information by physical address or by DHCP Client ID? This
might be useful for non-router access concentrators.
[?] This capability has been added to the current draft since
we found it quite useful, and thought that others might as
well.
 End of changes. 

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