draft-ietf-dhc-dhcpv6-bulk-leasequery-01.txt   draft-ietf-dhc-dhcpv6-bulk-leasequery-02.txt 
DHC M. Stapp DHC M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: November 22, 2008 May 21, 2008 Expires: December 5, 2008 June 3, 2008
DHCPv6 Bulk Leasequery DHCPv6 Bulk Leasequery
draft-ietf-dhc-dhcpv6-bulk-leasequery-01.txt draft-ietf-dhc-dhcpv6-bulk-leasequery-02.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 November 22, 2008. This Internet-Draft will expire on December 5, 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . 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_RELAYID . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. Modification History . . . . . . . . . . . . . . . . . . . . . 16 11. Modification History . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The DHCPv6 [1] protocol specifies a mechanism for the assignment of The DHCPv6 [RFC3315] protocol specifies a mechanism for the
IPv6 address and configuration information to IPv6 nodes. IPv6 assignment of IPv6 address and configuration information to IPv6
Prefix Delegation for DHCPv6 (PD) [2] specifies a mechanism for nodes. IPv6 Prefix Delegation for DHCPv6 (PD) [RFC3633] specifies a
DHCPv6 delegation of IPv6 prefixes and related data. DHCPv6 servers mechanism for DHCPv6 delegation of IPv6 prefixes and related data.
maintain authoritative information including binding information for DHCPv6 servers maintain authoritative information including binding
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 [6] 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 [3] for efficiency of data transfer. We specify a new the use of TCP [RFC4614] for efficiency of data transfer. We specify
DHCPv6 option, the Relay Identifier option, to support efficient a new DHCPv6 option, the Relay Identifier option, to support
recovery of all data associated with a specific relay agent; we also efficient recovery of all data associated with a specific relay
add a query-type for this purpose. We add query-types by network agent; we also add a query-type for this purpose. We add query-types
segment and by Remote-ID option value, to assist a relay that needs by network segment and by Remote-ID option value, to assist a relay
to recover a subset of its clients' bindings. that needs to recover a subset of its clients' bindings.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [4]. document are to be interpreted as described in [RFC2119].
DHCPv6 terminology is defined in [1]. DHCPv6 Leasequery terminology DHCPv6 terminology is defined in [RFC3315]. DHCPv6 Leasequery
is defined in [6]. 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 [6]; most differences arise from the use of Leasequery protocol in [RFC5007]; most differences arise from the use
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-
skipping to change at page 4, line 45 skipping to change at page 4, line 45
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 RFC5007 [6]. The Bulk Leasequery protocol also DUID as specified in RFC5007 [RFC5007]. The Bulk Leasequery protocol
adds several new queries. The new queries introduced here cannot be also adds several new queries. The new queries introduced here
used effectively with the UDP Leasequery protocol. Requestors MUST cannot be used effectively with the UDP Leasequery protocol.
NOT send these new query-types in RFC5007 [6] query messages. Requestors MUST NOT send these new query-types in RFC5007 [RFC5007]
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 [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 [6]. 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 permitted
when Bulk Leasequery is used. RFC5007 [6], in sections 4.1.2.5 and when Bulk Leasequery is used. RFC5007 [RFC5007], in sections 4.1.2.5
4.3.3, specifies the use of a Client Link option in LEASEQUERY-REPLY and 4.3.3, specifies the use of a Client Link option in LEASEQUERY-
messages in cases where multiple bindings were found. When Bulk REPLY messages in cases where multiple bindings were found. When
Leasequery is used, this mechanism is not necessary: a server Bulk 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- 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 [6]. respond with an error status code of NotAllowed [RFC5007].
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 33 skipping to change at page 6, line 33
| . | .
. 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 [1]. 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
[6]. 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
skipping to change at page 7, line 43 skipping to change at page 7, line 43
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.
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 [RFC5007]. We introduce the
following new query-types: QUERY_BY_RELAYID, 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_RELAYID 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_RELAYID (3) - The query-options MUST contain an QUERY_BY_RELAY_ID (3) - The query-options MUST contain an
OPTION_RELAYID 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 (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 Agent Remote-ID option [5]. The query-options MUST include a Relay Agent Remote-ID option
[RFC4649].
In order to support this query, a server needs to record the most- 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 [5]. If the Server has recorded Remote-ID Agent Remote-ID option [RFC4649]. If the Server has recorded
values with its bindings, it uses the option's value to identify Remote-ID values with its bindings, it uses the option's value to
bindings to return. identify 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 [1]. A relay agent MAY include The Relay-ID option carries a DUID [RFC3315]. A relay agent MAY
the option in Relay-Forward messages it sends. Obviously, it will include the option in Relay-Forward messages it sends. Obviously, it
not be possible for a server to respond to QUERY_BY_RELAYID queries will not be possible for a server to respond to QUERY_BY_RELAY_ID
unless the relay agent has included this option. A relay SHOULD be queries unless the relay agent has included this option. A relay
able to generate a DUID for this purpose, and capture the result in SHOULD be able to generate a DUID for this purpose, and capture the
stable storage. A relay SHOULD also allow the DUID value to be result in stable storage. A relay SHOULD also allow the DUID value
configurable: doing so allows an administrator to replace a relay to be configurable: doing so allows an administrator to replace a
agent while retaining the association between the relay and existing relay agent while retaining the association between the relay and
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 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_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_RELAYID | option-len | | OPTION_RELAY_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. DUID . . DUID .
. (variable length) . . (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RELAYID (TBD). option-code OPTION_RELAY_ID (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
QueryTerminated (TBD) - Indicates that the server is unable to QueryTerminated (TBD) - Indicates that the server is unable to
perform a query or has prematurely terminated the query for some perform a query or has prematurely terminated the query for some
reason (which should be communicated in the text message). This may reason (which should be communicated in the text message). This may
skipping to change at page 10, line 27 skipping to change at page 10, line 28
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. The Requestor SHOULD be in order to initiate a Leasequery exchange. The Requestor SHOULD be
prepared to abandon the connection attempt after prepared to abandon the connection attempt after
BULK_LQ_CONN_TIMEOUT. If the attempt fails, the Requestor MAY retry. BULK_LQ_CONN_TIMEOUT. If the attempt fails, the Requestor MAY retry.
Retries MUST use an exponential backoff timer, increasing the Retries MUST use an exponential backoff timer, increasing the
interval between attempts up to BULK_LQ_MAX_RETRY. interval between attempts up to BULK_LQ_MAX_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 [6]. The query may have any of Leasequery message, as specified in [RFC5007]. The query may have
the defined query-types, and includes the options and data required any of the defined query-types, and includes the options and data
by the query-type chosen. The Requestor sends the message size then required by the query-type chosen. The Requestor sends the message
sends the actual DHCPv6 message, as described in Section 5.1. size then sends the actual DHCPv6 message, as described in
Section 5.1.
If the TCP connection becomes blocked while the Requestor is sending If the TCP connection becomes blocked while the Requestor is sending
its query, the Requestor SHOULD be prepared to terminate the its query, the Requestor 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 Requestors to control the period of time they are willing to to allow Requestors to control the period of time they are willing to
wait before abandoning a connection, independent of notifications wait before abandoning a connection, independent of notifications
from the TCP implementations they may be using. 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 stream of replies becomes blocked, the TCP connection. If the stream of replies becomes blocked, the
Requestor SHOULD be prepared to terminate the connection after Requestor SHOULD be prepared to terminate the connection after
BULK_LQ_DATA_TIMEOUT, and MAY begin retry processing if configured to BULK_LQ_DATA_TIMEOUT, and MAY begin retry processing if configured to
do so. 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 [6]. If the reply contains an error status code (carried Leasequery [RFC5007]. If the reply contains an error status code
in an OPTION_STATUS_CODE option), the Requestor follows the (carried in an OPTION_STATUS_CODE option), the Requestor follows the
recommendations in [6]. A successful reply that does not include an recommendations in [RFC5007]. A successful reply that does not
OPTION_CLIENT_DATA option indicates that the target server had no include an OPTION_CLIENT_DATA option indicates that the target server
bindings matching the query. had no bindings matching the query.
The Leasequery protocol uses the OPTION_CLIENT_LINK option as an The Leasequery protocol uses the OPTION_CLIENT_LINK option as an
indicator that multiple bindings were present in response to a single indicator that multiple bindings were present in response to a single
query. For Bulk Leasequery, the OPTION_CLIENT_LINK option is not query. For Bulk Leasequery, the OPTION_CLIENT_LINK option is not
used, and MUST NOT be present in replies. 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
skipping to change at page 11, line 39 skipping to change at page 11, line 41
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 [RFC5007] includes a discussion about
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 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
skipping to change at page 13, line 20 skipping to change at page 13, line 21
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 [6], or MAY close the connection. NotAllowed status code [RFC5007], or MAY 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 [6] 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 are 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
skipping to change at page 14, line 6 skipping to change at page 14, line 10
resulted in one or more reply messages, the server SHOULD send a resulted in one or more reply messages, the server SHOULD send a
LEASEQUERY-DONE message with an error status. The server SHOULD LEASEQUERY-DONE message with an error status. The server SHOULD
close its end of the connection as an indication that it was not able close its end of the connection as an indication that it was not able
to complete query processing. to complete query processing.
If the server does not find any bindings satisfying a query, it If the server does not find any bindings satisfying a query, it
SHOULD send a LEASEQUERY-REPLY without an OPTION_STATUS_CODE option SHOULD send a LEASEQUERY-REPLY without an OPTION_STATUS_CODE option
and without any OPTION_CLIENT_DATA option. Otherwise, the server and without any OPTION_CLIENT_DATA option. Otherwise, the server
sends each binding's data in a reply message. The first reply sends each binding's data in a reply message. The first reply
message is a LEASEQUERY-REPLY. The binding data is carried in an message is a LEASEQUERY-REPLY. The binding data is carried in an
OPTION_CLIENT_DATA option, as specified in [6] and extended below. OPTION_CLIENT_DATA option, as specified in [RFC5007] and extended
The server returns subsequent bindings in LEASEQUERY-DATA messages, below. The server returns subsequent bindings in LEASEQUERY-DATA
which can avoid redundant data (such as the requestor's Client-ID). messages, which can avoid redundant data (such as the requestor's
Client-ID).
For QUERY_BY_RELAYID, the server locates each binding associated with For QUERY_BY_RELAY_ID, the server locates each binding associated
the query's Relay-ID option value. In order to give a meaningful with the query's Relay-ID option value. In order to give a
reply to a QUERY_BY_RELAYID, the server has to be able to maintain meaningful reply to a QUERY_BY_RELAY_ID, the server has to be able to
this association in its DHCPv6 binding data. If the query's link- maintain this association in its DHCPv6 binding data. If the query's
address is not set to 0::0, the server only returns bindings on links link-address is not set to 0::0, the server only returns bindings on
that could contain that address. If the link-address is not 0::0 and links that could contain that address. If the link-address is not
the server cannot find any matching links, the server SHOULD return 0::0 and the server cannot find any matching links, the server SHOULD
the NotConfigured status in a LEASEQUERY-REPLY. return the NotConfigured status in a LEASEQUERY-REPLY.
For QUERY_BY_LINK_ADDRESS, the server locates each binding associated For QUERY_BY_LINK_ADDRESS, the server locates each binding associated
with the link identified by the query's link-address value. with the link identified by the query's link-address value.
For QUERY_BY_REMOTE_ID, the server locates each binding associated For QUERY_BY_REMOTE_ID, the server locates each binding associated
with the query's Relay Remote-ID option value. In order to be able with the query's Relay Remote-ID option value. In order to be able
to give meaningful replies to this query, the server has to be able to give meaningful replies to this query, the server has to be able
to maintain this association in its binding database. If the query to maintain this association in its binding database. If the query
message's link-address is not set to 0::0, the server only returns message's link-address is not set to 0::0, the server only returns
bindings on links that could contain that address. If the link- bindings on links that could contain that address. If the link-
skipping to change at page 15, line 26 skipping to change at page 15, line 26
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 signal that to its clients by using the QueryTerminated
(Section 5.5) status code. If the server detects that the client end (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 has been closed, the server MUST close its end of the connection
after it has finished processing any outstanding requests from the after it has finished processing any outstanding requests from the
client. client.
8. Security Considerations 8. Security Considerations
The "Security Considerations" section of [1] details the general The "Security Considerations" section of [RFC3315] details the
threats to DHCPv6. The DHCPv6 Leasequery specification [6] describes general threats to DHCPv6. The DHCPv6 Leasequery specification
recommendations for the Leasequery protocol, especially with regard [RFC5007] describes recommendations for the Leasequery protocol,
to relayed LEASEQUERY messages, mitigation of packet-flooding DOS especially with regard to relayed LEASEQUERY messages, mitigation of
attacks, restriction to trusted clients, and use of IPsec [7]. packet-flooding DOS attacks, restriction to trusted clients, and use
of IPsec [RFC2401].
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 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_RELAY_ID
IANA is requested to assign a new value in the registry of DHCPv6 IANA is requested to assign a new value in the registry of DHCPv6
Status Codes maintained in Status Codes maintained in
http://www.iana.org/assignments/dhcpv6-parameters: http://www.iana.org/assignments/dhcpv6-parameters:
QueryTerminated 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_RELAY_ID
QUERY_BY_LINK_ADDRESS QUERY_BY_LINK_ADDRESS
QUERY_BY_REMOTE_ID QUERY_BY_REMOTE_ID
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. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", and M. Carney, "Dynamic Host Configuration Protocol for
RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[2] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[3] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
Transmission Control Protocol (TCP) Specification Documents", for Transmission Control Protocol (TCP) Specification
RFC 4614, September 2006. Documents", RFC 4614, September 2006.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
Relay Agent Remote-ID Option", RFC 4649, August 2006. (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
August 2006.
[6] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
Leasequery", RFC 5007, September 2007. "DHCPv6 Leasequery", RFC 5007, September 2007.
12.2. Informative References 12.2. Informative References
[7] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
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
 End of changes. 43 change blocks. 
102 lines changed or deleted 108 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/