idnits 2.17.1 draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 260 has weird spacing: '...ge-size the...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (January 13, 2009) is 5583 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 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC M. Stapp 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track January 13, 2009 5 Expires: July 17, 2009 7 DHCPv6 Bulk Leasequery 8 draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 17, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been 48 extended with a Leasequery capability that allows a client to request 49 information about DHCPv6 bindings. That mechanism is limited to 50 queries for individual bindings. In some situations individual 51 binding queries may not be efficient, or even possible. This 52 document expands on the Leasequery protocol, adding new query types 53 and allowing for bulk transfer of DHCPv6 binding data via TCP. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Interaction Between UDP Leasequery and Bulk Leasequery . . . . 5 61 5. Message and Option Definitions . . . . . . . . . . . . . . . . 6 62 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 6 63 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2.1. LEASEQUERY-DATA . . . . . . . . . . . . . . . . . . . 7 65 5.2.2. LEASEQUERY-DONE . . . . . . . . . . . . . . . . . . . 7 66 5.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.3.1. QUERY_BY_RELAY_ID . . . . . . . . . . . . . . . . . . 7 68 5.3.2. QUERY_BY_LINK_ADDRESS . . . . . . . . . . . . . . . . 8 69 5.3.3. QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . 8 70 5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.4.1. Relay-ID Option . . . . . . . . . . . . . . . . . . . 8 72 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.6. Connection and Transmission Parameters . . . . . . . . . . 9 74 6. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1. Connecting . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.2. Forming Queries . . . . . . . . . . . . . . . . . . . . . 10 77 6.3. Processing Replies . . . . . . . . . . . . . . . . . . . . 10 78 6.3.1. Reply Completion . . . . . . . . . . . . . . . . . . . 11 79 6.4. Querying Multiple Servers . . . . . . . . . . . . . . . . 12 80 6.5. Multiple Queries to a Single Server . . . . . . . . . . . 12 81 6.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 13 83 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 84 7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 13 85 7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 14 86 7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 15 87 7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 15 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 The DHCPv6 [RFC3315] protocol specifies a mechanism for the 99 assignment of IPv6 address and configuration information to IPv6 100 nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a 101 mechanism for DHCPv6 delegation of IPv6 prefixes and related data. 102 DHCPv6 servers maintain authoritative information including binding 103 information for delegated IPv6 prefixes. 105 The client of a PD binding is typically a router, which then 106 advertises the delegated prefix to locally-connected hosts. The 107 delegated IPv6 prefix must be routeable in order to be useful. The 108 actual DHCPv6 PD client may not be permitted to inject routes into 109 the delegating network. In service-provider (SP) networks, for 110 example, an edge router typically acts as a DHCPv6 relay agent, and 111 this edge router often has the responsibility to maintain routes 112 within the service-provider network for clients' PD bindings. 114 A DHCPv6 relay with this responsibility requires a means to recover 115 binding information from the authoritative DHCPv6 server(s) in the 116 event of replacement or reboot, in order to restore routeability to 117 delegated prefixes. The relay may be a network device without 118 adequate local storage to maintain the necessary binding-to-route 119 data. A DHCPv6 Leasequery protocol [RFC5007] has been developed that 120 allows queries for individual bindings from the authoritative DHCPv6 121 Server(s). The individual query mechanism is only useable when the 122 target binding is known to the requestor, such as upon receipt of 123 traffic. In the case of DHCPv6 Prefix Delegation, the PD binding 124 data may need to be known before any traffic arrives from the client 125 router. The DHCPv6 relay router may not be able to form individual 126 queries in such cases. 128 This document extends the DHCPv6 Leasequery protocol to add support 129 for queries that address these requirements. At the SP edge there 130 may be many thousands of delegated prefixes per relay, so we specify 131 the use of TCP [RFC4614] for efficiency of data transfer. We specify 132 a new DHCPv6 option, the Relay Identifier option, to support 133 efficient recovery of all data associated with a specific relay 134 agent; we also add a query-type for this purpose. We add query-types 135 by network segment and by Remote-ID option value, to assist a relay 136 that needs to recover a subset of its clients' bindings. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 DHCPv6 terminology is defined in [RFC3315]. DHCPv6 Leasequery 145 terminology is defined in [RFC5007]. 147 3. Protocol Overview 149 The Bulk Leasequery mechanism is modeled on the existing individual 150 Leasequery protocol in [RFC5007]; most differences arise from the use 151 of TCP. A Bulk Leasequery client opens a TCP connection to a DHCPv6 152 Server, using the DHCPv6 port 547. Note that this implies that the 153 Leasequery client has server IP address(es) available via 154 configuration or some other means, and that it has unicast IP 155 reachability to the server. No relaying for bulk leasequery is 156 specified. 158 After establishing a connection, the client sends a LEASEQUERY 159 message containing a query-type and data about bindings it is 160 interested in. The server uses the query-type and the data to 161 identify any relevant bindings. In order to support some query- 162 types, servers may have to maintain additional data structures or be 163 able to locate bindings based on specific option data. The server 164 replies with a LEASEQUERY-REPLY message, indicating the success or 165 failure of the query. If the query was successful, the server 166 includes the first client's binding data in the LEASEQUERY-REPLY 167 message also. If more than one client's bindings are being returned, 168 the server then transmits the additional client bindings in a series 169 of LEASEQUERY-DATA messages. If the server has sent at least one 170 client's bindings, it sends a LEASEQUERY-DONE message when it has 171 finished sending its replies. The client may reuse the connection to 172 send additional queries. Each end of the TCP connection can be 173 closed after all data has been sent. 175 This specification includes a new DHCPv6 option, the Relay-ID option. 176 The option contains a DUID (DHCP Unique Identifier) identifying a 177 DHCPv6 relay agent. Relay agents can include this option in Relay- 178 Forward messages they send. Servers can retain the Relay-ID and 179 associate it with bindings made on behalf of the relay's clients. A 180 relay can then recover binding information about downstream clients 181 by using the Relay-ID in a LEASEQUERY message. The Relay-ID option 182 is defined in Section 5.4.1. 184 Bulk Leasequery supports the queries by IPv6 address and by Client 185 DUID as specified in [RFC5007]. The Bulk Leasequery protocol also 186 adds several new queries. The new queries introduced here cannot be 187 used effectively with the UDP Leasequery protocol. Requestors MUST 188 NOT send these new query-types in [RFC5007] query messages. 190 Query by Relay Identifier - This query asks a server for the 191 bindings associated with a specific relay; the relay is identified 192 by a DUID carried in a Relay-ID option. 194 Query by Link Address - This query asks a server for the bindings on 195 a particular network segment; the link is specified in the query's 196 link-address field. 198 Query by Remote ID - This query asks a server for the bindings 199 associated with a Relay Agent Remote-ID option [RFC4649] value. 201 4. Interaction Between UDP Leasequery and Bulk Leasequery 203 Bulk Leasequery can be seen as an extension of the existing UDP 204 Leasequery protocol [RFC5007]. This section tries to clarify the 205 relationship between the two protocols. 207 The query-types introduced in the UDP Leasequery protocol can be used 208 in the Bulk Leasequery protocol. One change in behavior is 209 introduced when Bulk Leasequery is used. [RFC5007], in sections 210 4.1.2.5 and 4.3.3, specifies the use of a Client Link option in 211 LEASEQUERY-REPLY messages in cases where multiple bindings were 212 found. When Bulk Leasequery is used, this mechanism is not 213 necessary: a server returning multiple bindings simply does so 214 directly as specified in this document. The Client Link option MUST 215 NOT appear in Bulk Leasequery replies. 217 Only LEASEQUERY, LEASEQUERY-REPLY, LEASEQUERY-DATA, and LEASEQUERY- 218 DONE messages are allowed over the Bulk Leasequery connection. No 219 other DHCPv6 messages are supported. The Bulk Leasequery connection 220 is not an alternative DHCPv6 communication option for clients seeking 221 DHCPv6 service. 223 The new queries introduced in this specification cannot be used with 224 the UDP Leasequery protocol. Servers that implement this 225 specification and also permit UDP queries MUST NOT accept Bulk 226 Leasequery query-types in UDP Leasequery messages. Such servers MUST 227 respond with an error status code of NotAllowed [RFC5007]. 229 Implementors should note that the TCP message framing defined in 230 Section 5.1 is not compatible with the UDP message format. If a TCP- 231 framed request is sent as a UDP message, it may not be valid, because 232 protocol fields will be offset by the message-size prefix. 234 5. Message and Option Definitions 236 5.1. Message Framing for TCP 238 The use of TCP for the Bulk Leasequery protocol permits one or more 239 DHCPv6 messages to be sent at a time. The receiver needs to be able 240 to determine how large each message is. Two octets containing the 241 message size in network byte order are prepended to each DHCPv6 242 message sent on a Bulk Leasequery TCP connection. The two message- 243 size octets 'frame' each DHCPv6 message. 245 DHCPv6 message framed for TCP: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | message-size | msg-type | : 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 : transaction-id | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | . 255 . options . 256 . (variable) . 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 message-size the number of octets in the message that 261 follows, as a 16-bit integer in network 262 byte order. 264 All other fields are as specified in DHCPv6 [RFC3315]. 266 5.2. Messages 268 The LEASEQUERY and LEASEQUERY-REPLY messages are defined in 269 [RFC5007]. In a Bulk Leasequery exchange, a single LEASEQUERY-REPLY 270 message is used to indicate the success or failure of a query, and to 271 carry data that do not change in the context of a single query and 272 answer, such as the Server-ID and Client-ID options. If a query is 273 successful, only a single LEASEQUERY-REPLY message MUST appear. If 274 the server is returning binding data, the LEASEQUERY-REPLY also 275 contains the first client's binding data in an OPTION_CLIENT_DATA 276 option. 278 5.2.1. LEASEQUERY-DATA 280 The LEASEQUERY-DATA message carries data about a single DHCPv6 281 client's leases and/or PD bindings on a single link. The purpose of 282 the message is to reduce redundant data when there are multiple 283 bindings to be sent. The LEASEQUERY-DATA message MUST be preceded by 284 a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY conveys the query's 285 status, carries the Leasequery's Client-ID and Server-ID options, and 286 carries the first client's binding data if the query was successful. 288 LEASEQUERY-DATA MUST ONLY be sent in response to a successful 289 LEASEQUERY, and only if more than one client's data is to be sent. 290 The LEASEQUERY-DATA message's transaction-id field MUST match the 291 transaction-id of the LEASEQUERY request message. The Server-ID, 292 Client-ID, and OPTION_STATUS_CODE options SHOULD NOT be included: 293 that data should be constant for any one Bulk Leasequery reply, and 294 should have been conveyed in the LEASEQUERY-REPLY message. 296 5.2.2. LEASEQUERY-DONE 298 The LEASEQUERY-DONE message indicates the end of a group of related 299 Leasequery replies. The LEASEQUERY-DONE message's transaction-id 300 field MUST match the transaction-id of the LEASEQUERY request 301 message. The presence of the message itself signals the end of a 302 stream of reply messages. A single LEASEQUERY-DONE MUST BE sent 303 after all replies (a successful LEASEQUERY-REPLY and zero or more 304 LEASEQUERY-DATA messages) to a successful Bulk Leasequery request 305 that returned at least one binding. 307 A server may encounter an error condition after it has sent the 308 initial LEASEQUERY-REPLY. In that case, it SHOULD attempt to send a 309 LEASEQUERY-DONE with an OPTION_STATUS_CODE option indicating the 310 error condition to the requestor. Other DHCPv6 options SHOULD NOT be 311 included in the LEASEQUERY-DONE message. 313 5.3. Query Types 315 The OPTION_LQ_QUERY option is defined in [RFC5007]. We introduce the 316 following new query-types: QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, 317 QUERY_BY_REMOTE_ID. These queries are designed to assist relay 318 agents in recovering binding data in circumstances where some or all 319 of the relay's binding data has been lost. 321 5.3.1. QUERY_BY_RELAY_ID 323 This query asks the server to return bindings associated with the 324 specified relay DUID. 326 QUERY_BY_RELAY_ID - The query-options MUST contain an 327 OPTION_RELAY_ID option. If the link-address field is 0::0, the 328 query asks for all bindings associated with the specified relay 329 DUID. If the link-address is specified, the query asks for 330 bindings on that link. 332 5.3.2. QUERY_BY_LINK_ADDRESS 334 The QUERY_BY_LINK_ADDRESS asks the server to return bindings on a 335 network segment identified by an link-address value from a relay's 336 Relay-Forward message. 338 QUERY_BY_LINK_ADDRESS - The query's link-address contains an 339 address a relay may have used in the link-address of a Relay- 340 Forward message. The Server attempts to locate bindings on the 341 same network segment as the link-address. 343 5.3.3. QUERY_BY_REMOTE_ID 345 The QUERY_BY_REMOTE_ID asks the server to return bindings associated 346 with a Remote-ID option value from a relay's Relay-Forward message. 347 The query-options MUST include a Relay Agent Remote-ID option 348 [RFC4649]. 350 In order to support this query, a server needs to record the most- 351 recent Remote-ID option value seen in a Relay-Forward message along 352 with its other binding data. 354 QUERY_BY_REMOTE_ID - The query-options MUST include a Relay Agent 355 Remote-ID option [RFC4649]. If the Server has recorded Remote-ID 356 values with its bindings, it uses the option's value to identify 357 bindings to return. 359 5.4. Options 361 5.4.1. Relay-ID Option 363 The Relay-ID option carries a DUID [RFC3315]. A relay agent MAY 364 include the option in Relay-Forward messages it sends. Obviously, it 365 will not be possible for a server to respond to QUERY_BY_RELAY_ID 366 queries unless the relay agent has included this option. A relay 367 SHOULD be able to generate a DUID for this purpose, and capture the 368 result in stable storage. A relay SHOULD also allow the DUID value 369 to be configurable: doing so allows an administrator to replace a 370 relay agent while retaining the association between the relay and 371 existing DHCPv6 bindings. 373 A DHCPv6 Server MAY associate Relay-ID options from Relay-Forward 374 messages it processes with prefix delegations and/or lease bindings 375 that result. Doing so allows it to respond to QUERY_BY_RELAY_ID 376 Leasequeries. 378 The format of the Relay-ID option is shown below: 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | OPTION_RELAY_ID | option-len | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 . . 386 . DUID . 387 . (variable length) . 388 . . 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 option-code OPTION_RELAY_ID. 393 option-len Length of DUID in octets. 395 DUID The DUID for the relay agent. 397 5.5. Status Codes 399 QueryTerminated - Indicates that the server is unable to perform a 400 query or has prematurely terminated the query for some reason (which 401 should be communicated in the text message). This may be because the 402 server is short of resources or is being shut down. The requestor 403 may retry the query at a later time. The requestor should wait at 404 least a short interval before retrying. Note that while a server may 405 simply prematurely close its end of the connection, it is preferable 406 for the server to send a LEASEQUERY-REPLY or LEASEQUERY-DONE with 407 this status-code to notify the requestor of the condition. 409 5.6. Connection and Transmission Parameters 411 DHCPv6 Servers that support Bulk Leasequery SHOULD listen for 412 incoming TCP connections on the DHCPv6 server port 547. 413 Implementations MAY offer to make the incoming port configurable, but 414 port 547 MUST be the default. Client implementations SHOULD make TCP 415 connections to port 547, and MAY offer to make the destination server 416 port configurable. 418 This section presents a table of values used to control Bulk 419 Leasequery behavior, including recommended defaults. Implementations 420 MAY make these values configurable. However, configuring too-small 421 timeout values may lead to harmful behavior both to this application 422 as well as to other traffic in the network. As a result, timeout 423 values smaller than the default values are NOT RECOMMENDED. 425 Parameter Default Description 426 ------------------------------------------- 427 BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout 428 BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections 430 6. Requestor Behavior 432 6.1. Connecting 434 A Requestor attempts to establish a TCP connection to a DHCPv6 Server 435 in order to initiate a Leasequery exchange. If the attempt fails, 436 the Requestor MAY retry. 438 6.2. Forming Queries 440 After a connection is established, the Requestor constructs a 441 Leasequery message, as specified in [RFC5007]. The query may have 442 any of the defined query-types, and includes the options and data 443 required by the query-type chosen. The Requestor sends the message 444 size then sends the actual DHCPv6 message, as described in 445 Section 5.1. 447 If the TCP connection becomes blocked or stops being writeable while 448 the Requestor is sending its query, the Requestor SHOULD be prepared 449 to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this 450 recommendation to allow Requestors to control the period of time they 451 are willing to wait before abandoning a connection, independent of 452 notifications from the TCP implementations they may be using. 454 6.3. Processing Replies 456 The Requestor attempts to read a LEASEQUERY-REPLY message from the 457 TCP connection. If the TCP connection stops delivering reply data 458 (if the connection stops being readable), the Requestor SHOULD be 459 prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT, and 460 MAY begin retry processing if configured to do so. 462 The Requestor examines the LEASEQUERY-REPLY message, and determines 463 how to proceed. Message validation rules are specified in DHCPv6 464 Leasequery [RFC5007]. If the reply contains an error status code 465 (carried in an OPTION_STATUS_CODE option), the Requestor follows the 466 recommendations in [RFC5007]. A successful reply that does not 467 include an OPTION_CLIENT_DATA option indicates that the target server 468 had no bindings matching the query. 470 Note: The Leasequery protocol uses the OPTION_CLIENT_LINK option as 471 an indicator that multiple bindings were present in response to a 472 single query. For Bulk Leasequery, the OPTION_CLIENT_LINK option is 473 not used, and MUST NOT be present in replies. 475 A successful LEASEQUERY-REPLY that is returning binding data includes 476 an OPTION_CLIENT_DATA option and possibly additional options. If 477 there are additional bindings to be returned, they will be carried in 478 LEASEQUERY-DATA messages. Each LEASEQUERY-DATA message contains an 479 OPTION_CLIENT_DATA option, and possibly other options. A LEASEQUERY- 480 DATA message that does not contain an OPTION_CLIENT_DATA MUST be 481 discarded. 483 A single bulk query can result in a large number of replies. For 484 example, a single relay agent might be responsible for routes for 485 thousands of clients' delegated prefixes. The Requestor MUST be 486 prepared to receive more than one LEASEQUERY-DATA with transaction- 487 ids matching a single LEASEQUERY message. 489 The LEASEQUERY-DONE message ends a successful Bulk Leasequery request 490 that returned at least one binding. A LEASEQUERY-REPLY without any 491 bindings MUST NOT be followed by a LEASEQUERY-DONE message for the 492 same transaction-id. After receiving LEASEQUERY-DONE from a server, 493 the Requestor MAY close the TCP connection to that server. If the 494 transaction-id in the LEASEQUERY-DONE does not match an outstanding 495 LEASEQUERY message, the client MUST close the TCP connection. 497 6.3.1. Reply Completion 499 The reply to a Bulk Leasequery request is complete (i.e., no further 500 messages for that request transaction-id will be received) when one 501 of these conditions is met: 503 1. if the LEASEQUERY-REPLY message had no OPTION_CLIENT_DATA option, 504 when the LEASEQUERY-REPLY is received, 506 2. else if the LEASEQUERY-REPLY did have an OPTION_CLIENT_DATA, when 507 the corresponding LEASEQUERY-DONE message is received, 509 3. else when the connection is closed. 511 6.4. Querying Multiple Servers 513 A Bulk Leasequery client MAY be configured to attempt to connect to 514 and query from multiple DHCPv6 servers in parallel. The DHCPv6 515 Leasequery specification [RFC5007] includes a discussion about 516 reconciling binding data received from multiple DHCPv6 servers. 518 6.5. Multiple Queries to a Single Server 520 Bulk Leasequery clients may need to make multiple queries in order to 521 recover binding information. A Requestor MAY use a single connection 522 to issue multiple queries. Each query MUST have a unique transaction 523 id. A server MAY process more than one query at a time. A server 524 that is willing to do so MAY interleave replies to the multiple 525 queries within the stream of reply messages it sends. Clients need 526 to be aware that replies for multiple queries may be interleaved 527 within the stream of reply messages. Clients that are not able to 528 process interleaved replies (based on transaction-id) MUST NOT send 529 more than one query at a time. Requestors should be aware that 530 servers are not required to process queries in parallel, and that 531 servers are likely to limit the rate at which they process queries 532 from any one Requestor. 534 6.5.1. Example 536 This example illustrates what a series of queries and responses might 537 look like. This is only an example - there is no requirement that 538 this sequence must be followed, or that clients or servers must 539 support parallel queries. 541 In the example session, the client sends four queries after 542 establishing a connection; "xid" denotes a transaction-id in the 543 diagram. Query 1 results in a failure; query 2 succeeds and the 544 stream of replies concludes before the client issues any new query. 545 Query 3 and query 4 overlap, and the server interleaves its replies 546 to those two queries. 548 Client Server 549 ------ ------ 550 LEASEQUERY xid 1 -----> 551 <----- LEASEQUERY-REPLY xid 1 (w/error) 552 LEASEQUERY xid 2 -----> 553 <----- LEASEQUERY-REPLY xid 2 554 <----- LEASEQUERY-DATA xid 2 555 <----- LEASEQUERY-DATA xid 2 556 <----- LEASEQUERY-DONE xid 2 557 LEASEQUERY xid 3 -----> 558 LEASEQUERY xid 4 -----> 559 <----- LEASEQUERY-REPLY xid 4 560 <----- LEASEQUERY-DATA xid 4 561 <----- LEASEQUERY-REPLY xid 3 562 <----- LEASEQUERY-DATA xid 4 563 <----- LEASEQUERY-DATA xid 3 564 <----- LEASEQUERY-DONE xid 3 565 <----- LEASEQUERY-DATA xid 4 566 <----- LEASEQUERY-DONE xid 4 568 6.6. Closing Connections 570 The Requestor MAY close its end of the TCP connection after sending a 571 LEASEQUERY message to the server. The Requestor MAY choose to retain 572 the connection if it intends to issue additional queries. Note that 573 this client behavior does not guarantee that the connection will be 574 available for additional queries: the server might decide to close 575 the connection based on its own configuration. 577 7. Server Behavior 579 7.1. Accepting Connections 581 Servers that implement DHCPv6 Bulk Leasequery listen for incoming TCP 582 connections. Port numbers are discussed in Section 5.6. Servers 583 MUST be able to limit the number of currently accepted and active 584 connections. The value BULK_LQ_MAX_CONNS MUST be the default; 585 implementations MAY permit the value to be configurable. 587 Servers MAY restrict Bulk Leasequery connections and LEASEQUERY 588 messages to certain clients. Connections not from permitted clients 589 SHOULD BE closed immediately, to avoid server connection resource 590 exhaustion. Servers MAY restrict some clients to certain query 591 types. Servers MAY reply to queries that are not permitted with the 592 NotAllowed status code [RFC5007], and/or close the connection. 594 If the TCP connection becomes blocked while the server is accepting a 595 connection or reading a query, it SHOULD be prepared to terminate the 596 connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation 597 to allow Servers to control the period of time they are willing to 598 wait before abandoning an inactive connection, independent of the TCP 599 implementations they may be using. 601 7.2. Forming Replies 603 The DHCPv6 Leasequery [RFC5007] specification describes the initial 604 construction of LEASEQUERY-REPLY messages and the processing of 605 QUERY_BY_ADDRESS and QUERY_BY_CLIENTID. Use of the LEASEQUERY-REPLY 606 and LEASEQUERY-DATA messages to carry multiple bindings are described 607 in Section 5.2. Message transmission and framing for TCP is 608 described in Section 5.1. If the connection becomes blocked while 609 the server is attempting to send reply messages, the server SHOULD be 610 prepared to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT. 612 If the server encounters an error during initial query processing, 613 before any reply has been sent, it SHOULD send a LEASEQUERY-REPLY 614 containing an error code in an OPTION_STATUS_CODE option. This 615 signals to the requestor that no data will be returned. If the 616 server encounters an error while processing a query that has already 617 resulted in one or more reply messages, the server SHOULD send a 618 LEASEQUERY-DONE message with an error status. The server SHOULD 619 close its end of the connection as an indication that it was not able 620 to complete query processing. 622 If the server does not find any bindings satisfying a query, it 623 SHOULD send a LEASEQUERY-REPLY without an OPTION_STATUS_CODE option 624 and without any OPTION_CLIENT_DATA option. Otherwise, the server 625 sends each binding's data in a reply message. The first reply 626 message is a LEASEQUERY-REPLY. The binding data is carried in an 627 OPTION_CLIENT_DATA option, as specified in [RFC5007] and extended 628 below. The server returns subsequent bindings in LEASEQUERY-DATA 629 messages, which can avoid redundant data (such as the requestor's 630 Client-ID). 632 For QUERY_BY_RELAY_ID, the server locates each binding associated 633 with the query's Relay-ID option value. In order to give a 634 meaningful reply to a QUERY_BY_RELAY_ID, the server has to be able to 635 maintain this association in its DHCPv6 binding data. If the query's 636 link-address is not set to 0::0, the server only returns bindings on 637 links that could contain that address. If the link-address is not 638 0::0 and the server cannot find any matching links, the server SHOULD 639 return the NotConfigured status in a LEASEQUERY-REPLY. 641 For QUERY_BY_LINK_ADDRESS, the server locates each binding associated 642 with the link identified by the query's link-address value. 644 For QUERY_BY_REMOTE_ID, the server locates each binding associated 645 with the query's Relay Remote-ID option value. In order to be able 646 to give meaningful replies to this query, the server has to be able 647 to maintain this association in its binding database. If the query 648 message's link-address is not set to 0::0, the server only returns 649 bindings on links that could contain that address. If the link- 650 address is not 0::0 and the server cannot find any matching links, 651 the server SHOULD return the NotConfigured status in a LEASEQUERY- 652 REPLY. 654 The server sends the LEASEQUERY-DONE message as specified in 655 Section 5.2. 657 7.3. Multiple or Parallel Queries 659 As discussed in Section 6.5, Requestors may want to leverage an 660 existing connection if they need to make multiple queries. Servers 661 MAY support reading and processing multiple queries from a single 662 connection. A server MUST NOT read more query messages from a 663 connection than it is prepared to process simultaneously. 665 This MAY be a feature that is administratively controlled. Servers 666 that are able to process queries in parallel SHOULD offer 667 configuration that limits the number of simultaneous queries 668 permitted from any one Requestor, in order to control resource use if 669 there are multiple Requestors seeking service. 671 7.4. Closing Connections 673 The server MAY close its end of the TCP connection after sending its 674 last message (a LEASEQUERY-REPLY or a LEASEQUERY-DONE) in response to 675 a query. Alternatively, the server MAY retain the connection and 676 wait for additional queries from the client. The server SHOULD be 677 prepared to limit the number of connections it maintains, and SHOULD 678 be prepared to close idle connections to enforce the limit. 680 The server MUST close its end of the TCP connection if it encounters 681 an error sending data on the connection. The server MUST close its 682 end of the TCP connection if it finds that it has to abort an in- 683 process request. A server aborting an in-process request MAY attempt 684 to signal that to its clients by using the QueryTerminated 685 (Section 5.5) status code. If the server detects that the client end 686 has been closed, the server MUST close its end of the connection 687 after it has finished processing any outstanding requests from the 688 client. 690 8. Security Considerations 692 The "Security Considerations" section of [RFC3315] details the 693 general threats to DHCPv6. The DHCPv6 Leasequery specification 694 [RFC5007] describes recommendations for the Leasequery protocol, 695 especially with regard to relayed LEASEQUERY messages, mitigation of 696 packet-flooding DOS attacks, restriction to trusted clients, and use 697 of IPsec [RFC4301]. 699 The use of TCP introduces some additional concerns. Attacks that 700 attempt to exhaust the DHCPv6 server's available TCP connection 701 resources, such as SYN flooding attacks, can compromise the ability 702 of legitimate clients to receive service. Malicious clients who 703 succeed in establishing connections, but who then send invalid 704 queries, partial queries, or no queries at all also can exhaust a 705 server's pool of available connections. We recommend that servers 706 offer configuration to limit the sources of incoming connections, 707 that they limit the number of accepted connections and the number of 708 in-process queries from any one connection, and that they limit the 709 period of time during which an idle connection will be left open. 711 9. IANA Considerations 713 IANA is requested to assign a new DHCPv6 Option Code in the registry 714 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 716 OPTION_RELAY_ID 718 IANA is requested to assign a new value in the registry of DHCPv6 719 Status Codes maintained in 720 http://www.iana.org/assignments/dhcpv6-parameters: 722 QueryTerminated 724 IANA is requested to assign values for the following new DHCPv6 725 Message types in the registry maintained in 726 http://www.iana.org/assignments/dhcpv6-parameters: 728 LEASEQUERY-DONE 729 LEASEQUERY-DATA 731 IANA is requested to assign the following new values in the registry 732 of query-types for the DHCPv6 OPTION_LQ_QUERY option: 734 QUERY_BY_RELAY_ID 735 QUERY_BY_LINK_ADDRESS 736 QUERY_BY_REMOTE_ID 738 10. Acknowledgements 740 Many of the ideas in this document were originally proposed by Kim 741 Kinnear, Richard Johnson, Hemant Singh, Ole Troan, and Bernie Volz. 742 Further suggestions and improvements were made by participants in the 743 DHC working group, including John Brzozowski, Marcus Goller, Alfred 744 Hoenes, Ted Lemon, Bud Millwood, and Thomas Narten. 746 11. References 748 11.1. Normative References 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, March 1997. 753 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 754 and M. Carney, "Dynamic Host Configuration Protocol for 755 IPv6 (DHCPv6)", RFC 3315, July 2003. 757 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 758 Host Configuration Protocol (DHCP) version 6", RFC 3633, 759 December 2003. 761 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 762 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 763 August 2006. 765 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 766 "DHCPv6 Leasequery", RFC 5007, September 2007. 768 11.2. Informative References 770 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 771 Internet Protocol", RFC 4301, December 2005. 773 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 774 for Transmission Control Protocol (TCP) Specification 775 Documents", RFC 4614, September 2006. 777 Author's Address 779 Mark Stapp 780 Cisco Systems, Inc. 781 1414 Massachusetts Ave. 782 Boxborough, MA 01719 783 USA 785 Phone: +1 978 936 0000 786 Email: mjs@cisco.com