draft-ietf-dhc-dhcpv6-leasequery-00.txt   draft-ietf-dhc-dhcpv6-leasequery-01.txt 
DHC J. Brzozowski DHC J. Brzozowski
Internet-Draft Comcast Cable Internet-Draft Comcast Cable
Intended status: Standards Track K. Kinnear Intended status: Standards Track K. Kinnear
Expires: September 3, 2007 B. Volz Expires: June 21, 2007 B. Volz
S. Zeng S. Zeng
Cisco Systems, Inc. Cisco Systems, Inc.
March 2, 2007 December 18, 2006
DHCPv6 Leasequery DHCPv6 Leasequery
<draft-ietf-dhc-dhcpv6-leasequery-00.txt> <draft-ietf-dhc-dhcvp6-leasequery-01.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 September 3, 2007. This Internet-Draft will expire on June 21, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies leasequery for the Dynamic Host Configuration This document specifies leasequery for the Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) which can be used as a means to obtain Protocol for IPv6 (DHCPv6) which can be used as a means to obtain
lease information about DHCPv6 clients from a DHCPv6 server. This lease information about DHCPv6 clients from a DHCPv6 server. This
document specifies the scope of data that can be retrieved as well as document specifies the scope of data that can be retrieved as well as
both DHCPv6 leasequery requestor and server behavior. This document both DHCPv6 leasequery requestor and server behavior. This document
extends DHCPv6. extends DHCPv6.
skipping to change at page 2, line 39 skipping to change at page 2, line 39
4.4.1. Receipt of LEASEQUERY Messages . . . . . . . . . . . . 14 4.4.1. Receipt of LEASEQUERY Messages . . . . . . . . . . . . 14
4.4.2. Constructing the Client's OPTION_CLIENT_DATA . . . . . 15 4.4.2. Constructing the Client's OPTION_CLIENT_DATA . . . . . 15
4.4.3. Transmission of LEASEQUERY-REPLY Messages . . . . . . 16 4.4.3. Transmission of LEASEQUERY-REPLY Messages . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. Modification History . . . . . . . . . . . . . . . . . . . . . 18 8. Modification History . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
The DHCPv6 [2] protocol specifies a mechanism for the assignment of The DHCPv6 [2] protocol specifies a mechanism for the assignment of
both IPv6 address and configuration information to IPv6 nodes. IPv6 both IPv6 address and configuration information to IPv6 nodes. IPv6
Prefix Options for DHCPv6 [4] specifies a mechanism for the automated Prefix Options for DHCPv6 [4] specifies a mechanism for the automated
delegation of IPv6 prefixes and related options. Similar to DHCPv4 delegation of IPv6 prefixes and related options. Similar to DHCPv4
[5], DHCPv6 servers maintain authoritative information related to its [6], DHCPv6 servers maintain authoritative information related to its
operations including but not limited to lease information for IPv6 operations including but not limited to lease information for IPv6
addresses and delegated prefixes. addresses and delegated prefixes.
The requirement exists in various types of IPv6 deployments, The requirement exists in various types of IPv6 deployments,
particularly those of a broadband variety, to leverage DHCPv6 [2] for particularly those of a broadband variety, to leverage DHCPv6 [2] for
retrieving data related to the operation of DHCPv6 servers retrieving data related to the operation of DHCPv6 servers
programmatically. In particular it is desirable to be able to programmatically. In particular it is desirable to be able to
extract lease information about IPv6 addresses and delegated prefixes extract lease information about IPv6 addresses and delegated prefixes
assigned using DHCPv6 [2] [4]. Specific examples where this assigned using DHCPv6 [2] [4]. Specific examples where this
information has illustrated value are in broadband networks to information has illustrated value are in broadband networks to
skipping to change at page 13, line 30 skipping to change at page 13, line 30
4.3.3. Receipt of LEASEQUERY-REPLY 4.3.3. Receipt of LEASEQUERY-REPLY
A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE
option (or an OPTION_STATUS_CODE option with a success code). There option (or an OPTION_STATUS_CODE option with a success code). There
are three varients: are three varients:
1. If the server has bindings for the requested client, the message 1. If the server has bindings for the requested client, the message
includes an OPTION_CLIENT_DATA option and the requestor extracts includes an OPTION_CLIENT_DATA option and the requestor extracts
the client data for the LEASEQUERY-REPLY and updates its binding the client data for the LEASEQUERY-REPLY and updates its binding
information database. If the OPTION_CLIENT_DATA contains no information database. If the OPTION_CLIENT_DATA contains no
OPTION_CLT_TIME, the requestor SHOULD silently discard the OPTION_CLT_TIME, the requestor SHOULD silently discard the
OPTION_CLIENT_DATA option. OPTION_CLIENT_DATA option. The LEASEQUERY-REPLY SHOULD contain
an OPTION_SERVER_RSN option [5] and the requestor SHOULD only
update its binding information database as described in [5].
2. If the server found bindings for the client on multiple links, 2. If the server found bindings for the client on multiple links,
the message includes an OPTION_CLIENT_LINK option. The requestor the message includes an OPTION_CLIENT_LINK option. The requestor
will need to reissue LEASEQUERY messages using each of the will need to reissue LEASEQUERY messages using each of the
returned link-addresses to obtain the client's bindings. returned link-addresses to obtain the client's bindings.
3. If the server has no bindings for the client, neither the 3. If the server has no bindings for the client, neither the
OPTION_CLIENT_DATA nor OPTION_CLIENT_LINK option will be present. OPTION_CLIENT_DATA nor OPTION_CLIENT_LINK option will be present.
An unsuccessful LEASEQUERY-REPLY is one that has an An unsuccessful LEASEQUERY-REPLY is one that has an
OPTION_STATUS_CODE with an error code. Depending on the status code, OPTION_STATUS_CODE with an error code. Depending on the status code,
the requestor may try a different server (such as for NotAllowed, the requestor may try a different server (such as for NotAllowed,
NotConfigured, and UnknownQueryType), try a different or corrected NotConfigured, and UnknownQueryType), try a different or corrected
query (such as for UnknownQueryType and MalformedQuery), or terminate query (such as for UnknownQueryType and MalformedQuery), or terminate
the query. the query.
4.3.4. Handling DHCPv6 Client Data from Multiple Sources 4.3.4. Handling DHCPv6 Client Data from Multiple Sources
A requestor may receive lease data on the same client from the same A requestor may receive lease data on the same client from the same
DHCPv6 server in response to different types of LEASEQUERY. If a DHCPv6 server in response to different types of LEASEQUERY. If a
LEASEQUERY is sent to multiple servers, the requestor may receive LEASEQUERY is sent to multiple servers, the requestor may receive
from several servers lease data on the same DHCPv6 client. This from several servers lease data on the same DHCPv6 client.
section describes how the requestor handles multiple lease data
Additionally, if a requestor is an access concentrator, it may
receive lease data from other than leasequery exchanges, e.g., [7].
This section describes how the requestor handles multiple lease data
sources on the same DHCPv6 client from the same server or different sources on the same DHCPv6 client from the same server or different
servers. servers.
The client data from the different sources may be disjoint or The client data from the different sources may be disjoint or
overlapping. The disjoint and overlapping relationship can happen overlapping. The disjoint and overlapping relationship can happen
between data from the same server or different servers. between data from the same server or different servers.
If client data from two sources on the same client are of different If client data from two sources on the same client are of different
types or values, then the data are disjoint. An example of data of types or values, then the data are disjoint. An example of data of
different types is when a requestor receives an IPv6 address lease different types is when a requestor receives an IPv6 address lease
skipping to change at page 14, line 26 skipping to change at page 14, line 31
different servers, both assigned to the same client, but the leases different servers, both assigned to the same client, but the leases
are on two different IPv6 addresses. If the requestor receives are on two different IPv6 addresses. If the requestor receives
disjoint client data from different sources, it SHOULD merge them. disjoint client data from different sources, it SHOULD merge them.
If client data from two sources on the same client are of the same If client data from two sources on the same client are of the same
type and value, then the data are overlapping. An example of type and value, then the data are overlapping. An example of
overlapping data is when a requestor receives a lease on the same overlapping data is when a requestor receives a lease on the same
IPv6 address from two different servers. Overlapping client data are IPv6 address from two different servers. Overlapping client data are
also called conflicting data. also called conflicting data.
The requestor SHOULD use the OPTION_CLT_TIME to resolve data The requestor SHOULD use the OPTION_SERVER_RSN [5] to resolve data
conflicts originated from different servers, and SHOULD accept data conflicts originated from the same server, and SHOULD accept data
with most recent OPTION_CLT_TIME. with the higher server-sequence-number. The requestor SHOULD use the
OPTION_CLT_TIME to resolve data conflicts originated from different
servers, and SHOULD accept data with most recent OPTION_CLT_TIME.
4.4. DHCPv6 Leasequery Server Behavior 4.4. DHCPv6 Leasequery Server Behavior
A DHCPv6 server sends LEASEQUERY-REPLY messages in response to valid A DHCPv6 server sends LEASEQUERY-REPLY messages in response to valid
LEASEQUERY messages it receives to return the statefully assigned LEASEQUERY messages it receives to return the statefully assigned
addresses, delegated prefixes, and other information about that match addresses, delegated prefixes, and other information about that match
the query. the query.
4.4.1. Receipt of LEASEQUERY Messages 4.4.1. Receipt of LEASEQUERY Messages
skipping to change at page 16, line 37 skipping to change at page 16, line 45
If the requestor is an access concentrator, DHCPv6 leasequery If the requestor is an access concentrator, DHCPv6 leasequery
security SHOULD follow security between the relay agent and the security SHOULD follow security between the relay agent and the
DHCPv6 server as described in [2] Sections 21.1 and 22.11. DHCPv6 server as described in [2] Sections 21.1 and 22.11.
Requestors are essentially a DHCPv6 client for the purposes of the Requestors are essentially a DHCPv6 client for the purposes of the
LEASEQUERY message. Thus, DHCPv6 authentication [2] is also an LEASEQUERY message. Thus, DHCPv6 authentication [2] is also an
appropriate mechanism for securing LEASEQUERY and LEASEQUERY-REPLY appropriate mechanism for securing LEASEQUERY and LEASEQUERY-REPLY
messages. messages.
Access concentrators are expected to be common leasequery requestors. Access concentrators are expected to be common leasequery requestors.
Access concentrators that use DHCPv6 gleaning (i.e., [6]), refreshed Access concentrators that use DHCPv6 gleaning (i.e., [7]), refreshed
with LEASEQUERY messages, will maintain accurate client/binding with LEASEQUERY messages, will maintain accurate client/binding
information. This ensures that the access concentrator can forward information. This ensures that the access concentrator can forward
data traffic to the intended destination in the broadband access data traffic to the intended destination in the broadband access
network, can perform IPv6 source address verification of datagrams network, can perform IPv6 source address verification of datagrams
from the access network, and can encrypt traffic that can only be from the access network, and can encrypt traffic that can only be
decrypted by the intended access modem (e.g., [7] and [8]). Thus, decrypted by the intended access modem (e.g., [BPI] and [BPI+]).
the LEASEQUERY message allows an access concentrator to provide Thus, the LEASEQUERY message allows an access concentrator to provide
considerably enhanced security. DHCPv6 servers SHOULD prevent considerably enhanced security. DHCPv6 servers SHOULD prevent
exposure of their information (particularly the mapping of hardware exposure of their information (particularly the mapping of hardware
address to IPv6 address, which can be an invasion of broadband address to IPv6 address, which can be an invasion of broadband
subscriber privacy) by employing the techniques detailed in [2], subscriber privacy) by employing the techniques detailed in [2],
Section 21, "Authentication of DHCP Messages". Section 21, "Authentication of DHCP Messages".
DHCPv6 servers SHOULD also provide for the ability to restrict the DHCPv6 servers SHOULD also provide for the ability to restrict the
information that they make via leasequery, as described in information that they make via leasequery, as described in
Section 4.4.2. Section 4.4.2.
skipping to change at page 17, line 32 skipping to change at page 17, line 39
legitimate DHCPv6 leasequery requestors, denying configurations to legitimate DHCPv6 leasequery requestors, denying configurations to
legitimate DHCPv6 clients as well lease information to legitimate legitimate DHCPv6 clients as well lease information to legitimate
DHCPv6 leasequery requestors. DHCPv6 leasequery requestors.
One attack specific to an access concentrator as a requestor is the One attack specific to an access concentrator as a requestor is the
establishment of a malicious server with the intent of providing establishment of a malicious server with the intent of providing
incorrect lease or route information to the access concentrator, incorrect lease or route information to the access concentrator,
thwarting source IPv6 address verification and preventing correct thwarting source IPv6 address verification and preventing correct
routing. routing.
The use of the OPTION_SERVER_RSN option [5] does provide an attacker
that also knows the server's DUID the ability to effectively lock out
future updates from the real server by supply a large sequence
number.
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign the following new DHCPv6 Message types in IANA is requested to assign the following new DHCPv6 Message types in
the registry maintained in the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters: http://www.iana.org/assignments/dhcpv6-parameters:
LEASEQUERY LEASEQUERY
LEASEQUERY-REPLY LEASEQUERY-REPLY
IANA is requested to assign the following new DHCPv6 Option Codes in IANA is requested to assign the following new DHCPv6 Option Codes in
skipping to change at page 18, line 31 skipping to change at page 18, line 46
Thanks to Ralph Droms, Richard Johnson, Josh Littlefield, Hemant Thanks to Ralph Droms, Richard Johnson, Josh Littlefield, Hemant
Singh, Pak Siripunkaw, Markus Stenberg, and Ole Troan for their Singh, Pak Siripunkaw, Markus Stenberg, and Ole Troan for their
input, ideas, and review during the production of this document. input, ideas, and review during the production of this document.
8. Modification History 8. Modification History
If this section is present in the document when it is submitted for If this section is present in the document when it is submitted for
publication, the RFC Editor is requested to remove it. publication, the RFC Editor is requested to remove it.
This document was previously accidentally published under an Changes in rev -01:
incorrect name, draft-ietf-dhc-dhcvp6-leasequery-00 and
draft-ietf-dhc-dhcvp6-leasequery-01. The changes between the -00 and
-01 version were:
o Added the ability to query by client identifier (DUID), o Added the ability to query by client identifier (DUID),
QUERY_BY_CLIENTID. To avoid potentially large messages for QUERY_BY_CLIENTID. To avoid potentially large messages for
clients that are multihomed or mobile, a new option, clients that are multihomed or mobile, a new option,
OPTION_LQ_CLIENT_LINK, to return the list of the links the client OPTION_LQ_CLIENT_LINK, to return the list of the links the client
is on was added. The requestor then needs to re-query for each is on was added. The requestor then needs to re-query for each
link, specifying the link-address in the query to get the client's link, specifying the link-address in the query to get the client's
data. data.
o Added the ability to return full relay agent details via the o Added the ability to return full relay agent details via the
OPTION_LQ_RELAY_DATA option. OPTION_LQ_RELAY_DATA option.
o And, other minor changes to accommodate the above. o And, other minor changes to accommodate the above.
The changes between draft-ietf-dhc-dhcvp6-leasequery-01 and this
version with the corrected document name were:
o Fixed draft name (had dhcvp6 instead of dhcpv6).
o Removed reference to SRSN I-D and associated text. SRSN is only
needed if and when RAAN moves forward (in or close to its current
form).
o Added [7] and [8] references that were missing (referenced in
Security Considerations section).
o Updated RAAN I-D reference to current version.
o Updated boilerplate and copyright year.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003. RFC 3315, July 2003.
[3] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol [3] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol
(DHCP) Leasequery", RFC 4388, February 2006. (DHCP) Leasequery", RFC 4388, February 2006.
[4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[5] Volz, B. and R. Droms, "DHCPv6 Server Reply Sequence Number
Option (draft-volz-dhc-dhcpv6-srsn-option-*)", August 2006.
9.2. Informative References 9.2. Informative References
[5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[6] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN) [7] Droms, R., Volz, B., and O. Troan, "DHCP Relay Agent Assignment
Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-02 (work in Notification Option
progress), November 2006. (draft-ietf-dhc-dhcpv6-agentopt-delegate-*)", August 2006.
[7] 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/.
[8] CableLab, "Data-Over-Cable Service Interface Specifications:
Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-
050812", August 2005, available at http://www.cablemodem.com/.
Authors' Addresses Authors' Addresses
John Jason Brzozowski John Jason Brzozowski
Comcast Cable Comcast Cable
1800 Bishops Gate Boulevard 1800 Bishops Gate Boulevard
Mt. Laurel, NJ 08054 Mt. Laurel, NJ 08054
USA USA
Phone: +1 856 324 2671 Phone: +1 856 324 2671
skipping to change at page 21, line 7 skipping to change at page 21, line 7
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: szeng@cisco.com Email: szeng@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 20 change blocks. 
50 lines changed or deleted 41 lines changed or added

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