draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt   draft-ietf-dhc-dhcpv6-bulk-leasequery-05.txt 
DHC M. Stapp DHC M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track October 16, 2008 Intended status: Standards Track November 25, 2008
Expires: April 19, 2009 Expires: May 29, 2009
DHCPv6 Bulk Leasequery DHCPv6 Bulk Leasequery
draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt draft-ietf-dhc-dhcpv6-bulk-leasequery-05.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 34 skipping to change at page 1, line 34
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 April 19, 2009. This Internet-Draft will expire on May 29, 2009.
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 . . . . . . . . . . . . . . . . 5 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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
includes the first client's binding data in the LEASEQUERY-REPLY includes the first client's binding data in the LEASEQUERY-REPLY
message also. If more than one client's bindings are being returned, message also. If more than one client's bindings are being returned,
the server then transmits the additional client bindings in a series the server then transmits the additional client bindings in a series
of LEASEQUERY-DATA messages. If the server has sent at least one of LEASEQUERY-DATA messages. If the server has sent at least one
client's bindings, it sends a LEASEQUERY-DONE message when it has client's bindings, it sends a LEASEQUERY-DONE message when it has
finished sending its replies. The client may reuse the connection to finished sending its replies. The client may reuse the connection to
send additional queries. Each end of the TCP connection can be send additional queries. Each end of the TCP connection can be
closed after all data has been sent. 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 (DHCP Unique Identifier) identifying a
agents can include this option in Relay-Forward messages they send. DHCPv6 relay agent. Relay agents can include this option in Relay-
Servers can retain the Relay-ID and associate it with bindings made Forward messages they send. Servers can retain the Relay-ID and
on behalf of the relay's clients. A relay can then recover binding associate it with bindings made on behalf of the relay's clients. A
information about downstream clients by using the Relay-ID in a relay can then recover binding information about downstream clients
LEASEQUERY message. The Relay-ID option is defined in Section 5.4.1. by using the Relay-ID in a LEASEQUERY message. The Relay-ID option
is defined in Section 5.4.1.
Bulk Leasequery supports the queries by IPv6 address and by Client Bulk Leasequery supports the queries by IPv6 address and by Client
DUID as specified in RFC5007 [RFC5007]. The Bulk Leasequery protocol DUID as specified in [RFC5007]. The Bulk Leasequery protocol also
also adds several new queries. The new queries introduced here adds several new queries. The new queries introduced here cannot be
cannot be used effectively with the UDP Leasequery protocol. used effectively with the UDP Leasequery protocol. Requestors MUST
Requestors MUST NOT send these new query-types in RFC5007 [RFC5007] NOT send these new query-types in [RFC5007] query messages.
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 [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 permitted in the Bulk Leasequery protocol. One change in behavior is
when Bulk Leasequery is used. RFC5007 [RFC5007], in sections 4.1.2.5 introduced when Bulk Leasequery is used. [RFC5007], in sections
and 4.3.3, specifies the use of a Client Link option in LEASEQUERY- 4.1.2.5 and 4.3.3, specifies the use of a Client Link option in
REPLY messages in cases where multiple bindings were found. When LEASEQUERY-REPLY messages in cases where multiple bindings were
Bulk Leasequery is used, this mechanism is not necessary: a server found. When Bulk Leasequery is used, this mechanism is not
returning multiple bindings simply does so directly as specified in necessary: a server returning multiple bindings simply does so
this document. The Client Link option MUST NOT appear in Bulk directly as specified in this document. The Client Link option MUST
Leasequery replies. NOT appear in Bulk Leasequery replies.
Only LEASEQUERY, LEASEQUERY-REPLY, LEASEQUERY-DATA, and LEASEQUERY- Only LEASEQUERY, LEASEQUERY-REPLY, LEASEQUERY-DATA, and LEASEQUERY-
DONE messages are allowed over the Bulk Leasequery connection. No DONE messages are allowed over the Bulk Leasequery connection. No
other DHCPv6 messages are supported. The Bulk Leasequery connection other DHCPv6 messages are supported. The Bulk Leasequery connection
is not an alternative DHCPv6 communication option for clients seeking is not an alternative DHCPv6 communication option for clients seeking
DHCPv6 service. 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 [RFC5007]. respond with an error status code of NotAllowed [RFC5007].
Implementors should note that the TCP message framing defined in
Section 5.1 is not compatible with the UDP message format. If a TCP-
framed request is sent as a UDP message, it may not be valid, because
protocol fields will be offset by the message-size prefix.
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-
size octets 'frame' each DHCPv6 message. size octets 'frame' each DHCPv6 message.
DHCPv6 message framed for TCP: DHCPv6 message framed for TCP:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message-size | msg-type | trans-id | | message-size | msg-type | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| transaction-id (cont'd) | | : transaction-id | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| . | .
. options . . options .
. (variable) . . (variable) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [RFC3315]. All other fields are as specified in DHCPv6 [RFC3315].
5.2. Messages 5.2. Messages
The LEASEQUERY and LEASEQUERY-REPLY messages are defined in RFC5007 The LEASEQUERY and LEASEQUERY-REPLY messages are defined in
[RFC5007]. In a Bulk Leasequery exchange, a single LEASEQUERY-REPLY [RFC5007]. In a Bulk Leasequery exchange, a single LEASEQUERY-REPLY
message is used to indicate the success or failure of a query, and to message is used to indicate the success or failure of a query, and to
carry data that do not change in the context of a single query and carry data that do not change in the context of a single query and
answer, such as the Server-ID and Client-ID options. If a query is answer, such as the Server-ID and Client-ID options. If a query is
successful, only a single LEASEQUERY-REPLY message MUST appear. If successful, only a single LEASEQUERY-REPLY message MUST appear. If
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 (message type TBD) carries data about a The LEASEQUERY-DATA message carries data about a single DHCPv6
single DHCPv6 client's leases and/or PD bindings on a single link. client's leases and/or PD bindings on a single link. The purpose of
The purpose of the message is to reduce redundant data when there are the message is to reduce redundant data when there are multiple
multiple bindings to be sent. The LEASEQUERY-DATA message MUST be bindings to be sent. The LEASEQUERY-DATA message MUST be preceded by
preceded by a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY conveys a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY conveys the query's
the query's status, carries the Leasequery's Client-ID and Server-ID status, carries the Leasequery's Client-ID and Server-ID options, and
options, and carries the first client's binding data if the query was carries the first client's binding data if the query was successful.
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
The LEASEQUERY-DONE message (message type TBD) indicates the end of a The LEASEQUERY-DONE message indicates the end of a group of related
group of related Leasequery replies. The LEASEQUERY-DONE message's Leasequery replies. The LEASEQUERY-DONE message's transaction-id
transaction-id field MUST match the transaction-id of the LEASEQUERY field MUST match the transaction-id of the LEASEQUERY request
request message. The presence of the message itself signals the end message. The presence of the message itself signals the end of a
of a stream of reply messages. A single LEASEQUERY-DONE MUST BE sent stream of reply messages. A single LEASEQUERY-DONE MUST BE sent
after all replies (a successful LEASEQUERY-REPLY and zero or more after all replies (a successful LEASEQUERY-REPLY and zero or more
LEASEQUERY-DATA messages) to a successful Bulk Leasequery request LEASEQUERY-DATA messages) to a successful Bulk Leasequery request
that returned at least one binding. 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.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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 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 (3) - 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 an link-address value from a relay's
Relay-Forward message. Relay-Forward message.
QUERY_BY_LINK_ADDRESS (4) - 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
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 Agent Remote-ID option The query-options MUST include a Relay Agent Remote-ID option
[RFC4649]. [RFC4649].
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 - The query-options MUST include a Relay Agent
Agent Remote-ID option [RFC4649]. If the Server has recorded Remote-ID option [RFC4649]. If the Server has recorded Remote-ID
Remote-ID values with its bindings, it uses the option's value to values with its bindings, it uses the option's value to identify
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 [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 PD and/or lease bindings that result. messages it processes with prefix delegations and/or lease bindings
Doing so allows it to respond to QUERY_BY_RELAY_ID Leasequeries. that result. Doing so allows it to respond to QUERY_BY_RELAY_ID
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. DUID . . DUID .
. (variable length) . . (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RELAY_ID (TBD). 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 (TBD) - Indicates that the server is unable to QueryTerminated - Indicates that the server is unable to perform a
perform a query or has prematurely terminated the query for some query or has prematurely terminated the query for some reason (which
reason (which should be communicated in the text message). This may should be communicated in the text message). This may be because the
be because the server is short of resources or is being shut down. server is short of resources or is being shut down. The requestor
The requestor may retry the query at a later time. The requestor may retry the query at a later time. The requestor should wait at
should wait at least a short interval before retrying. Note that least a short interval before retrying. Note that while a server may
while a server may simply prematurely close its end of the simply prematurely close its end of the connection, it is preferable
connection, it is preferable for the server to send a LEASEQUERY- for the server to send a LEASEQUERY-REPLY or LEASEQUERY-DONE with
REPLY or LEASEQUERY-DONE with this status-code to notify the this status-code to notify the requestor of the condition.
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 21 skipping to change at page 11, line 21
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 xid will be received) when one of these messages for that request transaction-id will be received) when one
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,
when the LEASEQUERY-REPLY is received, when the LEASEQUERY-REPLY is received,
2. else if the LEASEQUERY-REPLY did have an OPTION_CLIENT_DATA, when 2. else if the LEASEQUERY-REPLY did have an OPTION_CLIENT_DATA, when
the corresponding LEASEQUERY-DONE message is received, the corresponding LEASEQUERY-DONE message is received,
3. else when the connection is closed. 3. else when the connection is closed.
6.4. Querying Multiple Servers 6.4. Querying Multiple Servers
skipping to change at page 12, line 23 skipping to change at page 12, line 23
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 transaction
id. A server MAY process more than one query at a time. A server id. A server MAY process more than one query at a time. A server
that is willing to do so MAY interleave replies to the multiple that is willing to do so MAY interleave replies to the multiple
queries within the stream of reply messages it sends. Clients need queries within the stream of reply messages it sends. Clients need
to be aware that replies for multiple queries may be interleaved to be aware that replies for multiple queries may be interleaved
within the stream of reply messages. Clients that are not able to within the stream of reply messages. Clients that are not able to
process interleaved replies (based on transaction id) MUST NOT send process interleaved replies (based on transaction-id) MUST NOT send
more than one query at a time. Requestors should be aware that 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 not required to process queries in parallel, and that
servers are likely to limit the rate at which they process queries servers are likely to limit the rate at which they process queries
from any one Requestor. 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. Query 1 results in a failure; query 2 establishing a connection; "xid" denotes a transaction-id in the
succeeds and the stream of replies concludes before the client issues diagram. Query 1 results in a failure; query 2 succeeds and the
any new query. Query 3 and query 4 overlap, and the server stream of replies concludes before the client issues any new query.
interleaves its replies to those two queries. Query 3 and query 4 overlap, and the server interleaves its replies
to those two queries.
Client Server Client Server
------ ------ ------ ------
LEASEQUERY xid 1 -----> LEASEQUERY xid 1 ----->
<----- LEASEQUERY-REPLY xid 1 (w/error) <----- LEASEQUERY-REPLY xid 1 (w/error)
LEASEQUERY xid 2 -----> LEASEQUERY xid 2 ----->
<----- LEASEQUERY-REPLY xid 2 <----- LEASEQUERY-REPLY xid 2
<----- LEASEQUERY-DATA xid 2 <----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2 <----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DONE xid 2 <----- LEASEQUERY-DONE xid 2
skipping to change at page 13, line 49 skipping to change at page 13, line 49
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 not from permitted clients
SHOULD BE closed immediately, to avoid server connection resource SHOULD BE closed immediately, to avoid server connection resource
exhaustion. Servers MAY restrict some clients to certain query exhaustion. Servers MAY restrict some clients to certain query
types. Servers MAY reply to queries that are not permitted with the types. Servers MAY reply to queries that are not permitted with the
NotAllowed status code [RFC5007], or MAY close the connection. 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
skipping to change at page 17, line 23 skipping to change at page 17, line 23
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
August 2006. August 2006.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007. "DHCPv6 Leasequery", RFC 5007, September 2007.
12.2. Informative References 12.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
 End of changes. 28 change blocks. 
73 lines changed or deleted 78 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/