draft-ietf-dhc-leasequery-05.txt   draft-ietf-dhc-leasequery-06.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
March 2003 October 2003
Expires September 2003 Expires April 2004
DHCP Lease Query DHCP Lease Query
<draft-ietf-dhc-leasequery-05.txt> <draft-ietf-dhc-leasequery-06.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 2, line 7 skipping to change at page 2, line 7
A DHCP server contains considerable authoritative information A DHCP server contains considerable authoritative information
concerning the IP addresses it has leased to DHCP clients. Other concerning the IP addresses it has leased to DHCP clients. Other
processes and devices, many that already send and receive DHCP format processes and devices, many that already send and receive DHCP format
packets, sometimes need to access this information. The leasequery packets, sometimes need to access this information. The leasequery
protocol is designed to give these processes and devices a protocol is designed to give these processes and devices a
lightweight way to access information that may be critical to their lightweight way to access information that may be critical to their
operation. operation.
1. Introduction 1. Introduction
A DHCP server contains considerable authoritative information con- A DHCP server contains considerable authoritative information
cerning the IP addresses it has leased to DHCP clients. Other concerning the IP addresses it has leased to DHCP clients. Other
processes and devices, many that already send and receive DHCP format processes and devices, many that already send and receive DHCP format
packets, sometimes need to access this information. The leasequery packets, sometimes need to access this information. The leasequery
protocol is designed to give these processes and devices a light- protocol is designed to give these processes and devices a
weight way to access information that may be critical to their opera- lightweight way to access information that may be critical to their
tion. operation.
For example, access concentrators that act as DHCP relay agents some- For example, access concentrators that act as DHCP relay agents
times derive information important to their operation by extracting sometimes derive information important to their operation by
data out of the DHCP packets they forward, a process known as "glean- extracting data out of the DHCP packets they forward, a process known
ing". Unfortunately, the typical access concentrator loses its as "gleaning". Unfortunately, the typical access concentrator loses
gleaned information when the access concentrator is rebooted or is its gleaned information when the access concentrator is rebooted or
replaced. This memo proposes that when gleaned DHCP information is is replaced. This memo proposes that when gleaned DHCP information
not available, the access concentrator/relay agent can obtain the is not available, the access concentrator/relay agent can obtain the
location information directly from the DHCP server(s) using the new location information directly from the DHCP server(s) using the
lightweight DHCPLEASEQUERY message. DHCPLEASEQUERY message.
To continue this example in more depth, in many broadband access net- To continue this example in more depth, in many broadband access
works, the access concentrator needs to associate an IP address lease networks, the access concentrator needs to associate an IP address
to the correct endpoint location, which includes knowledge of the lease to the correct endpoint location, which includes knowledge of
host hardware address, the port or virtual circuit that leads to the the host hardware address, the port or virtual circuit that leads to
host, and/or the hardware address of the intervening subscriber the host, and/or the hardware address of the intervening subscriber
modem. This is particularly important when one or more IP subnets modem. This is particularly important when one or more IP subnets
are shared among many ports, circuits, and modems. Representative are shared among many ports, circuits, and modems. Representative
cable and DSL environments are depicted in Figures 1 and 2 below. cable and DSL environments are depicted in Figures 1 and 2 below.
+--------+ +---------------+ +--------+ +---------------+
| DHCP | | DOCSIS CMTS | | DHCP | | DOCSIS CMTS |
| Server |-...-| or DVB INA |------------------- | Server |-...-| or DVB INA |-------------------
+--------+ | (Relay Agent) | | | +--------+ | (Relay Agent) | | |
+---------------+ +------+ +------+ +---------------+ +------+ +------+
|Modem1| |Modem2| |Modem1| |Modem2|
skipping to change at page 3, line 19 skipping to change at page 3, line 19
+------+ +------+ +------+ +------+
|Modem1| |Modem2| |Modem1| |Modem2|
+------+ +------+ +------+ +------+
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|Host1| |Host2| |Host3| |Host1| |Host2| |Host3|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 2: DSL Environment for DHCPLEASEQUERY Figure 2: DSL Environment for DHCPLEASEQUERY
Knowledge of this location information can benefit the access concen- Knowledge of this location information can benefit the access
trator in several ways: concentrator in several ways:
1. The access concentrator can forward traffic to the access net- 1. The access concentrator can forward traffic to the access
work using the correct access network port, down the correct network using the correct access network port, down the correct
virtual circuit, through the correct modem, to the correct virtual circuit, through the correct modem, to the correct
hardware address. hardware address.
2. The access concentrator can perform IP source address verifica- 2. The access concentrator can perform IP source address
tion of datagrams received from the access network. The verif- verification of datagrams received from the access network.
ication may be based on the datagram source hardware address, The verification may be based on the datagram source hardware
the incoming access network port, the incoming virtual circuit, address, the incoming access network port, the incoming virtual
and/or the transmitting modem. circuit, and/or the transmitting modem.
3. The access concentrator can encrypt datagrams which can only be 3. The access concentrator can encrypt datagrams which can only be
decrypted by the correct modem, using mechanisms such as [BPI] decrypted by the correct modem, using mechanisms such as [BPI]
or [BPI+]. or [BPI+].
The access concentrator in this example obtains the location informa- The access concentrator in this example obtains the location
tion primarily from "gleaning" information from DHCP server responses information primarily from "gleaning" information from DHCP server
sent through the relay agent. When location information is not responses sent through the relay agent. When location information is
available from "gleaning", e.g. due to reboot, the access concentra- not available from "gleaning", e.g. because the access concentrator
tor can query the DHCP server(s) for location information using the has rebooted, the access concentrator can query the DHCP server(s)
DHCPLEASEQUERY message defined in this document. for location information using the DHCPLEASEQUERY message defined in
this document.
The DHCPLEASEQUERY message is a new DHCP message type transmitted The DHCPLEASEQUERY message is a new DHCP message type transmitted
from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware
relay agent sends the DHCPLEASEQUERY message when it needs to know relay agent sends the DHCPLEASEQUERY message when it needs to know
the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server
replies with a DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN replies with a DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN
message. The DHCPLEASEACTIVE response to a DHCPLEASEQUERY message message. The DHCPLEASEACTIVE response to a DHCPLEASEQUERY message
allows the relay agent to determine the IP endpoint location, and the allows the relay agent to determine the IP endpoint location, and the
remaining duration of the IP address lease. The DHCPLEASEKNOWN is remaining duration of the IP address lease. The DHCPLEASEKNOWN is
similar to a DHCPLEASEACTIVE message but indicates that there is no similar to a DHCPLEASEACTIVE message but indicates that there is no
currently active lease on the resultant IP address. The DHCPLEASEUN- currently active lease on the resultant IP address but that this DHCP
KNOWN message indicates that the DHCP server has no knowledge of the server is authoritative for this IP address. The DHCPLEASEUNKNOWN
message indicates that the DHCP server has no knowledge of the
information specified in the query (e.g., IP address, MAC address, or information specified in the query (e.g., IP address, MAC address, or
client-id option). client-id 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 infor- the information it returns -- it is simply designed to return
mation for which the DHCP server is an authoritative source to a information for which the DHCP server is an authoritative source to a
client which requests that information. It is designed to make it client which requests that information. It is designed to make it
straightforward for processes and devices which already interpret straightforward for processes and devices which already interpret
DHCP packets to access information from the DHCP server. DHCP packets to access information from the DHCP server.
2. Terminology 2. Terminology
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].
skipping to change at page 4, line 38 skipping to change at page 4, line 40
o "access concentrator" o "access concentrator"
An access concentrator is a router or switch at the broadband An access concentrator is a router or switch at the broadband
access provider's edge of a public broadband access network. access provider's edge of a public broadband access network.
This document assumes that the access concentrator includes the This document assumes that the access concentrator includes the
DHCP relay agent functionality. DHCP relay agent functionality.
o "DHCP client" o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain confi- A DHCP client is an Internet host using DHCP to obtain
guration parameters such as a network address. configuration parameters such as a network address.
o "DHCP relay agent" o "DHCP relay agent"
A DHCP relay agent is a third-party agent that transfers BOOTP A DHCP relay agent is a third-party agent that transfers BOOTP
and DHCP messages between clients and servers residing on dif- and DHCP messages between clients and servers residing on
ferent subnets, per [RFC 951] and [RFC 1542]. different subnets, per [RFC 951] and [RFC 1542].
o "DHCP server" o "DHCP server"
A DHCP server is an Internet host that returns configuration A DHCP server is an Internet host that returns configuration
parameters to DHCP clients. parameters to DHCP clients.
o "downstream" o "downstream"
Downstream is the direction from the access concentrator towards Downstream is the direction from the access concentrator towards
the broadband subscriber. the broadband subscriber.
o "gleaning" o "gleaning"
skipping to change at page 5, line 18 skipping to change at page 5, line 20
the broadband subscriber. the broadband subscriber.
o "gleaning" o "gleaning"
Gleaning is the extraction of location information from DHCP Gleaning is the extraction of location information from DHCP
messages, as the messages are forwarded by the DHCP relay agent messages, as the messages are forwarded by the DHCP relay agent
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
trator to forward traffic to a broadband-accessible host. This concentrator to forward traffic to a broadband-accessible host.
information includes knowledge of the host hardware address, the This information includes knowledge of the host hardware
port or virtual circuit that leads to the host, and/or the address, the port or virtual circuit that leads to the host,
hardware address of the intervening subscriber modem. and/or the hardware address of the intervening subscriber modem.
o "MAC address" o "MAC address"
In the context of a DHCP packet, a MAC address consists of the In the context of a DHCP packet, a MAC address consists of the
fields: hardware type "htype", hardware length "hlen", and fields: hardware type "htype", hardware length "hlen", and
client hardware address "chaddr". client hardware address "chaddr".
o "reservation"
At times it is convenient for an administrator to assign a fixed
IP address to a particular DHCP client. The DHCP server must be
configured with this DHCP client to IP address mapping, typi-
cally using the MAC address as the way to identify the client. A
reservation defines a mapping between a client and an IP address
but doesn't establish or record a lease binding for the IP
address. The DHCP client to IP address mapping, configured in
the DHCP server, is called a reservation for the purposes of
this document.
o "primary DHCP server" o "primary DHCP server"
The primary DHCP server in a DHCP Failover environment is con- The primary DHCP server in a DHCP Failover environment is
figured to provide primary service to a set of DHCP clients for configured to provide primary service to a set of DHCP clients
a particular set of subnet address pools. for 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
figured to act as backup to a primary server for a particular configured to act as backup to a primary server for a particular
set of subnet address pools. set of subnet address pools.
o "stable storage" o "stable storage"
Every DHCP server is assumed to have some form of what is called Every DHCP server is assumed to have some form of what is called
"stable storage". Stable storage is used to hold information "stable storage". Stable storage is used to hold information
concerning IP address bindings (among other things) so that this concerning IP address bindings (among other things) so that this
information is not lost in the event of a server failure which information is not lost in the event of a server failure which
requires restart of the server. requires restart of the server.
skipping to change at page 6, line 32 skipping to change at page 6, line 24
convenient manner. It is especially appropriate for processes and convenient manner. It is especially appropriate for processes and
devices which already interpret DHCP packets. devices which already interpret DHCP packets.
One important motivating example is that the DHCPLEASEQUERY message One important motivating example is that the DHCPLEASEQUERY message
allows access concentrators to send DHCPLEASEQUERY messages to DHCP allows access concentrators to send DHCPLEASEQUERY messages to DHCP
servers, to obtain location information of broadband access network servers, to obtain location information of broadband access network
devices. devices.
This document assumes that many access concentrators have an embedded This document assumes that many access concentrators have an embedded
DHCP relay agent functionality. Typical access concentrators include DHCP relay agent functionality. Typical access concentrators include
DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB Interac- DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB
tive Network Adapters (INAs) [EUROMODEM], and DSL Access Concentra- Interactive Network Adapters (INAs) [EUROMODEM], and DSL Access
tors. Concentrators.
The DHCPLEASEQUERY message is an optional extension to the DHCP pro-
tocol [RFC 2131].
In a DHCP Failover environment [FAILOVER], the DHCPLEASEQUERY message The DHCPLEASEQUERY message is an optional extension to the DHCP
can be sent to the primary or secondary DHCP server. In order for the protocol [RFC 2131].
secondary DHCP server to answer DHCPLEASEQUERY messages, the primary
DHCP server must send "interesting options" (such as the relay-
agent-information option [RFC 3046]) in Failover BNDUPD messages to
the secondary DHCP server, as recommended by section 7.1.1 of [FAIL-
OVER].
The DHCPLEASEQUERY message is a query message only, and does not The DHCPLEASEQUERY message is a query message only, and does not
affect the state of the IP address or the binding information associ- affect the state of the IP address or the binding information
ated with it. associated with it.
4. Design Goals 4. Design Goals
The goal of this document is to provide a lightweight mechanism for The goal of this document is to provide a lightweight mechanism for
processes or devices to access information contained in the DHCP processes or devices to access information contained in the DHCP
server. It is designed to allow processes and devices which already server. It is designed to allow processes and devices which already
process and interpret DHCP messages to access this information in a process and interpret DHCP messages to access this information in a
rapid and lightweight manner. rapid and lightweight manner.
Some of this information might be acquired in a different way, and Some of this information might be acquired in a different way, and
the following sections discuss some of these alternative approaches. the following sections discuss some of these alternative approaches.
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], and observe the origin and contents of the ARP Reply, to recon- 826], and observe the origin and contents of the ARP Reply, to
struct 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 pro- 2. the burden on the numerous subscriber hosts to receive and
cess 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 Client Functionality is Lacking
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 a primary
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].
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 net- mechanisms (ARP, SNMP, LDAP) because of the lack of additional
work traffic, but sometimes gleaning information can be incomplete. network traffic, but sometimes gleaning information can be
The access concentrator usually cannot glean information from any incomplete. The access concentrator usually cannot glean information
DHCP unicast (i.e. non-relayed) messages due to performance reasons. from any DHCP unicast (i.e. non-relayed) messages due to performance
Furthermore, the DHCP-gleaned location information often does not reasons. Furthermore, the DHCP-gleaned location information often
persist across access concentrator reboots (due to lack of stable does not persist across access concentrator reboots (due to lack of
storage), and almost never persists across concentrator replacements. stable storage), and almost never persists across concentrator
replacements.
4.4. DHCP Servers as a Reliable Source of Location Information 4.4. DHCP Servers as a 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
gle IP subnet extends behind many broadband modems). DHCP servers single IP subnet extends behind many broadband modems). DHCP servers
participate in all IP lease transactions (and therefore in all loca- participate in all IP lease transactions (and therefore in all
tion information updates) with DHCP clients, whereas access concen- location information updates) with DHCP clients, whereas access
trators sometimes miss some important lease transactions. concentrators sometimes miss some important lease transactions.
In a DHCP Failover environment [FAILOVER], the access concentrator An access concentrator can be configured with the IP addresses of
can query either the primary or secondary DHCP server, so that no one multiple different DHCP servers, so that no one DHCP server is a
DHCP server is a single point of failure. 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 for forwarding by the relay agent, thus minimizing configuration used for forwarding by the relay agent, thus minimizing configuration
requirements. requirements.
5. Protocol Overview 5. Protocol Overview
In the following discussion of the DHCPLEASEQUERY message, the client In the following discussion of the DHCPLEASEQUERY message, the client
of the message is assumed to be an access concentrator. Note that of the message is assumed to be an access concentrator. Note that
access concentrators are not the only allowed (or required) consumers access concentrators are not the only allowed (or required) consumers
of the information provided by the DHCPLEASEQUERY message, but they of the information provided by the DHCPLEASEQUERY message, but they
do give reader a concrete feel for how the message might be used. do give reader a concrete feel for how the message might be used.
The access concentrator initiates all DHCPLEASEQUERY message conver- The access concentrator initiates all DHCPLEASEQUERY message
sations. This document assumes that the access concentrator gleans conversations. This document assumes that the access concentrator
location information in its DHCP relay agent function. However, the gleans location information in its DHCP relay agent function.
location information is usually unavailable after the reboot or However, the location information is usually unavailable after the
replacement of the access concentrator. reboot or replacement of the access concentrator.
Suppose the access concentrator is a router, and further suppose that Suppose the access concentrator is a router, and further suppose that
the router receives an IP datagram to forward downstream to the pub- the router receives an IP datagram to forward downstream to the
lic broadband access network. If the location information for the public broadband access network. If the location information for the
downstream next hop is missing, the access concentrator sends one or downstream next hop is missing, the access concentrator sends one or
more DHCPLEASEQUERY message(s), each containing the IP address of the more DHCPLEASEQUERY message(s), each containing the IP address of the
downstream next hop in the "ciaddr" field. downstream next hop in the "ciaddr" field.
An alternative approach is to send in a DHCPLEASEQUERY message with An alternative approach is to send in a DHCPLEASEQUERY message with
the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen", the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen",
and "chaddr" fields) with a valid MAC address or a Client-identifier and "chaddr" fields) with a valid MAC address or a Client-identifier
option (option 61) appearing in the options area. In this case, the option (option 61) appearing in the options area. In this case, the
DHCP server SHOULD return an IP address in the "ciaddr" if it has any DHCP server SHOULD return an IP address in the "ciaddr" if it has any
record of the client described by the Client-identifier or MAC record of the client described by the Client-identifier or MAC
address. In the absence of specific configuration information to the address. In the absence of specific configuration information to the
contrary (see Section 6.4) it MUST be the IP address most recently contrary (see Section 6.4) it MUST be the IP address most recently
used by the client described by the MAC address or Client-identifier used by the client described by the MAC address or Client-identifier
option (or the client described by both, if both appear). option (or the client described by both, if both appear).
The DHCP servers that implement this protocol always send a response The DHCP servers that implement this protocol always send a response
to the DHCPLEASEQUERY message: either a DHCPLEASEKNOWN, DHCPLEASEAC- to the DHCPLEASEQUERY message: either a DHCPLEASEKNOWN,
TIVE or DHCPLEASEUNKNOWN (or in some cases, DHCPUNIMPLEMENTED). The DHCPLEASEACTIVE or DHCPLEASEUNKNOWN (or in some cases,
reasons why a DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN DHCPUNIMPLEMENTED). The reasons why a DHCPLEASEKNOWN, DHCPLEASEACTIVE
message might be generated are explained in the specific query or DHCPLEASEUNKNOWN message might be generated are explained in the
regimes, below. specific query regimes, below.
Servers which do not implement the DHCPLEASEQUERY message fall into Servers which do not implement the DHCPLEASEQUERY message fall into
two classes. Those that simply do not know about the DHCPLEASEQUERY two classes. Those that simply do not know about the DHCPLEASEQUERY
message will simply not respond to it, so clients which send the message will simply not respond to it, so clients which send the
DHCPLEASEQUERY message MUST be prepared to deal with this behavior. DHCPLEASEQUERY message MUST be prepared to deal with this behavior.
Servers which are aware of the DHCPLEASEQUERY message but do not Servers which are aware of the DHCPLEASEQUERY message but do not
implement it SHOULD respond with a DHCPUNIMPLEMENTED message but MAY implement it SHOULD respond with a DHCPUNIMPLEMENTED message but MAY
simply not respond. simply not respond.
The DHCPLEASEQUERY message can support three query regimes: The DHCPLEASEQUERY message can support three query regimes:
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 infor- DHCPLEASEQUERY message. The DHCP server will return any
mation that it has on the most recent client to have been information that it has on the most recent client to have been
assigned that IP address. assigned that IP address.
The DHCP server replies with a DHCPLEASEKNOWN or DHCPLEASEACTIVE The DHCP server replies with a DHCPLEASEKNOWN or DHCPLEASEACTIVE
message if the IP address in the DHCPLEASEQUERY message message if the IP address in the DHCPLEASEQUERY message
corresponds to an IP address about which the server has defini- corresponds to an IP address about which the server has
tive information (ie., it is authorized to lease this IP definitive information (ie., it is authorized to lease this IP
address). The server replies with a DHCPLEASEUNKNOWN message if address). The server replies with a DHCPLEASEUNKNOWN message if
the server does not have definitive information concerning the the server does not have definitive information concerning the
address in the DHCPLEASEQUERY message. address in the DHCPLEASEQUERY message.
A server which implements the DHCPLEASEQUERY message MUST A server which implements the DHCPLEASEQUERY message MUST
implement this capability. implement this capability.
o Query by MAC address: o Query by MAC address:
For this query, the requester supplies only a MAC address in the For this query, the requester supplies only a MAC address in the
DHCPLEASEQUERY message. The DHCP server will return any infor- DHCPLEASEQUERY message. The DHCP server will return any
mation that it has on the IP address most recently accessed by a information that it has on the IP address most recently accessed
client with that MAC address. In addition, it may supply addi- by a client with that MAC address. In addition, it may supply
tion IP addresses which have been associated with that MAC addition IP addresses which have been associated with that MAC
address in different subnets. Information about these bindings address in different subnets. Information about these bindings
can then be found using the Query by IP Address, described can then be found using the Query by IP Address, described
above. above.
The DHCP server replies with a DHCPLEASEKNOWN or DHCPLEASEACTIVE The DHCP server replies with a DHCPLEASEACTIVE message if the
message if the MAC address in the DHCPLEASEQUERY message MAC address in the DHCPLEASEQUERY message corresponds to an MAC
corresponds to an IP address about which the server has defini- address with an active lease on an IP address in this server.
tive information (ie., it is authorized to lease this IP The server replies with a DHCPLEASEUNKNOWN message if the server
address). The server replies with a DHCPLEASEUNKNOWN message if does not presently have an active lease by a client with this
the server does not have definitive information concerning the MAC address in this DHCP server.
MAC address in the DHCPLEASEQUERY message.
A server which implements the DHCPLEASEQUERY message SHOULD A server which implements the DHCPLEASEQUERY message SHOULD
implement this capability. If it does not, it SHOULD respond implement this capability. If it does not, it SHOULD respond
with a DHCPUNIMPLEMENTED message when it receives a query by MAC with a DHCPUNIMPLEMENTED message when it receives a query by MAC
address. address.
o Query by Client-identifier option: o Query by Client-identifier option:
For this query, the requester supplies only a client-id option For this query, the requester supplies only a client-id option
in the DHCPLEASEQUERY message. The DHCP server will return any in the DHCPLEASEQUERY message. The DHCP server will return any
information that it has on the IP address most recently accessed information that it has on the IP address most recently accessed
by a client with that client-id. In addition, it may supply by a client with that client-id. In addition, it may supply
addition IP addresses which have been associated with client-id addition IP addresses which have been associated with client-id
in different subnets. Information about these bindings can then in different subnets. Information about these bindings can then
be found using the Query by IP Address, described above. be found using the Query by IP Address, described above.
The DHCP server replies with a DHCPLEASEKNOWN or DHCPLEASEACTIVE The DHCP server replies with a DHCPLEASEACTIVE message if the
message if the client-id in the DHCPLEASEQUERY message client-id in the DHCPLEASEQUERY message currently has an active
corresponds to an IP address about which the server has defini- lease on an IP address in this DHCP server. The server replies
tive information (ie., it is authorized to lease this IP with a DHCPLEASEUNKNOWN message if the server does not have an
address). The server replies with a DHCPLEASEUNKNOWN message if active lease by a client with this client-id.
the server does not have definitive information concerning the
client-id in the DHCPLEASEQUERY message.
A server which implements the DHCPLEASEQUERY message SHOULD A server which implements the DHCPLEASEQUERY message SHOULD
implement this capability. If it does not, it SHOULD respond implement this capability. If it does not, it SHOULD respond
with a DHCPUNIMPLEMENTED message when it receives a query by with a DHCPUNIMPLEMENTED message when it receives a query by
Client-identifier option address. Client-identifier option address.
Generally, the query by IP address is likely to be the most efficient Generally, the query by IP address is likely to be the most efficient
and widely implemented form of leasequery, and it SHOULD be used if and widely implemented form of leasequery, and it SHOULD be used if
at all possible. Use of the other two query formats SHOULD be minim- at all possible. Use of the other two query formats SHOULD be
ized, as they can potentially place a large load on some servers. minimized, as they can potentially place a large load on some
servers.
The DHCPLEASEKNOWN or DHCPLEASEACTIVE message reply MUST always con- The DHCPLEASEKNOWN or DHCPLEASEACTIVE message reply MUST always
tain the IP address in the ciaddr field and SHOULD contains the phy- contain the IP address in the ciaddr field. The DHCPLEASEACTIVE
sical address of the IP address lease owner in the "htype", "hlen", message SHOULD contains the physical address of the IP address lease
and "chaddr" fields. The Parameter Request List (option 55) can be owner in the "htype", "hlen", and "chaddr" fields. The Parameter
used to request specific options to be returned about the IP address Request List (option 55) can be used to request specific options to
in the ciaddr. The reply often contains the time until expiration of be returned about the IP address in the ciaddr. The reply often
the lease, and the original contents of the Relay Agent Information contains the time until expiration of the lease, and the original
option [RFC 3046]. The access concentrator uses the "chaddr" and contents of the Relay Agent Information option [RFC 3046]. The
Relay Agent Information option to construct location information, access concentrator uses the "chaddr" and Relay Agent Information
which can be cached on the access concentrator until lease expira- option to construct location information, which can be cached on the
tion. access concentrator until lease expiration.
Any DHCP server which supports the DHCPLEASEQUERY message SHOULD save Any DHCP server which supports the DHCPLEASEQUERY message SHOULD save
the information from the most recent Relay Agent Information option the information from the most recent Relay Agent Information option
(option 82) [RFC 3046] associated with every IP address which it (option 82) [RFC 3046] associated with every IP address which it
serves. It is assumed that most clients which generate the DHCPLEASE- serves. It is assumed that most clients which generate the
QUERY message will ask for the Relay Agent Information option (option DHCPLEASEQUERY message will ask for the Relay Agent Information
82) in the Parameter Request List (option 55), and so supporting the option (option 82) in the Parameter Request List (option 55), and so
DHCPLEASEQUERY message without having the Relay Agent Information supporting the DHCPLEASEQUERY message without having the Relay Agent
option around to return to the client is likely to be less than help- Information option around to return to the client is likely to be
ful. less than helpful.
A server which implements DHCPLEASEQUERY SHOULD also save the infor- A server which implements DHCPLEASEQUERY SHOULD also save the
mation on the most recent Vendor class identifier, option 60, associ- information on the most recent Vendor class identifier, option 60,
ated with each IP address, since this option is also a likely candi- associated with each IP address, since this option is also a likely
date to be requested by clients sending the DHCPLEASEQUERY message. candidate to be requested by clients sending the DHCPLEASEQUERY
message.
6. Protocol Details 6. Protocol Details
6.1. Definitions required for DHCPLEASEQUERY processing 6.1. Definitions required for DHCPLEASEQUERY processing
The operation of the DHCPLEASEQUERY message requires the definition The operation of the DHCPLEASEQUERY message requires the definition
of the following new and extended values for the DHCP packet beyond of the following new and extended values for the DHCP packet beyond
those defined by [RFC 2131] and [RFC 2132]. See also Section 8, IANA those defined by [RFC 2131] and [RFC 2132]. See also Section 8, IANA
considerations. considerations.
1. The message type option (option 53) from [RFC 2132] requires 1. The message type option (option 53) from [RFC 2132] requires
five new values: The DHCPLEASEQUERY message itself and its five new values: one for the DHCPLEASEQUERY message itself and
three possible responses DHCPLEASEKNOWN, DHCPLEASEACTIVE, and one for each of its four possible responses DHCPLEASEKNOWN,
DHCPLEASEUNKNOWN, and DHCPUNIMPLEMENTED. The values of these DHCPLEASEACTIVE, DHCPLEASEUNKNOWN, and DHCPUNIMPLEMENTED. The
message types are shown below in a reproduction of the table values of these message types are shown below in a reproduction
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 DHCPLEASEKNOWN TBD DHCPLEASEKNOWN
TBD DHCPLEASEUNKNOWN TBD DHCPLEASEUNKNOWN
TBD DHCPLEASEACTIVE TBD DHCPLEASEACTIVE
TBD DHCPUNIMPLEMENTED TBD DHCPUNIMPLEMENTED
2. There is a new bit defined in the "flags" field of the DHCP 2. There is a new option, the client-last-transaction-time:
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|R| 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 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 DHCPLEASEKNOWN 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 situa- need to be compared, although it can be useful in other
tions. The value is a duration in seconds from the current situations. The value is a duration in seconds from the
time into the past when this IP address was most recently the current time into the past when this IP address was most
subject of communication between the client and the DHCP recently the subject of communication between the client and
server. the DHCP server.
This MUST NOT be an absolute time. This MUST NOT be an abso- This MUST NOT be an absolute time. This MUST NOT be an
lute number of seconds since Jan 1, 1970. Instead, this MUST absolute number of seconds since Jan 1, 1970. Instead, this
be an integer number of seconds in the past from the time the MUST be an integer number of seconds in the past from the time
DHCPLEASEKNOWN message is sent that the client last dealt with the DHCPLEASEACTIVE message is sent that the client last dealt
this server about this IP address. In the same way that the IP with this server about this IP address. In the same way that
Address Lease Time option (option 51) encodes a lease time the IP Address Lease Time option (option 51) encodes a lease
which is a number of seconds into the future from the time the time which is a number of seconds into the future from the time
message was sent, this option encodes a value which is a number the message was sent, this option encodes a value which is a
of seconds into the past from when the message was sent. number of seconds into the past from when the message was sent.
The code for the this option is TBD. The length of the this The code for the this option is TBD. The length of the this
option is 4 octets. option is 4 octets.
Code Len Seconds in the past Code Len Seconds in the past
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD | 4 | t1 | t2 | t3 | t4 | | TBD | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
4. There in a second new option, the associated-ip option: 3. There in a second new option, the associated-ip option:
associated-ip associated-ip
This option is used to return all of the IP addresses associ- This option is used to return all of the IP addresses
ated with the DHCP client specified in a particular DHCPLEASE- associated with the DHCP client specified in a particular
QUERY message. DHCPLEASEQUERY message.
The code for this option is TBD. The minimum length for this 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 option is 4 octets, and the length MUST always be a multiple of
4. 4.
Code Len Address 1 Address 2 Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+-----+--
| TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | ... | TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+-----+-----+--
6.2. Sending the DHCPLEASEQUERY Message 6.2. Sending the DHCPLEASEQUERY Message
The DHCPLEASEQUERY message is typically sent by an access concentra- The DHCPLEASEQUERY message is typically sent by an access
tor. The DHCPLEASEQUERY message uses the DHCP message format as concentrator. The DHCPLEASEQUERY message uses the DHCP message
described in [RFC 2131], and uses message number TBD in the DHCP Mes- format as described in [RFC 2131], and uses message number TBD in the
sage Type option (option 53). The DHCPLEASEQUERY message has the DHCP Message Type option (option 53). The DHCPLEASEQUERY message has
following pertinent message contents: the following pertinent message contents:
o The giaddr MUST be set to the IP address of the requester (i.e. o The giaddr MUST be set to the IP address of the requester (i.e.
the access concentrator). The giaddr is independent of the the access concentrator). The giaddr is independent of the
"ciaddr" field to be searched -- it is simply the return address "ciaddr" field to be searched -- it is simply the return address
of for the DHCPLEASEKNOWN or DHCPLEASEUNKNOWN message from the of for the DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN
DHCP server. message from the DHCP server.
o The Parameter Request List option (option 55) SHOULD be set to o The Parameter Request List option (option 55) SHOULD be set to
the options of interest to the requester. The interesting the options of interest to the requester. The interesting
options are likely to include the IP Address Lease Time option options are likely to include the IP Address Lease Time option
(option 51), the Relay Agent Information option (option 82) and (option 51), the Relay Agent Information option (option 82) and
possibly the Vendor class identifier option (option 60). In the possibly the Vendor class identifier option (option 60). In the
absence of a Parameter Request List option, the server will absence of a Parameter Request List option, the server will
return the same options it would return for a DHCPREQUEST mes- return the same options it would return for a DHCPREQUEST
sage which didn't contain a DHCPLEASEQUERY message, which message which didn't contain a DHCPLEASEQUERY message, which
includes those mandated by [RFC 2131, Section 4.3.1] as well as includes those mandated by [RFC 2131, Section 4.3.1] as well as
any options which the server was configured to always return to any options which the server was configured to always return to
a client. a client.
o The Reservation bit in the "flags" field of the DHCP packet (see
[RFC 2131] and Section 6.1 of this document) is not used when
sending a DHCPLEASEQUERY message.
Additional details concerning different query types are: Additional details concerning different query types are:
o Query by IP address: o Query by IP address:
The values of htype, hlen, and chaddr MUST be set to 0. The values of htype, hlen, and chaddr MUST be set to 0.
The "ciaddr" field MUST be set to the IP address of the lease to The "ciaddr" field MUST be set to the IP address of the lease to
be queried. be queried.
The Client-identifier option (option 61) MUST NOT appear in the The Client-identifier option (option 61) MUST NOT appear in the
skipping to change at page 15, line 27 skipping to change at page 14, line 51
The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is
known to possess authoritative information concerning the IP address. known to possess authoritative information concerning the IP address.
The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, The DHCPLEASEQUERY message MAY be sent to more than one DHCP server,
and in the absence of information concerning which DHCP server might and in the absence of information concerning which DHCP server might
possess authoritative information concerning the IP address, it possess authoritative information concerning the IP address, it
SHOULD be sent to all DHCP servers configured for the associated SHOULD be sent to all DHCP servers configured for the associated
relay agent (if any are known). relay agent (if any are known).
6.3. Receiving the DHCPLEASEQUERY Message 6.3. Receiving the DHCPLEASEQUERY Message
A DHCPLEASEQUERY message MUST have a non-zero giaddr. The DHCPLEASE- A DHCPLEASEQUERY message MUST have a non-zero giaddr. The
QUERY message MUST have exactly one of: a non-zero ciaddr, a non- DHCPLEASEQUERY message MUST have exactly one of: a non-zero ciaddr,
zero "htype"/"hlen"/"chaddr", or a Client-identifier. a non-zero "htype"/"hlen"/"chaddr", or a Client-identifier.
The DHCP server which receives a DHCPLEASEQUERY message MUST base its The DHCP server which receives a DHCPLEASEQUERY message MUST base its
response on the particular data item used in the query. response on the particular data item used in the query.
The giaddr is used only for the destination address of any generated The giaddr is used only for the destination address of any generated
response and, while required, is not otherwise used in generating the response and, while required, is not otherwise used in generating the
response to the DHCPLEASEQUERY message. It MUST NOT be used to res- response to the DHCPLEASEQUERY message. It MUST NOT be used to
trict the processing of the query in any way, and MUST NOT be used restrict the processing of the query in any way, and MUST NOT be used
locate a subnet to which the ciaddr (if any) must belong. locate a subnet to which the ciaddr (if any) must belong.
6.4. Responding to the DHCPLEASEQUERY Message 6.4. Responding to the DHCPLEASEQUERY Message
There are four possible responses to a DHCPLEASEQUERY message: There are four possible responses to a DHCPLEASEQUERY message:
o DHCPLEASEKNOWN o DHCPLEASEKNOWN
The server MUST respond with a DHCPLEASEKNOWN message if this The server MUST respond with a DHCPLEASEKNOWN message if this
server has information about the IP address or client in ques- server has information about the IP address, but there is no
tion, but there is no active lease for the IP address or client active lease for the IP address. The DHCPLEASEKNOWN message is
specified in the query. If the query was by IP address, then only returned for a query by IP address, and indicates that the
the DHCPLEASEKNOWN message indicates that this server manages server manages this IP address but there is no currently active
this IP address. In the case where a client was specified either lease on this IP address.
by Client-identifier or MAC address, then the DHCPLEASEKNOWN
message indicates that the client is known to the DHCP server,
and was the most recent client associated with a particular IP
address.
For any type of query, if the client specified in the DHCPLEASE-
KNOWN message has a reservation for the IP address specifed in
the ciaddr, then the server MUST set the R (reservation) bit in
the DHCPLEASEKNOWN message.
o DHCPLEASEUNKNOWN o DHCPLEASEUNKNOWN
The DHCPLEASEKNOWN message indicates that the server knows noth- The DHCPLEASEUNKNOWN message indicates that the server does not
ing about the IP address or client specified in the DHCPLEASE- manage the IP address or the client specified in the
QUERY message. DHCPLEASEQUERY message does not currently have a lease on an IP
address.
The server MUST response with a DHCPLEASEKNOWN message when this
server has no information about the IP address or client speci-
fied in the DHCPLEASEQUERY message.
When responding with a DHCPLEASEUNKNOWN, the DHCP server SHOULD When responding with a DHCPLEASEUNKNOWN, the DHCP server SHOULD
NOT include other DHCP options in the response. The R (reserva- NOT include other DHCP options in the response.
tion) bit MUST NOT be set in the "flags" field of the DHCP
packet.
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.
In some cases, the DHCP server MAY be configured to return a
DHCPLEASEACTIVE message when there is no active lease but when
there is a reservation by the specified client for the IP
address in the "ciaddr" field of the DHCPLEASEACTIVE message. A
server would be so configured when it was desired that the
access concentrator would allow access to IP addresses which are
not DHCP clients. In this case the DHCP server SHOULD NOT place
an IP Address Lease Time (option 51) in the DHCPLEASEACTIVE mes-
sage, allowing the access concentrator to determine that this is
a DHCPLEASEACTIVE message for an IP address without a currently
active lease.
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.
If the client returned in the DHCPLEASEACTIVE message has a
reservation for that IP address recorded in the DHCP server,
then the R (reservation) bit MUST be set in the "flags" field of
the DHCP packet.
o DHCPUNIMPLEMENTED o DHCPUNIMPLEMENTED
The DHCPUNIMPLEMENTED response to the DHCPLEASEQUERY message The DHCPUNIMPLEMENTED response to the DHCPLEASEQUERY message
indicates that the particular form of DHCPLEASEQUERY used is not indicates that the particular form of DHCPLEASEQUERY used is not
implemented in this DHCP server. It may mean that the DHCPLEASE- implemented in this DHCP server. It may mean that the
QUERY message as a whole is not implemented by this DHCP server DHCPLEASEQUERY message as a whole is not implemented by this
although it is usually used to indicate that a query by Client- DHCP server although it is usually used to indicate that a query
identifier or MAC address is not implemented by a DHCP server by Client-identifier or MAC address is not implemented by a DHCP
that otherwise supports a DHCPLEASEQUERY by IP address. server that otherwise supports a DHCPLEASEQUERY by IP address.
The DHCPUNIMPLEMENTED message can apply to any unimplemented The DHCPUNIMPLEMENTED message can apply to any unimplemented
messages, and MAY be used to respond to messages other than messages, and MAY be used to respond to messages other than
DHCPLEASEQUERY. DHCPLEASEQUERY.
6.4.1. Determining the IP address to which to respond 6.4.1. Determining the IP address to which to respond
Since the response to a DHCPLEASEQUERY request can only contain full Since the response to a DHCPLEASEQUERY request can only contain full
information about one IP address -- the one that appears in the information about one IP address -- the one that appears in the
"ciaddr" field -- determination of which IP address to which to "ciaddr" field -- determination of which IP address to which to
skipping to change at page 17, line 44 skipping to change at page 16, line 39
DHCPLEASEKNOWN message. DHCPLEASEKNOWN message.
If the IP address is not managed by the DHCP server, then a If the IP address is not managed by the DHCP server, then a
DHCPLEASEUNKNOWN message must be returned. DHCPLEASEUNKNOWN message must be returned.
If the "ciaddr" field of the DHCPLEASEQUERY is zero, then the If the "ciaddr" field of the DHCPLEASEQUERY is zero, then the
DHCPLEASEQUERY message is a query by Client-identifier or MAC DHCPLEASEQUERY message is a query by Client-identifier or MAC
address. In this case, the client's identity is any client which has address. In this case, the client's identity is any client which has
proffered an identical Client-identifier option (if the Client- proffered an identical Client-identifier option (if the Client-
identifier option appears in the DHCPLEASEQUERY message), or an identifier option appears in the DHCPLEASEQUERY message), or an
identical MAC address (if the MAC address fields in the DHCPLEASE- identical MAC address (if the MAC address fields in the
QUERY message are non-zero). This client matching approach will, for DHCPLEASEQUERY message are non-zero). This client matching approach
the purposes of this section, be described as "Client-identifier or will, for the purposes of this section, be described as "Client-
MAC address". identifier or MAC address".
The Reservations bit (the R bit) has no meaning in the DHCPLEASEQUERY
message and is used only to indicate the existence of a reservation
in a DHCPLEASEKNOWN or DHCPLEASEACTIVE message.
If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the
IP address placed in the "ciaddr" field of the DHCPLEASEKNOWN or IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message
DHCPLEASEACTIVE message MUST be that of an IP address for which the MUST be that of an IP address for which the client that most recently
client that most recently used the IP address matches the Client- used the IP address matches the Client-identifier or MAC address
identifier or MAC address specified in the DHCPLEASEQUERY message. specified in the DHCPLEASEQUERY message.
If there is only a single IP address which fulfills this criteria, If there is only a single IP address which fulfills this criteria,
then it MUST be placed in the "ciaddr" field of the DHCPLEASEKNOWN or then it MUST be placed in the "ciaddr" field of the DHCPLEASEACTIVE
DHCPLEASEACTIVE message. message.
In the case where more than one IP address has been accessed by the In the case where more than one IP address has been accessed by the
client specified by the MAC address or Client-identifier option, then client specified by the MAC address or Client-identifier option, then
the DHCP server MUST return the IP address returned to the client in the DHCP server MUST return the IP address returned to the client in
the most recent transaction with the client unless the DHCP server the most recent transaction with the client unless the DHCP server
has been configured by the server administrator to use some other has been configured by the server administrator to use some other
preference mechanism. preference mechanism.
If, after all of the above processing, no value is set in the If, after all of the above processing, no value is set in the
"ciaddr" field of the DHCPLEASEKNOWN or DHCPLEASEACTIVE message, then "ciaddr" field of the DHCPLEASEKNOWN or DHCPLEASEACTIVE message, then
a DHCPLEASEUNKNOWN message MUST be returned instead. a DHCPLEASEUNKNOWN message MUST be returned instead.
6.4.2. Building a DHCPLEASEKNOWN or DHCPLEASEACTIVE message once the 6.4.2. Building a DHCPLEASEKNOWN or DHCPLEASEACTIVE message once the
"ciaddr" field is set "ciaddr" field is set
Once the "ciaddr" field of the DHCPLEASEKNOWN or DHCPLEASEACTIVE mes- Once the "ciaddr" field of the DHCPLEASEKNOWN or DHCPLEASEACTIVE
sage is set, the rest of the processing largely involves returning message is set, the processing for a DHCPLEASEKNOWN message is
information about the IP address specified in the "ciaddr" field. complete.
If the IP address in the "ciaddr" field of the DHCPLEASEKNOWN or
DHCPLEASEACTIVE message is currently leased by the client specified
in the Client-identifier or MAC address returned in the DHCPLEASE-
KNOWN or DHCPLEASEACTIVE message, then the message MUST be a
DHCPLEASEACTIVE message, otherwise it MUST be a DHCPLEASEKNOWN mes-
sage.
It MAY be possible to configure a DHCP server to return a
DHCPLEASEACTIVE message even though the IP address specified in the
"ciaddr" field is not currently leased if there is a reservation for
that IP address by the client specified in the Client-identifier or
MAC address fields of the DHCPLEASEACTIVE message. In this case,
there MUST NOT be an IP Address Lease Time option (option 51) in the
packet.
The R (reservation) bit must be set in the "flags" field if the IP For the DHCPLEASEACTIVE message, the rest of the processing largely
address in the "ciaddr" field is reserved for the client returned in involves returning information about the IP address specified in the
the MAC address or Client-identifier option. "ciaddr" field.
The IP address in the "ciaddr" field of the DHCPLEASEKNOWN or The IP address in the "ciaddr" field of the DHCPLEASEKNOWN or
DHCPLEASEACTIVE message MUST be one for which this server is respon- DHCPLEASEACTIVE message MUST be one for which this server is
sible (or a DHCPLEASEUNKNOWN message would be have already been responsible (or a DHCPLEASEUNKNOWN message would be have already been
returned early in the processing described in the previous section). returned early in the processing described in the previous section).
The MAC address of the DHCPLEASEKNOWN or DHCPLEASEACTIVE message MUST The MAC address of the DHCPLEASEACTIVE message MUST be set to the
be set to the values which identify the client associated with the IP values which identify the client associated with the IP address in
address in the "ciaddr" field of the DHCPLEASEKNOWN message. This the "ciaddr" field of the DHCPLEASEKNOWN message.
may be derived from a real DHCP client or from reservation informa-
tion configured into the DHCP server.
If the Client-identifier option (option 61) is specified in the If the Client-identifier option (option 61) is specified in the
Parameter Request List option (option 55), then the Client-identifier Parameter Request List option (option 55), then the Client-identifier
(if any) of the client associated with the IP address in the "ciaddr" (if any) of the client associated with the IP address in the "ciaddr"
field SHOULD be returned in the DHCPLEASEKNOWN or DHCPLEASEACTIVE field SHOULD be returned in the DHCPLEASEACTIVE message.
message. This may be derived from a real DHCP client, or from reser-
vation information configured into the DHCP server.
In the case where more than one IP address has been involved in a In the case where more than one IP address has been involved in a
DHCP message exchange with the client specified by the MAC address DHCP message exchange with the client specified by the MAC address
and/or Client-identifier option, then the list of all of the IP and/or Client-identifier option, then the list of all of the IP
addresses SHOULD be returned in the associated-ip option (option addresses SHOULD be returned in the associated-ip option (option
TBD), if that option was requested as part of the Parameter Request TBD), if that option was requested as part of the Parameter Request
List option. List option.
If the IP Address Lease Time option (option 51) is specified in the If the IP Address Lease Time option (option 51) is specified in the
Parameter Request List and if there is a currently valid lease for Parameter Request List and if there is a currently valid lease for
the IP address specified in the ciaddr, then the DHCP server MUST the IP address specified in the ciaddr, then the DHCP server MUST
return this option in the DHCPLEASEKNOWN with its value equal to the return this option in the DHCPLEASEACTIVE message with its value
time remaining until lease expiration. If there is no valid lease equal to the time remaining until lease expiration. If there is no
for the IP address, then the server MUST NOT return the IP Address valid lease for the IP address, then the server MUST NOT return the
Lease Time option (option 51). IP Address Lease Time option (option 51).
If there is no currently valid lease on the IP address in the
"ciaddr" field, and if the "ciaddr" in the DHCPLEASEKNOWN message is
currently reserved for the client specified by the client-id or MAC
address, then the DHCP server MAY synthesize an IP Address Lease Time
option for the DHCPLEASEKNOWN message if configured to do so. Typi-
cally the value of this option would itself be a configuration param-
eter of the DHCP server.
A request for the Renewal (T1) Time Value option or the Rebinding A request for the Renewal (T1) Time Value option or the Rebinding
(T2) Time Value option in the Parameter Request List of the (T2) Time Value option in the Parameter Request List of the
DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time
option is handled. If there is a valid lease, then the DHCP server option is handled. If there is a valid lease and these times are not
SHOULD return these options (when requested) with the remaining time yet in the past, then the DHCP server SHOULD return these options
until renewal or rebinding, respectively. If there is not currently (when requested) with the remaining time until renewal or rebinding,
a valid lease for this IP address, the DHCP server MUST NOT return respectively. If these times are already in the past, or if there is
these options. not currently a valid lease for this IP address, the DHCP server MUST
NOT return these options.
If the Relay Agent Information (option 82) is specified in the Param- If the Relay Agent Information (option 82) is specified in the
eter Request List and if the DHCP server has saved the information Parameter Request List and if the DHCP server has saved the
contained in the most recent Relay Agent Information option, the DHCP information contained in the most recent Relay Agent Information
server MUST include that information in a Relay Agent Information option, the DHCP server MUST include that information in a Relay
option in the DHCPLEASEKNOWN. Agent Information option in the DHCPLEASEACTIVE message.
The DHCPLEASEKNOWN or DHCPLEASEACTIVE message SHOULD include the The DHCPLEASEACTIVE message SHOULD include the values of all other
values of all other options not specifically discussed above that options not specifically discussed above that were requested in the
were requested in the Parameter Request List of the DHCPLEASEQUERY Parameter Request List of the DHCPLEASEQUERY message. The DHCP
message. The DHCP server uses information from its lease binding server uses information from its lease binding database to supply the
database to supply the DHCPLEASEKNOWN or DHCPLEASEACTIVE option DHCPLEASEACTIVE option values. The values of the options that were
values. The values of the options that were returned to the DHCP returned to the DHCP client would generally be preferred, but in the
client would generally be preferred, but in the absence of those, absence of those, options that were sent in DHCP client requests
options that were sent in DHCP client requests would be acceptable. would be acceptable.
In order to accommodate DHCPLEASEQUERY messages sent to a DHCP Fail- In order to accommodate DHCPLEASEQUERY messages sent to a DHCP
over secondary server [FAILOVER] when the primary server is down, the Failover secondary server [FAILOVER] when the primary server is down,
primary server MUST communicate the Relay Agent Information option the primary server MUST communicate the Relay Agent Information
(option 82) values to the secondary server via the DHCP Failover option (option 82) values to the secondary server via the DHCP
BNDUPD messages. Failover BNDUPD messages.
6.4.3. Sending a DHCPLEASEKNOWN, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN 6.4.3. Sending a DHCPLEASEKNOWN, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN
message message
The server expects a giaddr in the DHCPLEASEQUERY message, and uni- The server expects a giaddr in the DHCPLEASEQUERY message, and
casts the DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message unicasts the DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN
to the giaddr. If the giaddr field is zero, then the DHCP server MUST message to the giaddr. If the giaddr field is zero, then the DHCP
NOT reply to the DHCPLEASEQUERY message. server MUST NOT reply to the DHCPLEASEQUERY message.
6.5. Receiving a DHCPLEASEKNOWN, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN 6.5. Receiving a DHCPLEASEKNOWN, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN
Message Message
When a DHCPLEASEACTIVE message is received in response to the When a DHCPLEASEACTIVE message is received in response to the
DHCPLEASEQUERY message it means that there is a currently active DHCPLEASEQUERY message it means that there is a currently active
lease for this IP address in this DHCP server. The access concentra- lease for this IP address in this DHCP server. The access
tor SHOULD use the information in the htype, hlen, and chaddr fields concentrator SHOULD use the information in the htype, hlen, and
of the DHCPLEASEACTIVE as well as any Relay Agent Information option chaddr fields of the DHCPLEASEACTIVE as well as any Relay Agent
information included in the packet to refresh its location informa- Information option information included in the packet to refresh its
tion for this IP address. location information for this IP address.
When a DHCPLEASEKNOWN message is received in response to the When a DHCPLEASEKNOWN message is received in response to the
DHCPLEASEQUERY message that means that there is no currently active DHCPLEASEQUERY message that means that there is no currently active
lease for the IP address present in the DHCP server. In this case, lease for the IP address present in the DHCP server, but that this
the access concentrator SHOULD cache this information in order to server does in fact manage that IP address. In this case, the access
prevent unacceptable loads on the access concentrator and the DHCP concentrator SHOULD cache this information in order to prevent
server in the face of a malicious or seriously compromised device unacceptable loads on the access concentrator and the DHCP server in
downstream of the access concentrator. This cacheing could be as the face of a malicious or seriously compromised device downstream of
simple as simply setting a bit saying that a response was received the access concentrator. This cacheing could be as simple as simply
from a server which knew about this IP address but that there was no setting a bit saying that a response was received from a server which
current lease. This would of course need to be cleared when the knew about this IP address but that there was no current lease. This
access concentrator next "gleaned" that a lease for this IP address would of course need to be cleared when the access concentrator next
came into existance. "gleaned" that a lease for this IP address came into existance.
If the R (reservation) bit is set in the "flags" field of the
DHCPLEASEKNOWN message, it means that a reservation exists in the
DHCP server for the IP address and associated client. The access
concentrator MAY be configured to allow the client access even though
no currently outstanding lease is in place for this
In either case, when a DHCPLEASEKNOWN or DHCPLEASEACTIVE message is In either case, when a DHCPLEASEKNOWN or DHCPLEASEACTIVE message is
received in response to a DHCPLEASEQUERY message, it means that the received in response to a DHCPLEASEQUERY message, it means that the
DHCP server which responded is a DHCP server which manages the IP DHCP server which responded is a DHCP server which manages the IP
address present in the ciaddr, and the Relay Agent SHOULD cache this address present in the ciaddr, and the Relay Agent SHOULD cache this
information for later use. information for later use.
When a DHCPLEASEUNKNOWN message is received by an access concentrator When a DHCPLEASEUNKNOWN message is received by an access concentrator
which has sent out a DHCPLEASEQUERY message, it means that the DHCP which has sent out a DHCPLEASEQUERY message, it means that the DHCP
server contacted supports the DHCPLEASEQUERY message but that the server contacted supports the DHCPLEASEQUERY message but that the
DHCP server does not have definitive information concerning the IP DHCP server does not have definitive information concerning the IP
address contained in the "ciaddr" field of the DHCPLEASEQUERY mes- address contained in the "ciaddr" field of the DHCPLEASEQUERY
sage. If there is no IP address in the "ciaddr" field of the message. If there is no IP address in the "ciaddr" field of the
DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means that DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means that
the DHCP server does not have definitive information concerning the the DHCP server does not have definitive information concerning the
any DHCP client specified in the "hlen", "htype", and "chaddr" fields any DHCP client specified in the "hlen", "htype", and "chaddr" fields
or the Client-identifier option of the DHCPLEASEQUERY message. or the Client-identifier option of the DHCPLEASEQUERY message.
The access concentrator SHOULD cache this information, and only The access concentrator SHOULD cache this information, and only
infrequently direct a DHCPLEASEQUERY message to a DHCP server that infrequently direct a DHCPLEASEQUERY message to a DHCP server that
responded to a DHCPLEASEQUERY message for a particular "ciaddr" field responded to a DHCPLEASEQUERY message for a particular "ciaddr" field
with a DHCPLEASEUNKNOWN. with a DHCPLEASEUNKNOWN.
When a DHCPUNIMPLEMENTED message is received by an access concentra- When a DHCPUNIMPLEMENTED message is received by an access
tor, it means that the particular aspect of DHCPLEASEQUERY processing concentrator, it means that the particular aspect of DHCPLEASEQUERY
requested is not implemented in the responding server. It may or may processing requested is not implemented in the responding server. It
not be the case that other aspects of DHCPLEASEQUERY processing are may or may not be the case that other aspects of DHCPLEASEQUERY
not implemented in that server. processing are not implemented in that server.
6.6. Receiving no response to the DHCPLEASEQUERY Message 6.6. Receiving no response to the DHCPLEASEQUERY Message
When an access concentrator receives no response to a DHCPLEASEQUERY When an access concentrator receives no response to a DHCPLEASEQUERY
message, there are several possible reasons: message, there are several possible reasons:
o The DHCPLEASEQUERY or a corresponding DHCPLEASEKNOWN, o The DHCPLEASEQUERY or a corresponding DHCPLEASEKNOWN,
DHCPLEASEACTIVE or DHCPLEASEUNKNOWN were lost during transmis- DHCPLEASEACTIVE or DHCPLEASEUNKNOWN were lost during
sion or the DHCPLEASEQUERY arrived at the DHCP server but it was transmission or the DHCPLEASEQUERY arrived at the DHCP server
dropped because the server was too busy. but it was dropped because the server was too busy.
o The DHCP server doesn't support DHCPLEASEQUERY. o The DHCP server doesn't support DHCPLEASEQUERY.
In the first of the cases above, a retransmission of the 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
does or does not support the DHCPLEASEQUERY message). does or does not support the DHCPLEASEQUERY message).
An access concentrator which utilizes the DHCPLEASEQUERY message An access concentrator which utilizes the DHCPLEASEQUERY message
SHOULD attempt to resend DHCPLEASEQUERY messages to servers which do SHOULD attempt to resend DHCPLEASEQUERY messages to servers which do
not respond to them using a backoff algorithm for the retry time that not respond to them using a backoff algorithm for the retry time that
approximates an exponential backoff. The access concentrator SHOULD approximates an exponential backoff. The access concentrator SHOULD
adjust the backoff approach such that DHCPLEASEQUERY messages do not adjust the backoff approach such that DHCPLEASEQUERY messages do not
arrive at a server which is not otherwise known to support the arrive at a server which is not otherwise known to support the
DHCPLEASEQUERY message at a rate of more than approximately one DHCPLEASEQUERY message at a rate of more than approximately one
packet every 10 seconds, and yet (if the access concentrator needs to packet every 10 seconds, and yet (if the access concentrator needs to
send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per 70
minute. seconds.
In practice this approach would probably best be handled by a per- In practice this approach would probably best be handled by a per-
server timer that backs off exponentially to once a minute, and a server timer that is restarted whenever a response to a
per-message backoff timer that also backs off to once a minute. The DHCPLEASEQUERY message is received, and expires after one minute.
per-server timer would start off expired, and in the expired state The per-server timer would start off expired, and in the expired
only one DHCPLEASEQUERY message would be queued for the associated state only one DHCPLEASEQUERY message would be queued for the
server. This DHCPLEASEQUERY message would be sent with the backoff associated server.
quickly moving to once a minute until a DHCPLEASEACTIVE, DHCPLEASE-
KNOWN, or DHCPLEASEUNKNOWN message reply was received. Whenever one
of these messages is received, the per-server timer is reset, and
whenever the per-server timer has not expired, more than one indivi-
dual DHCPLEASEQUERY messages can be outstanding to the DHCP server at
one time. It is recommended that this number be limited to a rela-
tively small number, for example, 100 or 200, to avoid swamping the
DHCP server. Each of these messages should have its own per-message
retry timer. This would retransmit each message and backoff as dis-
cussed above. In the event the per-server timer goes off, then all
outstanding messages SHOULD be dropped except for a single DHCPLEASE-
QUERY message which is used to poll the server until such time as
another DHCPLEASEACTIVE, DHCPLEASEKNOWN, or DHCPLEASEUNKNOWN message
is received.
6.7. Using the DHCPLEASEQUERY message in a failover environment All DHCPLEASEQUERY messages SHOULD use the exponetial backoff
algorithm specified in RFC 2131, section 4.1 [RFC 2131].
When using the DHCPLEASEQUERY message in an environment where multi- Thus, in the initial state, the per-server timer is expired, and a
ple DHCP server may contain authoritative information about the same single DHCPLEASEQUERY message is queued for each server. After the
IP address (such as when failover [FAILOVER] is operating), there first response to a DHCPLEASEQUERY message, the per-server timer is
could be some difficulty in deciding which results are the most use- started. At that time, multiple DHCPLEASEQUERY message can be sent
ful if two servers respond with DHCPLEASEKNOWN messages to the same in parallel to the DHCP server, though the total number SHOULD be
query. limited to 100 or 200, to avoid swamping the DHCP server. Each of
these messages uses the RFC 2131 exponential backoff algorithm.
Every time a response to any of these messages is received, the per-
server timer is reset and starts counting again up to one minute. In
the event the per-server timer goes off, then all outstanding
messages SHOULD be dropped except for a single DHCPLEASEQUERY message
which is used to poll the server at approximately 64 second intervals
until such time as another (or the first) response to the
DHCPLEASEQUERY is received.
In this case, the client-last-transaction-time can be used to decide In the event that there is no DHCPLEASEQUERY traffic for one minute,
which server has more recent information concerning the IP address then the per-server timer will expire. After that time, there will
returned in the "ciaddr" field. only be one DHCPLEASEQUERY message allowed to be outstanding to that
server until a response to that message is recieved.
6.7. Using the DHCPLEASEQUERY message with multiple DHCP servers
When using the DHCPLEASEQUERY message in an environment where
multiple DHCP servers may contain authoritative information about the
same IP address (such as when failover [FAILOVER] is operating),
multiple, possibly conflicting, responses might be received.
In this case, some information in the response packet SHOULD be used
to decide among the various responses. The client-last-transaction-
time (if it is available) can be used to decide which server has more
recent information concerning the IP address returned in the "ciaddr"
field.
7. Security Considerations 7. Security Considerations
Access concentrators that use DHCP gleaning, refreshed with Access concentrators that use DHCP gleaning, refreshed with
DHCPLEASEQUERY messages, will maintain accurate location information. DHCPLEASEQUERY messages, will maintain accurate location information.
Location information accuracy ensures that the access concentrator Location information accuracy ensures that the access concentrator
can forward data traffic to the intended location in the broadband can forward data traffic to the intended location in the broadband
access network, can perform IP source address verification of access network, can perform IP source address verification of
datagrams from the access network, and can encrypt traffic which can datagrams from the access network, and can encrypt traffic which can
only be decrypted by the intended access modem (e.g. [BPI] and only be decrypted by the intended access modem (e.g. [BPI] and
[BPI+]). As a result, the access concentrator does not need to [BPI+]). As a result, the access concentrator does not need to
depend on ARP broadcasts across the access network, which is suscep- depend on ARP broadcasts across the access network, which is
tible to malicious hosts which masquerade as the intended IP end- susceptible to malicious hosts which masquerade as the intended IP
points. Thus, the DHCPLEASEQUERY message allows an access concentra- endpoints. Thus, the DHCPLEASEQUERY message allows an access
tor to provide considerably enhanced security. concentrator to provide considerably enhanced security.
DHCP servers SHOULD prevent exposure of location information (partic- DHCP servers SHOULD prevent exposure of location information
ularly the mapping of hardware address to IP address lease, which can (particularly the mapping of hardware address to IP address lease,
be an invasion of broadband subscriber privacy) by leveraging DHCP which can be an invasion of broadband subscriber privacy) by
authentication [RFC 3118]. With respect to authentication, the leveraging DHCP authentication [RFC 3118]. With respect to
access concentrator acts as the "client". The use of "Authentication authentication, the access concentrator acts as the "client". The
Protocol 0" (using simple unencoded authentication token(s) between use of "Authentication Protocol 0" (using simple unencoded
the access concentrator and the DHCP server) is straightforward. authentication token(s) between the access concentrator and the DHCP
Alternatively, use of IPsec would also be a way to ensure security server) is straightforward. Alternatively, use of IPsec would also be
between the relay agent and the DHCP server. a way to ensure security between the relay agent and the DHCP server.
Access concentrators SHOULD minimize potential denial of service Access concentrators SHOULD minimize potential denial of service
attacks on the DHCP servers by minimizing the generation of attacks on the DHCP servers by minimizing the generation of
DHCPLEASEQUERY messages. In particular, the access concentrator DHCPLEASEQUERY messages. In particular, the access concentrator
should employ negative cacheing (i.e. cache both DHCPLEASEKNOWN and should employ negative cacheing (i.e. cache DHCPLEASEKNOWN,
DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY messages) and ciaddr DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY
restriction (i.e. don't send a DHCPLEASEQUERY message with a ciaddr messages) and ciaddr restriction (i.e. don't send a DHCPLEASEQUERY
outside of the range of the attached broadband access networks). message with a ciaddr outside of the range of the attached broadband
Together, these mechanisms limit the access concentrator to transmit- access networks). Together, these mechanisms limit the access
ting one DHCPLEASEQUERY message (excluding message retries) per legi- concentrator to transmitting one DHCPLEASEQUERY message (excluding
timate broadband access network IP address after a reboot event. message retries) per legitimate broadband access network IP address
after a reboot event.
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 and one bit position for this docu- IANA has assigned seven values for this document. See Section 6.1 for
ment. See Section 6.1 for details. There are five new messages details. There are five new messages types, which are the value of
types, which are the value of the message type option (option 53) the message type option (option 53) from [RFC 2132]. The value for
from [RFC 2132]. The value for DHCPLEASEQUERY is TBD, the value for DHCPLEASEQUERY is TBD, the value for DHCPLEASEKNOWN is TBD, the value
DHCPLEASEKNOWN is TBD, the value for DHCPLEASEACTIVE is TBD, the for DHCPLEASEACTIVE is TBD, the value for DHCPLEASEUNKNOWN is TBD and
value for DHCPLEASEUNKNOWN is TBD and the value for DHCPUNIMPLEMENTED the value for DHCPUNIMPLEMENTED is TBD. Finally, there are two new
is TBD. There is a new bit defined for the "flags" field of the DHCP DHCP option defined; the client-last-transaction-time option --
packet (see Section 1, Figure 1 and Table 1 of [RFC 2131]). The flag option code TBD, and the associated-ip option -- option code TBD.
is called "R: RESERVATION flag", and its value is TBD. Finally,
there are two new DHCP option defined; the client-last-transaction-
time option -- option code TBD, and the associated-ip option --
option code TBD.
9. Acknowledgments 9. Acknowledgments
Jim Forster, Joe Ng, Guenter Roeck, and Mark Stapp contributed Jim Forster, Joe Ng, Guenter Roeck, and Mark Stapp contributed
greatly to the initial creation of the DHCPLEASEQUERY message. greatly to the initial creation of the DHCPLEASEQUERY message.
Patrick Guelat suggested several improvements to support static IP Patrick Guelat suggested several improvements to support static IP
addressing. addressing.
10. References 10. References
[RFC 826] Plummer, D., "Ethernet Address Resolution Protocol: Or con- 10.1. Normative References
verting network protocol addresses to 48.bit Ethernet address for
transmission on Ethernet hardware", RFC 826, November 1982.
[RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC
951, September 1985.
[RFC 1542] Wimer, W., "Clarifications and Extensions for the
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
Extensions", RFC 2132, 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 Mes- 10.2. Informative References
sages", RFC 3118, June 2001.
[RFC 826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address
for transmission on Ethernet hardware", RFC 826, November 1982.
[RFC 951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC
951, September 1985.
[RFC 1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993.
[RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC 3118] Droms, R., Arbaugh, W., "Authentication for DHCP
Messages", RFC 3118, June 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/.
[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-06.txt, February
2002. 2002.
[DOCSIS] CableLabs, "Data-Over-Cable Service Interface Specifica- [DOCSIS] CableLabs, "Data-Over-Cable Service Interface
tions: Cable Modem Radio Frequency Interface Specification SP- Specifications: Cable Modem Radio Frequency Interface
RFI-I05-991105", November 1999. Specification SP-RFI-I05-991105", November 1999.
[EUROMODEM] ECCA, "Technical Specification of a European Cable Modem [EUROMODEM] ECCA, "Technical Specification of a European Cable Modem
for digital bi-directional communications via cable networks", for digital bi-directional communications via cable networks",
Version 1.0, May 1999. Version 1.0, May 1999.
[FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., [FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S.,
Rabil, G., Dooley, M., Kapur, A., "DHCP Failover Protocol", Rabil, G., Dooley, M., Kapur, A., "DHCP Failover Protocol",
draft-ietf-dhc-failover-10.txt, January 2002. draft-ietf-dhc-failover-12.txt, March 2003.
11. Author's information 11. Author's information
Rich Woundy Rich Woundy
Comcast Cable Comcast Cable
27 Industrial Ave. 27 Industrial Ave.
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 244-4010 Phone: (978) 244-4010
EMail: richard_woundy@cable.comcast.com EMail: richard_woundy@cable.comcast.com
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems
250 Apollo Drive 1414 Massachusetts Ave
Chelmsford, MA 01824 Boxborough, MA 01719
Phone: (978) 936-0000
Phone: (978) 497-8000
EMail: kkinnear@cisco.com EMail: kkinnear@cisco.com
12. Intellectual Property Statement 12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any intel- The IETF takes no position regarding the validity or scope of any
lectual property or other rights that might be claimed to pertain to intellectual property or other rights that might be claimed to pertain
the implementation or use of the technology described in this document to the implementation or use of the technology described in this
or the extent to which any license under such rights might or might not document or the extent to which any license under such rights might or
be available; neither does it represent that it has made any effort to might not be available; neither does it represent that it has made any
identify any such rights. Information on the IETF's procedures with effort to identify any such rights. Information on the IETF's
respect to rights in standards-track and standards-related documentation procedures with respect to rights in standards-track and standards-
can be found in BCP-11. Copies of claims of rights made available for related documentation can be found in BCP-11. Copies of claims of
publication and any assurances of licenses to be made available, or the rights made available for publication and any assurances of licenses to
result of an attempt made to obtain a general license or permission for be made available, or the result of an attempt made to obtain a general
the use of such proprietary rights by implementors or users of this license or permission for the use of such proprietary rights by
specification can be obtained from the IETF Secretariat. implementors or users of this specification can be obtained from the
IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this stan- which may cover technology that may be required to practice this
dard. Please address the information to the IETF Executive Director. standard. Please address the information to the IETF Executive
Director.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). 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
ers, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis- assist in its implementation may be prepared, copied, published and
tributed, in whole or in part, without restriction of any kind, provided distributed, in whole or in part, without restriction of any kind,
that the above copyright notice and this paragraph are included on all provided that the above copyright notice and this paragraph are included
such copies and derivative works. However, this document itself may not on all such copies and derivative works. However, this document itself
be modified in any way, such as by removing the copyright notice or may not be modified in any way, such as by removing the copyright notice
references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Stan- which case the procedures for copyrights defined in the Internet
dards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. languages other than English.
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
NESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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