diff options
Diffstat (limited to 'doc/rfc/rfc5460.txt')
| -rw-r--r-- | doc/rfc/rfc5460.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc5460.txt b/doc/rfc/rfc5460.txt new file mode 100644 index 0000000..6f76491 --- /dev/null +++ b/doc/rfc/rfc5460.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group M. Stapp +Request for Comments: 5460 Cisco Systems, Inc. +Category: Standards Track February 2009 + + + DHCPv6 Bulk Leasequery + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been + extended with a Leasequery capability that allows a client to request + information about DHCPv6 bindings. That mechanism is limited to + queries for individual bindings. In some situations individual + binding queries may not be efficient, or even possible. This + document expands on the Leasequery protocol, adding new query types + and allowing for bulk transfer of DHCPv6 binding data via TCP. + + + + + + + + + + + + + + + + +Stapp Standards Track [Page 1] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Interaction between UDP Leasequery and Bulk Leasequery . . . . 5 + 5. Message and Option Definitions . . . . . . . . . . . . . . . . 6 + 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 6 + 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.2.1. LEASEQUERY-DATA . . . . . . . . . . . . . . . . . . . 7 + 5.2.2. LEASEQUERY-DONE . . . . . . . . . . . . . . . . . . . 7 + 5.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.3.1. QUERY_BY_RELAY_ID . . . . . . . . . . . . . . . . . . 7 + 5.3.2. QUERY_BY_LINK_ADDRESS . . . . . . . . . . . . . . . . 8 + 5.3.3. QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . 8 + 5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5.4.1. Relay-ID Option . . . . . . . . . . . . . . . . . . . 8 + 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.6. Connection and Transmission Parameters . . . . . . . . . . 9 + 6. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. Connecting . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.2. Forming Queries . . . . . . . . . . . . . . . . . . . . . 10 + 6.3. Processing Replies . . . . . . . . . . . . . . . . . . . . 10 + 6.3.1. Reply Completion . . . . . . . . . . . . . . . . . . . 11 + 6.4. Querying Multiple Servers . . . . . . . . . . . . . . . . 11 + 6.5. Multiple Queries to a Single Server . . . . . . . . . . . 12 + 6.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 13 + 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 13 + 7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 14 + 7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 15 + 7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 15 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 + + + + + + + + + + + + +Stapp Standards Track [Page 2] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + +1. Introduction + + The DHCPv6 [RFC3315] protocol specifies a mechanism for the + assignment of IPv6 address and configuration information to IPv6 + nodes. IPv6 Prefix Delegation (PD) for DHCPv6 [RFC3633] specifies a + mechanism for DHCPv6 delegation of IPv6 prefixes and related data. + DHCPv6 servers maintain authoritative information including binding + information for delegated IPv6 prefixes. + + The client of a PD binding is typically a router, which then + advertises the delegated prefix to locally-connected hosts. The + delegated IPv6 prefix must be routeable in order to be useful. The + actual DHCPv6 PD client may not be permitted to inject routes into + the delegating network. In service-provider (SP) networks, for + example, an edge router typically acts as a DHCPv6 relay agent, and + this edge router often has the responsibility to maintain routes + within the service-provider network for clients' PD bindings. + + A DHCPv6 relay with this responsibility requires a means to recover + binding information from the authoritative DHCPv6 server(s) in the + event of replacement or reboot, in order to restore routeability to + delegated prefixes. The relay may be a network device without + adequate local storage to maintain the necessary binding-to-route + data. A DHCPv6 Leasequery protocol [RFC5007] has been developed that + allows queries for individual bindings from the authoritative DHCPv6 + server(s). The individual query mechanism is only useable when the + target binding is known to the requestor, such as upon receipt of + traffic. In the case of DHCPv6 Prefix Delegation, the PD binding + data may need to be known before any traffic arrives from the client + router. The DHCPv6 relay router may not be able to form individual + queries in such cases. + + This document extends the DHCPv6 Leasequery protocol to add support + for queries that address these requirements. At the SP edge there + may be many thousands of delegated prefixes per relay, so we specify + the use of TCP [RFC4614] for efficiency of data transfer. We specify + a new DHCPv6 option, the Relay Identifier option, to support + efficient recovery of all data associated with a specific relay + agent; we also add a query-type for this purpose. We add query-types + by network segment and by Remote-ID option value, to assist a relay + that needs to recover a subset of its clients' bindings. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + +Stapp Standards Track [Page 3] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + + DHCPv6 terminology is defined in [RFC3315]. DHCPv6 Leasequery + terminology is defined in [RFC5007]. + +3. Protocol Overview + + The Bulk Leasequery mechanism is modeled on the existing individual + Leasequery protocol in [RFC5007]; most differences arise from the use + of TCP. A Bulk Leasequery client opens a TCP connection to a DHCPv6 + server, using the DHCPv6 port 547. Note that this implies that the + Leasequery client has server IP address(es) available via + configuration or some other means, and that it has unicast IP + reachability to the server. No relaying for bulk leasequery is + specified. + + After establishing a connection, the client sends a LEASEQUERY + message containing a query-type and data about bindings it is + interested in. The server uses the query-type and the data to + identify any relevant bindings. In order to support some query- + types, servers may have to maintain additional data structures or be + able to locate bindings based on specific option data. The server + replies with a LEASEQUERY-REPLY message, indicating the success or + failure of the query. If the query was successful, the server + includes the first client's binding data in the LEASEQUERY-REPLY + message also. If more than one client's bindings are being returned, + the server then transmits the additional client bindings in a series + of LEASEQUERY-DATA messages. If the server has sent at least one + client's bindings, it sends a LEASEQUERY-DONE message when it has + finished sending its replies. The client may reuse the connection to + send additional queries. Each end of the TCP connection can be + closed after all data has been sent. + + This specification includes a new DHCPv6 option, the Relay-ID option. + The option contains a DUID (DHCP Unique Identifier) identifying a + DHCPv6 relay agent. Relay agents can include this option in Relay- + Forward messages they send. Servers can retain the Relay-ID and + associate it with bindings made on behalf of the relay's clients. A + relay can then recover binding information about downstream clients + by using the Relay-ID in a LEASEQUERY message. The Relay-ID option + is defined in Section 5.4.1. + + Bulk Leasequery supports the queries by IPv6 address and by Client + DUID as specified in [RFC5007]. The Bulk Leasequery protocol also + adds several new queries. The new queries introduced here cannot be + used effectively with the UDP Leasequery protocol. Requestors MUST + NOT send these new query-types in [RFC5007] query messages. + + + + + + +Stapp Standards Track [Page 4] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + + Query by Relay Identifier - This query asks a server for the + bindings associated with a specific relay; the relay is identified + by a DUID carried in a Relay-ID option. + + Query by Link Address - This query asks a server for the bindings on + a particular network segment; the link is specified in the query's + link-address field. + + Query by Remote ID - This query asks a server for the bindings + associated with a Relay Agent Remote-ID option [RFC4649] value. + +4. Interaction between UDP Leasequery and Bulk Leasequery + + Bulk Leasequery can be seen as an extension of the existing UDP + Leasequery protocol [RFC5007]. This section tries to clarify the + relationship between the two protocols. + + The query-types introduced in the UDP Leasequery protocol can be used + in the Bulk Leasequery protocol. One change in behavior is + introduced when Bulk Leasequery is used. [RFC5007], in sections + 4.1.2.5 and 4.3.3, specifies the use of a Client Link option in + LEASEQUERY-REPLY messages in cases where multiple bindings were + found. When Bulk Leasequery is used, this mechanism is not + necessary: a server returning multiple bindings simply does so + directly as specified in this document. The Client Link option MUST + NOT appear in Bulk Leasequery replies. + + Only LEASEQUERY, LEASEQUERY-REPLY, LEASEQUERY-DATA, and LEASEQUERY- + DONE messages are allowed over the Bulk Leasequery connection. No + other DHCPv6 messages are supported. The Bulk Leasequery connection + is not an alternative DHCPv6 communication option for clients seeking + DHCPv6 service. + + The new queries introduced in this specification cannot be used with + the UDP Leasequery protocol. Servers that implement this + specification and also permit UDP queries MUST NOT accept Bulk + Leasequery query-types in UDP Leasequery messages. Such servers MUST + respond with an error status code of NotAllowed [RFC5007]. + + Implementors should note that the TCP message framing defined in + Section 5.1 is not compatible with the UDP message format. If a TCP- + framed request is sent as a UDP message, it may not be valid, because + protocol fields will be offset by the message-size prefix. + + + + + + + + +Stapp Standards Track [Page 5] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + +5. Message and Option Definitions + +5.1. Message Framing for TCP + + The use of TCP for the Bulk Leasequery protocol permits one or more + DHCPv6 messages to be sent at a time. The receiver needs to be able + to determine how large each message is. Two octets containing the + message size in network byte order are prepended to each DHCPv6 + message sent on a Bulk Leasequery TCP connection. The two message- + size octets 'frame' each DHCPv6 message. + + DHCPv6 message framed for TCP: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message-size | msg-type | : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : transaction-id | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | . + . options . + . (variable) . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + message-size the number of octets in the message that + follows, as a 16-bit integer in network + byte order. + + All other fields are as specified in DHCPv6 [RFC3315]. + +5.2. Messages + + The LEASEQUERY and LEASEQUERY-REPLY messages are defined in + [RFC5007]. In a Bulk Leasequery exchange, a single LEASEQUERY-REPLY + message is used to indicate the success or failure of a query, and to + carry data that do not change in the context of a single query and + answer, such as the Server-ID and Client-ID options. If a query is + successful, only a single LEASEQUERY-REPLY message MUST appear. If + the server is returning binding data, the LEASEQUERY-REPLY also + contains the first client's binding data in an OPTION_CLIENT_DATA + option. + + + + + + + + +Stapp Standards Track [Page 6] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + +5.2.1. LEASEQUERY-DATA + + The LEASEQUERY-DATA message carries data about a single DHCPv6 + client's leases and/or PD bindings on a single link. The purpose of + the message is to reduce redundant data when there are multiple + bindings to be sent. The LEASEQUERY-DATA message MUST be preceded by + a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY carries the query's + status, the Leasequery's Client-ID and Server-ID options, and the + first client's binding data if the query was successful. + + LEASEQUERY-DATA MUST ONLY be sent in response to a successful + LEASEQUERY, and only if more than one client's data is to be sent. + The LEASEQUERY-DATA message's transaction-id field MUST match the + transaction-id of the LEASEQUERY request message. The Server-ID, + Client-ID, and OPTION_STATUS_CODE options SHOULD NOT be included: + that data should be constant for any one Bulk Leasequery reply, and + should have been conveyed in the LEASEQUERY-REPLY message. + +5.2.2. LEASEQUERY-DONE + + The LEASEQUERY-DONE message indicates the end of a group of related + Leasequery replies. The LEASEQUERY-DONE message's transaction-id + field MUST match the transaction-id of the LEASEQUERY request + message. The presence of the message itself signals the end of a + stream of reply messages. A single LEASEQUERY-DONE MUST BE sent + after all replies (a successful LEASEQUERY-REPLY and zero or more + LEASEQUERY-DATA messages) to a successful Bulk Leasequery request + that returned at least one binding. + + A server may encounter an error condition after it has sent the + initial LEASEQUERY-REPLY. In that case, it SHOULD attempt to send a + LEASEQUERY-DONE with an OPTION_STATUS_CODE option indicating the + error condition to the requestor. Other DHCPv6 options SHOULD NOT be + included in the LEASEQUERY-DONE message. + +5.3. Query Types + + The OPTION_LQ_QUERY option is defined in [RFC5007]. We introduce the + following new query-types: QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, + and QUERY_BY_REMOTE_ID. These queries are designed to assist relay + agents in recovering binding data in circumstances where some or all + of the relay's binding data has been lost. + +5.3.1. QUERY_BY_RELAY_ID + + This query asks the server to return bindings associated with the + specified relay DUID. + + + + +Stapp Standards Track [Page 7] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + + QUERY_BY_RELAY_ID - The query-options MUST contain an + OPTION_RELAY_ID option. If the link-address field is 0::0, the + query asks for all bindings associated with the specified relay + DUID. If the link-address is specified, the query asks for + bindings on that link. + +5.3.2. QUERY_BY_LINK_ADDRESS + + The QUERY_BY_LINK_ADDRESS asks the server to return bindings on a + network segment identified by a link-address value from a relay's + Relay-Forward message. + + QUERY_BY_LINK_ADDRESS - The query's link-address contains an + address a relay may have used in the link-address of a Relay- + Forward message. The Server attempts to locate bindings on the + same network segment as the link-address. + +5.3.3. QUERY_BY_REMOTE_ID + + The QUERY_BY_REMOTE_ID asks the server to return bindings associated + with a Remote-ID option value from a relay's Relay-Forward message. + The query-options MUST include a Relay Agent Remote-ID option + [RFC4649]. + + In order to support this query, a server needs to record the most- + recent Remote-ID option value seen in a Relay-Forward message along + with its other binding data. + + QUERY_BY_REMOTE_ID - The query-options MUST include a Relay Agent + Remote-ID option [RFC4649]. If the Server has recorded Remote-ID + values with its bindings, it uses the option's value to identify + bindings to return. + +5.4. Options + +5.4.1. Relay-ID Option + + The Relay-ID option carries a DUID [RFC3315]. A relay agent MAY + include the option in Relay-Forward messages it sends. Obviously, it + will not be possible for a server to respond to QUERY_BY_RELAY_ID + queries unless the relay agent has included this option. A relay + SHOULD be able to generate a DUID for this purpose, and capture the + result in stable storage. A relay SHOULD also allow the DUID value + to be configurable: doing so allows an administrator to replace a + relay agent while retaining the association between the relay and + existing DHCPv6 bindings. + + + + + +Stapp Standards Track [Page 8] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + + A DHCPv6 server MAY associate Relay-ID options from Relay-Forward + messages it processes with prefix delegations and/or lease bindings + that result. Doing so allows it to respond to QUERY_BY_RELAY_ID + Leasequeries. + + The format of the Relay-ID option is shown below: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_RELAY_ID | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . DUID . + . (variable length) . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + option-code OPTION_RELAY_ID. + + option-len Length of DUID in octets. + + DUID The DUID for the relay agent. + +5.5. Status Codes + + QueryTerminated - Indicates that the server is unable to perform a + query or has prematurely terminated the query for some reason (which + should be communicated in the text of the message). This may be + because the server is short of resources or is being shut down. The + requestor may retry the query at a later time. The requestor should + wait at least a short interval before retrying. Note that while a + server may simply prematurely close its end of the connection, it is + preferable for the server to send a LEASEQUERY-REPLY or LEASEQUERY- + DONE with this status-code to notify the requestor of the condition. + +5.6. Connection and Transmission Parameters + + DHCPv6 servers that support Bulk Leasequery SHOULD listen for + incoming TCP connections on the DHCPv6 server port 547. + Implementations MAY offer to make the incoming port configurable, but + port 547 MUST be the default. Client implementations SHOULD make TCP + connections to port 547, and MAY offer to make the destination server + port configurable. + + This section presents a table of values used to control Bulk + Leasequery behavior, including recommended defaults. Implementations + MAY make these values configurable. However, configuring too-small + + + +Stapp Standards Track [Page 9] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + + timeout values may lead to harmful behavior both to this application + as well as to other traffic in the network. As a result, timeout + values smaller than the default values are NOT RECOMMENDED. + + Parameter Default Description + ------------------------------------------- + BULK_LQ_DATA_TIMEOUT 300 s Bulk Leasequery data timeout + BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections + +6. Requestor Behavior + +6.1. Connecting + + A requestor attempts to establish a TCP connection to a DHCPv6 server + in order to initiate a Leasequery exchange. If the attempt fails, + the requestor MAY retry. + +6.2. Forming Queries + + After a connection is established, the requestor constructs a + Leasequery message, as specified in [RFC5007]. The query may have + any of the defined query-types, and includes the options and data + required by the query-type chosen. The requestor sends the message + size then sends the actual DHCPv6 message, as described in + Section 5.1. + + If the TCP connection becomes blocked or stops being writeable while + the requestor is sending its query, the requestor SHOULD be prepared + to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this + recommendation to allow requestors to control the period of time they + are willing to wait before abandoning a connection, independent of + notifications from the TCP implementations they may be using. + +6.3. Processing Replies + + The requestor attempts to read a LEASEQUERY-REPLY message from the + TCP connection. If the TCP connection stops delivering reply data + (if the connection stops being readable), the requestor SHOULD be + prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT, and + MAY begin retry-processing if configured to do so. + + The requestor examines the LEASEQUERY-REPLY message, and determines + how to proceed. Message validation rules are specified in DHCPv6 + Leasequery [RFC5007]. If the reply contains an error status code + (carried in an OPTION_STATUS_CODE option), the requestor follows the + recommendations in [RFC5007]. A successful reply that does not + include an OPTION_CLIENT_DATA option indicates that the target server + had no bindings matching the query. + + + +Stapp Standards Track [Page 10] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + + Note: The Leasequery protocol uses the OPTION_CLIENT_LINK option as + an indicator that multiple bindings were present in response to a + single query. For Bulk Leasequery, the OPTION_CLIENT_LINK option is + not used, and MUST NOT be present in replies. + + A successful LEASEQUERY-REPLY that is returning binding data includes + an OPTION_CLIENT_DATA option and possibly additional options. If + there are additional bindings to be returned, they will be carried in + LEASEQUERY-DATA messages. Each LEASEQUERY-DATA message contains an + OPTION_CLIENT_DATA option, and possibly other options. A LEASEQUERY- + DATA message that does not contain an OPTION_CLIENT_DATA MUST be + discarded. + + A single bulk query can result in a large number of replies. For + example, a single relay agent might be responsible for routes for + thousands of clients' delegated prefixes. The requestor MUST be + prepared to receive more than one LEASEQUERY-DATA with transaction- + ids matching a single LEASEQUERY message. + + The LEASEQUERY-DONE message ends a successful Bulk Leasequery request + that returned at least one binding. A LEASEQUERY-REPLY without any + bindings MUST NOT be followed by a LEASEQUERY-DONE message for the + same transaction-id. After receiving LEASEQUERY-DONE from a server, + the requestor MAY close the TCP connection to that server. If the + transaction-id in the LEASEQUERY-DONE does not match an outstanding + LEASEQUERY message, the client MUST close the TCP connection. + +6.3.1. Reply Completion + + The reply to a Bulk Leasequery request is complete (i.e., no further + messages for that request transaction-id will be received) when one + of these conditions is met: + + 1. if the LEASEQUERY-REPLY message had no OPTION_CLIENT_DATA option, + when the LEASEQUERY-REPLY is received, + + 2. else if the LEASEQUERY-REPLY did have an OPTION_CLIENT_DATA, when + the corresponding LEASEQUERY-DONE message is received, + + 3. else when the connection is closed. + +6.4. Querying Multiple Servers + + A Bulk Leasequery client MAY be configured to attempt to connect to + and query from multiple DHCPv6 servers in parallel. The DHCPv6 + Leasequery specification [RFC5007] includes a discussion about + reconciling binding data received from multiple DHCPv6 servers. + + + + +Stapp Standards Track [Page 11] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + +6.5. Multiple Queries to a Single Server + + Bulk Leasequery clients may need to make multiple queries in order to + recover binding information. A requestor MAY use a single connection + to issue multiple queries. Each query MUST have a unique + transaction-id. A server MAY process more than one query at a time. + A server that is willing to do so MAY interleave replies to the + multiple queries within the stream of reply messages it sends. + Clients need to be aware that replies for multiple queries may be + interleaved within the stream of reply messages. Clients that are + not able to process interleaved replies (based on transaction-id) + MUST NOT send more than one query at a time. Requestors should be + aware that servers are not required to process queries in parallel, + and that servers are likely to limit the rate at which they process + queries from any one requestor. + +6.5.1. Example + + This example illustrates what a series of queries and responses might + look like. This is only an example -- there is no requirement that + this sequence must be followed, or that clients or servers must + support parallel queries. + + In the example session, the client sends four queries after + establishing a connection; "xid" denotes a transaction-id in the + diagram. Query 1 results in a failure; query 2 succeeds and the + stream of replies concludes before the client issues any new query. + Query 3 and query 4 overlap, and the server interleaves its replies + to those two queries. + + + + + + + + + + + + + + + + + + + + + + +Stapp Standards Track [Page 12] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + + Client Server + ------ ------ + LEASEQUERY xid 1 -----> + <----- LEASEQUERY-REPLY xid 1 (w/error) + LEASEQUERY xid 2 -----> + <----- LEASEQUERY-REPLY xid 2 + <----- LEASEQUERY-DATA xid 2 + <----- LEASEQUERY-DATA xid 2 + <----- LEASEQUERY-DONE xid 2 + LEASEQUERY xid 3 -----> + LEASEQUERY xid 4 -----> + <----- LEASEQUERY-REPLY xid 4 + <----- LEASEQUERY-DATA xid 4 + <----- LEASEQUERY-REPLY xid 3 + <----- LEASEQUERY-DATA xid 4 + <----- LEASEQUERY-DATA xid 3 + <----- LEASEQUERY-DONE xid 3 + <----- LEASEQUERY-DATA xid 4 + <----- LEASEQUERY-DONE xid 4 + +6.6. Closing Connections + + The requestor MAY close its end of the TCP connection after sending a + LEASEQUERY message to the server. The requestor MAY choose to retain + the connection if it intends to issue additional queries. Note that + this client behavior does not guarantee that the connection will be + available for additional queries: the server might decide to close + the connection based on its own configuration. + +7. Server Behavior + +7.1. Accepting Connections + + Servers that implement DHCPv6 Bulk Leasequery listen for incoming TCP + connections. Port numbers are discussed in Section 5.6. Servers + MUST be able to limit the number of currently accepted and active + connections. The value BULK_LQ_MAX_CONNS MUST be the default; + implementations MAY permit the value to be configurable. + + Servers MAY restrict Bulk Leasequery connections and LEASEQUERY + messages to certain clients. Connections that are not from permitted + clients SHOULD BE closed immediately, to avoid server connection + resource exhaustion. Servers MAY restrict some clients to certain + query types. Servers MAY reply to queries that are not permitted + with the NotAllowed status code [RFC5007], and/or close the + connection. + + + + + +Stapp Standards Track [Page 13] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + + If the TCP connection becomes blocked while the server is accepting a + connection or reading a query, it SHOULD be prepared to terminate the + connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation + to allow Servers to control the period of time they are willing to + wait before abandoning an inactive connection, independent of the TCP + implementations they may be using. + +7.2. Forming Replies + + The DHCPv6 Leasequery [RFC5007] specification describes the initial + construction of LEASEQUERY-REPLY messages and the processing of + QUERY_BY_ADDRESS and QUERY_BY_CLIENTID. Use of the LEASEQUERY-REPLY + and LEASEQUERY-DATA messages to carry multiple bindings is described + in Section 5.2. Message transmission and framing for TCP is + described in Section 5.1. If the connection becomes blocked while + the server is attempting to send reply messages, the server SHOULD be + prepared to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT. + + If the server encounters an error during initial query processing, + before any reply has been sent, it SHOULD send a LEASEQUERY-REPLY + containing an error code in an OPTION_STATUS_CODE option. This + signals to the requestor that no data will be returned. If the + server encounters an error while processing a query that has already + resulted in one or more reply messages, the server SHOULD send a + LEASEQUERY-DONE message with an error status. The server SHOULD + close its end of the connection as an indication that it was not able + to complete query processing. + + If the server does not find any bindings satisfying a query, it + SHOULD send a LEASEQUERY-REPLY without an OPTION_STATUS_CODE option + and without any OPTION_CLIENT_DATA option. Otherwise, the server + sends each binding's data in a reply message. The first reply + message is a LEASEQUERY-REPLY. The binding data is carried in an + OPTION_CLIENT_DATA option, as specified in [RFC5007] and extended + below. The server returns subsequent bindings in LEASEQUERY-DATA + messages, which can avoid redundant data (such as the requestor's + Client-ID). + + For QUERY_BY_RELAY_ID, the server locates each binding associated + with the query's Relay-ID option value. In order to give a + meaningful reply to a QUERY_BY_RELAY_ID, the server has to be able to + maintain this association in its DHCPv6 binding data. If the query's + link-address is not set to 0::0, the server only returns bindings on + links that could contain that address. If the link-address is not + 0::0 and the server cannot find any matching links, the server SHOULD + return the NotConfigured status in a LEASEQUERY-REPLY. + + + + + +Stapp Standards Track [Page 14] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + + For QUERY_BY_LINK_ADDRESS, the server locates each binding associated + with the link identified by the query's link-address value. + + For QUERY_BY_REMOTE_ID, the server locates each binding associated + with the query's Relay Remote-ID option value. In order to be able + to give meaningful replies to this query, the server has to be able + to maintain this association in its binding database. If the query + message's link-address is not set to 0::0, the server only returns + bindings on links that could contain that address. If the link- + address is not 0::0 and the server cannot find any matching links, + the server SHOULD return the NotConfigured status in a LEASEQUERY- + REPLY. + + The server sends the LEASEQUERY-DONE message as specified in + Section 5.2. + +7.3. Multiple or Parallel Queries + + As discussed in Section 6.5, requestors may want to leverage an + existing connection if they need to make multiple queries. Servers + MAY support reading and processing multiple queries from a single + connection. A server MUST NOT read more query messages from a + connection than it is prepared to process simultaneously. + + This MAY be a feature that is administratively controlled. Servers + that are able to process queries in parallel SHOULD offer + configuration that limits the number of simultaneous queries + permitted from any one requestor, in order to control resource use if + there are multiple requestors seeking service. + +7.4. Closing Connections + + The server MAY close its end of the TCP connection after sending its + last message (a LEASEQUERY-REPLY or a LEASEQUERY-DONE) in response to + a query. Alternatively, the server MAY retain the connection and + wait for additional queries from the client. The server SHOULD be + prepared to limit the number of connections it maintains, and SHOULD + be prepared to close idle connections to enforce the limit. + + The server MUST close its end of the TCP connection if it encounters + an error sending data on the connection. The server MUST close its + end of the TCP connection if it finds that it has to abort an in- + process request. A server aborting an in-process request MAY attempt + to notify its clients by using the QueryTerminated (Section 5.5) + status code. If the server detects that the client end has been + closed, the server MUST close its end of the connection after it has + finished processing any outstanding requests from the client. + + + + +Stapp Standards Track [Page 15] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + +8. Security Considerations + + The "Security Considerations" section of [RFC3315] details the + general threats to DHCPv6. The DHCPv6 Leasequery specification + [RFC5007] describes recommendations for the Leasequery protocol, + especially with regard to relayed LEASEQUERY messages, mitigation of + packet-flooding denial-of-service (DoS) attacks, restriction to + trusted clients, and use of IPsec [RFC4301]. + + The use of TCP introduces some additional concerns. Attacks that + attempt to exhaust the DHCPv6 server's available TCP connection + resources, such as SYN flooding attacks, can compromise the ability + of legitimate clients to receive service. Malicious clients who + succeed in establishing connections, but who then send invalid + queries, partial queries, or no queries at all also can exhaust a + server's pool of available connections. We recommend that servers + offer configuration to limit the sources of incoming connections, + that they limit the number of accepted connections and the number of + in-process queries from any one connection, and that they limit the + period of time during which an idle connection will be left open. + +9. IANA Considerations + + IANA has assigned a new value in the registry of DHCPv6 Option Codes: + + 53 OPTION_RELAY_ID + + IANA has assigned a new value in the registry of DHCPv6 Status Codes: + + 11 QueryTerminated + + IANA has assigned the following values in the registry of DHCPv6 + Message types: + + 16 LEASEQUERY-DONE + 17 LEASEQUERY-DATA + + IANA has assigned the following values in the registry of query-types + for the DHCPv6 OPTION_LQ_QUERY option: + + 3 QUERY_BY_RELAY_ID + 4 QUERY_BY_LINK_ADDRESS + 5 QUERY_BY_REMOTE_ID + + The above-mentioned registries are available from + http://www.iana.org. + + + + + +Stapp Standards Track [Page 16] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + +10. Acknowledgments + + Many of the ideas in this document were originally proposed by Kim + Kinnear, Richard Johnson, Hemant Singh, Ole Troan, and Bernie Volz. + Further suggestions and improvements were made by participants in the + DHC working group, including John Brzozowski, Marcus Goller, Alfred + Hoenes, Ted Lemon, Bud Millwood, and Thomas Narten. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, + August 2006. + + [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, + "DHCPv6 Leasequery", RFC 5007, September 2007. + +11.2. Informative References + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap + for Transmission Control Protocol (TCP) Specification + Documents", RFC 4614, September 2006. + + + + + + + + + + + + + +Stapp Standards Track [Page 17] + +RFC 5460 DHCPv6 Bulk Leasequery February 2009 + + +Author's Address + + Mark Stapp + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxborough, MA 01719 + USA + + Phone: +1 978 936 0000 + EMail: mjs@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stapp Standards Track [Page 18] + |