idnits 2.17.1 draft-ietf-dhc-dhcvp6-leasequery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 924. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 937. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 261 has weird spacing: '...options the...' == Line 313 has weird spacing: '...options the ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 18, 2006) is 6338 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'BPI' on line 732 ** Obsolete normative reference: RFC 3315 (ref. '2') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (ref. '4') (Obsoleted by RFC 8415) -- No information found for draft-volz-dhc-dhcpv6-srsn-option- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' -- No information found for draft-ietf-dhc-dhcpv6-agentopt-delegate- - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC J. Brzozowski 3 Internet-Draft Comcast Cable 4 Intended status: Standards Track K. Kinnear 5 Expires: June 21, 2007 B. Volz 6 S. Zeng 7 Cisco Systems, Inc. 8 December 18, 2006 10 DHCPv6 Leasequery 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 21, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document specifies leasequery for the Dynamic Host Configuration 45 Protocol for IPv6 (DHCPv6) which can be used as a means to obtain 46 lease information about DHCPv6 clients from a DHCPv6 server. This 47 document specifies the scope of data that can be retrieved as well as 48 both DHCPv6 leasequery requestor and server behavior. This document 49 extends DHCPv6. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. On-Demand Query . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Anticipatory Query . . . . . . . . . . . . . . . . . . . . 4 58 3.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Message and Option Definitions . . . . . . . . . . . . . . 5 61 4.1.1. Messages . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1.2. Options . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 10 64 4.1.4. Transmission and Retransmission Parameters . . . . . . 11 65 4.2. Message Validation . . . . . . . . . . . . . . . . . . . . 11 66 4.2.1. LEASEQUERY . . . . . . . . . . . . . . . . . . . . . . 11 67 4.2.2. LEASEQUERY-REPLY . . . . . . . . . . . . . . . . . . . 11 68 4.3. DHCPv6 Leasequery Requestor Behavior . . . . . . . . . . . 12 69 4.3.1. Creation of LEASEQUERY . . . . . . . . . . . . . . . . 12 70 4.3.2. Transmission of LEASEQUERY . . . . . . . . . . . . . . 12 71 4.3.3. Receipt of LEASEQUERY-REPLY . . . . . . . . . . . . . 13 72 4.3.4. Handling DHCPv6 Client Data from Multiple Sources . . 13 73 4.4. DHCPv6 Leasequery Server Behavior . . . . . . . . . . . . 14 74 4.4.1. Receipt of LEASEQUERY Messages . . . . . . . . . . . . 14 75 4.4.2. Constructing the Client's OPTION_CLIENT_DATA . . . . . 15 76 4.4.3. Transmission of LEASEQUERY-REPLY Messages . . . . . . 16 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 80 8. Modification History . . . . . . . . . . . . . . . . . . . . . 18 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 85 Intellectual Property and Copyright Statements . . . . . . . . . . 21 87 1. Introduction 89 The DHCPv6 [2] protocol specifies a mechanism for the assignment of 90 both IPv6 address and configuration information to IPv6 nodes. IPv6 91 Prefix Options for DHCPv6 [4] specifies a mechanism for the automated 92 delegation of IPv6 prefixes and related options. Similar to DHCPv4 93 [6], DHCPv6 servers maintain authoritative information related to its 94 operations including but not limited to lease information for IPv6 95 addresses and delegated prefixes. 97 The requirement exists in various types of IPv6 deployments, 98 particularly those of a broadband variety, to leverage DHCPv6 [2] for 99 retrieving data related to the operation of DHCPv6 servers 100 programmatically. In particular it is desirable to be able to 101 extract lease information about IPv6 addresses and delegated prefixes 102 assigned using DHCPv6 [2] [4]. Specific examples where this 103 information has illustrated value are in broadband networks to 104 facilitate access control by edge devices. This capability to 105 programitcally extract lease data from the DHCPv6 server is called 106 leasequery. 108 Existing specifications, such as [3] are leveraged as a basis for 109 extending the DHCPv6 protocol to support leasequery. The motivations 110 and justifications identified in [3] also generally apply to this 111 specification. Furthermore, advancements in DHCPv6 [2] are expanded 112 upon to specify additional means by which IPv6 address and delegated 113 prefix lease data can be retrieved through DHCPv6 leasequery. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [1]. 121 DHCPv6 terminology is defined in [2]. Terminology specific to DHCPv6 122 leasequery can be found below: 124 client(s) The nodes that have one or more bindings 125 with a DHCPv6 server. This does not refer to 126 the node issuing the LEASEQUERY unless it 127 itself has one or more bindings with a DHCPv6 128 server. 130 requestor The node that sends LEASEQUERY messages to one 131 or more servers to retrieve information on the 132 bindings for a client. 134 3. Protocol Overview 136 The focus of this document is to extend the DHCPv6 protocol to allow 137 processes and devices that wish to access information from a DHCPv6 138 server to do so in a lightweight and convenient manner. It is 139 especially appropriate for processes and devices that already 140 interpret DHCPv6 messages. 142 The LEASEQUERY message is a query message only and does not affect 143 the state of the IPv6 address or prefix, or the binding information 144 associated with it. 146 One important motivating example is that the LEASEQUERY message 147 allows access concentrators to query DHCP servers to obtain location 148 information of broadband access network devices. 150 The leasequery capability described in this document parallels the 151 DHCPv4 leasequery capability documented in [3]. As such, it shares 152 many of the basic motivations, design goals and constraints as the 153 capability described in Section 4 of [3]. 155 3.1. On-Demand Query 157 The on-demand leasequery capability allows requesting just the 158 information necessary to satisfy an immediate need. If the requestor 159 is an access concentrator, then the immediate need will typically be 160 that it has received an IPv6 packet and it needs to refresh its 161 information concerning the DHCPv6 client to which that an IPv6 162 address is currently leased. In this case, the request will be by 163 Address. This fits clearly into the single request/response cycle 164 common to other DHCPv6 message exchanges. 166 However, this approach has limitations when used with prefix 167 delegation [4] as no traffic may arrive because the access 168 concentrator is unable to inject the appropriate routing information 169 into the routing infrastructure, such as after a reboot. This 170 approach does work if the access concentrator is configured to inject 171 routing information for a prefix which aggregates potentially 172 delegated prefixes. Or, if the access concentrator and requesting 173 router use a routing protocol; as then the requesting router can 174 trigger the access concentrator to request information from a DHCPv6 175 server and inject appropriate routing information into the routing 176 infrastructure. 178 3.2. Anticipatory Query 180 A second approach for requesting information from a DHCPv6 server 181 would be to use a leasequery-like capability to rebuild an internal 182 data store containing information available from a DHCPv6 server. 183 The rebuilding of the data store in this approach can take place as 184 soon as possible after the need to rebuild it is discovered (such as 185 on booting), and doesn't wait on the receipt of specific packets to 186 trigger a piecemeal database update (as is the case for on-demand 187 leasequery). This approach would also remove the limitation 188 discussed above for prefix delegation. 190 This anticipatory query is not specified in this document and is an 191 area of future work. 193 3.3. Query Types 195 Leasquery provides for the following queries: 197 Query by IPv6 address - This query allows a requestor to request 198 from a server the bindings for a client that either is bound to 199 the address or has been delegated the prefix that contains the 200 address. 202 Query by Client Identifier (DUID) - This query allows a requestor to 203 request from a server the bindings for a specific client on a 204 specific link or a list of the links on which the client has one 205 or more bindings. 207 4. Protocol Details 209 4.1. Message and Option Definitions 211 4.1.1. Messages 213 The LEASEQUERY and LEASEQUERY-REPLY messages use the Client/Server 214 message formats described in [2], section 6. Two new message codes 215 are defined: 217 LEASEQUERY (TBD) - A requestor sends a LEASEQUERY message to any 218 available server to obtain information on a client's or clients' 219 leases. The options in an OPTION_LQ_QUERY determine the query. 221 LEASEQUERY-REPLY (TBD) - A server sends a LEASEQUERY-REPLY message 222 containing client data in response to a LEASEQUERY message. 224 4.1.2. Options 225 4.1.2.1. Query Option 227 The Leasequery Query option is used only in a LEASEQUERY message and 228 identifies the query being performed. The option includes the query 229 type, link-address (or 0::0), and option(s) to provide data needed 230 for the query. 232 The format of the Query option is shown below: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | OPTION_LQ_QUERY | option-len | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | query-type | | 240 +-+-+-+-+-+-+-+-+ | 241 | | 242 | link-address | 243 | | 244 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | . 246 +-+-+-+-+-+-+-+-+ . 247 . query-options . 248 . . 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 option-code OPTION_LQ_QUERY (TBD) 253 option-len 17 + length of query-options field. 255 link-address A global address that will be used by the 256 server to identify the link to which the 257 query applies, or 0::0 if unspecified. 259 query-type the query requested (see below). 261 query-options the options related to the query. 263 The query-type and required query-options are: 265 QUERY_BY_ADDRESS (1) - The query-options MUST contain an 266 OPTION_IAADDR option [2]. The link-address field, if not 0::0, 267 specifies an address for the link on which the client is located 268 if the address in the OPTION_IAADDR option is of insufficient 269 scope. Only the information for the client that has a lease for 270 the specified address or was delegated a prefix that contains the 271 specified address is returned (if available). 273 QUERY_BY_CLIENTID (2) - The query-options MUST contain an 274 OPTION_CLIENTID option [2]. The link-address field, if not 0::0, 275 specifies an address for the link on which the client is located. 276 If the link-address field is 0::0, the server SHOULD search all of 277 its links of the client. 279 The query-options MAY also include an OPTION_ORO option [2] to 280 indicate the options for each client that the requestor would like 281 the server to return. Note that this OPTION_ORO is distinct and 282 separate from an OPTION_ORO that may be in the requestor's LEASEQUERY 283 message. 285 If a server receives an OPTION_LQ_QUERY with a query-type it does not 286 support, the server SHOULD return an UnknownQueryType status-code. 287 If a server receives a supported query-type but the query-options is 288 missing a required option, the server SHOULD return a MalformedQuery 289 status-code. 291 4.1.2.2. Client Data Option 293 The Client Data option is used to encapsulate the data for a single 294 client on a single link in a LEASEQUERY-REPLY message. 296 The format of the Client Data option is shown below: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | OPTION_CLIENT_DATA | option-len | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 . . 304 . client-options . 305 . . 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 option-code OPTION_CLIENT_DATA (TBD) 310 option-len length, in octets, of the encapsulated client- 311 options field. 313 client-options the options associated with this client. 315 The encapsulated client-options include the OPTION_CLIENTID, 316 OPTION_IAADDR, OPTION_IAPREFIX, and OPTION_CLT_TIME options and other 317 options specific to the client and requested by the requestor in the 318 OPTION_ORO in the OPTION_LQ_QUERY's query-options. The server MUST 319 return all of the client's statefully assigned addresses and 320 delegated prefixes, with a non-zero valid lifetime, on the link. 322 4.1.2.3. Client Last Transaction Time Option 324 The Client Last Transaction Time option is encapsulated in an 325 OPTION_CLIENT_DATA and identifies how long ago the server last 326 communicated with the client, in seconds. 328 The format of the Client Last Transaction Time option is shown below: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | OPTION_CLT_TIME | option-len | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | client-last-transaction-time | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 option-code OPTION_CLT_TIME (TBD) 340 option-len 4 342 client-last-transaction-time 343 the number of seconds since the server last 344 communicated with the client (on that link). 346 The client-last-transaction-time is a positive value and reflects the 347 number of seconds since the server last communicated with the client 348 (on that link). 350 4.1.2.4. Relay Data 352 The Relay Data option is used only in a LEASEQUERY-REPLY message and 353 provides the relay agent information used when the client last 354 communicated with the server. 356 The format of the Client Links option is shown below: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | OPTION_LQ_RELAY_DATA | option-len | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 | peer-address (IPv6 address) | 365 | | 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 | DHCP-relay-message | 370 . . 371 . . 372 . . 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 option-code OPTION_LQ_RELAY_DATA (TBD) 377 option-len 16 + length of DHCP-relay-message. 379 peer-address The address of the relay agent from which 380 the relayed message was received by the 381 server. 383 DHCP-relay-message 384 The last complete relayed message excluding 385 the client's message OPTION_RELAY_MSG 386 received by the server. 388 This option is used by the server to return full relay agent 389 information for a client. It MUST NOT be returned if the server does 390 not have such information, either because the client last 391 communicated directly (without relay agent) with the server or if the 392 server does not retained such information. 394 If returned, the DHCP-relay-message MUST contain a valid (perhaps 395 multi-hop) RELAY-FORW message as most recently received by the server 396 for the client. However, the (inner most) OPTION_RELAY_MSG option 397 containing the client's message MUST have been removed. 399 This option SHOULD only be returned if requested by the OPTION_ORO of 400 the OPTION_LQ_QUERY. 402 4.1.2.5. Client Link Option 404 The Client Link option is used only in a LEASEQUERY-REPLY message and 405 identifies the links on which the client has one or more bindings. 406 It is used in reply to a query when no link-address was specified and 407 the client is found to be on more than one link. 409 The format of the Client Link option is shown below: 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | OPTION_LQ_CLIENT_LINK | option-len | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 | link-address (IPv6 address) | 418 | | 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | | 422 | link-address (IPv6 address) | 423 | | 424 | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | ... | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 option-code OPTION_LQ_CLIENT_LINKS (TBD) 431 option-len Length of the list of links in octets; 432 must be a multiple of 16. 434 link-address A global address used by the server to 435 identify the link on which the client is 436 located. 438 A server may respond to a query by client-id, where the 0::0 link- 439 address was specified, with this option if the client is found to be 440 on multiple links. The requestor may then repeat the query once for 441 each link-address returned in the list, specifying the returned link- 442 address. If the client is on a single link, the server SHOULD return 443 the client's data in an OPTION_CLIENT_DATA option. 445 4.1.3. Status Codes 447 The following new status codes are defined: 449 UnknownQueryType (TBD) - The query-type is unknown to or not 450 supported by the server. 452 MalformedQuery (TBD) - The query is not valid, for example a 453 required query-option is missing from the OPTION_LQ_QUERY. 455 NotConfigured (TBD) - The server does not have the target address or 456 link in its configuration. 458 NotAllowed (TBD) - The server does not allow the requestor to issue 459 this LEASEQUERY. 461 4.1.4. Transmission and Retransmission Parameters 463 This section presents a table of values used to describe the message 464 transmission behavior for leasequery. 466 Parameter Default Description 467 ---------------------------------- 468 LQ_TIMEOUT 1 sec Initial LEASEQUERY timeout 469 LQ_MAX_RT 10 secs Max LEASEQUERY timeout value 470 LQ_MAX_RC 5 Max LEASEQUERY retry attempts 472 4.2. Message Validation 474 4.2.1. LEASEQUERY 476 Requestors and clients MUST discard any received LEASEQUERY messages. 478 Servers MUST discard any received LEASEQUERY messages that meet any 479 of the following conditions: 480 o the message does not include an OPTION_CLIENTID option. 481 o the message includes an OPTION_SERVERID option but the contents of 482 the OPTION_SERVERID option does not match the server's identifier. 483 o the message does not include an OPTION_LQ_QUERY option. 485 4.2.2. LEASEQUERY-REPLY 487 Requestors MUST discard any received LEASEQUERY-REPLY messages that 488 meet any of the following conditions: 489 o the message does not include an OPTION_SERVERID option. 490 o the message does not include an OPTION_CLIENTID option or the 491 contents of the OPTION_CLIENTID option do not match the DUID of 492 the requestor. 493 o the "transaction-id" field in the message does not match the value 494 used in the original message. 496 Servers and Relay Agents (on the server port, 547 [2]) MUST discard 497 any received LEASEQUERY-REPLY messages. 499 4.3. DHCPv6 Leasequery Requestor Behavior 501 This section describes how a requestor initiates lease data retrieval 502 from DHCPv6 servers. 504 4.3.1. Creation of LEASEQUERY 506 The requestor sets the "msg-type" field to LEASEQUERY. The requestor 507 generates a transaction ID and inserts this value in the 508 "transaction-id" field. 510 The requestor MUST include an OPTION_CLIENTID option to identify 511 itself to the server. 513 The requestor MUST include an OPTION_LQ_QUERY option and set the 514 query-type, link-address, and query-options as appropriate to the 515 query-type (Section 4.1.2.1). 517 The requestor SHOULD include an OPTION_SERVERID if it is not 518 unicasting the LEASEQUERY yet only wants a response from a specific 519 server. 521 4.3.2. Transmission of LEASEQUERY 523 The requestor MAY be configured to use a list of destination 524 addresses, which MAY include unicast addresses, the All_DHCP_Servers 525 multicast address, or other addresses selected by the network 526 administrator. If the requestor has not been explicitly configured, 527 it MAY use the All_DHCP_Servers multicast address as the default. 529 The requestor SHOULD send LEASEQUERY to one or more DHCPv6 servers 530 which are known to possess authoritative information concerning the 531 query target. 533 In the absence of information concerning which DHCPv6 servers might 534 possess authoritative information on the query target, the requestor 535 SHOULD send LEASEQUERY to all DHCPv6 servers that the requestor knows 536 about or is configured with. For example, the requestor MAY send 537 LEASEQUERY to the All_DHCP_Servers multicast address. 539 The requestor transmits LEASEQUERY messages according to section 14 540 of [2], using the following parameters: 542 IRT LQ_TIMEOUT 543 MRT LQ_MAX_RT 544 MRC LQ_MAX_RC 545 MRD 0 547 If the message exchange fails, the requestor takes an action based on 548 the requestor's local policy. Examples of actions the requestor 549 might take include: 551 o Select another server from a list of servers known to the 552 requestor. 553 o Send to multiple servers by multicasting to the All_DHCP_Servers 554 address. 555 o Terminate the leasequery. 557 4.3.3. Receipt of LEASEQUERY-REPLY 559 A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE 560 option (or an OPTION_STATUS_CODE option with a success code). There 561 are three varients: 562 1. If the server has bindings for the requested client, the message 563 includes an OPTION_CLIENT_DATA option and the requestor extracts 564 the client data for the LEASEQUERY-REPLY and updates its binding 565 information database. If the OPTION_CLIENT_DATA contains no 566 OPTION_CLT_TIME, the requestor SHOULD silently discard the 567 OPTION_CLIENT_DATA option. The LEASEQUERY-REPLY SHOULD contain 568 an OPTION_SERVER_RSN option [5] and the requestor SHOULD only 569 update its binding information database as described in [5]. 570 2. If the server found bindings for the client on multiple links, 571 the message includes an OPTION_CLIENT_LINK option. The requestor 572 will need to reissue LEASEQUERY messages using each of the 573 returned link-addresses to obtain the client's bindings. 574 3. If the server has no bindings for the client, neither the 575 OPTION_CLIENT_DATA nor OPTION_CLIENT_LINK option will be present. 577 An unsuccessful LEASEQUERY-REPLY is one that has an 578 OPTION_STATUS_CODE with an error code. Depending on the status code, 579 the requestor may try a different server (such as for NotAllowed, 580 NotConfigured, and UnknownQueryType), try a different or corrected 581 query (such as for UnknownQueryType and MalformedQuery), or terminate 582 the query. 584 4.3.4. Handling DHCPv6 Client Data from Multiple Sources 586 A requestor may receive lease data on the same client from the same 587 DHCPv6 server in response to different types of LEASEQUERY. If a 588 LEASEQUERY is sent to multiple servers, the requestor may receive 589 from several servers lease data on the same DHCPv6 client. 591 Additionally, if a requestor is an access concentrator, it may 592 receive lease data from other than leasequery exchanges, e.g., [7]. 593 This section describes how the requestor handles multiple lease data 594 sources on the same DHCPv6 client from the same server or different 595 servers. 597 The client data from the different sources may be disjoint or 598 overlapping. The disjoint and overlapping relationship can happen 599 between data from the same server or different servers. 601 If client data from two sources on the same client are of different 602 types or values, then the data are disjoint. An example of data of 603 different types is when a requestor receives an IPv6 address lease 604 from one server and a prefix lease from another server, both assigned 605 to the same client. An example of different values (but the same 606 type) is when a requestor receives two IPv6 address leases from two 607 different servers, both assigned to the same client, but the leases 608 are on two different IPv6 addresses. If the requestor receives 609 disjoint client data from different sources, it SHOULD merge them. 611 If client data from two sources on the same client are of the same 612 type and value, then the data are overlapping. An example of 613 overlapping data is when a requestor receives a lease on the same 614 IPv6 address from two different servers. Overlapping client data are 615 also called conflicting data. 617 The requestor SHOULD use the OPTION_SERVER_RSN [5] to resolve data 618 conflicts originated from the same server, and SHOULD accept data 619 with the higher server-sequence-number. The requestor SHOULD use the 620 OPTION_CLT_TIME to resolve data conflicts originated from different 621 servers, and SHOULD accept data with most recent OPTION_CLT_TIME. 623 4.4. DHCPv6 Leasequery Server Behavior 625 A DHCPv6 server sends LEASEQUERY-REPLY messages in response to valid 626 LEASEQUERY messages it receives to return the statefully assigned 627 addresses, delegated prefixes, and other information about that match 628 the query. 630 4.4.1. Receipt of LEASEQUERY Messages 632 Upon receipt of a valid LEASEQUERY message, the DHCPv6 server locates 633 the requested client, collects data on the client, and constructs and 634 returns a LEASEQUERY-REPLY. A LEASEQUERY message can not be used to 635 assign, release, or otherwise modify bindings or other configuration 636 information. 638 The server constructs a LEASEQUERY-REPLY message by setting the "msg- 639 type" field to LEASEQUERY-REPLY, and copying the transaction ID from 640 the LEASEQUERY message into the transaction-id field. 642 If the query-type in the OPTION_LQ_QUERY option is not a known or 643 supported value, the server adds an OPTION_STATUS_CODE option with 644 the UnknownQueryType status code and sends the LEASEQUERY-REPLY to 645 the requestor. If the query-options do not contain the required 646 options for the query-type, the server adds an OPTION_STATUS_CODE 647 option with the MalformedQuery status code and sends the LEASEQUERY- 648 REPLY to the client. 650 A server may also restrict LEASEQUERY messages, or query-types, to 651 certain requestors. In this case, the server MAY discard the 652 LEASEQUERY message or MAY add an OPTION_STATUS_CODE option with the 653 NotAllowed status code and send the LEASEQUERY-REPLY to the 654 requestor. 656 If the OPTION_LQ_QUERY specified a non-zero link-address, the server 657 MUST use the link-address to find the appropriate link for the 658 client. For a QUERY_BY_ADDRESS, if the 0::0 link-address was 659 specified, the server uses the address from the OPTION_IAADDR option 660 to find the appropriate link for the client. In either of these 661 cases, if the server is unable to find the link, it SHOULD return an 662 OPTION_STATUS_CODE option with the NotConfigured status and send the 663 LEASEQUERY-REPLY to the requestor. 665 For a QUERY_BY_CLIENTID, if a 0::0 link-address was specified, the 666 server MUST search all of its links for the client. If the client is 667 only found on a single link, the server SHOULD return that client's 668 data in an OPTION_CLIENT_DATA option. If the client is found on more 669 than a single link, the server MUST return the list of links in the 670 OPTION_CLIENT_LINK option; the server MUST NOT return any client 671 data. 673 Otherwise, the server uses the data in the OPTION_LQ_QUERY to 674 initiate the query. The result of the query will be zero or one 675 client. This will result in zero or one OPTION_CLIENT_DATA option 676 being added to the LEASEQUERY-REPLY. 678 4.4.2. Constructing the Client's OPTION_CLIENT_DATA 680 An OPTION_CLIENT_DATA option in a LEASEQUERY-REPLY message MUST 681 minimally contain the following data. 682 1. OPTION_CLIENTID 683 2. OPTION_IAADDR 684 3. OPTION_IAPREFIX 685 4. OPTION_CLT_TIME 687 Depending on the bindings the client has on a link, either 688 OPTION_IAADDR options, OPTION_IAPREFIX options, or both may be 689 present. 691 The OPTION_CLIENT_DATA SHOULD include options requested in the 692 OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY message 693 and that are acceptable to return based on the list of "sensitive 694 options", discussed below. 696 DHCPv6 servers SHOULD be configurable with a list of "sensitive 697 options" that must not be returned to the requestor when specified in 698 the OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY 699 message. Any option on this list MUST NOT be returned to a 700 requestor, even if requested by that requestor. 702 4.4.3. Transmission of LEASEQUERY-REPLY Messages 704 The server sends the LEASEQUERY-REPLY message as described in the 705 "Transmission of Reply Messages" section of [2]. 707 5. Security Considerations 709 The senders of LEASEQUERY messages are expected to be within the same 710 security domain as the DHCPv6 server. As such, the security threat 711 to DHCPv6 leasequery is inherently an insider threat. However, this 712 document doesn't prohibit entities in external security domains from 713 sending LEASEQUERY messages to DHCPv6 servers. Regardless of the 714 network configuration, however, the potential attacks by insiders and 715 outsiders are the same. 717 If the requestor is an access concentrator, DHCPv6 leasequery 718 security SHOULD follow security between the relay agent and the 719 DHCPv6 server as described in [2] Sections 21.1 and 22.11. 720 Requestors are essentially a DHCPv6 client for the purposes of the 721 LEASEQUERY message. Thus, DHCPv6 authentication [2] is also an 722 appropriate mechanism for securing LEASEQUERY and LEASEQUERY-REPLY 723 messages. 725 Access concentrators are expected to be common leasequery requestors. 726 Access concentrators that use DHCPv6 gleaning (i.e., [7]), refreshed 727 with LEASEQUERY messages, will maintain accurate client/binding 728 information. This ensures that the access concentrator can forward 729 data traffic to the intended destination in the broadband access 730 network, can perform IPv6 source address verification of datagrams 731 from the access network, and can encrypt traffic that can only be 732 decrypted by the intended access modem (e.g., [BPI] and [BPI+]). 733 Thus, the LEASEQUERY message allows an access concentrator to provide 734 considerably enhanced security. DHCPv6 servers SHOULD prevent 735 exposure of their information (particularly the mapping of hardware 736 address to IPv6 address, which can be an invasion of broadband 737 subscriber privacy) by employing the techniques detailed in [2], 738 Section 21, "Authentication of DHCP Messages". 740 DHCPv6 servers SHOULD also provide for the ability to restrict the 741 information that they make via leasequery, as described in 742 Section 4.4.2. 744 DHCPv6 servers supporting LEASEQUERY SHOULD ensure that they cannot 745 be successfully attacked by being flooded with large quantities of 746 LEASEQUERY messages in a short time. In some environments, it may be 747 appropriate to configure a DHCPv6 server with the IPv6 source 748 addresses of the relay agents for which it may respond to LEASEQUERY 749 messages, thereby allowing it to respond only to requests from only a 750 handful of relay agents. This does not provide any true security, 751 but may be useful to thwart unsophisticated attacks of various sorts. 753 Replayed messages can represent a DOS attack through exhaustion of 754 processing resources, bogus leasequery requestors can send a lot of 755 LEASEQUERY messages to overwhelm a DHCPv6 server, thus preventing the 756 server from serving legitimate and regular DHCPv6 clients as well as 757 legitimate DHCPv6 leasequery requestors, denying configurations to 758 legitimate DHCPv6 clients as well lease information to legitimate 759 DHCPv6 leasequery requestors. 761 One attack specific to an access concentrator as a requestor is the 762 establishment of a malicious server with the intent of providing 763 incorrect lease or route information to the access concentrator, 764 thwarting source IPv6 address verification and preventing correct 765 routing. 767 The use of the OPTION_SERVER_RSN option [5] does provide an attacker 768 that also knows the server's DUID the ability to effectively lock out 769 future updates from the real server by supply a large sequence 770 number. 772 6. IANA Considerations 774 IANA is requested to assign the following new DHCPv6 Message types in 775 the registry maintained in 776 http://www.iana.org/assignments/dhcpv6-parameters: 778 LEASEQUERY 779 LEASEQUERY-REPLY 781 IANA is requested to assign the following new DHCPv6 Option Codes in 782 the registry maintained in 783 http://www.iana.org/assignments/dhcpv6-parameters: 785 OPTION_LQ_QUERY 786 OPTION_CLIENT_DATA 787 OPTION_CLT_TIME 788 OPTION_LQ_RELAY_DATA 789 OPTION_LQ_CLIENT_LINK 791 IANA is requested to assign the following new DHCPv6 Status Codes in 792 the registry maintained in 793 http://www.iana.org/assignments/dhcpv6-parameters: 795 UnknownQueryType 796 MalformedQuery 797 NotConfigured 798 NotAllowed 800 IANA is requested to create a new registry for the OPTION_LQ_QUERY 801 option query-type codes in the registry maintained in 802 http://www.iana.org/assignments/dhcpv6-parameters with the following 803 initial assignments: 805 QUERY_BY_ADDRESS 1 806 QUERY_BY_CLIENTID 2 808 7. Acknowledgements 810 Thanks to Ralph Droms, Richard Johnson, Josh Littlefield, Hemant 811 Singh, Pak Siripunkaw, Markus Stenberg, and Ole Troan for their 812 input, ideas, and review during the production of this document. 814 8. Modification History 816 If this section is present in the document when it is submitted for 817 publication, the RFC Editor is requested to remove it. 819 Changes in rev -01: 820 o Added the ability to query by client identifier (DUID), 821 QUERY_BY_CLIENTID. To avoid potentially large messages for 822 clients that are multihomed or mobile, a new option, 823 OPTION_LQ_CLIENT_LINK, to return the list of the links the client 824 is on was added. The requestor then needs to re-query for each 825 link, specifying the link-address in the query to get the client's 826 data. 827 o Added the ability to return full relay agent details via the 828 OPTION_LQ_RELAY_DATA option. 829 o And, other minor changes to accommodate the above. 831 9. References 833 9.1. Normative References 835 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 836 Levels", BCP 14, RFC 2119, March 1997. 838 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 839 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 840 RFC 3315, July 2003. 842 [3] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol 843 (DHCP) Leasequery", RFC 4388, February 2006. 845 [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 846 Configuration Protocol (DHCP) version 6", RFC 3633, 847 December 2003. 849 [5] Volz, B. and R. Droms, "DHCPv6 Server Reply Sequence Number 850 Option (draft-volz-dhc-dhcpv6-srsn-option-*)", August 2006. 852 9.2. Informative References 854 [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 855 March 1997. 857 [7] Droms, R., Volz, B., and O. Troan, "DHCP Relay Agent Assignment 858 Notification Option 859 (draft-ietf-dhc-dhcpv6-agentopt-delegate-*)", August 2006. 861 Authors' Addresses 863 John Jason Brzozowski 864 Comcast Cable 865 1800 Bishops Gate Boulevard 866 Mt. Laurel, NJ 08054 867 USA 869 Phone: +1 856 324 2671 870 Email: john_brzozowski@cable.comcast.com 872 Kim Kinnear 873 Cisco Systems, Inc. 874 1414 Massachusetts Ave. 875 Boxborough, MA 01719 876 USA 878 Phone: +1 978 936 0000 879 Email: kkinnear@cisco.com 881 Bernard Volz 882 Cisco Systems, Inc. 883 1414 Massachusetts Ave. 884 Boxborough, MA 01719 885 USA 887 Phone: +1 978 936 0000 888 Email: volz@cisco.com 890 Shengyou Zeng 891 Cisco Systems, Inc. 892 1414 Massachusetts Ave. 893 Boxborough, MA 01719 894 USA 896 Phone: +1 978 936 0000 897 Email: szeng@cisco.com 899 Full Copyright Statement 901 Copyright (C) The Internet Society (2006). 903 This document is subject to the rights, licenses and restrictions 904 contained in BCP 78, and except as set forth therein, the authors 905 retain all their rights. 907 This document and the information contained herein are provided on an 908 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 909 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 910 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 911 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 912 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 913 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 915 Intellectual Property 917 The IETF takes no position regarding the validity or scope of any 918 Intellectual Property Rights or other rights that might be claimed to 919 pertain to the implementation or use of the technology described in 920 this document or the extent to which any license under such rights 921 might or might not be available; nor does it represent that it has 922 made any independent effort to identify any such rights. Information 923 on the procedures with respect to rights in RFC documents can be 924 found in BCP 78 and BCP 79. 926 Copies of IPR disclosures made to the IETF Secretariat and any 927 assurances of licenses to be made available, or the result of an 928 attempt made to obtain a general license or permission for the use of 929 such proprietary rights by implementers or users of this 930 specification can be obtained from the IETF on-line IPR repository at 931 http://www.ietf.org/ipr. 933 The IETF invites any interested party to bring to its attention any 934 copyrights, patents or patent applications, or other proprietary 935 rights that may cover technology that may be required to implement 936 this standard. Please address the information to the IETF at 937 ietf-ipr@ietf.org. 939 Acknowledgment 941 Funding for the RFC Editor function is provided by the IETF 942 Administrative Support Activity (IASA).