< draft-ietf-dhc-dhcpv6-bulk-leasequery-05.txt   draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt >
DHC M. Stapp DHC M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track November 25, 2008 Intended status: Standards Track January 13, 2009
Expires: May 29, 2009 Expires: July 17, 2009
DHCPv6 Bulk Leasequery DHCPv6 Bulk Leasequery
draft-ietf-dhc-dhcpv6-bulk-leasequery-05.txt draft-ietf-dhc-dhcpv6-bulk-leasequery-06.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 May 29, 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
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been
extended with a Leasequery capability that allows a client to request extended with a Leasequery capability that allows a client to request
information about DHCPv6 bindings. That mechanism is limited to information about DHCPv6 bindings. That mechanism is limited to
queries for individual bindings. In some situations individual queries for individual bindings. In some situations individual
binding queries may not be efficient, or even possible. This binding queries may not be efficient, or even possible. This
document expands on the Leasequery protocol, adding new query types document expands on the Leasequery protocol, adding new query types
and allowing for bulk transfer of DHCPv6 binding data via TCP. and allowing for bulk transfer of DHCPv6 binding data via TCP.
skipping to change at page 2, line 41 skipping to change at page 2, line 46
6.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12 6.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 13 6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 13
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 13 7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 13
7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 14 7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 14
7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 15 7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 15
7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 15 7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. Modification History . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
The DHCPv6 [RFC3315] protocol specifies a mechanism for the The DHCPv6 [RFC3315] protocol specifies a mechanism for the
assignment of IPv6 address and configuration information to IPv6 assignment of IPv6 address and configuration information to IPv6
nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a
mechanism for DHCPv6 delegation of IPv6 prefixes and related data. mechanism for DHCPv6 delegation of IPv6 prefixes and related data.
DHCPv6 servers maintain authoritative information including binding DHCPv6 servers maintain authoritative information including binding
information for delegated IPv6 prefixes. information for delegated IPv6 prefixes.
skipping to change at page 10, line 7 skipping to change at page 10, line 7
DHCPv6 Servers that support Bulk Leasequery SHOULD listen for DHCPv6 Servers that support Bulk Leasequery SHOULD listen for
incoming TCP connections on the DHCPv6 server port 547. incoming TCP connections on the DHCPv6 server port 547.
Implementations MAY offer to make the incoming port configurable, but Implementations MAY offer to make the incoming port configurable, but
port 547 MUST be the default. Client implementations SHOULD make TCP port 547 MUST be the default. Client implementations SHOULD make TCP
connections to port 547, and MAY offer to make the destination server connections to port 547, and MAY offer to make the destination server
port configurable. port configurable.
This section presents a table of values used to control Bulk This section presents a table of values used to control Bulk
Leasequery behavior, including recommended defaults. Implementations Leasequery behavior, including recommended defaults. Implementations
MAY make these values configurable. MAY make these values configurable. However, configuring too-small
timeout values may lead to harmful behavior both to this application
as well as to other traffic in the network. As a result, timeout
values smaller than the default values are NOT RECOMMENDED.
Parameter Default Description Parameter Default Description
------------------------------------------ -------------------------------------------
BULK_LQ_CONN_TIMEOUT 30 secs Bulk Leasequery connection timeout BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout
BULK_LQ_DATA_TIMEOUT 30 secs Bulk Leasequery data timeout BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
BULK_LQ_MAX_RETRY 60 secs Max Bulk Leasequery retry timeout
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
6. Requestor Behavior 6. Requestor Behavior
6.1. Connecting 6.1. Connecting
A Requestor attempts to establish a TCP connection to a DHCPv6 Server A Requestor attempts to establish a TCP connection to a DHCPv6 Server
in order to initiate a Leasequery exchange. The Requestor SHOULD be in order to initiate a Leasequery exchange. If the attempt fails,
prepared to abandon the connection attempt after the Requestor MAY retry.
BULK_LQ_CONN_TIMEOUT. If the attempt fails, the Requestor MAY retry.
Retries MUST use an exponential backoff timer, increasing the
interval between attempts up to BULK_LQ_MAX_RETRY.
6.2. Forming Queries 6.2. Forming Queries
After a connection is established, the Requestor constructs a After a connection is established, the Requestor constructs a
Leasequery message, as specified in [RFC5007]. The query may have Leasequery message, as specified in [RFC5007]. The query may have
any of the defined query-types, and includes the options and data any of the defined query-types, and includes the options and data
required by the query-type chosen. The Requestor sends the message required by the query-type chosen. The Requestor sends the message
size then sends the actual DHCPv6 message, as described in size then sends the actual DHCPv6 message, as described in
Section 5.1. Section 5.1.
If the TCP connection becomes blocked while the Requestor is sending If the TCP connection becomes blocked or stops being writeable while
its query, the Requestor SHOULD be prepared to terminate the the Requestor is sending its query, the Requestor SHOULD be prepared
connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this
to allow Requestors to control the period of time they are willing to recommendation to allow Requestors to control the period of time they
wait before abandoning a connection, independent of notifications are willing to wait before abandoning a connection, independent of
from the TCP implementations they may be using. notifications from the TCP implementations they may be using.
6.3. Processing Replies 6.3. Processing Replies
The Requestor attempts to read a LEASEQUERY-REPLY message from the The Requestor attempts to read a LEASEQUERY-REPLY message from the
TCP connection. If the stream of replies becomes blocked, the TCP connection. If the TCP connection stops delivering reply data
Requestor SHOULD be prepared to terminate the connection after (if the connection stops being readable), the Requestor SHOULD be
BULK_LQ_DATA_TIMEOUT, and MAY begin retry processing if configured to prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT, and
do so. MAY begin retry processing if configured to do so.
The Requestor examines the LEASEQUERY-REPLY message, and determines The Requestor examines the LEASEQUERY-REPLY message, and determines
how to proceed. Message validation rules are specified in DHCPv6 how to proceed. Message validation rules are specified in DHCPv6
Leasequery [RFC5007]. If the reply contains an error status code Leasequery [RFC5007]. If the reply contains an error status code
(carried in an OPTION_STATUS_CODE option), the Requestor follows the (carried in an OPTION_STATUS_CODE option), the Requestor follows the
recommendations in [RFC5007]. A successful reply that does not recommendations in [RFC5007]. A successful reply that does not
include an OPTION_CLIENT_DATA option indicates that the target server include an OPTION_CLIENT_DATA option indicates that the target server
had no bindings matching the query. had no bindings matching the query.
Note: The Leasequery protocol uses the OPTION_CLIENT_LINK option as Note: The Leasequery protocol uses the OPTION_CLIENT_LINK option as
skipping to change at page 17, line 14 skipping to change at page 17, line 14
QUERY_BY_RELAY_ID QUERY_BY_RELAY_ID
QUERY_BY_LINK_ADDRESS QUERY_BY_LINK_ADDRESS
QUERY_BY_REMOTE_ID QUERY_BY_REMOTE_ID
10. Acknowledgements 10. Acknowledgements
Many of the ideas in this document were originally proposed by Kim Many of the ideas in this document were originally proposed by Kim
Kinnear, Richard Johnson, Hemant Singh, Ole Troan, and Bernie Volz. Kinnear, Richard Johnson, Hemant Singh, Ole Troan, and Bernie Volz.
Further suggestions and improvements were made by participants in the Further suggestions and improvements were made by participants in the
DHC working group, including John Brzozowski, Marcus Goller, Ted DHC working group, including John Brzozowski, Marcus Goller, Alfred
Lemon, and Bud Millwood. Hoenes, Ted Lemon, Bud Millwood, and Thomas Narten.
11. Modification History
12. References 11. References
12.1. Normative References 11.1. Normative References
[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.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
August 2006. August 2006.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007. "DHCPv6 Leasequery", RFC 5007, September 2007.
12.2. Informative References 11.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification for Transmission Control Protocol (TCP) Specification
Documents", RFC 4614, September 2006. Documents", RFC 4614, September 2006.
Author's Address Author's Address
Mark Stapp Mark Stapp
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 0000 Phone: +1 978 936 0000
Email: mjs@cisco.com Email: mjs@cisco.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. 15 change blocks. 
43 lines changed or deleted 47 lines changed or added

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