idnits 2.17.1 draft-ietf-dhc-dhcpv6-bulk-leasequery-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 798. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 822. 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 Copyright Line does not match the current year == Line 252 has weird spacing: '...ge-size 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 (November 25, 2008) is 5623 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 (~~), 3 warnings (==), 8 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 November 25, 2008 5 Expires: May 29, 2009 7 DHCPv6 Bulk Leasequery 8 draft-ietf-dhc-dhcpv6-bulk-leasequery-05.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 29, 2009. 35 Abstract 37 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been 38 extended with a Leasequery capability that allows a client to request 39 information about DHCPv6 bindings. That mechanism is limited to 40 queries for individual bindings. In some situations individual 41 binding queries may not be efficient, or even possible. This 42 document expands on the Leasequery protocol, adding new query types 43 and allowing for bulk transfer of DHCPv6 binding data via TCP. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 50 4. Interaction Between UDP Leasequery and Bulk Leasequery . . . . 5 51 5. Message and Option Definitions . . . . . . . . . . . . . . . . 6 52 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 6 53 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 5.2.1. LEASEQUERY-DATA . . . . . . . . . . . . . . . . . . . 7 55 5.2.2. LEASEQUERY-DONE . . . . . . . . . . . . . . . . . . . 7 56 5.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 7 57 5.3.1. QUERY_BY_RELAY_ID . . . . . . . . . . . . . . . . . . 7 58 5.3.2. QUERY_BY_LINK_ADDRESS . . . . . . . . . . . . . . . . 8 59 5.3.3. QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . 8 60 5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5.4.1. Relay-ID Option . . . . . . . . . . . . . . . . . . . 8 62 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.6. Connection and Transmission Parameters . . . . . . . . . . 9 64 6. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 10 65 6.1. Connecting . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6.2. Forming Queries . . . . . . . . . . . . . . . . . . . . . 10 67 6.3. Processing Replies . . . . . . . . . . . . . . . . . . . . 10 68 6.3.1. Reply Completion . . . . . . . . . . . . . . . . . . . 11 69 6.4. Querying Multiple Servers . . . . . . . . . . . . . . . . 12 70 6.5. Multiple Queries to a Single Server . . . . . . . . . . . 12 71 6.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12 72 6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 13 73 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 74 7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 13 75 7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 14 76 7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 15 77 7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 15 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 81 11. Modification History . . . . . . . . . . . . . . . . . . . . . 17 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 84 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 Intellectual Property and Copyright Statements . . . . . . . . . . 19 88 1. Introduction 90 The DHCPv6 [RFC3315] protocol specifies a mechanism for the 91 assignment of IPv6 address and configuration information to IPv6 92 nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a 93 mechanism for DHCPv6 delegation of IPv6 prefixes and related data. 94 DHCPv6 servers maintain authoritative information including binding 95 information for delegated IPv6 prefixes. 97 The client of a PD binding is typically a router, which then 98 advertises the delegated prefix to locally-connected hosts. The 99 delegated IPv6 prefix must be routeable in order to be useful. The 100 actual DHCPv6 PD client may not be permitted to inject routes into 101 the delegating network. In service-provider (SP) networks, for 102 example, an edge router typically acts as a DHCPv6 relay agent, and 103 this edge router often has the responsibility to maintain routes 104 within the service-provider network for clients' PD bindings. 106 A DHCPv6 relay with this responsibility requires a means to recover 107 binding information from the authoritative DHCPv6 server(s) in the 108 event of replacement or reboot, in order to restore routeability to 109 delegated prefixes. The relay may be a network device without 110 adequate local storage to maintain the necessary binding-to-route 111 data. A DHCPv6 Leasequery protocol [RFC5007] has been developed that 112 allows queries for individual bindings from the authoritative DHCPv6 113 Server(s). The individual query mechanism is only useable when the 114 target binding is known to the requestor, such as upon receipt of 115 traffic. In the case of DHCPv6 Prefix Delegation, the PD binding 116 data may need to be known before any traffic arrives from the client 117 router. The DHCPv6 relay router may not be able to form individual 118 queries in such cases. 120 This document extends the DHCPv6 Leasequery protocol to add support 121 for queries that address these requirements. At the SP edge there 122 may be many thousands of delegated prefixes per relay, so we specify 123 the use of TCP [RFC4614] for efficiency of data transfer. We specify 124 a new DHCPv6 option, the Relay Identifier option, to support 125 efficient recovery of all data associated with a specific relay 126 agent; we also add a query-type for this purpose. We add query-types 127 by network segment and by Remote-ID option value, to assist a relay 128 that needs to recover a subset of its clients' bindings. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 DHCPv6 terminology is defined in [RFC3315]. DHCPv6 Leasequery 137 terminology is defined in [RFC5007]. 139 3. Protocol Overview 141 The Bulk Leasequery mechanism is modeled on the existing individual 142 Leasequery protocol in [RFC5007]; most differences arise from the use 143 of TCP. A Bulk Leasequery client opens a TCP connection to a DHCPv6 144 Server, using the DHCPv6 port 547. Note that this implies that the 145 Leasequery client has server IP address(es) available via 146 configuration or some other means, and that it has unicast IP 147 reachability to the server. No relaying for bulk leasequery is 148 specified. 150 After establishing a connection, the client sends a LEASEQUERY 151 message containing a query-type and data about bindings it is 152 interested in. The server uses the query-type and the data to 153 identify any relevant bindings. In order to support some query- 154 types, servers may have to maintain additional data structures or be 155 able to locate bindings based on specific option data. The server 156 replies with a LEASEQUERY-REPLY message, indicating the success or 157 failure of the query. If the query was successful, the server 158 includes the first client's binding data in the LEASEQUERY-REPLY 159 message also. If more than one client's bindings are being returned, 160 the server then transmits the additional client bindings in a series 161 of LEASEQUERY-DATA messages. If the server has sent at least one 162 client's bindings, it sends a LEASEQUERY-DONE message when it has 163 finished sending its replies. The client may reuse the connection to 164 send additional queries. Each end of the TCP connection can be 165 closed after all data has been sent. 167 This specification includes a new DHCPv6 option, the Relay-ID option. 168 The option contains a DUID (DHCP Unique Identifier) identifying a 169 DHCPv6 relay agent. Relay agents can include this option in Relay- 170 Forward messages they send. Servers can retain the Relay-ID and 171 associate it with bindings made on behalf of the relay's clients. A 172 relay can then recover binding information about downstream clients 173 by using the Relay-ID in a LEASEQUERY message. The Relay-ID option 174 is defined in Section 5.4.1. 176 Bulk Leasequery supports the queries by IPv6 address and by Client 177 DUID as specified in [RFC5007]. The Bulk Leasequery protocol also 178 adds several new queries. The new queries introduced here cannot be 179 used effectively with the UDP Leasequery protocol. Requestors MUST 180 NOT send these new query-types in [RFC5007] query messages. 182 Query by Relay Identifier - This query asks a server for the 183 bindings associated with a specific relay; the relay is identified 184 by a DUID carried in a Relay-ID option. 186 Query by Link Address - This query asks a server for the bindings on 187 a particular network segment; the link is specified in the query's 188 link-address field. 190 Query by Remote ID - This query asks a server for the bindings 191 associated with a Relay Agent Remote-ID option [RFC4649] value. 193 4. Interaction Between UDP Leasequery and Bulk Leasequery 195 Bulk Leasequery can be seen as an extension of the existing UDP 196 Leasequery protocol [RFC5007]. This section tries to clarify the 197 relationship between the two protocols. 199 The query-types introduced in the UDP Leasequery protocol can be used 200 in the Bulk Leasequery protocol. One change in behavior is 201 introduced when Bulk Leasequery is used. [RFC5007], in sections 202 4.1.2.5 and 4.3.3, specifies the use of a Client Link option in 203 LEASEQUERY-REPLY messages in cases where multiple bindings were 204 found. When Bulk Leasequery is used, this mechanism is not 205 necessary: a server returning multiple bindings simply does so 206 directly as specified in this document. The Client Link option MUST 207 NOT appear in Bulk Leasequery replies. 209 Only LEASEQUERY, LEASEQUERY-REPLY, LEASEQUERY-DATA, and LEASEQUERY- 210 DONE messages are allowed over the Bulk Leasequery connection. No 211 other DHCPv6 messages are supported. The Bulk Leasequery connection 212 is not an alternative DHCPv6 communication option for clients seeking 213 DHCPv6 service. 215 The new queries introduced in this specification cannot be used with 216 the UDP Leasequery protocol. Servers that implement this 217 specification and also permit UDP queries MUST NOT accept Bulk 218 Leasequery query-types in UDP Leasequery messages. Such servers MUST 219 respond with an error status code of NotAllowed [RFC5007]. 221 Implementors should note that the TCP message framing defined in 222 Section 5.1 is not compatible with the UDP message format. If a TCP- 223 framed request is sent as a UDP message, it may not be valid, because 224 protocol fields will be offset by the message-size prefix. 226 5. Message and Option Definitions 228 5.1. Message Framing for TCP 230 The use of TCP for the Bulk Leasequery protocol permits one or more 231 DHCPv6 messages to be sent at a time. The receiver needs to be able 232 to determine how large each message is. Two octets containing the 233 message size in network byte order are prepended to each DHCPv6 234 message sent on a Bulk Leasequery TCP connection. The two message- 235 size octets 'frame' each DHCPv6 message. 237 DHCPv6 message framed for TCP: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | message-size | msg-type | : 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 : transaction-id | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 246 | . 247 . options . 248 . (variable) . 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 message-size the number of octets in the message that 253 follows, as a 16-bit integer in network 254 byte order. 256 All other fields are as specified in DHCPv6 [RFC3315]. 258 5.2. Messages 260 The LEASEQUERY and LEASEQUERY-REPLY messages are defined in 261 [RFC5007]. In a Bulk Leasequery exchange, a single LEASEQUERY-REPLY 262 message is used to indicate the success or failure of a query, and to 263 carry data that do not change in the context of a single query and 264 answer, such as the Server-ID and Client-ID options. If a query is 265 successful, only a single LEASEQUERY-REPLY message MUST appear. If 266 the server is returning binding data, the LEASEQUERY-REPLY also 267 contains the first client's binding data in an OPTION_CLIENT_DATA 268 option. 270 5.2.1. LEASEQUERY-DATA 272 The LEASEQUERY-DATA message carries data about a single DHCPv6 273 client's leases and/or PD bindings on a single link. The purpose of 274 the message is to reduce redundant data when there are multiple 275 bindings to be sent. The LEASEQUERY-DATA message MUST be preceded by 276 a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY conveys the query's 277 status, carries the Leasequery's Client-ID and Server-ID options, and 278 carries the first client's binding data if the query was successful. 280 LEASEQUERY-DATA MUST ONLY be sent in response to a successful 281 LEASEQUERY, and only if more than one client's data is to be sent. 282 The LEASEQUERY-DATA message's transaction-id field MUST match the 283 transaction-id of the LEASEQUERY request message. The Server-ID, 284 Client-ID, and OPTION_STATUS_CODE options SHOULD NOT be included: 285 that data should be constant for any one Bulk Leasequery reply, and 286 should have been conveyed in the LEASEQUERY-REPLY message. 288 5.2.2. LEASEQUERY-DONE 290 The LEASEQUERY-DONE message indicates the end of a group of related 291 Leasequery replies. The LEASEQUERY-DONE message's transaction-id 292 field MUST match the transaction-id of the LEASEQUERY request 293 message. The presence of the message itself signals the end of a 294 stream of reply messages. A single LEASEQUERY-DONE MUST BE sent 295 after all replies (a successful LEASEQUERY-REPLY and zero or more 296 LEASEQUERY-DATA messages) to a successful Bulk Leasequery request 297 that returned at least one binding. 299 A server may encounter an error condition after it has sent the 300 initial LEASEQUERY-REPLY. In that case, it SHOULD attempt to send a 301 LEASEQUERY-DONE with an OPTION_STATUS_CODE option indicating the 302 error condition to the requestor. Other DHCPv6 options SHOULD NOT be 303 included in the LEASEQUERY-DONE message. 305 5.3. Query Types 307 The OPTION_LQ_QUERY option is defined in [RFC5007]. We introduce the 308 following new query-types: QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, 309 QUERY_BY_REMOTE_ID. These queries are designed to assist relay 310 agents in recovering binding data in circumstances where some or all 311 of the relay's binding data has been lost. 313 5.3.1. QUERY_BY_RELAY_ID 315 This query asks the server to return bindings associated with the 316 specified relay DUID. 318 QUERY_BY_RELAY_ID - The query-options MUST contain an 319 OPTION_RELAY_ID option. If the link-address field is 0::0, the 320 query asks for all bindings associated with the specified relay 321 DUID. If the link-address is specified, the query asks for 322 bindings on that link. 324 5.3.2. QUERY_BY_LINK_ADDRESS 326 The QUERY_BY_LINK_ADDRESS asks the server to return bindings on a 327 network segment identified by an link-address value from a relay's 328 Relay-Forward message. 330 QUERY_BY_LINK_ADDRESS - The query's link-address contains an 331 address a relay may have used in the link-address of a Relay- 332 Forward message. The Server attempts to locate bindings on the 333 same network segment as the link-address. 335 5.3.3. QUERY_BY_REMOTE_ID 337 The QUERY_BY_REMOTE_ID asks the server to return bindings associated 338 with a Remote-ID option value from a relay's Relay-Forward message. 339 The query-options MUST include a Relay Agent Remote-ID option 340 [RFC4649]. 342 In order to support this query, a server needs to record the most- 343 recent Remote-ID option value seen in a Relay-Forward message along 344 with its other binding data. 346 QUERY_BY_REMOTE_ID - The query-options MUST include a Relay Agent 347 Remote-ID option [RFC4649]. If the Server has recorded Remote-ID 348 values with its bindings, it uses the option's value to identify 349 bindings to return. 351 5.4. Options 353 5.4.1. Relay-ID Option 355 The Relay-ID option carries a DUID [RFC3315]. A relay agent MAY 356 include the option in Relay-Forward messages it sends. Obviously, it 357 will not be possible for a server to respond to QUERY_BY_RELAY_ID 358 queries unless the relay agent has included this option. A relay 359 SHOULD be able to generate a DUID for this purpose, and capture the 360 result in stable storage. A relay SHOULD also allow the DUID value 361 to be configurable: doing so allows an administrator to replace a 362 relay agent while retaining the association between the relay and 363 existing DHCPv6 bindings. 365 A DHCPv6 Server MAY associate Relay-ID options from Relay-Forward 366 messages it processes with prefix delegations and/or lease bindings 367 that result. Doing so allows it to respond to QUERY_BY_RELAY_ID 368 Leasequeries. 370 The format of the Relay-ID option is shown below: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | OPTION_RELAY_ID | option-len | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 . . 378 . DUID . 379 . (variable length) . 380 . . 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 option-code OPTION_RELAY_ID. 385 option-len Length of DUID in octets. 387 DUID The DUID for the relay agent. 389 5.5. Status Codes 391 QueryTerminated - Indicates that the server is unable to perform a 392 query or has prematurely terminated the query for some reason (which 393 should be communicated in the text message). This may be because the 394 server is short of resources or is being shut down. The requestor 395 may retry the query at a later time. The requestor should wait at 396 least a short interval before retrying. Note that while a server may 397 simply prematurely close its end of the connection, it is preferable 398 for the server to send a LEASEQUERY-REPLY or LEASEQUERY-DONE with 399 this status-code to notify the requestor of the condition. 401 5.6. Connection and Transmission Parameters 403 DHCPv6 Servers that support Bulk Leasequery SHOULD listen for 404 incoming TCP connections on the DHCPv6 server port 547. 405 Implementations MAY offer to make the incoming port configurable, but 406 port 547 MUST be the default. Client implementations SHOULD make TCP 407 connections to port 547, and MAY offer to make the destination server 408 port configurable. 410 This section presents a table of values used to control Bulk 411 Leasequery behavior, including recommended defaults. Implementations 412 MAY make these values configurable. 414 Parameter Default Description 415 ------------------------------------------ 416 BULK_LQ_CONN_TIMEOUT 30 secs Bulk Leasequery connection timeout 417 BULK_LQ_DATA_TIMEOUT 30 secs Bulk Leasequery data timeout 418 BULK_LQ_MAX_RETRY 60 secs Max Bulk Leasequery retry timeout 419 BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections 421 6. Requestor Behavior 423 6.1. Connecting 425 A Requestor attempts to establish a TCP connection to a DHCPv6 Server 426 in order to initiate a Leasequery exchange. The Requestor SHOULD be 427 prepared to abandon the connection attempt after 428 BULK_LQ_CONN_TIMEOUT. If the attempt fails, the Requestor MAY retry. 429 Retries MUST use an exponential backoff timer, increasing the 430 interval between attempts up to BULK_LQ_MAX_RETRY. 432 6.2. Forming Queries 434 After a connection is established, the Requestor constructs a 435 Leasequery message, as specified in [RFC5007]. The query may have 436 any of the defined query-types, and includes the options and data 437 required by the query-type chosen. The Requestor sends the message 438 size then sends the actual DHCPv6 message, as described in 439 Section 5.1. 441 If the TCP connection becomes blocked while the Requestor is sending 442 its query, the Requestor SHOULD be prepared to terminate the 443 connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation 444 to allow Requestors to control the period of time they are willing to 445 wait before abandoning a connection, independent of notifications 446 from the TCP implementations they may be using. 448 6.3. Processing Replies 450 The Requestor attempts to read a LEASEQUERY-REPLY message from the 451 TCP connection. If the stream of replies becomes blocked, the 452 Requestor SHOULD be prepared to terminate the connection after 453 BULK_LQ_DATA_TIMEOUT, and MAY begin retry processing if configured to 454 do so. 456 The Requestor examines the LEASEQUERY-REPLY message, and determines 457 how to proceed. Message validation rules are specified in DHCPv6 458 Leasequery [RFC5007]. If the reply contains an error status code 459 (carried in an OPTION_STATUS_CODE option), the Requestor follows the 460 recommendations in [RFC5007]. A successful reply that does not 461 include an OPTION_CLIENT_DATA option indicates that the target server 462 had no bindings matching the query. 464 Note: The Leasequery protocol uses the OPTION_CLIENT_LINK option as 465 an indicator that multiple bindings were present in response to a 466 single query. For Bulk Leasequery, the OPTION_CLIENT_LINK option is 467 not used, and MUST NOT be present in replies. 469 A successful LEASEQUERY-REPLY that is returning binding data includes 470 an OPTION_CLIENT_DATA option and possibly additional options. If 471 there are additional bindings to be returned, they will be carried in 472 LEASEQUERY-DATA messages. Each LEASEQUERY-DATA message contains an 473 OPTION_CLIENT_DATA option, and possibly other options. A LEASEQUERY- 474 DATA message that does not contain an OPTION_CLIENT_DATA MUST be 475 discarded. 477 A single bulk query can result in a large number of replies. For 478 example, a single relay agent might be responsible for routes for 479 thousands of clients' delegated prefixes. The Requestor MUST be 480 prepared to receive more than one LEASEQUERY-DATA with transaction- 481 ids matching a single LEASEQUERY message. 483 The LEASEQUERY-DONE message ends a successful Bulk Leasequery request 484 that returned at least one binding. A LEASEQUERY-REPLY without any 485 bindings MUST NOT be followed by a LEASEQUERY-DONE message for the 486 same transaction-id. After receiving LEASEQUERY-DONE from a server, 487 the Requestor MAY close the TCP connection to that server. If the 488 transaction-id in the LEASEQUERY-DONE does not match an outstanding 489 LEASEQUERY message, the client MUST close the TCP connection. 491 6.3.1. Reply Completion 493 The reply to a Bulk Leasequery request is complete (i.e., no further 494 messages for that request transaction-id will be received) when one 495 of these conditions is met: 497 1. if the LEASEQUERY-REPLY message had no OPTION_CLIENT_DATA option, 498 when the LEASEQUERY-REPLY is received, 500 2. else if the LEASEQUERY-REPLY did have an OPTION_CLIENT_DATA, when 501 the corresponding LEASEQUERY-DONE message is received, 503 3. else when the connection is closed. 505 6.4. Querying Multiple Servers 507 A Bulk Leasequery client MAY be configured to attempt to connect to 508 and query from multiple DHCPv6 servers in parallel. The DHCPv6 509 Leasequery specification [RFC5007] includes a discussion about 510 reconciling binding data received from multiple DHCPv6 servers. 512 6.5. Multiple Queries to a Single Server 514 Bulk Leasequery clients may need to make multiple queries in order to 515 recover binding information. A Requestor MAY use a single connection 516 to issue multiple queries. Each query MUST have a unique transaction 517 id. A server MAY process more than one query at a time. A server 518 that is willing to do so MAY interleave replies to the multiple 519 queries within the stream of reply messages it sends. Clients need 520 to be aware that replies for multiple queries may be interleaved 521 within the stream of reply messages. Clients that are not able to 522 process interleaved replies (based on transaction-id) MUST NOT send 523 more than one query at a time. Requestors should be aware that 524 servers are not required to process queries in parallel, and that 525 servers are likely to limit the rate at which they process queries 526 from any one Requestor. 528 6.5.1. Example 530 This example illustrates what a series of queries and responses might 531 look like. This is only an example - there is no requirement that 532 this sequence must be followed, or that clients or servers must 533 support parallel queries. 535 In the example session, the client sends four queries after 536 establishing a connection; "xid" denotes a transaction-id in the 537 diagram. Query 1 results in a failure; query 2 succeeds and the 538 stream of replies concludes before the client issues any new query. 539 Query 3 and query 4 overlap, and the server interleaves its replies 540 to those two queries. 542 Client Server 543 ------ ------ 544 LEASEQUERY xid 1 -----> 545 <----- LEASEQUERY-REPLY xid 1 (w/error) 546 LEASEQUERY xid 2 -----> 547 <----- LEASEQUERY-REPLY xid 2 548 <----- LEASEQUERY-DATA xid 2 549 <----- LEASEQUERY-DATA xid 2 550 <----- LEASEQUERY-DONE xid 2 551 LEASEQUERY xid 3 -----> 552 LEASEQUERY xid 4 -----> 553 <----- LEASEQUERY-REPLY xid 4 554 <----- LEASEQUERY-DATA xid 4 555 <----- LEASEQUERY-REPLY xid 3 556 <----- LEASEQUERY-DATA xid 4 557 <----- LEASEQUERY-DATA xid 3 558 <----- LEASEQUERY-DONE xid 3 559 <----- LEASEQUERY-DATA xid 4 560 <----- LEASEQUERY-DONE xid 4 562 6.6. Closing Connections 564 The Requestor MAY close its end of the TCP connection after sending a 565 LEASEQUERY message to the server. The Requestor MAY choose to retain 566 the connection if it intends to issue additional queries. Note that 567 this client behavior does not guarantee that the connection will be 568 available for additional queries: the server might decide to close 569 the connection based on its own configuration. 571 7. Server Behavior 573 7.1. Accepting Connections 575 Servers that implement DHCPv6 Bulk Leasequery listen for incoming TCP 576 connections. Port numbers are discussed in Section 5.6. Servers 577 MUST be able to limit the number of currently accepted and active 578 connections. The value BULK_LQ_MAX_CONNS MUST be the default; 579 implementations MAY permit the value to be configurable. 581 Servers MAY restrict Bulk Leasequery connections and LEASEQUERY 582 messages to certain clients. Connections not from permitted clients 583 SHOULD BE closed immediately, to avoid server connection resource 584 exhaustion. Servers MAY restrict some clients to certain query 585 types. Servers MAY reply to queries that are not permitted with the 586 NotAllowed status code [RFC5007], and/or close the connection. 588 If the TCP connection becomes blocked while the server is accepting a 589 connection or reading a query, it SHOULD be prepared to terminate the 590 connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation 591 to allow Servers to control the period of time they are willing to 592 wait before abandoning an inactive connection, independent of the TCP 593 implementations they may be using. 595 7.2. Forming Replies 597 The DHCPv6 Leasequery [RFC5007] specification describes the initial 598 construction of LEASEQUERY-REPLY messages and the processing of 599 QUERY_BY_ADDRESS and QUERY_BY_CLIENTID. Use of the LEASEQUERY-REPLY 600 and LEASEQUERY-DATA messages to carry multiple bindings are described 601 in Section 5.2. Message transmission and framing for TCP is 602 described in Section 5.1. If the connection becomes blocked while 603 the server is attempting to send reply messages, the server SHOULD be 604 prepared to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT. 606 If the server encounters an error during initial query processing, 607 before any reply has been sent, it SHOULD send a LEASEQUERY-REPLY 608 containing an error code in an OPTION_STATUS_CODE option. This 609 signals to the requestor that no data will be returned. If the 610 server encounters an error while processing a query that has already 611 resulted in one or more reply messages, the server SHOULD send a 612 LEASEQUERY-DONE message with an error status. The server SHOULD 613 close its end of the connection as an indication that it was not able 614 to complete query processing. 616 If the server does not find any bindings satisfying a query, it 617 SHOULD send a LEASEQUERY-REPLY without an OPTION_STATUS_CODE option 618 and without any OPTION_CLIENT_DATA option. Otherwise, the server 619 sends each binding's data in a reply message. The first reply 620 message is a LEASEQUERY-REPLY. The binding data is carried in an 621 OPTION_CLIENT_DATA option, as specified in [RFC5007] and extended 622 below. The server returns subsequent bindings in LEASEQUERY-DATA 623 messages, which can avoid redundant data (such as the requestor's 624 Client-ID). 626 For QUERY_BY_RELAY_ID, the server locates each binding associated 627 with the query's Relay-ID option value. In order to give a 628 meaningful reply to a QUERY_BY_RELAY_ID, the server has to be able to 629 maintain this association in its DHCPv6 binding data. If the query's 630 link-address is not set to 0::0, the server only returns bindings on 631 links that could contain that address. If the link-address is not 632 0::0 and the server cannot find any matching links, the server SHOULD 633 return the NotConfigured status in a LEASEQUERY-REPLY. 635 For QUERY_BY_LINK_ADDRESS, the server locates each binding associated 636 with the link identified by the query's link-address value. 638 For QUERY_BY_REMOTE_ID, the server locates each binding associated 639 with the query's Relay Remote-ID option value. In order to be able 640 to give meaningful replies to this query, the server has to be able 641 to maintain this association in its binding database. If the query 642 message's link-address is not set to 0::0, the server only returns 643 bindings on links that could contain that address. If the link- 644 address is not 0::0 and the server cannot find any matching links, 645 the server SHOULD return the NotConfigured status in a LEASEQUERY- 646 REPLY. 648 The server sends the LEASEQUERY-DONE message as specified in 649 Section 5.2. 651 7.3. Multiple or Parallel Queries 653 As discussed in Section 6.5, Requestors may want to leverage an 654 existing connection if they need to make multiple queries. Servers 655 MAY support reading and processing multiple queries from a single 656 connection. A server MUST NOT read more query messages from a 657 connection than it is prepared to process simultaneously. 659 This MAY be a feature that is administratively controlled. Servers 660 that are able to process queries in parallel SHOULD offer 661 configuration that limits the number of simultaneous queries 662 permitted from any one Requestor, in order to control resource use if 663 there are multiple Requestors seeking service. 665 7.4. Closing Connections 667 The server MAY close its end of the TCP connection after sending its 668 last message (a LEASEQUERY-REPLY or a LEASEQUERY-DONE) in response to 669 a query. Alternatively, the server MAY retain the connection and 670 wait for additional queries from the client. The server SHOULD be 671 prepared to limit the number of connections it maintains, and SHOULD 672 be prepared to close idle connections to enforce the limit. 674 The server MUST close its end of the TCP connection if it encounters 675 an error sending data on the connection. The server MUST close its 676 end of the TCP connection if it finds that it has to abort an in- 677 process request. A server aborting an in-process request MAY attempt 678 to signal that to its clients by using the QueryTerminated 679 (Section 5.5) status code. If the server detects that the client end 680 has been closed, the server MUST close its end of the connection 681 after it has finished processing any outstanding requests from the 682 client. 684 8. Security Considerations 686 The "Security Considerations" section of [RFC3315] details the 687 general threats to DHCPv6. The DHCPv6 Leasequery specification 688 [RFC5007] describes recommendations for the Leasequery protocol, 689 especially with regard to relayed LEASEQUERY messages, mitigation of 690 packet-flooding DOS attacks, restriction to trusted clients, and use 691 of IPsec [RFC4301]. 693 The use of TCP introduces some additional concerns. Attacks that 694 attempt to exhaust the DHCPv6 server's available TCP connection 695 resources, such as SYN flooding attacks, can compromise the ability 696 of legitimate clients to receive service. Malicious clients who 697 succeed in establishing connections, but who then send invalid 698 queries, partial queries, or no queries at all also can exhaust a 699 server's pool of available connections. We recommend that servers 700 offer configuration to limit the sources of incoming connections, 701 that they limit the number of accepted connections and the number of 702 in-process queries from any one connection, and that they limit the 703 period of time during which an idle connection will be left open. 705 9. IANA Considerations 707 IANA is requested to assign a new DHCPv6 Option Code in the registry 708 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 710 OPTION_RELAY_ID 712 IANA is requested to assign a new value in the registry of DHCPv6 713 Status Codes maintained in 714 http://www.iana.org/assignments/dhcpv6-parameters: 716 QueryTerminated 718 IANA is requested to assign values for the following new DHCPv6 719 Message types in the registry maintained in 720 http://www.iana.org/assignments/dhcpv6-parameters: 722 LEASEQUERY-DONE 723 LEASEQUERY-DATA 725 IANA is requested to assign the following new values in the registry 726 of query-types for the DHCPv6 OPTION_LQ_QUERY option: 728 QUERY_BY_RELAY_ID 729 QUERY_BY_LINK_ADDRESS 730 QUERY_BY_REMOTE_ID 732 10. Acknowledgements 734 Many of the ideas in this document were originally proposed by Kim 735 Kinnear, Richard Johnson, Hemant Singh, Ole Troan, and Bernie Volz. 736 Further suggestions and improvements were made by participants in the 737 DHC working group, including John Brzozowski, Marcus Goller, Ted 738 Lemon, and Bud Millwood. 740 11. Modification History 742 12. References 744 12.1. Normative References 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, March 1997. 749 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 750 and M. Carney, "Dynamic Host Configuration Protocol for 751 IPv6 (DHCPv6)", RFC 3315, July 2003. 753 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 754 Host Configuration Protocol (DHCP) version 6", RFC 3633, 755 December 2003. 757 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 758 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 759 August 2006. 761 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 762 "DHCPv6 Leasequery", RFC 5007, September 2007. 764 12.2. Informative References 766 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 767 Internet Protocol", RFC 4301, December 2005. 769 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 770 for Transmission Control Protocol (TCP) Specification 771 Documents", RFC 4614, September 2006. 773 Author's Address 775 Mark Stapp 776 Cisco Systems, Inc. 777 1414 Massachusetts Ave. 778 Boxborough, MA 01719 779 USA 781 Phone: +1 978 936 0000 782 Email: mjs@cisco.com 784 Full Copyright Statement 786 Copyright (C) The IETF Trust (2008). 788 This document is subject to the rights, licenses and restrictions 789 contained in BCP 78, and except as set forth therein, the authors 790 retain all their rights. 792 This document and the information contained herein are provided on an 793 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 794 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 795 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 796 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 797 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 798 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 800 Intellectual Property 802 The IETF takes no position regarding the validity or scope of any 803 Intellectual Property Rights or other rights that might be claimed to 804 pertain to the implementation or use of the technology described in 805 this document or the extent to which any license under such rights 806 might or might not be available; nor does it represent that it has 807 made any independent effort to identify any such rights. Information 808 on the procedures with respect to rights in RFC documents can be 809 found in BCP 78 and BCP 79. 811 Copies of IPR disclosures made to the IETF Secretariat and any 812 assurances of licenses to be made available, or the result of an 813 attempt made to obtain a general license or permission for the use of 814 such proprietary rights by implementers or users of this 815 specification can be obtained from the IETF on-line IPR repository at 816 http://www.ietf.org/ipr. 818 The IETF invites any interested party to bring to its attention any 819 copyrights, patents or patent applications, or other proprietary 820 rights that may cover technology that may be required to implement 821 this standard. Please address the information to the IETF at 822 ietf-ipr@ietf.org.