draft-ietf-dhc-leasequery-00.txt   draft-ietf-dhc-leasequery-01.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
November 2000 March 2001
Expires May 2001 Expires September 2001
DHCP Lease Query DHCP Lease Query
<draft-ietf-dhc-leasequery-00.txt> <draft-ietf-dhc-leasequery-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
Access concentrators that act as DHCP relay agents need to determine Access concentrators that act as DHCP relay agents need to determine
the endpoint locations of IP addresses across public broadband access the endpoint locations of IP addresses across public broadband access
networks such as cable, DSL, and wireless networks. Because ARP networks such as cable, DSL, and wireless networks. Because ARP
broadcasts are undesirable in public networks, many access broadcasts are undesirable in public networks, many access
concentrator implementations "glean" location information from DHCP concentrator implementations "glean" location information from DHCP
messages forwarded by its relay agent function. Unfortunately, the messages forwarded by its relay agent function. Unfortunately, the
typical access concentrator loses its gleaned information when the typical access concentrator loses its gleaned information when the
skipping to change at page 3, line 34 skipping to change at page 3, line 34
DHCP server responses sent through the relay agent. When location DHCP server responses sent through the relay agent. When location
information is not available from "gleaning", e.g. due to reboot, information is not available from "gleaning", e.g. due to reboot,
the access concentrator can query the DHCP server(s) for location the access concentrator can query the DHCP server(s) for location
information using the DHCPLEASEQUERY message. The DHCPLEASEQUERY information using the DHCPLEASEQUERY message. The DHCPLEASEQUERY
mechanism is the focus of this document. mechanism is the focus of this document.
The DHCPLEASEQUERY message is a new DHCP message type transmitted The DHCPLEASEQUERY message is a new DHCP message type transmitted
from a DHCP relay agent to a DHCP server. The DHCPLEASEQUERY-aware from a DHCP relay agent to a DHCP server. The DHCPLEASEQUERY-aware
relay agent sends the DHCPLEASEQUERY message when it needs to know relay agent sends the DHCPLEASEQUERY message when it needs to know
the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server
replies with a DHCPACK or DHCPNAK message. The DHCPACK response to a replies with a DHCPKNOWN or DHCPUNKNOWN message. The DHCPKNOWN
DHCPLEASEQUERY message allows the relay agent to determine the IP response to a DHCPLEASEQUERY message allows the relay agent to deter-
endpoint location, and the remaining duration of the IP address mine the IP endpoint location, and the remaining duration of the IP
lease. address lease.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC 2119].
This document uses the following terms: This document uses the following terms:
o "access concentrator" o "access concentrator"
skipping to change at page 4, line 43 skipping to change at page 4, line 43
function. function.
o "location information" o "location information"
Location information is information needed by the access concen- Location information is information needed by the access concen-
trator to forward traffic to a broadband-accessible host. This trator to forward traffic to a broadband-accessible host. This
information includes knowledge of the host hardware address, the information includes knowledge of the host hardware address, the
port or virtual circuit that leads to the host, and/or the port or virtual circuit that leads to the host, and/or the
hardware address of the intervening subscriber modem. hardware address of the intervening subscriber modem.
o "MAC address"
In the context of a DHCP packet, a MAC address consists of the
fields: hardware type "htype", hardware length "hlen", and
client hardware address "chaddr".
o "primary DHCP server" o "primary DHCP server"
The primary DHCP server in a DHCP Failover environment is con- The primary DHCP server in a DHCP Failover environment is con-
figured to provide primary service to a set of DHCP clients for figured to provide primary service to a set of DHCP clients for
a particular set of subnet address pools. a particular set of subnet address pools.
o "secondary DHCP server" o "secondary DHCP server"
The secondary DHCP server in a DHCP Failover environment is con- The secondary DHCP server in a DHCP Failover environment is con-
figured to act as backup to a primary server for a particular figured to act as backup to a primary server for a particular
skipping to change at page 5, line 34 skipping to change at page 5, line 40
This document assumes that many access concentrators have an embedded This document assumes that many access concentrators have an embedded
DHCP relay agent functionality. Typical access concentrators include DHCP relay agent functionality. Typical access concentrators include
DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB Interac- DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB Interac-
tive Network Adapters (INAs) [EUROMODEM], and DSL Access Concentra- tive Network Adapters (INAs) [EUROMODEM], and DSL Access Concentra-
tors. tors.
The DHCPLEASEQUERY message is an optional extension to the DHCP pro- The DHCPLEASEQUERY message is an optional extension to the DHCP pro-
tocol [RFC 2131]. Unlike previous DHCP message types, the DHCP relay tocol [RFC 2131]. Unlike previous DHCP message types, the DHCP relay
agent originates and sends the DHCPLEASEQUERY message to the DHCP agent originates and sends the DHCPLEASEQUERY message to the DHCP
server, and processes the reply from the DHCP server (a DHCPACK or server, and processes the reply from the DHCP server (a DHCPKNOWN or
DHCPNAK). DHCPUNKNOWN).
In a DHCP Failover environment [FAILOVER], the DHCPLEASEQUERY message In a DHCP Failover environment [FAILOVER], the DHCPLEASEQUERY message
can be sent to the primary or secondary DHCP server. In order for the can be sent to the primary or secondary DHCP server. In order for the
secondary DHCP server to answer DHCPLEASEQUERY messages, the primary secondary DHCP server to answer DHCPLEASEQUERY messages, the primary
DHCP server must send "interesting options" (such as the relay- DHCP server must send "interesting options" (such as the relay-
agent-information option) in Failover BNDUPD messages to the secon- agent-information option) in Failover BNDUPD messages to the secon-
dary DHCP server, as recommended by section 7.1.1 of [FAILOVER]. dary DHCP server, as recommended by section 7.1.1 of [FAILOVER].
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 lease. affect the state of the IP address or the binding information associ-
ated with it.
4. Design Goals 4. Design Goals
The core requirement of this document is to provide a lightweight The core requirement of this document is to provide a lightweight
mechanism for access concentrator implementations to obtain location mechanism for access concentrator implementations to obtain location
information for broadband access network devices. The specifics of information for broadband access network devices. The specifics of
the broadband environment that drove the approach of this document the broadband environment that drove the approach of this document
follow. follow.
4.1. Broadcast ARP is Undesirable 4.1. Broadcast ARP is Undesirable
The access concentrator can transmit a broadcast ARP Request [RFC The access concentrator can transmit a broadcast ARP Request [RFC 826],
826], and observe the origin and contents of the ARP Reply, to recon- and observe the origin and contents of the ARP Reply, to reconstruct the
struct the location information. 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
span multiple ports or virtual circuits), multiple ports or virtual circuits),
2. the burden on the numerous subscriber hosts to receive and pro- 2. the burden on the numerous subscriber hosts to receive and process
cess the broadcast, and 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
the IP endpoint. IP endpoint.
4.2. SNMP and LDAP Client Functionality is Lacking 4.2. SNMP and LDAP Client Functionality is Lacking
Access concentrator implementations typically do not have SNMP Access concentrator implementations typically do not have SNMP manage-
management client interfaces nor LDAP client interfaces (although ment client interfaces nor LDAP client interfaces (although they typi-
they typically do include SNMP management agents). This is a primary cally do include SNMP management agents). This is a primary reason why
reason why this document does not leverage the proposed DHCP Server this document does not leverage the proposed DHCP Server MIB [DHCPMIB]
MIB [DHCPMIB] nor leverage the proposed DHCP LDAP schema nor leverage the proposed DHCP LDAP schema [DHCPSCHEMA].
[DHCPSCHEMA].
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
DHCP server responses, as part of the relay agent function. server responses, as part of the relay agent function.
The gleaning mechanism as a technique to determine the IP addresses The gleaning mechanism as a technique to determine the IP addresses
valid for a particular downstream link is preferred over other
mechanisms (ARP, SNMP, LDAP) because of the lack of additional net- valid for a particular downstream link is preferred over other mechan-
work traffic, but sometimes gleaning information can be incomplete. isms (ARP, SNMP, LDAP) because of the lack of additional network
The access concentrator usually cannot glean information from any traffic, but sometimes gleaning information can be incomplete. The
DHCP unicast (i.e. non-relayed) messages due to performance reasons. access concentrator usually cannot glean information from any DHCP uni-
Furthermore, the DHCP-gleaned location information often does not cast (i.e. non-relayed) messages due to performance reasons. Further-
persist across access concentrator reboots (due to lack of stable more, the DHCP-gleaned location information often does not persist
storage), and almost never persists across concentrator replacements. across access concentrator reboots (due to lack of stable storage), and
almost never persists across concentrator replacements.
4.4. DHCP Servers Are Most Reliable Source of Location Information 4.4. DHCP Servers Are Most Reliable Source of Location Information
DHCP servers are the most reliable source of location information for DHCP servers are the most reliable source of location information for
access concentrators, particularly when the location information is access concentrators, particularly when the location information is
dynamic and not reproducible by algorithmic means (e.g. when a sin- dynamic and not reproducible by algorithmic means (e.g. when a single
gle IP subnet extends behind many broadband modems). DHCP servers IP subnet extends behind many broadband modems). DHCP servers partici-
participate in all IP lease transactions (and therefore in all loca- pate in all IP lease transactions (and therefore in all location infor-
tion information updates) with DHCP clients, whereas access concen- mation updates) with DHCP clients, whereas access concentrators some-
trators sometimes miss some important lease transactions. times miss some important lease transactions.
In a DHCP Failover environment [FAILOVER], the access concentrator In a DHCP Failover environment [FAILOVER], the access concentrator can
can query either the primary or secondary DHCP server, so that no one query either the primary or secondary DHCP server, so that no one DHCP
DHCP server is a single point of failure. server is a single point of failure.
4.5. Minimal Additional Configuration is Required 4.5. Minimal Additional Configuration is Required
Access concentrators can usually query the same set of DHCP servers Access concentrators can usually query the same set of DHCP servers used
used for forwarding by the relay agent, thus minimizing configuration for forwarding by the relay agent, thus minimizing configuration
requirements. requirements.
5. Protocol Overview 5. Protocol Overview
The access concentrator initiates all DHCPLEASEQUERY message conver- The access concentrator initiates all DHCPLEASEQUERY message conver-
sations. This document assumes that the access concentrator gleans sations. This document assumes that the access concentrator gleans
location information in its DHCP relay agent function. However, the location information in its DHCP relay agent function. However, the
location information is usually unavailable after the reboot or location information is usually unavailable after the reboot or
replacement of the access concentrator. replacement of the access concentrator.
Suppose the access concentrator is a router, and further suppose that Suppose the access concentrator is a router, and further suppose that
the router receives an IP datagram to forward downstream to the pub- the router receives an IP datagram to forward downstream to the pub-
lic broadband access network. If the location information for the lic broadband access network. If the location information for the
downstream next hop is missing, the access concentrator sends one or downstream next hop is missing, the access concentrator sends one or
more DHCPLEASEQUERY message(s), each containing the IP address of the more DHCPLEASEQUERY message(s), each containing the IP address of the
downstream next hop in the "ciaddr" field. downstream next hop in the "ciaddr" field.
An alternative approach is to send in a DHCPLEASEQUERY message with
the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen",
and "chaddr" fields) with a valid MAC address and/or a client-id
option (option 61) appearing in the options area. In this case, the
DHCP server SHOULD return an IP address in the "ciaddr". It MUST be
the IP address most recently used by the client described by the MAC
address or client-id option (or both, if both appear).
The DHCP servers that implement this protocol always sends a response The DHCP servers that implement this protocol always sends a response
to the DHCPLEASEQUERY message: either a DHCPACK or DHCPNAK. The DHCP to the DHCPLEASEQUERY message: either a DHCPKNOWN or DHCPUNKNOWN. The
server replies to the DHCPLEASEQUERY message with a DHCPACK message DHCP server replies to the DHCPLEASEQUERY message with a DHCPKNOWN
if the "ciaddr" corresponds to an IP address about which the server message if the "ciaddr" corresponds to an IP address about which the
has definitive information (i.e., it is authorized to lease this IP server has definitive information (i.e., it is authorized to lease
address). The server replies with a DHCPNAK message if the server this IP address). The server replies with a DHCPUNKNOWN message if
does not have definitive location information concerning the lease the server does not have definitive location information concerning
implied by the "ciaddr". Note that non-DHCPLEASEQUERY-literate DHCP the lease implied by the "ciaddr". Note that non-DHCPLEASEQUERY-
servers are expected to drop the DHCPLEASEQUERY message silently. literate DHCP servers SHOULD (and are expected to) drop the
DHCPLEASEQUERY message silently. The DHCPLEASEQUERY message can sup-
port three different query regimes:
The DHCPACK message reply contains the physical address of the IP o Query by IP address:
For this query, the client passes in an IP address and the DHCP
server the IP address and returns any information that it has on
the most recent client to utilized that IP address. Any server
which supports the DHCPLEASEQUERY message MUST support query by
IP address. If an IP address appears in the "ciaddr" field,
then the query MUST be by IP address regardless of the contents
of the MAC address or client-id option (if any).
o Query by MAC address:
For this query, the MAC address is specified in the "htype",
"hlen", and "chaddr" fields and no IP address is given in the
"ciaddr" field. The DHCP server looks up all IP addresses for
which clients with this MAC address are the most recent acces-
sor. It returns information associated with the IP address most
recently accessed by a DHCP client with this MAC address. If
requested, the DHCP server SHOULD return information on all of
the IP addresses it found to be associated with the DHCP client
with the MAC address in the associated-ip option (option TBD).
A server which implements the DHCPLEASEQUERY message SHOULD
implement this capability.
o Query by client-id option:
This query is similar to the query by MAC address, except that a
client-id option is present in the DHCPLEASEQUERY packet. In
this case, information on the IP address most recently accessed
by a client with the included client-id will be returned in the
DHCPACK. If no MAC address is given in the DHCPLEASEQUERY
request, then all IP addresses which have been accessed by any
client with the included client-id SHOULD be returned in the
associated-ip option (option TBD). If a MAC address is present
in the DHCP packet, then the client-id and the MAC address both
must match the client information for an IP address for informa-
tion about that IP address to be returned either in the "ciaddr"
or the associated-ip option.
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
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.
The DHCPKNOWN message reply MUST always contain the IP address in the
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
reply often contains the time until expiration of the lease, and the dhcp-parameter-request option can be used to request specific options
original contents of the Relay Agent Information option [RELAYAGEN- to be returned about the IP address in the ciaddr. The reply often
TINFO]. The access concentrator uses the "chaddr" and Relay Agent contains the time until expiration of the lease, and the original
Information option to construct location information, which can be contents of the Relay Agent Information option [RFC 3046]. The
cached on the access concentrator until lease expiration. access concentrator uses the "chaddr" and Relay Agent Information
option to construct location information, which can be cached on the
access concentrator until lease expiration.
Any DHCP server which supports the DHCPLEASEQUERY message SHOULD save Any DHCP server which supports the DHCPLEASEQUERY message SHOULD save
the information from the most recent Relay Agent Information option the information from the most recent Relay Agent Information option
[RELAYAGENTINFO] associated with every IP address which it serves. [RFC 3046] associated with every IP address which it serves. A
server which implements DHCPLEASEQUERY SHOULD also save the informa-
tion on the most recent vendor-class-identifier, option 60, associ-
ated with each IP address.
6. Protocol Details 6. Protocol Details
6.1. Sending the DHCPLEASEQUERY Message 6.1. Definitions required for DHCPLEASEQUERY processing
The operation of the DHCPLEASEQUERY message requires the definition
of the following new values for the DHCP packet beyond those defined
by [RFC 2131].
1. The message type option (option 53) from [RFC 2132] requires
three new values: The DHCPLEASEQUERY message itself and its
two responses DHCPKNOWN and DHCPUNKNOWN. The values of these
message types are shown below in a reproduction of the table
from [RFC 2132]:
Value Message Type
----- ------------
1 DHCPDISCOVER
2 DHCPOFFER
3 DHCPREQUEST
4 DHCPDECLINE
5 DHCPACK
6 DHCPNAK
7 DHCPRELEASE
8 DHCPINFORM
TBD DHCPLEASEQUERY
TBD DHCPKNOWN
TBD DHCPUNKNOWN
2. There is a new bit defined in the flags field of the DHCP
packet (see Section 1, Figure 1 and Table 1 of [RFC 2131]). It
is called the R: RESERVATION flag. The revised Figure 2 from
[RFC 2131] is show here:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| tbd MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag
R: RESERVATION FLAG
MBZ: MUST BE ZERO (reserved for future use)
Revised Figure 2 from RFC2131:
Format of the 'flags' field
3. There are three new options defined which can be used to return
important information in a DHCPKNOWN response to a DHCPLEASE-
QUERY message: associated-ip, client-last-transaction-time, and
client-requested-host-name. See Section 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
host-name option in that the client-requested-host-name
option is used to return the name that the client requested
by either the host-name (option 12) or client-FQDN option
(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
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 values of htype, hlen, and chaddr MUST be set to 0. This
DHCP message is used for querying on IP address, not on hardware
address or DHCP client ID.
o The ciaddr MUST be set to the IP address of the lease to be
queried.
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.
the access concentrator). The giaddr is independent of the the access concentrator). The giaddr is independent of the
ciaddr to be searched -- it is simply the return address of for ciaddr to be searched -- it is simply the return address of for
the DHCPACK or DHCPNAK message from the DHCP server. the DHCPKNOWN or DHCPUNKNOWN message from the DHCP server.
o The Parameter Request List SHOULD be set to the options of o The Parameter Request List SHOULD be set to the options of
interest to the requestor. The interesting options are likely interest to the requestor. The interesting options are likely
to include the IP Address Lease Time option (option 51) and the to include the IP Address Lease Time option (option 51) and the
Relay Agent Information option (82). Relay Agent Information option (82).
o The Reservation bit in the "flags" field of the DHCP packet (see
[RFC 2131] and Section 6.1 of this document) is used to specify
if the response should include information encoded into reserva-
tions.
Additional details concerning different query types are:
o Query by IP address:
The values of htype, hlen, and chaddr MUST be set to 0.
The ciaddr MUST be set to the IP address of the lease to be
queried.
The client-id option (option 61) MUST NOT appear in the packet.
o Query by MAC address:
The values of htype, hlen, and chaddr MUST be set to the value
of the MAC address to search for.
The ciaddr MUST be set to zero.
The client-id option (option 61) MUST NOT appear in the packet.
o Query by client-id option:
There MUST be a client-id option (option 61) in the DHCPLEASE-
QUERY message.
The ciaddr MUST be set to zero.
The values of htype, hlen, and chaddr MAY be set to the value of
the MAC address to search for. In this case, the search MUST
match both the values in the client-id option and the MAC
address specified in the "htype", "hlen", or "chaddr".
The access concentrator SHOULD ensure that the ciaddr mentioned in The access concentrator SHOULD ensure that the ciaddr mentioned in
the DHCPLEASEQUERY message is a local subnet of the interface speci- the DHCPLEASEQUERY message (if a query by IP address) is a local sub-
fied for the client. net of the interface specified for the client.
The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is
known to possess authoritative information concerning the IP address. known to possess authoritative information concerning the IP address.
The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, The DHCPLEASEQUERY message MAY be sent to more than one DHCP server,
and in the absence of information concerning which DHCP server might and in the absence of information concerning which DHCP server might
possess authoritative information concerning the IP address, it possess authoritative information concerning the IP address, it
SHOULD be sent to all DHCP servers configured for the associated SHOULD be sent to all DHCP servers configured for the associated
relay agent (if any are known). relay agent (if any are known).
6.2. Receiving the DHCPLEASEQUERY Message 6.3. Receiving the DHCPLEASEQUERY Message
A DHCPLEASEQUERY message MUST have a non-zero ciaddr and MUST have a A DHCPLEASEQUERY message MUST have a non-zero giaddr. The DHCPLEASE-
non-zero giaddr. The DHCP server which receives a DHCPLEASEQUERY QUERY message MUST have at least one of: a non-zero ciaddr, a non-
message MUST base its response (if any) on the IP address represented zero "htype"/"hlen"/"chaddr", or a client-id. It MAY have more than
by the ciaddr in the DHCPLEASEQUERY message. The giaddr is used only one.
for the destination address of any generated response and, while
required, is not otherwise used in generating the response to the
DHCPLEASEQUERY message.
6.3. Responding to the DHCPLEASEQUERY Message The DHCP server which receives a DHCPLEASEQUERY message MUST base its
response (if any) on the IP address represented by the ciaddr in the
DHCPLEASEQUERY message if one is given.
If an IP address is not given, then the receiving DHCP server MUST
base its response on the client-id and any MAC address contained in
the "htype", "hlen", and "chaddr" fields of the DHCP packet.
The giaddr is used only for the destination address of any generated
response and, while required, is not otherwise used in generating the
response to the DHCPLEASEQUERY message.
6.4. Responding to the DHCPLEASEQUERY Message
The DHCP server MUST respond to a DHCPLEASEQUERY message with a The DHCP server MUST respond to a DHCPLEASEQUERY message with a
DHCPACK message if the ciaddr corresponds to an IP address which is DHCPKNOWN message if the ciaddr corresponds to an IP address which is
managed by the DHCP server. managed by the DHCP server or if there is an IP address which has
most recently been acccess by any DHCP client described by any
client-id option and/or MAC address information in the "htype",
"hlen", and "chaddr" fields of the DHCPLEASEQUERY request.
The DHCP server SHOULD respond to a DHCPLEASEQUERY message with a In the event that an IP address appears in the "ciaddr" field, then
DHCPACK if the ciaddr corresponds to an IP address about which the the information returned should be about that IP address regardless
DHCP server has definitive information, even if the ciaddr does not of the values of the MAC address and/or client-id option.
correspond to an IP address which might be dynamically allocated by
the DHCP server -- for example, a statically allocated IP address
which is known to be reserved for a particular device by the DHCP
server.
The DHCP server MUST respond to the DHCPLEASEQUERY with a DHCPNAK if If the Reservation bit is not set in the "flags" field of the DHCP
the DHCP server supports the DHCPLEASEQUERY message but does not have packet (see [RFC 2131]), then the DHCP server SHOULD NOT respond to a
definitive information concerning the IP address in the ciaddr. When DHCPLEASEQUERY message with a DHCPKNOWN if the "ciaddr" corresponds
responding with a DHCPNAK, the DHCP server SHOULD NOT include other to an IP address about which the DHCP server has definitive informa-
DHCP options in the response. tion but which has no DHCP client information associated with it. As
well, if the "ciaddr" does not contain an IP address and there is a
MAC address or client-id in the DHCPLEASEQUERY request, if the Reser-
vation bit is not set then the DHCP server SHOULD NOT respond with a
DHCPKNOWN unless the client specified in the DHCPLEASEQUERY has
accessed an IP address.
Conversely, if the Reservation bit is set in the "flags" field of the
DHCP packet, then the DHCP server SHOULD respond with information
contained in the reservation associated with either the IP address
specified in the "ciaddr" or the client specified in the MAC adddress
and/or client-id if there is no actual usage information concerning
the association of the IP address or specified client.
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
address in an associated-ip option), the the DHCP server MUST set the
Reservation bit in the "flags" field of the DHCPKNOWN message.
Thus, a DHCP server SHOULD, but doesn't have to implement reservation
support if it implements support for the DHCPLEASEQUERY message, but
if it does, it MUST set the Reservation bit in the "flags" field
whenever the primary information it returns in the DHCPKNOWN message
is based on a reservation.
The DHCP server MUST respond to the DHCPLEASEQUERY with a DHCPUNKNOWN
if the DHCP server supports the DHCPLEASEQUERY message but does not
have definitive information concerning the IP address in the ciaddr
(if any) or if it does not have definitive information concerning the
DHCP client specified in the "htype", "hlen", and "chaddr" fields or
the client-id option. When responding with a DHCPUNKNOWN, the DHCP
server SHOULD NOT include other DHCP options in the response.
A DHCP server which does not support the DHCPLEASEQUERY message MUST 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 DHCPACK: When responding to a DHCPLEASEQUERY message with a DHCPKNOWN:
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,
then the IP address most recently accessed by that client SHOULD
be used as the IP address to place into the "ciaddr".
In this case, all of the IP addresses which are recorded as hav-
ing been most recently been accessed by this client should be
returned in the associated-ip option (option TBD) if that option
is included in the dhcp-parameter-request-list option in the
request. They should appear in order of increasing age of
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 51) is specified in the
Parameter Request List and if there is a currently valid lease Parameter Request List and if there is a currently valid lease
for the IP address specified in the ciaddr, then the DHCP server for the IP address specified in the ciaddr, then the DHCP server
MUST return this option in the DHCPACK with its value equal to MUST return this option in the DHCPKNOWN with its value equal to
the time remaining until lease expiration. If there is no valid the time remaining until lease expiration. If there is no valid
lease for the IP address, then the server MUST NOT return the IP lease for the IP address, then the server MUST NOT return the IP
Address Lease Time option (option 51). This allows the reques- Address Lease Time option (option 51). This allows the reques-
tor (i.e. the access concentrator) to determine if there is tor (i.e. the access concentrator) to determine if there is
currently a valid lease for the IP address as well as the time currently a valid lease for the IP address as well as the time
until the lease expiration. 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.
o If the DHCP server has information about the most recent device o If the DHCP server has information about the most recent device
associated with the IP address specified in the ciaddr, then the associated with the IP address specified in the ciaddr, then the
DHCP server MUST encode the physical address of that device in DHCP server MUST encode the physical address of that device in
the htype, hlen, and chaddr fields. Otherwise, the values of the htype, hlen, and chaddr fields. Otherwise, the values of
htype, hlen, and chaddr MUST be set to 0 in the DHCPACK. If the htype, hlen, and chaddr MUST be set to 0 in the DHCPKNOWN. If
IP Address Lease Time (option 51) is returned in the DHCPACK the IP Address Lease Time (option 51) is returned in the
(indicating a currently valid lease by some device for this IP DHCPKNOWN (indicating a currently valid lease by some device for
address), the DHCP server MUST encode the physical address of this IP address), the DHCP server MUST encode the physical
the device which owns the lease in the htype, hlen, and chaddr address of the device which owns the lease in the htype, hlen,
fields. and chaddr fields.
o If the Relay Agent Information (option 82) is specified in the o 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 and if the DHCP server has saved the
information contained in the most recent Relay Agent Information information contained in the most recent Relay Agent Information
option, the DHCP server MUST include that information in a Relay option, the DHCP server MUST include that information in a Relay
Agent Information option in the DHCPACK. Agent Information option in the DHCPKNOWN.
In environments with non-DHCP-enabled devices, when the DHCP In environments with non-DHCP-enabled devices, when the DHCP
server knows the network access information (perhaps through server knows the network access information (perhaps through
server configuration), the DHCP server MAY generate its own server configuration), the DHCP server MAY generate its own
Relay Agent Information option value in the DHCPACK; in such Relay Agent Information option value in the DHCPKNOWN; in such
cases, the DHCP server MUST generate an option value that the cases, the DHCP server MUST generate an option value that the
access concentrator can process. access concentrator can process.
o The DHCPACK message SHOULD include the values of all other o The DHCPKNOWN message SHOULD include the values of all other
options not specifically discussed above that were requested in options not specifically discussed above that were requested in
the Parameter Request List of the DHCPLEASEQUERY message. the Parameter Request List of the DHCPLEASEQUERY message.
The DHCP server uses information from the lease binding database to The DHCP server uses information from the lease binding database to
supply the DHCPACK option values. supply the DHCPKNOWN option values.
In order to accommodate DHCPLEASEQUERY messages sent to a DHCP Fail- In order to accommodate DHCPLEASEQUERY messages sent to a DHCP Fail-
over secondary server [FAILOVER] when the primary server is down, the over secondary server [FAILOVER] when the primary server is down, the
primary server MUST communicate the Relay Agent Information option primary server MUST communicate the Relay Agent Information option
(82) values to the secondary server via the DHCP Failover BNDUPD mes- (82) values to the secondary server via the DHCP Failover BNDUPD mes-
sages. sages.
The server expects a giaddr in the DHCPLEASEQUERY message, and uni- The server expects a giaddr in the DHCPLEASEQUERY message, and uni-
casts the DHCPACK or DHCPNAK to the giaddr. If the giaddr field is casts the DHCPKNOWN or DHCPUNKNOWN to the giaddr. If the giaddr
zero, then the DHCP server does not reply to the DHCPLEASEQUERY mes- field is zero, then the DHCP server does not reply to the DHCPLEASE-
sage. QUERY message.
6.4. Receiving a DHCPACK or DHCPNAK response to the DHCPLEASEQUERY Mes- 6.5. Receiving a DHCPKNOWN or DHCPUNKNOWN response to the DHCPLEASE-
sage QUERY Message
When a DHCPACK message is received in response to the DHCPLEASEQUERY When a DHCPKNOWN message is received in response to the DHCPLEASE-
message and the DHCPACK has an IP Address Lease Time option value QUERY message and the DHCPKNOWN has an IP Address Lease Time option
that is non-zero, it means that there is a currently active lease for value that is non-zero, it means that there is a currently active
this IP address in this DHCP server. The access concentrator SHOULD lease for this IP address in this DHCP server. The access
use the information in the htype, hlen, and chaddr fields of the concentrator SHOULD use the information in the htype, hlen, and
DHCPACK as well as any Relay Agent Information option information chaddr fields of the DHCPKNOWN as well as any Relay Agent Information
included in the packet to refresh its location information for this option information included in the packet to refresh its location
IP address. information for this IP address.
When a DHCPACK message is received in response to the DHCPLEASEQUERY When a DHCPKNOWN message is received in response to the DHCPLEASE-
message and the DHCPACK has no IP Address Lease Time option (though QUERY message and the DHCPKNOWN has no IP Address Lease Time option
one was requested in the Parameter Request List), that means that (though one was requested in the Parameter Request List), that means
there is no currently active lease for the IP address present in the that there is no currently active lease for the IP address present in
DHCP server. In this case, the access concentrator SHOULD cache this the DHCP server. In this case, the access concentrator SHOULD cache
information in order to prevent unacceptable loads on the access con- this information in order to prevent unacceptable loads on the access
centrator and the DHCP server in the face of a malicious or seriously concentrator and the DHCP server in the face of a malicious or seri-
compromised device downstream of the access concentrator. ously compromised device downstream of the access concentrator.
In either case, when a DHCPACK 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 DHCPNAK message is received by an access concentrator which When a DHCPUNKNOWN message is received by an access concentrator
has sent out a DHCPLEASEQUERY message, it means that the DHCP server which has sent out a DHCPLEASEQUERY message, it means that the DHCP
contacted supports the DHCPLEASEQUERY message but that the DHCP server contacted supports the DHCPLEASEQUERY message but that the
server not have definitive information concerning the IP address con- DHCP server not have definitive information concerning the IP address
tained in the ciaddr of the DHCPLEASEQUERY message. It doesn't contained in the ciaddr of the DHCPLEASEQUERY message. If there is
manage this IP address. no IP address in the ciaddr of the DHCPLEASEQUERY message, then a
DHCPUNKNOWN message means that the DHCP server does not have defini-
tive information concering the any DHCP client specified in the
"hlen", "htype", and "chaddr" fields or the client-id option of the
DHCPLEASEQUERY message.
The access concentrator SHOULD cache this information, and only The access concentrator SHOULD cache this information, and only
infrequently direct a DHCPLEASEQUERY message to a DHCP server that infrequently direct a DHCPLEASEQUERY message to a DHCP server that
responded to a DHCPLEASEQUERY message for a particular ciaddr with a responded to a DHCPLEASEQUERY message for a particular ciaddr with a
DHCPNAK. DHCPUNKNOWN.
6.5. Receiving no response to the DHCPLEASEQUERY Message 6.6. Receiving the 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 DHCPACK or DHCPNAK were o The DHCPLEASEQUERY or a corresponding DHCPKNOWN or DHCPUNKNOWN
lost during transmission or the DHCPLEASEQUERY arrived at the were lost during transmission or the DHCPLEASEQUERY arrived at
DHCP server but it was dropped because the server was too busy. the DHCP server 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 DHCPLEASE- In the first of the cases above, a retransmission of the
QUERY would be appropriate, but in the second of the two cases, a DHCPLEASEQUERY would be appropriate, but in the second of the two
retransmission would not be appropriate. There is no way to tell cases, a retransmission would not be appropriate. There is no way to
these two cases apart (other than, perhaps, because of a DHCP tell 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
packet every 10 seconds, and yet (if the access concentrator needs to packet every 10 seconds, and yet (if the access concentrator needs to
send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per
minute. minute.
6.7. Utilizing the DHCPLEASEQUERY message in a failover environment
When utilizing the DHCPLEASEQUERY message in an environment where multi-
ple DHCP server may contain authoritative information about the same IP
address (such as when failover [FAILOVER] is operating), there could be
some difficulty in deciding which results are the most useful if two
servers respond with DHCPKNOWN messages to the same query.
In this case, the client-last-transaction-time can be used to decide
which server has more recent information concerning the IP address
returned in the "ciaddr" field.
6.8. New options 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
6.8.1. client-last-transaction-time
This option SHOULD record the time of the most recent access of the
client. It is particularly useful when DHCPLEASEQUERY responses from
two different DHCP servers need to be compared, although it can be
useful in other situations. The value is a duration in seconds in
the past from when this IP address was most recently accessed by the
client specified.
The code for the this option is TBD. The length of the this option is
4 octets.
Code Len Seconds in the past
+-----+-----+-----+-----+-----+-----+
| TBD | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
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 13, line 13 skipping to change at page 19, line 25
authentication [DHCPAUTH]. With respect to authentication, the authentication [DHCPAUTH]. With respect to authentication, the
access concentrator acts as the "client". The use of "Authentication access concentrator acts as the "client". The use of "Authentication
Protocol 0" (using simple unencoded authentication token(s) between Protocol 0" (using simple unencoded authentication token(s) between
the access concentrator and the DHCP server) is straightforward. The the access concentrator and the DHCP server) is straightforward. The
use of "Authentication Protocol 1" (using "delayed authentication") use of "Authentication Protocol 1" (using "delayed authentication")
is under investigation, since it requires two message round trips. is under investigation, since it requires two message round trips.
Access concentrators SHOULD minimize potential denial of service Access concentrators SHOULD minimize potential denial of service
attacks on the DHCP servers by minimizing the generation of attacks on the DHCP servers by minimizing the generation of
DHCPLEASEQUERY messages. In particular, the access concentrator DHCPLEASEQUERY messages. In particular, the access concentrator
should employ negative caching (i.e. cache both DHCPACK and DHCPNAK should employ negative caching (i.e. cache both DHCPKNOWN and
responses to DHCPLEASEQUERY messages) and ciaddr restriction (i.e. DHCPUNKNOWN responses to DHCPLEASEQUERY messages) and ciaddr restric-
don't send a DHCPLEASEQUERY message with a ciaddr outside of the tion (i.e. don't send a DHCPLEASEQUERY message with a ciaddr outside
range of the attached broadband access networks). Together, these of the range of the attached broadband access networks). Together,
mechanisms limit the access concentrator to transmitting one these mechanisms limit the access concentrator to transmitting one
DHCPLEASEQUERY message (excluding message retries) per legitimate DHCPLEASEQUERY message (excluding message retries) per legitimate
broadband access network IP address after a reboot event. broadband access network IP address after a reboot event.
8. Acknowledgments 8. 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.
Ralph Droms, Mark Stapp and Andy Sudduth contributed to making the
draft more complete and helped add clarity.
9. References 9. References
[RFC 826] Plummer, D., "Ethernet Address Resolution Protocol: Or con- [RFC 826] Plummer, D., "Ethernet Address Resolution Protocol: Or con-
verting network protocol addresses to 48.bit Ethernet address for verting network protocol addresses to 48.bit Ethernet address for
transmission on Ethernet hardware", RFC 826, November 1982. transmission on Ethernet hardware", RFC 826, November 1982.
[RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC [RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC
951, September 1985. 951, September 1985.
[RFC 1542] Wimer, W., "Clarifications and Extensions for the [RFC 1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993. Bootstrap Protocol", RFC 1542, October 1993.
[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 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", Internet RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[BPI] CableLabs, "Baseline Privacy Interface Specification", SP-BPI- [BPI] CableLabs, "Baseline Privacy Interface Specification", SP-BPI-
I02-990319, March 1999, available at http://www.cablemodem.com/. I02-990319, March 1999, available at http://www.cablemodem.com/.
[BPI+] CableLabs, "Baseline Privacy Plus Interface Specification", [BPI+] CableLabs, "Baseline Privacy Plus Interface Specification",
SP-BPI+-I04-000407, April 2000, available at SP-BPI+-I04-000407, April 2000, available at
http://www.cablemodem.com/. http://www.cablemodem.com/.
[DHCPAUTH] Droms, R., Arbaugh, W., "Authentication for DHCP Mes- [DHCPAUTH] Droms, R., Arbaugh, W., "Authentication for DHCP Mes-
sages", draft-ietf-dhc-authentication-14.txt, July 2000. sages", draft-ietf-dhc-authentication-14.txt, July 2000.
skipping to change at page 14, line 37 skipping to change at page 21, line 5
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-08.txt, November 2000.
[RELAYAGENTINFO] Patrick, M., "DHCP Relay Agent Information Option",
draft-ietf-dhc-agent-options-12.txt, October 2000.
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 (2000). 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-
skipping to change at page 15, line 38 skipping to change at page 22, line 5
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 Open Issues
These issues need to be resolved by the working group: These issues need to be resolved by the working group:
1. May the DHCPLEASEQUERY message be sent by parties other than 1. Should the DHCPLEASEQUERY message be extended to find lease
relay agents?
[Resolved] Sure, you can't stop them in any case.
2. Should the DHCPLEASEQUERY message be extended to find lease
information by physical address or by DHCP Client ID? This information by physical address or by DHCP Client ID? This
might be useful for non-router access concentrators. might be useful for non-router access concentrators.
[Resolved] There has been no working group interest in this [?] This capability has been added to the current draft since
aspect of the DHCPLEASEQUERY message, so it has been specifi- we found it quite useful, and thought that others might as
cally excluded. well.
3. How can the DHCPLEASEQUERY message exchange be modified to lev-
erage the better DHCP authentication protocol types?
[Unresolved]
 End of changes. 

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