draft-ietf-dhc-dhcpv4-bulk-leasequery-07.txt   rfc6926.txt 
DHC Working Group Kim Kinnear Internet Engineering Task Force (IETF) K. Kinnear
Internet Draft Mark Stapp Request for Comments: 6926 M. Stapp
Intended Status: Standards Track Cisco Systems, Inc. Category: Standards Track Cisco Systems, Inc.
Expires: April 15, 2013 D. Rao ISSN: 2070-1721 R. Desetti
B. Joshi B. Joshi
Infosys Technologies Ltd. Infosys Ltd.
Neil Russell N. Russell
BMC Software, Inc. Sea Street Technologies Inc.
October 15, 2012 P. Kurapati
Juniper Networks
B. Volz
Cisco Systems, Inc.
April 2013
Bulk DHCPv4 Lease Query DHCPv4 Bulk Leasequery
<draft-ietf-dhc-dhcpv4-bulk-leasequery-07.txt>
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery
provisions of BCP 78 and BCP 79. protocol allows a requestor to request information about DHCPv4
bindings. This protocol is limited to queries for individual
bindings. In some situations, individual binding queries may not be
efficient or even possible. This document extends the DHCPv4
Leasequery protocol to allow for bulk transfer of DHCPv4 address
binding data via TCP.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This is an Internet Standards Track document.
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/ietf/1id-abstracts.txt. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6926.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 Simplified BSD License. described in the Simplified BSD License.
Abstract
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery
extension allows a requestor to request information about DHCPv4
bindings. This mechanism is limited to queries for individual
bindings. In some situations individual binding queries may not be
efficient, or even possible. This document extends the DHCPv4
Leasequery protocol to allow for bulk transfer of DHCPv4 address
binding data via TCP.
Table of Contents Table of Contents
1. Introduction................................................. 3 1. Introduction ....................................................4
2. Terminology.................................................. 4 2. Terminology .....................................................5
3. Design Goals................................................. 7 3. Design Goals ....................................................8
3.1. Information Acquisition before Data Starts................. 7 3.1. Information Acquisition before Data Starts .................8
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'................................ 8 3.3. Antispoofing in 'Fast Path' ................................8
3.4. Minimize data transmission................................. 8 3.4. Minimize Data Transmission .................................9
4. Protocol Overview............................................ 8 4. Protocol Overview ...............................................9
5. Interaction Between UDP Leasequery and Bulk Leasequery....... 10 5. Interaction between UDP Leasequery and Bulk Leasequery .........11
6. Message and Option Definitions............................... 11 6. Message and Option Definitions .................................12
6.1. Message Framing for TCP.................................... 11 6.1. Message Framing for TCP ...................................12
6.2. New or Changed Options..................................... 12 6.2. New or Changed Options ....................................13
6.3. Connection and Transmission Parameters..................... 19 6.3. Connection and Transmission Parameters ....................20
7. Requestor Behavior........................................... 19 7. Requestor Behavior .............................................21
7.1. Connecting and General Processing.......................... 19 7.1. Connecting and General Processing .........................21
7.2. Forming a Bulk Leasequery.................................. 20 7.2. Forming a Bulk Leasequery .................................21
7.3. Processing Bulk Replies.................................... 22 7.3. Processing Bulk Replies ...................................23
7.4. Processing Time Values in Leasequery messages.............. 24 7.4. Processing Time Values in Leasequery Messages .............25
7.5. Querying Multiple Servers.................................. 25 7.5. Querying Multiple Servers .................................26
7.6. Making Sense Out of Multiple Responses Concerning a Single. 25 7.6. Making Sense out of Multiple Responses concerning
7.7. Multiple Queries to a Single Server over One Connection.... 26 a Single IPv4 Address .....................................26
7.8. Closing Connections........................................ 27 7.7. Multiple Queries to a Single Server over One Connection ...27
8. Server Behavior.............................................. 28 7.8. Closing Connections .......................................28
8.1. Accepting Connections...................................... 28 8. Server Behavior ................................................29
8.2. Replying to a Bulk Leasequery.............................. 28 8.1. Accepting Connections .....................................29
8.3. Building a Single Reply for Bulk Leasequery................ 31 8.2. Replying to a Bulk Leasequery .............................29
8.4. Multiple or Parallel Queries............................... 33 8.3. Building a Single Reply for Bulk Leasequery ...............33
8.5. Closing Connections........................................ 33 8.4. Multiple or Parallel Queries ..............................34
9. Security Considerations...................................... 34 8.5. Closing Connections .......................................35
10. IANA Considerations......................................... 35 9. Security Considerations ........................................35
11. Contributing Authors........................................ 37 10. IANA Considerations ...........................................37
12. Acknowledgements............................................ 38 11. Acknowledgements ..............................................38
13. References.................................................. 38 12. References ....................................................38
13.1. Normative References...................................... 38 12.1. Normative References .....................................38
13.2. Informative References.................................... 39 12.2. Informative References ...................................39
1. Introduction 1. Introduction
The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the DHCPv4 [RFC2131] [RFC2132] specifies a protocol for the assignment of
assignment of IPv4 address and configuration information to IPv4 IPv4 address and configuration information to IPv4 nodes. DHCPv4
nodes. DHCPv4 servers maintain authoritative binding information. servers maintain authoritative binding information.
+--------+ +--------+
| DHCPv4 | +--------------+ | DHCPv4 | +--------------+
| Server |-...-| DHCP | | Server |-...-| DHCP |
| | | Relay Agent | | | | Relay Agent |
+--------+ +--------------+ +--------+ +--------------+
| | | |
+------+ +------+ +------+ +------+
|Modem1| |Modem2| |Modem1| |Modem2|
+------+ +------+ +------+ +------+
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|Node1| |Node2| |Node3| |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
agents also glean lease information sent by the server and cache it relay agents also glean lease information sent by the server and
locally. This information is used for a variety of purposes. Two cache it locally. This information is used for a variety of
examples are prevention of spoofing attempts from the DHCPv4 clients, purposes. Two examples are prevention of spoofing attempts from the
and installation of routes. When a relay agent reboots, this DHCPv4 clients and installation of routes. When a relay agent
information is frequently lost. reboots, this information is frequently lost.
The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4
capability to allow an external entity, such as a relay agent, to capability to allow an external entity, such as a relay agent, to
query a DHCPv4 server to rapidly recover lease state information query a DHCPv4 server to rapidly recover lease state information
about a particular IP address or client. about a particular IP address or client.
The existing query types in Leasequery are typically data driven; the The existing query types in Leasequery are typically data driven; the
relay agent initiates the Leasequery when it receives data traffic relay agent initiates the Leasequery when it receives data traffic
from or to the client. This approach may not scale well when there from or to the client. This approach may not scale well when there
are thousands of clients connected to the relay agent or when the are thousands of clients connected to the relay agent or when the
relay agent has a need to rebuild its internal data store prior to relay agent has a need to rebuild its internal data store prior to
processing traffic in one direction or another. processing traffic in one direction or another.
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
requires an underlying transport more suitable to the bulk turn, 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 [RFC4388] to add
for queries that address these additional requirements. There may be support for queries that address these additional requirements.
many thousands of DHCPv4 bindings returned as the result of a single There may be many thousands of DHCPv4 bindings returned as the result
request, so TCP [RFC4614] is specified for efficiency of data of a single request, so TCP [RFC4614] is specified for efficiency of
transfer. We define several additional query types, each of which data transfer. We define several additional query types, each of
can return multiple responses, in order to meet a variety of which 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
This document uses the following terms: This document uses the following terms:
o "absolute time" o "absolute time"
A 32-bit quantity containing the number of seconds since Jan 1, Absolute time is a 32-bit quantity containing the number of
1970. seconds since January 1, 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
This document assumes that the access concentrator includes the document assumes that the access concentrator includes the DHCPv4
DHCPv4 relay agent functionality. For example, a CMTS (Cable relay agent functionality, for example, a CMTS (Cable Modem
Modem Termination System) in Cable environment or a DSLAM Termination System) in a cable environment or a DSLAM (Digital
(Digital Subscriber Line Access Multiplexer) in a DSL Subscriber Line Access Multiplexer) in a DSL environment.
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 that
which is currently associated with a DHCPv4 client where that is currently associated with a DHCPv4 client where that DHCPv4
DHCPv4 client has the right to use the IP address. client has the right to use the IP address.
o "Bulk Leasequery" o "Bulk Leasequery"
Requesting and receiving the existing DHCPv4 address binding Bulk Leasequery involves requesting and receiving the existing
information in an efficient manner. DHCPv4 address binding information in an efficient manner.
o "clock skew" o "clock skew"
The difference between the absolute time on a DHCPv4 server and The clock skew for a Bulk Leasequery connection is the difference
the absolute time on the system where a requestor of a Bulk between the absolute time on a DHCPv4 server and the absolute time
Leasequery is executing is termed the "clock skew" for that Bulk on the system where a requestor of a Bulk Leasequery is executing.
Leasequery connection. It is not absolutely constant but is It is not absolutely constant but is likely to vary only slowly.
likely to vary only slowly. It is possible that, when both
systems run NTP, the clock skew is negligible, and this is not
only acceptable, but desired.
While it is easy to think that this can be calculated precisely It is possible that, when both systems run NTP, the clock skew is
after one message is received by a requestor from a DHCPv4 negligible; this is not only acceptable but desired.
server, a more accurate value is derived from continuously
examining the instantaneous value developed from each message
received from a DHCPv4 server and using it to make small
adjustments to the existing value held in the requestor.
o "Default VPN" While it is easy to think that this can be calculated precisely
after one message is received by a requestor from a DHCPv4 server,
a more accurate value is derived from continuously examining the
instantaneous value developed from each message received from a
DHCPv4 server and using it to make small adjustments to the
existing value held in the requestor.
Indicates that the address being described belongs to the set of o "Default VPN"
addresses not part of any VPN. In other words, the normal
address space operated on by DHCP. This includes Special Use
IPv4 Addresses as defined in [RFC1918].
o "DHCPv4 client" A default VPN indicates that the address being described belongs
to the set of addresses not part of any VPN (in other words, the
normal address space operated on by DHCP). This includes Special
Use IPv4 Addresses as defined in [RFC5735].
A DHCPv4 client is an Internet node using DHCPv4 to obtain o "DHCPv4 client"
configuration parameters such as a network address.
o "DHCPv4 relay agent" A DHCPv4 client is an Internet node using DHCPv4 to obtain
configuration parameters such as a network address.
A DHCPv4 relay agent is an agent that is neither a DHCPv4 client o "DHCPv4 relay agent"
nor a DHCP server that transfers BOOTP and DHCPv4 messages
between clients and servers residing on different subnets, per
[RFC951] and [RFC1542].
o "DHCPv4 server" A DHCPv4 relay agent is an agent that is neither a DHCPv4 client
nor a DHCP server that transfers BOOTP and DHCPv4 messages between
clients and servers residing on different subnets, per [RFC951]
and [RFC1542].
A DHCPv4 server is an Internet node that returns configuration o "DHCPv4 server"
parameters to DHCPv4 clients.
o "DSLAM" A DHCPv4 server is an Internet node that returns configuration
parameters to DHCPv4 clients.
Digital Subscriber Line Multiplexer. o "DSLAM"
o "downstream" DSLAM stands for Digital Subscriber Line Access Multiplexer.
Refers to a direction away from the central part of a network o "downstream"
and toward the edge. In a DHCPv4 context, typically refers to a
network direction which is away from the DHCPv4 server and
toward the DHCPv4 client..
o "Global VPN" Downstream refers to a direction away from the central part of a
network and toward the edge. In a DHCPv4 context, this typically
refers to a network direction that is away from the DHCPv4 server
and toward the DHCPv4 client.
Another name for the "Default VPN". o "Global VPN"
o "IP address" Global VPN is another name for the default VPN.
In this document, the term "IP address" refers to an IPv4 IP o "IP address"
address.
o "IP address binding" In this document, the term "IP address" refers to an IPv4 IP
address.
The information that a DHCPv4 server keeps regarding the o "IP address binding"
relationship between a DHCPv4 client and an IP address. This
includes the identity of the DHCPv4 client and the expiration
time, if any, of any lease that client has on a particular IP
address. In some contexts, this may include information on IP
addresses that are currently associated with DHCPv4 clients, and
in others it may also include IP addresses with no current
association to a DHCPv4 client.
o "MAC address" An IP address binding is the information that a DHCPv4 server
keeps regarding the relationship between a DHCPv4 client and an IP
address. This includes the identity of the DHCPv4 client and the
expiration time, if any, of any lease that client has on a
particular IP address. In some contexts, this may include
information on IP addresses that are currently associated with
DHCPv4 clients, and in others, it may also include IP addresses
with no current association to a DHCPv4 client.
In the context of a DHCPv4 message, a MAC address consists of o "MAC address"
the fields: hardware type "htype", hardware length "hlen", and
client hardware address "chaddr".
o "upstream" In the context of a DHCPv4 message, a Media Access Control (MAC)
address consists of the fields: hardware type "htype", hardware
length "hlen", and client hardware address "chaddr".
Refers to a direction toward the central part of a network and o "upstream"
away from the edge. In a DHCPv4 context, typically refers to a
network direction which is away from the DHCPv4 client toward
the DHCPv4 server.
o "stable storage" Upstream refers to a direction toward the central part of a
network and away from the edge. In a DHCPv4 context, this
typically refers to a network direction that is away from the
DHCPv4 client and toward the DHCPv4 server.
Stable storage is used to hold information concerning IP address o "stable storage"
bindings (among other things) so that this information is not
lost in the event of a failure which requires restart of the
network element. DHCPv4 servers are typically expected to have
high speed access to stable storage, while relay agents and
access concentrators usually do not have access to stable
storage, although they may have periodic access to such storage.
o "xid" Stable storage is used to hold information concerning IP address
bindings (among other things) so that this information is not lost
in the event of a failure that requires restart of the network
element. DHCPv4 servers are typically expected to have high-speed
access to stable storage, while relay agents and access
concentrators usually do not have access to stable storage,
although they may have periodic access to such storage.
Transaction-id. The term "xid" refers to the DHCPv4 field o "xid"
containing the transaction-id of the message.
Transaction-id. The term "xid" refers to the DHCPv4 field
containing the transaction-id of the message.
3. Design Goals 3. Design Goals
The goal of this document is to provide a lightweight mechanism for The goal of this document is to provide a lightweight protocol for an
an Access Concentrator or other network element (such as a DHCP Relay access concentrator or other network element (such as a DHCP relay
Agent) to retrieve IP address binding information available in the agent) to retrieve IP address binding information available in the
DHCPv4 server. The mechanism should also allow an Access DHCPv4 server. The protocol should also allow an access concentrator
Concentrator or DHCP Relay Agent to retrieve consolidated IP address or DHCP relay agent to retrieve consolidated IP address binding
binding information for either the entire access concentrator or a information for either the entire access concentrator or a single
single connection/circuit. Throughout the discussion below, connection/circuit. Throughout the discussion below, everything that
everything that applies to an Access Concentrator also applies to a applies to an access concentrator also applies to a DHCP relay agent.
DHCP Relay Agent.
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
messages for each client until it gets lease information from the messages for each client until it gets lease information from the
DHCPv4 server for that client. If an Access Concentrator finishes the DHCPv4 server for that client. If an access concentrator finishes
Leasequeries before it starts receiving data, then there is no need the Leasequeries before it starts receiving data, then there is no
to drop legitimate messages. In this way, outage time may be reduced. need to drop legitimate messages. 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.
These caches not only consume precious resources, they also need to These caches not only consume precious resources, they also need to
be managed. Hence they should be avoided as much as possible. One be managed. Hence, they should be avoided as much as possible. One
of the goals of the DHCPv4 Bulk Leasequery is to reduce the need for of the goals of the DHCPv4 Bulk Leasequery is to reduce the need for
this sort of caching. this sort of caching.
3.3. Antispoofing in 'Fast Path' 3.3. Antispoofing in 'Fast Path'
If Antispoofing is not done in the fast path, it will become a If antispoofing is not done in the fast path, it will become a
bottleneck and may lead to denial of service of the access bottleneck and may lead to denial of service of the access
concentrator. The Leasequeries should make it possible to do concentrator. The Leasequeries should make it possible to do
antispoofing in the fast path. antispoofing in the fast path.
3.4. Minimize data transmission 3.4. Minimize Data Transmission
It may be that a network element is able to periodically save its It may be that a network element is able to periodically save its
entire list of assigned IP addresses to some form of stable storage. entire list of assigned IP addresses to some form of stable storage.
In this case, it will wish to recover all of the updates to this In this case, it will wish to recover all of the updates to this
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 DHCPv4 Bulk Leasequery mechanism is modeled on the existing The DHCPv4 Bulk Leasequery protocol is modeled on the existing
individual DHCPv4 Leasequery protocol in [RFC4388] as well as related individual DHCPv4 Leasequery protocol in [RFC4388] as well as related
work on DHCPv6 Bulk Leasequery [RFC5460]. A Bulk Leasequery requestor work on DHCPv6 Bulk Leasequery [RFC5460]. A Bulk Leasequery
opens a TCP connection to a DHCPv4 Server, using the DHCPv4 port 67. requestor opens a TCP connection to a DHCPv4 server using the DHCPv4
Note that this implies that the Leasequery requestor has server IP port 67. Note that this implies that the Leasequery requestor has
address(es) available via configuration or some other means, and that server IP address(es) available via configuration or some other means
it has unicast IP reachability to the DHCPv4 server. No relaying of and that it has unicast IP reachability to the DHCPv4 server. No
Bulk Leasequery messages is specified. relaying of 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.
Relevant bindings are returned in DHCPv4 messages with either the Relevant bindings are returned in DHCPv4 messages with either the
DHCPLEASEACTIVE message type for an IP address with a currently DHCPLEASEACTIVE message type for an IP address with a currently
active lease or, in some situations, a DHCPLEASEUNASSIGNED message active lease or, in some situations, a DHCPLEASEUNASSIGNED message
type for an IP address which is controlled by the DHCPv4 server but type for an IP address that is controlled by the DHCPv4 server but is
which is not actively leased by a DHCPv4 client at the present time. not actively leased by a DHCPv4 client at the present time.
The Bulk Leasequery mechanism is designed to provide an external The Bulk Leasequery protocol is designed to provide an external
entity with information concerning existing DHCPv4 IPv4 address entity with information concerning existing DHCPv4 IPv4 address
bindings managed by the DHCPv4 server. When complete, the DHCPv4 bindings managed by the DHCPv4 server. When complete, the DHCPv4
server will send a DHCPLEASEQUERYDONE message. If a connection is server will send a DHCPLEASEQUERYDONE message. If a connection is
lost while processing a Bulk Leasequery, the Bulk Leasequery must be lost while processing a Bulk Leasequery, the Bulk Leasequery must be
retried as there is no provision for determining the extent of data retried as there is no provision for determining the extent of data
already received by the requestor for a Bulk Leasequery. already received by the requestor for a Bulk Leasequery.
Bulk Leasequery supports queries by MAC address and by Client Bulk Leasequery supports queries by MAC address and by Client
Identifier in a way similar to [RFC4388]. The Bulk Leasequery Identifier in a way similar to [RFC4388]. The Bulk Leasequery
protocol also adds several new queries. protocol also adds several new queries.
o Query by Relay Identifier o Query by Relay Identifier
This query asks a server for the bindings associated with a This query asks a server for the bindings associated with a
specific relay agent; the relay agent is identified by a DUID specific relay agent; the relay agent is identified by a Relay
carried in a Relay-ID sub-option [RelayId]. Relay agents can Agent Identifier carried in a Relay-ID sub-option [RFC6925].
include this sub-option while relaying messages to DHCPv4 Relay agents can include this sub-option while relaying messages
servers. Servers can retain the Relay-ID and associate it with to DHCPv4 servers. Servers can retain the Relay-ID and associate
bindings made on behalf of the relay agent's clients. The it with bindings made on behalf of the relay agent's clients. The
bindings returned are only those for DHCPv4 clients with a bindings returned are only those for DHCPv4 clients with a
currently active binding. currently active binding.
o Query by Remote ID o Query by Remote ID
This query asks a server for the bindings associated with a This query asks a server for the bindings associated with a relay
Relay Agent Remote-ID sub-option [RFC3046] value. The bindings agent Remote ID sub-option [RFC3046] value. The bindings returned
returned are only those for DHCPv4 clients with a currently are only those for DHCPv4 clients with a currently active binding.
active binding.
o Query for All Configured IP Addresses o Query for All Configured IP Addresses
This query asks a server for information concerning all IP This query asks a server for information concerning all IP
addresses configured in that DHCPv4 server, by specifying no addresses configured in that DHCPv4 server by specifying no other
other type of query. In this case, the bindings returned are for type of query. In this case, the bindings returned are for all
all configured IP addresses, whether or not they contain a configured IP addresses, whether or not they contain a currently
currently active binding to a DHCPv4 client, since one point of active binding to a DHCPv4 client, since one point of this type of
this type of query is to update an existing database with query is to update an existing database with changes after a
changes after a particular point in time. particular point in time.
Any of the above queries can be qualified by the specification of a Any of the above queries can be qualified by the specification of a
query-start-time or a query-end-time (or both). When these timers are query-start-time or a query-end-time (or both). When these timers
used as qualifiers, they indicate that a binding should be included are used as qualifiers, they indicate that a binding should be
if it changed on or after the query-start-time and on or before the included if it changed on or after the query-start-time and on or
query-end-time. before the query-end-time.
In addition, any of the above queries can be qualified by the In addition, any of the above queries can be qualified by the
specification of a vpn-id option [RFC6607] to select the VPN on which specification of a VPN-ID option [RFC6607] to select the VPN on which
the query should be processed. The vpn-id option is also extended to the query should be processed. The VPN-ID option is also extended to
allow queries across all available VPNs. In the absence of any vpn-id allow queries across all available VPNs. In the absence of any VPN-
option, only the default (global) VPN is used to satisfy the query. ID option, only the default (global) VPN is used to satisfy the
query.
5. Interaction Between UDP Leasequery and Bulk Leasequery 5. Interaction between UDP Leasequery and Bulk Leasequery
Bulk Leasequery can be seen as an extension of the existing UDP Bulk Leasequery can be seen as an extension of the existing UDP
Leasequery protocol [RFC4388]. This section clarifies the Leasequery protocol [RFC4388]. This section clarifies the
relationship between the two protocols. relationship between the two protocols.
The Bulk Leasequery TCP connection is only designed to handle the The Bulk Leasequery TCP connection is only designed to handle the
DHCPBULKLEASEQUERY request. It is not intended as an alternative DHCPBULKLEASEQUERY request. It is not intended as an alternative
DHCPv4 communication option for clients seeking other DHCPv4 DHCPv4 communication option for clients seeking other DHCPv4
services. DHCPv4 address allocation could not be performed over a services. DHCPv4 address allocation could not be performed over a
TCP connection in any case, as a TCP connection requires an IP TCP connection in any case, as a TCP connection requires an IP
address, as no IPv4 address exists prior to a successful DHCPv4 address and no IPv4 address exists prior to a successful DHCPv4
address allocation exchange. In addition, the existing DHCPv4 UDP address allocation exchange. In addition, the existing DHCPv4 UDP
transmission regime is implemented in untold millions of devices transmission regime is implemented in untold millions of devices
deployed worldwide, and complicating DHCPv4 services with alternative deployed worldwide, and complicating DHCPv4 services with alternative
transmission approaces (even if it were possible) would be worse than transmission approaches (even if it were possible) would be worse
any perceived benefit to doing so. than any perceived benefit to doing so.
Two of the query-types introduced in the UDP Leasequery protocol can Two of the query types introduced in the UDP Leasequery protocol can
be used in the Bulk Leasequery protocol -- query by MAC address and be used in the Bulk Leasequery protocol -- Query by MAC address and
query by client-id. Query by Client-identifier.
The contents of the reply messages are similar between the existing The contents of the reply messages are similar between the existing
UDP Leasequery protocol and the Bulk Leasequery protocol, though more UDP Leasequery protocol and the Bulk Leasequery protocol, though more
information is returned in the Bulk Leasequery messages. information is returned in the Bulk Leasequery messages.
One change in behavior for these existing queries is required when One change in behavior for these existing queries is required when
Bulk Leasequery is used. [RFC4388], in sections 6.1, 6.4.1, and Bulk Leasequery is used. Sections 6.1, 6.4.1, and 6.4.2 of [RFC4388]
6.4.2 specifies the use of an associated-ip option in DHCPLEASEACTIVE specify the use of an associated-ip option in DHCPLEASEACTIVE
messages in cases where multiple bindings were found. When Bulk messages in cases where multiple bindings were found. When Bulk
Leasequery is used, this mechanism is not necessary; a server Leasequery is used, this mechanism is not necessary; a server
returning multiple bindings simply does so directly as specified in returning multiple bindings simply does so directly as specified in
this document. The associated-ip option MUST NOT appear in Bulk this document. The associated-ip option MUST NOT appear in Bulk
Leasequery replies. Leasequery replies.
Implementors should note that the TCP message framing defined in Implementors should note that the TCP message framing defined in
Section 4.1 is not compatible with the UDP message format. If a TCP- Section 6.1 is not compatible with the UDP message format. If a TCP-
framed request is sent as a UDP message, it may not be valid, because framed request is sent as a UDP message, it may not be valid, because
protocol fields will be offset by the message-size prefix. protocol fields will be offset by the message-size prefix.
6. Message and Option Definitions 6. Message and Option Definitions
6.1. Message Framing for TCP 6.1. Message Framing for TCP
The use of TCP for the Bulk Leasequery protocol permits multiple The use of TCP for the Bulk Leasequery protocol permits multiple
messages to be sent from one end of the connection to the other messages to be sent from one end of the connection to the other
without requiring a request/response paradigm as does UDP DHCPv4 without requiring a request/response paradigm as does UDP DHCPv4
[RFC2131]. The receiver needs to be able to determine the size of [RFC2131]. The receiver needs to be able to determine the size of
each message it receives. Two octets containing the message size in each message it receives. Two octets containing the message size in
network byte-order are prepended to each DHCPv4 message sent on a network byte order are prepended to each DHCPv4 message sent on a
Bulk Leasequery TCP connection. The two message-size octets 'frame' Bulk Leasequery TCP connection. The two message-size octets 'frame'
each DHCPv4 message. each DHCPv4 message.
The maximum message size is 65535 octets. The maximum message size is 65535 octets.
DHCPv4 message framed for TCP: 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | message-size | op (1) | htype (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message-size | op (1) | htype (1) | | hlen (1) | hops (1) | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---------------+---------------+ +
| hlen (1) | hops (1) | .... | | |
+---------------+---------------+ + . remainder of DHCPv4 message,
| | . from Figure 1 of [RFC2131] .
. remainder of DHCPv4 message, . .
. from Figure 1 of [RFC2131] . . (variable) .
. . | |
. (variable) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
message-size the number of octets in the message that message-size the number of octets in the message that
follows, as a 16-bit unsigned integer in follows, as a 16-bit unsigned integer in
network byte-order. network byte order.
All other fields are as specified in DHCPv4 [RFC2131]. All other fields are as specified in DHCPv4 [RFC2131].
Figure 2: Format of a DHCPv4 message in TCP Figure 2: Format of a DHCPv4 Message in TCP
The intent in using this format is that code which currently knows The intent in using this format is that code that currently knows how
how to deal with sending or receiving a message in [RFC2131] format to deal with sending or receiving a message in [RFC2131] format will
will easily be able to deal with the message contained in the TCP easily be able to deal with the message contained in the TCP framing.
framing.
6.2. New or Changed Options 6.2. New or Changed Options
The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are
used as the value of the dhcp-message-type option to indicate an IP used as the value of the dhcp-message-type option to indicate an IP
address which is currently not leased or currently leased to a DHCPv4 address that is currently not leased or currently leased to a DHCPv4
client, respectively [RFC4388]. client, respectively [RFC4388].
Additional options have also been defined to enable the Bulk Additional options have also been defined to enable the Bulk
Leasequery protocol to communicate useful information to the Leasequery protocol to communicate useful information to the
requestor. requestor.
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
----- ------------ ----- ------------
TBD8 DHCPBULKLEASEQUERY 14 DHCPBULKLEASEQUERY
TBD9 DHCPLEASEQUERYDONE 15 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 151. The length of this option is a
minimum of 1 octet. minimum of 1 octet.
Status Status Status Status
Code Len Code Message Code Len Code Message
+------+------+------+------+------+-- --+-----+ +------+------+------+------+------+-- --+-----+
| TBD1 | n+1 |status| s1 | s2 | ... | sn | | 151 | n+1 |status| s1 | s2 | ... | sn |
+------+------+------+------+------+-- --+-----+ +------+------+------+------+------+-- --+-----+
The status-code is indicated in one octet as defined in the table The status-code is indicated in one octet as defined in the table
below. The Status Message is an optional UTF-8 encoded text string below. The Status Message is an optional UTF-8-encoded text string
suitable for display to an end user. This text string MUST NOT suitable for display to an end user. This text string MUST NOT
contain a termination character (e.g., a null). The len field contain a termination character (e.g., a null). The Len field
describes the length of the status message without any terminator describes the length of the Status Message without any terminator
character. Nulls characters MUST NOT appear in the Status Message character. Null characters MUST NOT appear in the Status Message
string and it is a protocol violation for them to appear in any string, and it is a protocol violation for them to appear in any
position in the Status Message, including at the end. position in the Status Message, including at the end.
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 status-code 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
skipping to change at page 13, line 34 skipping to change at page 14, line 34
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 status-code 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 status-code 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 status-code option SHOULD NOT that the operation was successful. The status-code option SHOULD NOT
appear in a message which is successful unless there is some text appear in a message that 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 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- in 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 who placed this This time is in the context of the DHCPv4 server that placed this
option in a message. option in a message.
This is an unsigned integer in network byte order. This is an unsigned 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 152. 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 | | 152 | 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, 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 January 1, 1970.
Instead, this MUST be the unsigned integer number of seconds from the Instead, this MUST be the unsigned integer number of seconds from the
time the IP address transitioned its current state to the time time the IP address transitioned its current state to the time
specified in the base-time option in the same message. specified in the base-time option in the same message.
This is an unsigned integer in network byte order. This is an unsigned 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 153. 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 | | 153 | 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 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 unsigned integer in network byte order. This is an unsigned 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 154. The length of this option is 4
octets. octets.
DHCPv4 Server DHCPv4 Server
Code Len query-start-time Code Len query-start-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD4| 4 | t1 | t2 | t3 | t4 | | 154 | 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 unsigned integer in network byte order. This is an unsigned 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 155. The length of this option is 4
octets. octets.
DHCPv4 Server DHCPv4 Server
Code Len query-end-time Code Len query-end-time
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| TBD5| 4 | t1 | t2 | t3 | t4 | | 155 | 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 156. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD6 | Length | State | | 156 | Length | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBD6 The option code. 156 The option code.
Length The option length, 1 octet. Length The option length, 1 octet.
State The State of the IP address. State The state of the IP address.
Value State Value State
----- ----- ----- -----
1 AVAILABLE Address is available to local DHCPv4 server 1 AVAILABLE Address is available to local DHCPv4 server
2 ACTIVE Address is assigned to a DHCPv4 client 2 ACTIVE Address is assigned to a DHCPv4 client
3 EXPIRED Lease has expired 3 EXPIRED Lease has expired
4 RELEASED Lease has been released by DHCPv4 client 4 RELEASED Lease has been released by DHCPv4 client
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 Note the states AVAILABLE and REMOTE are relative to the current
server. An address that is available to the current server should server. An address that is available to the current server should
show AVAILABLE on that server, and if another server is involved with 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. that address as well, it should show as REMOTE on that other server.
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
with the state of REMOTE is available to a remote server. Usually, with the state of REMOTE is available to a remote server. Usually,
an IP address which is AVAILABLE on one server would be REMOTE on any an IP address that is AVAILABLE on one server would be REMOTE on any
remote server. The TRANSITIONING state is also likely to be useful remote server. The TRANSITIONING state is also likely to be useful
in multiple server deployments, where sometimes one server must in multiple server deployments, where sometimes one server must
interlock a state change with one or more other servers. Should a interlock a state change with one or more other servers. Should a
Bulk Leasequery need to send information concerning the state of the Bulk Leasequery need to send information concerning the state of the
IP address during this period, it SHOULD use the TRANSITIONING state, IP address during this period, it SHOULD use the TRANSITIONING state,
since the IP address is likely to be neither ACTIVE or AVAILABLE. since the IP address is likely to be neither ACTIVE or AVAILABLE.
There is no requirement for the state of an IP address to transition There is no requirement for the state of an IP address to transition
in a well defined way from state to state. To put this another way, in a well-defined way from state to state. To put this another way,
you cannot draw a simple state transition graph for the states of an you cannot draw a simple state transition graph for the states of an
IP address and the requestor of a Leasequery MUST NOT depend on one IP address, and the requestor of a Leasequery MUST NOT depend on one
certain state always following a particular previous state. While a certain state always following a particular previous state. While a
state transition diagram can be drawn, it would be fully connected state transition diagram can be drawn, it would be fully connected
and therefore conveys no useful information. Every state can (at and therefore conveys no useful information. Every state can (at
times) follow every other state. times) follow every other state.
6.2.8. data-source 6.2.8. data-source
The data-source option contains information about the source of the The data-source option contains information about the source of the
data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It
SHOULD be used when there are two or more servers who might have SHOULD be used when there are two or more servers that might have
information about a particular IP address binding. Frequently two information about a particular IP address binding. Frequently, two
servers work together to provide an increased availability solution servers work together to provide an increased availability solution
for the DHCPv4 service, and in these cases, both servers will respond for the DHCPv4 service, and in these cases, both servers will respond
to Bulk Leasequery requests for the same IP address. When one server to Bulk Leasequery requests for the same IP address. When one server
is working with another server and both may respond with information is working with another server and both may respond with information
about the same IP address, each server SHOULD return the data-source about the same IP address, each server SHOULD return the data-source
option with the other information provided about the IP address. option with the other information provided about the 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 TBD7. The length of this option is 1 The code for this option is 157. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD7 | Length | Flags | | 157 | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBD7 The option code. 157 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| UNA |R| | UNA |R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
R: REMOTE flag R: REMOTE flag
remote = 1 remote = 1
local = 0 local = 0
UNA: UNASSIGNED UNA: UNASSIGNED
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 requestor If this option was requested and it doesn't appear, the requestor
MUST consider that the data-source was local. MUST consider that the data-source was local.
Unassigned bits MUST be ignored. Unassigned bits MUST be ignored.
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 [RFC6607] carry identical All of the (sub-)options defined in [RFC6607] carry identical
payloads, consisting of a type and additional VSS (Virtual Subnet payloads, consisting of a type and additional VSS (Virtual Subnet
Selection) information. The existing table is extended (see below) Selection) information. The existing table is extended (see below)
with a new type 254 to allow specification of a type code which with a new type 254 to allow specification of a type code that
indicates that all VPN's are to be used to process the Bulk indicates that all VPNs are to be used to process the Bulk
Leasequery. Leasequery.
Type VSS Information Format Type VSS Information Format
---------------------------------------------------------- ----------------------------------------------------------
0 Network Virtual Terminal (NVT) ASCII VPN identifier 0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID 1 RFC 2685 VPN-ID
CHANGED -> 2-253 Unassigned CHANGED -> 2-253 Unassigned
NEW -> 254 All VPN's (wildcard) NEW -> 254 All VPNs (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 for both client and server
(see Sections 7 and 8) (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) 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 status-code option with a status-code of QueryTerminated or by with a status-code option with a status code of QueryTerminated or by
the failure of the connection over which it was being submitted, the the failure of the connection over which it was being submitted, the
requestor MAY retry the request after the creation of a new requestor MAY retry the request after the creation of a new
connection. 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 that 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. The xid
which allows the data-streams of two different DHCPBULKLEASEQUERY allows the data-streams of two different DHCPBULKLEASEQUERY requests
requests to be demultiplexed by the requestor. 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 that will transfer
transfer the state of some subset (or possibly all) of the IP address the state of some subset (or possibly all) of the IP address bindings
bindings from the DHCPv4 server to the requestor. The DHCPv4 server from the DHCPv4 server to the requestor. The DHCPv4 server will send
will send all of the requested IPv4 address bindings across this all of the requested IPv4 address bindings across this connection
connection with minimal delay after it receives the request. In this with minimal delay after it receives the request. In this context,
context, "all IP address binding information" means information about "all IP address binding information" means information about all IPv4
all IPv4 addresses configured within the DHCPv4 server which meet the addresses configured within the DHCPv4 server that meet the specified
specified query criteria. For some query criteria, this may include query criteria. For some query criteria, this may include IP address
IP address binding information for IP addresses which may not now binding information for IP addresses that may not now have or ever
have or ever had have an association with a specific DHCPv4 client. have had an association with a specific DHCPv4 client.
To form the Bulk query, a DHCPv4 request is constructed with a dhcp- To form the Bulk query, a DHCPv4 request is constructed with a dhcp-
message-type of DHCPBULKLEASEQUERY. The query SHOULD have a dhcp- message-type of DHCPBULKLEASEQUERY. The query SHOULD have a dhcp-
parameter-request-list to inform the DHCPv4 server which DHCPv4 parameter-request-list to inform the DHCPv4 server which DHCPv4
options are of interest to the requestor sending the options are of interest to the requestor sending the
DHCPBULKLEASEQUERY message. The dhcp-parameter-request-list in a DHCPBULKLEASEQUERY message. The dhcp-parameter-request-list in a
DHCPBULKLEASEQUERY message SHOULD contain the codes for base-time, DHCPBULKLEASEQUERY message SHOULD contain the codes for base-time,
dhcp-lease-time, start-time-of-state, and client-last-transaction- dhcp-lease-time, start-time-of-state, and client-last-transaction-
time. time.
A DHCPBULKLEASEQUERY request is constructed of one primary query and A DHCPBULKLEASEQUERY request is constructed of one primary query and
optionally one or more qualifiers for it. optionally one or more qualifiers for it.
The possible primary queries are listed below. Each The possible primary queries are listed below. Each
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-identifier
In a Query by Client-Id, a dhcp-client-id option containing the
requested value is included in the DHCPBULKLEASEQUERY request.
o Query by Remote-Id In a Query by Client-identifier, a Client-identifier option
containing the requested value is included in the
DHCPBULKLEASEQUERY request.
In a Query by Remote-Id, a remote-id sub-option containing the o Query by Remote ID
requested value is included in the relay-agent-information
option of the DHCPBULKLEASEQUERY request.
o Query by Relay-Id In a Query by Remote ID, a Remote ID sub-option containing the
requested value is included in the relay-agent-information option
of the DHCPBULKLEASEQUERY request.
In a Query by Relay-Id, a relay-id sub-option [RelayId] o Query by Relay-ID
containing the requested value is included in the relay-agent-
information option of the DHCPBULKLEASEQUERY request.
o Query for All Configured IP Addresses In a Query by Relay-ID, a Relay-ID sub-option [RFC6925] containing
the requested value is included in the relay-agent-information
option of the DHCPBULKLEASEQUERY request.
A Query for All Configured IP addresses is signaled by the o Query for All Configured IP Addresses
absence of any other primary query.
There are three qualifiers which can be applied to any of the above A Query for All Configured IP addresses is signaled by the absence
of any other primary query.
There are three qualifiers that 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 a 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 that 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 a query-end-time option specifies that only IP address Inclusion of a query-end-time option specifies that only IP
bindings which have changed on or before the time specified in the address bindings that have changed on or before the time specified
query-end-time option should be returned. in the 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
(global) VPN is searched to satisfy the query specified by the (global) VPN is searched to satisfy the query specified by the
DHCPBULKLEASEQUERY. Using the vpn-id option [RFC6607] allows the DHCPBULKLEASEQUERY. Using the VPN-ID option [RFC6607] 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 VPNs be
searched in order to satisfy the query specified in the searched in order to satisfy the query specified in the
DHCPBULKLEASEQUERY. DHCPBULKLEASEQUERY.
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 (global) VPN MUST contain a vpn-id option in the the default (global) VPN MUST contain a VPN-ID option in the
message. 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. Note that the times specified connection by a considerable amount. Note that the times specified
in the query-start-time or query-end-time options are absolute times, in the query-start-time or query-end-time options are absolute times,
not durations offset from "now". not durations offset from "now".
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 by 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 requestor 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 requestor SHOULD terminate the connection. This timer expires, the requestor SHOULD terminate the connection. This timer
is completely independent of any TCP timeout established by the TCP is completely independent of any TCP timeout established by the TCP
protocol connection. protocol connection.
skipping to change at page 22, line 43 skipping to change at page 24, line 9
connection stops being readable). Should this happen, the connection stops being readable). Should this happen, the
implementation's behavior is controlled by 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 requestor 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 requestor 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.
If the requestor receives more data than it can process, it can If the requestor receives more data than it can process, it can
simply abort the connection and try again with a more specific simply abort the connection and try again with a more specific
request. It can also simply read the TCP connection more slowly, and request. It can also simply read the TCP connection more slowly and
match the rate at which it can digest the information returned in the match the rate at which it can digest the information returned in the
Bulk Leasequery packets with the rate at which it reads those packets Bulk Leasequery packets with the rate at which it reads those packets
from the TCP connection. from 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 requestor 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 that match the
specified query criteria. The IP address which is bound to a specified query criteria. The IP address that is bound to a
DHCPv4 client will appear in the ciaddr field of the DHCPv4 client will appear in the ciaddr field of the
DHCPLEASEACTIVE message. The message may contain a non-zero DHCPLEASEACTIVE message. The message may contain a non-zero
chaddr, htype, and hlen and possibly additional options. chaddr, htype, hlen, and possibly additional options.
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 that 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 in this chaddr, htype, 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
will be sent in response to the DHCPBULKLEASEQUERY. More details be sent in response to the DHCPBULKLEASEQUERY. More details will
will sometimes be available in the received status-code option sometimes be available in the received status-code option in the
in the DHCPLEASEQUERYDONE message. If there is no status-code DHCPLEASEQUERYDONE message. If there is no status-code option in
option in the DHCPLEASEQUERYDONE message, then the query the DHCPLEASEQUERYDONE message, then the query completed
completed successfully. successfully.
Note that a query which returned no data, that is a Note that a query that 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
to have no information to return to a DHCPBULKLEASEQUERY have no information to return to a DHCPBULKLEASEQUERY request.
request.
The DHCPLEASEUNKNOWN message MUST NOT appear in a response to a Bulk The DHCPLEASEUNKNOWN message MUST NOT appear in a response to a Bulk
Leasequery. Leasequery.
The requestor MUST NOT assume that there is any inherent order in the The requestor MUST NOT assume that there is any inherent order in the
IP address binding information that is sent in response to a IP address binding information that is sent in response to a
DHCPBULKLEASEQUERY. While the base-time will tend to increase DHCPBULKLEASEQUERY. While the base-time will tend to increase
monotonically (as it is the current time on the DHCPv4 server), the monotonically (as it is the current time on the DHCPv4 server), the
actual time that any IP address binding information changed is actual time that any IP address binding information changed is
unrelated to the base-time. unrelated to the base-time.
The DHCPLEASEQUERYDONE message always ends a successful The DHCPLEASEQUERYDONE message always ends a successful
DHCPBULKLEASEQUERY request and any unsuccessful DHCPBULKLEASEQUERY DHCPBULKLEASEQUERY request and any unsuccessful DHCPBULKLEASEQUERY
requests not terminated by a dropped connection. After receiving requests not terminated by a dropped connection. After receiving a
DHCPLEASEQUERYDONE from a server, the requestor MAY close the TCP DHCPLEASEQUERYDONE from a server, the requestor MAY close the TCP
connection to that server if no other DHCPBULKLEASEQUERY is connection to that server if no other DHCPBULKLEASEQUERY is
outstanding on that TCP connection. outstanding on that TCP connection.
The DHCPv4 Leasequery protocol [RFC4388] uses the associated-ip The DHCPv4 Leasequery protocol [RFC4388] uses the associated-ip
option as an indicator that multiple bindings were present in option as an indicator that multiple bindings were present in
response to a single DHCPv4 client based query. For Bulk Leasequery, response to a single DHCPv4 client-based query. For Bulk Leasequery,
a separate message is returned for each binding, and so the a separate message is returned for each binding, so the associated-ip
associated-ip option is not used. option is not used.
7.4. Processing Time Values in Leasequery messages 7.4. Processing Time Values in Leasequery Messages
Bulk Leasequery requests may be made to a DHCPv4 server whose Bulk Leasequery requests may be made to a DHCPv4 server whose
absolute time may not be synchronized with the local time of the absolute time may not be synchronized with the local time of the
requestor. Thus, there are at least two time contexts in even the requestor. Thus, there are at least two time contexts in even the
simplest Bulk Leasequery response, and in the situation where simplest Bulk Leasequery response, and in the situation where
multiple DHCPv4 servers are queried, the situation becomes even more multiple DHCPv4 servers are queried, the situation becomes even more
complex. complex.
If the requestor of a Bulk Leasequery is saving the data returned in If the requestor of a Bulk Leasequery is saving the data returned in
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 some of these will be time in the context of the requestor, and some
some will be time in the context of the DHCPv4 server. 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 ever need to issue a DHCPBULKLEASEQUERY
message using those options as part of a later query, since those message using those options as part of a later query, since those
options require a time in the context of the DHCPv4 server. 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 or query-end-time option, the base-time is used as query-start-time or query-end-time option, the base-time is used as
part of the conversion of the other times in the Leasequery message part of the conversion of the other times in the Leasequery message
to values which are meaningful in the context of the requestor. to values that are meaningful in the context of the requestor. These
These other time values are specified as a offset (duration) from the other time values are specified as a offset (duration) from the base-
base-time value and not as an absolute time. time value and not as an absolute time.
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. clock skew will usually be zero.
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 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
particular IPv4 address is termed a "record". The times used in the particular IPv4 address is termed a "record". The times used in the
algorithm below SHOULD have been converted into the requestor's algorithm below SHOULD have been converted into the requestor's
context and the time comparisons SHOULD be performed in a manner context, and the time comparisons SHOULD be performed in a manner
consistent with the information in Section 7.4. consistent with the information in Section 7.4.
o If both the existing and the new record contain client-last- o If both the existing and the new record contain client-last-
transaction-time information, the record with the later client- transaction-time information, the record with the later client-
last-transaction-time is considered better. last-transaction-time is considered better.
o If one of the records contains client-last-transaction-time
information and the other one doesn't, then compare the client-
last-transaction-time in the record that contains it against the
other record's start-time-of-state. The record with the later
time is considered better.
o If neither record contains client-last-transaction-time o If one of the records contains client-last-transaction-time
information, compare their start-time-of-state information. The information and the other one doesn't, then compare the client-
record with the later start-time-of-state is considered better. last-transaction-time in the record that contains it against the
other record's start-time-of-state. The record with the later
time is considered better.
o If none of the comparisons above yield a clear answer as to o If neither record contains client-last-transaction-time
which record is later, then compare the value of the REMOTE flag information, compare their start-time-of-state information. The
from the data-source option for each record. record with the later start-time-of-state is considered better.
If the values of the REMOTE flag are different between the two o If none of the comparisons above yield a clear answer as to which
records, the record with the REMOTE flag value of local is record is later, then compare the value of the REMOTE flag from
considered better. the data-source option for each record. If the values of the
REMOTE flag are different between the two records, the record with
the REMOTE flag value of local is considered better.
The above algorithm does not necessarily determine which record is The above algorithm does not necessarily determine which record is
better. In the event that the algorithm is inconclusive with regard better. In the event that the algorithm is inconclusive with regard
to a record which was just received by the requestor, the requestor to a record that was just received by the requestor, the requestor
SHOULD use additional information in the two records to make a SHOULD use additional information in the two records to make a
determination as to which record is better. determination as to which record is better.
7.7. Multiple Queries to a Single Server over One Connection 7.7. Multiple Queries to a Single Server over One Connection
Bulk Leasequery requestors may need to make multiple queries in order Bulk Leasequery requestors may need to make multiple queries in order
to recover binding information. A requestor MAY use a single to recover binding information. A requestor MAY use a single
connection to issue multiple queries to a server willing to support connection to issue multiple queries to a server willing to support
them. Each query MUST have a unique xid. them. Each query MUST have a unique xid.
A server SHOULD allow configuration of the number of queries that can A server SHOULD allow configuration of the number of queries that can
be processed simultaneously over a single connection. A server be processed simultaneously over a single connection. A server
SHOULD read the number of queries it is configured to process SHOULD read the number of queries it is configured to process
simultaneously and only read any subsequent queries as current simultaneously and only read any subsequent queries as current
queries are processed. queries are processed.
A server that is processing multiple queries simultaneously MUST NOT A server that is processing multiple queries simultaneously MUST NOT
block sending replies on new queries until all replies for the block sending replies on new queries until all replies for the
existing query are complete. Requestors need to be aware that existing query are complete. Requestors need to be aware that
replies for multiple queries may be interleaved within the stream of replies for multiple queries may be interleaved within the stream of
reply messages. Requestors that are not able to process interleaved reply messages. Requestors that are not able to process interleaved
replies (based on xid) MUST NOT send more than one query over a replies (based on xid) MUST NOT send more than one query over a
single connection prior to the completion of the previous query. single connection prior to the completion of the previous query.
Requestors should be aware that servers are not required to process Requestors should be aware that servers are not required to process
more than one query over a connection at a time (the limiting case more than one query over a connection at a time (the limiting case
for the configuration described above), and that servers are likely for the configuration described above) and that servers are likely to
to limit the rate at which they process queries from any one limit the rate at which they process queries from any one requestor.
requestor.
7.7.1. Example 7.7.1. Example
This example illustrates what a series of queries and responses might This example illustrates what a series of queries and responses might
look like. This is only an example - there is no requirement that look like. This is only an example -- there is no requirement that
this sequence must be followed, or that requestors or servers must this sequence must be followed or that requestors or servers must
support parallel queries. support parallel queries.
In the example session, the client sends four queries after In the example session, the client sends four queries after
establishing a connection. Query 1 returns no results; query 2 establishing a connection. Query 1 returns no results; query 2
returns 3 messages and the stream of replies concludes before the returns 3 messages, and the stream of replies concludes before the
client issues any new query. Query 3 and query 4 overlap, and the client issues any new query. Query 3 and query 4 overlap, and the
server interleaves its replies to those two queries. server interleaves its replies to those two queries.
Requestor Server Requestor Server
--------- ------ --------- ------
DHCPBULKLEASEQUERY xid 1 -----> DHCPBULKLEASEQUERY xid 1 ----->
<----- DHCPLEASEQUERYDONE xid 1 <----- DHCPLEASEQUERYDONE xid 1
DHCPBULKLEASEQUERY xid 2 -----> DHCPBULKLEASEQUERY xid 2 ----->
<----- DHCPLEASEACTIVE xid 2 <----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEACTIVE xid 2 <----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEACTIVE xid 2 <----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEQUERYDONE xid 2 <----- DHCPLEASEQUERYDONE xid 2
DHCPBULKLEASEQUERY xid 3 -----> DHCPBULKLEASEQUERY xid 3 ----->
DHCPBULKLEASEQUERY xid 4 -----> DHCPBULKLEASEQUERY xid 4 ----->
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 3 <----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEACTIVE xid 4 <----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEUNASSIGNED xid 3 <----- DHCPLEASEUNASSIGNED xid 3
<----- 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
If a requestor as no additional queries to send, or doesn't know if If a requestor has no additional queries to send, or doesn't know if
it has additional queries to send or not, then it SHOULD close the it has additional queries to send or not, then it SHOULD close the
connection after receiving the DHCPLEASEQUERYDONE message for the connection after receiving the DHCPLEASEQUERYDONE message for the
last outstanding query that it has sent. last outstanding query that it sent.
The requestor SHOULD close connections in a graceful manner and not The requestor SHOULD close connections in a graceful manner and not
an abort. The requestor SHOULD NOT assume that the manner in which an abort. The requestor SHOULD NOT assume that the manner in which
the DHCP server closed a connection carries any special meaning. the DHCP server closed a connection carries any special meaning.
Typically, the requestor is the entity which will close the Typically, the requestor is the entity that will close the
connection, as servers will often wait with an open connection in connection, as servers will often wait with an open connection in
case the requestor has additional queries. case the requestor has additional queries.
If a server closes a connection with an exception condition, the If a server closes a connection with an exception condition, the
requestor SHOULD consider as valid any completely received requestor SHOULD consider as valid any completely received
intermediate results, and the requestor MAY retry the Bulk Leasequery intermediate results, and the requestor MAY retry the Bulk Leasequery
operation. operation.
8. Server Behavior 8. Server Behavior
skipping to change at page 28, line 24 skipping to change at page 29, line 32
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 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 status- are not permitted with the DHCPLEASEQUERYDONE message with a status-
code option 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 a BULK_LQ_DATA_TIMEOUT. We make this recommendation
recommendation to allow servers to control the period of time they to allow servers to control the period of time they are willing to
are willing to wait before abandoning an inactive connection, wait before abandoning an inactive connection, independent of the TCP
independent of the TCP implementations they may be using. 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 a 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 status-code option status if DHCPLEASEQUERYDONE message MUST have a status-code option status if
the termination was other than successful, and SHOULD NOT contain a the termination was other than successful, and SHOULD NOT contain a
status-code option 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
skipping to change at page 29, line 22 skipping to change at page 30, line 32
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. 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 status-code status of DHCPLEASEQUERYDONE message with a status-code option status of
MalformedQuery. MalformedQuery.
Any DHCPBULKLEASEQUERY which has more than one of the following Any DHCPBULKLEASEQUERY that 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 status-code option 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.
o Query by MAC address o Query by MAC address
Every IP address that has a current binding to a DHCPv4 client Every IP address that has a current binding to a DHCPv4 client
matching the chaddr, htype, and hlen in the DHCPBULKLEASEQUERY matching the chaddr, htype, and hlen in the DHCPBULKLEASEQUERY
request MUST be returned in a DHCPLEASEACTIVE message. request MUST be returned in a DHCPLEASEACTIVE message.
o Query by Client-Id o Query by Client-identifier
Every IP address that has a current binding to a DHCPv4 client Every IP address that has a current binding to a DHCPv4 client
matching the client-id option in the DHCPBULKLEASEQUERY request matching the Client-identifier option in the DHCPBULKLEASEQUERY
MUST be returned in a DHCPLEASEACTIVE message. request MUST be returned in a DHCPLEASEACTIVE message.
o Query by Remote-Id o Query by Remote ID
Every IP address that has a current binding to a DHCPv4 client Every IP address that has a current binding to a DHCPv4 client
matching the remote-id sub-option of the relay-agent-information matching the Remote ID sub-option of the relay-agent-information
option in the DHCPBULKLEASEQUERY request MUST be returned in a option in the DHCPBULKLEASEQUERY request MUST be returned in a
DHCPLEASEACTIVE message. DHCPLEASEACTIVE message.
o Query by Relay-Id o Query by Relay-ID
Every IP address that has a current binding to a DHCPv4 client Every IP address that has a current binding to a DHCPv4 client
matching the relay-id sub-option of the relay-agent-information matching the Relay-ID sub-option of the relay-agent-information
option in the DHCPBULKLEASEQUERY request MUST be returned in a option in the DHCPBULKLEASEQUERY request MUST be returned in a
DHCPLEASEACTIVE message. DHCPLEASEACTIVE message.
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
absence of any other primary query. That is, if there is no of any other primary query. That is, if there is no value in the
value in the chaddr, hlen, htype, no client-id option, no chaddr, hlen, htype, no Client-identifier option, and no Remote ID
remote-id sub-option or relay-id sub-option of the relay-agent- sub-option or Relay-ID sub-option of the relay-agent-information
information option, then the request is a query for information option, then the request is a query for information concerning all
concerning all configured IP addresses. In this case, every configured IP addresses. In this case, every configured IP
configured IP address that has a current binding to a DHCPv4 address that has a current binding to a DHCPv4 client MUST be
client MUST be returned in a DHCPLEASEACTIVE message. In returned in a DHCPLEASEACTIVE message. In addition, every
addition, every configured IP address that does not have a configured IP address that does not have a current binding to a
current binding to a DHCPv4 client MUST be returned in a DHCPv4 client MUST be returned in a DHCPLEASEUNASSIGNED message.
DHCPLEASEUNASSIGNED message.
In this form of query, each configured IP address MUST be In this form of query, each configured IP address MUST be returned
returned at most one time. If the absence of qualifiers at most one time. In the absence of qualifiers restricting the
restricting the number of IP addresses returned, every number of IP addresses returned, every configured IP address MUST
configured IP address MUST be returned exactly once. be returned exactly once.
There are three qualifiers that can be applied to any of the above There are three qualifiers that 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
If a query-start-time option appears in the DHCPBULKLEASEQUERY If a query-start-time option appears in the DHCPBULKLEASEQUERY
request, only IP address bindings that have changed on or after the request, only IP address bindings that have changed on or after
time specified in the query-start-time option should be returned. the time specified in the query-start-time option should be
returned.
o Query End Time o Query End Time
If a query-end-time option appears in the DHCPBULKLEASEQUERY If a query-end-time option appears in the DHCPBULKLEASEQUERY
request, only IP address bindings that have changed on or before request, only IP address bindings that have changed on or before
the time specified in the query-end-time option should be returned. the time specified in the 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
(global) VPN is used to satisfy the query. A vpn-id option (global) VPN is used to satisfy the query. A VPN-ID option
[RFC6607] value other than the wildcard value (254) allows the [RFC6607] value other than the wildcard value (254) 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 of a type 254 which indicates that document to allow specification of a type 254, which indicates
all configured VPN's be searched in order to satisfy the primary that all configured VPNs be searched in order to satisfy the
query. primary query.
In all cases, if the information returned in a DHCPLEASEACTIVE or In all cases, if the information returned in a DHCPLEASEACTIVE or
DHCPLEASEUNASSIGNED message is for a VPN other than the default DHCPLEASEUNASSIGNED message is for a VPN other than the default
(global) VPN, a vpn-id option MUST appear in the packet. (global) VPN, a VPN-ID option MUST appear in the packet.
The query-start-time and query-end-time qualifiers are used to The query-start-time and query-end-time qualifiers are used to
constrain the amount of data returned by a Bulk Leasequery request by constrain the amount of data returned by a Bulk Leasequery request by
returning only IP addresses whose address bindings have changed in returning only IP addresses whose address bindings have changed in
some way during the time window specified by the query-start-time and some way during the time window specified by the query-start-time and
query-end-time. query-end-time.
A DHCPv4 server SHOULD consider an address binding to have changed A DHCPv4 server SHOULD consider an address binding to have changed
during a specified time window if either the client-last- during a specified time window if either the client-last-
transaction-time or the start-time-of-state of the address binding transaction-time or the start-time-of-state of the address binding
changed during that time window. changed during that time window.
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 specification [RFC4388] 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
6.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 are 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 option in later messages.
The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based
on the value of the dhcp-state option. If the dhcp-state option on the value of the dhcp-state option. If the dhcp-state option
value is ACTIVE, then the message type is DHCPLEASEACTIVE, otherwise value is ACTIVE, then the message type is DHCPLEASEACTIVE; otherwise,
the message type is DHCPLEASEUNASSIGNED. the message type is DHCPLEASEUNASSIGNED.
In addition to the basic message construction described in [RFC4388], In addition to the basic message construction described in [RFC4388],
the following guidelines exist: the following guidelines exist:
1. If the dhcp-state option code appears in the dhcp-parameter- 1. If the dhcp-state option code appears in the dhcp-parameter-
request-list, the DHCPv4 server SHOULD include a dhcp-state request-list, the DHCPv4 server SHOULD include a dhcp-state
option whose value corresponds most closely to the state held option whose value corresponds most closely to the state held by
by the DHCPv4 server for the IP address associated with this the DHCPv4 server for the IP address associated with this reply.
reply. If the state is ACTIVE and the message being returned If the state is ACTIVE and the message being returned is
is DHCPLEASEACTIVE, then the DHCPv4 server MAY choose to not DHCPLEASEACTIVE, then the DHCPv4 server MAY choose to not send
send the dhcp-state option. The requestor SHOULD assume that the dhcp-state option. The requestor SHOULD assume that any
any DHCPLEASEACTIVE message arriving without a requested dhcp- DHCPLEASEACTIVE message arriving without a requested dhcp-state
state option has a dhcp-state of ACTIVE. option has a dhcp-state of ACTIVE.
2. If the base-time option code appears in the dhcp-parameter- 2. If the base-time option code appears in the dhcp-parameter-
request-list, the DHCPv4 server MUST include a base-time request-list, the DHCPv4 server MUST include a base-time option,
option, which is the current time in the DHCPv4 server's which is the current time in the DHCPv4 server's context and the
context and the time from which the start-time-of-state, dhcp- time from which the start-time-of-state, dhcp-lease-time, client-
lease-time, client-last-transaction-time, and other duration- last-transaction-time, and other duration-style times are based
style times are based upon. 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-
start-time-of-state option whose value represents the time at time-of-state option whose value represents the time at which the
which the dhcp-state option's state became valid. 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 timeout value
associated with it. associated with it.
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.
zero. Thus, in the absence of the data-source option, the Thus, in the absence of the data-source option, the assumption is
assumption is that all of the flags were zero. that all of the flags are 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
information is available. information is available.
7. If there is a dhcp-parameter-request-list in the initial 7. If there is a dhcp-parameter-request-list in the initial
DHCPBULKLEASEQUERY request, then it should be used for all of DHCPBULKLEASEQUERY request, then it should be used for all of the
the replies generated by that request. Some options can be replies generated by that request. Some options can be sent from
sent from a DHCPv4 client to the server or from the DHCPv4 a DHCPv4 client to the server or from the DHCPv4 server to a
server to a DHCPv4 client. Option 125 is such an option. If DHCPv4 client. Option 125 is such an option. If the option code
the option code for one of these options appears in the dhcp- for one of these options appears in the dhcp-parameter-request-
parameter-request-list, it SHOULD result in returning the value list, it SHOULD result in returning the value of the option sent
of the option sent by the DHCPv4 client to the server if one by the DHCPv4 client to the server if one exists.
exists.
Note that there may be other requirements for a reply to a Note that there may be other requirements for a reply to a
DHCPBULKLEASEQUERY request discussed in Section 8.2. DHCPBULKLEASEQUERY request, as discussed in Section 8.2.
8.4. Multiple or Parallel Queries 8.4. Multiple or Parallel Queries
As discussed in Section 7.3, requestors may want to use a connection As discussed in Section 7.3, requestors may want to use a connection
that has already been established when they need to make additional that has already been established when they need to make additional
queries. Servers SHOULD support reading and processing multiple queries. Servers SHOULD support reading and processing multiple
queries from a single connection and SHOULD allow configuration of queries from a single connection and SHOULD allow configuration of
the number of simultaneous queries it may process. A server MUST NOT the number of simultaneous queries it may process. A server MUST NOT
read more query messages from a connection than it is prepared to read more query messages from a connection than it is prepared to
process simultaneously. process simultaneously.
This SHOULD be a feature that is administratively controlled. This SHOULD be a feature that is administratively controlled.
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 close connections in a graceful manner and The DHCPv4 server SHOULD close connections in a graceful manner and
not abort the connection. The DHCPv4 server SHOULD NOT assume that not abort the connection. The DHCPv4 server SHOULD NOT assume that
the manner in which the requestor closed a connection carries any the manner in which the requestor closed a connection carries any
special meaning. special meaning.
Typically, the DHCPv4 server will only close the connection after Typically, the DHCPv4 server will only close the connection after
some form of an exception or a timeout on the connection. some form of an exception or a timeout on the connection.
Using a timer to detect when a connection is idle, and then closing Using a timer to detect when a connection is idle and then closing
that connection is designed to protect the DHCPv4 server from that connection is designed to protect the DHCPv4 server from
consuming unnecessary resources. consuming unnecessary resources.
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 if there is no
current query outstanding for that connection. It should restart current query outstanding for that connection. It should restart
this timer if a query arrives over that connection. If the timer this timer if a query arrives over that connection. If the timer
expires, the DHCPv4 server should close the connection. expires, 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 status-code 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 connection is closed for any reason, all of for the abort. If the connection is closed for any reason, all of
the data flows associated with any currently outstanding the data flows associated with any currently outstanding
DHCPBULKLEASEQUERY messages will be terminated. DHCPBULKLEASEQUERY messages will be terminated.
If the server detects that the requesting end of the connection has If the server detects that the requesting end of the connection has
been closed, the server MUST close its end of the connection. been closed, the server MUST close its end of the connection.
9. Security Considerations 9. Security Considerations
The "Security Considerations" section of [RFC2131] details the The Security Considerations section of [RFC2131] details the general
general threats to DHCPv4. The DHCPv4 Leasequery specification threats to DHCPv4. The DHCPv4 Leasequery specification [RFC4388]
[RFC4388] describes recommendations for the Leasequery protocol, describes recommendations for the Leasequery protocol, especially
especially with regard to authentication of LEASEQUERY messages, with regard to authentication of LEASEQUERY messages, mitigation of
mitigation of packet-flooding DOS attacks, and restriction to trusted packet-flooding DoS attacks, and restriction to trusted requestors.
requestors.
The use of TCP introduces some additional concerns. Attacks that The use of TCP introduces some additional concerns. Attacks that
attempt to exhaust the DHCPv4 server's available TCP connection attempt to exhaust the DHCPv4 server's available TCP connection
resources, such as SYN flooding attacks, can compromise the ability resources, such as SYN flooding attacks, can compromise the ability
of legitimate requestors to receive service. Malicious requestors of legitimate requestors to receive service. Malicious requestors
who succeed in establishing connections, but who then send invalid who succeed in establishing connections but who then send invalid
queries, partial queries, or no queries at all also can exhaust a queries, partial queries, or no queries at all can also exhaust a
server's pool of available connections. We recommend that servers server's pool of available connections. We recommend that servers
offer configuration to limit the sources of incoming connections, offer configuration to limit the sources of incoming connections,
that they limit the number of accepted connections and the number of that they limit the number of accepted connections and the number of
in-process queries from any one connection, and that they limit the in-process queries from any one connection, and that they limit the
period of time during which an idle connection will be left open. period of time during which an idle connection will be left open.
There are two specific issues regarding Bulk Leasequery security that There are two specific issues regarding Bulk Leasequery security that
deserve explicit mention. The first is preventing information that deserve explicit mention. The first is preventing information that
Bulk Leasequery can provide from reaching clients who are not Bulk Leasequery can provide from reaching clients who are not
authorized to receive such information. The second is ensuring that authorized to receive such information. The second is ensuring that
authorized clients of the Bulk Leasequery capability receive accurate authorized clients of the Bulk Leasequery capability receive accurate
information from the Server (and that this information is not information from the server (and that this information is not
disrupted in transit). disrupted in transit).
To prevent information leakage to unauthorized clients Servers SHOULD To prevent information leakage to unauthorized clients, servers
restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages SHOULD restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY
to certain requestors, either through explicit configuration of the messages to certain requestors, either through explicit configuration
Server itself or by employing external network elements to provide of the server itself or by employing external network elements to
such restrictions. In particular, the typical DHCPv4 client SHOULD provide such restrictions. In particular, the typical DHCPv4 client
NOT be allowed to receive a response to a Bulk Leasequery request, SHOULD NOT be allowed to receive a response to a Bulk Leasequery
and some technique MUST exist to allow prevention of such access in request, and some technique MUST exist to allow prevention of such
any environment where Bulk Leasequery is deployed. access in any environment where Bulk Leasequery is deployed.
Connections not from permitted requestors SHOULD be closed Connections not from permitted requestors SHOULD be closed
immediately, to avoid server connection resource exhaustion or immediately to avoid server connection resource exhaustion or
alternatively, simply not be allowed to reach the server at all. alternatively, simply not be allowed to reach the server at all.
Servers SHOULD have the capability to restrict certain requestors to Servers SHOULD have the capability to restrict certain requestors to
certain query types. Servers MAY reply to queries that are not certain query types. Servers MAY reply to queries that are not
permitted with the DHCPLEASEQUERYDONE message with a status-code permitted with the DHCPLEASEQUERYDONE message with a status-code
option status of NotAllowed, or MAY simply close the connection. option status of NotAllowed or MAY simply close the connection.
To prevent disruption and malicious corruption of Bulk Leasequery To prevent disruption and malicious corruption of Bulk Leasequery
data flows between the server and authorized clients these data flows data flows between the server and authorized clients, these data
SHOULD transit only secured networks. These data flows are flows SHOULD transit only secured networks. These data flows are
typically infrastructure oriented, and there is usually no reason to typically infrastructure oriented, and there is usually no reason to
have them flowing over networks where such attacks are likely. In have them flowing over networks where such attacks are likely. In
the rare cases where these data flows might need to be sent through the rare cases where these data flows might need to be sent through
unsecured networks, they MUST sent over connections secured through unsecured networks, they MUST be sent over connections secured
means external to the DHCPv4/DHCPv6 server and its client(s) (e.g., through means external to the DHCPv4/DHCPv6 server and its client(s)
through VPN's). (e.g., through VPNs).
Authentication for DHCP Messages [RFC3118] MUST NOT be used to Authentication for DHCP messages [RFC3118] MUST NOT be used to
attempt to secure transmission of the messages described in this attempt to secure transmission of the messages described in this
document. In particular, the message framing would not be protected document. In particular, the message framing would not be protected
by using the mechanisms described in [RFC3118] (which was designed by using the mechanisms described in [RFC3118] (which was designed
only with UDP transport in mind). only with UDP transport in mind).
10. IANA Considerations 10. IANA Considerations
IANA is requested to assign the following new DHCPv4 option codes IANA has assigned the following new DHCPv4 option codes from the
from the registry "BOOTP Vendor Extensions and DHCP Options" registry "BOOTP Vendor Extensions and DHCP Options" maintained at
maintained at http://www.iana.org/assignments/bootp-dhcp-parameters http://www.iana.org/assignments/bootp-dhcp-parameters.
1. An option code of TBD1 for status-code. 1. An option code of 151 for status-code.
2. An option code of TBD2 for base-time. 2. An option code of 152 for base-time.
3. An option code of TBD3 for start-time-of-state. 3. An option code of 153 for start-time-of-state.
4. An option code of TBD4 for query-start-time. 4. An option code of 154 for query-start-time.
5. An option code of TBD5 for query-end-time. 5. An option code of 155 for query-end-time.
6. An option code of TBD6 for dhcp-state. 6. An option code of 156 for dhcp-state.
7. An option code of TBD7 for data-source. 7. An option code of 157 for data-source.
IANA is requested to assign the following new DHCP message types from IANA has assigned the following new DHCP message types from the
the registry "DHCP Message Type 53 Values" maintained at registry "DHCP Message Type 53 Values" maintained at
http://www.iana.org/assignments/bootp-dhcp-parameters http://www.iana.org/assignments/bootp-dhcp-parameters.
1. A dhcp-message-type of TBD8 for DHCPBULKLEASEQUERY. 1. A dhcp-message-type of 14 for DHCPBULKLEASEQUERY.
2. A dhcp-message-type of TBD9 for DHCPLEASEQUERYDONE. 2. A dhcp-message-type of 15 for DHCPLEASEQUERYDONE.
IANA is requested to create a new registry on the same assignments IANA has created a new registry on the same assignments page, titled
page, titled "DHCP State TBD6 Values" (where TBD6 corresponds to the "DHCP State 156 Values" (where 156 corresponds to the assigned value
assigned value of the dhcp-state option, above). This registry will of the dhcp-state option above). This registry has the following
have the following initial values: initial values:
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
New values for this name space may only be defined by IETF Review, as New values for this namespace may only be defined by IETF Review, as
described in [RFC5226]. described in [RFC5226].
IANA is requested to create a new registry on the same assignments IANA has created a new registry on the same assignments page, titled
page, titled "DHCP Status Code TBD1 Values" (where TBD1 corresponds "DHCP Status Code 151 Values" (where 151 corresponds to the assigned
to the assigned value of the status-code option, above). This value of the status-code option above). This registry has the
registry will have the following initial values: following initial values:
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
New values for this name space may only be defined by IETF Review, as New values for this namespace may only be defined by IETF Review, as
described in [RFC5226]. described in [RFC5226].
IANA is requested to revise the registry "VSS Type Options" created IANA has revised the registry "VSS Type Options" created by [RFC6607]
by [RFC6607] in the overall area "Dynamic Host Configuration Protocol in the overall area "Dynamic Host Configuration Protocol (DHCP) and
(DHCP) and Bootstrap Protocol (BOOTP) Parameters". It should be Bootstrap Protocol (BOOTP) Parameters". It has been revised to
revised to appear as follows. Note that the number range for appear as follows. Note that the number range for "Unassigned" has
"Unassigned" has changed as well as the new line for "All VPN's changed, and a new line for "All VPNs (wildcard)" was added.
(wildcard)" which was added.
Type VSS Information Format
------------------------------------------------------------
0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID
2-253 Unassigned
254 All VPN's (wildcard)
255 Global, default VPN
11. Contributing Authors
The following authors were full participants in creating this
document. In order to facilitate the process of approval for this
work, they graciously volunteered to have their names appear in this
section instead of on the title page.
Pavan Kurapati
Juniper Networks Ltd.
Embassy Prime Buildings, C.V.Raman Nagar
Bangalore 560 093
India
Email: kurapati@juniper.net
URI: http://www.juniper.net/
Bernie Volz
Cisco Systems
1414 Massachusetts Ave.
Boxborough, Massachusetts 01719
Phone: (978) 936-0000
EMail: volz@cisco.com Type VSS Information Format
------------------------------------------------------------
0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID
2-253 Unassigned
254 All VPNs (wildcard)
255 Global, default VPN
12. Acknowledgements 11. Acknowledgements
This draft is a collaboration between the authors of draft-dtv-dhc- Significant text as well as important ideas were borrowed in whole or
dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk- in part from "DHCPv6 Bulk Leasequery" [RFC5460], written by Mark
leasequery-00.txt. Both documents acknowledged that significant text Stapp. Further suggestions and improvements were made by
as well as important ideas were borrowed in whole or in part from the participants in the DHC Working Group, including Alfred Hoenes.
DHCPv6 Bulk Leasequery RFC, [RFC5460] written by Mark Stapp. Further
suggestions and improvements were made by participants in the DHC
working group, including Alfred Hoenes.
13. References 12. References
13.1. Normative References 12.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
E. Lear, "Address Allocation for Private Internets", RFC 1918, Requirement Levels", BCP 14, RFC 2119, March 1997.
February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
Requirement Levels", RFC 2119, March 1997. 2131, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
March 1997. Extensions", RFC 2132, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
Extensions", RFC 2132, March 1997. 3046, January 2001.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for
3046, January 2001. DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms, R. "Authentication for DHCP Messages", RFC 3118, [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
June 2001. Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Protocol (DHCP) Leasequery", RFC 4388, February 2006. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. BCP 153, RFC 5735, January 2010.
[RelayId] Joshi, B., Rao, D., and M. Stapp, "The DHCPv4 Relay Agent [RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet
Identifier Suboption", draft-ietf-dhc-relay-id-suboption-11.txt, Selection Options for DHCPv4 and DHCPv6", RFC 6607, April
(work in progress) July 2012. 2012.
[RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet [RFC6925] Joshi, B., Desetti, R., and M. Stapp, "The DHCPv4 Relay
Selection Options for DHCPv4 and DHCPv6", RFC 6607, April 2012. Agent Identifier Sub-Option", RFC 6925, April 2013.
13.2. Informative References 12.2. Informative References
[RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC [RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
951, September 1985. September 1985.
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap [RFC1542] Wimer, W., "Clarifications and Extensions for the
Protocol", RFC 1542, October 1993. Bootstrap Protocol", RFC 1542, October 1993.
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification Documents", for Transmission Control Protocol (TCP) Specification
RFC 4614, September 2006. Documents", RFC 4614, September 2006.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009. 2009.
Authors' Addresses Authors' Addresses
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
USA
Phone: (978) 936-0000 Phone: (978) 936-0000
EMail: kkinnear@cisco.com
EMail: kkinnear@cisco.com Mark Stapp
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, Massachusetts 01719
USA
Neil Russell Phone: (978) 936-0000
BMC Software EMail: mjs@cisco.com
10 Maguire Rd., Bldg. 3, Ste. 320
Lexington, MA 02421
Phone: (781) 257-3105 D.T.V Ramakrishna Rao
Infosys Ltd.
44 Electronics City, Hosur Road
Bangalore 560 100
India
EMail: neil_russell@bmc.com EMail: ramakrishnadtv@infosys.com
URI: http://www.infosys.com/
Mark Stapp Bharat Joshi
Cisco Systems Infosys Ltd.
1414 Massachusetts Ave. 44 Electronics City, Hosur Road
Boxborough, Massachusetts 01719 Bangalore 560 100
India
Phone: (978) 936-0000 EMail: bharat_joshi@infosys.com
EMail: mjs@cisco.com URI: http://www.infosys.com/
Ramakrishna Rao DTV Neil Russell
Infosys Technologies Ltd. Sea Street Technologies Inc.
44 Electronics City, Hosur Road
Bangalore 560 100
India
EMail: ramakrishnadtv@infosys.com EMail: neil.e.russell@gmail.com
URI: http://www.infosys.com/ Pavan Kurapati
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
Bharat Joshi EMail: kurapati@juniper.net
Infosys Technologies Ltd. URI: http://www.juniper.net/
44 Electronics City, Hosur Road
Bangalore 560 100
India
EMail: bharat_joshi@infosys.com Bernie Volz
URI: http://www.infosys.com/ Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, Massachusetts 01719
USA
Phone: (978) 936-0000
EMail: volz@cisco.com
 End of changes. 287 change blocks. 
792 lines changed or deleted 759 lines changed or added

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