DHC Working Group D. Rao
Internet-Draft B. Joshi
Expires: January 2, 2009 P. Kurapati
Infosys Technologies Ltd.
July 1, 2008
DHCPv4 bulk lease query
draft-dtv-dhc-dhcpv4-bulk-leasequery-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
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
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
extended with a Leasequery capability that allows a client to request
information about DHCPv4 bindings. That mechanism is limited to
queries for individual bindings. In some situations individual
binding queries may not be efficient, or even possible. This
document expands on the Leasequery protocol, adding new query types
and allowing for bulk transfer of DHCPv4 binding data via TCP.
Rao, et al. Expires January 2, 2009 [Page 1]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Information Acquisition before Data Starts . . . . . . . . 6
4.2. Lessen Negative Caching . . . . . . . . . . . . . . . . . 6
4.3. Antispoofing in 'Fast Path' . . . . . . . . . . . . . . . 6
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
6. Interaction Between UDP Leasequery and Bulk Leasequery . . . . 9
7. Message and Option Definitions . . . . . . . . . . . . . . . . 10
7.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 10
7.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2.1. DHCPLEASEDATA . . . . . . . . . . . . . . . . . . . . 12
7.2.2. DHCPLEASEDONE . . . . . . . . . . . . . . . . . . . . 12
7.2.3. DHCPLEASEQUERYFAIL . . . . . . . . . . . . . . . . . . 12
7.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 13
7.3.1. QUERY_BY_RELAYID . . . . . . . . . . . . . . . . . . . 13
7.3.2. QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . 14
7.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.4.1. STATUS-CODE option . . . . . . . . . . . . . . . . . . 14
7.5. Connection and Transmission Parameters . . . . . . . . . . 16
8. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Connecting . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Forming Queries . . . . . . . . . . . . . . . . . . . . . 17
8.3. Processing Replies . . . . . . . . . . . . . . . . . . . . 17
8.4. Leasequery Request Completion Criteria . . . . . . . . . . 18
8.5. Querying Multiple Servers . . . . . . . . . . . . . . . . 19
8.6. Multiple Queries to a Single Server . . . . . . . . . . . 19
8.6.1. Example . . . . . . . . . . . . . . . . . . . . . . . 19
8.7. Closing Connections . . . . . . . . . . . . . . . . . . . 20
9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Accepting Connections . . . . . . . . . . . . . . . . . . 21
9.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 21
9.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 22
9.4. Closing Connections . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.1. Normative Reference . . . . . . . . . . . . . . . . . . . 27
13.2. Informative Reference . . . . . . . . . . . . . . . . . . 27
Appendix 1. Why a New Leasequery is Required? . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Rao, et al. Expires January 2, 2009 [Page 2]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
1. Introduction
The DHCPv4 [2] protocol specifies a mechanism for the assignment of
IPv4 address and configuration information to IPv4 nodes. DHCPv4
servers maintain authoritative binding information.
+--------+
| DHCP | +--------------+
| Server |-...-| DSLAM |
| | | Relay Agent |
+--------+ +--------------+
| |
+------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Host1| |Host2| |Host3|
+-----+ +-----+ +-----+
Figure 1
DHCP relay agents snoop DHCP messages and append relay agent
information option before relaying it to the configured DHCP Servers
(see Figure 1). In this process, some relay agents also glean the
lease information sent by the server and maintain this locally. This
information is used for prevention of spoofing attempts from the
clients and to install routes. When a relay agent reboots, this
information is lost. RFC 4388 [5] has defined a mechanism to obtain
this lease information from the server. The existing query types in
leasequery are data driven; relay agent initiates the leasequery when
it receives data traffic from/for the client. This approach does not
scale well when there are thousands of clients connected to the relay
agent. Different query types are needed where a relay agent can
query the server without waiting for the traffic from/for the
clients.
This document extends the DHCPv4 Leasequery protocol to add support
for queries that address these requirements. There may be many
thousands of DHCPv4 bindings per relay agent, so we specify the use
of TCP [4] for efficiency of data transfer. We specify a new query
type that uses the Relay Identifier sub-option to support efficient
recovery of all data associated with a specific relay agent. We also
specify query-type by Remote-ID sub-option value, to assist a relay
agent that needs to recover a subset of its clients' bindings.
Rao, et al. Expires January 2, 2009 [Page 3]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
DHCPv4 terminology is defined in [2]. DHCPv4 Leasequery terminology
is defined in [5]. DUID terminology is in defined in [7]. Relay
agent terminalogy is defined in [3].
Rao, et al. Expires January 2, 2009 [Page 4]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
3. Motivation
Consider a typical DSLAM working also as a DHCP relay agent (see
Figure 1). "Fast path" and "slow path" generally exist in most
networking boxes including DSLAMs. Fast path processing is done in
network processor or an ASIC (Application Specific Integrated
Circuit). Slow path processing is done in a normal processor. As
much as possible, regular data handling code should be in fast path.
Slow path processing should be reduced as it may become a bottleneck.
For a DSLAM having multiple DSL ports, multiple IP addresses may be
assigned using DHCP to a single port and the number of clients on a
port may be unknown. The DSLAM may also not know the network
portions of the IP addresses that are assigned to its DHCP clients.
The DSLAM gleans IP address or other information from DHCP
negotiations for antispoofing and for other purposes. The
antispoofing itself is done in fast path. DSLAM keeps track of only
one list of IP addresses: list of IP addresses that are assigned by
DHCP server. Traffic for all other IP addresses is dropped. If
client starts its data transfer after its DHCP negotiations are
gleaned by DSLAM, no legitimate packets will be dropped because of
antispoofing. In other words, antispoofing is effective (no
legitimate packets are dropped and all spoofed packets are dropped)
and efficient (antispoofing is done in fast path). The intention is
to achieve similar effective and efficient antispoofing in the lease
query scenario also when a DSLAM loses its gleaned information (for
example, because of reboot).
After a deep analysis, we found that the three existing query types
supported by RFC 4388 [5] do not provide effective and efficient
antispoofing for the above scenario and a new mechanism is required.
The existing query types
o necessitate a data driven approach: the lease queries can only be
done when the Access Concentrator receives data. That results in
increased outage time for clients.
o result in excessive negative caching consuming lot of resources
under a spoofing attack.
o result in antispoofing being done in slow path instead of fast
path.
The deeper analysis, which led to the above conclusions, itself
appears as an Appendix to this document.
Rao, et al. Expires January 2, 2009 [Page 5]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
4. Design Goals
The goal of this document is to provide a lightweight mechanism for
an Access Concentrator to retrieve lease information available in the
DHCP server. The mechanism should also support an Access
Concentrator to retrieve consolidated lease information for the
entire access concentrator or for a connection/circuit.
4.1. Information Acquisition before Data Starts
Existing data driven approach by RFC 4388 [5] means that the lease
queries can only be done when an Access Concentrator receives data.
For antispoofing, packets need to be dropped until it gets the lease
information from DHCP server. If an Access Concentrator finishes the
lease queries before it starts receiving data, then there is no need
to drop legitimate packets. So, effectively outage time may be
reduced.
4.2. Lessen Negative Caching
If lease queries result in negative caches, then that puts additional
overhead on the access concentrator. The negative caches not only
consume precious resources they also need to be managed. Hence they
should be avoided as much as possible. The lease queries should
reduce the need for negative caching as far as possible.
4.3. Antispoofing in 'Fast Path'
If Antispoofing is not done in fast path, it will become a bottleneck
and may lead to denial of service of the access concentrator. The
lease queries should make it possible to do antispoofing in fast
path.
Rao, et al. Expires January 2, 2009 [Page 6]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
5. Protocol Overview
The Bulk Leasequery mechanism is modeled on the existing individual
Leasequery protocol described in RFC 4388[5]; most differences arise
from the use of TCP. A Bulk Leasequery client opens a TCP connection
to a DHCPv4 Server, using the DHCPv4 port 67. Note that this implies
that the Leasequery client has server IP address(es) available via
configuration or some other means, and that it has unicast IP
reachability to the server. No relaying for bulk leasequery is
specified.
After establishing a connection, the client sends a DHCPLEASEQUERY
message containing a query-type and data about bindings it is
interested in. The server uses the query-type and the data to
identify any relevant bindings. In order to support some query-
types, servers may have to maintain additional data structures or be
able to locate bindings based on specific option data. The server
replies with a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE,
DHCPLEASEQUERYFAIL, or DHCPLEASEUNKNOWN. The reasons why a
DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message
might be generated are explained in [5] and below. The reasons why a
DHCPLEASEQUERYFAIL message might be generated are explained below.
If the query was successful, the server includes the first client's
binding data in a DHCPLEASEACTIVE message. If more than one client's
bindings are being returned, the server then transmits the additional
client bindings in a series of DHCPLEASEDATA messages. If the server
has sent at least one client's bindings, it sends a DHCPLEASEDONE
message when it has finished sending its replies. The client may
reuse the connection to send additional queries. Each end of the TCP
connection can be closed after all data has been sent.
The Relay-ID sub-option is defined in [6]. The sub-option contains a
DUID identifying a DHCPv4 relay agent. Relay agents can include this
sub-option while relaying messages to DHCPv4 servers. Servers can
retain the Relay-ID and associate it with bindings made on behalf of
the relay agent's clients. A relay agent can then recover binding
information about downstream clients by using the Relay-ID in a
DHCPLEASEQUERY message.
Bulk Leasequery supports the queries by IPv4 address, MAC address,
and Client Identifier as specified in RFC4388 [5]. The Bulk
Leasequery protocol also adds two new queries.
o Query by Relay Identifier
This query asks a server for the bindings associated with a specific
relay agent; the relay agent is identified by a DUID carried in a
Relay-ID sub-option.
Rao, et al. Expires January 2, 2009 [Page 7]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
o Query by Remote ID
This query asks a server for the bindings associated with a Relay
Agent Remote-ID sub-option [3] value.
Rao, et al. Expires January 2, 2009 [Page 8]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
6. Interaction Between UDP Leasequery and Bulk Leasequery
Bulk Leasequery can be seen as an extension of the existing UDP
Leasequery protocol [5]. This section tries to clarify the
relationship between the two protocols.
The query-types introduced in the UDP Leasequery protocol can be used
in the Bulk Leasequery protocol. One change in behavior is required
when Bulk Leasequery is used. RFC4388 [5], in sections 6.1, 6.4.1,
and 6.4.2 specifies the use of an associated-ip option in
DHCPLEASEACTIVE messages in cases where multiple bindings were found.
When Bulk Leasequery is used, this mechanism is not necessary: a
server returning multiple bindings simply does so directly as
specified in this document. The associated-ip option MUST NOT appear
in Bulk Leasequery replies.
Only DHCPLEASEQUERY, DHCPLEASEACTIVE, DHCPLEASEUNASSIGNED,
DHCPLEASEUNKNOWN, DHCPLEASEDATA, DHCPLEASEQUERYFAIL, and
DHCPLEASEDONE messages are allowed over the Bulk Leasequery
connection. No other DHCPv4 messages are supported. The Bulk
Leasequery connection is not an alternative DHCPv4 communication
option for clients seeking DHCPv4 service.
Rao, et al. Expires January 2, 2009 [Page 9]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
7. Message and Option Definitions
7.1. Message Framing for TCP
The use of TCP for the Bulk Leasequery protocol permits one or more
DHCPv4 messages to be sent at a time. The receiver needs to be able
to determine how large each message is. Four octets, out of which
the first two octets contain the message size in network byte-order,
are prepended to each DHCPv4 message sent on a Bulk Leasequery TCP
connection. The four octets 'frame' each DHCPv4 message.
DHCPv4 message framed for TCP:
Rao, et al. Expires January 2, 2009 [Page 10]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
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 | unused |
+---------------+---------------+---------------+---------------+
| op (1) | htype (1) | hlen (1) | hops (1) |
+---------------+---------------+---------------+---------------+
| xid (4) |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
+-------------------------------+-------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| yiaddr (4) |
+---------------------------------------------------------------+
| siaddr (4) |
+---------------------------------------------------------------+
| giaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
| |
| |
+---------------------------------------------------------------+
| |
| sname (64) |
+---------------------------------------------------------------+
| |
| file (128) |
+---------------------------------------------------------------+
| |
| options (variable) |
+---------------------------------------------------------------+
message-size the number of octets in the message that
follows (excluding the two unused bytes), as a
16-bit integer in network byte-order.
unused these 16 bits are unused; they should be set to
zero by sender and ignored by receiver.
All other fields are as specified in DHCPv4 [2].
7.2. Messages
The DHCPLEASEQUERY, DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN, and
DHCPLEASEACTIVE messages are defined in RFC4388 [5]. In a Bulk
Leasequery exchange, a single DHCPLEASEUNASSIGNED,
DHCPLEASEQUERYFAIL, or DHCPLEASEUNKNOWN message is used to indicate
Rao, et al. Expires January 2, 2009 [Page 11]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
the failure of a query. A single DHCPLEASEACTIVE message is used to
indicate the success of a query, and contains the first client's
binding data. It also carries data that do not change in the context
of a single query and answer, such as the Server Identifier (option
54) option.
7.2.1. DHCPLEASEDATA
The DHCPLEASEDATA message (message type TBD) carries data about a
single DHCPv4 client's leases and bindings. The purpose of the
message is to reduce redundant data when there are multiple bindings
to be sent. The DHCPLEASEDATA message MUST be preceded by a
DHCPLEASEACTIVE message. The DHCPLEASEACTIVE carries the
Leasequery's Server Identifier options, and carries the first
client's binding data if the query was successful.
DHCPLEASEDATA MUST ONLY be sent in response to a successful
DHCPLEASEQUERY, and only if more than one client's data is to be
sent. The DHCPLEASEDATA message's xid field MUST match the xid of
the DHCPLEASEQUERY request message. The Server Identifier option
SHOULD NOT be included: that data should be constant for any one Bulk
Leasequery reply, and should have been conveyed in the
DHCPLEASEACTIVE message.
7.2.2. DHCPLEASEDONE
The DHCPLEASEDONE message (message type TBD) indicates the end of a
group of related Leasequery replies. The DHCPLEASEDONE message's xid
field MUST match the xid of the DHCPLEASEQUERY request message. The
presence of the message itself signals the end of a stream of reply
messages. A single DHCPLEASEDONE MUST be sent after all replies (a
DHCPLEASEACTIVE and zero or more DHCPLEASEDATA messages) to a
successful Bulk Leasequery request that returned at least one
binding. Other DHCPv4 options SHOULD NOT be included in the
DHCPLEASEDONE message.
7.2.3. DHCPLEASEQUERYFAIL
A server may encounter an error condition while processing a
DHCPLEASEQUERY message but before it has sent any response. A server
may also encounter an error condition after it has sent the initial
DHCPLEASEACTIVE. In these cases, it SHOULD attempt to send a
DHCPLEASEQUERYFAIL (message type TBD) with STATUS_CODE option
indicating the error condition to the requestor. Other DHCPv4
options SHOULD NOT be included in the DHCPLEASEQUERYFAIL message.
Rao, et al. Expires January 2, 2009 [Page 12]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
7.3. Query Types
We introduce the following new query-types: QUERY_BY_RELAYID and
QUERY_BY_REMOTE_ID. These queries are designed to assist relay
agents in recovering binding data in circumstances where some or all
of the relay agent's binding data has been lost.
7.3.1. QUERY_BY_RELAYID
This query asks the server to return bindings associated with the
specified relay DUID. A relay agent MAY include the option in the
messages it relays. Obviously, it will not be possible for a server
to respond to QUERY_BY_RELAYID queries unless the relay agent has
included this option. A relay agent SHOULD be able to generate a
DUID for this purpose, and capture the result in stable storage. A
relay agent SHOULD also allow the DUID value to be configurable:
doing so allows an administrator to replace a relay agent while
retaining the association between the relay agent and existing DHCPv4
bindings.
A DHCPv4 Server MAY associate Relay-ID sub-options from relayed
messages it processes with lease bindings that result. Doing so
allows it to respond to QUERY_BY_RELAYID Leasequeries.
QUERY_BY_RELAYID message is formatted as follows:
o The requester supplies only an option 82 which will include only
an Agent Relay ID sub-option in the DHCPLEASEQUERY message. The
query options MUST contain a RELAYID sub-option.
o The "ciaddr" field MUST be set to zero.
o The values of htype, hlen, and chaddr MUST be set to zero.
o The Client-identifier option (option 61) MUST NOT appear in the
packet.
The DHCP server replies with a DHCPLEASEACTIVE message if the DHCP
server has one or multiple active leases which were assigned through
the Relay Agent identified by Relay ID in the DHCPLEASEQUERY message.
If the Server has recorded Relay-ID values with its bindings, it uses
the sub-option's value to identify bindings to return. Server
replies with a DHCPLEASEUNASSIGNED if it has information of the said
relay ID but no lease is associated with the same. Server replies
with a DHCPLEASEUNKNOWN message if it has no information of the said
relay ID.
Rao, et al. Expires January 2, 2009 [Page 13]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
7.3.2. QUERY_BY_REMOTE_ID
The QUERY_BY_REMOTE_ID is used to ask the server to return bindings
associated with a Remote-ID sub-option value from a relayed message.
QUERY_BY_REMOTE_ID for TCP defined in this draft is consistent with
QUERY_BY_REMOTE_ID for UDP defined in [9].
In order to support this query, a server needs to record the most-
recent Remote-ID sub-option value seen in a relayed message along
with its other binding data.
QUERY_BY_REMOTE_ID message is formatted as follows:
o There MUST be only a Relay Agent Information option (option 82)
with only Agent Remote ID sub-option (sub-option 2) in the
DHCPLEASEQUERY message.
o The "ciaddr" field MUST be set to zero.
o The values of htype, hlen, and chaddr MUST be set to zero.
o The Client-identifier option (option 61) MUST NOT appear in the
packet.
The DHCP server replies with a DHCPLEASEACTIVE message if the Agent
Remote ID in the DHCPLEASEQUERY message currently has an active lease
on an IP address in this DHCP server. Server replies with a
DHCPLEASEUNASSIGNED if it has information of the said remote ID but
no lease is associated with the same. Server replies with a
DHCPLEASEUNKNOWN message if it has no information of the said remote
ID. If the Server has recorded Remote-ID values with its bindings,
it uses the sub-option's value to identify bindings to return.
7.4. Options
7.4.1. STATUS-CODE option
This option returns a status indication related to the DHCP message.
Currently it is used along with DHCPLEASEQUERYFAIL message.
The format of the Status Code option is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rao, et al. Expires January 2, 2009 [Page 14]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
| status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. status-message .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code STATUS_CODE (TBD).
option-len 2 + length of status-message.
status-code The numeric code for the status encoded in
this option. The status codes are defined below.
status-message A UTF-8 encoded text string suitable for
display to an end user, which MUST NOT be
null-terminated.
A Status Code option may appear in the options field of a DHCP
message. If the Status Code option does not appear in a message
in which the option could appear, the status of the message is
assumed to be Success.
The following status codes are defined:
Name Code Description
---------- ---- -----------
Success 0 Success.
UnspecFail 1 Failure, reason unspecified; this
status code is sent by either a client
or a server to indicate a failure
not explicitly specified in this
document.
UnknownQueryType 2 The query-type is unknown to or not supported
by the server.
MalformedQuery 3 The query is not valid; for example, a
required query option is missing.
NotAllowed 4 The server does not allow the requestor to
issue this DHCPLEASEQUERY
QueryTerminated 5 Indicates that the server is unable to perform
a query or has prematurely terminated the query
for some reason (which should be communicated
in the text message). This may be because the
server is short of resources or is being shut
down. The requestor may retry the query at a
later time. The requestor should wait at least
a short interval before retrying. Note that
while a server may simply prematurely close
Rao, et al. Expires January 2, 2009 [Page 15]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
its end of the connection, it is preferable
for the server to send a DHCPLEASEQUERYFAIL
with this status-code to notify the requestor
of the condition.
7.5. Connection and Transmission Parameters
DHCPv4 Servers that support Bulk Leasequery SHOULD listen for
incoming TCP connections on the DHCPv4 server port 67.
Implementations MAY offer to make the incoming port configurable, but
port 67 MUST be the default. Client implementations SHOULD make TCP
connections to port 67, and MAY offer to make the destination server
port configurable.
This section presents a table of values used to control Bulk
Leasequery behavior, including recommended defaults. Implementations
MAY make these values configurable.
Parameter Default Description
------------------------------------------------------------------
BULK_LQ_CONN_TIMEOUT 30 secs Bulk Leasequery connection timeout
BULK_LQ_DATA_TIMEOUT 30 secs Bulk Leasequery data timeout
BULK_LQ_MAX_RETRY 60 secs Max Bulk Leasequery retry timeout
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
Rao, et al. Expires January 2, 2009 [Page 16]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
8. Requestor Behavior
8.1. Connecting
A Requestor attempts to establish a TCP connection to a DHCPv4 Server
in order to initiate a Leasequery exchange. The Requestor SHOULD be
prepared to abandon the connection attempt after
BULK_LQ_CONN_TIMEOUT. If the attempt fails, the Requestor MAY retry.
Retries MUST use an exponential backoff timer, increasing the
interval between attempts up to BULK_LQ_MAX_RETRY.
8.2. Forming Queries
After a connection is established, the Requestor constructs a
Leasequery message, as specified in [5]. The query may have any of
the defined query-types, and includes the options and data required
by the query-type chosen. The Requestor sends the message size, 16
reserved bits (zeroes), and then sends the actual DHCPv4 message, as
described in Section 7.1.
If the TCP connection becomes blocked while the Requestor is sending
its query, the Requestor SHOULD be prepared to terminate the
connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation
to allow Requestors to control the period of time they are willing to
wait before abandoning a connection, independent of notifications
from the TCP implementations they may be using.
8.3. Processing Replies
The Requestor attempts to read a DHCPLEASEACTIVE, DHCPLEASEUNKNOWN,
DHCPLEASEQUERYFAIL, or DHCPLEASEUNASSIGNED message from the TCP
connection. If the stream of replies becomes blocked, the Requestor
SHOULD be prepared to terminate the connection after
BULK_LQ_DATA_TIMEOUT, and MAY begin retry processing if configured to
do so.
The Requestor examines the DHCPLEASEACTIVE, DHCPLEASEUNKNOWN,
DHCPLEASEQUERYFAIL, or DHCPLEASEUNASSIGNED message, and determines
how to proceed. If the xid in the received message does not match an
outstanding DHCPLEASEQUERY message, the client MUST close the TCP
connection. Message processing rules for DHCPLEASEACTIVE are
specified in DHCPv4 Leasequery [5]. DHCPLEASEUNKNOWN and
DHCPLEASEUNASSIGNED replies indicate that the target server had no
bindings matching the query. DHCPLEASEQUERYFAIL indicates that the
server failed to serve the client. More details will be available in
the received STATUS_CODE option.
The Leasequery protocol [5] uses the associated-ip option as an
Rao, et al. Expires January 2, 2009 [Page 17]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
indicator that multiple bindings were present in response to a single
query. For Bulk Leasequery, the associated-ip option is not used,
and MUST NOT be present in replies.
A successful DHCPLEASEACTIVE that is returning binding data is
created as specified in [5]. If there are additional bindings to be
returned, they will be carried in DHCPLEASEDATA messages. Each
DHCPLEASEDATA message returns binding data and is prepared just like
the DHCPLEASEACTIVE message described in [5] except for the new
message type.
A single bulk query can result in a large number of replies. For
example, a single relay agent might be responsible for thousands of
DHCP clients. The Requestor MUST be prepared to receive more than
one DHCPLEASEDATA with xids matching a single DHCPLEASEQUERY message.
The DHCPLEASEDONE message ends a successful Bulk Leasequery request
that returned at least one binding. DHCPLEASEUNKNOWN and
DHCPLEASEUNASSIGNED MUST NOT be followed by a DHCPLEASEDONE message
for the same xid. After receiving DHCPLEASEDONE from a server, the
Requestor MAY close the TCP connection to that server. If the xid in
the DHCPLEASEDONE does not match an outstanding DHCPLEASEQUERY
message, the client MUST close the TCP connection.
The DHCPLEASEQUERYFAIL message ends a Bulk Leasequery request in
failure. Depending on the status code, the requestor may try a
different server (such as for NotAllowed and UnknownQueryType), try a
different or corrected query (such as for UnknownQueryType and
MalformedQuery), or terminate the query. If the xid in the
DHCPLEASEQUERYFAIL does not match an outstanding DHCPLEASEQUERY
message, the client MUST close the TCP connection.
8.4. Leasequery Request Completion Criteria
This section provides rules for when a DHCPLEASEQUERY request is
complete.
A DHCPLEASEQUERY request is complete for a requestor (i.e., no
further messages for that request will be received):
o If it receives a DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN,
DHCPLEASEDONE, or DHCPLEASEQUERYFAIL message.
o If the connection is closed.
Rao, et al. Expires January 2, 2009 [Page 18]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
8.5. Querying Multiple Servers
A Bulk Leasequery client MAY be configured to attempt to connect to
and query from multiple DHCPv4 servers in parallel. Binding data
received from multiple DHCPv4 servers may need to be reconciled.
The client data from the different servers may be disjoint or
overlapping.
When using the DHCPLEASEQUERY message in an environment where
multiple DHCP servers may contain authoritative information about the
same IP address (such as when two DHCP servers are cooperating to
provide a high-availability DHCP service), multiple, possibly
conflicting, responses might be received.
In this case, some information in the response packet SHOULD be used
to decide among the various responses. The client-last-transaction-
time (if it is available) can be used to decide which server has more
recent information concerning the IP address returned in the "ciaddr"
field.
If the requestor receives disjoint client data from different
sources, it SHOULD merge them.
8.6. Multiple Queries to a Single Server
Bulk Leasequery clients may need to make multiple queries in order to
recover binding information. A Requestor MAY use a single connection
to issue multiple queries. Each query MUST have a unique xid. A
server MAY process more than one query at a time. A server that is
willing to do so MAY interleave replies to the multiple queries
within the stream of reply messages it sends. Clients need to be
aware that replies for multiple queries may be interleaved within the
stream of reply messages. Clients that are not able to process
interleaved replies (based on xid) MUST NOT send more than one query
at a time. Requestors should be aware that servers are not required
to process queries in parallel, and that servers are likely to limit
the rate at which they process queries from any one Requestor.
8.6.1. Example
This example illustrates what a series of queries and responses might
look like. This is only an example - there is no requirement that
this sequence must be followed, or that clients or servers must
support parallel queries.
In the example session, the client sends four queries after
establishing a connection. Query 1 results in a failure; query 2
Rao, et al. Expires January 2, 2009 [Page 19]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
succeeds and the stream of replies concludes before the client issues
any new query. Query 3 and query 4 overlap, and the server
interleaves its replies to those two queries.
Client Server
------ ------
DHCPLEASEQUERY xid 1 ----->
<----- DHCPLEASEUNKNOWN xid 1
DHCPLEASEQUERY xid 2 ----->
<----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEDATA xid 2
<----- DHCPLEASEDATA xid 2
<----- DHCPLEASEDONE xid 2
DHCPLEASEQUERY xid 3 ----->
DHCPLEASEQUERY xid 4 ----->
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEDATA xid 4
<----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEDATA xid 4
<----- DHCPLEASEDATA xid 3
<----- DHCPLEASEDONE xid 3
<----- DHCPLEASEDATA xid 4
<----- DHCPLEASEDONE xid 4
8.7. Closing Connections
The Requestor MAY close its end of the TCP connection after sending a
DHCPLEASEQUERY message to the server. The Requestor MAY choose to
retain the connection if it intends to issue additional queries.
Note that this client behavior does not guarantee that the connection
will be available for additional queries: the server might decide to
close the connection based on its own configuration.
Rao, et al. Expires January 2, 2009 [Page 20]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
9. Server Behavior
9.1. Accepting Connections
Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP
connections. Port numbers are discussed in Section 7.5. Servers
MUST be able to limit the number of currently accepted and active
connections. The value BULK_LQ_MAX_CONNS MUST be the default;
implementations MAY permit the value to be configurable.
Servers MAY restrict Bulk Leasequery connections and DHCPLEASEQUERY
messages to certain clients. Connections not from permitted clients
SHOULD be closed immediately, to avoid server connection resource
exhaustion. Servers MAY restrict some clients to certain query
types. Servers MAY reply to queries that are not permitted with the
DHCPLEASEQUERYFAIL message with the NotAllowed status code, or MAY
close the connection.
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 after BULK_LQ_DATA_TIMEOUT. We make this recommendation
to allow Servers to control the period of time they are willing to
wait before abandoning an inactive connection, independent of the TCP
implementations they may be using.
9.2. Forming Replies
The DHCPv4 Leasequery [5] specification describes the initial
construction of DHCPLEASEACTIVE, DHCPLEASEUNKNOWN, and
DHCPLEASEUNASSIGNED messages and the processing of
QUERY_BY_IP_ADDRESS, QUERY_BY_MAC_ADDRESS, and
QUERY_BY_CLIENTIDENTIFIER. Use of the DHCPLEASEACTIVE and
DHCPLEASEDATA messages to carry multiple bindings are described in
Section 7.2. Message transmission and framing for TCP is described
in Section 7.1. If the connection becomes blocked while the server
is attempting to send reply messages, the server SHOULD be prepared
to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT.
If the server encounters an error during initial query processing,
before any reply has been sent, it SHOULD send a DHCPLEASEQUERYFAIL
containing an appropriate STATUS_CODE option. This signals to the
requestor that no data will be returned. If the server encounters an
error while processing a query that has already resulted in one or
more reply messages, the server SHOULD send a DHCPLEASEQUERYFAIL
containing an appropriate STATUS_CODE option. The server SHOULD
close its end of the connection as an indication that it was not able
to complete query processing.
Rao, et al. Expires January 2, 2009 [Page 21]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
If the server does not recognize the identifier (relay id or remote
id) in a query, it SHOULD send a DHCPLEASEUNKNOWN. If the server
recognizes the identifier in a query but does not find any bindings
satisfying a query, it SHOULD send a DHCPLEASEUNASSIGNED. Otherwise,
the server sends each binding's data in a reply message. The first
reply message is a DHCPLEASEACTIVE. The binding data is carried as
specified in [5] and extended below. The server returns subsequent
bindings in DHCPLEASEDATA messages.
For QUERY_BY_RELAYID, the server locates each binding associated with
the query's Relay-ID sub-option value. In order to give a meaningful
reply to a QUERY_BY_RELAYID, the server has to be able to maintain
this association in its DHCPv4 binding data.
For QUERY_BY_REMOTE_ID, the server locates each binding associated
with the query's Relay Remote-ID sub-option value. In order to be
able to give meaningful replies to this query, the server has to be
able to maintain this association in its binding database.
The server sends the DHCPLEASEDONE message as specified in Section
7.2.
9.3. Multiple or Parallel Queries
As discussed in Section 6.5, Requestors may want to leverage an
existing connection if they need to make multiple queries. Servers
MAY support reading and processing multiple queries from a single
connection. A server MUST NOT read more query messages from a
connection than it is prepared to process simultaneously.
This MAY be a feature that is administratively controlled. Servers
that are able to process queries in parallel SHOULD offer
configuration that limits the number of simultaneous queries
permitted from any one Requestor, in order to control resource use if
there are multiple Requestors seeking service.
9.4. Closing Connections
The server MAY close its end of the TCP connection after sending its
last message (a DHCPLEASEUNASSIGNED, a DHCPLEASEUNKNOWN,
DHCPLEASEQUERYFAIL, or a DHCPLEASEDONE) in response to a query.
Alternatively, the server MAY retain the connection and wait for
additional queries from the client. The server SHOULD be prepared to
limit the number of connections it maintains, and SHOULD be prepared
to close idle connections to enforce the limit.
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
Rao, et al. Expires January 2, 2009 [Page 22]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
end of the TCP connection if it finds that it has to abort an in-
process request. A server aborting an in-process request MAY attempt
to signal that to its clients by using the DHCPLEASEQUERYFAIL message
type (Section 7.2.3). If the server detects that the client end has
been closed, the server MUST close its end of the connection after it
has finished processing any outstanding requests from the client.
Rao, et al. Expires January 2, 2009 [Page 23]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
10. Security Considerations
The "Security Considerations" section of [2] details the general
threats to DHCPv4. The DHCPv4 Leasequery specification [5] describes
recommendations for the Leasequery protocol, especially with regard
to DHCPLEASEQUERY messages, mitigation of packet-flooding DOS
attacks, and restriction to trusted clients.
The use of TCP introduces some additional concerns. Attacks that
attempt to exhaust the DHCPv4 server's available TCP connection
resources, such as SYN flooding attacks, can compromise the ability
of legitimate clients to receive service. Malicious clients who
succeed in establishing connections, but who then send invalid
queries, partial queries, or no queries at all also can exhaust a
server's pool of available connections. We recommend that servers
offer configuration to limit the sources of incoming connections,
that they limit the number of accepted connections and the number of
in-process queries from any one connection, and that they limit the
period of time during which an idle connection will be left open.
Rao, et al. Expires January 2, 2009 [Page 24]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
11. IANA Considerations
IANA is requested to assign a new DHCPv4 Option Code in the registry
maintained in http://www.iana.org/assignments/bootp-dhcp-parameters:
o STATUS_CODE
IANA is requested to assign the following values for the STATUS_CODE
option maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters:
Success 0
UnspecFail 1
UnknownQueryType 2
MalformedQuery 3
NotAllowed 4
QueryTerminated 5
IANA is requested to assign values for the following new DHCPv4
Message types in the Message Type option (option 53) in the registry
maintained in http://www.iana.org/assignments/bootp-dhcp-parameters:
o DHCPLEASEDONE
o DHCPLEASEDATA
o DHCPLEASEQUERYFAIL
Rao, et al. Expires January 2, 2009 [Page 25]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
12. Acknowledgments
The bulk lease query protocol for DHCPv4 described in this draft is
inspired by the bulk lease query protocol defined for DHCPv6 [8] by
Mark Stapp and liberally borrows from that draft. We also use the
protocol mechanisms proposed in RFC 4388 [5] by R. Woundy and K.
Kinnear.
Rao, et al. Expires January 2, 2009 [Page 26]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
13. References
13.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[4] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for
Transmission Control Protocol (TCP) Specification Documents",
RFC 4614, September 2006.
[5] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol
(DHCP) Leasequery", RFC 4388, February 2006.
[6] Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption",
IETF draft, June 2008.
[7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 31315, July 2003.
13.2. Informative Reference
[8] Stapp, M., "DHCPv6 Bulk Leasequery", IETF draft, June 2008.
[9] Kurapati, P., Desetti, R., and B. Joshi, "DHCPv4 Leasequery by
relay agent remote ID", IETF draft, June 2008.
Rao, et al. Expires January 2, 2009 [Page 27]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
1. Why a New Leasequery is Required?
The three existing query types supported by RFC 4388 [5] do not
provide effective and efficient antispoofing for the above scenario.
o Query by Client Identifier
Query by Client Identifier is not possible because to use that DSLAM
need to glean client identifier also but the whole issue is that we
need leasequeries because the gleaned information was lost. On the
other hand, we can query by client identifier when client sends a
DHCP request, but then there may not be any need for lease query as
such -- regular gleaning may be enough.
o Query by IP Address
RFC 4388 [5] suggests that it is preferable to use Query by IP
Address when getting downstream traffic.
Query by IP address is not very useful in downstream traffic because
downstream traffic may not exist for the clients on a DSL port. (In
most Internet applications, downstream traffic exists only when a
client sends upstream traffic). In other words, the client will be
denied service until it gets downstream traffic, which may never
come.
Query by IP address may be used for upstream traffic. Then whenever
an upstream packet comes whose IP address is unknown to the DSLAM, a
lease query may be initiated. A related question is what to do with
that upstream traffic itself until lease query response comes? If
the traffic is dropped, we may be dropping legitimate traffic. If
the traffic is forwarded, we may be forwarding spoofed packets. Once
the lease response comes, subsequent traffic is handled depending on
the response. If a DHCPLEASEACTIVE response comes, DSLAM will accept
the traffic. If a DHCPLEASEUNASSIGNED response comes, DSLAM will
drop the traffic corresponding to the IP address. If a
DHCPLEASEUNKNOWN response comes DSLAM may drop the traffic
corresponding to the IP address but will have to periodically send
the lease query for that IP address again (additional overhead). The
process is triggered whenever an unknown IP address comes.
Note that DSLAM needs to keep track of 4 lists of IP addresses: (1)
List of IP addresses for which it got DHCPLEASEACTIVE responses; (2)
List of IP addresses for which it got DHCPLEASEUNASSIGNED responses;
(3) List of IP addresses for which it got DHCPLEASEUNKNOWN responses;
(4) All other IP addresses.
This approach may be acceptable if only legitimate traffic is
Rao, et al. Expires January 2, 2009 [Page 28]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
received. Consider the case when someone sends packets that uses
spoofed IP addresses. In that case, lease response will be
DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN. RFC 4388 [5] suggests usage
of negative caching in this regard (which involves additional
resources).
In a spoofing type of attack, negative caching information may grow
considerably if attacker varies the source IP address. For each such
new source IP address, traffic will come to slow path, a new lease
query needs to be initiated, response will be processed, and negative
caching to be done. That will mean using many resources for negative
caching.
RFC 4388 [5] suggests that if the DSLAM knows the network portion of
the IP addresses that are assigned to its clients, then some amount
of antispoofing can be done in fast path and some lease queries may
be avoided. But as indicated before, that information may not always
be available to DSLAMs.
Effectively, antispoofing support involves considerable slow path
processing and considerable resources tied for negative caching.
RFC 4388 [5] says that DHCP server should be protected from being
flooded with too many leasequery requests and DSLAM also should not
send too many lease query messages at a time. This would mean that
legitimate clients may be excessively delayed getting their
information in the face of antispoofing attacks.
It is concluded that antispoofing is neither effective nor efficient
with this query type.
o Query by MAC Address
Query by MAC address can also be used similar to query by IP address
described above. Indeed, query by MAC address may be better than
query by IP address in one sense because of the possible presence of
associated-ip option in lease responses (Note that associated-ip
option does not appear in responses for query by IP address). With
associated-ip option DSLAM can get information not only about the IP
address/MAC address that triggered the lease query but also about
other IP addresses that are associated with the original MAC address.
That way, when traffic that uses the other IP addresses comes along,
DSLAM is already prepared to deal with them.
Although, query by MAC address is better than query by IP address in
the above respect, it has a specific problem which is not shared by
query by IP address. For a query by MAC address, only two types of
responses are possible: DHCPLEASEUNKNOWN and DHCPLEASEACTIVE;
Rao, et al. Expires January 2, 2009 [Page 29]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
DHCPLEASEUNASSIGNED is not supported. This is particularly
troublesome when a DHCP server indeed has definitive information that
no IP addresses are associated with the specified MAC address in the
leasequery, but it is forced to respond with DHCPLEASEUNKNOWN instead
of DHCPLEASEUNASSIGNED. As we have seen above, unlike
DHCPLEASEUNASSIGNED, DHCPLEASEUNKNOWN requires periodic querying with
DHCP server, an additional overhead.
Moreover, query by MAC address also shares all other issues we
discussed above for query by IP address.
We conclude that existing lease query types are not appropriate to
achieve effective and efficient antispoofing.
Rao, et al. Expires January 2, 2009 [Page 30]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
Authors' Addresses
Ramakrishna Rao D. T. V.
Infosys Technologies Ltd.
44 Electronics City, Hosur Road
Bangalore 560 100
India
Email: RAMAKRISHNADTV@infosys.com
URI: http://www.infosys.com/
Bharat joshi
Infosys Technologies Ltd.
44 Electronics City, Hosur Road
Bangalore 560 100
India
Email: bharat_joshi@infosys.com
URI: http://www.infosys.com/
Pavan Kurapati
Infosys Technologies Ltd.
44 Electronics City, Hosur Road
Bangalore 560 100
India
Email: pavan_kurapati@infosys.com
URI: http://www.infosys.com/
Rao, et al. Expires January 2, 2009 [Page 31]
Internet-Draft DHCPv4 Bulk Leasequery July 2008
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rao, et al. Expires January 2, 2009 [Page 32]