arrive at a server that is not otherwise known to support the
DHCPLEASEQUERY message at a rate of more than approximately one
packet every 10 seconds, and yet (if the access concentrator needs to
send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per 70
seconds.
In practice, this approach would probably best be handled by a per-
server timer that is restarted whenever a response to a
DHCPLEASEQUERY message is received, and expires after one minute.
The per-server timer would start off expired, and in the expired
state only one DHCPLEASEQUERY message would be queued for the
associated server.
All DHCPLEASEQUERY messages SHOULD use the exponential backoff
algorithm specified in Section 4.1 of [RFC2131].
Thus, in the initial state, the per-server timer is expired, and a
single DHCPLEASEQUERY message is queued for each server. After the
first response to a DHCPLEASEQUERY message, the per-server timer is
started. At that time, multiple DHCPLEASEQUERY messages can be sent
in parallel to the DHCP server, though the total number SHOULD be
limited to 100 or 200, to avoid swamping the DHCP server. Each of
these messages uses the [RFC2131] 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
that 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 the event that there is no DHCPLEASEQUERY traffic for one minute,
then the per-server timer will expire. After that time, there will
only be one DHCPLEASEQUERY message allowed to be outstanding to that
server until a response to that message is received.
6.7. Lease Binding Data Storage Requirements
DHCP server implementations that implement the DHCPLEASEQUERY
capability MUST save the most recent Relay Agent Information option
from the most recent DHCPREQUEST packet for two reasons. First, it
is almost certain to be requested by in the dhcp-parameter-request-
list option in any DHCPLEASEQUERY request. Second, the saved Relay
Agent Information option may be necessary to determine the value of
other options given to the DHCP client, if these are requested by the
dhcp-parameter-request list in the DHCPLEASEQUERY request.
This is a list of the information that is required to successfully
implement
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
required for normal operation of the DHCP protocol, as required to
properly implement [RFC2131].
6.8. 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 two DHCP servers are cooperating to
provide a high-availability DHCP service), 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
Access concentrators that use DHCP gleaning, refreshed with
DHCPLEASEQUERY messages, will maintain accurate location information.
Location information accuracy ensures that the access concentrator
can forward data traffic to the intended location in the broadband
access network, can perform IP source address verification of
datagrams from the access network, and can encrypt traffic that can
only be decrypted by the intended access modem (e.g., [BPI] and
[BPI+]). As a result, the access concentrator does not need to
depend on ARP broadcasts across the access network, which is
susceptible to malicious hosts that masquerade as the intended IP
endpoints. Thus, the DHCPLEASEQUERY message allows an access
concentrator to provide considerably enhanced security.
DHCP servers SHOULD prevent exposure of location information
(particularly the mapping of hardware address to IP address lease,
which can be an invasion of broadband subscriber privacy) by
employing the techniques detailed in [RFC3118], "Authentication for
DHCP Messages".
This RFC describes how a DHCP client interacts with a DHCP server.
Access concentrators that send the DHCPLEASEQUERY message are
essentially DHCP clients for the purposes of the DHCPLEASEQUERY
message, even though they perform the functions of a DHCP relay agent
as well. Thus, [RFC3118] is an appropriate mechanism for
DHCPLEASEQUERY messages.
Since [RFC3118] discusses the normal DHCP client interaction,
consisting of a DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, it
is necessary to transpose the operations described in [RFC3118] to
the DHCPLEASEQUERY domain. The operations described in [RFC3118] for
DHCPDISCOVER are performed for DHCPLEASEQUERY, and the operations
described for DHCPOFFER are performed for DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN messages.
Access concentrators SHOULD minimize potential denial of service
attacks on the DHCP servers by minimizing the generation of
DHCPLEASEQUERY messages. In particular, the access concentrator
SHOULD employ negative caching (i.e., cache DHCPLEASEUNASSIGNED,
DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY
messages) and ciaddr restriction (i.e., don’t send a DHCPLEASEQUERY
message with a ciaddr outside of the range of the attached broadband
access networks). Together, these mechanisms limit the access
concentrator to transmitting one DHCPLEASEQUERY message (excluding
message retries) per legitimate broadband access network IP address
after a reboot event.
DHCP servers supporting the DHCPLEASEQUERY message SHOULD ensure that
they cannot be successfully attacked by being flooded with large
quantities of DHCPLEASEQUERY messages in a short time.
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 DHCPLEASEQUERY messages, thereby allowing it to respond
only to requests from only a handful of relay agents. This does not
provide any true security, but may be useful to thwart
unsophisticated attacks of various sorts.
8. IANA Considerations
IANA has assigned six values for this document. See Section 6.1 for
details. There are four new messages types, which are the value of
the message type option (option 53) from [RFC2132]. The value for
DHCPLEASEQUERY is 10, the value for DHCPLEASEUNASSIGNED is 11, the
value for DHCPLEASEUNKNOWN is 12, and the value for DHCPLEASEACTIVE
is 13. Finally, there are two new DHCP option defined; the client-
last-transaction-time option -- option code 91, and the associated-ip
option -- option code 92.
9. Acknowledgements
Jim Forster, Joe Ng, Guenter Roeck, and Mark Stapp contributed
greatly to the initial creation of the DHCPLEASEQUERY message.
Patrick Guelat suggested several improvements to support static IP
addressing. Thomas Narten made many suggestions for improvements.
Russ Housley pressed effectively for increased security capabilities,
and Ted Hardie suggested ways to minimize undesired information
leakage. Bert Wijnen suggested we clarify our focus to DHCPv4 and
distinguish our approach from that of the DHCP MIB. R. Barr Hibbs,
one of the authors of the DHCP MIB, supplied information to
effectively distinguish that effort from DHCPLEASEQUERY.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
10.2. Informative References
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985.
[RFC1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[BPI] SCTE Data Standards Subcommittee, "Data-Over-Cable
Service Interface Specifications: DOCSIS 1.0 Baseline
Privacy Interface Specification SCTE 22-2 2002", 2002,
available at http://www.scte.org/standards/.
[BPI+] CableLabs, "Data-Over-Cable Service Interface
Specifications: Baseline Privacy Plus Interface
Specification CM-SP-BPI+_I12-050812", August 2005,
available at http://www.cablemodem.com/.
[DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration
Protocol (DHCP) Server MIB", Work in Progress, February
2004.
[DOCSIS] SCTE Data Standards Subcommittee, "Data-Over-Cable
Service Interface Specifications: DOCSIS 1.0 Radio
Frequency Interface Specification SCTE 22-1 2002", 2002,
available at http://www.scte.org/standards/.
[EUROMODEM] ECCA, "Technical Specification of a European Cable Modem
for digital bi-directional communications via cable
networks", Version 1.0, May 1999.
Authors’ Addresses
Rich Woundy
Comcast Cable
27 Industrial Ave.
Chelmsford, MA 01824
Phone: (978) 244-4010
EMail: richard_woundy@cable.comcast.com
Kim Kinnear
Cisco Systems
1414 Massachusetts Ave
Boxborough, MA 01719
Phone: (978) 936-0000
EMail: kkinnear@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).