draft-ietf-dhc-dhcpv4-bulk-leasequery-05.txt   draft-ietf-dhc-dhcpv4-bulk-leasequery-06.txt 
DHC Working Group Kim Kinnear DHC Working Group Kim Kinnear
Internet Draft Bernie Volz Internet Draft Mark Stapp
Intended Status: Standards Track Mark Stapp Intended Status: Standards Track Cisco Systems, Inc.
Expires: May 18, 2012 Cisco Systems, Inc. Expires: September 12, 2012 D. Rao
D. Rao
B. Joshi B. Joshi
Infosys Technologies Ltd. Infosys Technologies Ltd.
Neil Russell Neil Russell
Nokia BMC Software, Inc.
P. Kurapati March 12, 2012
Juniper Networks Ltd.
November 18, 2011
Bulk DHCPv4 Lease Query Bulk DHCPv4 Lease Query
<draft-ietf-dhc-dhcpv4-bulk-leasequery-05.txt> <draft-ietf-dhc-dhcpv4-bulk-leasequery-06.txt>
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 39
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 27 skipping to change at page 2, line 24
Leasequery protocol to allow for bulk transfer of DHCPv4 address Leasequery protocol to allow for bulk transfer of DHCPv4 address
binding data via TCP. binding data via TCP.
Table of Contents Table of Contents
1. Introduction................................................. 3 1. Introduction................................................. 3
2. Terminology.................................................. 4 2. Terminology.................................................. 4
3. Design Goals................................................. 7 3. Design Goals................................................. 7
3.1. Information Acquisition before Data Starts................. 7 3.1. Information Acquisition before Data Starts................. 7
3.2. Lessen need for Caching and Negative Caching............... 7 3.2. Lessen need for Caching and Negative Caching............... 7
3.3. Antispoofing in 'Fast Path'................................ 7 3.3. Antispoofing in 'Fast Path'................................ 8
3.4. Minimize data transmission................................. 7 3.4. Minimize data transmission................................. 8
4. Protocol Overview............................................ 8 4. Protocol Overview............................................ 8
5. Interaction Between UDP Leasequery and Bulk Leasequery....... 9 5. Interaction Between UDP Leasequery and Bulk Leasequery....... 10
6. Message and Option Definitions............................... 10 6. Message and Option Definitions............................... 10
6.1. Message Framing for TCP.................................... 10 6.1. Message Framing for TCP.................................... 10
6.2. New or Changed Options..................................... 11 6.2. New or Changed Options..................................... 11
6.3. Connection and Transmission Parameters..................... 19 6.3. Connection and Transmission Parameters..................... 19
7. Requestor Behavior........................................... 19 7. Requestor Behavior........................................... 19
7.1. Connecting and General Processing.......................... 19 7.1. Connecting and General Processing.......................... 19
7.2. Forming a Bulk Leasequery.................................. 20 7.2. Forming a Bulk Leasequery.................................. 20
7.3. Processing Bulk Replies.................................... 22 7.3. Processing Bulk Replies.................................... 22
7.4. Processing Time Values in Leasequery messages.............. 24 7.4. Processing Time Values in Leasequery messages.............. 24
7.5. Querying Multiple Servers.................................. 25 7.5. Querying Multiple Servers.................................. 25
skipping to change at page 3, line 12 skipping to change at page 3, line 12
7.7. Multiple Queries to a Single Server over One Connection.... 26 7.7. Multiple Queries to a Single Server over One Connection.... 26
7.8. Closing Connections........................................ 27 7.8. Closing Connections........................................ 27
8. Server Behavior.............................................. 27 8. Server Behavior.............................................. 27
8.1. Accepting Connections...................................... 27 8.1. Accepting Connections...................................... 27
8.2. Replying to a Bulk Leasequery.............................. 28 8.2. Replying to a Bulk Leasequery.............................. 28
8.3. Building a Single Reply for Bulk Leasequery................ 31 8.3. Building a Single Reply for Bulk Leasequery................ 31
8.4. Multiple or Parallel Queries............................... 32 8.4. Multiple or Parallel Queries............................... 32
8.5. Closing Connections........................................ 33 8.5. Closing Connections........................................ 33
9. Security Considerations...................................... 33 9. Security Considerations...................................... 33
10. IANA Considerations......................................... 34 10. IANA Considerations......................................... 34
11. Acknowledgements............................................ 36 11. Contributing Authors........................................ 36
12. References.................................................. 36 12. Acknowledgements............................................ 37
12.1. Normative References...................................... 36 13. References.................................................. 37
12.2. Informative References.................................... 37 13.1. Normative References...................................... 37
13.2. Informative References.................................... 38
1. Introduction 1. Introduction
The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the
assignment of IPv4 address and configuration information to IPv4 assignment of IPv4 address and configuration information to IPv4
nodes. DHCPv4 servers maintain authoritative binding information. nodes. DHCPv4 servers maintain authoritative binding information.
+--------+ +--------+
| DHCPv4 | +--------------+ | DHCPv4 | +--------------+
| Server |-...-| DSLAM | | Server |-...-| DSLAM |
skipping to change at page 7, line 31 skipping to change at page 7, line 31
address binding information available in the DHCPv4 server. The address binding information available in the DHCPv4 server. The
mechanism should also allow an Access Concentrator to retrieve mechanism should also allow an Access Concentrator to retrieve
consolidated IP address binding information for either the entire consolidated IP address binding information for either the entire
access concentrator or a single connection/circuit. access concentrator or a single connection/circuit.
3.1. Information Acquisition before Data Starts 3.1. Information Acquisition before Data Starts
The existing data driven approach required by [RFC4388] means that The existing data driven approach required by [RFC4388] means that
the Leasequeries can only be performed after an Access Concentrator the Leasequeries can only be performed after an Access Concentrator
receives data. To implement antispoofing, the concentrator must drop receives data. To implement antispoofing, the concentrator must drop
packets for each client until it gets lease information from 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 the
Leasequeries before it starts receiving data, then there is no need Leasequeries before it starts receiving data, then there is no need
to drop legitimate packets. In this way, outage time may be reduced. to drop legitimate 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
skipping to change at page 8, line 46 skipping to change at page 8, line 46
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 packets 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 which is controlled by the DHCPv4 server but
which is not actively leased by a DHCPv4 client at the present time. which is not actively leased by a DHCPv4 client at the present time.
The Bulk Leasequery mechanism is designed to provide an external The Bulk Leasequery mechanism 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
skipping to change at page 17, line 19 skipping to change at page 17, line 19
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. In certain state always following a particular previous state. In
general, every state can (at times) follow every other state. general, every state can (at 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 is data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It
used when there are two or more servers who might have information SHOULD be used when there are two or more servers who might have
about a particular IP address binding. Frequently two servers work information about a particular IP address binding. Frequently two
together to provide an increased availability solution for the DHCPv4 servers work together to provide an increased availability solution
service, and in these cases, both servers will respond to Bulk for the DHCPv4 service, and in these cases, both servers will respond
Leasequery requests for the same IP address. to Bulk Leasequery requests for the same IP address. When one server
is working with another server and both may respond with information
about the same IP address, each server SHOULD return the data-source
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 TBD7. The length of this option is 1
octet. octet.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
skipping to change at page 34, line 7 skipping to change at page 34, line 7
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 also can exhaust a
server's pool of available connections. We recommend that servers server's pool of available connections. We recommend that servers
offer configuration to limit the sources of incoming connections, offer configuration to limit the sources of incoming connections,
that they limit the number of accepted connections and the number of that they limit the number of accepted connections and the number of
in-process queries from any one connection, and that they limit the in-process queries from any one connection, and that they limit the
period of time during which an idle connection will be left open. period of time during which an idle connection will be left open.
[RFC4388] discusses security concerns and potential solutions for There are two specific issues regarding Bulk Leasequery security that
DHCPLEASEQUERY message exchanges in its Section 7, and all of the deserve explicit mention. The first is preventing information that
solutions discussed there are applicable to the DHCPLEASEQUERY Bulk Leasequery can provide from reaching clients who are not
message exchanges described in this document. authorized to receive such information. The second is ensuring that
authorized clients of the Bulk Leasequery capability receive accurate
information from the Server (and that this information is not
disrupted in transit).
To prevent information leakage to unauthorized clients Servers SHOULD
restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages
to certain requestors, either through explicit configuration of the
Server itself or by employing external network elements to provide
such restrictions. In particular, the typical DHCPv4 client SHOULD
NOT be allowed to receive a response to a Bulk Leasequery request,
and some technique MUST exist to allow prevention of such access in
any environment where Bulk Leasequery is deployed.
Connections not from permitted requestors SHOULD be closed
immediately, to avoid server connection resource exhaustion or
alternatively, simply not be allowed to reach the server at all.
Servers SHOULD have the capability to restrict certain requestors to
certain query types. Servers MAY reply to queries that are not
permitted with the DHCPLEASEQUERYDONE message with a status-code
option status of NotAllowed, or MAY simply close the connection.
To prevent disruption and malicious corruption of Bulk Leasequery
data flows between the server and authorized clients these data flows
SHOULD transit only secured networks. These data flows are
typically infrastructure oriented, and there is usually no reason to
have them flowing over networks where such attacks are likely. In
the rare cases where these data flows might need to be sent through
unsecured networks, they MUST sent over connections secured through
means external to the DHCPv4/DHCPv6 server and its client(s) (e.g.,
through VPN's).
Authentication for DHCP Messages [RFC3118] MUST NOT be used to
attempt to secure transmission of the messages described in this
document. In particular, the message framing would not be protected
by using the mechanisms described in [RFC3118] (which was designed
only with UDP transport in mind).
10. IANA Considerations 10. IANA Considerations
IANA is requested to assign the following new DHCPv4 option codes IANA is requested to assign the following new DHCPv4 option codes
from the registry "BOOTP Vendor Extensions and DHCP Options" from the registry "BOOTP Vendor Extensions and DHCP Options"
maintained at http://www.iana.org/assignments/bootp-dhcp-parameters maintained at http://www.iana.org/assignments/bootp-dhcp-parameters
1. An option code of TBD1 for status-code. 1. An option code of TBD1 for status-code.
2. An option code of TBD2 for base-time. 2. An option code of TBD2 for base-time.
skipping to change at page 36, line 14 skipping to change at page 36, line 33
Type VSS Information format: Type VSS Information format:
0 UTF-8 ASCII VPN identifier 0 UTF-8 ASCII VPN identifier
1 RFC2685 VPN-ID 1 RFC2685 VPN-ID
2-253 Not Allowed 2-253 Not Allowed
254 All VPN's. (wildcard; only allowed in 254 All VPN's. (wildcard; only allowed in
DHCPBULKLEASEQUERY messages) DHCPBULKLEASEQUERY messages)
255 Global, default VPN. 255 Global, default VPN.
11. Acknowledgements 11. 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
12. Acknowledgements
This draft is a collaboration between the authors of draft-dtv-dhc- This draft is a collaboration between the authors of draft-dtv-dhc-
dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk- dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk-
leasequery-00.txt. Both documents acknowledged that significant text leasequery-00.txt. Both documents acknowledged that significant text
as well as important ideas were borrowed in whole or in part from the as well as important ideas were borrowed in whole or in part from the
DHCPv6 Bulk Leasequery RFC, [RFC5460] written by Mark Stapp. Further DHCPv6 Bulk Leasequery RFC, [RFC5460] written by Mark Stapp. Further
suggestions and improvements were made by participants in the DHC suggestions and improvements were made by participants in the DHC
working group, including Alfred Hoenes. working group, including Alfred Hoenes.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
[RFC3118] Droms, R. "Authentication for DHCP Messages", RFC 3118,
June 2001.
[RFC4388] Woundy, R., K. Kinnear, "Dynamic Host Configuration [RFC4388] Woundy, R., K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC 4388, February 2006. Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RelayId] Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption", [RelayId] Joshi, B., Rao, D. and M. Stapp, "The DHCPv4 Relay Agent
draft-ietf-dhc-relay-id-suboption-09.txt, (work in progress) June Identifier Suboption", draft-ietf-dhc-relay-id-suboption-10.txt,
2011. (work in progress) January 2012.
[VpnId] Kinnear, K., R. Johnson, M. Stapp and J. Kumarasamy, "Virtual [VpnId] Kinnear, K., R. Johnson, M. Stapp and J. Kumarasamy, "Virtual
Subnet Selection Options for DHCPv4 and DHCPv6" draft-ietf-dhc- Subnet Selection Options for DHCPv4 and DHCPv6" draft-ietf-dhc-
vpn-option-14.txt, (work in progress) November 2011. vpn-option-15.txt, (work in progress) January 2012.
12.2. Informative References 13.2. Informative References
[RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC [RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC
951, September 1985. 951, September 1985.
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, October 1993. Protocol", RFC 1542, October 1993.
[RFC4614] Duke, M., R. Braden, W. Eddy, and E. Blanton, "A Roadmap [RFC4614] Duke, M., R. Braden, W. Eddy, and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification Documents", for Transmission Control Protocol (TCP) Specification Documents",
RFC 4614, September 2006. RFC 4614, September 2006.
skipping to change at page 37, line 36 skipping to change at page 38, line 45
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
Phone: (978) 936-0000 Phone: (978) 936-0000
EMail: kkinnear@cisco.com EMail: kkinnear@cisco.com
Bernie Volz
Cisco Systems
1414 Massachusetts Ave.
Boxborough, Massachusetts 01719
Phone: (978) 936-0000
EMail: volz@cisco.com
Neil Russell Neil Russell
Nokia BMC Software
5 Wayside Drive 10 Maguire Rd., Bldg. 3, Ste. 320
Burlington, MA 01803 Lexington, MA 02421
EMail: neil.russell@nokia.com Phone: (781) 257-3105
EMail: neil_russell@bmc.com
Mark Stapp Mark Stapp
Cisco Systems Cisco Systems
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
Phone: (978) 936-0000 Phone: (978) 936-0000
EMail: mjs@cisco.com EMail: mjs@cisco.com
skipping to change at page 38, line 37 skipping to change at line 1748
URI: http://www.infosys.com/ URI: http://www.infosys.com/
Bharat Joshi Bharat Joshi
Infosys Technologies Ltd. Infosys Technologies Ltd.
44 Electronics City, Hosur Road 44 Electronics City, Hosur Road
Bangalore 560 100 Bangalore 560 100
India India
EMail: bharat_joshi@infosys.com EMail: bharat_joshi@infosys.com
URI: http://www.infosys.com/ URI: http://www.infosys.com/
Pavan Kurapati
Juniper Networks Ltd.
Embassy Prime Buildings, C.V.Raman Nagar
Bangalore 560 093
India
Email: kurapati@juniper.net
URI: http://www.juniper.net/
 End of changes. 23 change blocks. 
50 lines changed or deleted 108 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/