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