draft-ietf-dhc-leasequery-07.txt   draft-ietf-dhc-leasequery-08.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 2004 February 2005
Expires September 2004 Expires August 2005
DHCP Lease Query DHCP Lease Query
<draft-ietf-dhc-leasequery-07.txt> <draft-ietf-dhc-leasequery-08.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
A DHCP server contains considerable authoritative information A DHCPv4 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 for DHCPv4 is designed to give these processes and devices a
lightweight way to access information that may be critical to their lightweight way to access information that may be critical to their
operation. operation.
Table of Contents Table of Contents
1. Introduction................................................. 2 1. Introduction................................................. 2
2. Terminology.................................................. 5 2. Terminology.................................................. 5
3. Background................................................... 6 3. Background................................................... 6
4. Design Goals................................................. 7 4. Design Goals................................................. 7
4.1. Broadcast ARP is Undesirable............................... 7 4.1. Broadcast ARP is Undesirable............................... 7
4.2. SNMP and LDAP Client Functionality is Lacking.............. 7 4.2. SNMP and LDAP Client Functionality is Lacking.............. 8
4.3. DHCP Relay Agent Functionality is Common................... 7 4.3. DHCP Relay Agent Functionality is Common................... 8
4.4. DHCP Servers as a Reliable Source of Location Information.. 8 4.4. DHCP Servers as a Reliable Source of Location Information.. 8
4.5. Minimal Additional Configuration is Required............... 8 4.5. Minimal Additional Configuration is Required............... 9
5. Protocol Overview............................................ 8 5. Protocol Overview............................................ 9
6. Protocol Details............................................. 11 6. Protocol Details............................................. 12
6.1. Definitions required for DHCPLEASEQUERY processing......... 11 6.1. Definitions required for DHCPLEASEQUERY processing......... 12
6.2. Sending the DHCPLEASEQUERY Message......................... 13 6.2. Sending the DHCPLEASEQUERY Message......................... 13
6.3. Receiving the DHCPLEASEQUERY Message....................... 15 6.3. Receiving the DHCPLEASEQUERY Message....................... 15
6.4. Responding to the DHCPLEASEQUERY Message................... 15 6.4. Responding to the DHCPLEASEQUERY Message................... 16
6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or....... 19 6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or....... 20
6.6. Receiving no response to the DHCPLEASEQUERY Message........ 20 6.6. Receiving no response to the DHCPLEASEQUERY Message........ 21
6.7. Lease binding data storage requirements.................... 21 6.7. Lease binding data storage requirements.................... 22
6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 22 6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 23
7. Security Considerations...................................... 22 7. Security Considerations...................................... 23
8. IANA Considerations.......................................... 23 8. IANA Considerations.......................................... 24
9. Acknowledgments.............................................. 23 9. Acknowledgments.............................................. 24
10. References.................................................. 24 10. References.................................................. 24
10.1. Normative References...................................... 24 10.1. Normative References...................................... 24
10.2. Informative References.................................... 24 10.2. Informative References.................................... 25
11. Author's information........................................ 25 11. Author's information........................................ 25
12. Intellectual Property Statement............................. 25 12. Intellectual Property Statement............................. 26
13. Full Copyright Statement.................................... 26 13. Full Copyright Statement.................................... 26
1. Introduction 1. Introduction
A DHCP server contains considerable authoritative information A DHCPv4 server contains considerable authoritative information
concerning the IP addresses it has leased to DHCP clients. Sometimes concerning the IP addresses it has leased to DHCP clients. Sometimes
devices or other processes may need access to this information. In devices or other processes may need access to this information. In
some cases, these devices or processes already have the capability to some cases, these devices or processes already have the capability to
send and receive DHCP packets, and so the leasequery protocol is send and receive DHCP packets, and so the leasequery protocol is
designed to give these processes and devices a low overhead way to designed to give these processes and devices a low overhead way to
access such information. access such information.
For example, access concentrators that act as DHCP relay agents For example, access concentrators that act as DHCP relay agents
sometimes derive information important to their operation by sometimes derive information important to their operation by
extracting data out of the DHCP packets they forward, a process known extracting data out of the DHCP packets they forward, a process known
skipping to change at page 5, line 5 skipping to change at page 5, line 23
DHCP server has no knowledge of the information specified in the DHCP server has no knowledge of the information specified in the
query (e.g., IP address, MAC address, or Client-identifier option). query (e.g., IP address, MAC address, or Client-identifier option).
The DHCPLEASEQUERY message does not presuppose a particular use for The DHCPLEASEQUERY message does not presuppose a particular use for
the information it returns -- it is simply designed to return the information it returns -- it is simply designed to return
information for which the DHCP server is an authoritative source to a information for which the DHCP server is an authoritative source to a
client which requests that information. It is designed to make it client which requests that information. It is designed to make it
straightforward for processes and devices which already interpret straightforward for processes and devices which already interpret
DHCP packets to access information from the DHCP server. DHCP packets to access information from the DHCP server.
This document specifies an extension specifically to the DHCPv4
protocol [RFC2131].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC 2119].
This document uses the following terms: This document uses the following terms:
o "access concentrator" o "access concentrator"
skipping to change at page 9, line 20 skipping to change at page 9, line 43
current when this client's lease was last granted or renewed, current when this client's lease was last granted or renewed,
allowing the access concentrator to forward the IP datagram. allowing the access concentrator to forward the IP datagram.
An alternative approach is to send in a DHCPLEASEQUERY message with An alternative approach is to send in a DHCPLEASEQUERY message with
the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen", the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen",
and "chaddr" fields) with a valid MAC address or a Client-identifier and "chaddr" fields) with a valid MAC address or a Client-identifier
option (option 61) appearing in the options area. In this case, the option (option 61) appearing in the options area. In this case, the
DHCP server must return an IP address in the "ciaddr" if it has any DHCP server must return an IP address in the "ciaddr" if it has any
record of the client described by the Client-identifier or MAC record of the client described by the Client-identifier or MAC
address. In the absence of specific configuration information to the address. In the absence of specific configuration information to the
contrary (see Section 6.4) it should be the IP address most recently contrary (see Section 6.4) it SHOULD be the IP address with the
used by the client described by the MAC address or Client-identifier latest client-last-transaction-time associated with the client
option (or the client described by both, if both appear). described by the MAC address or Client-identifier 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 DHCPLEASEUNASSIGNED, to the DHCPLEASEQUERY message: either a DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE or DHCPLEASEUNKNOWN (or in some cases, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN (or in some cases,
DHCPUNIMPLEMENTED). The reasons why a DHCPLEASEUNASSIGNED, DHCPUNIMPLEMENTED). The reasons why a DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message might be generated are DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message might be generated are
explained in the specific query regimes, below. explained in the specific query regimes, below.
Servers which do not implement the DHCPLEASEQUERY message fall into Servers which do not implement the DHCPLEASEQUERY message fall into
two classes. Those that simply do not know about the DHCPLEASEQUERY two classes. Those that simply do not know about the DHCPLEASEQUERY
message will simply not respond to it, so clients which send the message will simply not respond to it, so clients which send the
DHCPLEASEQUERY message must be prepared to deal with this behavior. DHCPLEASEQUERY message must be prepared to deal with this behavior.
Servers which are aware of the DHCPLEASEQUERY message but do not Servers which are aware of the DHCPLEASEQUERY message but do not
implement it should respond with a DHCPUNIMPLEMENTED message but may implement it SHOULD respond with a DHCPUNIMPLEMENTED message but may
simply not respond. simply not respond.
The DHCPLEASEQUERY message can support three query regimes: A server The DHCPLEASEQUERY message can support three query regimes: A server
which implements the DHCPLEASEQUERY message must implement all three which implements the DHCPLEASEQUERY message must implement all three
query regimes. query regimes.
o Query by IP address: o Query by IP address:
For this query, the requester supplies only an IP address in the For this query, the requester supplies only an IP address in the
DHCPLEASEQUERY message. The DHCP server will return any DHCPLEASEQUERY message. The DHCP server will return any
skipping to change at page 10, line 47 skipping to change at page 11, line 24
Query by IP Address, described above. Query by IP Address, described above.
The DHCP server replies with a DHCPLEASEACTIVE message if the The DHCP server replies with a DHCPLEASEACTIVE message if the
Client-identifier in the DHCPLEASEQUERY message currently has an Client-identifier in the DHCPLEASEQUERY message currently has an
active lease on an IP address in this DHCP server. The server active lease on an IP address in this DHCP server. The server
replies with a DHCPLEASEUNKNOWN message if the server does not replies with a DHCPLEASEUNKNOWN message if the server does not
have an active lease by a client with this Client-identifier. have an active lease by a client with this Client-identifier.
For many DHCP servers, the query by IP address is likely to be the For many DHCP servers, the query by IP address is likely to be the
most efficient form of leasequery. This is the form of most efficient form of leasequery. This is the form of
DHCPLEASEQUERY that should be used if possible. DHCPLEASEQUERY that SHOULD be used if possible.
The DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message reply must always The DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message reply must always
contain the IP address in the ciaddr field. The DHCPLEASEACTIVE contain the IP address in the ciaddr field. The DHCPLEASEACTIVE
message should contains the physical address of the IP address lease message SHOULD contain the physical address of the IP address lease
owner in the "htype", "hlen", and "chaddr" fields. The Parameter owner in the "htype", "hlen", and "chaddr" fields. The Parameter
Request List (option 55) can be used to request specific options to Request List (option 55) can be used to request specific options to
be returned about the IP address in the ciaddr. The reply often be returned about the IP address in the ciaddr. The reply often
contains the time until expiration of the lease, and the original contains the time until expiration of the lease, and the original
contents of the Relay Agent Information option [RFC 3046]. The contents of the Relay Agent Information option [RFC 3046]. The
access concentrator uses the "chaddr" and Relay Agent Information access concentrator uses the "chaddr" and Relay Agent Information
option to construct location information, which can be cached on the option to construct location information, which can be cached on the
access concentrator until lease expiration. access concentrator until lease expiration.
Any DHCP server which supports the DHCPLEASEQUERY message should save Any DHCP server which supports the DHCPLEASEQUERY message SHOULD save
the information from the most recent Relay Agent Information option the information from the most recent Relay Agent Information option
(option 82) [RFC 3046] associated with every IP address which it (option 82) [RFC 3046] associated with every IP address which it
serves. It is assumed that most clients which generate the serves. It is assumed that most clients which generate the
DHCPLEASEQUERY message will ask for the Relay Agent Information DHCPLEASEQUERY message will ask for the Relay Agent Information
option (option 82) in the Parameter Request List (option 55), and so option (option 82) in the Parameter Request List (option 55), and so
supporting the DHCPLEASEQUERY message without having the Relay Agent supporting the DHCPLEASEQUERY message without having the Relay Agent
Information option around to return to the client is likely to be Information option around to return to the client is likely to be
less than helpful. less than helpful.
A server which implements DHCPLEASEQUERY should also save the A server which implements DHCPLEASEQUERY SHOULD also save the
information on the most recent Vendor class identifier, option 60, information on the most recent Vendor class identifier, option 60,
associated with each IP address, since this option is also a likely associated with each IP address, since this option is also a likely
candidate to be requested by clients sending the DHCPLEASEQUERY candidate to be requested by clients sending the DHCPLEASEQUERY
message. message.
6. Protocol Details 6. Protocol Details
6.1. Definitions required for DHCPLEASEQUERY processing 6.1. Definitions required for DHCPLEASEQUERY processing
The operation of the DHCPLEASEQUERY message requires the definition The operation of the DHCPLEASEQUERY message requires the definition
skipping to change at page 15, line 9 skipping to change at page 15, line 25
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 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).
Any device expecting to use a DHCPLEASEQUERY message SHOULD ensure
that the Relay Agent Info option that it uses contains information
that unambiguously identifies the device.
6.3. Receiving the DHCPLEASEQUERY Message 6.3. Receiving the DHCPLEASEQUERY Message
A server which implements the DHCPLEASEQUERY message MUST implement A server which implements the DHCPLEASEQUERY message MUST implement
all three query regimes, query by IP address, query by MAC address, all three query regimes, query by IP address, query by MAC address,
and query by Client-identifier. and query by Client-identifier.
A DHCPLEASEQUERY message MUST have a non-zero giaddr. The A DHCPLEASEQUERY message MUST have a non-zero giaddr. The
DHCPLEASEQUERY message MUST have exactly one of: a non-zero ciaddr, DHCPLEASEQUERY message MUST have exactly one of: a non-zero ciaddr,
a non-zero "htype"/"hlen"/"chaddr", or a Client-identifier option. a non-zero "htype"/"hlen"/"chaddr", or a Client-identifier option.
skipping to change at page 17, line 36 skipping to change at page 18, line 9
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 DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message, "ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message,
then a DHCPLEASEUNKNOWN message MUST be returned instead. then a DHCPLEASEUNKNOWN message MUST be returned instead.
6.4.2. Building a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message once 6.4.2. Building a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message once
the "ciaddr" field is set the "ciaddr" field is set
Once the "ciaddr" field of the DHCPLEASEUNASSIGNED is set, the Once the "ciaddr" field of the DHCPLEASEUNASSIGNED is set, the
processing for a DHCPLEASEUNASSIGNED message is complete. processing for a DHCPLEASEUNASSIGNED message is complete. No other
options returned for the DHCPLEASEUNASSIGNED message.
For the DHCPLEASEACTIVE message, the rest of the processing largely For the DHCPLEASEACTIVE message, the rest of the processing largely
involves returning information about the IP address specified in the involves returning information about the IP address specified in the
"ciaddr" field. "ciaddr" field.
The IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED or The IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED or
DHCPLEASEACTIVE message MUST be one for which this server is DHCPLEASEACTIVE message MUST be one for which this server is
responsible (or a DHCPLEASEUNKNOWN message would be have already been responsible (or a DHCPLEASEUNKNOWN message would be have already been
returned early in the processing described in the previous section). returned early in the processing described in the previous section).
skipping to change at page 18, line 11 skipping to change at page 18, line 33
the "ciaddr" field of the DHCPLEASEUNASSIGNED message. the "ciaddr" field of the DHCPLEASEUNASSIGNED message.
If the Client-identifier option (option 61) is specified in the If the Client-identifier option (option 61) is specified in the
Parameter Request List option (option 55), then the Client-identifier Parameter Request List option (option 55), then the Client-identifier
(if any) of the client associated with the IP address in the "ciaddr" (if any) of the client associated with the IP address in the "ciaddr"
field SHOULD be returned in the DHCPLEASEACTIVE message. field SHOULD be returned in the DHCPLEASEACTIVE message.
In the case where more than one IP address has been involved in a In the case where more than one IP address has been involved in a
DHCP message exchange with the client specified by the MAC address DHCP message exchange with the client specified by the MAC address
and/or Client-identifier option, then the list of all of the IP and/or Client-identifier option, then the list of all of the IP
addresses SHOULD be returned in the associated-ip option (option addresses MUST be returned in the associated-ip option, whether or
TBD), if that option was requested as part of the Parameter Request not that option was requested as part of the Parameter Request List
List option. 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 DHCPLEASEACTIVE message with its value return this option in the DHCPLEASEACTIVE message with its value
equal to the time remaining until lease expiration. If there is no equal to the time remaining until lease expiration. If there is no
valid lease for the IP address, then the server MUST NOT return the valid lease for the IP address, then the server MUST NOT return the
IP Address Lease Time option (option 51). IP Address Lease Time option (option 51).
A request for the Renewal (T1) Time Value option or the Rebinding A request for the Renewal (T1) Time Value option or the Rebinding
skipping to change at page 18, line 42 skipping to change at page 19, line 15
If the Relay Agent Information (option 82) is specified in the If the Relay Agent Information (option 82) is specified in the
Parameter Request List then the information contained in the most Parameter Request List then the information contained in the most
recent Relay Agent Information option received from the relay agent recent Relay Agent Information option received from the relay agent
associated with this IP address MUST be included in the associated with this IP address MUST be included in the
DHCPLEASEACTIVE message. The DHCP server MUST the Relay Agent DHCPLEASEACTIVE message. The DHCP server MUST the Relay Agent
Information option that was received when from the relay agent Information option that was received when from the relay agent
associated with this IP address. associated with this IP address.
The DHCPLEASEACTIVE message SHOULD include the values of all other The DHCPLEASEACTIVE message SHOULD include the values of all other
options not specifically discussed above that were requested in the options not specifically discussed above or specifically excluded by
being configured as "sensitive options" that were requested in the
Parameter Request List of the DHCPLEASEQUERY message. The DHCP Parameter Request List of the DHCPLEASEQUERY message. The DHCP
server uses information from its lease binding database to supply the server uses information from its lease binding database to supply the
DHCPLEASEACTIVE option values. The values of the options that were DHCPLEASEACTIVE option values. The values of the options that were
returned to the DHCP client would generally be preferred, but in the returned to the DHCP client would generally be preferred, but in the
absence of those, options that were sent in DHCP client requests absence of those, options that were sent in DHCP client requests
would be acceptable. would be acceptable.
DHCP servers SHOULD be configurable with a list of "sensitive
options" that will not be returned to the client even if specified in
the Parameter Request List of the DHCPLEASEQUERY message.
In some cases, the Relay Agent Information option in an incoming In some cases, the Relay Agent Information option in an incoming
DHCPREQUEST packet is used to help determine the options returned to DHCPREQUEST packet is used to help determine the options returned to
the DHCP client which sent the DHCPREQUEST. When responding to a the DHCP client which sent the DHCPREQUEST. When responding to a
DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay
Agent Information option just like it did when responding to the DHCP Agent Information option just like it did when responding to the DHCP
client in order to determine the values of any options requested by client in order to determine the values of any options requested by
the DHCPLEASEQUERY message. The goal is to return the same option the DHCPLEASEQUERY message. The goal is to return the same option
values to the DHCPLEASEQUERY as those that were returned to the values to the DHCPLEASEQUERY as those that were returned to the
DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise
specified, above). specified, above).
skipping to change at page 22, line 10 skipping to change at page 22, line 37
DHCP server implementations that implement the DHCPLEASEQUERY DHCP server implementations that implement the DHCPLEASEQUERY
capability MUST save the most recent Relay Agent Information option capability MUST save the most recent Relay Agent Information option
from the most recent DHCPREQUEST packet for two reasons. First, it from the most recent DHCPREQUEST packet for two reasons. First, it
is almost certain to be requested by in the dhcp-parameter-request- is almost certain to be requested by in the dhcp-parameter-request-
list option in any DHCPLEASEQUERY request. Second, the saved Relay list option in any DHCPLEASEQUERY request. Second, the saved Relay
Agent Information option may be necessary to determine the value of Agent Information option may be necessary to determine the value of
other options given to the DHCP client, if these are requested by the other options given to the DHCP client, if these are requested by the
dhcp-parameter-request list in the DHCPLEASEQUERY request. dhcp-parameter-request list in the DHCPLEASEQUERY request.
Some of the clients of the DHCPLEASEQUERY capability will also This is a list of the information that is required to successfully
request the vendor-class-id of in the dhcp-parameter-request list, implement
and so a DHCP server SHOULD save that option in the lease binding
data storage. o relay-agent-info option from client packet: MUST store with
binding.
o client-last-transaction-time of last client interaction: MUST
store with binding.
o vendor-class-id: SHOULD store with binding.
These data storage requirements are minimally larger than those These data storage requirements are minimally larger than those
required for normal operation of the DHCP protocol, as required to required for normal operation of the DHCP protocol, as required to
properly implement [RFC2131]. properly implement [RFC2131].
6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers 6.8. Using the DHCPLEASEQUERY message with multiple DHCP servers
When using the DHCPLEASEQUERY message in an environment where When using the DHCPLEASEQUERY message in an environment where
multiple DHCP servers may contain authoritative information about the multiple DHCP servers may contain authoritative information about the
same IP address (such as when two DHCP servers are cooperating to same IP address (such as when two DHCP servers are cooperating to
skipping to change at page 23, line 15 skipping to change at page 23, line 49
Clients of the DHCPLEASEQUERY message SHOULD ensure that their data Clients of the DHCPLEASEQUERY message SHOULD ensure that their data
path to the DHCP server is secure. Clients SHOULD use Relay Agent path to the DHCP server is secure. Clients SHOULD use Relay Agent
Information security as a way to achieve this goal. This will ensure Information security as a way to achieve this goal. This will ensure
against the clients receiving false data, due perhaps to a third against the clients receiving false data, due perhaps to a third
party spoofing the reply from a DHCPLEASEQUERY message. party spoofing the reply from a DHCPLEASEQUERY message.
Access concentrators SHOULD minimize potential denial of service Access concentrators SHOULD minimize potential denial of service
attacks on the DHCP servers by minimizing the generation of attacks on the DHCP servers by minimizing the generation of
DHCPLEASEQUERY messages. In particular, the access concentrator DHCPLEASEQUERY messages. In particular, the access concentrator
should employ negative caching (i.e. cache DHCPLEASEUNASSIGNED, SHOULD employ negative caching (i.e. cache DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY
messages) and ciaddr restriction (i.e. don't send a DHCPLEASEQUERY messages) and ciaddr restriction (i.e. don't send a DHCPLEASEQUERY
message with a ciaddr outside of the range of the attached broadband message with a ciaddr outside of the range of the attached broadband
access networks). Together, these mechanisms limit the access access networks). Together, these mechanisms limit the access
concentrator to transmitting one DHCPLEASEQUERY message (excluding concentrator to transmitting one DHCPLEASEQUERY message (excluding
message retries) per legitimate broadband access network IP address message retries) per legitimate broadband access network IP address
after a reboot event. after a reboot event.
DHCP servers supporting the DHCPLEASEQUERY message SHOULD ensure that DHCP servers supporting the DHCPLEASEQUERY message SHOULD ensure that
they cannot be successfully attacked by being flooded with large they cannot be successfully attacked by being flooded with large
skipping to change at page 26, line 15 skipping to change at page 26, line 44
IETF Secretariat. IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive standard. Please address the information to the IETF Executive
Director. Director.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
This document and translations of it may be copied and furnished to set forth therein, the authors retain all their rights.
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
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 are provided on an
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
FITNESS FOR A PARTICULAR PURPOSE. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR 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/