draft-ietf-dhc-dhcpv4-bulk-leasequery-02.txt   draft-ietf-dhc-dhcpv4-bulk-leasequery-03.txt 
DHC Working Group Kim Kinnear DHC Working Group Kim Kinnear
Internet Draft Bernie Volz Internet Draft Bernie Volz
Intended Status: Standards Track Mark Stapp Intended Status: Standards Track Mark Stapp
Expires: September 5, 2010 Cisco Systems, Inc. Expires: April 18, 2011 Cisco Systems, Inc.
D. Rao D. Rao
B. Joshi B. Joshi
P. Kurapati
Infosys Technologies Ltd. Infosys Technologies Ltd.
Neil Russell Neil Russell
March 5, 2010 Nokia
P. Kurapati
Juniper Networks Ltd.
October 18, 2010
Bulk DHCPv4 Lease Query Bulk DHCPv4 Lease Query
<draft-ietf-dhc-dhcpv4-bulk-leasequery-02.txt> <draft-ietf-dhc-dhcpv4-bulk-leasequery-03.txt>
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 3, line 4 skipping to change at page 2, line 23
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery
extension allows a requestor to request information about DHCPv4 extension allows a requestor to request information about DHCPv4
bindings. This mechanism is limited to queries for individual bindings. This mechanism is limited to queries for individual
bindings. In some situations individual binding queries may not be bindings. In some situations individual binding queries may not be
efficient, or even possible. This document extends the DHCPv4 efficient, or even possible. This document extends the DHCPv4
Leasequery protocol to allow for bulk transfer of DHCPv4 address Leasequery protocol to allow for bulk transfer of DHCPv4 address
binding data via TCP. binding data via TCP.
Table of Contents Table of Contents
1. Introduction................................................. 3 1. Introduction................................................. 3
2. Terminology.................................................. 5 2. Terminology.................................................. 4
3. Design Goals................................................. 7 3. Design Goals................................................. 7
3.1. Information Acquisition before Data Starts................. 7 3.1. Information Acquisition before Data Starts................. 7
3.2. Lessen need for Caching and Negative Caching............... 8 3.2. Lessen need for Caching and Negative Caching............... 7
3.3. Antispoofing in 'Fast Path'................................ 8 3.3. Antispoofing in 'Fast Path'................................ 7
3.4. Minimize data transmission................................. 8 3.4. Minimize data transmission................................. 7
4. Protocol Overview............................................ 8 4. Protocol Overview............................................ 8
5. Interaction Between UDP Leasequery and Bulk Leasequery....... 10 5. Interaction Between UDP Leasequery and Bulk Leasequery....... 9
6. Message and Option Definitions............................... 11 6. Message and Option Definitions............................... 10
6.1. Message Framing for TCP.................................... 11 6.1. Message Framing for TCP.................................... 10
6.2. New or Changed Options..................................... 12 6.2. New or Changed Options..................................... 11
6.3. Connection and Transmission Parameters..................... 19 6.3. Connection and Transmission Parameters..................... 19
7. Requestor Behavior........................................... 20 7. Requestor Behavior........................................... 19
7.1. Connecting and General Processing.......................... 20 7.1. Connecting and General Processing.......................... 19
7.2. Forming a Bulk Leasequery.................................. 20 7.2. Forming a Bulk Leasequery.................................. 20
7.3. Processing Bulk Replies.................................... 22 7.3. Processing Bulk Replies.................................... 22
7.4. Processing Time Values in Leasequery messages.............. 24 7.4. Processing Time Values in Leasequery messages.............. 24
7.5. Querying Multiple Servers.................................. 25 7.5. Querying Multiple Servers.................................. 25
7.6. Making Sense Out of Multiple Responses Concerning a Single. 25 7.6. Making Sense Out of Multiple Responses Concerning a Single. 25
7.7. Multiple Queries to a Single Server over One Connection.... 26 7.7. Multiple Queries to a Single Server over One Connection.... 26
7.8. Closing Connections........................................ 27 7.8. Closing Connections........................................ 27
8. Server Behavior.............................................. 28 8. Server Behavior.............................................. 27
8.1. Accepting Connections...................................... 28 8.1. Accepting Connections...................................... 27
8.2. Replying to a Bulk Leasequery.............................. 28 8.2. Replying to a Bulk Leasequery.............................. 28
8.3. Building a Single Reply for Bulk Leasequery................ 31 8.3. Building a Single Reply for Bulk Leasequery................ 31
8.4. Multiple or Parallel Queries............................... 33 8.4. Multiple or Parallel Queries............................... 32
8.5. Closing Connections........................................ 33 8.5. Closing Connections........................................ 33
9. Security Considerations...................................... 34 9. Security Considerations...................................... 33
10. IANA Considerations......................................... 34 10. IANA Considerations......................................... 34
11. Acknowledgements............................................ 36 11. Acknowledgements............................................ 35
12. References.................................................. 36 12. References.................................................. 36
12.1. Normative References...................................... 36 12.1. Normative References...................................... 36
12.2. Informative References.................................... 37 12.2. Informative References.................................... 36
Authors' Addresses............................................... 37
1. Introduction 1. Introduction
The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the
assignment of IPv4 address and configuration information to IPv4 assignment of IPv4 address and configuration information to IPv4
nodes. DHCPv4 servers maintain authoritative binding information. nodes. DHCPv4 servers maintain authoritative binding information.
+--------+ +--------+
| DHCPv4 | +--------------+ | DHCPv4 | +--------------+
| Server |-...-| DSLAM | | Server |-...-| DSLAM |
skipping to change at page 13, line 9 skipping to change at page 12, line 9
6.2.1. dhcp-message-type 6.2.1. dhcp-message-type
The dhcp-message-type option (option 53) from Section 9.6 of The dhcp-message-type option (option 53) from Section 9.6 of
[RFC2132] requires new values. The values of these message types are [RFC2132] requires new values. The values of these message types are
shown below in an extension of the table from Section 9.6 of shown below in an extension of the table from Section 9.6 of
[RFC2132]: [RFC2132]:
Value Message Type Value Message Type
----- ------------ ----- ------------
14 DHCPBULKLEASEQUERY TBD8 DHCPBULKLEASEQUERY
15 DHCPLEASEQUERYDONE TBD9 DHCPLEASEQUERYDONE
6.2.2. status-code 6.2.2. status-code
The status code option allows a machine readable value to be returned The status code option allows a machine readable value to be returned
regarding the status of a DHCPBULKLEASEQUERY request. regarding the status of a DHCPBULKLEASEQUERY request.
This option has two possible scopes when used with Bulk Leasequery, This option has two possible scopes when used with Bulk Leasequery,
depending on the context in which it appears. It refers to the depending on the context in which it appears. It refers to the
information in a single Leasequery reply if the value of the dhcp- information in a single Leasequery reply if the value of the dhcp-
message-type is DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED. It refers to message-type is DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED. It refers to
the message stream related to an entire request if the value of the the message stream related to an entire request if the value of the
dhcp-message-type is DHCPLEASEQUERYDONE. dhcp-message-type is DHCPLEASEQUERYDONE.
The code for this option is TBD1. The length of this option is a The code for this option is TBD1. The length of this option is a
minimum of 1 octect. minimum of 1 octet.
Status Status Status Status
Code Len Code Message Code Len Code Message
+------+------+------+------+------+-- --+-----+ +------+------+------+------+------+-- --+-----+
| TBD1 | n+1 |status| s1 | s2 | ... | sn | | TBD1 | n+1 |status| s1 | s2 | ... | sn |
+------+------+------+------+------+-- --+-----+ +------+------+------+------+------+-- --+-----+
The status-code is an octect defined in the table below. The Status The status-code is an octet defined in the table below. The Status
Message is an optional NVT ASCII encoded text string suitable for Message is an optional NVT ASCII encoded text string suitable for
display to an end user, which MUST NOT be null-terminated. display to an end user, which MUST NOT be null-terminated.
Name Status Code Description Name Status Code Description
---- ----------- ----------- ---- ----------- -----------
Success 000 Success. Also signaled by absence of Success 000 Success. Also signaled by absence of
a dhcp-message option. a status-code option.
UnspecFail 001 Failure, reason unspecified. UnspecFail 001 Failure, reason unspecified.
QueryTerminated 002 Indicates that the server is unable to QueryTerminated 002 Indicates that the server is unable to
perform a query or has prematurely terminated perform a query or has prematurely terminated
the query for some reason (which should be the query for some reason (which should be
communicated in the text message). communicated in the text message).
MalformedQuery 003 The query was not understood. MalformedQuery 003 The query was not understood.
skipping to change at page 14, line 35 skipping to change at page 13, line 35
appear in a message which is successful unless there is some text appear in a message which is successful unless there is some text
string that needs to be communicated to the requestor. string that needs to be communicated to the requestor.
6.2.3. base-time 6.2.3. base-time
The base-time option is the current time the message was created to The base-time option is the current time the message was created to
be sent by the DHCPv4 server to the requestor of the Bulk Leasequery. be sent by the DHCPv4 server to the requestor of the Bulk Leasequery.
This MUST be an absolute time. All of the other time based options in This MUST be an absolute time. All of the other time based options in
the reply message are relative to this time, including the dhcp- the reply message are relative to this time, including the dhcp-
lease-time [RFC2132] and client-last-transaction-time [RFC4388]. lease-time [RFC2132] and client-last-transaction-time [RFC4388].
This time is in the context of the DHCPv4 server. This time is in the context of the DHCPv4 server who placed this
option in a message.
This is an integer in network byte order. This is an integer in network byte order.
The code for this option is TBD2. The length of this option is 4 The code for this option is TBD2. The length of this option is 4
octets. octets.
DHCPv4 Server DHCPv4 Server
Code Len base-time Code Len base-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD2| 4 | t1 | t2 | t3 | t4 | | TBD2| 4 | t1 | t2 | t3 | t4 |
skipping to change at page 15, line 14 skipping to change at page 14, line 14
6.2.4. start-time-of-state 6.2.4. start-time-of-state
The start-time-of-state option allows the receiver to determine the The start-time-of-state option allows the receiver to determine the
time at which the IP address made the transition into its current time at which the IP address made the transition into its current
state. state.
This MUST NOT be an absolute time, which is equivalent to saying that This MUST NOT be an absolute time, which is equivalent to saying that
this MUST NOT be an absolute number of seconds since Jan 1, 1970. this MUST NOT be an absolute number of seconds since Jan 1, 1970.
Instead, this MUST be the integer number of seconds from the time the Instead, this MUST be the integer number of seconds from the time the
IP address transitioned its current stae to the time specified in the IP address transitioned its current state to the time specified in
base-time option in the same message. the base-time option in the same message.
This is an integer in network byte order. This is an integer in network byte order.
The code for this option is TBD3. The length of this option is 4 The code for this option is TBD3. The length of this option is 4
octets. octets.
Seconds in the past Seconds in the past
Code Len from base-time Code Len from base-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD3| 4 | t1 | t2 | t3 | t4 | | TBD3| 4 | t1 | t2 | t3 | t4 |
skipping to change at page 15, line 37 skipping to change at page 14, line 37
6.2.5. query-start-time 6.2.5. query-start-time
The query-start-time option specifies a start query time to the The query-start-time option specifies a start query time to the
DHCPv4 server. If specified, only bindings that have changed on or DHCPv4 server. If specified, only bindings that have changed on or
after the query-start-time should be included in the response to the after the query-start-time should be included in the response to the
query. query.
The requestor MUST determine the query-start-time using lease The requestor MUST determine the query-start-time using lease
information it has received from the DHCPv4 server. This MUST be an information it has received from the DHCPv4 server. This MUST be an
absolute time in the DHCPv4 server's context (see Section 7 .4). absolute time in the DHCPv4 server's context (see Section 7.4).
Typically (though this is not a requirement) the query-start-time Typically (though this is not a requirement) the query-start-time
option will contain the value most recently received in a base-time option will contain the value most recently received in a base-time
option by the requestor, as this will indicate the last successful option by the requestor, as this will indicate the last successful
communication with the DHCP server. communication with the DHCP server.
This MUST be an absolute time. This MUST be an absolute time.
This is an integer in network byte order. This is an integer in network byte order.
skipping to change at page 16, line 18 skipping to change at page 15, line 18
| TBD4| 4 | t1 | t2 | t3 | t4 | | TBD4| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
6.2.6. query-end-time 6.2.6. query-end-time
The query-end-time option specifies an end query time to the DHCPv4 The query-end-time option specifies an end query time to the DHCPv4
server. If specified, only bindings that have changed on or before server. If specified, only bindings that have changed on or before
the query-end-time should be included in the response to the query. the query-end-time should be included in the response to the query.
The requestor MUST determine the query-end-time based on lease The requestor MUST determine the query-end-time based on lease
information it has received from the DHCPv4 server. This MUST be an information it has received from the DHCPv4 server. This MUST be an
absolute time in the context of the DHCPv4 server. absolute time in the context of the DHCPv4 server.
In the absence of information to the contrary, the requestor SHOULD In the absence of information to the contrary, the requestor SHOULD
assume that the time context of the DHCPv4 server is identical to the assume that the time context of the DHCPv4 server is identical to the
time context of the requestor (see Section 7.4). time context of the requestor (see Section 7.4).
This is an integer in network byte order. This is an integer in network byte order.
The code for this option is TBD5. The length of this option is 4 The code for this option is TBD5. The length of this option is 4
octets. octets.
skipping to change at page 17, line 33 skipping to change at page 16, line 33
5 ABANDONED Server or client flagged address as unusable 5 ABANDONED Server or client flagged address as unusable
6 RESET Lease was freed by some external agent 6 RESET Lease was freed by some external agent
7 REMOTE Address is available to a remote DHCPv4 server 7 REMOTE Address is available to a remote DHCPv4 server
8 TRANSITIONING Address is moving between states 8 TRANSITIONING Address is moving between states
Note that some of these states may be transient and may not appear in Note that some of these states may be transient and may not appear in
normal use. A DHCPv4 server MUST implement at least the AVAILABLE normal use. A DHCPv4 server MUST implement at least the AVAILABLE
and ACTIVE states, and SHOULD implement at least the ABANDONED and and ACTIVE states, and SHOULD implement at least the ABANDONED and
RESET states. RESET states.
Note the states AVAILABLE and REMOTE are relative to the current
server. An address that is available to the current server should
show AVAILABLE on that server, and if another server is involved with
that address as well, on that other server it should show as REMOTE.
The dhcp-state option SHOULD contain ACTIVE when it appears in a The dhcp-state option SHOULD contain ACTIVE when it appears in a
DHCPLEASEACTIVE message. A DHCPv4 server MAY choose to not send a DHCPLEASEACTIVE message. A DHCPv4 server MAY choose to not send a
dhcp-state option in a DHCPLEASEACTIVE message, and a requestor dhcp-state option in a DHCPLEASEACTIVE message, and a requestor
SHOULD assume that the dhcp-state is ACTIVE if no dhcp-state option SHOULD assume that the dhcp-state is ACTIVE if no dhcp-state option
appears in a DHCPLEASEACTIVE message. appears in a DHCPLEASEACTIVE message.
The reference to local and remote relate to possible use in an The reference to local and remote relate to possible use in an
environment that includes multiple servers cooperating to provide an environment that includes multiple servers cooperating to provide an
increased availability solution. In this case, an IP address with increased availability solution. In this case, an IP address with
the state of AVAILABLE is available to the local server, while one the state of AVAILABLE is available to the local server, while one
skipping to change at page 20, line 22 skipping to change at page 20, line 4
7. Requestor Behavior 7. Requestor Behavior
7.1. Connecting and General Processing 7.1. Connecting and General Processing
A Requestor attempts to establish a TCP connection to a DHCPv4 Server A Requestor attempts to establish a TCP connection to a DHCPv4 Server
in order to initiate a Leasequery exchange. If the attempt fails, in order to initiate a Leasequery exchange. If the attempt fails,
the Requestor MAY retry. the Requestor MAY retry.
If Bulk Leasequery is terminated prematurely by a DHCPLEASEQUERYDONE If Bulk Leasequery is terminated prematurely by a DHCPLEASEQUERYDONE
with a dhcp-message status-code of QueryTerminated or by the failure with a status-code option with a status-code of QueryTerminated or by
of the connection over which it was being submitted, the requestor the failure of the connection over which it was being submitted, the
MAY retry the request after the creation of a new connection. requestor MAY retry the request after the creation of a new
connection.
Messages from the DHCPv4 server come as multiple responses to a Messages from the DHCPv4 server come as multiple responses to a
single DHCPBULKLEASEQUERY message. Thus, each DHCPBULKLEASEQUERY single DHCPBULKLEASEQUERY message. Thus, each DHCPBULKLEASEQUERY
request MUST have an xid (transaction-id) unique on the connection on request MUST have an xid (transaction-id) unique on the connection on
which it is sent. All of the messages which come as a response to which it is sent. All of the messages which come as a response to
that message will contain the same xid as the request. It is the xid that message will contain the same xid as the request. It is the xid
which allows the data-streams of two different DHCPBULKLEASEQUERY which allows the data-streams of two different DHCPBULKLEASEQUERY
requests to be demultiplexed by the requestor. requests to be demultiplexed by the requestor.
7.2. Forming a Bulk Leasequery 7.2. Forming a Bulk Leasequery
skipping to change at page 21, line 36 skipping to change at page 21, line 15
requested value is included in the DHCPBULKLEASEQUERY request. requested value is included in the DHCPBULKLEASEQUERY request.
o Query by Remote-Id o Query by Remote-Id
In a Query by Remote-Id, a remote-id sub-option containing the In a Query by Remote-Id, a remote-id sub-option containing the
requested value is included in the relay-agent-information requested value is included in the relay-agent-information
option of the DHCPBULKLEASEQUERY request. option of the DHCPBULKLEASEQUERY request.
o Query by Relay-Id o Query by Relay-Id
IN a Query by Relay-Id, a relay-id sub-option [RelayId] In a Query by Relay-Id, a relay-id sub-option [RelayId]
containing the requested value is included in the relay-agent- containing the requested value is included in the relay-agent-
information option of the DHCPBULKLEASEQUERY request. information option of the DHCPBULKLEASEQUERY request.
o Query for All Configured IP Addresses o Query for All Configured IP Addresses
A Query for All Configured IP addresses is signaled by the A Query for All Configured IP addresses is signaled by the
absence of any other primary query. absence of any other primary query.
There are three qualifiers which can be applied to any of the above There are three qualifiers which can be applied to any of the above
primary queries. These qualifiers can appear individually or primary queries. These qualifiers can appear individually or
skipping to change at page 24, line 6 skipping to change at page 23, line 34
also contain information about the last DHCPv4 client that was also contain information about the last DHCPv4 client that was
bound to this IP address. The message may contain a non-zero bound to this IP address. The message may contain a non-zero
chaddr, htype, and hlen and possibly additional options in this chaddr, htype, and hlen and possibly additional options in this
case. case.
o DHCPLEASEQUERYDONE o DHCPLEASEQUERYDONE
A response of DHCPLEASEQUERYDONE indicates that the server has A response of DHCPLEASEQUERYDONE indicates that the server has
completed its response to the query, and that no more messages completed its response to the query, and that no more messages
will be sent in response to the DHCPBULKLEASEQUERY. More details will be sent in response to the DHCPBULKLEASEQUERY. More details
will sometimes be available in the received dhcp-message option will sometimes be available in the received status-code option
in the DHCPLEASEQUERYDONE message. If there is no dhcp-message in the DHCPLEASEQUERYDONE message. If there is no status-code
option in the DHCPLEASEQUERYDONE message, then the query option in the DHCPLEASEQUERYDONE message, then the query
completed successfully. completed successfully.
Note that a query which returned no data, that is a Note that a query which returned no data, that is a
DHCPBULKLEASEQUERY request followed by a DHCPLEASEQUERYDONE DHCPBULKLEASEQUERY request followed by a DHCPLEASEQUERYDONE
response, is considered a successful query in that no errors response, is considered a successful query in that no errors
occurred during the processing. It is not considered an error occurred during the processing. It is not considered an error
to have no information to return to a DHCPBULKLEASEQUERY to have no information to return to a DHCPBULKLEASEQUERY
request. request.
skipping to change at page 25, line 13 skipping to change at page 24, line 40
some form, it has a requirement to store a variety of time values, some form, it has a requirement to store a variety of time values,
and some of these will be time in the context of the requestor and and some of these will be time in the context of the requestor and
some will be time in the context of the DHCPv4 server. some will be time in the context of the DHCPv4 server.
When receiving a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message from When receiving a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message from
the DHCPv4 server, the message will contain a base-time option. The the DHCPv4 server, the message will contain a base-time option. The
time contained in this base-time option is in the context of the time contained in this base-time option is in the context of the
DHCPv4 server. As such, it is an ideal time to save and use as input DHCPv4 server. As such, it is an ideal time to save and use as input
to a DHCPBULKLEASEQUERY in the query-start-time or query-end-time to a DHCPBULKLEASEQUERY in the query-start-time or query-end-time
options, should the requestor need to ever issue a DHCPBULKLEASEQUERY options, should the requestor need to ever issue a DHCPBULKLEASEQUERY
message using those options as part of a later query. message using those options as part of a later query, since those
options require a time in the context of the DHCPv4 server.
In addition to saving the base-time for possible future use in a In addition to saving the base-time for possible future use in a
query-start-time option, the base-time is used as part of the query-start-time or query-end-time option, the base-time is used as
conversion of the other times in the Leasequery message to values part of the conversion of the other times in the Leasequery message
which are meaningful in the context of the requestor. to values which are meaningful in the context of the requestor.
In systems whose clocks are synchronized, perhaps using NTP, the In systems whose clocks are synchronized, perhaps using NTP, the
clock skew will usually be zero, which is not only acceptable, but clock skew will usually be zero, which is not only acceptable, but
desired. desired.
7.5. Querying Multiple Servers 7.5. Querying Multiple Servers
A Bulk Leasequery requestor MAY be configured to attempt to connect A Bulk Leasequery requestor MAY be configured to attempt to connect
to and query from multiple DHCPv4 servers in parallel. The DHCPv4 to and query from multiple DHCPv4 servers in parallel. The DHCPv4
Leasequery specification [RFC4388] includes a discussion about Leasequery specification [RFC4388] includes a discussion about
reconciling binding data received from multiple DHCPv4 servers. reconciling binding data received from multiple DHCPv4 servers.
In addition, the algorithm in the Section 7.6 should be used. In addition, the algorithm in Section 7.6 should be used.
7.6. Making Sense Out of Multiple Responses Concerning a Single IPv4 7.6. Making Sense Out of Multiple Responses Concerning a Single IPv4
Address Address
Any requestor of an Bulk Leasequery MUST be prepared for multiple Any requestor of an Bulk Leasequery MUST be prepared for multiple
responses to arrive for a particular IPv4 address from multiple responses to arrive for a particular IPv4 address from multiple
different DHCPv4 servers. The following algorithm SHOULD be used to different DHCPv4 servers. The following algorithm SHOULD be used to
decide if the information just received is more up to date (i.e., decide if the information just received is more up to date (i.e.,
better) than the best existing information. In the discussion below, better) than the best existing information. In the discussion below,
the information that is received from a DHCPv4 server about a the information that is received from a DHCPv4 server about a
skipping to change at page 28, line 20 skipping to change at page 27, line 48
connections. Port numbers are discussed in Section 6.3. Servers connections. Port numbers are discussed in Section 6.3. Servers
MUST be able to limit the number of concurrently accepted and active MUST be able to limit the number of concurrently accepted and active
connections. The value BULK_LQ_MAX_CONNS SHOULD be the default; connections. The value BULK_LQ_MAX_CONNS SHOULD be the default;
implementations MAY permit the value to be configurable. Connections implementations MAY permit the value to be configurable. Connections
SHOULD be accepted and, if the number of connections is over SHOULD be accepted and, if the number of connections is over
BULK_LQ_MAX_CONNS, they SHOULD be closed immediately. BULK_LQ_MAX_CONNS, they SHOULD be closed immediately.
Servers MAY restrict Bulk Leasequery connections and Servers MAY restrict Bulk Leasequery connections and
DHCPBULKLEASEQUERY messages to certain requestors. Connections not DHCPBULKLEASEQUERY messages to certain requestors. Connections not
from permitted requestors SHOULD be closed immediately, to avoid from permitted requestors SHOULD be closed immediately, to avoid
server connection resource exhaustion. Servers MAY restrict some server connection resource exhaustion. Servers MAY restrict some
requestors to certain query types. Servers MAY reply to queries that requestors to certain query types. Servers MAY reply to queries that
are not permitted with the DHCPLEASEQUERYDONE message with a dhcp- are not permitted with the DHCPLEASEQUERYDONE message with a status-
message status of NotAllowed, or MAY simply close the connection. code option status of NotAllowed, or MAY simply 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 an BULK_LQ_DATA_TIMEOUT. We make this connection after an BULK_LQ_DATA_TIMEOUT. We make this
recommendation to allow servers to control the period of time they recommendation to allow servers to control the period of time they
are willing to wait before abandoning an inactive connection, are willing to wait before abandoning an inactive connection,
independent of the TCP implementations they may be using. independent of the TCP implementations they may be using.
8.2. Replying to a Bulk Leasequery 8.2. Replying to a Bulk Leasequery
If the connection becomes blocked while the server is attempting to If the connection becomes blocked while the server is attempting to
send reply messages, the server SHOULD be prepared to terminate the send reply messages, the server SHOULD be prepared to terminate the
TCP connection after BULK_LQ_DATA_TIMEOUT. TCP connection after BULK_LQ_DATA_TIMEOUT.
Every Bulk Leasequery request MUST be terminated by sending a final Every Bulk Leasequery request MUST be terminated by sending a final
DHCPLEASEQUERYDONE message if such a message can be sent. The DHCPLEASEQUERYDONE message if such a message can be sent. The
DHCPLEASEQUERYDONE message MUST have a dhcp-message status if the DHCPLEASEQUERYDONE message MUST have a status-code option status if
termination was other than successful, and SHOULD NOT contain a the termination was other than successful, and SHOULD NOT contain a
dhcp-message status if the termination was successful. status-code option status if the termination was successful.
If the DHCPv4 server encounters an error during processing of the If the DHCPv4 server encounters an error during processing of the
DHCPBULKLEASEQUERY message, either during initial processing or later DHCPBULKLEASEQUERY message, either during initial processing or later
during the message processing, it SHOULD send a DHCPLEASEQUERYDONE during the message processing, it SHOULD send a DHCPLEASEQUERYDONE
containing a status dhcp-message option. It MAY close the connection containing a status-code option. It MAY close the connection after
after this error is signaled, but that is not required. this error is signaled, but that is not required.
If the server does not find any bindings satisfying a query, it MUST If the server does not find any bindings satisfying a query, it MUST
send a DHCPLEASEQUERYDONE. It SHOULD NOT include a dhcp-message send a DHCPLEASEQUERYDONE. It SHOULD NOT include a status-code
option with a Success status unless there is a useful string to option with a Success status unless there is a useful string to
include in the dhcp-message option. Otherwise, the server sends each include in the status-code option. Otherwise, the server sends each
binding's data in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message. binding's data in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message.
The response to a DHCPBULKLEASEQUERY may involve examination of The response to a DHCPBULKLEASEQUERY may involve examination of
multiple DHCPv4 IP address bindings maintained by the DHCPv4 server. multiple DHCPv4 IP address bindings maintained by the DHCPv4 server.
The Bulk Leasequery protocol does not require any ordering of the IP The Bulk Leasequery protocol does not require any ordering of the IP
addresses returned in DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED addresses returned in DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED
messages. messages.
When responding to a DHCPBULKLEASEQUERY message, the DHCPv4 server When responding to a DHCPBULKLEASEQUERY message, the DHCPv4 server
MUST NOT send more than one message for each applicable IP address, MUST NOT send more than one message for each applicable IP address,
even if the state of some of those IP addresses changes during the even if the state of some of those IP addresses changes during the
processing of the message. Updates to such IP address state are processing of the message. Updates to such IP address state are
already handled by normal protocol processing, so no special effort already handled by normal protocol processing, so no special effort
is needed here. (I hope!) is needed here.
If the ciaddr, yiaddr, or siaddr is non-zero in a DHCPBULKLEASEQUERY If the ciaddr, yiaddr, or siaddr is non-zero in a DHCPBULKLEASEQUERY
request, the request must be terminated immediately by a request, the request must be terminated immediately by a
DHCPLEASEQUERYDONE message with a dhcp-message status of DHCPLEASEQUERYDONE message with a status-code status of
MalformedQuery. MalformedQuery.
Any DHCPBULKLEASEQUERY which has more than one of the following Any DHCPBULKLEASEQUERY which has more than one of the following
primary query types specified MUST be terminated immediately by a primary query types specified MUST be terminated immediately by a
DHCPLEASEQUERYDONE message with a dhcp-message status code of DHCPLEASEQUERYDONE message with a status-code option status code of
NotAllowed. NotAllowed.
The allowable queries in a DHCPBULKLEASEQUERY message are processed The allowable queries in a DHCPBULKLEASEQUERY message are processed
as follows. Note that the descriptions of the primary queries below as follows. Note that the descriptions of the primary queries below
must be constrained by the actions of any of the three qualifiers must be constrained by the actions of any of the three qualifiers
described subsequently as well. described subsequently as well.
The following table discusses how to process the various queries. The following table discusses how to process the various queries.
For information on how to identify the query, see the information in For information on how to identify the query, see the information in
Section 7.2. Section 7.2.
skipping to change at page 33, line 43 skipping to change at page 33, line 27
DHCPLEASEQUERYDONE message over that connection and if there is no DHCPLEASEQUERYDONE message over that connection and if there is no
current query outstanding for that connection. It should clear this current query outstanding for that connection. It should clear this
timer if a query arrives over that connection. If the timer expires, timer if a query arrives over that connection. If the timer expires,
the DHCPv4 server should close the connection. the DHCPv4 server should close the connection.
The server MUST close its end of the TCP connection if it encounters The server MUST close its end of the TCP connection if it encounters
an error sending data on the connection. The server MUST close its an error sending data on the connection. The server MUST close its
end of the TCP connection if it finds that it has to abort an in- end of the TCP connection if it finds that it has to abort an in-
process request. A server aborting an in-process request SHOULD process request. A server aborting an in-process request SHOULD
attempt to signal that to its requestors by using the QueryTerminated attempt to signal that to its requestors by using the QueryTerminated
status code in the dhcp-message option in a DHCPLEASEQUERYDONE status code in the status-code option in a DHCPLEASEQUERYDONE
message, including a message string indicating details of the reason message, including a message string indicating details of the reason
for the abort. If the server detects that the requesting end of the for the abort. If the server detects that the requesting end of the
connection has been closed, the server MUST close its end of the connection has been closed, the server MUST close its end of the
connection. connection.
9. Security Considerations 9. Security Considerations
The "Security Considerations" section of [RFC2131] details the The "Security Considerations" section of [RFC2131] details the
general threats to DHCPv4. The DHCPv4 Leasequery specification general threats to DHCPv4. The DHCPv4 Leasequery specification
[RFC4388] describes recommendations for the Leasequery protocol, [RFC4388] describes recommendations for the Leasequery protocol,
skipping to change at page 34, line 40 skipping to change at page 34, line 21
10. IANA Considerations 10. IANA Considerations
This document defines two new name spaces associated with DHCPv4 This document defines two new name spaces associated with DHCPv4
options: options:
1. Status code values for the status-code option, TBD1. 1. Status code values for the status-code option, TBD1.
2. DHCP state values for the dhcp-state option, TBD6. 2. DHCP state values for the dhcp-state option, TBD6.
IANA has established a registry of values for these two name IANA has established a registry of values for these two name spaces.
spaces. These name spaces will be managed by the IANA. New values These name spaces will be managed by IANA. New values for these name
for these name spaces may only be defined by IETF Consensus, as spaces may only be defined by IETF Consensus, as described in
described in [RFC5226]. Basically, this means that they are [RFC5226]. Basically, this means that they are defined by RFCs
defined by RFCs approved by the IESG. approved by the IESG.
IANA is requested to assign the following new values for this IANA is requested to assign the following new values for this
document. See Section 6.2 for details. document. See Section 6.2 for details.
1. A dhcp-message-type of 14 for DHCPBULKLEASEQUERY. 1. A dhcp-message-type of TBD8 for DHCPBULKLEASEQUERY.
2. A dhcp-message-type of 15 for DHCPLEASEQUERYDONE. 2. A dhcp-message-type of TBD9 for DHCPLEASEQUERYDONE.
3. An option code of TBD1 for status-code. 3. An option code of TBD1 for status-code.
4. An option code of TBD2 for base-time. 4. An option code of TBD2 for base-time.
5. An option code of TBD3 for start-time-of-state. 5. An option code of TBD3 for start-time-of-state.
6. An option code of TBD4 for query-start-time. 6. An option code of TBD4 for query-start-time.
7. An option code of TBD5 for query-end-time. 7. An option code of TBD5 for query-end-time.
8. An option code of TBD6 for dhcp-state. 8. An option code of TBD6 for dhcp-state.
9. An option code of TBD7 for data-source. 9. An option code of TBD7 for data-source.
10.Values for status code in a status-code option (option TBD1): 10.Values for status code in a status-code option (option TBD1):
Name status-code Name status-code
---- ----------- ---- -----------
Success 000 Success 000
UnspecFail 001 UnspecFail 001
QueryTerminated 002 QueryTerminated 002
MalformedQuery 003 MalformedQuery 003
NotAllowed 004 NotAllowed 004
11.Values for dhcp-state (option TBD6): 11.Values for dhcp-state (option TBD6):
State State
----- -----
1 AVAILABLE 1 AVAILABLE
2 ACTIVE 2 ACTIVE
3 EXPIRED 3 EXPIRED
4 RELEASED 4 RELEASED
5 ABANDONED 5 ABANDONED
6 RESET 6 RESET
7 REMOTE 7 REMOTE
8 TRANSITIONING 8 TRANSITIONING
12.Additional type field values for the Virtual Subnet Selection 12.Additional type field values for the Virtual Subnet Selection Type
Type and Information [VpnId]: and Information [VpnId]:
Type VSS Information format: Type VSS Information format:
0 NVT ASCII VPN identifier 0 NVT ASCII VPN identifier
1 RFC2685 VPN-ID 1 RFC2685 VPN-ID
2-253 Not Allowed 2-253 Not Allowed
254 All VPN's. (wildcard; only allowed in 254 All VPN's. (wildcard; only allowed in
DHCPBULKLEASEQUERY messages) DHCPBULKLEASEQUERY messages)
255 Global, default VPN. 255 Global, default VPN.
11. Acknowledgements 11. Acknowledgements
This draft is a collaboration between the authors of draft-dtv-dhc- This draft is a collaboration between the authors of draft-dtv-dhc-
dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk- dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk-
leasequery-00.txt. Both documents acknowledged that significant text leasequery-00.txt. Both documents acknowledged that significant text
as well as important ideas were borrowed in whole or in part from the as well as important ideas were borrowed in whole or in part from the
DHCPv6 Bulk Leasequery RFC, [RFC5460] written by Mark Stapp. Further DHCPv6 Bulk Leasequery RFC, [RFC5460] written by Mark Stapp. Further
suggestions and improvements were made by participants in the DHC suggestions and improvements were made by participants in the DHC
working group, including Alfred Hoenes. working group, including Alfred Hoenes.
skipping to change at page 38, line 4 skipping to change at page 37, line 24
EMail: kkinnear@cisco.com EMail: kkinnear@cisco.com
Bernie Volz Bernie Volz
Cisco Systems Cisco Systems
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
Phone: (978) 936-0000 Phone: (978) 936-0000
EMail: volz@cisco.com EMail: volz@cisco.com
Neil Russell Neil Russell
Wakefield, MA 01880 Nokia
5 Wayside Drive
Burlington, MA 01803
EMail: neilerussell@gmail.com EMail: neil.russell@nokia.com
Mark Stapp Mark Stapp
Cisco Systems Cisco Systems
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
Phone: (978) 936-0000 Phone: (978) 936-0000
EMail: mjs@cisco.com EMail: mjs@cisco.com
skipping to change at page 38, line 37 skipping to change at page 38, line 20
Bharat Joshi Bharat Joshi
Infosys Technologies Ltd. Infosys Technologies Ltd.
44 Electronics City, Hosur Road 44 Electronics City, Hosur Road
Bangalore 560 100 Bangalore 560 100
India India
EMail: bharat_joshi@infosys.com EMail: bharat_joshi@infosys.com
URI: http://www.infosys.com/ URI: http://www.infosys.com/
Pavan Kurapati Pavan Kurapati
Infosys Technologies Ltd. Juniper Networks Ltd.
44 Electronics City, Hosur Road Embassy Prime Buildings, C.V.Raman Nagar
Bangalore 560 100 Bangalore 560 093
India India
EMail: pavan_kurapati@infosys.com Email: kurapati@juniper.net
URI: http://www.infosys.com/ URI: http://www.juniper.net/
 End of changes. 62 change blocks. 
107 lines changed or deleted 119 lines changed or added

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