draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt   rfc5460.txt 
DHC M. Stapp Network Working Group M. Stapp
Internet-Draft Cisco Systems, Inc. Request for Comments: 5460 Cisco Systems, Inc.
Intended status: Standards Track January 13, 2009 Category: Standards Track February 2009
Expires: July 17, 2009
DHCPv6 Bulk Leasequery DHCPv6 Bulk Leasequery
draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 17, 2009. 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 Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been
extended with a Leasequery capability that allows a client to request extended with a Leasequery capability that allows a client to request
information about DHCPv6 bindings. That mechanism is limited to information about DHCPv6 bindings. That mechanism is limited to
queries for individual bindings. In some situations individual queries for individual bindings. In some situations individual
binding queries may not be efficient, or even possible. This binding queries may not be efficient, or even possible. This
document expands on the Leasequery protocol, adding new query types document expands on the Leasequery protocol, adding new query types
and allowing for bulk transfer of DHCPv6 binding data via TCP. and allowing for bulk transfer of DHCPv6 binding data via TCP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Interaction Between UDP Leasequery and Bulk Leasequery . . . . 5 4. Interaction between UDP Leasequery and Bulk Leasequery . . . . 5
5. Message and Option Definitions . . . . . . . . . . . . . . . . 6 5. Message and Option Definitions . . . . . . . . . . . . . . . . 6
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 6 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 6
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. LEASEQUERY-DATA . . . . . . . . . . . . . . . . . . . 7 5.2.1. LEASEQUERY-DATA . . . . . . . . . . . . . . . . . . . 7
5.2.2. LEASEQUERY-DONE . . . . . . . . . . . . . . . . . . . 7 5.2.2. LEASEQUERY-DONE . . . . . . . . . . . . . . . . . . . 7
5.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 7
5.3.1. QUERY_BY_RELAY_ID . . . . . . . . . . . . . . . . . . 7 5.3.1. QUERY_BY_RELAY_ID . . . . . . . . . . . . . . . . . . 7
5.3.2. QUERY_BY_LINK_ADDRESS . . . . . . . . . . . . . . . . 8 5.3.2. QUERY_BY_LINK_ADDRESS . . . . . . . . . . . . . . . . 8
5.3.3. QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . 8 5.3.3. QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . 8
5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4.1. Relay-ID Option . . . . . . . . . . . . . . . . . . . 8 5.4.1. Relay-ID Option . . . . . . . . . . . . . . . . . . . 8
5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 9
5.6. Connection and Transmission Parameters . . . . . . . . . . 9 5.6. Connection and Transmission Parameters . . . . . . . . . . 9
6. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 10 6. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Connecting . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Connecting . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Forming Queries . . . . . . . . . . . . . . . . . . . . . 10 6.2. Forming Queries . . . . . . . . . . . . . . . . . . . . . 10
6.3. Processing Replies . . . . . . . . . . . . . . . . . . . . 10 6.3. Processing Replies . . . . . . . . . . . . . . . . . . . . 10
6.3.1. Reply Completion . . . . . . . . . . . . . . . . . . . 11 6.3.1. Reply Completion . . . . . . . . . . . . . . . . . . . 11
6.4. Querying Multiple Servers . . . . . . . . . . . . . . . . 12 6.4. Querying Multiple Servers . . . . . . . . . . . . . . . . 11
6.5. Multiple Queries to a Single Server . . . . . . . . . . . 12 6.5. Multiple Queries to a Single Server . . . . . . . . . . . 12
6.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12 6.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 13 6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 13
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 13 7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 13
7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 14 7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 14
7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 15 7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 15
7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 15 7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The DHCPv6 [RFC3315] protocol specifies a mechanism for the The DHCPv6 [RFC3315] protocol specifies a mechanism for the
assignment of IPv6 address and configuration information to IPv6 assignment of IPv6 address and configuration information to IPv6
nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a nodes. IPv6 Prefix Delegation (PD) for DHCPv6 [RFC3633] specifies a
mechanism for DHCPv6 delegation of IPv6 prefixes and related data. mechanism for DHCPv6 delegation of IPv6 prefixes and related data.
DHCPv6 servers maintain authoritative information including binding DHCPv6 servers maintain authoritative information including binding
information for delegated IPv6 prefixes. information for delegated IPv6 prefixes.
The client of a PD binding is typically a router, which then The client of a PD binding is typically a router, which then
advertises the delegated prefix to locally-connected hosts. The advertises the delegated prefix to locally-connected hosts. The
delegated IPv6 prefix must be routeable in order to be useful. 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 actual DHCPv6 PD client may not be permitted to inject routes into
the delegating network. In service-provider (SP) networks, for the delegating network. In service-provider (SP) networks, for
example, an edge router typically acts as a DHCPv6 relay agent, and example, an edge router typically acts as a DHCPv6 relay agent, and
this edge router often has the responsibility to maintain routes this edge router often has the responsibility to maintain routes
within the service-provider network for clients' PD bindings. within the service-provider network for clients' PD bindings.
A DHCPv6 relay with this responsibility requires a means to recover A DHCPv6 relay with this responsibility requires a means to recover
binding information from the authoritative DHCPv6 server(s) in the binding information from the authoritative DHCPv6 server(s) in the
event of replacement or reboot, in order to restore routeability to event of replacement or reboot, in order to restore routeability to
delegated prefixes. The relay may be a network device without delegated prefixes. The relay may be a network device without
adequate local storage to maintain the necessary binding-to-route adequate local storage to maintain the necessary binding-to-route
data. A DHCPv6 Leasequery protocol [RFC5007] has been developed that data. A DHCPv6 Leasequery protocol [RFC5007] has been developed that
allows queries for individual bindings from the authoritative DHCPv6 allows queries for individual bindings from the authoritative DHCPv6
Server(s). The individual query mechanism is only useable when the server(s). The individual query mechanism is only useable when the
target binding is known to the requestor, such as upon receipt of target binding is known to the requestor, such as upon receipt of
traffic. In the case of DHCPv6 Prefix Delegation, the PD binding traffic. In the case of DHCPv6 Prefix Delegation, the PD binding
data may need to be known before any traffic arrives from the client 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 router. The DHCPv6 relay router may not be able to form individual
queries in such cases. queries in such cases.
This document extends the DHCPv6 Leasequery protocol to add support This document extends the DHCPv6 Leasequery protocol to add support
for queries that address these requirements. At the SP edge there for queries that address these requirements. At the SP edge there
may be many thousands of delegated prefixes per relay, so we specify may be many thousands of delegated prefixes per relay, so we specify
the use of TCP [RFC4614] for efficiency of data transfer. We specify the use of TCP [RFC4614] for efficiency of data transfer. We specify
skipping to change at page 4, line 13 skipping to change at page 4, line 13
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
DHCPv6 terminology is defined in [RFC3315]. DHCPv6 Leasequery DHCPv6 terminology is defined in [RFC3315]. DHCPv6 Leasequery
terminology is defined in [RFC5007]. terminology is defined in [RFC5007].
3. Protocol Overview 3. Protocol Overview
The Bulk Leasequery mechanism is modeled on the existing individual The Bulk Leasequery mechanism is modeled on the existing individual
Leasequery protocol in [RFC5007]; most differences arise from the use Leasequery protocol in [RFC5007]; most differences arise from the use
of TCP. A Bulk Leasequery client opens a TCP connection to a DHCPv6 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 server, using the DHCPv6 port 547. Note that this implies that the
Leasequery client has server IP address(es) available via Leasequery client has server IP address(es) available via
configuration or some other means, and that it has unicast IP configuration or some other means, and that it has unicast IP
reachability to the server. No relaying for bulk leasequery is reachability to the server. No relaying for bulk leasequery is
specified. specified.
After establishing a connection, the client sends a LEASEQUERY After establishing a connection, the client sends a LEASEQUERY
message containing a query-type and data about bindings it is message containing a query-type and data about bindings it is
interested in. The server uses the query-type and the data to interested in. The server uses the query-type and the data to
identify any relevant bindings. In order to support some query- identify any relevant bindings. In order to support some query-
types, servers may have to maintain additional data structures or be types, servers may have to maintain additional data structures or be
skipping to change at page 5, line 16 skipping to change at page 5, line 16
bindings associated with a specific relay; the relay is identified bindings associated with a specific relay; the relay is identified
by a DUID carried in a Relay-ID option. by a DUID carried in a Relay-ID option.
Query by Link Address - This query asks a server for the bindings on 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 a particular network segment; the link is specified in the query's
link-address field. link-address field.
Query by Remote ID - This query asks a server for the bindings Query by Remote ID - This query asks a server for the bindings
associated with a Relay Agent Remote-ID option [RFC4649] value. associated with a Relay Agent Remote-ID option [RFC4649] value.
4. Interaction Between UDP Leasequery and Bulk Leasequery 4. Interaction between UDP Leasequery and Bulk Leasequery
Bulk Leasequery can be seen as an extension of the existing UDP Bulk Leasequery can be seen as an extension of the existing UDP
Leasequery protocol [RFC5007]. This section tries to clarify the Leasequery protocol [RFC5007]. This section tries to clarify the
relationship between the two protocols. relationship between the two protocols.
The query-types introduced in the UDP Leasequery protocol can be used The query-types introduced in the UDP Leasequery protocol can be used
in the Bulk Leasequery protocol. One change in behavior is in the Bulk Leasequery protocol. One change in behavior is
introduced when Bulk Leasequery is used. [RFC5007], in sections 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 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 LEASEQUERY-REPLY messages in cases where multiple bindings were
skipping to change at page 7, line 11 skipping to change at page 7, line 11
the server is returning binding data, the LEASEQUERY-REPLY also the server is returning binding data, the LEASEQUERY-REPLY also
contains the first client's binding data in an OPTION_CLIENT_DATA contains the first client's binding data in an OPTION_CLIENT_DATA
option. option.
5.2.1. LEASEQUERY-DATA 5.2.1. LEASEQUERY-DATA
The LEASEQUERY-DATA message carries data about a single DHCPv6 The LEASEQUERY-DATA message carries data about a single DHCPv6
client's leases and/or PD bindings on a single link. The purpose of 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 the message is to reduce redundant data when there are multiple
bindings to be sent. The LEASEQUERY-DATA message MUST be preceded by bindings to be sent. The LEASEQUERY-DATA message MUST be preceded by
a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY conveys the query's a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY carries the query's
status, carries the Leasequery's Client-ID and Server-ID options, and status, the Leasequery's Client-ID and Server-ID options, and the
carries the first client's binding data if the query was successful. first client's binding data if the query was successful.
LEASEQUERY-DATA MUST ONLY be sent in response to a 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. 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 The LEASEQUERY-DATA message's transaction-id field MUST match the
transaction-id of the LEASEQUERY request message. The Server-ID, transaction-id of the LEASEQUERY request message. The Server-ID,
Client-ID, and OPTION_STATUS_CODE options SHOULD NOT be included: Client-ID, and OPTION_STATUS_CODE options SHOULD NOT be included:
that data should be constant for any one Bulk Leasequery reply, and that data should be constant for any one Bulk Leasequery reply, and
should have been conveyed in the LEASEQUERY-REPLY message. should have been conveyed in the LEASEQUERY-REPLY message.
5.2.2. LEASEQUERY-DONE 5.2.2. LEASEQUERY-DONE
skipping to change at page 7, line 44 skipping to change at page 7, line 44
A server may encounter an error condition after it has sent the A server may encounter an error condition after it has sent the
initial LEASEQUERY-REPLY. In that case, it SHOULD attempt to send a initial LEASEQUERY-REPLY. In that case, it SHOULD attempt to send a
LEASEQUERY-DONE with an OPTION_STATUS_CODE option indicating the LEASEQUERY-DONE with an OPTION_STATUS_CODE option indicating the
error condition to the requestor. Other DHCPv6 options SHOULD NOT be error condition to the requestor. Other DHCPv6 options SHOULD NOT be
included in the LEASEQUERY-DONE message. included in the LEASEQUERY-DONE message.
5.3. Query Types 5.3. Query Types
The OPTION_LQ_QUERY option is defined in [RFC5007]. We introduce the The OPTION_LQ_QUERY option is defined in [RFC5007]. We introduce the
following new query-types: QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, following new query-types: QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS,
QUERY_BY_REMOTE_ID. These queries are designed to assist relay and QUERY_BY_REMOTE_ID. These queries are designed to assist relay
agents in recovering binding data in circumstances where some or all agents in recovering binding data in circumstances where some or all
of the relay's binding data has been lost. of the relay's binding data has been lost.
5.3.1. QUERY_BY_RELAY_ID 5.3.1. QUERY_BY_RELAY_ID
This query asks the server to return bindings associated with the This query asks the server to return bindings associated with the
specified relay DUID. specified relay DUID.
QUERY_BY_RELAY_ID - The query-options MUST contain an QUERY_BY_RELAY_ID - The query-options MUST contain an
OPTION_RELAY_ID option. If the link-address field is 0::0, the OPTION_RELAY_ID option. If the link-address field is 0::0, the
query asks for all bindings associated with the specified relay query asks for all bindings associated with the specified relay
DUID. If the link-address is specified, the query asks for DUID. If the link-address is specified, the query asks for
bindings on that link. bindings on that link.
5.3.2. QUERY_BY_LINK_ADDRESS 5.3.2. QUERY_BY_LINK_ADDRESS
The QUERY_BY_LINK_ADDRESS asks the server to return bindings on a The QUERY_BY_LINK_ADDRESS asks the server to return bindings on a
network segment identified by an link-address value from a relay's network segment identified by a link-address value from a relay's
Relay-Forward message. Relay-Forward message.
QUERY_BY_LINK_ADDRESS - The query's link-address contains an QUERY_BY_LINK_ADDRESS - The query's link-address contains an
address a relay may have used in the link-address of a Relay- address a relay may have used in the link-address of a Relay-
Forward message. The Server attempts to locate bindings on the Forward message. The Server attempts to locate bindings on the
same network segment as the link-address. same network segment as the link-address.
5.3.3. QUERY_BY_REMOTE_ID 5.3.3. QUERY_BY_REMOTE_ID
The QUERY_BY_REMOTE_ID asks the server to return bindings associated The QUERY_BY_REMOTE_ID asks the server to return bindings associated
skipping to change at page 9, line 6 skipping to change at page 9, line 5
The Relay-ID option carries a DUID [RFC3315]. A relay agent MAY The Relay-ID option carries a DUID [RFC3315]. A relay agent MAY
include the option in Relay-Forward messages it sends. Obviously, it 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 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 queries unless the relay agent has included this option. A relay
SHOULD be able to generate a DUID for this purpose, and capture the 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 result in stable storage. A relay SHOULD also allow the DUID value
to be configurable: doing so allows an administrator to replace a to be configurable: doing so allows an administrator to replace a
relay agent while retaining the association between the relay and relay agent while retaining the association between the relay and
existing DHCPv6 bindings. existing DHCPv6 bindings.
A DHCPv6 Server MAY associate Relay-ID options from Relay-Forward A DHCPv6 server MAY associate Relay-ID options from Relay-Forward
messages it processes with prefix delegations and/or lease bindings messages it processes with prefix delegations and/or lease bindings
that result. Doing so allows it to respond to QUERY_BY_RELAY_ID that result. Doing so allows it to respond to QUERY_BY_RELAY_ID
Leasequeries. Leasequeries.
The format of the Relay-ID option is shown below: The format of the Relay-ID option is shown below:
0 1 2 3 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 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 | | OPTION_RELAY_ID | option-len |
skipping to change at page 9, line 34 skipping to change at page 9, line 33
option-code OPTION_RELAY_ID. option-code OPTION_RELAY_ID.
option-len Length of DUID in octets. option-len Length of DUID in octets.
DUID The DUID for the relay agent. DUID The DUID for the relay agent.
5.5. Status Codes 5.5. Status Codes
QueryTerminated - Indicates that the server is unable to perform a QueryTerminated - Indicates that the server is unable to perform a
query or has prematurely terminated the query for some reason (which query or has prematurely terminated the query for some reason (which
should be communicated in the text message). This may be because the should be communicated in the text of the message). This may be
server is short of resources or is being shut down. The requestor because the server is short of resources or is being shut down. The
may retry the query at a later time. The requestor should wait at requestor may retry the query at a later time. The requestor should
least a short interval before retrying. Note that while a server may wait at least a short interval before retrying. Note that while a
simply prematurely close its end of the connection, it is preferable server may simply prematurely close its end of the connection, it is
for the server to send a LEASEQUERY-REPLY or LEASEQUERY-DONE with preferable for the server to send a LEASEQUERY-REPLY or LEASEQUERY-
this status-code to notify the requestor of the condition. DONE with this status-code to notify the requestor of the condition.
5.6. Connection and Transmission Parameters 5.6. Connection and Transmission Parameters
DHCPv6 Servers that support Bulk Leasequery SHOULD listen for DHCPv6 servers that support Bulk Leasequery SHOULD listen for
incoming TCP connections on the DHCPv6 server port 547. incoming TCP connections on the DHCPv6 server port 547.
Implementations MAY offer to make the incoming port configurable, but Implementations MAY offer to make the incoming port configurable, but
port 547 MUST be the default. Client implementations SHOULD make TCP port 547 MUST be the default. Client implementations SHOULD make TCP
connections to port 547, and MAY offer to make the destination server connections to port 547, and MAY offer to make the destination server
port configurable. port configurable.
This section presents a table of values used to control Bulk This section presents a table of values used to control Bulk
Leasequery behavior, including recommended defaults. Implementations Leasequery behavior, including recommended defaults. Implementations
MAY make these values configurable. However, configuring too-small MAY make these values configurable. However, configuring too-small
timeout values may lead to harmful behavior both to this application timeout values may lead to harmful behavior both to this application
as well as to other traffic in the network. As a result, timeout as well as to other traffic in the network. As a result, timeout
values smaller than the default values are NOT RECOMMENDED. values smaller than the default values are NOT RECOMMENDED.
Parameter Default Description Parameter Default Description
------------------------------------------- -------------------------------------------
BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout BULK_LQ_DATA_TIMEOUT 300 s Bulk Leasequery data timeout
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
6. Requestor Behavior 6. Requestor Behavior
6.1. Connecting 6.1. Connecting
A Requestor attempts to establish a TCP connection to a DHCPv6 Server A requestor attempts to establish a TCP connection to a DHCPv6 server
in order to initiate a Leasequery exchange. If the attempt fails, in order to initiate a Leasequery exchange. If the attempt fails,
the Requestor MAY retry. the requestor MAY retry.
6.2. Forming Queries 6.2. Forming Queries
After a connection is established, the Requestor constructs a After a connection is established, the requestor constructs a
Leasequery message, as specified in [RFC5007]. The query may have Leasequery message, as specified in [RFC5007]. The query may have
any of the defined query-types, and includes the options and data any of the defined query-types, and includes the options and data
required by the query-type chosen. The Requestor sends the message required by the query-type chosen. The requestor sends the message
size then sends the actual DHCPv6 message, as described in size then sends the actual DHCPv6 message, as described in
Section 5.1. Section 5.1.
If the TCP connection becomes blocked or stops being writeable while If the TCP connection becomes blocked or stops being writeable while
the Requestor is sending its query, the Requestor SHOULD be prepared the requestor is sending its query, the requestor SHOULD be prepared
to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this
recommendation to allow Requestors to control the period of time they recommendation to allow requestors to control the period of time they
are willing to wait before abandoning a connection, independent of are willing to wait before abandoning a connection, independent of
notifications from the TCP implementations they may be using. notifications from the TCP implementations they may be using.
6.3. Processing Replies 6.3. Processing Replies
The Requestor attempts to read a LEASEQUERY-REPLY message from the The requestor attempts to read a LEASEQUERY-REPLY message from the
TCP connection. If the TCP connection stops delivering reply data TCP connection. If the TCP connection stops delivering reply data
(if the connection stops being readable), the Requestor SHOULD be (if the connection stops being readable), the requestor SHOULD be
prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT, and prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT, and
MAY begin retry processing if configured to do so. MAY begin retry-processing if configured to do so.
The Requestor examines the LEASEQUERY-REPLY message, and determines The requestor examines the LEASEQUERY-REPLY message, and determines
how to proceed. Message validation rules are specified in DHCPv6 how to proceed. Message validation rules are specified in DHCPv6
Leasequery [RFC5007]. If the reply contains an error status code Leasequery [RFC5007]. If the reply contains an error status code
(carried in an OPTION_STATUS_CODE option), the Requestor follows the (carried in an OPTION_STATUS_CODE option), the requestor follows the
recommendations in [RFC5007]. A successful reply that does not recommendations in [RFC5007]. A successful reply that does not
include an OPTION_CLIENT_DATA option indicates that the target server include an OPTION_CLIENT_DATA option indicates that the target server
had no bindings matching the query. had no bindings matching the query.
Note: The Leasequery protocol uses the OPTION_CLIENT_LINK option as Note: The Leasequery protocol uses the OPTION_CLIENT_LINK option as
an indicator that multiple bindings were present in response to a an indicator that multiple bindings were present in response to a
single query. For Bulk Leasequery, the OPTION_CLIENT_LINK option is single query. For Bulk Leasequery, the OPTION_CLIENT_LINK option is
not used, and MUST NOT be present in replies. not used, and MUST NOT be present in replies.
A successful LEASEQUERY-REPLY that is returning binding data includes A successful LEASEQUERY-REPLY that is returning binding data includes
an OPTION_CLIENT_DATA option and possibly additional options. If an OPTION_CLIENT_DATA option and possibly additional options. If
there are additional bindings to be returned, they will be carried in there are additional bindings to be returned, they will be carried in
LEASEQUERY-DATA messages. Each LEASEQUERY-DATA message contains an LEASEQUERY-DATA messages. Each LEASEQUERY-DATA message contains an
OPTION_CLIENT_DATA option, and possibly other options. A LEASEQUERY- OPTION_CLIENT_DATA option, and possibly other options. A LEASEQUERY-
DATA message that does not contain an OPTION_CLIENT_DATA MUST be DATA message that does not contain an OPTION_CLIENT_DATA MUST be
discarded. discarded.
A single bulk query can result in a large number of replies. For A single bulk query can result in a large number of replies. For
example, a single relay agent might be responsible for routes for example, a single relay agent might be responsible for routes for
thousands of clients' delegated prefixes. The Requestor MUST be thousands of clients' delegated prefixes. The requestor MUST be
prepared to receive more than one LEASEQUERY-DATA with transaction- prepared to receive more than one LEASEQUERY-DATA with transaction-
ids matching a single LEASEQUERY message. ids matching a single LEASEQUERY message.
The LEASEQUERY-DONE message ends a successful Bulk Leasequery request The LEASEQUERY-DONE message ends a successful Bulk Leasequery request
that returned at least one binding. A LEASEQUERY-REPLY without any that returned at least one binding. A LEASEQUERY-REPLY without any
bindings MUST NOT be followed by a LEASEQUERY-DONE message for the bindings MUST NOT be followed by a LEASEQUERY-DONE message for the
same transaction-id. After receiving LEASEQUERY-DONE from a server, same transaction-id. After receiving LEASEQUERY-DONE from a server,
the Requestor MAY close the TCP connection to that server. If the the requestor MAY close the TCP connection to that server. If the
transaction-id in the LEASEQUERY-DONE does not match an outstanding transaction-id in the LEASEQUERY-DONE does not match an outstanding
LEASEQUERY message, the client MUST close the TCP connection. LEASEQUERY message, the client MUST close the TCP connection.
6.3.1. Reply Completion 6.3.1. Reply Completion
The reply to a Bulk Leasequery request is complete (i.e., no further The reply to a Bulk Leasequery request is complete (i.e., no further
messages for that request transaction-id will be received) when one messages for that request transaction-id will be received) when one
of these conditions is met: of these conditions is met:
1. if the LEASEQUERY-REPLY message had no OPTION_CLIENT_DATA option, 1. if the LEASEQUERY-REPLY message had no OPTION_CLIENT_DATA option,
skipping to change at page 12, line 15 skipping to change at page 12, line 8
6.4. Querying Multiple Servers 6.4. Querying Multiple Servers
A Bulk Leasequery client MAY be configured to attempt to connect to A Bulk Leasequery client MAY be configured to attempt to connect to
and query from multiple DHCPv6 servers in parallel. The DHCPv6 and query from multiple DHCPv6 servers in parallel. The DHCPv6
Leasequery specification [RFC5007] includes a discussion about Leasequery specification [RFC5007] includes a discussion about
reconciling binding data received from multiple DHCPv6 servers. reconciling binding data received from multiple DHCPv6 servers.
6.5. Multiple Queries to a Single Server 6.5. Multiple Queries to a Single Server
Bulk Leasequery clients may need to make multiple queries in order to Bulk Leasequery clients may need to make multiple queries in order to
recover binding information. A Requestor MAY use a single connection recover binding information. A requestor MAY use a single connection
to issue multiple queries. Each query MUST have a unique transaction to issue multiple queries. Each query MUST have a unique
id. A server MAY process more than one query at a time. A server transaction-id. A server MAY process more than one query at a time.
that is willing to do so MAY interleave replies to the multiple A server that is willing to do so MAY interleave replies to the
queries within the stream of reply messages it sends. Clients need multiple queries within the stream of reply messages it sends.
to be aware that replies for multiple queries may be interleaved Clients need to be aware that replies for multiple queries may be
within the stream of reply messages. Clients that are not able to interleaved within the stream of reply messages. Clients that are
process interleaved replies (based on transaction-id) MUST NOT send not able to process interleaved replies (based on transaction-id)
more than one query at a time. Requestors should be aware that MUST NOT send more than one query at a time. Requestors should be
servers are not required to process queries in parallel, and that aware that servers are not required to process queries in parallel,
servers are likely to limit the rate at which they process queries and that servers are likely to limit the rate at which they process
from any one Requestor. queries from any one requestor.
6.5.1. Example 6.5.1. Example
This example illustrates what a series of queries and responses might This example illustrates what a series of queries and responses might
look like. This is only an example - there is no requirement that look like. This is only an example -- there is no requirement that
this sequence must be followed, or that clients or servers must this sequence must be followed, or that clients or servers must
support parallel queries. support parallel queries.
In the example session, the client sends four queries after In the example session, the client sends four queries after
establishing a connection; "xid" denotes a transaction-id in the establishing a connection; "xid" denotes a transaction-id in the
diagram. Query 1 results in a failure; query 2 succeeds and the diagram. Query 1 results in a failure; query 2 succeeds and the
stream of replies concludes before the client issues any new query. stream of replies concludes before the client issues any new query.
Query 3 and query 4 overlap, and the server interleaves its replies Query 3 and query 4 overlap, and the server interleaves its replies
to those two queries. to those two queries.
skipping to change at page 13, line 27 skipping to change at page 13, line 27
<----- LEASEQUERY-DATA xid 4 <----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-REPLY xid 3 <----- LEASEQUERY-REPLY xid 3
<----- LEASEQUERY-DATA xid 4 <----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-DATA xid 3 <----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DONE xid 3 <----- LEASEQUERY-DONE xid 3
<----- LEASEQUERY-DATA xid 4 <----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-DONE xid 4 <----- LEASEQUERY-DONE xid 4
6.6. Closing Connections 6.6. Closing Connections
The Requestor MAY close its end of the TCP connection after sending a The requestor MAY close its end of the TCP connection after sending a
LEASEQUERY message to the server. The Requestor MAY choose to retain LEASEQUERY message to the server. The requestor MAY choose to retain
the connection if it intends to issue additional queries. Note that the connection if it intends to issue additional queries. Note that
this client behavior does not guarantee that the connection will be this client behavior does not guarantee that the connection will be
available for additional queries: the server might decide to close available for additional queries: the server might decide to close
the connection based on its own configuration. the connection based on its own configuration.
7. Server Behavior 7. Server Behavior
7.1. Accepting Connections 7.1. Accepting Connections
Servers that implement DHCPv6 Bulk Leasequery listen for incoming TCP Servers that implement DHCPv6 Bulk Leasequery listen for incoming TCP
connections. Port numbers are discussed in Section 5.6. Servers connections. Port numbers are discussed in Section 5.6. Servers
MUST be able to limit the number of currently accepted and active MUST be able to limit the number of currently accepted and active
connections. The value BULK_LQ_MAX_CONNS MUST be the default; connections. The value BULK_LQ_MAX_CONNS MUST be the default;
implementations MAY permit the value to be configurable. implementations MAY permit the value to be configurable.
Servers MAY restrict Bulk Leasequery connections and LEASEQUERY Servers MAY restrict Bulk Leasequery connections and LEASEQUERY
messages to certain clients. Connections not from permitted clients messages to certain clients. Connections that are not from permitted
SHOULD BE closed immediately, to avoid server connection resource clients SHOULD BE closed immediately, to avoid server connection
exhaustion. Servers MAY restrict some clients to certain query resource exhaustion. Servers MAY restrict some clients to certain
types. Servers MAY reply to queries that are not permitted with the query types. Servers MAY reply to queries that are not permitted
NotAllowed status code [RFC5007], and/or close the connection. with the NotAllowed status code [RFC5007], and/or close the
connection.
If the TCP connection becomes blocked while the server is accepting a 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 or reading a query, it SHOULD be prepared to terminate the
connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation
to allow Servers to control the period of time they are willing to to allow Servers to control the period of time they are willing to
wait before abandoning an inactive connection, independent of the TCP wait before abandoning an inactive connection, independent of the TCP
implementations they may be using. implementations they may be using.
7.2. Forming Replies 7.2. Forming Replies
The DHCPv6 Leasequery [RFC5007] specification describes the initial The DHCPv6 Leasequery [RFC5007] specification describes the initial
construction of LEASEQUERY-REPLY messages and the processing of construction of LEASEQUERY-REPLY messages and the processing of
QUERY_BY_ADDRESS and QUERY_BY_CLIENTID. Use of the LEASEQUERY-REPLY QUERY_BY_ADDRESS and QUERY_BY_CLIENTID. Use of the LEASEQUERY-REPLY
and LEASEQUERY-DATA messages to carry multiple bindings are described and LEASEQUERY-DATA messages to carry multiple bindings is described
in Section 5.2. Message transmission and framing for TCP is in Section 5.2. Message transmission and framing for TCP is
described in Section 5.1. If the connection becomes blocked while described in Section 5.1. If the connection becomes blocked while
the server is attempting to send reply messages, the server SHOULD be the server is attempting to send reply messages, the server SHOULD be
prepared to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT. prepared to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT.
If the server encounters an error during initial query processing, If the server encounters an error during initial query processing,
before any reply has been sent, it SHOULD send a LEASEQUERY-REPLY before any reply has been sent, it SHOULD send a LEASEQUERY-REPLY
containing an error code in an OPTION_STATUS_CODE option. This containing an error code in an OPTION_STATUS_CODE option. This
signals to the requestor that no data will be returned. If the signals to the requestor that no data will be returned. If the
server encounters an error while processing a query that has already server encounters an error while processing a query that has already
skipping to change at page 15, line 20 skipping to change at page 15, line 23
bindings on links that could contain that address. If the link- bindings on links that could contain that address. If the link-
address is not 0::0 and the server cannot find any matching links, address is not 0::0 and the server cannot find any matching links,
the server SHOULD return the NotConfigured status in a LEASEQUERY- the server SHOULD return the NotConfigured status in a LEASEQUERY-
REPLY. REPLY.
The server sends the LEASEQUERY-DONE message as specified in The server sends the LEASEQUERY-DONE message as specified in
Section 5.2. Section 5.2.
7.3. Multiple or Parallel Queries 7.3. Multiple or Parallel Queries
As discussed in Section 6.5, Requestors may want to leverage an As discussed in Section 6.5, requestors may want to leverage an
existing connection if they need to make multiple queries. Servers existing connection if they need to make multiple queries. Servers
MAY support reading and processing multiple queries from a single MAY support reading and processing multiple queries from a single
connection. A server MUST NOT read more query messages from a connection. A server MUST NOT read more query messages from a
connection than it is prepared to process simultaneously. connection than it is prepared to process simultaneously.
This MAY be a feature that is administratively controlled. Servers This MAY be a feature that is administratively controlled. Servers
that are able to process queries in parallel SHOULD offer that are able to process queries in parallel SHOULD offer
configuration that limits the number of simultaneous queries configuration that limits the number of simultaneous queries
permitted from any one Requestor, in order to control resource use if permitted from any one requestor, in order to control resource use if
there are multiple Requestors seeking service. there are multiple requestors seeking service.
7.4. Closing Connections 7.4. Closing Connections
The server MAY close its end of the TCP connection after sending its 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 last message (a LEASEQUERY-REPLY or a LEASEQUERY-DONE) in response to
a query. Alternatively, the server MAY retain the connection and a query. Alternatively, the server MAY retain the connection and
wait for additional queries from the client. The server SHOULD be wait for additional queries from the client. The server SHOULD be
prepared to limit the number of connections it maintains, and SHOULD prepared to limit the number of connections it maintains, and SHOULD
be prepared to close idle connections to enforce the limit. be prepared to close idle connections to enforce the limit.
The server MUST close its end of the TCP connection if it encounters 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 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- 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 process request. A server aborting an in-process request MAY attempt
to signal that to its clients by using the QueryTerminated to notify its clients by using the QueryTerminated (Section 5.5)
(Section 5.5) status code. If the server detects that the client end status code. If the server detects that the client end has been
has been closed, the server MUST close its end of the connection closed, the server MUST close its end of the connection after it has
after it has finished processing any outstanding requests from the finished processing any outstanding requests from the client.
client.
8. Security Considerations 8. Security Considerations
The "Security Considerations" section of [RFC3315] details the The "Security Considerations" section of [RFC3315] details the
general threats to DHCPv6. The DHCPv6 Leasequery specification general threats to DHCPv6. The DHCPv6 Leasequery specification
[RFC5007] describes recommendations for the Leasequery protocol, [RFC5007] describes recommendations for the Leasequery protocol,
especially with regard to relayed LEASEQUERY messages, mitigation of especially with regard to relayed LEASEQUERY messages, mitigation of
packet-flooding DOS attacks, restriction to trusted clients, and use packet-flooding denial-of-service (DoS) attacks, restriction to
of IPsec [RFC4301]. trusted clients, and use of IPsec [RFC4301].
The use of TCP introduces some additional concerns. Attacks that The use of TCP introduces some additional concerns. Attacks that
attempt to exhaust the DHCPv6 server's available TCP connection attempt to exhaust the DHCPv6 server's available TCP connection
resources, such as SYN flooding attacks, can compromise the ability resources, such as SYN flooding attacks, can compromise the ability
of legitimate clients to receive service. Malicious clients who of legitimate clients to receive service. Malicious clients who
succeed in establishing connections, but who then send invalid succeed in establishing connections, but who then send invalid
queries, partial queries, or no queries at all also can exhaust a queries, partial queries, or no queries at all also can exhaust a
server's pool of available connections. We recommend that servers server's pool of available connections. We recommend that servers
offer configuration to limit the sources of incoming connections, offer configuration to limit the sources of incoming connections,
that they limit the number of accepted connections and the number of that they limit the number of accepted connections and the number of
in-process queries from any one connection, and that they limit the in-process queries from any one connection, and that they limit the
period of time during which an idle connection will be left open. period of time during which an idle connection will be left open.
9. IANA Considerations 9. IANA Considerations
IANA is requested to assign a new DHCPv6 Option Code in the registry IANA has assigned a new value in the registry of DHCPv6 Option Codes:
maintained in http://www.iana.org/assignments/dhcpv6-parameters:
OPTION_RELAY_ID 53 OPTION_RELAY_ID
IANA is requested to assign a new value in the registry of DHCPv6 IANA has assigned a new value in the registry of DHCPv6 Status Codes:
Status Codes maintained in
http://www.iana.org/assignments/dhcpv6-parameters:
QueryTerminated 11 QueryTerminated
IANA is requested to assign values for the following new DHCPv6 IANA has assigned the following values in the registry of DHCPv6
Message types in the registry maintained in Message types:
http://www.iana.org/assignments/dhcpv6-parameters:
LEASEQUERY-DONE 16 LEASEQUERY-DONE
LEASEQUERY-DATA 17 LEASEQUERY-DATA
IANA is requested to assign the following new values in the registry IANA has assigned the following values in the registry of query-types
of query-types for the DHCPv6 OPTION_LQ_QUERY option: for the DHCPv6 OPTION_LQ_QUERY option:
QUERY_BY_RELAY_ID 3 QUERY_BY_RELAY_ID
QUERY_BY_LINK_ADDRESS 4 QUERY_BY_LINK_ADDRESS
QUERY_BY_REMOTE_ID 5 QUERY_BY_REMOTE_ID
10. Acknowledgements The above-mentioned registries are available from
http://www.iana.org.
10. Acknowledgments
Many of the ideas in this document were originally proposed by Kim Many of the ideas in this document were originally proposed by Kim
Kinnear, Richard Johnson, Hemant Singh, Ole Troan, and Bernie Volz. Kinnear, Richard Johnson, Hemant Singh, Ole Troan, and Bernie Volz.
Further suggestions and improvements were made by participants in the Further suggestions and improvements were made by participants in the
DHC working group, including John Brzozowski, Marcus Goller, Alfred DHC working group, including John Brzozowski, Marcus Goller, Alfred
Hoenes, Ted Lemon, Bud Millwood, and Thomas Narten. Hoenes, Ted Lemon, Bud Millwood, and Thomas Narten.
11. References 11. References
11.1. Normative References 11.1. Normative References
skipping to change at page 18, line 14 skipping to change at page 18, line 14
Author's Address Author's Address
Mark Stapp Mark Stapp
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 0000 Phone: +1 978 936 0000
Email: mjs@cisco.com EMail: mjs@cisco.com
 End of changes. 52 change blocks. 
116 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/