draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt   draft-ietf-dhc-dhcpv4-bulk-leasequery-02.txt 
DHC Working Group Kim Kinnear DHC Working Group Kim Kinnear
Internet Draft Bernie Volz Internet Draft Bernie Volz
Intended Status: Standards Track Neil Russell Intended Status: Standards Track Mark Stapp
Expires: April 26, 2010 Mark Stapp Expires: September 5, 2010 Cisco Systems, Inc.
Cisco Systems, Inc.
D. Rao D. Rao
B. Joshi B. Joshi
P. Kurapati P. Kurapati
Infosys Technologies Ltd. Infosys Technologies Ltd.
October 26, 2009 Neil Russell
March 5, 2010
Bulk DHCPv4 Lease Query Bulk DHCPv4 Lease Query
<draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt> <draft-ietf-dhc-dhcpv4-bulk-leasequery-02.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 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2010 This Internet-Draft will expire on September 5, 2010
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Abstract Abstract
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.................................................. 4 2. Terminology.................................................. 5
3. Design Goals................................................. 6 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............... 7 3.2. Lessen need for Caching and Negative Caching............... 8
3.3. Antispoofing in 'Fast Path'................................ 7 3.3. Antispoofing in 'Fast Path'................................ 8
3.4. Minimize data transmission................................. 7 3.4. Minimize data transmission................................. 8
4. Protocol Overview............................................ 8 4. Protocol Overview............................................ 8
5. Interaction Between UDP Leasequery and Bulk Leasequery....... 9 5. Interaction Between UDP Leasequery and Bulk Leasequery....... 10
6. Message and Option Definitions............................... 10 6. Message and Option Definitions............................... 11
6.1. Message Framing for TCP.................................... 10 6.1. Message Framing for TCP.................................... 11
6.2. New or Changed Options..................................... 11 6.2. New or Changed Options..................................... 12
6.3. Connection and Transmission Parameters..................... 19 6.3. Connection and Transmission Parameters..................... 19
7. Requestor Behavior........................................... 19 7. Requestor Behavior........................................... 20
7.1. Connecting and General Processing.......................... 19 7.1. Connecting and General Processing.......................... 20
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.................................. 24 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.... 25 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.............................................. 27 8. Server Behavior.............................................. 28
8.1. Accepting Connections...................................... 27 8.1. Accepting Connections...................................... 28
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............................... 33
8.5. Closing Connections........................................ 33 8.5. Closing Connections........................................ 33
9. Security Considerations...................................... 33 9. Security Considerations...................................... 34
10. IANA Considerations......................................... 34 10. IANA Considerations......................................... 34
11. Acknowledgements............................................ 35 11. Acknowledgements............................................ 36
12. References.................................................. 35 12. References.................................................. 36
12.1. Normative References...................................... 35 12.1. Normative References...................................... 36
12.2. Informative References.................................... 36 12.2. Informative References.................................... 37
Authors' Addresses............................................... 37 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 |
| | | Relay Agent | | | | Relay Agent |
+--------+ +--------------+ +--------+ +--------------+
| | | |
+------+ +------+ +------+ +------+
|Modem1| |Modem2| |Modem1| |Modem2|
+------+ +------+ +------+ +------+
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|Host1| |Host2| |Host3| |Node1| |Node2| |Node3|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 1: Example DHCPv4 configuration Figure 1: Example DHCPv4 configuration
DHCPv4 relay agents receive DHCPv4 messages and frequently append a DHCPv4 relay agents receive DHCPv4 messages and frequently append a
relay agent information option [RFC3046] before relaying them to the relay agent information option [RFC3046] before relaying them to the
configured DHCPv4 servers (see Figure 1). In this process, some relay configured DHCPv4 servers (see Figure 1). In this process, some relay
agents also glean lease information sent by the server and cache it agents also glean lease information sent by the server and cache it
locally. This information is used for a variety of purposes. Two locally. This information is used for a variety of purposes. Two
examples are prevention of spoofing attempts from the DHCPv4 clients, examples are prevention of spoofing attempts from the DHCPv4 clients,
skipping to change at page 5, line 6 skipping to change at page 5, line 6
Some applications require the ability to query the server without Some applications require the ability to query the server without
waiting for traffic from or to clients. This query capability in turn waiting for traffic from or to clients. This query capability in turn
requires an underlying transport more suitable to the bulk requires an underlying transport more suitable to the bulk
transmission of data. transmission of data.
This document extends the DHCPv4 Leasequery protocol to add support This document extends the DHCPv4 Leasequery protocol to add support
for queries that address these additional requirements. There may be for queries that address these additional requirements. There may be
many thousands of DHCPv4 bindings returned as the result of a single many thousands of DHCPv4 bindings returned as the result of a single
request, so TCP [RFC4614] is specified for efficiency of data request, so TCP [RFC4614] is specified for efficiency of data
transfer. We define several additional query types, each of which transfer. We define several additional query types, each of which
could return multiple responses, in order to meet a variety of can return multiple responses, in order to meet a variety of
requirements. requirements.
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the following terms: This document uses the following terms:
skipping to change at page 5, line 29 skipping to change at page 5, line 29
A 32-bit quantity containing the number of seconds since Jan 1, A 32-bit quantity containing the number of seconds since Jan 1,
1970. 1970.
o "access concentrator" o "access concentrator"
An access concentrator is a router or switch at the broadband An access concentrator is a router or switch at the broadband
access provider's edge of a public broadband access network. access provider's edge of a public broadband access network.
This document assumes that the access concentrator includes the This document assumes that the access concentrator includes the
DHCPv4 relay agent functionality. For example, a CMTS (Cable DHCPv4 relay agent functionality. For example, a CMTS (Cable
Modem Termination System) in Cable environment or a DSLAM Modem Termination System) in Cable environment or a DSLAM
(Digital Subscriber Line Multiplexer) in a DSL environment. (Digital Subscriber Line Access Multiplexer) in a DSL
environment.
o "active binding" o "active binding"
An IP address with an active binding refers to an IP address An IP address with an active binding refers to an IP address
which is currently associated with a DHCPv4 client where that which is currently associated with a DHCPv4 client where that
DHCPv4 client has the right to use the IP address. DHCPv4 client has the right to use the IP address.
o "Bulk Leasequery" o "Bulk Leasequery"
Requesting and receiving the existing DHCPv4 address binding Requesting and receiving the existing DHCPv4 address binding
skipping to change at page 6, line 14 skipping to change at page 6, line 15
While it is easy to think that this can be calculated precisely While it is easy to think that this can be calculated precisely
after one message is received by a requestor from a DHCPv4 after one message is received by a requestor from a DHCPv4
server, a more accurate value is derived from continuously server, a more accurate value is derived from continuously
examining the instantaneous value developed from each message examining the instantaneous value developed from each message
received from a DHCPv4 server and using it to make small received from a DHCPv4 server and using it to make small
adjustments to the existing value held in the requestor. adjustments to the existing value held in the requestor.
o "DHCPv4 client" o "DHCPv4 client"
A DHCPv4 client is an Internet host using DHCPv4 to obtain A DHCPv4 client is an Internet node using DHCPv4 to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
o "DHCPv4 relay agent" o "DHCPv4 relay agent"
A DHCPv4 relay agent is a third-party agent that transfers BOOTP A DHCPv4 relay agent is a third-party agent that transfers BOOTP
and DHCPv4 messages between clients and servers residing on and DHCPv4 messages between clients and servers residing on
different subnets, per [RFC951] and [RFC1542]. different subnets, per [RFC951] and [RFC1542].
o "DHCPv4 server" o "DHCPv4 server"
A DHCPv4 server is an Internet host that returns configuration A DHCPv4 server is an Internet node that returns configuration
parameters to DHCPv4 clients. parameters to DHCPv4 clients.
o "DSLAM" o "DSLAM"
Digital Subscriber Line Multiplexer. Digital Subscriber Line Multiplexer.
o "downstream" o "downstream"
Refers to a direction away from the central part of a network Refers to a direction away from the central part of a network
and toward the edge. In a DHCPv4 context, typically refers to a and toward the edge. In a DHCPv4 context, typically refers to a
network direction which is away from the DHCPv4 server. network direction which is away from the DHCPv4 server.
o "IP address" o "IP address"
In this document, the term "IP address" refers to an IPv4 IP In this document, the term "IP address" refers to an IPv4 IP
address. address.
o "IP address binding" o "IP address binding"
The information that a DHCPv4 server keeps regarding the The information that a DHCPv4 server keeps regarding the
relationship between a DHCPv4 client and an IPv4 IP address. relationship between a DHCPv4 client and an IP address. This
This includes the identity of the DHCPv4 client and the includes the identity of the DHCPv4 client and the expiration
expiration time, if any, of any lease that client has on a time, if any, of any lease that client has on a particular IP
particular IPv4 address. In some contexts, this may include address. In some contexts, this may include information on IP
information on IP addresses that are currently associated with addresses that are currently associated with DHCPv4 clients, and
DHCPv4 clients, and in others it may also include IP addresses in others it may also include IP addresses with no current
with no current association to a DHCPv4 client. association to a DHCPv4 client.
o "MAC address" o "MAC address"
In the context of a DHCPv4 message, a MAC address consists of In the context of a DHCPv4 message, a MAC address consists of
the fields: hardware type "htype", hardware length "hlen", and the fields: hardware type "htype", hardware length "hlen", and
client hardware address "chaddr". client hardware address "chaddr".
o "upstream" o "upstream"
Refers to a direction toward the central part of a network and Refers to a direction toward the central part of a network and
skipping to change at page 7, line 46 skipping to change at page 7, line 48
address binding information available in the DHCPv4 server. The address binding information available in the DHCPv4 server. The
mechanism should also allow an Access Concentrator to retrieve mechanism should also allow an Access Concentrator to retrieve
consolidated IP address binding information for either the entire consolidated IP address binding information for either the entire
access concentrator or a single connection/circuit. access concentrator or a single connection/circuit.
3.1. Information Acquisition before Data Starts 3.1. Information Acquisition before Data Starts
The existing data driven approach required by [RFC4388] means that The existing data driven approach required by [RFC4388] means that
the Leasequeries can only be performed after an Access Concentrator the Leasequeries can only be performed after an Access Concentrator
receives data. To implement antispoofing, the concentrator must drop receives data. To implement antispoofing, the concentrator must drop
packets for each client until it gets lease information from DHCPv4 packets for each client until it gets lease information from the
server for that client. If an Access Concentrator finishes the DHCPv4 server for that client. If an Access Concentrator finishes the
Leasequeries before it starts receiving data, then there is no need Leasequeries before it starts receiving data, then there is no need
to drop legitimate packets. In this way, outage time may be reduced. to drop legitimate packets. In this way, outage time may be reduced.
3.2. Lessen need for Caching and Negative Caching 3.2. Lessen need for Caching and Negative Caching
The result of a single Leasequery should be cached, whether that The result of a single Leasequery should be cached, whether that
results in a positive or negative cache, in order to remember that results in a positive or negative cache, in order to remember that
the Leasequery was performed. This caching is required to limit the the Leasequery was performed. This caching is required to limit the
traffic imposed upon a DHCPv4 server by Leasequeries for information traffic imposed upon a DHCPv4 server by Leasequeries for information
already received. already received.
skipping to change at page 8, line 38 skipping to change at page 8, line 40
information without duplicating the information it has recovered from information without duplicating the information it has recovered from
its own stable storage. its own stable storage.
Bulk Leasequery allows the specification of a query-start-time as Bulk Leasequery allows the specification of a query-start-time as
well as a query-end-time. Use of query-times allows a network well as a query-end-time. Use of query-times allows a network
element that periodically commits information to stable storage to element that periodically commits information to stable storage to
recover just what it lost since the last commit. recover just what it lost since the last commit.
4. Protocol Overview 4. Protocol Overview
The Bulk Leasequery mechanism is modeled on the existing individual The DHCPv4 Bulk Leasequery mechanism is modeled on the existing
Leasequery protocol in [RFC4388] as well as related work on DHCPv6 individual DHCPv4 Leasequery protocol in [RFC4388] as well as related
Bulk Leasequery [RFC5460]. A Bulk Leasequery requestor opens a TCP work on DHCPv6 Bulk Leasequery [RFC5460]. A Bulk Leasequery requestor
connection to a DHCPv4 Server, using the DHCPv4 port 67. Note that opens a TCP connection to a DHCPv4 Server, using the DHCPv4 port 67.
this implies that the Leasequery requestor has server IP address(es) Note that this implies that the Leasequery requestor has server IP
available via configuration or some other means, and that it has address(es) available via configuration or some other means, and that
unicast IP reachability to the DHCPv4 server. No relaying of Bulk it has unicast IP reachability to the DHCPv4 server. No relaying of
Leasequery messages is specified. Bulk Leasequery messages is specified.
After establishing a connection, the requestor sends a After establishing a connection, the requestor sends a
DHCPBULKLEASEQUERY message over the connection. DHCPBULKLEASEQUERY message over the connection.
The server uses the message type and additional data in the DHCPv4 The server uses the message type and additional data in the DHCPv4
DHCPBULKLEASEQUERY message to identify any relevant bindings. DHCPBULKLEASEQUERY message to identify any relevant bindings.
In order to support some query types, servers may have to maintain In order to support some query types, servers may have to maintain
additional data structures or otherwise be able to locate bindings additional data structures or otherwise be able to locate bindings
that have been requested by the Leasequery requestor. that have been requested by the Leasequery requestor.
skipping to change at page 12, line 31 skipping to change at page 13, line 12
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 14 DHCPBULKLEASEQUERY
15 DHCPLEASEQUERYDONE 15 DHCPLEASEQUERYDONE
6.2.2. dhcp-message 6.2.2. status-code
The dhcp-message option (option 56) from Section 9.9 of [RFC2132]
requires additional definition for use in the context of a
DHCPBULKLEASEQUERY.
The format of the NVT ASCII message in the dhcp-message option is
specified to have the first three characters appear in a constrained
format. The first three characters MUST be numeric (base 10)
characters.
Encoded in these first three characters is the decimal number
corresponding to a variety of status codes defined below.
The motivation for this constraint of the existing dhcp-message
option is to reduce the number of top-level options used by this
document.
The status code returned in the dhcp-message option allows greater The status code option allows a machine readable value to be returned
detail to be returned regarding the status of a DHCPBULKLEASEQUERY regarding the status of a DHCPBULKLEASEQUERY request.
request. While specified in the Bulk Leasequery document, this
additional specification of the DHCPv4 dhcp-message option may well
be valuable in other circumstances. In those circumstances its scope
should be explicitly defined.
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 56. The length of this option is at least The code for this option is TBD1. The length of this option is a
3 octets. minimum of 1 octect.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | left-number | middle-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| right-number | status-message (if any) ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code 56.
option-len 3 + length of status-message (which may be 0).
left-number NVT ASCII encoded characters representing the Status Status
middle-number base-10 value of the status code, taken Code Len Code Message
right-number from the table below. +------+------+------+------+------+-- --+-----+
| TBD1 | n+1 |status| s1 | s2 | ... | sn |
+------+------+------+------+------+-- --+-----+
status-message An optional NVT ASCII encoded text string The status-code is an octect defined in the table below. The Status
suitable for display to an end user, which Message is an optional NVT ASCII encoded text string suitable for
MUST NOT be null-terminated. It SHOULD display to an end user, which MUST NOT be null-terminated.
start with an NVT ASCII space.
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 dhcp-message 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.
NotAllowed 004 The query or request was understood but was NotAllowed 004 The query or request was understood but was
not allowed in this context. not allowed in this context.
A dhcp-message option MAY appear in the options field of a DHCPv4 A status-code option MAY appear in the options field of a DHCPv4
message. If the dhcp-message option does not appear, it is assumed message. If the status-code option does not appear, it is assumed
that the operation was successful. The dhcp-message option SHOULD that the operation was successful. The status-code option SHOULD NOT
NOT 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.
This is an integer in network byte order. This is an integer in network byte order.
The code for this option is TBD1. 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
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD1| 4 | t1 | t2 | t3 | t4 | | TBD2| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
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. This MUST NOT be an absolute This MUST NOT be an absolute time, which is equivalent to saying that
number of seconds since Jan 1, 1970. Instead, this MUST be an this MUST NOT be an absolute number of seconds since Jan 1, 1970.
integer number of seconds in the past from the time specified in the Instead, this MUST be the integer number of seconds from the time the
base-time option in the same message that the IP address transitioned IP address transitioned its current stae to the time specified in the
into its current state. In the same way that the IP Address Lease base-time option in the same message.
Time option (option 51) encodes a lease time which is a number of
seconds into the future from the time the message was sent, this
option encodes a value which is a number of seconds into the past
from the base-time option included 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 TBD2. 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
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD2| 4 | t1 | t2 | t3 | t4 | | TBD3| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
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 requester MUST compute the query-start-time relative to a lease The requestor MUST determine the query-start-time using lease
it has received from the DHCPv4 server, and MUST specify that time in information it has received from the DHCPv4 server. This MUST be an
terms of the DHCPv4 server's clock. 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.
The code for this option is TBD3. The length of this option is 4 The code for this option is TBD4. The length of this option is 4
octets. octets.
DHCPv4 Server DHCPv4 Server
Code Len query-start-time Code Len query-start-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD3| 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 requester MUST compute the query-end-time relative to a lease it The requestor MUST determine the query-end-time based on lease
has received from the DHCPv4 server, and MUST specify that time in information it has received from the DHCPv4 server. This MUST be an
terms of the DHCPv4 server's clock. absolute time in the context of the DHCPv4 server.
This MUST be an absolute time.
This MUST be a time in the context of the DHCPv4 server. In the
absence of information to the contrary, the requestor SHOULD assume
that the time context of the DHCPv4 server is identical to the time
context of the requestor.
It SHOULD NOT be a time in the context of the requestor. In the absence of information to the contrary, the requestor SHOULD
assume that the time context of the DHCPv4 server is identical to the
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 TBD4. The length of this option is 4 The code for this option is TBD5. The length of this option is 4
octets. octets.
DHCPv4 Server DHCPv4 Server
Code Len query-end-time Code Len query-end-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD4| 4 | t1 | t2 | t3 | t4 | | TBD5| 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
6.2.7. dhcp-state 6.2.7. dhcp-state
The dhcp-state option allows greater detail to be returned than The dhcp-state option allows greater detail to be returned than
allowed by the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types. allowed by the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types.
The code for this option is TBD6. The length of this option is 1 The code for this option is TBD6. The length of this option is 1
octet. octet.
skipping to change at page 18, line 26 skipping to change at page 18, line 26
used when there are two or more servers who might have information used when there are two or more servers who might have information
about a particular IP address binding. Frequently two servers work about a particular IP address binding. Frequently two servers work
together to provide an increased availability solution for the DHCPv4 together to provide an increased availability solution for the DHCPv4
service, and in these cases, both servers will respond to Bulk service, and in these cases, both servers will respond to Bulk
Leasequery requests for the same IP address. Leasequery requests for the same IP address.
The data contained in this option will allow an external process to The data contained in this option will allow an external process to
better discriminate between the information provided by each of the better discriminate between the information provided by each of the
servers servicing this IPv4 address. servers servicing this IPv4 address.
The code for this option is TBD5. The length of this option is 1 The code for this option is TBD7. The length of this option is 1
octet. octet.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD5 | Length | Flags | | TBD7 | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBD5 The option code. TBD7 The option code.
Length The option length, 1 octet. Length The option length, 1 octet.
Flags The Source information for this message. Flags The Source information for this message.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MBZ |R| | MBZ |R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 19, line 12 skipping to change at page 19, line 12
MBZ: MUST BE ZERO (reserved for future use) MBZ: MUST BE ZERO (reserved for future use)
The REMOTE flag is used to indicate where the most recent change of The REMOTE flag is used to indicate where the most recent change of
state (or other interesting change) concerning this IPv4 address took state (or other interesting change) concerning this IPv4 address took
place. If the value is local, then the change took place on the place. If the value is local, then the change took place on the
server from which this message was transmitted. If the value is server from which this message was transmitted. If the value is
remote, then the change took place on some other server, and was made remote, then the change took place on some other server, and was made
known to the server from which this message was transmitted. known to the server from which this message was transmitted.
If this option was requested and it doesn't appear, the the requestor If this option was requested and it doesn't appear, the requestor
SHOULD consider that the data-source was local. SHOULD consider that the data-source was local.
6.2.9. Virtual Subnet Selection Type and Information 6.2.9. Virtual Subnet Selection Type and Information
All of the (sub)options defined in [VpnId] carry identical payloads, All of the (sub)options defined in [VpnId] carry identical payloads,
consisting of a type and additional VSS (Virtual Subnet Selection) consisting of a type and additional VSS (Virtual Subnet Selection)
information. The existing table is extended (see below) with a new information. The existing table is extended (see below) with a new
type 254 to allow specification of a type code which indicates that type 254 to allow specification of a type code which indicates that
all VPN's are to be used to process the Bulk Leasequery. all VPN's are to be used to process the Bulk Leasequery.
Type VSS Information format: Type VSS Information format:
---- ----------------------- ---- -----------------------
0 NVT ASCII VPN identifier 0 NVT ASCII VPN identifier
1 RFC2685 VPN-ID 1 RFC 2685 VPN-ID
2-253 Not Allowed CHANGED -> 2-253 Not Allowed
NEW -> 254 All VPN's (wildcard). NEW -> 254 All VPN's (wildcard)
255 Global, default VPN. 255 Global, default VPN
6.3. Connection and Transmission Parameters 6.3. Connection and Transmission Parameters
DHCPv4 servers that support Bulk Leasequery SHOULD listen for DHCPv4 servers that support Bulk Leasequery SHOULD listen for
incoming TCP connections on the DHCPv4 server port 67. incoming TCP connections on the DHCPv4 server port 67.
Implementations MAY offer to make the incoming port configurable, but Implementations MAY offer to make the incoming port configurable, but
port 67 MUST be the default. Requestors SHOULD make TCP connections port 67 MUST be the default. Requestors SHOULD make TCP connections
to port 67, and MAY offer to make the destination server port to port 67, and MAY offer to make the destination server port
configurable. configurable.
This section presents a table of values used to control Bulk This section presents a table of values used to control Bulk
Leasequery behavior, including recommended defaults. Implementations Leasequery behavior, including recommended defaults. Implementations
MAY make these values configurable. However, configuring too-small MAY make these values configurable. However, configuring too-small
timeout values may lead to harmful behavior both to this application timeout values may lead to harmful behavior both to this application
as well as to other traffic in the network. As a result, timeout as well as to other traffic in the network. As a result, timeout
values smaller than the default values are NOT RECOMMENDED. values smaller than the default values are NOT RECOMMENDED.
Parameter Default Description Parameter Default Description
------------------------------------------- -------------------------------------------
BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout
for both client and server
(see Sections 7 and 8)
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
at the server side (see Section 8.1)
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 dhcp-message status-code of QueryTerminated or by the failure
of the connection over which it was being submitted, the requestor of the connection over which it was being submitted, the requestor
MAY retry the request after the creation of a new connection. 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 a 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
Bulk Leasequery is designed to create a connection which will Bulk Leasequery is designed to create a connection which will
transfer the state of some subset (or possibly all) of the IP address transfer the state of some subset (or possibly all) of the IP address
bindings from the DHCPv4 server to the requestor. The DHCPv4 server bindings from the DHCPv4 server to the requestor. The DHCPv4 server
skipping to change at page 21, line 22 skipping to change at page 21, line 25
DHCPBULKLEASEQUERY request MUST contain only one of these primary DHCPBULKLEASEQUERY request MUST contain only one of these primary
queries. queries.
o Query by MAC address o Query by MAC address
In a Query by MAC address, the chaddr, htype, and hlen of the In a Query by MAC address, the chaddr, htype, and hlen of the
DHCPv4 packet are filled in with the values requested. DHCPv4 packet are filled in with the values requested.
o Query by Client-Id o Query by Client-Id
In a Query by Client-Id, the dhcp-client-id option containing In a Query by Client-Id, a dhcp-client-id option containing the
the requested value is included in the DHCPBULKLEASEQUERY requested value is included in the DHCPBULKLEASEQUERY request.
request.
o Query by Remote-Id o Query by Remote-Id
In a Query by Remote-Id, the remote-id sub-option of the relay- In a Query by Remote-Id, a remote-id sub-option containing the
agent-information option containing the requested value is requested value is included in the relay-agent-information
included in the DHCPBULKLEASEQUERY request. option of the DHCPBULKLEASEQUERY request.
o Query by Relay-Id o Query by Relay-Id
In a Query by Relay-Id, the relay-id sub-option [RelayId] of the IN a Query by Relay-Id, a relay-id sub-option [RelayId]
relay-agent-information option containing the requested value is containing the requested value is included in the relay-agent-
included in 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
together in any combination, but only one of each can appear. together in any combination, but only one of each can appear.
o Query Start Time o Query Start Time
Inclusion of the query-start-time option specifies that only IP Inclusion of a query-start-time option specifies that only IP
address bindings which have changed on or after the time specified address bindings which have changed on or after the time specified
in the query-start-time option should be returned. in the query-start-time option should be returned.
o Query End Time o Query End Time
Inclusion of the query-end-time option specifies that only IP Inclusion of a query-end-time option specifies that only IP address
address bindings which have changed on or before the time specified bindings which have changed on or before the time specified in the
in the query-end-time option should be returned. query-end-time option should be returned.
o VPN Id o VPN Id
If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default
VPN is used to search to satisfy the query specified by the VPN is used to search to satisfy the query specified by the
DHCPBULKLEASEQUERY. Using the vpn-id option [VpnId] allows the DHCPBULKLEASEQUERY. Using the vpn-id option [VpnId] allows the
requestor to specify a single VPN other than the default VPN. In requestor to specify a single VPN other than the default VPN. In
addition, the vpn-id option has been extended as part of this addition, the vpn-id option has been extended as part of this
document to allow specification that all configured VPN's be document to allow specification that all configured VPN's be
searched in order to satisfy the query specified in the searched in order to satisfy the query specified in the
skipping to change at page 22, line 32 skipping to change at page 22, line 34
In all cases, any message returned from a DHCPBULKLEASEQUERY In all cases, any message returned from a DHCPBULKLEASEQUERY
request containing information about an IP address for other than request containing information about an IP address for other than
the default VPN MUST contain a vpn-id option in the message. the default VPN MUST contain a vpn-id option in the message.
Use of the query-start-time or the query-end-time options or both can Use of the query-start-time or the query-end-time options or both can
serve to reduce the amount of data transferred over the TCP serve to reduce the amount of data transferred over the TCP
connection by a considerable amount. connection by a considerable amount.
The TCP connection may become blocked or stop being writable while The TCP connection may become blocked or stop being writable while
the requestor is sending its query. Should this happen, the the requestor is sending its query. Should this happen, the
implementation's behavior is controlled the current value of implementation's behavior is controlled by the current value of
BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this
document, and this value may be overridden by local configuration of document, and this value may be overridden by local configuration of
the operator. the operator.
If this situation is detected, the requester SHOULD start a timer If this situation is detected, the requestor SHOULD start a timer
using the current value of BULK_LQ_DATA_TIMEOUT. If that timer using the current value of BULK_LQ_DATA_TIMEOUT. If that timer
expires, the requester SHOULD terminate the connection. expires, the requestor SHOULD terminate the connection.
7.3. Processing Bulk Replies 7.3. Processing Bulk Replies
The requestor attempts to read a DHCPv4 Leasequery message from the The requestor attempts to read a DHCPv4 Leasequery reply message from
TCP connection. the TCP connection.
The TCP connection may stop delivering reply data (i.e., the The TCP connection may stop delivering reply data (i.e., the
connection stops being readable). Should this happen, the connection stops being readable). Should this happen, the
implementation's behavior is controlled the current value of implementation's behavior is controlled by the current value of
BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this
document, and this value may be overridden by local configuration of document, and this value may be overridden by local configuration of
the operator. the operator.
If this situation is detected, the requester SHOULD start a timer If this situation is detected, the requestor SHOULD start a timer
using the current value of BULK_LQ_DATA_TIMEOUT. If that timer using the current value of BULK_LQ_DATA_TIMEOUT. If that timer
expires, the requester SHOULD terminate the connection. expires, the requestor SHOULD terminate the connection.
A single Bulk Leasequery can and usually will result in a large A single Bulk Leasequery can and usually will result in a large
number of replies. The requestor MUST be prepared to receive more number of replies. The requestor MUST be prepared to receive more
than one reply with an xid matching a single DHCPBULKLEASEQUERY than one reply with an xid matching a single DHCPBULKLEASEQUERY
message from a single DHCPv4 server. If the xid in the received message from a single DHCPv4 server. If the xid in the received
message does not match an outstanding DHCPBULKLEASEQUERY message, the message does not match an outstanding DHCPBULKLEASEQUERY message, the
requestor MUST close the TCP connection. requestor MUST close the TCP connection.
The DHCPv4 server MUST send a server-identifier option (option 54) in The DHCPv4 server MUST send a server-identifier option (option 54) in
the first response to any DHCPBULKLEASEQUERY message. The DHCPv4 the first response to any DHCPBULKLEASEQUERY message. The DHCPv4
server SHOULD NOT send server identifier options in subsequent server SHOULD NOT send server identifier options in subsequent
responses to that DHCPBULKLEASEQUERY message. The requester MUST responses to that DHCPBULKLEASEQUERY message. The requestor MUST
cache the server-identifier option from the first response and apply cache the server-identifier option from the first response and apply
it to any subsequent responses. it to any subsequent responses.
The response messages generated by a DHCPBULKLEASEQUERY request are: The response messages generated by a DHCPBULKLEASEQUERY request are:
o DHCPLEASEACTIVE o DHCPLEASEACTIVE
A Bulk Leasequery will generate DHCPLEASEACTIVE messages A Bulk Leasequery will generate DHCPLEASEACTIVE messages
containing binding data for bound IP addresses which match the containing binding data for bound IP addresses which match the
specified query criteria. The IP address which is bound to a specified query criteria. The IP address which is bound to a
skipping to change at page 23, line 44 skipping to change at page 23, line 46
o DHCPLEASEUNASSIGNED o DHCPLEASEUNASSIGNED
Some queries will also generate DHCPLEASEUNASSIGNED messages for Some queries will also generate DHCPLEASEUNASSIGNED messages for
IP addresses which match the query criteria. These messages IP addresses which match the query criteria. These messages
indicate that the IP address is managed by the DHCPv4 server but indicate that the IP address is managed by the DHCPv4 server but
is not currently bound to any DHCPv4 client. The IP address to is not currently bound to any DHCPv4 client. The IP address to
which this message refers will appear in the ciaddr field of the which this message refers will appear in the ciaddr field of the
DHCPLEASEUNASSIGNED message. A DHCPLEASEUNASSGINED message MAY DHCPLEASEUNASSIGNED message. A DHCPLEASEUNASSGINED message MAY
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. chaddr, htype, and hlen and possibly additional options in this
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 dhcp-message option
in the DHCPLEASEQUERYDONE message. If there is no dhcp-message in the DHCPLEASEQUERYDONE message. If there is no dhcp-message
option in the DHCPLEASEQUERYDONE message, then the query option in the DHCPLEASEQUERYDONE message, then the query
completed successfully. completed successfully.
skipping to change at page 27, line 44 skipping to change at page 27, line 45
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 3 <----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEQUERYDONE xid 3 <----- DHCPLEASEQUERYDONE xid 3
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEQUERYDONE xid 4 <----- DHCPLEASEQUERYDONE xid 4
7.8. Closing Connections 7.8. Closing Connections
The requestor SHOULD close the connection after the The requestor SHOULD close the connection after the
DHCPLEASEQUERYDONE message is received for the last outstanding query DHCPLEASEQUERYDONE message is received for the last outstanding query
that it has sent. that it has sent, if it has no more queries to send.
8. Server Behavior 8. Server Behavior
8.1. Accepting Connections 8.1. Accepting Connections
Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP
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 currently 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
skipping to change at page 31, line 37 skipping to change at page 31, line 40
The DHCPv4 server MAY return address binding data in any order, as The DHCPv4 server MAY return address binding data in any order, as
long as binding information for any given IP address is not repeated. long as binding information for any given IP address is not repeated.
When all binding data for a given DHCPBULKLEASEQUERY has been sent, When all binding data for a given DHCPBULKLEASEQUERY has been sent,
the DHCPv4 server MUST send a DHCPBULKLEASEQUERYDONE message. the DHCPv4 server MUST send a DHCPBULKLEASEQUERYDONE message.
8.3. Building a Single Reply for Bulk Leasequery 8.3. Building a Single Reply for Bulk Leasequery
The DHCPv4 Leasequery [RFC4388] specification describes the initial The DHCPv4 Leasequery [RFC4388] specification describes the initial
construction of DHCPLEASEQUERY reply messages using the construction of DHCPLEASEQUERY reply messages using the
DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types in Section DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types in Section
5.4.2. All of the reply messages in Bulk Leasequery are similar to 6.4.2. All of the reply messages in Bulk Leasequery are similar to
the reply messages for an IP address query. Message transmission and the reply messages for an IP address query. Message transmission and
framing for TCP is described in this document in Section 6.1. framing for TCP is described in this document in Section 6.1.
[RFC2131] and [RFC4388] specify that every response message MUST [RFC2131] and [RFC4388] specify that every response message MUST
contain the server-identifier option. However, that option will be contain the server-identifier option. However, that option will be
the same for every response from a particular DHCPBULKLEASEQUERY the same for every response from a particular DHCPBULKLEASEQUERY
request. Thus, the DHCPv4 server MUST include the server-identifier request. Thus, the DHCPv4 server MUST include the server-identifier
option in the first message sent in response to a DHCPBULKLEASEQUERY. option in the first message sent in response to a DHCPBULKLEASEQUERY.
It SHOULD NOT include the server-identifier in later messages. It SHOULD NOT include the server-identifier in later messages.
skipping to change at page 32, line 33 skipping to change at page 32, line 35
style times are based upon. style times are based upon.
3. If the start-time-of-state option code appears in the dhcp- 3. If the start-time-of-state option code appears in the dhcp-
parameter-request-list, the DHCPv4 server MUST include a parameter-request-list, the DHCPv4 server MUST include a
start-time-of-state option whose value represents the time at start-time-of-state option whose value represents the time at
which the dhcp-state option's state became valid. which the dhcp-state option's state became valid.
4. If the dhcp-lease-time option code appears in the dhcp- 4. If the dhcp-lease-time option code appears in the dhcp-
parameter-request-list, the DHCPv4 server MUST include a dhcp- parameter-request-list, the DHCPv4 server MUST include a dhcp-
lease-time option for any state that has a time-out value lease-time option for any state that has a time-out value
associated with it. In the [RFC4388] Leasequery, the dhcp- associated with it.
lease-time option appears only in a DHCPLEASEACTIVE message.
Thus, the EXPIRED state, which is sent in a DHCPLEASEUNASSIGNED
message, would have a dhcp-lease-time option in the message if
the EXPIRED state represented a grace-period and would be
changed into the FREE state after the expiration of the grace-
period.
5. If the data-source option code appears in the dhcp-parameter- 5. If the data-source option code appears in the dhcp-parameter-
request-list, the DHCPv4 server MUST include the data-source request-list, the DHCPv4 server MUST include the data-source
option in any situation where any of the bits would be non- option in any situation where any of the bits would be non-
zero. Thus, in the absence of the data-source option, the zero. Thus, in the absence of the data-source option, the
assumption is that all of the flags were zero. assumption is that all of the flags were zero.
6. If the client-last-transaction-time option code appears in the 6. If the client-last-transaction-time option code appears in the
dhcp-parameter-request-list, The DHCPv4 server MUST include the dhcp-parameter-request-list, The DHCPv4 server MUST include the
client-last-transaction-time option in any situation where the client-last-transaction-time option in any situation where the
skipping to change at page 33, line 37 skipping to change at page 33, line 34
Servers SHOULD offer configuration that limits the number of Servers SHOULD offer configuration that limits the number of
simultaneous queries permitted from any one requestor, in order to simultaneous queries permitted from any one requestor, in order to
control resource use if there are multiple requestors seeking control resource use if there are multiple requestors seeking
service. service.
8.5. Closing Connections 8.5. Closing Connections
The DHCPv4 server SHOULD start a timer for BULK_LQ_DATA_TIMEOUT The DHCPv4 server SHOULD start a timer for BULK_LQ_DATA_TIMEOUT
seconds for a particular connection after it sends a seconds for a particular connection after it sends a
DHCPLEASEQUERYDONE message over that connection and if there is no DHCPLEASEQUERYDONE message over that connection and if there is no
current outstanding query outstanding for that connection. It should current query outstanding for that connection. It should clear this
clear this timer if a query arrives over that connection. If the timer if a query arrives over that connection. If the timer expires,
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 dhcp-message 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
skipping to change at page 34, line 33 skipping to change at page 34, line 33
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.
[RFC4388] discusses security concerns and potential solutions for [RFC4388] discusses security concerns and potential solutions for
DHCPLEASEQUERY message exchanges in its Section 7, and all of the DHCPLEASEQUERY message exchanges in its Section 7, and all of the
solutions discussed there are applicable to the DHCPLEASEQUERY solutions discussed there are applicable to the DHCPLEASEQUERY
message exchanges described in this document. message exchanges described in this document.
10. IANA Considerations 10. IANA Considerations
IANA is requested to assign the following new values for this This document defines two new name spaces associated with DHCPv4
document. See Section 6.2 for details. options:
1. Status code values for the status-code option, TBD1.
2. DHCP state values for the dhcp-state option, TBD6.
IANA has established a registry of values for these two name
spaces. These name spaces will be managed by the IANA. New values
for these name spaces may only be defined by IETF Consensus, as
described in [RFC5226]. Basically, this means that they are
defined by RFCs approved by the IESG.
IANA is requested to assign the following new values for this
document. See Section 6.2 for details.
1. A dhcp-message-type of 14 for DHCPBULKLEASEQUERY. 1. A dhcp-message-type of 14 for DHCPBULKLEASEQUERY.
2. A dhcp-message-type of 15 for DHCPLEASEQUERYDONE. 2. A dhcp-message-type of 15 for DHCPLEASEQUERYDONE.
3. An option code of TBD1 for base-time. 3. An option code of TBD1 for status-code.
4. An option code of TBD2 for start-time-of-state. 4. An option code of TBD2 for base-time.
5. An option code of TBD3 for query-start-time. 5. An option code of TBD3 for start-time-of-state.
6. An option code of TBD4 for query-end-time. 6. An option code of TBD4 for query-start-time.
7. An option code of TBD5 for data-source. 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. Values for dhcp-state: 9. An option code of TBD7 for data-source.
10.Values for status code in a status-code option (option TBD1):
Name status-code
---- -----------
Success 000
UnspecFail 001
QueryTerminated 002
MalformedQuery 003
NotAllowed 004
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
10.Values for status code in a constrained dhcp-message option 12.Additional type field values for the Virtual Subnet Selection
(option 53):
Name status-code
---- -----------
Success 000
UnspecFail 001
QueryTerminated 002
MalformedQuery 003
NotAllowed 004
11.Additional type field values for the Virtual Subnet Selection
Type and Information [VpnId]: Type 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
NEW -> 254 All VPN's. (wildcard) 254 All VPN's. (wildcard; only allowed in
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
skipping to change at page 36, line 24 skipping to change at page 36, line 43
[RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
[RFC4388] Woundy, R., K. Kinnear, "Dynamic Host Configuration [RFC4388] Woundy, R., K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC 4388, February 2006. Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RelayId] Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption", [RelayId] Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption",
draft-ietf-dhc-relay-id-suboption-07.txt, (work in progress) July draft-ietf-dhc-relay-id-suboption-07.txt, (work in progress) July
2009. 2009.
[VpnId] Kinnear, K., R. Johnson, M. Stapp and J. Kumarasamy, "Virtual [VpnId] Kinnear, K., R. Johnson, M. Stapp and J. Kumarasamy, "Virtual
Subnet Selection Options for DHCPv4 and DHCPv6" draft-ietf-dhc- Subnet Selection Options for DHCPv4 and DHCPv6" draft-ietf-dhc-
vpn-option-11.txt, (work in progress) March 2009. vpn-option-11.txt, (work in progress) March 2009.
12.2. Informative References 12.2. Informative References
skipping to change at page 37, line 24 skipping to change at page 38, line 4
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
10 Jordan Terrace
Wakefield, MA 01880 Wakefield, MA 01880
EMail: provng@gmail.com EMail: neilerussell@gmail.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
 End of changes. 86 change blocks. 
204 lines changed or deleted 179 lines changed or added

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