draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt   draft-ietf-dhc-dhcpv6-bulk-leasequery-01.txt 
DHC M. Stapp DHC M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: August 11, 2008 February 8, 2008 Expires: November 22, 2008 May 21, 2008
DHCPv6 Bulk Leasequery DHCPv6 Bulk Leasequery
draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt draft-ietf-dhc-dhcpv6-bulk-leasequery-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 11, 2008. This Internet-Draft will expire on November 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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 specifies extensions to the Leasequery protocol that add new document expands on the Leasequery protocol, adding new query types
query types and allow for bulk transfer of DHCPv6 binding data. 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 . . . . . . . . . . . . . . . . 5 5. Message and Option Definitions . . . . . . . . . . . . . . . . 5
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 5 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 6
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. LEASEQUERY-DATA . . . . . . . . . . . . . . . . . . . 6 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_RELAYID . . . . . . . . . . . . . . . . . . . 7 5.3.1. QUERY_BY_RELAYID . . . . . . . . . . . . . . . . . . . 7
5.3.2. QUERY_BY_LINK_ADDRESS . . . . . . . . . . . . . . . . 7 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.4. Querying Multiple Servers . . . . . . . . . . . . . . . . 11 6.4. Querying Multiple Servers . . . . . . . . . . . . . . . . 11
6.5. Multiple Queries to a Single Server . . . . . . . . . . . 11 6.5. Multiple Queries to a Single Server . . . . . . . . . . . 11
6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 11 6.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 12
7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 12 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 12 7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 13
7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 13 7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 13
7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 14 7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Modification History . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Modification History . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The DHCPv6 [1] protocol specifies a mechanism for the assignment of The DHCPv6 [1] protocol specifies a mechanism for the assignment of
IPv6 address and configuration information to IPv6 nodes. IPv6 IPv6 address and configuration information to IPv6 nodes. IPv6
Prefix Delegation for DHCPv6 (PD) [2] specifies a mechanism for Prefix Delegation for DHCPv6 (PD) [2] specifies a mechanism for
DHCPv6 delegation of IPv6 prefixes and related data. DHCPv6 servers DHCPv6 delegation of IPv6 prefixes and related data. DHCPv6 servers
maintain authoritative information including binding information for maintain authoritative information including binding information for
delegated IPv6 prefixes. delegated IPv6 prefixes.
skipping to change at page 3, line 31 skipping to change at page 3, line 31
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 [6] has been developed that data. A DHCPv6 Leasequery protocol [6] 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. In the case of DHCPv6 target binding is known to the requestor, such as upon receipt of
Prefix Delegation, the PD binding data may need to be known before traffic. In the case of DHCPv6 Prefix Delegation, the PD binding
any traffic arrives from the client router. The DHCPv6 relay router data may need to be known before any traffic arrives from the client
may not be able to form individual queries in such cases. 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 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 [3] for efficiency of data transfer. We specify a new the use of TCP [3] for efficiency of data transfer. We specify a new
DHCPv6 option, the Relay Identifier option, to support efficient DHCPv6 option, the Relay Identifier option, to support efficient
recovery of all data associated with a specific relay agent; we also 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 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 segment and by Remote-ID option value, to assist a relay that needs
to recover a subset of its clients' bindings. to recover a subset of its clients' bindings.
skipping to change at page 4, line 16 skipping to change at page 4, line 16
is defined in [6]. is defined in [6].
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 [6]; most differences arise from the use of Leasequery protocol in [6]; most differences arise from the use of
TCP. A Bulk Leasequery client opens a TCP connection to a DHCPv6 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. The client sends a LEASEQUERY message, reachability to the server. No relaying for bulk leasequery is
containing a query-type and data about bindings it is interested in. specified.
The server uses the query-type and the data to identify any relevant After establishing a connection, the client sends a LEASEQUERY
bindings. In order to support some query-types, servers may have to message containing a query-type and data about bindings it is
maintain additional data structures or be able to locate bindings interested in. The server uses the query-type and the data to
based on specific option data. The server replies with a LEASEQUERY- identify any relevant bindings. In order to support some query-
REPLY message, indicating the success or failure of the query. If types, servers may have to maintain additional data structures or be
the query was successful, the server includes the first client's able to locate bindings based on specific option data. The server
binding data in the LEASEQUERY-REPLY message also. If more than one replies with a LEASEQUERY-REPLY message, indicating the success or
client's bindings are being returned, the server then transmits the failure of the query. If the query was successful, the server
additional client bindings in a series of LEASEQUERY-DATA messages. includes the first client's binding data in the LEASEQUERY-REPLY
If the server has sent at least one client's bindings, it sends a message also. If more than one client's bindings are being returned,
LEASEQUERY-DONE message when it has finished sending its replies. the server then transmits the additional client bindings in a series
Each end of the TCP connection can be closed after all data has been of LEASEQUERY-DATA messages. If the server has sent at least one
sent. 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. This specification includes a new DHCPv6 option, the Relay-ID option.
The option contains a DUID identifying a DHCPv6 relay agent. Relay The option contains a DUID identifying a DHCPv6 relay agent. Relay
agents can include this option in Relay-Forward messages they send. agents can include this option in Relay-Forward messages they send.
Servers can retain the Relay-ID and associate it with bindings made 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 on behalf of the relay's clients. A relay can then recover binding
information about downstream clients by using the Relay-ID in a information about downstream clients by using the Relay-ID in a
LEASEQUERY message. The Relay-ID option is defined in Section 5.4.1. LEASEQUERY message. The Relay-ID option is defined in Section 5.4.1.
Bulk Leasequery supports the queries by IPv6 address and by Client Bulk Leasequery supports the queries by IPv6 address and by Client
DUID as specified in [6]. The Bulk Leasequery protocol also adds DUID as specified in RFC5007 [6]. The Bulk Leasequery protocol also
several new queries. The new queries introduced here cannot be used adds several new queries. The new queries introduced here cannot be
effectively with the UDP Leasequery protocol. Requestors MUST NOT used effectively with the UDP Leasequery protocol. Requestors MUST
send these new query-types in RFC5007 query messages. NOT send these new query-types in RFC5007 [6] query messages.
Query by Relay Identifier - This query asks a server for the Query by Relay Identifier - This query asks a server for the
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 [5] value. associated with a Relay Agent Remote-ID option [5] 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 [6]. This section tries to clarify the Leasequery protocol [6]. 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 permitted in the Bulk Leasequery protocol. One change in behavior is permitted
when Bulk Leasequery is used. RFC5007, in sections 4.1.2.5 and when Bulk Leasequery is used. RFC5007 [6], in sections 4.1.2.5 and
4.3.3, specifies the use of a Client Link option in LEASEQUERY-REPLY 4.3.3, specifies the use of a Client Link option in LEASEQUERY-REPLY
messages in cases where multiple bindings were found. When Bulk messages in cases where multiple bindings were found. When Bulk
Leasequery is used, this mechanism is not necessary: a server Leasequery is used, this mechanism is not necessary: a server
returning multiple bindings simply does so directly as specified in returning multiple bindings simply does so directly as specified in
this document. The Client Link option MUST NOT appear in Bulk this document. The Client Link option MUST NOT appear in Bulk
Leasequery replies. 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 new queries introduced in this specification cannot be used with
the UDP Leasequery protocol. Servers that implement this the UDP Leasequery protocol. Servers that implement this
specification and also permit UDP queries MUST NOT accept Bulk specification and also permit UDP queries MUST NOT accept Bulk
Leasequery query-types in UDP Leasequery messages. Such servers MUST Leasequery query-types in UDP Leasequery messages. Such servers MUST
respond with an error status code of NotAllowed. respond with an error status code of NotAllowed [6].
5. Message and Option Definitions 5. Message and Option Definitions
5.1. Message Framing for TCP 5.1. Message Framing for TCP
The use of TCP for the Bulk Leasequery protocol permits one or more 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 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 to determine how large each message is. Two octets containing the
message size in network byte-order are prepended to each DHCPv6 message size in network byte-order are prepended to each DHCPv6
message sent on a Bulk Leasequery TCP connection. The two message- message sent on a Bulk Leasequery TCP connection. The two message-
skipping to change at page 6, line 28 skipping to change at page 6, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
message-size the number of octets in the message that message-size the number of octets in the message that
follows, as a 16-bit integer in network follows, as a 16-bit integer in network
byte-order. byte-order.
All other fields are as specified in DHCPv6 [1]. All other fields are as specified in DHCPv6 [1].
5.2. Messages 5.2. Messages
The LEASEQUERY and LEASEQUERY-REPLY messages are defined in [6]. In The LEASEQUERY and LEASEQUERY-REPLY messages are defined in RFC5007
a Bulk Leasequery exchange, a single LEASEQUERY-REPLY message is used [6]. In a Bulk Leasequery exchange, a single LEASEQUERY-REPLY
to indicate the success or failure of a query, and to carry data that message is used to indicate the success or failure of a query, and to
do not change in the context of a single query and answer, such as carry data that do not change in the context of a single query and
the Server-ID and Client-ID options. If a query is successful, only answer, such as the Server-ID and Client-ID options. If a query is
a single LEASEQUERY-REPLY message MUST appear. If the server is successful, only a single LEASEQUERY-REPLY message MUST appear. If
returning binding data, the LEASEQUERY-REPLY also contains the first the server is returning binding data, the LEASEQUERY-REPLY also
client's binding data in an OPTION_CLIENT_DATA option. contains the first client's binding data in an OPTION_CLIENT_DATA
option.
5.2.1. LEASEQUERY-DATA 5.2.1. LEASEQUERY-DATA
The LEASEQUERY-DATA message (message type TBD) carries data about a The LEASEQUERY-DATA message (message type TBD) carries data about a
single DHCPv6 client's leases and/or PD bindings on a single link. 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 The purpose of the message is to reduce redundant data when there are
multiple bindings to be sent. The LEASEQUERY-DATA message MUST be multiple bindings to be sent. The LEASEQUERY-DATA message MUST be
preceded by a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY conveys preceded by a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY conveys
the query's status, carries the Leasequery's Client-ID and Server-ID the query's status, carries the Leasequery's Client-ID and Server-ID
options, and carries the first client's binding data if the query was options, and carries the first client's binding data if the query was
skipping to change at page 7, line 18 skipping to change at page 7, line 31
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
The LEASEQUERY-DONE message (message type TBD) indicates the end of a The LEASEQUERY-DONE message (message type TBD) indicates the end of a
group of related Leasequery replies. The LEASEQUERY-DONE message's group of related Leasequery replies. The LEASEQUERY-DONE message's
transaction-id field MUST match the transaction-id of the LEASEQUERY transaction-id field MUST match the transaction-id of the LEASEQUERY
request message. The presence of the message itself signals the end request message. The presence of the message itself signals the end
of a stream of reply messages. A single LEASEQUERY-DONE MUST BE sent of a stream of reply messages. A single LEASEQUERY-DONE MUST BE sent
after all replies to a successful Bulk Leasequery request that after all replies (a successful LEASEQUERY-REPLY and zero or more
returned at least one binding. 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 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 [6]. We introduce the The OPTION_LQ_QUERY option is defined in [6]. We introduce the
skipping to change at page 8, line 14 skipping to change at page 8, line 26
QUERY_BY_LINK_ADDRESS (4) - The query's link-address contains an QUERY_BY_LINK_ADDRESS (4) - 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
with a Remote-ID option value from a relay's Relay-Forward message. with a Remote-ID option value from a relay's Relay-Forward message.
The query-options MUST include a Relay-ID option. The query-options MUST include a Relay Agent Remote-ID option [5].
In order to support this query, a server needs to record the most- 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 recent Remote-ID option value seen in a Relay-Forward message along
with its other binding data. with its other binding data.
QUERY_BY_REMOTE_ID (5) - The query-options MUST include a Relay QUERY_BY_REMOTE_ID (5) - The query-options MUST include a Relay
Agent Remote-ID option. If the Server has recorded Remote-ID Agent Remote-ID option [5]. If the Server has recorded Remote-ID
values with its bindings, it uses the option's value to identify values with its bindings, it uses the option's value to identify
bindings to return. bindings to return.
5.4. Options 5.4. Options
5.4.1. Relay-ID Option 5.4.1. Relay-ID Option
The Relay-ID option carries a DUID. A relay agent MAY include the The Relay-ID option carries a DUID [1]. A relay agent MAY include
option in Relay-Forward messages it sends. Obviously, it will not be the option in Relay-Forward messages it sends. Obviously, it will
possible for a server to respond to QUERY_BY_RELAYID queries unless not be possible for a server to respond to QUERY_BY_RELAYID queries
the relay agent has included this option. A relay SHOULD be able to unless the relay agent has included this option. A relay SHOULD be
generate a DUID for this purpose, and capture the result in stable able to generate a DUID for this purpose, and capture the result in
storage. A relay SHOULD also allow the DUID value to be stable storage. A relay SHOULD also allow the DUID value to be
configurable: doing so allows an administrator to replace a relay configurable: doing so allows an administrator to replace a relay
agent while retaining the association between the relay and existing agent while retaining the association between the relay and existing
DHCPv6 bindings. 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 PD and/or lease bindings that result. messages it processes with PD and/or lease bindings that result.
Doing so allows it to respond to QUERY_BY_RELAYID Leasequeries. Doing so allows it to respond to QUERY_BY_RELAYID Leasequeries.
The format of the Relay-ID option is shown below: The format of the Relay-ID option is shown below:
skipping to change at page 9, line 26 skipping to change at page 9, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RELAYID (TBD). option-code OPTION_RELAYID (TBD).
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
TODO: are any new status codes needed - to indicate a connection or QueryTerminated (TBD) - Indicates that the server is unable to
resource problem e.g.? perform a query or has prematurely terminated the query for some
reason (which should be communicated in the text 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 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.
skipping to change at page 11, line 17 skipping to change at page 11, line 27
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 session 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.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 [6] includes a discussion about reconciling Leasequery specification [6] includes a discussion about reconciling
binding data received from multiple DHCPv6 servers. 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 with a unique transaction id. to issue multiple queries. Each query MUST have a unique transaction
Requestors should be aware that servers are not required to process id. A server MAY process more than one query at a time. A server
queries in parallel, and that servers are likely to limit the rate at that is willing to do so MAY interleave replies to the multiple
which they process queries from any one Requestor. 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. 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.
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 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.
skipping to change at page 14, line 14 skipping to change at page 15, line 14
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 finds that The server MUST close its end of the TCP connection if it encounters
it has to abort an in-process request, or if it encounters an error an error sending data on the connection. The server MUST close its
sending data on the connection. If the server detects that the end of the TCP connection if it finds that it has to abort an in-
client end has been closed, the server MUST close its end of the process request. A server aborting an in-process request MAY attempt
connection after it has finished processing any outstanding requests to signal that to its clients by using the QueryTerminated
from the client. (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.
8. Security Considerations 8. Security Considerations
The "Security Considerations" section of [1] details the general The "Security Considerations" section of [1] details the general
threats to DHCPv6. The DHCPv6 Leasequery specification [6] describes threats to DHCPv6. The DHCPv6 Leasequery specification [6] describes
recommendations for the Leasequery protocol, especially with regard recommendations for the Leasequery protocol, especially with regard
to relayed LEASEQUERY messages, mitigation of packet-flooding DOS to relayed LEASEQUERY messages, mitigation of packet-flooding DOS
attacks, restriction to trusted clients, and use of IPsec [7]. attacks, restriction to trusted clients, and use of IPsec [7].
The use of TCP introduces some additional concerns. Attacks that The use of TCP introduces some additional concerns. Attacks that
skipping to change at page 14, line 48 skipping to change at page 16, line 7
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 is requested to assign a new DHCPv6 Option Code in the registry
maintained in http://www.iana.org/assignments/dhcpv6-parameters: maintained in http://www.iana.org/assignments/dhcpv6-parameters:
OPTION_RELAYID OPTION_RELAYID
IANA is requested to assign a new value in the registry of DHCPv6
Status Codes maintained in
http://www.iana.org/assignments/dhcpv6-parameters:
QueryTerminated
IANA is requested to assign values for the following new DHCPv6 IANA is requested to assign values for the following new DHCPv6
Message types in the registry maintained in Message types in the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters: http://www.iana.org/assignments/dhcpv6-parameters:
LEASEQUERY-DONE LEASEQUERY-DONE
LEASEQUERY-DATA LEASEQUERY-DATA
IANA is requested to assign the following new values in the registry IANA is requested to assign the following new values in the registry
of query-types for the DHCPv6 OPTION_LQ_QUERY option: of query-types for the DHCPv6 OPTION_LQ_QUERY option:
QUERY_BY_RELAYID
QUERY_BY_RELAYID 3 QUERY_BY_LINK_ADDRESS
QUERY_BY_LINK_ADDRESS 4 QUERY_BY_REMOTE_ID
QUERY_BY_REMOTE_ID 5
10. Acknowledgements 10. Acknowledgements
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, Ted DHC working group, including John Brzozowski, Marcus Goller, Ted
Lemon, and Bud Millwood. Lemon, and Bud Millwood.
11. Modification History 11. Modification History
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
 End of changes. 27 change blocks. 
84 lines changed or deleted 153 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/