draft-ietf-dhc-leasequery-by-remote-id-00.txt   draft-ietf-dhc-leasequery-by-remote-id-01.txt 
DHC Working Group P. Kurapati DHC Working Group P. Kurapati
Internet-Draft R. Desetti Internet-Draft R. Desetti
Expires: April 23, 2009 B. Joshi Expires: July 17, 2009 B. Joshi
Infosys Technologies Ltd. Infosys Technologies Ltd.
October 20, 2008 January 13, 2009
DHCPv4 Leasequery by relay agent remote ID DHCPv4 Leasequery by relay agent remote ID
draft-ietf-dhc-leasequery-by-remote-id-00.txt draft-ietf-dhc-leasequery-by-remote-id-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 23, 2009. This Internet-Draft will expire on July 17, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
Some Relay Agents extract lease information from the DHCP message Some Relay Agents extract lease information from the DHCP message
exchanged between the client and DHCP server. This lease information exchanged between the client and DHCP server. This lease information
is used by relay agents for various purposes like antispoofing, is used by relay agents for various purposes like antispoofing,
prevention of flooding. RFC 4388 defines a mechanism for relay prevention of flooding. RFC 4388 defines a mechanism for relay
agents to retrieve the lease information from the DHCP server as and agents to retrieve the lease information from the DHCP server as and
when this information is lost. Existing leasequery mechanism is data when this information is lost. Existing leasequery mechanism is data
driven which means that a relay agent can initiate the leasequery driven which means that a relay agent can initiate the leasequery
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Information Acquisition before Data Starts . . . . . . . . 10 4.1. Information Acquisition before Data Starts . . . . . . . . 10
4.2. Lessen Negative Caching . . . . . . . . . . . . . . . . . 10 4.2. Lessen Negative Caching . . . . . . . . . . . . . . . . . 10
4.3. Antispoofing in 'Fast Path' . . . . . . . . . . . . . . . 10 4.3. Antispoofing in 'Fast Path' . . . . . . . . . . . . . . . 10
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 12 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Sending the DHCPLEASEQUERY Message . . . . . . . . . . . . 12 6.1. Sending the DHCPLEASEQUERY Message . . . . . . . . . . . . 13
6.2. Receiving the DHCPLEASEQUERY Message . . . . . . . . . . . 13 6.2. Receiving the DHCPLEASEQUERY Message . . . . . . . . . . . 14
6.3. Responding to the DHCPLEASEQUERY Message . . . . . . . . . 13 6.3. Responding to the DHCPLEASEQUERY Message . . . . . . . . . 14
6.4. Determining the IP address to be used in response . . . . 13 6.4. Determining the IP address to be used in response . . . . 14
6.5. Building a DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, or 6.5. Building a DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, or
DHCPLEASEACTIVE Messages . . . . . . . . . . . . . . . . . 14 DHCPLEASEACTIVE Messages . . . . . . . . . . . . . . . . . 15
6.6. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 6.6. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN Message . . . . . . . . . . . . . . . . . 16 DHCPLEASEUNKNOWN Message . . . . . . . . . . . . . . . . . 17
6.7. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or 6.7. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN Message . . . . . . . . . . . . . . . . . 16 DHCPLEASEUNKNOWN Message . . . . . . . . . . . . . . . . . 17
6.8. Receiving No Response to the DHCPLEASEQUERY Message . . . 17 6.8. Receiving No Response to the DHCPLEASEQUERY Message . . . 18
6.9. Lease Binding Data Storage Requirements . . . . . . . . . 17 6.9. Lease Binding Data Storage Requirements . . . . . . . . . 18
6.10. Using the DHCPLEASEQUERY Message with Multiple DHCP 6.10. Using the DHCPLEASEQUERY Message with Multiple DHCP
Servers . . . . . . . . . . . . . . . . . . . . . . . . . 17 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. RFC 4388 Considerations . . . . . . . . . . . . . . . . . . . 18 7. RFC 4388 Considerations . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 22 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 23
11.2. Informative Reference . . . . . . . . . . . . . . . . . . 22 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 23
Appendix 1. Why a New Leasequery is Required? . . . . . . . . . . 23 Appendix A. Why a New Leasequery is Required? . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
DHCP relay agents snoop DHCP messages and append relay agent DHCP relay agents snoop DHCP messages and append relay agent
information option before relaying it to the configured DHCP Servers. information option before relaying it to the configured DHCP Servers.
In this process, some relay agents also glean the lease information In this process, some relay agents also glean the lease information
sent by the server and maintain this locally. This information is sent by the server and maintain this locally. This information is
used for prevention of spoofing attempts from the clients and also used for prevention of spoofing attempts from the clients and also
sometimes used to install routing information. When relay agent sometimes used to install routing information. When relay agent
reboots, this information is lost. RFC 4388 [RFC4388] has defined a reboots, this information is lost. RFC 4388 [RFC4388] has defined a
skipping to change at page 11, line 40 skipping to change at page 11, line 40
not respond. not respond.
The query regime is described below: The query regime is described below:
o Query by Agent Remote ID sub-option: o Query by Agent Remote ID sub-option:
For this query, the requester supplies only a option 82 which will For this query, the requester supplies only a option 82 which will
include only an Agent Remote ID sub-option in the DHCPLEASEQUERY include only an Agent Remote ID sub-option in the DHCPLEASEQUERY
message. The DHCP server will return any information that it has on message. The DHCP server will return any information that it has on
the IP address most recently accessed by a client with that Agent the IP address most recently accessed by a client with that Agent
Remote ID. In addition, it may supply additional IP addresses that Remote ID. In addition, it SHOULD supply any additional IP addresses
have been associated with Agent Remote ID in different subnets. that have been associated with Agent Remote ID in different subnets.
Information about these bindings can then be found using the Query by Information about these bindings can then be found using the Query by
IP Address, as described in RFC 4388[RFC4388]. IP Address, as described in RFC 4388[RFC4388].
The DHCP server replies with a DHCPLEASEACTIVE message if the Agent The DHCP server MUST reply with a DHCPLEASEACTIVE message if the
Remote ID in the DHCPLEASEQUERY message currently has an active lease Agent Remote ID in the DHCPLEASEQUERY message currently has an active
on an IP address in this DHCP server. Server replies with a lease on an IP address in this DHCP server. The server MUST reply
DHCPLEASEUNASSIGNED if it has information of the said remote ID but with a DHCPLEASEUNASSIGNED if it has information of the said remote
no lease is assigned for the same. Server replies with a ID but no lease is assigned for the same. The server MAY keep track
of the remote ID values for which it has currently active leases as
well as any which it has served in the past but for which it has no
currently active leases. The server MUST reply with a
DHCPLEASEUNKNOWN message if it has no information of the said remote DHCPLEASEUNKNOWN message if it has no information of the said remote
ID. ID.
6. Protocol Details 6. Protocol Details
In this section, DHCPLEASEQUERY message refers to DHCPLEASEQUERY In this section, DHCPLEASEQUERY message refers to DHCPLEASEQUERY
message with query by remote ID. message with query by remote ID.
6.1. Sending the DHCPLEASEQUERY Message 6.1. Sending the DHCPLEASEQUERY Message
skipping to change at page 13, line 42 skipping to change at page 14, line 42
server manages the IP address allocation for the given remote ID, but server manages the IP address allocation for the given remote ID, but
there is no currently active lease. there is no currently active lease.
o DHCPLEASEUNKNOWN o DHCPLEASEUNKNOWN
The DHCPLEASEUNKNOWN message indicates that the client specified in The DHCPLEASEUNKNOWN message indicates that the client specified in
the DHCPLEASEQUERY message is not managed by the server. the DHCPLEASEQUERY message is not managed by the server.
o DHCPLEASEACTIVE o DHCPLEASEACTIVE
The DHCPLEASEACTIVE message indicates that the server not only know The DHCPLEASEACTIVE message indicates that the server not only knows
the client specified in the DHCPLEASEQUERY message, but also knows the client specified in the DHCPLEASEQUERY message, but also knows
that there is an active lease for that client. that there is an active lease for that client.
6.4. Determining the IP address to be used in response 6.4. Determining the IP address to be used in response
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 about which to "ciaddr" field -- determination of which IP address about which to
respond is a key issue. Of course, the values of additional IP respond is a key issue. Of course, the values of additional IP
addresses for which a client has a lease must also be returned in the addresses for which a client has a lease must also be returned in the
skipping to change at page 17, line 13 skipping to change at page 18, line 13
DHCPLEASEUNKNOWN. DHCPLEASEUNKNOWN.
6.8. Receiving No Response to the DHCPLEASEQUERY Message 6.8. 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, it should be handled in the same manner as suggested in RFC message, it should be handled in the same manner as suggested in RFC
4388 [RFC4388]. 4388 [RFC4388].
6.9. Lease Binding Data Storage Requirements 6.9. Lease Binding Data Storage Requirements
The lease binding data storage requirements are same as those Implementation Note:
specified in RFC 4388 [RFC4388].
To generate replies for a lease query by remote-id effeciently, a
DHCP server should index the lease binding data structures using
remote-id.
6.10. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers 6.10. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers
This scenario should be handled in the same way it is done in RFC This scenario should be handled in the same way it is done in RFC
4388 [RFC4388]. 4388 [RFC4388].
7. RFC 4388 Considerations 7. RFC 4388 Considerations
This document is compatible with RFC 4388 [RFC4388] based This document is compatible with RFC 4388 [RFC4388] based
implementations which means that a client which supports this implementations which means that a client which supports this
skipping to change at page 21, line 8 skipping to change at page 22, line 8
[RFC4388] specifications. [RFC4388] specifications.
9. IANA Considerations 9. IANA Considerations
This document does not introduce any new namespaces for the IANA to This document does not introduce any new namespaces for the IANA to
manage. manage.
10. Acknowledgments 10. Acknowledgments
Copious amounts of text in this document are derived from RFC 4388 Copious amounts of text in this document are derived from RFC 4388
[RFC4388]. [RFC4388]. Kim kinnear provided valuable feedback on this document.
11. References 11. References
11.1. Normative Reference 11.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC 4388, February 2006. Protocol (DHCP) Leasequery", RFC 4388, February 2006.
skipping to change at page 23, line 5 skipping to change at page 24, line 5
[RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)",
RFC 951, September 1985. RFC 951, September 1985.
[RFC1542] Wimer, W., "Clarifications and Extensions for the [RFC1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993. Bootstrap Protocol", RFC 1542, October 1993.
[RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor [RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
1. Why a New Leasequery is Required? Appendix A. Why a New Leasequery is Required?
The three existing query types supported by RFC 4388 do not provide The three existing query types supported by RFC 4388 do not provide
effective and efficient antispoofing for the above scenario. effective and efficient antispoofing for the above scenario.
o Query by Client Identifier o Query by Client Identifier
Query by Client Identifier is not possible because to use that access Query by Client Identifier is not possible because to use that access
concentrator need to glean client identifier also but the whole issue concentrator need to glean client identifier also but the whole issue
is that we need leasequeries because the gleaned information was is that we need leasequeries because the gleaned information was
lost. On the other hand, we can query by client identifier when lost. On the other hand, we can query by client identifier when
skipping to change at page 27, line 4 skipping to change at line 824
URI: http://www.infosys.com/ URI: http://www.infosys.com/
Bharat Joshi Bharat Joshi
Infosys Technologies Ltd. Infosys Technologies Ltd.
44 Electronics City, Hosur Road 44 Electronics City, Hosur Road
Bangalore 560 100 Bangalore 560 100
India India
Email: bharat_joshi@infosys.com Email: bharat_joshi@infosys.com
URI: http://www.infosys.com/ URI: http://www.infosys.com/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
 End of changes. 17 change blocks. 
41 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/