idnits 2.17.1 draft-ietf-dhc-dhcpv6-bulk-leasequery-00.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 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 717. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 730. 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 237 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 (February 8, 2008) is 5915 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (ref. '1') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (ref. '2') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4614 (ref. '3') (Obsoleted by RFC 7414) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '7') (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: August 11, 2008 February 8, 2008 6 DHCPv6 Bulk Leasequery 7 draft-ietf-dhc-dhcpv6-bulk-leasequery-00.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 August 11, 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 specifies extensions to the Leasequery protocol that add new 46 query types and allow for bulk transfer of DHCPv6 binding data. 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 . . . . . . . . . . . . . . . . . 5 56 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5.2.1. LEASEQUERY-DATA . . . . . . . . . . . . . . . . . . . 6 58 5.2.2. LEASEQUERY-DONE . . . . . . . . . . . . . . . . . . . 7 59 5.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 7 60 5.3.1. QUERY_BY_RELAYID . . . . . . . . . . . . . . . . . . . 7 61 5.3.2. QUERY_BY_LINK_ADDRESS . . . . . . . . . . . . . . . . 7 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.4. Querying Multiple Servers . . . . . . . . . . . . . . . . 11 72 6.5. Multiple Queries to a Single Server . . . . . . . . . . . 11 73 6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 11 74 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 75 7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 12 76 7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 12 77 7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 13 78 7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 14 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 82 11. Modification History . . . . . . . . . . . . . . . . . . . . . 15 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 Intellectual Property and Copyright Statements . . . . . . . . . . 17 89 1. Introduction 91 The DHCPv6 [1] protocol specifies a mechanism for the assignment of 92 IPv6 address and configuration information to IPv6 nodes. IPv6 93 Prefix Delegation for DHCPv6 (PD) [2] specifies a mechanism for 94 DHCPv6 delegation of IPv6 prefixes and related data. DHCPv6 servers 95 maintain authoritative information including binding information for 96 delegated IPv6 prefixes. 98 The client of a PD binding is typically a router, which then 99 advertises the delegated prefix to locally-connected hosts. The 100 delegated IPv6 prefix must be routeable in order to be useful. The 101 actual DHCPv6 PD client may not be permitted to inject routes into 102 the delegating network. In service-provider (SP) networks, for 103 example, an edge router typically acts as a DHCPv6 relay agent, and 104 this edge router often has the responsibility to maintain routes 105 within the service-provider network for clients' PD bindings. 107 A DHCPv6 relay with this responsibility requires a means to recover 108 binding information from the authoritative DHCPv6 server(s) in the 109 event of replacement or reboot, in order to restore routeability to 110 delegated prefixes. The relay may be a network device without 111 adequate local storage to maintain the necessary binding-to-route 112 data. A DHCPv6 Leasequery protocol [6] has been developed that 113 allows queries for individual bindings from the authoritative DHCPv6 114 Server(s). The individual query mechanism is only useable when the 115 target binding is known to the requestor. In the case of DHCPv6 116 Prefix Delegation, the PD binding data may need to be known before 117 any traffic arrives from the client router. The DHCPv6 relay router 118 may not be able to form individual 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 [3] for efficiency of data transfer. We specify a new 124 DHCPv6 option, the Relay Identifier option, to support efficient 125 recovery of all data associated with a specific relay agent; we also 126 add a query-type for this purpose. We add query-types by network 127 segment and by Remote-ID option value, to assist a relay that needs 128 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 [4]. 136 DHCPv6 terminology is defined in [1]. DHCPv6 Leasequery terminology 137 is defined in [6]. 139 3. Protocol Overview 141 The Bulk Leasequery mechanism is modeled on the existing individual 142 Leasequery protocol in [6]; most differences arise from the use of 143 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. The client sends a LEASEQUERY message, 148 containing a query-type and data about bindings it is interested in. 150 The server uses the query-type and the data to identify any relevant 151 bindings. In order to support some query-types, servers may have to 152 maintain additional data structures or be able to locate bindings 153 based on specific option data. The server replies with a LEASEQUERY- 154 REPLY message, indicating the success or failure of the query. If 155 the query was successful, the server includes the first client's 156 binding data in the LEASEQUERY-REPLY message also. If more than one 157 client's bindings are being returned, the server then transmits the 158 additional client bindings in a series of LEASEQUERY-DATA messages. 159 If the server has sent at least one client's bindings, it sends a 160 LEASEQUERY-DONE message when it has finished sending its replies. 161 Each end of the TCP connection can be closed after all data has been 162 sent. 164 This specification includes a new DHCPv6 option, the Relay-ID option. 165 The option contains a DUID identifying a DHCPv6 relay agent. Relay 166 agents can include this option in Relay-Forward messages they send. 167 Servers can retain the Relay-ID and associate it with bindings made 168 on behalf of the relay's clients. A relay can then recover binding 169 information about downstream clients by using the Relay-ID in a 170 LEASEQUERY message. The Relay-ID option is defined in Section 5.4.1. 172 Bulk Leasequery supports the queries by IPv6 address and by Client 173 DUID as specified in [6]. The Bulk Leasequery protocol also adds 174 several new queries. The new queries introduced here cannot be used 175 effectively with the UDP Leasequery protocol. Requestors MUST NOT 176 send these new query-types in RFC5007 query messages. 178 Query by Relay Identifier - This query asks a server for the 179 bindings associated with a specific relay; the relay is identified 180 by a DUID carried in a Relay-ID option. 182 Query by Link Address - This query asks a server for the bindings on 183 a particular network segment; the link is specified in the query's 184 link-address field. 186 Query by Remote ID - This query asks a server for the bindings 187 associated with a Relay Agent Remote-ID option [5] value. 189 4. Interaction Between UDP Leasequery and Bulk Leasequery 191 Bulk Leasequery can be seen as an extension of the existing UDP 192 Leasequery protocol [6]. This section tries to clarify the 193 relationship between the two protocols. 195 The query-types introduced in the UDP Leasequery protocol can be used 196 in the Bulk Leasequery protocol. One change in behavior is permitted 197 when Bulk Leasequery is used. RFC5007, in sections 4.1.2.5 and 198 4.3.3, specifies the use of a Client Link option in LEASEQUERY-REPLY 199 messages in cases where multiple bindings were found. When Bulk 200 Leasequery is used, this mechanism is not necessary: a server 201 returning multiple bindings simply does so directly as specified in 202 this document. The Client Link option MUST NOT appear in Bulk 203 Leasequery replies. 205 The new queries introduced in this specification cannot be used with 206 the UDP Leasequery protocol. Servers that implement this 207 specification and also permit UDP queries MUST NOT accept Bulk 208 Leasequery query-types in UDP Leasequery messages. Such servers MUST 209 respond with an error status code of NotAllowed. 211 5. Message and Option Definitions 213 5.1. Message Framing for TCP 215 The use of TCP for the Bulk Leasequery protocol permits one or more 216 DHCPv6 messages to be sent at a time. The receiver needs to be able 217 to determine how large each message is. Two octets containing the 218 message size in network byte-order are prepended to each DHCPv6 219 message sent on a Bulk Leasequery TCP connection. The two message- 220 size octets 'frame' each DHCPv6 message. 222 DHCPv6 message framed for TCP: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | message-size | msg-type | trans-id | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | transaction-id (cont'd) | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 231 | . 232 . options . 233 . (variable) . 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 message-size the number of octets in the message that 238 follows, as a 16-bit integer in network 239 byte-order. 241 All other fields are as specified in DHCPv6 [1]. 243 5.2. Messages 245 The LEASEQUERY and LEASEQUERY-REPLY messages are defined in [6]. In 246 a Bulk Leasequery exchange, a single LEASEQUERY-REPLY message is used 247 to indicate the success or failure of a query, and to carry data that 248 do not change in the context of a single query and answer, such as 249 the Server-ID and Client-ID options. If a query is successful, only 250 a single LEASEQUERY-REPLY message MUST appear. If the server is 251 returning binding data, the LEASEQUERY-REPLY also contains the first 252 client's binding data in an OPTION_CLIENT_DATA option. 254 5.2.1. LEASEQUERY-DATA 256 The LEASEQUERY-DATA message (message type TBD) carries data about a 257 single DHCPv6 client's leases and/or PD bindings on a single link. 258 The purpose of the message is to reduce redundant data when there are 259 multiple bindings to be sent. The LEASEQUERY-DATA message MUST be 260 preceded by a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY conveys 261 the query's status, carries the Leasequery's Client-ID and Server-ID 262 options, and carries the first client's binding data if the query was 263 successful. 265 LEASEQUERY-DATA MUST ONLY be sent in response to a successful 266 LEASEQUERY, and only if more than one client's data is to be sent. 268 The LEASEQUERY-DATA message's transaction-id field MUST match the 269 transaction-id of the LEASEQUERY request message. The Server-ID, 270 Client-ID, and OPTION_STATUS_CODE options SHOULD NOT be included: 271 that data should be constant for any one Bulk Leasequery reply, and 272 should have been conveyed in the LEASEQUERY-REPLY message. 274 5.2.2. LEASEQUERY-DONE 276 The LEASEQUERY-DONE message (message type TBD) indicates the end of a 277 group of related Leasequery replies. The LEASEQUERY-DONE message's 278 transaction-id field MUST match the transaction-id of the LEASEQUERY 279 request message. The presence of the message itself signals the end 280 of a stream of reply messages. A single LEASEQUERY-DONE MUST BE sent 281 after all replies to a successful Bulk Leasequery request that 282 returned at least one binding. 284 A server may encounter an error condition after it has sent the 285 initial LEASEQUERY-REPLY. In that case, it SHOULD attempt to send a 286 LEASEQUERY-DONE with an OPTION_STATUS_CODE option indicating the 287 error condition to the requestor. Other DHCPv6 options SHOULD NOT be 288 included in the LEASEQUERY-DONE message. 290 5.3. Query Types 292 The OPTION_LQ_QUERY option is defined in [6]. We introduce the 293 following new query-types: QUERY_BY_RELAYID, QUERY_BY_LINK_ADDRESS, 294 QUERY_BY_REMOTE_ID. These queries are designed to assist relay 295 agents in recovering binding data in circumstances where some or all 296 of the relay's binding data has been lost. 298 5.3.1. QUERY_BY_RELAYID 300 This query asks the server to return bindings associated with the 301 specified relay DUID. 303 QUERY_BY_RELAYID (3) - The query-options MUST contain an 304 OPTION_RELAYID option. If the link-address field is 0::0, the 305 query asks for all bindings associated with the specified relay 306 DUID. If the link-address is specified, the query asks for 307 bindings on that link. 309 5.3.2. QUERY_BY_LINK_ADDRESS 311 The QUERY_BY_LINK_ADDRESS asks the server to return bindings on a 312 network segment identified by an link-address value from a relay's 313 Relay-Forward message. 315 QUERY_BY_LINK_ADDRESS (4) - The query's link-address contains an 316 address a relay may have used in the link-address of a Relay- 317 Forward message. The Server attempts to locate bindings on the 318 same network segment as the link-address. 320 5.3.3. QUERY_BY_REMOTE_ID 322 The QUERY_BY_REMOTE_ID asks the server to return bindings associated 323 with a Remote-ID option value from a relay's Relay-Forward message. 324 The query-options MUST include a Relay-ID option. 326 In order to support this query, a server needs to record the most- 327 recent Remote-ID option value seen in a Relay-Forward message along 328 with its other binding data. 330 QUERY_BY_REMOTE_ID (5) - The query-options MUST include a Relay 331 Agent Remote-ID option. If the Server has recorded Remote-ID 332 values with its bindings, it uses the option's value to identify 333 bindings to return. 335 5.4. Options 337 5.4.1. Relay-ID Option 339 The Relay-ID option carries a DUID. A relay agent MAY include the 340 option in Relay-Forward messages it sends. Obviously, it will not be 341 possible for a server to respond to QUERY_BY_RELAYID queries unless 342 the relay agent has included this option. A relay SHOULD be able to 343 generate a DUID for this purpose, and capture the result in stable 344 storage. A relay SHOULD also allow the DUID value to be 345 configurable: doing so allows an administrator to replace a relay 346 agent while retaining the association between the relay and existing 347 DHCPv6 bindings. 349 A DHCPv6 Server MAY associate Relay-ID options from Relay-Forward 350 messages it processes with PD and/or lease bindings that result. 351 Doing so allows it to respond to QUERY_BY_RELAYID Leasequeries. 353 The format of the Relay-ID option is shown below: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | OPTION_RELAYID | option-len | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 . . 361 . DUID . 362 . (variable length) . 363 . . 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 option-code OPTION_RELAYID (TBD). 368 option-len Length of DUID in octets. 370 DUID The DUID for the relay agent. 372 5.5. Status Codes 374 TODO: are any new status codes needed - to indicate a connection or 375 resource problem e.g.? 377 5.6. Connection and Transmission Parameters 379 DHCPv6 Servers that support Bulk Leasequery SHOULD listen for 380 incoming TCP connections on the DHCPv6 server port 547. 381 Implementations MAY offer to make the incoming port configurable, but 382 port 547 MUST be the default. Client implementations SHOULD make TCP 383 connections to port 547, and MAY offer to make the destination server 384 port configurable. 386 This section presents a table of values used to control Bulk 387 Leasequery behavior, including recommended defaults. Implementations 388 MAY make these values configurable. 390 Parameter Default Description 391 ------------------------------------------ 392 BULK_LQ_CONN_TIMEOUT 30 secs Bulk Leasequery connection timeout 393 BULK_LQ_DATA_TIMEOUT 30 secs Bulk Leasequery data timeout 394 BULK_LQ_MAX_RETRY 60 secs Max Bulk Leasequery retry timeout value 395 BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections 397 6. Requestor Behavior 399 6.1. Connecting 401 A Requestor attempts to establish a TCP connection to a DHCPv6 Server 402 in order to initiate a Leasequery exchange. The Requestor SHOULD be 403 prepared to abandon the connection attempt after 404 BULK_LQ_CONN_TIMEOUT. If the attempt fails, the Requestor MAY retry. 405 Retries MUST use an exponential backoff timer, increasing the 406 interval between attempts up to BULK_LQ_MAX_RETRY. 408 6.2. Forming Queries 410 After a connection is established, the Requestor constructs a 411 Leasequery message, as specified in [6]. The query may have any of 412 the defined query-types, and includes the options and data required 413 by the query-type chosen. The Requestor sends the message size then 414 sends the actual DHCPv6 message, as described in Section 5.1. 416 If the TCP connection becomes blocked while the Requestor is sending 417 its query, the Requestor SHOULD be prepared to terminate the 418 connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation 419 to allow Requestors to control the period of time they are willing to 420 wait before abandoning a connection, independent of notifications 421 from the TCP implementations they may be using. 423 6.3. Processing Replies 425 The Requestor attempts to read a LEASEQUERY-REPLY message from the 426 TCP connection. If the stream of replies becomes blocked, the 427 Requestor SHOULD be prepared to terminate the connection after 428 BULK_LQ_DATA_TIMEOUT, and MAY begin retry processing if configured to 429 do so. 431 The Requestor examines the LEASEQUERY-REPLY message, and determines 432 how to proceed. Message validation rules are specified in DHCPv6 433 Leasequery [6]. If the reply contains an error status code (carried 434 in an OPTION_STATUS_CODE option), the Requestor follows the 435 recommendations in [6]. A successful reply that does not include an 436 OPTION_CLIENT_DATA option indicates that the target server had no 437 bindings matching the query. 439 The Leasequery protocol uses the OPTION_CLIENT_LINK option as an 440 indicator that multiple bindings were present in response to a single 441 query. For Bulk Leasequery, the OPTION_CLIENT_LINK option is not 442 used, and MUST NOT be present in replies. 444 A successful LEASEQUERY-REPLY that is returning binding data includes 445 an OPTION_CLIENT_DATA option and possibly additional options. If 446 there are additional bindings to be returned, they will be carried in 447 LEASEQUERY-DATA messages. Each LEASEQUERY-DATA message contains an 448 OPTION_CLIENT_DATA option, and possibly other options. A LEASEQUERY- 449 DATA message that does not contain an OPTION_CLIENT_DATA MUST BE 450 discarded. 452 A single bulk query can result in a large number of replies. For 453 example, a single relay agent might be responsible for routes for 454 thousands of clients' delegated prefixes. The Requestor MUST be 455 prepared to receive more than one LEASEQUERY-DATA with transaction- 456 ids matching a single LEASEQUERY message. 458 The LEASEQUERY-DONE message ends a successful Bulk Leasequery session 459 that returned at least one binding. A LEASEQUERY-REPLY without any 460 bindings MUST NOT be followed by a LEASEQUERY-DONE message for the 461 same transaction-id. After receiving LEASEQUERY-DONE from a server, 462 the Requestor MAY close the TCP connection to that server. If the 463 transaction-id in the LEASEQUERY-DONE does not match an outstanding 464 LEASEQUERY message, the client MUST close the TCP connection. 466 6.4. Querying Multiple Servers 468 A Bulk Leasequery client MAY be configured to attempt to connect to 469 and query from multiple DHCPv6 servers in parallel. The DHCPv6 470 Leasequery specification [6] includes a discussion about reconciling 471 binding data received from multiple DHCPv6 servers. 473 6.5. Multiple Queries to a Single Server 475 Bulk Leasequery clients may need to make multiple queries in order to 476 recover binding information. A Requestor MAY use a single connection 477 to issue multiple queries, each with a unique transaction id. 478 Requestors should be aware that servers are not required to process 479 queries in parallel, and that servers are likely to limit the rate at 480 which they process queries from any one Requestor. 482 6.6. Closing Connections 484 The Requestor MAY close its end of the TCP connection after sending a 485 LEASEQUERY message to the server. The Requestor MAY choose to retain 486 the connection if it intends to issue additional queries. Note that 487 this client behavior does not guarantee that the connection will be 488 available for additional queries: the server might decide to close 489 the connection based on its own configuration. 491 7. Server Behavior 493 7.1. Accepting Connections 495 Servers that implement DHCPv6 Bulk Leasequery listen for incoming TCP 496 connections. Port numbers are discussed in Section 5.6. Servers 497 MUST be able to limit the number of currently accepted and active 498 connections. The value BULK_LQ_MAX_CONNS MUST be the default; 499 implementations MAY permit the value to be configurable. 501 Servers MAY restrict Bulk Leasequery connections and LEASEQUERY 502 messages to certain clients. Connections not from permitted clients 503 SHOULD BE closed immediately, to avoid server connection resource 504 exhaustion. Servers MAY restrict some clients to certain query 505 types. Servers MAY reply to queries that are not permitted with the 506 NotAllowed status code [6], or MAY close the connection. 508 If the TCP connection becomes blocked while the server is accepting a 509 connection or reading a query, it SHOULD be prepared to terminate the 510 connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation 511 to allow Servers to control the period of time they are willing to 512 wait before abandoning an inactive connection, independent of the TCP 513 implementations they may be using. 515 7.2. Forming Replies 517 The DHCPv6 Leasequery [6] specification describes the initial 518 construction of LEASEQUERY-REPLY messages and the processing of 519 QUERY_BY_ADDRESS and QUERY_BY_CLIENTID. Use of the LEASEQUERY-REPLY 520 and LEASEQUERY-DATA messages to carry multiple bindings are described 521 in Section 5.2. Message transmission and framing for TCP is 522 described in Section 5.1. If the connection becomes blocked while 523 the server is attempting to send reply messages, the server SHOULD be 524 prepared to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT. 526 If the server encounters an error during initial query processing, 527 before any reply has been sent, it SHOULD send a LEASEQUERY-REPLY 528 containing an error code in an OPTION_STATUS_CODE option. This 529 signals to the requestor that no data will be returned. If the 530 server encounters an error while processing a query that has already 531 resulted in one or more reply messages, the server SHOULD send a 532 LEASEQUERY-DONE message with an error status. The server SHOULD 533 close its end of the connection as an indication that it was not able 534 to complete query processing. 536 If the server does not find any bindings satisfying a query, it 537 SHOULD send a LEASEQUERY-REPLY without an OPTION_STATUS_CODE option 538 and without any OPTION_CLIENT_DATA option. Otherwise, the server 539 sends each binding's data in a reply message. The first reply 540 message is a LEASEQUERY-REPLY. The binding data is carried in an 541 OPTION_CLIENT_DATA option, as specified in [6] and extended below. 542 The server returns subsequent bindings in LEASEQUERY-DATA messages, 543 which can avoid redundant data (such as the requestor's Client-ID). 545 For QUERY_BY_RELAYID, the server locates each binding associated with 546 the query's Relay-ID option value. In order to give a meaningful 547 reply to a QUERY_BY_RELAYID, the server has to be able to maintain 548 this association in its DHCPv6 binding data. If the query's link- 549 address is not set to 0::0, the server only returns bindings on links 550 that could contain that address. If the link-address is not 0::0 and 551 the server cannot find any matching links, the server SHOULD return 552 the NotConfigured status in a LEASEQUERY-REPLY. 554 For QUERY_BY_LINK_ADDRESS, the server locates each binding associated 555 with the link identified by the query's link-address value. 557 For QUERY_BY_REMOTE_ID, the server locates each binding associated 558 with the query's Relay Remote-ID option value. In order to be able 559 to give meaningful replies to this query, the server has to be able 560 to maintain this association in its binding database. If the query 561 message's link-address is not set to 0::0, the server only returns 562 bindings on links that could contain that address. If the link- 563 address is not 0::0 and the server cannot find any matching links, 564 the server SHOULD return the NotConfigured status in a LEASEQUERY- 565 REPLY. 567 The server sends the LEASEQUERY-DONE message as specified in 568 Section 5.2. 570 7.3. Multiple or Parallel Queries 572 As discussed in Section 6.5, Requestors may want to leverage an 573 existing connection if they need to make multiple queries. Servers 574 MAY support reading and processing multiple queries from a single 575 connection. A server MUST NOT read more query messages from a 576 connection than it is prepared to process simultaneously. 578 This MAY be a feature that is administratively controlled. Servers 579 that are able to process queries in parallel SHOULD offer 580 configuration that limits the number of simultaneous queries 581 permitted from any one Requestor, in order to control resource use if 582 there are multiple Requestors seeking service. 584 7.4. Closing Connections 586 The server MAY close its end of the TCP connection after sending its 587 last message (a LEASEQUERY-REPLY or a LEASEQUERY-DONE) in response to 588 a query. Alternatively, the server MAY retain the connection and 589 wait for additional queries from the client. The server SHOULD be 590 prepared to limit the number of connections it maintains, and SHOULD 591 be prepared to close idle connections to enforce the limit. 593 The server MUST close its end of the TCP connection if it finds that 594 it has to abort an in-process request, or if it encounters an error 595 sending data on the connection. If the server detects that the 596 client end has been closed, the server MUST close its end of the 597 connection after it has finished processing any outstanding requests 598 from the client. 600 8. Security Considerations 602 The "Security Considerations" section of [1] details the general 603 threats to DHCPv6. The DHCPv6 Leasequery specification [6] describes 604 recommendations for the Leasequery protocol, especially with regard 605 to relayed LEASEQUERY messages, mitigation of packet-flooding DOS 606 attacks, restriction to trusted clients, and use of IPsec [7]. 608 The use of TCP introduces some additional concerns. Attacks that 609 attempt to exhaust the DHCPv6 server's available TCP connection 610 resources, such as SYN flooding attacks, can compromise the ability 611 of legitimate clients to receive service. Malicious clients who 612 succeed in establishing connections, but who then send invalid 613 queries, partial queries, or no queries at all also can exhaust a 614 server's pool of available connections. We recommend that servers 615 offer configuration to limit the sources of incoming connections, 616 that they limit the number of accepted connections and the number of 617 in-process queries from any one connection, and that they limit the 618 period of time during which an idle connection will be left open. 620 9. IANA Considerations 622 IANA is requested to assign a new DHCPv6 Option Code in the registry 623 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 625 OPTION_RELAYID 627 IANA is requested to assign values for the following new DHCPv6 628 Message types in the registry maintained in 629 http://www.iana.org/assignments/dhcpv6-parameters: 631 LEASEQUERY-DONE 632 LEASEQUERY-DATA 634 IANA is requested to assign the following new values in the registry 635 of query-types for the DHCPv6 OPTION_LQ_QUERY option: 637 QUERY_BY_RELAYID 3 638 QUERY_BY_LINK_ADDRESS 4 639 QUERY_BY_REMOTE_ID 5 641 10. Acknowledgements 643 Many of the ideas in this document were originally proposed by Kim 644 Kinnear, Richard Johnson, Hemant Singh, Ole Troan, and Bernie Volz. 645 Further suggestions and improvements were made by participants in the 646 DHC working group, including: John Brzozowski, Marcus Goller, Ted 647 Lemon, and Bud Millwood. 649 11. Modification History 651 12. References 653 12.1. Normative References 655 [1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 656 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 657 RFC 3315, July 2003. 659 [2] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 660 Configuration Protocol (DHCP) version 6", RFC 3633, 661 December 2003. 663 [3] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for 664 Transmission Control Protocol (TCP) Specification Documents", 665 RFC 4614, September 2006. 667 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 668 Levels", BCP 14, RFC 2119, March 1997. 670 [5] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 671 Relay Agent Remote-ID Option", RFC 4649, August 2006. 673 [6] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 674 Leasequery", RFC 5007, September 2007. 676 12.2. Informative References 678 [7] Kent, S. and R. Atkinson, "Security Architecture for the 679 Internet Protocol", RFC 2401, November 1998. 681 Author's Address 683 Mark Stapp 684 Cisco Systems, Inc. 685 1414 Massachusetts Ave. 686 Boxborough, MA 01719 687 USA 689 Phone: +1 978 936 0000 690 Email: mjs@cisco.com 692 Full Copyright Statement 694 Copyright (C) The IETF Trust (2008). 696 This document is subject to the rights, licenses and restrictions 697 contained in BCP 78, and except as set forth therein, the authors 698 retain all their rights. 700 This document and the information contained herein are provided on an 701 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 702 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 703 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 704 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 705 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 706 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 708 Intellectual Property 710 The IETF takes no position regarding the validity or scope of any 711 Intellectual Property Rights or other rights that might be claimed to 712 pertain to the implementation or use of the technology described in 713 this document or the extent to which any license under such rights 714 might or might not be available; nor does it represent that it has 715 made any independent effort to identify any such rights. Information 716 on the procedures with respect to rights in RFC documents can be 717 found in BCP 78 and BCP 79. 719 Copies of IPR disclosures made to the IETF Secretariat and any 720 assurances of licenses to be made available, or the result of an 721 attempt made to obtain a general license or permission for the use of 722 such proprietary rights by implementers or users of this 723 specification can be obtained from the IETF on-line IPR repository at 724 http://www.ietf.org/ipr. 726 The IETF invites any interested party to bring to its attention any 727 copyrights, patents or patent applications, or other proprietary 728 rights that may cover technology that may be required to implement 729 this standard. Please address the information to the IETF at 730 ietf-ipr@ietf.org. 732 Acknowledgment 734 Funding for the RFC Editor function is provided by the IETF 735 Administrative Support Activity (IASA).