idnits 2.17.1 draft-ietf-dhc-dhcpv6-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, updated by RFC 4748 on line 995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1006. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1013. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1019. 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 IETF Trust Copyright Line does not match the current year == Line 281 has weird spacing: '...options the...' == Line 333 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 (June 15, 2007) is 6122 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) ** Obsolete normative reference: RFC 3315 (ref. '2') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (ref. '4') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '6') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '7') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '9') (Obsoleted by RFC 4301) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 10 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: December 17, 2007 B. Volz 6 S. Zeng 7 Cisco Systems, Inc. 8 June 15, 2007 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 December 17, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document specifies a leasequery exchange for the Dynamic Host 45 Configuration Protocol for IPv6 (DHCPv6) which can be used 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 . . . . . . . . . . . . . . . . . . . . . 5 57 3.2. Anticipatory Query . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Message and Option Definitions . . . . . . . . . . . . . . 6 61 4.1.1. Messages . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 11 64 4.1.4. Transmission and Retransmission Parameters . . . . . . 12 65 4.2. Message Validation . . . . . . . . . . . . . . . . . . . . 12 66 4.2.1. LEASEQUERY . . . . . . . . . . . . . . . . . . . . . . 12 67 4.2.2. LEASEQUERY-REPLY . . . . . . . . . . . . . . . . . . . 12 68 4.3. DHCPv6 Leasequery Requestor Behavior . . . . . . . . . . . 13 69 4.3.1. Creation of LEASEQUERY . . . . . . . . . . . . . . . . 13 70 4.3.2. Transmission of LEASEQUERY . . . . . . . . . . . . . . 13 71 4.3.3. Receipt of LEASEQUERY-REPLY . . . . . . . . . . . . . 14 72 4.3.4. Handling DHCPv6 Client Data from Multiple Sources . . 14 73 4.4. DHCPv6 Leasequery Server Behavior . . . . . . . . . . . . 15 74 4.4.1. Receipt of LEASEQUERY Messages . . . . . . . . . . . . 15 75 4.4.2. Constructing the Client's OPTION_CLIENT_DATA . . . . . 16 76 4.4.3. Transmission of LEASEQUERY-REPLY Messages . . . . . . 17 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 80 8. Modification History . . . . . . . . . . . . . . . . . . . . . 19 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 85 Intellectual Property and Copyright Statements . . . . . . . . . . 23 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 [5], 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 programmatically extract lease data from the DHCPv6 server is called 106 leasequery. 108 The leasequery capability described in this document parallels the 109 DHCPv4 leasequery capability documented in [3]. As such, it shares 110 the basic motivations, background, design goals and constraints as 111 described in [3]. Differences are due to the differences between 112 IPv4 and IPv6 and by extension, DHCPv4 and DHCPv6. For example, 113 Neighbor Discovery [7] is used in IPv6 instead of ARP [8] (section 114 4.1 of [3]) and DOCSIS 3.0 [11] defines IPv6 support for cable modem 115 environments. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [1]. 123 DHCPv6 terminology is defined in [2]. Terminology specific to DHCPv6 124 leasequery can be found below: 126 access concentrator 127 An access concentrator is a router or switch 128 at the broadband access provider's edge of a 129 public broadband access network. This document 130 assumes that the access concentrator includes 131 the DHCPv6 relay agent functionality. 133 client(s) The nodes that have one or more bindings 134 with a DHCPv6 server. This does not refer to 135 the node issuing the LEASEQUERY unless it 136 itself has one or more bindings with a DHCPv6 137 server. 139 gleaning Gleaning is the extraction of location 140 information from DHCPv6 messages, as the 141 messages are forwarded by the DHCP relay agent 142 function. 144 location information 145 Location information is information needed by 146 the access concentrator to forward traffic to 147 a broadband-accessible host. This information 148 includes knowledge of the host hardware 149 address, the port or virtual circuit that 150 leads to the host, and/or the hardware address 151 of the intervening subscriber modem. 153 requestor The node that sends LEASEQUERY messages to one 154 or more servers to retrieve information on the 155 bindings for a client. 157 3. Protocol Overview 159 The focus of this document is to extend the DHCPv6 protocol to allow 160 processes and devices that wish to access information from a DHCPv6 161 server to do so in a lightweight and convenient manner. It is 162 especially appropriate for processes and devices that already 163 interpret DHCPv6 messages. 165 The LEASEQUERY message is a query message only and does not affect 166 the state of the IPv6 address or prefix, or the binding information 167 associated with it. 169 One important motivating example is that the LEASEQUERY message 170 allows access concentrators to query DHCP servers to obtain location 171 information of broadband access network devices. This is described 172 in section 1 of [3] for IPv4. 174 3.1. On-Demand Query 176 The on-demand leasequery capability allows requesting just the 177 information necessary to satisfy an immediate need. If the requestor 178 is an access concentrator, then the immediate need will typically be 179 that it has received an IPv6 packet and it needs to refresh its 180 information concerning the DHCPv6 client to which that an IPv6 181 address is currently leased. In this case, the request will be by 182 Address. This fits clearly into the single request/response cycle 183 common to other DHCPv6 message exchanges. 185 However, this approach has limitations when used with prefix 186 delegation [4] as no traffic may arrive because the access 187 concentrator is unable to inject the appropriate routing information 188 into the routing infrastructure, such as after a reboot. This 189 approach does work if the access concentrator is configured to inject 190 routing information for a prefix which aggregates potentially 191 delegated prefixes. Or, if the access concentrator and requesting 192 router use a routing protocol; as then the requesting router can 193 trigger the access concentrator to request information from a DHCPv6 194 server and inject appropriate routing information into the routing 195 infrastructure. 197 3.2. Anticipatory Query 199 A second approach for requesting information from a DHCPv6 server 200 would be to use a leasequery-like capability to rebuild an internal 201 data store containing information available from a DHCPv6 server. 202 The rebuilding of the data store in this approach can take place as 203 soon as possible after the need to rebuild it is discovered (such as 204 on booting), and doesn't wait on the receipt of specific packets to 205 trigger a piecemeal database update (as is the case for on-demand 206 leasequery). This approach would also remove the limitation 207 discussed above for prefix delegation. 209 This anticipatory query is not specified in this document and is an 210 area of future work. 212 3.3. Query Types 214 Leasequery provides for the following queries: 216 Query by IPv6 address - This query allows a requestor to request 217 from a server the bindings for a client that either is bound to 218 the address or has been delegated the prefix that contains the 219 address. 221 Query by Client Identifier (DUID) - This query allows a requestor to 222 request from a server the bindings for a specific client on a 223 specific link or a list of the links on which the client has one 224 or more bindings. 226 4. Protocol Details 228 4.1. Message and Option Definitions 230 4.1.1. Messages 232 The LEASEQUERY and LEASEQUERY-REPLY messages use the Client/Server 233 message formats described in [2], section 6. Two new message codes 234 are defined: 236 LEASEQUERY (TBD) - A requestor sends a LEASEQUERY message to any 237 available server to obtain information on a client's or clients' 238 leases. The options in an OPTION_LQ_QUERY determine the query. 240 LEASEQUERY-REPLY (TBD) - A server sends a LEASEQUERY-REPLY message 241 containing client data in response to a LEASEQUERY message. 243 4.1.2. Options 245 4.1.2.1. Query Option 247 The Query option is used only in a LEASEQUERY message and identifies 248 the query being performed. The option includes the query type, link- 249 address (or 0::0), and option(s) to provide data needed for the 250 query. 252 The format of the Query option is shown below: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | OPTION_LQ_QUERY | option-len | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | query-type | | 260 +-+-+-+-+-+-+-+-+ | 261 | | 262 | link-address | 263 | | 264 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | . 266 +-+-+-+-+-+-+-+-+ . 267 . query-options . 268 . . 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 option-code OPTION_LQ_QUERY (TBD) 273 option-len 17 + length of query-options field. 275 link-address A global address that will be used by the 276 server to identify the link to which the 277 query applies, or 0::0 if unspecified. 279 query-type the query requested (see below). 281 query-options the options related to the query. 283 The query-type and required query-options are: 285 QUERY_BY_ADDRESS (1) - The query-options MUST contain an 286 OPTION_IAADDR option [2]. The link-address field, if not 0::0, 287 specifies an address for the link on which the client is located 288 if the address in the OPTION_IAADDR option is of insufficient 289 scope. Only the information for the client that has a lease for 290 the specified address or was delegated a prefix that contains the 291 specified address is returned (if available). 293 QUERY_BY_CLIENTID (2) - The query-options MUST contain an 294 OPTION_CLIENTID option [2]. The link-address field, if not 0::0, 295 specifies an address for the link on which the client is located. 296 If the link-address field is 0::0, the server SHOULD search all of 297 its links of the client. 299 The query-options MAY also include an OPTION_ORO option [2] to 300 indicate the options for each client that the requestor would like 301 the server to return. Note that this OPTION_ORO is distinct and 302 separate from an OPTION_ORO that may be in the requestor's LEASEQUERY 303 message. 305 If a server receives an OPTION_LQ_QUERY with a query-type it does not 306 support, the server SHOULD return an UnknownQueryType status-code. 307 If a server receives a supported query-type but the query-options is 308 missing a required option, the server SHOULD return a MalformedQuery 309 status-code. 311 4.1.2.2. Client Data Option 313 The Client Data option is used to encapsulate the data for a single 314 client on a single link in a LEASEQUERY-REPLY message. 316 The format of the Client Data option is shown below: 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | OPTION_CLIENT_DATA | option-len | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 . . 324 . client-options . 325 . . 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 option-code OPTION_CLIENT_DATA (TBD) 330 option-len length, in octets, of the encapsulated client- 331 options field. 333 client-options the options associated with this client. 335 The encapsulated client-options include the OPTION_CLIENTID, 336 OPTION_IAADDR, OPTION_IAPREFIX, and OPTION_CLT_TIME options and other 337 options specific to the client and requested by the requestor in the 338 OPTION_ORO in the OPTION_LQ_QUERY's query-options. The server MUST 339 return all of the client's statefully assigned addresses and 340 delegated prefixes, with a non-zero valid lifetime, on the link. 342 4.1.2.3. Client Last Transaction Time Option 344 The Client Last Transaction Time option is encapsulated in an 345 OPTION_CLIENT_DATA and identifies how long ago the server last 346 communicated with the client, in seconds. 348 The format of the Client Last Transaction Time option is shown below: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | OPTION_CLT_TIME | option-len | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | client-last-transaction-time | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 option-code OPTION_CLT_TIME (TBD) 360 option-len 4 362 client-last-transaction-time 363 the number of seconds since the server last 364 communicated with the client (on that link). 366 The client-last-transaction-time is a positive value and reflects the 367 number of seconds since the server last communicated with the client 368 (on that link). 370 4.1.2.4. Relay Data 372 The Relay Data option is used only in a LEASEQUERY-REPLY message and 373 provides the relay agent information used when the client last 374 communicated with the server. 376 The format of the Relay Data option is shown below: 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | OPTION_LQ_RELAY_DATA | option-len | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 | peer-address (IPv6 address) | 385 | | 386 | | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | | 389 | DHCP-relay-message | 390 . . 391 . . 392 . . 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 option-code OPTION_LQ_RELAY_DATA (TBD) 397 option-len 16 + length of DHCP-relay-message. 399 peer-address The address of the relay agent from which 400 the relayed message was received by the 401 server. 403 DHCP-relay-message 404 The last complete relayed message excluding 405 the client's message OPTION_RELAY_MSG 406 received by the server. 408 This option is used by the server to return full relay agent 409 information for a client. It MUST NOT be returned if the server does 410 not have such information, either because the client communicated 411 directly (without relay agent) with the server or if the server did 412 not retain such information. 414 If returned, the DHCP-relay-message MUST contain a valid (perhaps 415 multi-hop) RELAY-FORW message as most recently received by the server 416 for the client. However, the (inner most) OPTION_RELAY_MSG option 417 containing the client's message MUST have been removed. 419 This option SHOULD only be returned if requested by the OPTION_ORO of 420 the OPTION_LQ_QUERY. 422 4.1.2.5. Client Link Option 424 The Client Link option is used only in a LEASEQUERY-REPLY message and 425 identifies the links on which the client has one or more bindings. 426 It is used in reply to a query when no link-address was specified and 427 the client is found to be on more than one link. 429 The format of the Client Link option is shown below: 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | OPTION_LQ_CLIENT_LINK | option-len | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 | link-address (IPv6 address) | 438 | | 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | | 442 | link-address (IPv6 address) | 443 | | 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | ... | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 option-code OPTION_LQ_CLIENT_LINKS (TBD) 451 option-len Length of the list of links in octets; 452 must be a multiple of 16. 454 link-address A global address used by the server to 455 identify the link on which the client is 456 located. 458 A server may respond to a query by client-id, where the 0::0 link- 459 address was specified, with this option if the client is found to be 460 on multiple links. The requestor may then repeat the query once for 461 each link-address returned in the list, specifying the returned link- 462 address. If the client is on a single link, the server SHOULD return 463 the client's data in an OPTION_CLIENT_DATA option. 465 4.1.3. Status Codes 467 The following new status codes are defined: 469 UnknownQueryType (TBD) - The query-type is unknown to or not 470 supported by the server. 472 MalformedQuery (TBD) - The query is not valid, for example a 473 required query-option is missing from the OPTION_LQ_QUERY. 475 NotConfigured (TBD) - The server does not have the target address or 476 link in its configuration. 478 NotAllowed (TBD) - The server does not allow the requestor to issue 479 this LEASEQUERY. 481 4.1.4. Transmission and Retransmission Parameters 483 This section presents a table of values used to describe the message 484 transmission behavior for leasequery. 486 Parameter Default Description 487 ---------------------------------- 488 LQ_TIMEOUT 1 sec Initial LEASEQUERY timeout 489 LQ_MAX_RT 10 secs Max LEASEQUERY timeout value 490 LQ_MAX_RC 5 Max LEASEQUERY retry attempts 492 4.2. Message Validation 494 4.2.1. LEASEQUERY 496 Requestors and clients MUST discard any received LEASEQUERY messages. 498 Servers MUST discard any received LEASEQUERY messages that meet any 499 of the following conditions: 500 o the message does not include an OPTION_CLIENTID option. 501 o the message includes an OPTION_SERVERID option but the contents of 502 the OPTION_SERVERID option does not match the server's identifier. 503 o the message does not include an OPTION_LQ_QUERY option. 505 4.2.2. LEASEQUERY-REPLY 507 Requestors MUST discard any received LEASEQUERY-REPLY messages that 508 meet any of the following conditions: 509 o the message does not include an OPTION_SERVERID option. 510 o the message does not include an OPTION_CLIENTID option or the 511 contents of the OPTION_CLIENTID option do not match the DUID of 512 the requestor. 513 o the "transaction-id" field in the message does not match the value 514 used in the original message. 516 Servers and Relay Agents (on the server port, 547 [2]) MUST discard 517 any received LEASEQUERY-REPLY messages. 519 4.3. DHCPv6 Leasequery Requestor Behavior 521 This section describes how a requestor initiates lease data retrieval 522 from DHCPv6 servers. 524 4.3.1. Creation of LEASEQUERY 526 The requestor sets the "msg-type" field to LEASEQUERY. The requestor 527 generates a transaction ID and inserts this value in the 528 "transaction-id" field. 530 The requestor MUST include an OPTION_CLIENTID option to identify 531 itself to the server. 533 The requestor MUST include an OPTION_LQ_QUERY option and set the 534 query-type, link-address, and query-options as appropriate to the 535 query-type (Section 4.1.2.1). 537 The requestor SHOULD include an OPTION_SERVERID if it is not 538 unicasting the LEASEQUERY yet only wants a response from a specific 539 server. 541 4.3.2. Transmission of LEASEQUERY 543 The requestor MAY be configured to use a list of destination 544 addresses, which MAY include unicast addresses, the All_DHCP_Servers 545 multicast address, or other addresses selected by the network 546 administrator. If the requestor has not been explicitly configured, 547 it MAY use the All_DHCP_Servers multicast address as the default. 549 The requestor SHOULD send LEASEQUERY to one or more DHCPv6 servers 550 which are known to possess authoritative information concerning the 551 query target. 553 In the absence of information concerning which DHCPv6 servers might 554 possess authoritative information on the query target, the requestor 555 SHOULD send LEASEQUERY to all DHCPv6 servers that the requestor knows 556 about or is configured with. For example, the requestor MAY send 557 LEASEQUERY to the All_DHCP_Servers multicast address. 559 The requestor transmits LEASEQUERY messages according to section 14 560 of [2], using the following parameters: 562 IRT LQ_TIMEOUT 563 MRT LQ_MAX_RT 564 MRC LQ_MAX_RC 565 MRD 0 567 If the message exchange fails, the requestor takes an action based on 568 the requestor's local policy. Examples of actions the requestor 569 might take include: 571 o Select another server from a list of servers known to the 572 requestor. 573 o Send to multiple servers by multicasting to the All_DHCP_Servers 574 address. 575 o Terminate the request. 577 4.3.3. Receipt of LEASEQUERY-REPLY 579 A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE 580 option (or an OPTION_STATUS_CODE option with a success code). There 581 are three variants: 582 1. If the server had bindings for the requested client, the message 583 includes an OPTION_CLIENT_DATA option and the requestor extracts 584 the client data from the LEASEQUERY-REPLY and updates its binding 585 information database. If the OPTION_CLIENT_DATA contains no 586 OPTION_CLT_TIME, the requestor SHOULD silently discard the 587 OPTION_CLIENT_DATA option. 588 2. If the server found bindings for the client on multiple links, 589 the message includes an OPTION_CLIENT_LINK option. The requestor 590 will need to reissue LEASEQUERY messages using each of the 591 returned link-addresses to obtain the client's bindings. 592 3. If the server had no bindings for the client, neither the 593 OPTION_CLIENT_DATA nor OPTION_CLIENT_LINK option will be present. 595 An unsuccessful LEASEQUERY-REPLY is one that has an 596 OPTION_STATUS_CODE with an error code. Depending on the status code, 597 the requestor may try a different server (such as for NotAllowed, 598 NotConfigured, and UnknownQueryType), try a different or corrected 599 query (such as for UnknownQueryType and MalformedQuery), or terminate 600 the query. 602 4.3.4. Handling DHCPv6 Client Data from Multiple Sources 604 A requestor may receive lease data on the same client from the same 605 DHCPv6 server in response to different types of LEASEQUERY. If a 606 LEASEQUERY is sent to multiple servers, the requestor may receive 607 from several servers lease data on the same DHCPv6 client. This 608 section describes how the requestor handles multiple lease data 609 sources on the same DHCPv6 client from the same server or different 610 servers. 612 The client data from the different sources may be disjoint or 613 overlapping. The disjoint and overlapping relationship can happen 614 between data from the same server or different servers. 616 If client data from two sources on the same client are of different 617 types or values, then the data are disjoint. An example of data of 618 different types is when a requestor receives an IPv6 address lease 619 from one server and a prefix lease from another server, both assigned 620 to the same client. An example of different values (but the same 621 type) is when a requestor receives two IPv6 address leases from two 622 different servers, both assigned to the same client, but the leases 623 are on two different IPv6 addresses. If the requestor receives 624 disjoint client data from different sources, it SHOULD merge them. 626 If client data from two sources on the same client are of the same 627 type and value, then the data are overlapping. An example of 628 overlapping data is when a requestor receives a lease on the same 629 IPv6 address from two different servers. Overlapping client data are 630 also called conflicting data. 632 The requestor SHOULD use the OPTION_CLT_TIME to resolve data 633 conflicts originated from different servers, and SHOULD accept data 634 with most recent OPTION_CLT_TIME. 636 4.4. DHCPv6 Leasequery Server Behavior 638 A DHCPv6 server sends LEASEQUERY-REPLY messages in response to valid 639 LEASEQUERY messages it receives to return the statefully assigned 640 addresses, delegated prefixes, and other information about that match 641 the query. 643 4.4.1. Receipt of LEASEQUERY Messages 645 Upon receipt of a valid LEASEQUERY message, the DHCPv6 server locates 646 the requested client, collects data on the client, and constructs and 647 returns a LEASEQUERY-REPLY. A LEASEQUERY message can not be used to 648 assign, release, or otherwise modify bindings or other configuration 649 information. 651 The server constructs a LEASEQUERY-REPLY message by setting the "msg- 652 type" field to LEASEQUERY-REPLY, and copying the transaction ID from 653 the LEASEQUERY message into the transaction-id field. 655 If the query-type in the OPTION_LQ_QUERY option is not a known or 656 supported value, the server adds an OPTION_STATUS_CODE option with 657 the UnknownQueryType status code and sends the LEASEQUERY-REPLY to 658 the requestor. If the query-options do not contain the required 659 options for the query-type, the server adds an OPTION_STATUS_CODE 660 option with the MalformedQuery status code and sends the LEASEQUERY- 661 REPLY to the client. 663 A server may also restrict LEASEQUERY messages, or query-types, to 664 certain requestors. In this case, the server MAY discard the 665 LEASEQUERY message or MAY add an OPTION_STATUS_CODE option with the 666 NotAllowed status code and send the LEASEQUERY-REPLY to the 667 requestor. 669 If the OPTION_LQ_QUERY specified a non-zero link-address, the server 670 MUST use the link-address to find the appropriate link for the 671 client. For a QUERY_BY_ADDRESS, if the 0::0 link-address was 672 specified, the server uses the address from the OPTION_IAADDR option 673 to find the appropriate link for the client. In either of these 674 cases, if the server is unable to find the link, it SHOULD return an 675 OPTION_STATUS_CODE option with the NotConfigured status and send the 676 LEASEQUERY-REPLY to the requestor. 678 For a QUERY_BY_CLIENTID, if a 0::0 link-address was specified, the 679 server MUST search all of its links for the client. If the client is 680 only found on a single link, the server SHOULD return that client's 681 data in an OPTION_CLIENT_DATA option. If the client is found on more 682 than a single link, the server MUST return the list of links in the 683 OPTION_CLIENT_LINK option; the server MUST NOT return any client 684 data. 686 Otherwise, the server uses the data in the OPTION_LQ_QUERY to 687 initiate the query. The result of the query will be zero or one 688 client. This will result in zero or one OPTION_CLIENT_DATA option 689 being added to the LEASEQUERY-REPLY. 691 4.4.2. Constructing the Client's OPTION_CLIENT_DATA 693 An OPTION_CLIENT_DATA option in a LEASEQUERY-REPLY message MUST 694 minimally contain the following options: 695 1. OPTION_CLIENTID 696 2. OPTION_IAADDR and/or OPTION_IAPREFIX 697 3. OPTION_CLT_TIME 699 Depending on the bindings the client has on a link, either 700 OPTION_IAADDR options, OPTION_IAPREFIX options, or both may be 701 present. 703 The OPTION_CLIENT_DATA SHOULD include options requested in the 704 OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY message 705 and that are acceptable to return based on the list of "sensitive 706 options", discussed below. 708 DHCPv6 servers SHOULD be configurable with a list of "sensitive 709 options" that must not be returned to the requestor when specified in 710 the OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY 711 message. Any option on this list MUST NOT be returned to a 712 requestor, even if requested by that requestor. 714 4.4.3. Transmission of LEASEQUERY-REPLY Messages 716 The server sends the LEASEQUERY-REPLY message as described in the 717 "Transmission of Reply Messages" section of [2]. 719 5. Security Considerations 721 Access concentrators are expected to be common leasequery requestors. 722 Access concentrators that use DHCPv6 gleaning (i.e., [10]), refreshed 723 with LEASEQUERY messages, will maintain accurate client/binding 724 information. This ensures that the access concentrator can forward 725 data traffic to the intended destination in the broadband access 726 network, can perform IPv6 source address verification of datagrams 727 from the access network, and can encrypt traffic that can only be 728 decrypted by the intended access modem (e.g., [12] and [13]). Thus, 729 the leasequery capability allows an access concentrator to provide 730 considerably enhanced security. 732 The "Security Considerations" section of [2] details the general 733 threats to DHCPv6, and thus to LEASEQUERY messages. The 734 "Authentication of DHCP Messages" section of [2] describes securing 735 communication between relay agents and servers, as well as clients 736 and servers. If the requestor is an access concentrator, the IPsec 737 [9] based security as described in [2] section 21.1 SHOULD be used. 738 Other types of requestors are essentially DHCPv6 clients. Thus, 739 DHCPv6 authentication, section 21 of [2], is an appropriate mechanism 740 for securing LEASEQUERY and LEASEQUERY-REPLY messages. As the number 741 of leasequery requestors and servers in an administrative domain is 742 relatively small, any shared key distribution issues are minimized. 744 After implementing the above approaches, the DHCPv6 server should 745 only be communicating with trusted LEASEQUERY requestors, and so 746 security needs should be met. 748 However, not all traffic originates directly from these trusted 749 requestors. For example, trusted relay agents can relay LEASEQUERY 750 messages from untrusted requestors or elsewhere in the network. This 751 SHOULD be prevented at least at the perimeter relay agents (or on all 752 relay agents unless relayed LEASEQUERY messages are required for some 753 requestors). DHCPv6 servers MAY be configured to discard relayed 754 LEASEQUERY messages or restrict relay chaining. 756 DHCPv6 servers SHOULD also provide for the ability to restrict the 757 information returned for a client in a LEASEQUERY-REPLY even to a 758 trusted LEASEQUERY requestor, as described in Section 4.4.2. 760 Since even trusted access concentrators may generate LEASEQUERY 761 requests as a result of activity external to the access concentrator, 762 access concentrators SHOULD minimize potential denial of service 763 attacks on the DHCPv6 servers by minimizing the generation of 764 LEASEQUERY messages. In particular, the access concentrator SHOULD 765 employ negative caching (i.e., cache the fact that a particular 766 recent query failed to return client data) and address restrictions 767 where possible (i.e., don't send a LEASEQUERY message for addresses 768 outside of the range of the attached broadband access networks). 769 Together, these mechanisms limit the access concentrator to 770 transmitting one LEASEQUERY message (excluding message retries) per 771 legitimate broadband access network address after a reboot event. 773 Packet flooding denial of service attacks can result in the 774 exhaustion of processing resources, thus preventing the server from 775 serving legitimate and regular DHCPv6 clients as well as legitimate 776 DHCPv6 LEASEQUERY requestors, denying configurations to legitimate 777 DHCPv6 clients as well lease information to legitimate DHCPv6 778 LEASEQUERY requestors. While these attacks are unlikely when only 779 communicating with trusted LEASEQUERY requestors, the possibility 780 always exists that the trust is misplaced, security techniques are 781 compromised, or even trusted requestors can have bugs in them. 782 Therefore techniques for defending against packet flooding denial of 783 service are always a good idea, and they include good perimeter 784 security as mentioned earlier and rate limiting DHCPv6 traffic by 785 relay agents, other network elements, or the server itself. 787 One way to attack an access concentrator (as opposed to a DHCPv6 788 server) as a LEASEQUERY requestor is the establishment of a malicious 789 server with the intent of providing incorrect lease or route 790 information to the access concentrator, thwarting source IPv6 address 791 verification and preventing correct routing. This type of attack can 792 be minimized by using IPsec as described in section 21.1 of [2]. 794 6. IANA Considerations 796 IANA is requested to assign the following new DHCPv6 Message types in 797 the registry maintained in 798 http://www.iana.org/assignments/dhcpv6-parameters: 800 LEASEQUERY 801 LEASEQUERY-REPLY 803 IANA is requested to assign the following new DHCPv6 Option Codes in 804 the registry maintained in 805 http://www.iana.org/assignments/dhcpv6-parameters: 807 OPTION_LQ_QUERY 808 OPTION_CLIENT_DATA 809 OPTION_CLT_TIME 810 OPTION_LQ_RELAY_DATA 811 OPTION_LQ_CLIENT_LINK 813 IANA is requested to assign the following new DHCPv6 Status Codes in 814 the registry maintained in 815 http://www.iana.org/assignments/dhcpv6-parameters: 817 UnknownQueryType 818 MalformedQuery 819 NotConfigured 820 NotAllowed 822 IANA is requested to create a new registry for the OPTION_LQ_QUERY 823 option query-type codes in the registry maintained in 824 http://www.iana.org/assignments/dhcpv6-parameters with the following 825 initial assignments: 827 QUERY_BY_ADDRESS 1 828 QUERY_BY_CLIENTID 2 830 New OPTION_LQ_QUERY option query-type codes are assigned through 831 Standards Action, as defined in [6]. 833 7. Acknowledgements 835 Thanks to Ralph Droms, Richard Johnson, Josh Littlefield, Hemant 836 Singh, Pak Siripunkaw, Markus Stenberg, and Ole Troan for their 837 input, ideas, and review during the production of this document. 839 8. Modification History 841 If this section is present in the document when it is submitted for 842 publication, the RFC Editor is requested to remove it. 844 This document was previously accidentally published under an 845 incorrect name, draft-ietf-dhc-dhcvp6-leasequery-00 and 846 draft-ietf-dhc-dhcvp6-leasequery-01. The changes between the -00 and 847 -01 version were: 848 o Added the ability to query by client identifier (DUID), 849 QUERY_BY_CLIENTID. To avoid potentially large messages for 850 clients that are multihomed or mobile, a new option, 851 OPTION_LQ_CLIENT_LINK, to return the list of the links the client 852 is on was added. The requestor then needs to re-query for each 853 link, specifying the link-address in the query to get the client's 854 data. 855 o Added the ability to return full relay agent details via the 856 OPTION_LQ_RELAY_DATA option. 857 o And, other minor changes to accommodate the above. 859 The changes between draft-ietf-dhc-dhcvp6-leasequery-01 and 860 draft-ietf-dhcpv6-leasequery-00 (the corrected document name) were: 861 o Fixed draft name (had dhcvp6 instead of dhcpv6). 862 o Removed reference to SRSN I-D and associated text. SRSN is only 863 needed if and when RAAN moves forward (in or close to its current 864 form). 865 o Added [12] and [13] references that were missing (referenced in 866 Security Considerations section). 867 o Updated RAAN I-D reference to current version. 868 o Updated boilerplate and copyright year. 870 The changes between draft-ietf-dhc-dhcpv6-leaesquery-00 and this 871 version were as a result of the IETF last-call and IESG review: 872 o Several spelling, typographical, and grammatical corrections were 873 made. 874 o The Terminology section was expanded to define more of the terms 875 used, using the definitions from RFC 4388 [3]. 876 o The Introduction and Protocol Overview sections were revised to 877 explicitly reference material in RFC 4388 [3] and also indicate 878 some of the key differences. 879 o The Security Considerations section was reworked. 880 o The IANA Considerations section now specifies how new query-type 881 codes are assigned - through Standards Action. 882 o Additional references were added as a result of the above changes. 884 Thanks to those that pointed out the above issues during the last- 885 call process, including Jari Arkko, Lars Eggert, Sam Hartman, Alfred 886 Hoenes, Tim Polk, and the folks at IANA. 888 9. References 889 9.1. Normative References 891 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 892 Levels", BCP 14, RFC 2119, March 1997. 894 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 895 Carney, "Dynamic Host Configuration Protocol for IPv6 896 (DHCPv6)", RFC 3315, July 2003. 898 [3] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol 899 (DHCP) Leasequery", RFC 4388, February 2006. 901 [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 902 Configuration Protocol (DHCP) version 6", RFC 3633, 903 December 2003. 905 9.2. Informative References 907 [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 908 March 1997. 910 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 911 Considerations Section in RFCs", BCP 26, RFC 2434, 912 October 1998. 914 [7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 915 for IP Version 6 (IPv6)", RFC 2461, December 1998. 917 [8] Plummer, D., "Ethernet Address Resolution Protocol: Or 918 converting network protocol addresses to 48.bit Ethernet 919 address for transmission on Ethernet hardware", STD 37, 920 RFC 826, November 1982. 922 [9] Kent, S. and R. Atkinson, "Security Architecture for the 923 Internet Protocol", RFC 2401, November 1998. 925 [10] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN) 926 Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-02 (work in 927 progress), November 2006. 929 [11] CableLabs, "Data-Over-Cable Service Interface Specifications: 930 DOCSIS 3.0, MAC and Upper Layer Protocols Interface 931 Specification, CM-SP-MULPIv3.0-I04-070518", May 2007, available 932 at http://www.cablemodem.com/. 934 [12] SCTE Data Standards Subcommittee, "Data-Over-Cable Service 935 Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface 936 Specification SCTE 22-2 2002", 2002, available at 937 http://www.scte.org/standards/. 939 [13] CableLabs, "Data-Over-Cable Service Interface Specifications: 940 Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12- 941 050812", August 2005, available at http://www.cablemodem.com/. 943 Authors' Addresses 945 John Jason Brzozowski 946 Comcast Cable 947 1800 Bishops Gate Boulevard 948 Mt. Laurel, NJ 08054 949 USA 951 Phone: +1 856 324 2671 952 Email: john_brzozowski@cable.comcast.com 954 Kim Kinnear 955 Cisco Systems, Inc. 956 1414 Massachusetts Ave. 957 Boxborough, MA 01719 958 USA 960 Phone: +1 978 936 0000 961 Email: kkinnear@cisco.com 963 Bernard Volz 964 Cisco Systems, Inc. 965 1414 Massachusetts Ave. 966 Boxborough, MA 01719 967 USA 969 Phone: +1 978 936 0000 970 Email: volz@cisco.com 972 Shengyou Zeng 973 Cisco Systems, Inc. 974 1414 Massachusetts Ave. 975 Boxborough, MA 01719 976 USA 978 Phone: +1 978 936 0000 979 Email: szeng@cisco.com 981 Full Copyright Statement 983 Copyright (C) The IETF Trust (2007). 985 This document is subject to the rights, licenses and restrictions 986 contained in BCP 78, and except as set forth therein, the authors 987 retain all their rights. 989 This document and the information contained herein are provided on an 990 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 991 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 992 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 993 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 994 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 995 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 997 Intellectual Property 999 The IETF takes no position regarding the validity or scope of any 1000 Intellectual Property Rights or other rights that might be claimed to 1001 pertain to the implementation or use of the technology described in 1002 this document or the extent to which any license under such rights 1003 might or might not be available; nor does it represent that it has 1004 made any independent effort to identify any such rights. Information 1005 on the procedures with respect to rights in RFC documents can be 1006 found in BCP 78 and BCP 79. 1008 Copies of IPR disclosures made to the IETF Secretariat and any 1009 assurances of licenses to be made available, or the result of an 1010 attempt made to obtain a general license or permission for the use of 1011 such proprietary rights by implementers or users of this 1012 specification can be obtained from the IETF on-line IPR repository at 1013 http://www.ietf.org/ipr. 1015 The IETF invites any interested party to bring to its attention any 1016 copyrights, patents or patent applications, or other proprietary 1017 rights that may cover technology that may be required to implement 1018 this standard. Please address the information to the IETF at 1019 ietf-ipr@ietf.org. 1021 Acknowledgment 1023 Funding for the RFC Editor function is provided by the IETF 1024 Administrative Support Activity (IASA).