--- 1/draft-ietf-dhc-dhcvp6-leasequery-00.txt 2006-12-28 22:12:10.000000000 +0100 +++ 2/draft-ietf-dhc-dhcvp6-leasequery-01.txt 2006-12-28 22:12:11.000000000 +0100 @@ -1,21 +1,21 @@ DHC J. Brzozowski Internet-Draft Comcast Cable Intended status: Standards Track K. Kinnear -Expires: February 18, 2007 B. Volz +Expires: June 21, 2007 B. Volz S. Zeng Cisco Systems, Inc. - August 17, 2006 + December 18, 2006 DHCPv6 Leasequery - + Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -26,21 +26,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on February 18, 2007. + This Internet-Draft will expire on June 21, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies leasequery for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a means to obtain lease information about DHCPv6 clients from a DHCPv6 server. This @@ -48,46 +48,48 @@ both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3.1. On-Demand Query . . . . . . . . . . . . . . . . . . . . . 4 3.2. Anticipatory Query . . . . . . . . . . . . . . . . . . . . 4 + 3.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Message and Option Definitions . . . . . . . . . . . . . . 5 4.1.1. Messages . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. Options . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.1.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 8 - 4.1.4. Transmission and Retransmission Parameters . . . . . . 8 - 4.2. Message Validation . . . . . . . . . . . . . . . . . . . . 9 - 4.2.1. LEASEQUERY . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2.2. LEASEQUERY-REPLY . . . . . . . . . . . . . . . . . . . 9 - 4.3. DHCPv6 Leasequery Requestor Behavior . . . . . . . . . . . 9 - 4.3.1. Creation of LEASEQUERY . . . . . . . . . . . . . . . . 9 - 4.3.2. Transmission of LEASEQUERY . . . . . . . . . . . . . . 10 - 4.3.3. Receipt of LEASEQUERY-REPLY . . . . . . . . . . . . . 10 - 4.3.4. Handling DHCPv6 Client Data from Multiple Sources . . 11 - 4.4. DHCPv6 Leasequery Server Behavior . . . . . . . . . . . . 12 - 4.4.1. Receipt of LEASEQUERY Messages . . . . . . . . . . . . 12 - 4.4.2. Constructing the Client's OPTION_CLIENT_DATA . . . . . 13 - 4.4.3. Transmission of LEASEQUERY-REPLY Messages . . . . . . 13 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 - Intellectual Property and Copyright Statements . . . . . . . . . . 18 + 4.1.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 10 + 4.1.4. Transmission and Retransmission Parameters . . . . . . 11 + 4.2. Message Validation . . . . . . . . . . . . . . . . . . . . 11 + 4.2.1. LEASEQUERY . . . . . . . . . . . . . . . . . . . . . . 11 + 4.2.2. LEASEQUERY-REPLY . . . . . . . . . . . . . . . . . . . 11 + 4.3. DHCPv6 Leasequery Requestor Behavior . . . . . . . . . . . 12 + 4.3.1. Creation of LEASEQUERY . . . . . . . . . . . . . . . . 12 + 4.3.2. Transmission of LEASEQUERY . . . . . . . . . . . . . . 12 + 4.3.3. Receipt of LEASEQUERY-REPLY . . . . . . . . . . . . . 13 + 4.3.4. Handling DHCPv6 Client Data from Multiple Sources . . 13 + 4.4. DHCPv6 Leasequery Server Behavior . . . . . . . . . . . . 14 + 4.4.1. Receipt of LEASEQUERY Messages . . . . . . . . . . . . 14 + 4.4.2. Constructing the Client's OPTION_CLIENT_DATA . . . . . 15 + 4.4.3. Transmission of LEASEQUERY-REPLY Messages . . . . . . 16 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 + 8. Modification History . . . . . . . . . . . . . . . . . . . . . 18 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 + Intellectual Property and Copyright Statements . . . . . . . . . . 21 1. Introduction The DHCPv6 [2] protocol specifies a mechanism for the assignment of both IPv6 address and configuration information to IPv6 nodes. IPv6 Prefix Options for DHCPv6 [4] specifies a mechanism for the automated delegation of IPv6 prefixes and related options. Similar to DHCPv4 [6], DHCPv6 servers maintain authoritative information related to its operations including but not limited to lease information for IPv6 addresses and delegated prefixes. @@ -181,20 +183,34 @@ The rebuilding of the data store in this approach can take place as soon as possible after the need to rebuild it is discovered (such as on booting), and doesn't wait on the receipt of specific packets to trigger a piecemeal database update (as is the case for on-demand leasequery). This approach would also remove the limitation discussed above for prefix delegation. This anticipatory query is not specified in this document and is an area of future work. +3.3. Query Types + + Leasquery provides for the following queries: + + Query by IPv6 address - This query allows a requestor to request + from a server the bindings for a client that either is bound to + the address or has been delegated the prefix that contains the + address. + + Query by Client Identifier (DUID) - This query allows a requestor to + request from a server the bindings for a specific client on a + specific link or a list of the links on which the client has one + or more bindings. + 4. Protocol Details 4.1. Message and Option Definitions 4.1.1. Messages The LEASEQUERY and LEASEQUERY-REPLY messages use the Client/Server message formats described in [2], section 6. Two new message codes are defined: @@ -204,22 +220,22 @@ LEASEQUERY-REPLY (TBD) - A server sends a LEASEQUERY-REPLY message containing client data in response to a LEASEQUERY message. 4.1.2. Options 4.1.2.1. Query Option The Leasequery Query option is used only in a LEASEQUERY message and identifies the query being performed. The option includes the query - type, link-address (or 0::0 for no link), and option(s) to provide - data needed for the query. + type, link-address (or 0::0), and option(s) to provide data needed + for the query. The format of the Query option is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_LQ_QUERY | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | query-type | | +-+-+-+-+-+-+-+-+ | @@ -242,25 +258,31 @@ query applies, or 0::0 if unspecified. query-type the query requested (see below). query-options the options related to the query. The query-type and required query-options are: QUERY_BY_ADDRESS (1) - The query-options MUST contain an OPTION_IAADDR option [2]. The link-address field, if not 0::0, - MUST specify an address for the link on which the client is - located if the address in the OPTION_IAADDR option is of - insufficient scope. Only the information for the client that has - a lease for the specified address or was delegated a prefix that - contains the specified address is returned (if available). + specifies an address for the link on which the client is located + if the address in the OPTION_IAADDR option is of insufficient + scope. Only the information for the client that has a lease for + the specified address or was delegated a prefix that contains the + specified address is returned (if available). + + QUERY_BY_CLIENTID (2) - The query-options MUST contain an + OPTION_CLIENTID option [2]. The link-address field, if not 0::0, + specifies an address for the link on which the client is located. + If the link-address field is 0::0, the server SHOULD search all of + its links of the client. The query-options MAY also include an OPTION_ORO option [2] to indicate the options for each client that the requestor would like the server to return. Note that this OPTION_ORO is distinct and separate from an OPTION_ORO that may be in the requestor's LEASEQUERY message. If a server receives an OPTION_LQ_QUERY with a query-type it does not support, the server SHOULD return an UnknownQueryType status-code. If a server receives a supported query-type but the query-options is @@ -319,20 +341,115 @@ option-len 4 client-last-transaction-time the number of seconds since the server last communicated with the client (on that link). The client-last-transaction-time is a positive value and reflects the number of seconds since the server last communicated with the client (on that link). +4.1.2.4. Relay Data + + The Relay Data option is used only in a LEASEQUERY-REPLY message and + provides the relay agent information used when the client last + communicated with the server. + + The format of the Client Links option is shown below: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_LQ_RELAY_DATA | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | peer-address (IPv6 address) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | DHCP-relay-message | + . . + . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + option-code OPTION_LQ_RELAY_DATA (TBD) + + option-len 16 + length of DHCP-relay-message. + + peer-address The address of the relay agent from which + the relayed message was received by the + server. + + DHCP-relay-message + The last complete relayed message excluding + the client's message OPTION_RELAY_MSG + received by the server. + + This option is used by the server to return full relay agent + information for a client. It MUST NOT be returned if the server does + not have such information, either because the client last + communicated directly (without relay agent) with the server or if the + server does not retained such information. + + If returned, the DHCP-relay-message MUST contain a valid (perhaps + multi-hop) RELAY-FORW message as most recently received by the server + for the client. However, the (inner most) OPTION_RELAY_MSG option + containing the client's message MUST have been removed. + + This option SHOULD only be returned if requested by the OPTION_ORO of + the OPTION_LQ_QUERY. + +4.1.2.5. Client Link Option + + The Client Link option is used only in a LEASEQUERY-REPLY message and + identifies the links on which the client has one or more bindings. + It is used in reply to a query when no link-address was specified and + the client is found to be on more than one link. + + The format of the Client Link option is shown below: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_LQ_CLIENT_LINK | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | link-address (IPv6 address) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | link-address (IPv6 address) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + option-code OPTION_LQ_CLIENT_LINKS (TBD) + + option-len Length of the list of links in octets; + must be a multiple of 16. + + link-address A global address used by the server to + identify the link on which the client is + located. + + A server may respond to a query by client-id, where the 0::0 link- + address was specified, with this option if the client is found to be + on multiple links. The requestor may then repeat the query once for + each link-address returned in the list, specifying the returned link- + address. If the client is on a single link, the server SHOULD return + the client's data in an OPTION_CLIENT_DATA option. + 4.1.3. Status Codes The following new status codes are defined: UnknownQueryType (TBD) - The query-type is unknown to or not supported by the server. MalformedQuery (TBD) - The query is not valid, for example a required query-option is missing from the OPTION_LQ_QUERY. @@ -434,61 +551,51 @@ o Select another server from a list of servers known to the requestor. o Send to multiple servers by multicasting to the All_DHCP_Servers address. o Terminate the leasequery. 4.3.3. Receipt of LEASEQUERY-REPLY A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE - with an error code and may or may not contain client data in - OPTION_CLIENT_DATA options. A successful LEASEQUERY MAY contain no - OPTION_CLIENT_DATA if no clients matched the query. + option (or an OPTION_STATUS_CODE option with a success code). There + are three varients: + 1. If the server has bindings for the requested client, the message + includes an OPTION_CLIENT_DATA option and the requestor extracts + the client data for the LEASEQUERY-REPLY and updates its binding + information database. If the OPTION_CLIENT_DATA contains no + OPTION_CLT_TIME, the requestor SHOULD silently discard the + 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, + the message includes an OPTION_CLIENT_LINK option. The requestor + will need to reissue LEASEQUERY messages using each of the + returned link-addresses to obtain the client's bindings. + 3. If the server has no bindings for the client, neither the + OPTION_CLIENT_DATA nor OPTION_CLIENT_LINK option will be present. An unsuccessful LEASEQUERY-REPLY is one that has an - OPTION_STATUS_CODE with an error code. - -4.3.3.1. Receiving Successful LEASEQUERY-REPLY - - Upon the receipt of a successful LEASEQUERY-REPLY in response to a - LEASEQUERY, the requestor MUST extract the client data in the - LEASEQUERY-REPLY and may update its binding information database. - - 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]. - - If an OPTION_CLIENT_DATA contains no OPTION_CLT_TIME, the requestor - SHOULD silently discard the OPTION_CLIENT_DATA option. - - The requestor MUST be prepared to handle an OPTION_CLIENT_DATA that - contains more or fewer options than listed in the OPTION_ORO of the - LEASEQUERY message. - -4.3.3.2. Receiving Unsuccessful LEASEQUERY-REPLY - - An unsuccessful LEASEQUERY-REPLY contains an OPTION_STATUS_CODE with - one of the status codes listed in Section 4.1.3 or in [2] except - Success. - - Depending on the status code, the requestor may try a different - server (such as for NotAllowed, NotConfigured, and UnknownQueryType) - or try a different or corrected query (such as for UnknownQueryType - and MalformedQuery). + OPTION_STATUS_CODE with an error code. Depending on the status code, + the requestor may try a different server (such as for NotAllowed, + NotConfigured, and UnknownQueryType), try a different or corrected + query (such as for UnknownQueryType and MalformedQuery), or terminate + the query. 4.3.4. Handling DHCPv6 Client Data from Multiple Sources A requestor may receive lease data on the same client from the same DHCPv6 server in response to different types of LEASEQUERY. If a LEASEQUERY is sent to multiple servers, the requestor may receive from several servers lease data on the same DHCPv6 client. + 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 servers. The client data from the different sources may be disjoint or overlapping. The disjoint and overlapping relationship can happen between data from the same server or different servers. @@ -542,24 +649,36 @@ REPLY to the client. A server may also restrict LEASEQUERY messages, or query-types, to certain requestors. In this case, the server MAY discard the LEASEQUERY message or MAY add an OPTION_STATUS_CODE option with the NotAllowed status code and send the LEASEQUERY-REPLY to the requestor. If the OPTION_LQ_QUERY specified a non-zero link-address, the server MUST use the link-address to find the appropriate link for the - client. Otherwise, the server uses the address from the - OPTION_IAADDR option to find the appropriate link for the client. + client. For a QUERY_BY_ADDRESS, if the 0::0 link-address was + specified, the server uses the address from the OPTION_IAADDR option + to find the appropriate link for the client. In either of these + cases, if the server is unable to find the link, it SHOULD return an + OPTION_STATUS_CODE option with the NotConfigured status and send the + LEASEQUERY-REPLY to the requestor. - At this point, the server uses the data in the OPTION_LQ_QUERY to + For a QUERY_BY_CLIENTID, if a 0::0 link-address was specified, the + server MUST search all of its links for the client. If the client is + only found on a single link, the server SHOULD return that client's + data in an OPTION_CLIENT_DATA option. If the client is found on more + than a single link, the server MUST return the list of links in the + OPTION_CLIENT_LINK option; the server MUST NOT return any client + data. + + Otherwise, the server uses the data in the OPTION_LQ_QUERY to initiate the query. The result of the query will be zero or one client. This will result in zero or one OPTION_CLIENT_DATA option being added to the LEASEQUERY-REPLY. 4.4.2. Constructing the Client's OPTION_CLIENT_DATA An OPTION_CLIENT_DATA option in a LEASEQUERY-REPLY message MUST minimally contain the following data. 1. OPTION_CLIENTID 2. OPTION_IAADDR @@ -660,65 +779,85 @@ LEASEQUERY LEASEQUERY-REPLY IANA is requested to assign the following new DHCPv6 Option Codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters: OPTION_LQ_QUERY OPTION_CLIENT_DATA OPTION_CLT_TIME + OPTION_LQ_RELAY_DATA + OPTION_LQ_CLIENT_LINK IANA is requested to assign the following new DHCPv6 Status Codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters: UnknownQueryType MalformedQuery NotConfigured NotAllowed IANA is requested to create a new registry for the OPTION_LQ_QUERY option query-type codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters with the following initial assignments: QUERY_BY_ADDRESS 1 + QUERY_BY_CLIENTID 2 7. Acknowledgements Thanks to Ralph Droms, Richard Johnson, Josh Littlefield, Hemant Singh, Pak Siripunkaw, Markus Stenberg, and Ole Troan for their input, ideas, and review during the production of this document. -8. References +8. Modification History -8.1. Normative References + If this section is present in the document when it is submitted for + publication, the RFC Editor is requested to remove it. + + Changes in rev -01: + o Added the ability to query by client identifier (DUID), + QUERY_BY_CLIENTID. To avoid potentially large messages for + clients that are multihomed or mobile, a new option, + 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 + link, specifying the link-address in the query to get the client's + data. + o Added the ability to return full relay agent details via the + OPTION_LQ_RELAY_DATA option. + o And, other minor changes to accommodate the above. + +9. References + +9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [3] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006. [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [5] Volz, B. and R. Droms, "DHCPv6 Server Reply Sequence Number Option (draft-volz-dhc-dhcpv6-srsn-option-*)", August 2006. -8.2. Informative References +9.2. Informative References [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [7] Droms, R., Volz, B., and O. Troan, "DHCP Relay Agent Assignment Notification Option (draft-ietf-dhc-dhcpv6-agentopt-delegate-*)", August 2006. Authors' Addresses