idnits 2.17.1 draft-ietf-dhc-dhcpv4-bulk-leasequery-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 496 has weird spacing: '...ge-size the...' == Line 1659 has weird spacing: '... Name sta...' -- The document date (October 15, 2012) is 4210 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-13) exists of draft-ietf-dhc-relay-id-suboption-11 -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Kim Kinnear 3 Internet Draft Mark Stapp 4 Intended Status: Standards Track Cisco Systems, Inc. 5 Expires: April 15, 2013 D. Rao 6 B. Joshi 7 Infosys Technologies Ltd. 8 Neil Russell 9 BMC Software, Inc. 10 October 15, 2012 12 Bulk DHCPv4 Lease Query 13 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Abstract 53 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery 54 extension allows a requestor to request information about DHCPv4 55 bindings. This mechanism is limited to queries for individual 56 bindings. In some situations individual binding queries may not be 57 efficient, or even possible. This document extends the DHCPv4 58 Leasequery protocol to allow for bulk transfer of DHCPv4 address 59 binding data via TCP. 61 Table of Contents 63 1. Introduction................................................. 3 64 2. Terminology.................................................. 4 65 3. Design Goals................................................. 7 66 3.1. Information Acquisition before Data Starts................. 7 67 3.2. Lessen need for Caching and Negative Caching............... 7 68 3.3. Antispoofing in 'Fast Path'................................ 8 69 3.4. Minimize data transmission................................. 8 70 4. Protocol Overview............................................ 8 71 5. Interaction Between UDP Leasequery and Bulk Leasequery....... 10 72 6. Message and Option Definitions............................... 11 73 6.1. Message Framing for TCP.................................... 11 74 6.2. New or Changed Options..................................... 12 75 6.3. Connection and Transmission Parameters..................... 19 76 7. Requestor Behavior........................................... 19 77 7.1. Connecting and General Processing.......................... 19 78 7.2. Forming a Bulk Leasequery.................................. 20 79 7.3. Processing Bulk Replies.................................... 22 80 7.4. Processing Time Values in Leasequery messages.............. 24 81 7.5. Querying Multiple Servers.................................. 25 82 7.6. Making Sense Out of Multiple Responses Concerning a Single. 25 83 7.7. Multiple Queries to a Single Server over One Connection.... 26 84 7.8. Closing Connections........................................ 27 85 8. Server Behavior.............................................. 28 86 8.1. Accepting Connections...................................... 28 87 8.2. Replying to a Bulk Leasequery.............................. 28 88 8.3. Building a Single Reply for Bulk Leasequery................ 31 89 8.4. Multiple or Parallel Queries............................... 33 90 8.5. Closing Connections........................................ 33 91 9. Security Considerations...................................... 34 92 10. IANA Considerations......................................... 35 93 11. Contributing Authors........................................ 37 94 12. Acknowledgements............................................ 38 95 13. References.................................................. 38 96 13.1. Normative References...................................... 38 97 13.2. Informative References.................................... 39 99 1. Introduction 101 The DHCPv4 protocol [RFC2131] [RFC2132] specifies a mechanism for the 102 assignment of IPv4 address and configuration information to IPv4 103 nodes. DHCPv4 servers maintain authoritative binding information. 105 +--------+ 106 | DHCPv4 | +--------------+ 107 | Server |-...-| DHCP | 108 | | | Relay Agent | 109 +--------+ +--------------+ 110 | | 111 +------+ +------+ 112 |Modem1| |Modem2| 113 +------+ +------+ 114 | | | 115 +-----+ +-----+ +-----+ 116 |Node1| |Node2| |Node3| 117 +-----+ +-----+ +-----+ 119 Figure 1: Example DHCPv4 configuration 121 DHCPv4 relay agents receive DHCPv4 messages and frequently append a 122 relay agent information option [RFC3046] before relaying them to the 123 configured DHCPv4 servers (see Figure 1). In this process, some relay 124 agents also glean lease information sent by the server and cache it 125 locally. This information is used for a variety of purposes. Two 126 examples are prevention of spoofing attempts from the DHCPv4 clients, 127 and installation of routes. When a relay agent reboots, this 128 information is frequently lost. 130 The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 131 capability to allow an external entity, such as a relay agent, to 132 query a DHCPv4 server to rapidly recover lease state information 133 about a particular IP address or client. 135 The existing query types in Leasequery are typically data driven; the 136 relay agent initiates the Leasequery when it receives data traffic 137 from or to the client. This approach may not scale well when there 138 are thousands of clients connected to the relay agent or when the 139 relay agent has a need to rebuild its internal data store prior to 140 processing traffic in one direction or another. 142 Some applications require the ability to query the server without 143 waiting for traffic from or to clients. This query capability in turn 144 requires an underlying transport more suitable to the bulk 145 transmission of data. 147 This document extends the DHCPv4 Leasequery protocol to add support 148 for queries that address these additional requirements. There may be 149 many thousands of DHCPv4 bindings returned as the result of a single 150 request, so TCP [RFC4614] is specified for efficiency of data 151 transfer. We define several additional query types, each of which 152 can return multiple responses, in order to meet a variety of 153 requirements. 155 2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in RFC 160 2119 [RFC2119]. 162 This document uses the following terms: 164 o "absolute time" 166 A 32-bit quantity containing the number of seconds since Jan 1, 167 1970. 169 o "access concentrator" 171 An access concentrator is a router or switch at the broadband 172 access provider's edge of a public broadband access network. 173 This document assumes that the access concentrator includes the 174 DHCPv4 relay agent functionality. For example, a CMTS (Cable 175 Modem Termination System) in Cable environment or a DSLAM 176 (Digital Subscriber Line Access Multiplexer) in a DSL 177 environment. 179 o "active binding" 181 An IP address with an active binding refers to an IP address 182 which is currently associated with a DHCPv4 client where that 183 DHCPv4 client has the right to use the IP address. 185 o "Bulk Leasequery" 187 Requesting and receiving the existing DHCPv4 address binding 188 information in an efficient manner. 190 o "clock skew" 192 The difference between the absolute time on a DHCPv4 server and 193 the absolute time on the system where a requestor of a Bulk 194 Leasequery is executing is termed the "clock skew" for that Bulk 195 Leasequery connection. It is not absolutely constant but is 196 likely to vary only slowly. It is possible that, when both 197 systems run NTP, the clock skew is negligible, and this is not 198 only acceptable, but desired. 200 While it is easy to think that this can be calculated precisely 201 after one message is received by a requestor from a DHCPv4 202 server, a more accurate value is derived from continuously 203 examining the instantaneous value developed from each message 204 received from a DHCPv4 server and using it to make small 205 adjustments to the existing value held in the requestor. 207 o "Default VPN" 209 Indicates that the address being described belongs to the set of 210 addresses not part of any VPN. In other words, the normal 211 address space operated on by DHCP. This includes Special Use 212 IPv4 Addresses as defined in [RFC1918]. 214 o "DHCPv4 client" 216 A DHCPv4 client is an Internet node using DHCPv4 to obtain 217 configuration parameters such as a network address. 219 o "DHCPv4 relay agent" 221 A DHCPv4 relay agent is an agent that is neither a DHCPv4 client 222 nor a DHCP server that transfers BOOTP and DHCPv4 messages 223 between clients and servers residing on different subnets, per 224 [RFC951] and [RFC1542]. 226 o "DHCPv4 server" 228 A DHCPv4 server is an Internet node that returns configuration 229 parameters to DHCPv4 clients. 231 o "DSLAM" 233 Digital Subscriber Line Multiplexer. 235 o "downstream" 237 Refers to a direction away from the central part of a network 238 and toward the edge. In a DHCPv4 context, typically refers to a 239 network direction which is away from the DHCPv4 server and 240 toward the DHCPv4 client.. 242 o "Global VPN" 244 Another name for the "Default VPN". 246 o "IP address" 248 In this document, the term "IP address" refers to an IPv4 IP 249 address. 251 o "IP address binding" 253 The information that a DHCPv4 server keeps regarding the 254 relationship between a DHCPv4 client and an IP address. This 255 includes the identity of the DHCPv4 client and the expiration 256 time, if any, of any lease that client has on a particular IP 257 address. In some contexts, this may include information on IP 258 addresses that are currently associated with DHCPv4 clients, and 259 in others it may also include IP addresses with no current 260 association to a DHCPv4 client. 262 o "MAC address" 264 In the context of a DHCPv4 message, a MAC address consists of 265 the fields: hardware type "htype", hardware length "hlen", and 266 client hardware address "chaddr". 268 o "upstream" 270 Refers to a direction toward the central part of a network and 271 away from the edge. In a DHCPv4 context, typically refers to a 272 network direction which is away from the DHCPv4 client toward 273 the DHCPv4 server. 275 o "stable storage" 277 Stable storage is used to hold information concerning IP address 278 bindings (among other things) so that this information is not 279 lost in the event of a failure which requires restart of the 280 network element. DHCPv4 servers are typically expected to have 281 high speed access to stable storage, while relay agents and 282 access concentrators usually do not have access to stable 283 storage, although they may have periodic access to such storage. 285 o "xid" 287 Transaction-id. The term "xid" refers to the DHCPv4 field 288 containing the transaction-id of the message. 290 3. Design Goals 292 The goal of this document is to provide a lightweight mechanism for 293 an Access Concentrator or other network element (such as a DHCP Relay 294 Agent) to retrieve IP address binding information available in the 295 DHCPv4 server. The mechanism should also allow an Access 296 Concentrator or DHCP Relay Agent to retrieve consolidated IP address 297 binding information for either the entire access concentrator or a 298 single connection/circuit. Throughout the discussion below, 299 everything that applies to an Access Concentrator also applies to a 300 DHCP Relay Agent. 302 3.1. Information Acquisition before Data Starts 304 The existing data driven approach required by [RFC4388] means that 305 the Leasequeries can only be performed after an Access Concentrator 306 receives data. To implement antispoofing, the concentrator must drop 307 messages for each client until it gets lease information from the 308 DHCPv4 server for that client. If an Access Concentrator finishes the 309 Leasequeries before it starts receiving data, then there is no need 310 to drop legitimate messages. In this way, outage time may be reduced. 312 3.2. Lessen need for Caching and Negative Caching 314 The result of a single Leasequery should be cached, whether that 315 results in a positive or negative cache, in order to remember that 316 the Leasequery was performed. This caching is required to limit the 317 traffic imposed upon a DHCPv4 server by Leasequeries for information 318 already received. 320 These caches not only consume precious resources, they also need to 321 be managed. Hence they should be avoided as much as possible. One 322 of the goals of the DHCPv4 Bulk Leasequery is to reduce the need for 323 this sort of caching. 325 3.3. Antispoofing in 'Fast Path' 327 If Antispoofing is not done in the fast path, it will become a 328 bottleneck and may lead to denial of service of the access 329 concentrator. The Leasequeries should make it possible to do 330 antispoofing in the fast path. 332 3.4. Minimize data transmission 334 It may be that a network element is able to periodically save its 335 entire list of assigned IP addresses to some form of stable storage. 336 In this case, it will wish to recover all of the updates to this 337 information without duplicating the information it has recovered from 338 its own stable storage. 340 Bulk Leasequery allows the specification of a query-start-time as 341 well as a query-end-time. Use of query-times allows a network 342 element that periodically commits information to stable storage to 343 recover just what it lost since the last commit. 345 4. Protocol Overview 347 The DHCPv4 Bulk Leasequery mechanism is modeled on the existing 348 individual DHCPv4 Leasequery protocol in [RFC4388] as well as related 349 work on DHCPv6 Bulk Leasequery [RFC5460]. A Bulk Leasequery requestor 350 opens a TCP connection to a DHCPv4 Server, using the DHCPv4 port 67. 351 Note that this implies that the Leasequery requestor has server IP 352 address(es) available via configuration or some other means, and that 353 it has unicast IP reachability to the DHCPv4 server. No relaying of 354 Bulk Leasequery messages is specified. 356 After establishing a connection, the requestor sends a 357 DHCPBULKLEASEQUERY message over the connection. 359 The server uses the message type and additional data in the DHCPv4 360 DHCPBULKLEASEQUERY message to identify any relevant bindings. 362 In order to support some query types, servers may have to maintain 363 additional data structures or otherwise be able to locate bindings 364 that have been requested by the Leasequery requestor. 366 Relevant bindings are returned in DHCPv4 messages with either the 367 DHCPLEASEACTIVE message type for an IP address with a currently 368 active lease or, in some situations, a DHCPLEASEUNASSIGNED message 369 type for an IP address which is controlled by the DHCPv4 server but 370 which is not actively leased by a DHCPv4 client at the present time. 372 The Bulk Leasequery mechanism is designed to provide an external 373 entity with information concerning existing DHCPv4 IPv4 address 374 bindings managed by the DHCPv4 server. When complete, the DHCPv4 375 server will send a DHCPLEASEQUERYDONE message. If a connection is 376 lost while processing a Bulk Leasequery, the Bulk Leasequery must be 377 retried as there is no provision for determining the extent of data 378 already received by the requestor for a Bulk Leasequery. 380 Bulk Leasequery supports queries by MAC address and by Client 381 Identifier in a way similar to [RFC4388]. The Bulk Leasequery 382 protocol also adds several new queries. 384 o Query by Relay Identifier 386 This query asks a server for the bindings associated with a 387 specific relay agent; the relay agent is identified by a DUID 388 carried in a Relay-ID sub-option [RelayId]. Relay agents can 389 include this sub-option while relaying messages to DHCPv4 390 servers. Servers can retain the Relay-ID and associate it with 391 bindings made on behalf of the relay agent's clients. The 392 bindings returned are only those for DHCPv4 clients with a 393 currently active binding. 395 o Query by Remote ID 397 This query asks a server for the bindings associated with a 398 Relay Agent Remote-ID sub-option [RFC3046] value. The bindings 399 returned are only those for DHCPv4 clients with a currently 400 active binding. 402 o Query for All Configured IP Addresses 404 This query asks a server for information concerning all IP 405 addresses configured in that DHCPv4 server, by specifying no 406 other type of query. In this case, the bindings returned are for 407 all configured IP addresses, whether or not they contain a 408 currently active binding to a DHCPv4 client, since one point of 409 this type of query is to update an existing database with 410 changes after a particular point in time. 412 Any of the above queries can be qualified by the specification of a 413 query-start-time or a query-end-time (or both). When these timers are 414 used as qualifiers, they indicate that a binding should be included 415 if it changed on or after the query-start-time and on or before the 416 query-end-time. 418 In addition, any of the above queries can be qualified by the 419 specification of a vpn-id option [RFC6607] to select the VPN on which 420 the query should be processed. The vpn-id option is also extended to 421 allow queries across all available VPNs. In the absence of any vpn-id 422 option, only the default (global) VPN is used to satisfy the query. 424 5. Interaction Between UDP Leasequery and Bulk Leasequery 426 Bulk Leasequery can be seen as an extension of the existing UDP 427 Leasequery protocol [RFC4388]. This section clarifies the 428 relationship between the two protocols. 430 The Bulk Leasequery TCP connection is only designed to handle the 431 DHCPBULKLEASEQUERY request. It is not intended as an alternative 432 DHCPv4 communication option for clients seeking other DHCPv4 433 services. DHCPv4 address allocation could not be performed over a 434 TCP connection in any case, as a TCP connection requires an IP 435 address, as no IPv4 address exists prior to a successful DHCPv4 436 address allocation exchange. In addition, the existing DHCPv4 UDP 437 transmission regime is implemented in untold millions of devices 438 deployed worldwide, and complicating DHCPv4 services with alternative 439 transmission approaces (even if it were possible) would be worse than 440 any perceived benefit to doing so. 442 Two of the query-types introduced in the UDP Leasequery protocol can 443 be used in the Bulk Leasequery protocol -- query by MAC address and 444 query by client-id. 446 The contents of the reply messages are similar between the existing 447 UDP Leasequery protocol and the Bulk Leasequery protocol, though more 448 information is returned in the Bulk Leasequery messages. 450 One change in behavior for these existing queries is required when 451 Bulk Leasequery is used. [RFC4388], in sections 6.1, 6.4.1, and 452 6.4.2 specifies the use of an associated-ip option in DHCPLEASEACTIVE 453 messages in cases where multiple bindings were found. When Bulk 454 Leasequery is used, this mechanism is not necessary; a server 455 returning multiple bindings simply does so directly as specified in 456 this document. The associated-ip option MUST NOT appear in Bulk 457 Leasequery replies. 459 Implementors should note that the TCP message framing defined in 460 Section 4.1 is not compatible with the UDP message format. If a TCP- 461 framed request is sent as a UDP message, it may not be valid, because 462 protocol fields will be offset by the message-size prefix. 464 6. Message and Option Definitions 466 6.1. Message Framing for TCP 468 The use of TCP for the Bulk Leasequery protocol permits multiple 469 messages to be sent from one end of the connection to the other 470 without requiring a request/response paradigm as does UDP DHCPv4 471 [RFC2131]. The receiver needs to be able to determine the size of 472 each message it receives. Two octets containing the message size in 473 network byte-order are prepended to each DHCPv4 message sent on a 474 Bulk Leasequery TCP connection. The two message-size octets 'frame' 475 each DHCPv4 message. 477 The maximum message size is 65535 octets. 479 DHCPv4 message framed for TCP: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | message-size | op (1) | htype (1) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | hlen (1) | hops (1) | .... | 487 +---------------+---------------+ + 488 | | 489 . remainder of DHCPv4 message, 490 . from Figure 1 of [RFC2131] . 491 . . 492 . (variable) . 493 | | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 message-size the number of octets in the message that 497 follows, as a 16-bit unsigned integer in 498 network byte-order. 500 All other fields are as specified in DHCPv4 [RFC2131]. 502 Figure 2: Format of a DHCPv4 message in TCP 504 The intent in using this format is that code which currently knows 505 how to deal with sending or receiving a message in [RFC2131] format 506 will easily be able to deal with the message contained in the TCP 507 framing. 509 6.2. New or Changed Options 511 The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are 512 used as the value of the dhcp-message-type option to indicate an IP 513 address which is currently not leased or currently leased to a DHCPv4 514 client, respectively [RFC4388]. 516 Additional options have also been defined to enable the Bulk 517 Leasequery protocol to communicate useful information to the 518 requestor. 520 6.2.1. dhcp-message-type 522 The dhcp-message-type option (option 53) from Section 9.6 of 523 [RFC2132] requires new values. The values of these message types are 524 shown below in an extension of the table from Section 9.6 of 525 [RFC2132]: 527 Value Message Type 528 ----- ------------ 529 TBD8 DHCPBULKLEASEQUERY 530 TBD9 DHCPLEASEQUERYDONE 532 6.2.2. status-code 534 The status code option allows a machine readable value to be returned 535 regarding the status of a DHCPBULKLEASEQUERY request. 537 This option has two possible scopes when used with Bulk Leasequery, 538 depending on the context in which it appears. It refers to the 539 information in a single Leasequery reply if the value of the dhcp- 540 message-type is DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED. It refers to 541 the message stream related to an entire request if the value of the 542 dhcp-message-type is DHCPLEASEQUERYDONE. 544 The code for this option is TBD1. The length of this option is a 545 minimum of 1 octet. 547 Status Status 548 Code Len Code Message 549 +------+------+------+------+------+-- --+-----+ 550 | TBD1 | n+1 |status| s1 | s2 | ... | sn | 551 +------+------+------+------+------+-- --+-----+ 553 The status-code is indicated in one octet as defined in the table 554 below. The Status Message is an optional UTF-8 encoded text string 555 suitable for display to an end user. This text string MUST NOT 556 contain a termination character (e.g., a null). The len field 557 describes the length of the status message without any terminator 558 character. Nulls characters MUST NOT appear in the Status Message 559 string and it is a protocol violation for them to appear in any 560 position in the Status Message, including at the end. 562 Name Status Code Description 563 ---- ----------- ----------- 564 Success 000 Success. Also signaled by absence of 565 a status-code option. 567 UnspecFail 001 Failure, reason unspecified. 569 QueryTerminated 002 Indicates that the server is unable to 570 perform a query or has prematurely terminated 571 the query for some reason (which should be 572 communicated in the text message). 574 MalformedQuery 003 The query was not understood. 576 NotAllowed 004 The query or request was understood but was 577 not allowed in this context. 579 A status-code option MAY appear in the options field of a DHCPv4 580 message. If the status-code option does not appear, it is assumed 581 that the operation was successful. The status-code option SHOULD NOT 582 appear in a message which is successful unless there is some text 583 string that needs to be communicated to the requestor. 585 6.2.3. base-time 587 The base-time option is the current time the message was created to 588 be sent by the DHCPv4 server to the requestor of the Bulk Leasequery. 589 This MUST be an absolute time. All of the other time based options 590 in the reply message are relative to this time, including the dhcp- 591 lease-time [RFC2132] and client-last-transaction-time [RFC4388]. 592 This time is in the context of the DHCPv4 server who placed this 593 option in a message. 595 This is an unsigned integer in network byte order. 597 The code for this option is TBD2. The length of this option is 4 598 octets. 600 DHCPv4 Server 601 Code Len base-time 602 +-----+-----+-----+-----+-----+-----+ 603 | TBD2| 4 | t1 | t2 | t3 | t4 | 604 +-----+-----+-----+-----+-----+-----+ 606 6.2.4. start-time-of-state 608 The start-time-of-state option allows the receiver to determine the 609 time at which the IP address made the transition into its current 610 state. 612 This MUST NOT be an absolute time, which is equivalent to saying that 613 this MUST NOT be an absolute number of seconds since Jan 1, 1970. 614 Instead, this MUST be the unsigned integer number of seconds from the 615 time the IP address transitioned its current state to the time 616 specified in the base-time option in the same message. 618 This is an unsigned integer in network byte order. 620 The code for this option is TBD3. The length of this option is 4 621 octets. 623 Seconds in the past 624 Code Len from base-time 625 +-----+-----+-----+-----+-----+-----+ 626 | TBD3| 4 | t1 | t2 | t3 | t4 | 627 +-----+-----+-----+-----+-----+-----+ 629 6.2.5. query-start-time 631 The query-start-time option specifies a start query time to the 632 DHCPv4 server. If specified, only bindings that have changed on or 633 after the query-start-time should be included in the response to the 634 query. 636 The requestor MUST determine the query-start-time using lease 637 information it has received from the DHCPv4 server. This MUST be an 638 absolute time in the DHCPv4 server's context (see Section 7.4). 640 Typically (though this is not a requirement) the query-start-time 641 option will contain the value most recently received in a base-time 642 option by the requestor, as this will indicate the last successful 643 communication with the DHCP server. 645 This MUST be an absolute time. 647 This is an unsigned integer in network byte order. 649 The code for this option is TBD4. The length of this option is 4 650 octets. 652 DHCPv4 Server 653 Code Len query-start-time 654 +-----+-----+-----+-----+-----+-----+ 655 | TBD4| 4 | t1 | t2 | t3 | t4 | 656 +-----+-----+-----+-----+-----+-----+ 658 6.2.6. query-end-time 660 The query-end-time option specifies an end query time to the DHCPv4 661 server. If specified, only bindings that have changed on or before 662 the query-end-time should be included in the response to the query. 664 The requestor MUST determine the query-end-time based on lease 665 information it has received from the DHCPv4 server. This MUST be an 666 absolute time in the context of the DHCPv4 server. 668 In the absence of information to the contrary, the requestor SHOULD 669 assume that the time context of the DHCPv4 server is identical to the 670 time context of the requestor (see Section 7.4). 672 This is an unsigned integer in network byte order. 674 The code for this option is TBD5. The length of this option is 4 675 octets. 677 DHCPv4 Server 678 Code Len query-end-time 679 +-----+-----+-----+-----+-----+-----+ 680 | TBD5| 4 | t1 | t2 | t3 | t4 | 681 +-----+-----+-----+-----+-----+-----+ 683 6.2.7. dhcp-state 685 The dhcp-state option allows greater detail to be returned than 686 allowed by the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types. 688 The code for this option is TBD6. The length of this option is 1 689 octet. 691 0 1 2 692 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | TBD6 | Length | State | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 TBD6 The option code. 699 Length The option length, 1 octet. 701 State The State of the IP address. 703 Value State 704 ----- ----- 705 1 AVAILABLE Address is available to local DHCPv4 server 706 2 ACTIVE Address is assigned to a DHCPv4 client 707 3 EXPIRED Lease has expired 708 4 RELEASED Lease has been released by DHCPv4 client 709 5 ABANDONED Server or client flagged address as unusable 710 6 RESET Lease was freed by some external agent 711 7 REMOTE Address is available to a remote DHCPv4 server 712 8 TRANSITIONING Address is moving between states 714 Note that some of these states may be transient and may not appear in 715 normal use. A DHCPv4 server MUST implement at least the AVAILABLE 716 and ACTIVE states, and SHOULD implement at least the ABANDONED and 717 RESET states. 719 Note the states AVAILABLE and REMOTE are relative to the current 720 server. An address that is available to the current server should 721 show AVAILABLE on that server, and if another server is involved with 722 that address as well, on that other server it should show as REMOTE. 724 The dhcp-state option SHOULD contain ACTIVE when it appears in a 725 DHCPLEASEACTIVE message. A DHCPv4 server MAY choose to not send a 726 dhcp-state option in a DHCPLEASEACTIVE message, and a requestor 727 SHOULD assume that the dhcp-state is ACTIVE if no dhcp-state option 728 appears in a DHCPLEASEACTIVE message. 730 The reference to local and remote relate to possible use in an 731 environment that includes multiple servers cooperating to provide an 732 increased availability solution. In this case, an IP address with 733 the state of AVAILABLE is available to the local server, while one 734 with the state of REMOTE is available to a remote server. Usually, 735 an IP address which is AVAILABLE on one server would be REMOTE on any 736 remote server. The TRANSITIONING state is also likely to be useful 737 in multiple server deployments, where sometimes one server must 738 interlock a state change with one or more other servers. Should a 739 Bulk Leasequery need to send information concerning the state of the 740 IP address during this period, it SHOULD use the TRANSITIONING state, 741 since the IP address is likely to be neither ACTIVE or AVAILABLE. 743 There is no requirement for the state of an IP address to transition 744 in a well defined way from state to state. To put this another way, 745 you cannot draw a simple state transition graph for the states of an 746 IP address and the requestor of a Leasequery MUST NOT depend on one 747 certain state always following a particular previous state. While a 748 state transition diagram can be drawn, it would be fully connected 749 and therefore conveys no useful information. Every state can (at 750 times) follow every other state. 752 6.2.8. data-source 754 The data-source option contains information about the source of the 755 data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It 756 SHOULD be used when there are two or more servers who might have 757 information about a particular IP address binding. Frequently two 758 servers work together to provide an increased availability solution 759 for the DHCPv4 service, and in these cases, both servers will respond 760 to Bulk Leasequery requests for the same IP address. When one server 761 is working with another server and both may respond with information 762 about the same IP address, each server SHOULD return the data-source 763 option with the other information provided about the IP address. 765 The data contained in this option will allow an external process to 766 better discriminate between the information provided by each of the 767 servers servicing this IPv4 address. 769 The code for this option is TBD7. The length of this option is 1 770 octet. 772 0 1 2 773 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | TBD7 | Length | Flags | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 TBD7 The option code. 780 Length The option length, 1 octet. 782 Flags The Source information for this message. 784 0 1 2 3 4 5 6 7 785 +-+-+-+-+-+-+-+-+ 786 | UNA |R| 787 +-+-+-+-+-+-+-+-+ 789 R: REMOTE flag 791 remote = 1 792 local = 0 794 UNA: UNASSIGNED 796 The REMOTE flag is used to indicate where the most recent change of 797 state (or other interesting change) concerning this IPv4 address took 798 place. If the value is local, then the change took place on the 799 server from which this message was transmitted. If the value is 800 remote, then the change took place on some other server, and was made 801 known to the server from which this message was transmitted. 803 If this option was requested and it doesn't appear, the requestor 804 MUST consider that the data-source was local. 806 Unassigned bits MUST be ignored. 808 6.2.9. Virtual Subnet Selection Type and Information 810 All of the (sub)options defined in [RFC6607] carry identical 811 payloads, consisting of a type and additional VSS (Virtual Subnet 812 Selection) information. The existing table is extended (see below) 813 with a new type 254 to allow specification of a type code which 814 indicates that all VPN's are to be used to process the Bulk 815 Leasequery. 817 Type VSS Information Format 818 ---------------------------------------------------------- 819 0 Network Virtual Terminal (NVT) ASCII VPN identifier 820 1 RFC 2685 VPN-ID 821 CHANGED -> 2-253 Unassigned 822 NEW -> 254 All VPN's (wildcard) 823 255 Global, default VPN 825 6.3. Connection and Transmission Parameters 827 DHCPv4 servers that support Bulk Leasequery SHOULD listen for 828 incoming TCP connections on the DHCPv4 server port 67. 829 Implementations MAY offer to make the incoming port configurable, but 830 port 67 MUST be the default. Requestors SHOULD make TCP connections 831 to port 67, and MAY offer to make the destination server port 832 configurable. 834 This section presents a table of values used to control Bulk 835 Leasequery behavior, including recommended defaults. Implementations 836 MAY make these values configurable. However, configuring too-small 837 timeout values may lead to harmful behavior both to this application 838 as well as to other traffic in the network. As a result, timeout 839 values smaller than the default values are NOT RECOMMENDED. 841 Parameter Default Description 842 ------------------------------------------- 843 BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout 844 for both client and server 845 (see Sections 7 and 8) 846 BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections 847 at the server side (see Section 8.1) 849 7. Requestor Behavior 851 7.1. Connecting and General Processing 853 A Requestor attempts to establish a TCP connection to a DHCPv4 Server 854 in order to initiate a Leasequery exchange. If the attempt fails, 855 the Requestor MAY retry. 857 If Bulk Leasequery is terminated prematurely by a DHCPLEASEQUERYDONE 858 with a status-code option with a status-code of QueryTerminated or by 859 the failure of the connection over which it was being submitted, the 860 requestor MAY retry the request after the creation of a new 861 connection. 863 Messages from the DHCPv4 server come as multiple responses to a 864 single DHCPBULKLEASEQUERY message. Thus, each DHCPBULKLEASEQUERY 865 request MUST have an xid (transaction-id) unique on the connection on 866 which it is sent. All of the messages which come as a response to 867 that message will contain the same xid as the request. It is the xid 868 which allows the data-streams of two different DHCPBULKLEASEQUERY 869 requests to be demultiplexed by the requestor. 871 7.2. Forming a Bulk Leasequery 873 Bulk Leasequery is designed to create a connection which will 874 transfer the state of some subset (or possibly all) of the IP address 875 bindings from the DHCPv4 server to the requestor. The DHCPv4 server 876 will send all of the requested IPv4 address bindings across this 877 connection with minimal delay after it receives the request. In this 878 context, "all IP address binding information" means information about 879 all IPv4 addresses configured within the DHCPv4 server which meet the 880 specified query criteria. For some query criteria, this may include 881 IP address binding information for IP addresses which may not now 882 have or ever had have an association with a specific DHCPv4 client. 884 To form the Bulk query, a DHCPv4 request is constructed with a dhcp- 885 message-type of DHCPBULKLEASEQUERY. The query SHOULD have a dhcp- 886 parameter-request-list to inform the DHCPv4 server which DHCPv4 887 options are of interest to the requestor sending the 888 DHCPBULKLEASEQUERY message. The dhcp-parameter-request-list in a 889 DHCPBULKLEASEQUERY message SHOULD contain the codes for base-time, 890 dhcp-lease-time, start-time-of-state, and client-last-transaction- 891 time. 893 A DHCPBULKLEASEQUERY request is constructed of one primary query and 894 optionally one or more qualifiers for it. 896 The possible primary queries are listed below. Each 897 DHCPBULKLEASEQUERY request MUST contain only one of these primary 898 queries. 900 o Query by MAC address 902 In a Query by MAC address, the chaddr, htype, and hlen of the 903 DHCPv4 packet are filled in with the values requested. 905 o Query by Client-Id 906 In a Query by Client-Id, a dhcp-client-id option containing the 907 requested value is included in the DHCPBULKLEASEQUERY request. 909 o Query by Remote-Id 911 In a Query by Remote-Id, a remote-id sub-option containing the 912 requested value is included in the relay-agent-information 913 option of the DHCPBULKLEASEQUERY request. 915 o Query by Relay-Id 917 In a Query by Relay-Id, a relay-id sub-option [RelayId] 918 containing the requested value is included in the relay-agent- 919 information option of the DHCPBULKLEASEQUERY request. 921 o Query for All Configured IP Addresses 923 A Query for All Configured IP addresses is signaled by the 924 absence of any other primary query. 926 There are three qualifiers which can be applied to any of the above 927 primary queries. These qualifiers can appear individually or 928 together in any combination, but only one of each can appear. 930 o Query Start Time 932 Inclusion of a query-start-time option specifies that only IP 933 address bindings which have changed on or after the time specified 934 in the query-start-time option should be returned. 936 o Query End Time 938 Inclusion of a query-end-time option specifies that only IP address 939 bindings which have changed on or before the time specified in the 940 query-end-time option should be returned. 942 o VPN Id 944 If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default 945 (global) VPN is searched to satisfy the query specified by the 946 DHCPBULKLEASEQUERY. Using the vpn-id option [RFC6607] allows the 947 requestor to specify a single VPN other than the default VPN. In 948 addition, the vpn-id option has been extended as part of this 949 document to allow specification that all configured VPN's be 950 searched in order to satisfy the query specified in the 951 DHCPBULKLEASEQUERY. 953 In all cases, any message returned from a DHCPBULKLEASEQUERY 954 request containing information about an IP address for other than 955 the default (global) VPN MUST contain a vpn-id option in the 956 message. 958 Use of the query-start-time or the query-end-time options or both can 959 serve to reduce the amount of data transferred over the TCP 960 connection by a considerable amount. Note that the times specified 961 in the query-start-time or query-end-time options are absolute times, 962 not durations offset from "now". 964 The TCP connection may become blocked or stop being writable while 965 the requestor is sending its query. Should this happen, the 966 implementation's behavior is controlled by the current value of 967 BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this 968 document, and this value may be overridden by local configuration of 969 the operator. 971 If this situation is detected, the requestor SHOULD start a timer 972 using the current value of BULK_LQ_DATA_TIMEOUT. If that timer 973 expires, the requestor SHOULD terminate the connection. This timer 974 is completely independent of any TCP timeout established by the TCP 975 protocol connection. 977 7.3. Processing Bulk Replies 979 The requestor attempts to read a DHCPv4 Leasequery reply message from 980 the TCP connection. 982 The TCP connection may stop delivering reply data (i.e., the 983 connection stops being readable). Should this happen, the 984 implementation's behavior is controlled by the current value of 985 BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this 986 document, and this value may be overridden by local configuration of 987 the operator. 989 If this situation is detected, the requestor SHOULD start a timer 990 using the current value of BULK_LQ_DATA_TIMEOUT. If that timer 991 expires, the requestor SHOULD terminate the connection. 993 A single Bulk Leasequery can and usually will result in a large 994 number of replies. The requestor MUST be prepared to receive more 995 than one reply with an xid matching a single DHCPBULKLEASEQUERY 996 message from a single DHCPv4 server. If the xid in the received 997 message does not match an outstanding DHCPBULKLEASEQUERY message, the 998 requestor MUST close the TCP connection. 1000 If the requestor receives more data than it can process, it can 1001 simply abort the connection and try again with a more specific 1002 request. It can also simply read the TCP connection more slowly, and 1003 match the rate at which it can digest the information returned in the 1004 Bulk Leasequery packets with the rate at which it reads those packets 1005 from the TCP connection. 1007 The DHCPv4 server MUST send a server-identifier option (option 54) in 1008 the first response to any DHCPBULKLEASEQUERY message. The DHCPv4 1009 server SHOULD NOT send server identifier options in subsequent 1010 responses to that DHCPBULKLEASEQUERY message. The requestor MUST 1011 cache the server-identifier option from the first response and apply 1012 it to any subsequent responses. 1014 The response messages generated by a DHCPBULKLEASEQUERY request are: 1016 o DHCPLEASEACTIVE 1018 A Bulk Leasequery will generate DHCPLEASEACTIVE messages 1019 containing binding data for bound IP addresses which match the 1020 specified query criteria. The IP address which is bound to a 1021 DHCPv4 client will appear in the ciaddr field of the 1022 DHCPLEASEACTIVE message. The message may contain a non-zero 1023 chaddr, htype, and hlen and possibly additional options. 1025 o DHCPLEASEUNASSIGNED 1027 Some queries will also generate DHCPLEASEUNASSIGNED messages for 1028 IP addresses which match the query criteria. These messages 1029 indicate that the IP address is managed by the DHCPv4 server but 1030 is not currently bound to any DHCPv4 client. The IP address to 1031 which this message refers will appear in the ciaddr field of the 1032 DHCPLEASEUNASSIGNED message. A DHCPLEASEUNASSGINED message MAY 1033 also contain information about the last DHCPv4 client that was 1034 bound to this IP address. The message may contain a non-zero 1035 chaddr, htype, and hlen and possibly additional options in this 1036 case. 1038 o DHCPLEASEQUERYDONE 1040 A response of DHCPLEASEQUERYDONE indicates that the server has 1041 completed its response to the query, and that no more messages 1042 will be sent in response to the DHCPBULKLEASEQUERY. More details 1043 will sometimes be available in the received status-code option 1044 in the DHCPLEASEQUERYDONE message. If there is no status-code 1045 option in the DHCPLEASEQUERYDONE message, then the query 1046 completed successfully. 1048 Note that a query which returned no data, that is a 1049 DHCPBULKLEASEQUERY request followed by a DHCPLEASEQUERYDONE 1050 response, is considered a successful query in that no errors 1051 occurred during the processing. It is not considered an error 1052 to have no information to return to a DHCPBULKLEASEQUERY 1053 request. 1055 The DHCPLEASEUNKNOWN message MUST NOT appear in a response to a Bulk 1056 Leasequery. 1058 The requestor MUST NOT assume that there is any inherent order in the 1059 IP address binding information that is sent in response to a 1060 DHCPBULKLEASEQUERY. While the base-time will tend to increase 1061 monotonically (as it is the current time on the DHCPv4 server), the 1062 actual time that any IP address binding information changed is 1063 unrelated to the base-time. 1065 The DHCPLEASEQUERYDONE message always ends a successful 1066 DHCPBULKLEASEQUERY request and any unsuccessful DHCPBULKLEASEQUERY 1067 requests not terminated by a dropped connection. After receiving 1068 DHCPLEASEQUERYDONE from a server, the requestor MAY close the TCP 1069 connection to that server if no other DHCPBULKLEASEQUERY is 1070 outstanding on that TCP connection. 1072 The DHCPv4 Leasequery protocol [RFC4388] uses the associated-ip 1073 option as an indicator that multiple bindings were present in 1074 response to a single DHCPv4 client based query. For Bulk Leasequery, 1075 a separate message is returned for each binding, and so the 1076 associated-ip option is not used. 1078 7.4. Processing Time Values in Leasequery messages 1080 Bulk Leasequery requests may be made to a DHCPv4 server whose 1081 absolute time may not be synchronized with the local time of the 1082 requestor. Thus, there are at least two time contexts in even the 1083 simplest Bulk Leasequery response, and in the situation where 1084 multiple DHCPv4 servers are queried, the situation becomes even more 1085 complex. 1087 If the requestor of a Bulk Leasequery is saving the data returned in 1088 some form, it has a requirement to store a variety of time values, 1089 and some of these will be time in the context of the requestor and 1090 some will be time in the context of the DHCPv4 server. 1092 When receiving a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message from 1093 the DHCPv4 server, the message will contain a base-time option. The 1094 time contained in this base-time option is in the context of the 1095 DHCPv4 server. As such, it is an ideal time to save and use as input 1096 to a DHCPBULKLEASEQUERY in the query-start-time or query-end-time 1097 options, should the requestor need to ever issue a DHCPBULKLEASEQUERY 1098 message using those options as part of a later query, since those 1099 options require a time in the context of the DHCPv4 server. 1101 In addition to saving the base-time for possible future use in a 1102 query-start-time or query-end-time option, the base-time is used as 1103 part of the conversion of the other times in the Leasequery message 1104 to values which are meaningful in the context of the requestor. 1105 These other time values are specified as a offset (duration) from the 1106 base-time value and not as an absolute time. 1108 In systems whose clocks are synchronized, perhaps using NTP, the 1109 clock skew will usually be zero. 1111 7.5. Querying Multiple Servers 1113 A Bulk Leasequery requestor MAY be configured to attempt to connect 1114 to and query from multiple DHCPv4 servers in parallel. The DHCPv4 1115 Leasequery specification [RFC4388] includes a discussion about 1116 reconciling binding data received from multiple DHCPv4 servers. 1118 In addition, the algorithm in Section 7.6 should be used. 1120 7.6. Making Sense Out of Multiple Responses Concerning a Single IPv4 1121 Address 1123 Any requestor of an Bulk Leasequery MUST be prepared for multiple 1124 responses to arrive for a particular IPv4 address from multiple 1125 different DHCPv4 servers. The following algorithm SHOULD be used to 1126 decide if the information just received is more up to date (i.e., 1127 better) than the best existing information. In the discussion below, 1128 the information that is received from a DHCPv4 server about a 1129 particular IPv4 address is termed a "record". The times used in the 1130 algorithm below SHOULD have been converted into the requestor's 1131 context and the time comparisons SHOULD be performed in a manner 1132 consistent with the information in Section 7.4. 1134 o If both the existing and the new record contain client-last- 1135 transaction-time information, the record with the later client- 1136 last-transaction-time is considered better. 1138 o If one of the records contains client-last-transaction-time 1139 information and the other one doesn't, then compare the client- 1140 last-transaction-time in the record that contains it against the 1141 other record's start-time-of-state. The record with the later 1142 time is considered better. 1144 o If neither record contains client-last-transaction-time 1145 information, compare their start-time-of-state information. The 1146 record with the later start-time-of-state is considered better. 1148 o If none of the comparisons above yield a clear answer as to 1149 which record is later, then compare the value of the REMOTE flag 1150 from the data-source option for each record. 1152 If the values of the REMOTE flag are different between the two 1153 records, the record with the REMOTE flag value of local is 1154 considered better. 1156 The above algorithm does not necessarily determine which record is 1157 better. In the event that the algorithm is inconclusive with regard 1158 to a record which was just received by the requestor, the requestor 1159 SHOULD use additional information in the two records to make a 1160 determination as to which record is better. 1162 7.7. Multiple Queries to a Single Server over One Connection 1164 Bulk Leasequery requestors may need to make multiple queries in order 1165 to recover binding information. A requestor MAY use a single 1166 connection to issue multiple queries to a server willing to support 1167 them. Each query MUST have a unique xid. 1169 A server SHOULD allow configuration of the number of queries that can 1170 be processed simultaneously over a single connection. A server 1171 SHOULD read the number of queries it is configured to process 1172 simultaneously and only read any subsequent queries as current 1173 queries are processed. 1175 A server that is processing multiple queries simultaneously MUST NOT 1176 block sending replies on new queries until all replies for the 1177 existing query are complete. Requestors need to be aware that 1178 replies for multiple queries may be interleaved within the stream of 1179 reply messages. Requestors that are not able to process interleaved 1180 replies (based on xid) MUST NOT send more than one query over a 1181 single connection prior to the completion of the previous query. 1183 Requestors should be aware that servers are not required to process 1184 more than one query over a connection at a time (the limiting case 1185 for the configuration described above), and that servers are likely 1186 to limit the rate at which they process queries from any one 1187 requestor. 1189 7.7.1. Example 1191 This example illustrates what a series of queries and responses might 1192 look like. This is only an example - there is no requirement that 1193 this sequence must be followed, or that requestors or servers must 1194 support parallel queries. 1196 In the example session, the client sends four queries after 1197 establishing a connection. Query 1 returns no results; query 2 1198 returns 3 messages and the stream of replies concludes before the 1199 client issues any new query. Query 3 and query 4 overlap, and the 1200 server interleaves its replies to those two queries. 1202 Requestor Server 1203 --------- ------ 1204 DHCPBULKLEASEQUERY xid 1 -----> 1205 <----- DHCPLEASEQUERYDONE xid 1 1206 DHCPBULKLEASEQUERY xid 2 -----> 1207 <----- DHCPLEASEACTIVE xid 2 1208 <----- DHCPLEASEACTIVE xid 2 1209 <----- DHCPLEASEACTIVE xid 2 1210 <----- DHCPLEASEQUERYDONE xid 2 1211 DHCPBULKLEASEQUERY xid 3 -----> 1212 DHCPBULKLEASEQUERY xid 4 -----> 1213 <----- DHCPLEASEACTIVE xid 4 1214 <----- DHCPLEASEACTIVE xid 4 1215 <----- DHCPLEASEACTIVE xid 3 1216 <----- DHCPLEASEACTIVE xid 4 1217 <----- DHCPLEASEUNASSIGNED xid 3 1218 <----- DHCPLEASEACTIVE xid 4 1219 <----- DHCPLEASEACTIVE xid 3 1220 <----- DHCPLEASEQUERYDONE xid 3 1221 <----- DHCPLEASEACTIVE xid 4 1222 <----- DHCPLEASEQUERYDONE xid 4 1224 7.8. Closing Connections 1226 If a requestor as no additional queries to send, or doesn't know if 1227 it has additional queries to send or not, then it SHOULD close the 1228 connection after receiving the DHCPLEASEQUERYDONE message for the 1229 last outstanding query that it has sent. 1231 The requestor SHOULD close connections in a graceful manner and not 1232 an abort. The requestor SHOULD NOT assume that the manner in which 1233 the DHCP server closed a connection carries any special meaning. 1235 Typically, the requestor is the entity which will close the 1236 connection, as servers will often wait with an open connection in 1237 case the requestor has additional queries. 1239 If a server closes a connection with an exception condition, the 1240 requestor SHOULD consider as valid any completely received 1241 intermediate results, and the requestor MAY retry the Bulk Leasequery 1242 operation. 1244 8. Server Behavior 1246 8.1. Accepting Connections 1248 Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP 1249 connections. Port numbers are discussed in Section 6.3. Servers 1250 MUST be able to limit the number of concurrently accepted and active 1251 connections. The value BULK_LQ_MAX_CONNS SHOULD be the default; 1252 implementations MAY permit the value to be configurable. Connections 1253 SHOULD be accepted and, if the number of connections is over 1254 BULK_LQ_MAX_CONNS, they SHOULD be closed immediately. 1256 Servers MAY restrict Bulk Leasequery connections and 1257 DHCPBULKLEASEQUERY messages to certain requestors. Connections not 1258 from permitted requestors SHOULD be closed immediately, to avoid 1259 server connection resource exhaustion. Servers MAY restrict some 1260 requestors to certain query types. Servers MAY reply to queries that 1261 are not permitted with the DHCPLEASEQUERYDONE message with a status- 1262 code option status of NotAllowed, or MAY simply close the connection. 1264 If the TCP connection becomes blocked while the server is accepting a 1265 connection or reading a query, it SHOULD be prepared to terminate the 1266 connection after an BULK_LQ_DATA_TIMEOUT. We make this 1267 recommendation to allow servers to control the period of time they 1268 are willing to wait before abandoning an inactive connection, 1269 independent of the TCP implementations they may be using. 1271 8.2. Replying to a Bulk Leasequery 1273 If the connection becomes blocked while the server is attempting to 1274 send reply messages, the server SHOULD be prepared to terminate the 1275 TCP connection after BULK_LQ_DATA_TIMEOUT. 1277 Every Bulk Leasequery request MUST be terminated by sending a final 1278 DHCPLEASEQUERYDONE message if such a message can be sent. The 1279 DHCPLEASEQUERYDONE message MUST have a status-code option status if 1280 the termination was other than successful, and SHOULD NOT contain a 1281 status-code option status if the termination was successful. 1283 If the DHCPv4 server encounters an error during processing of the 1284 DHCPBULKLEASEQUERY message, either during initial processing or later 1285 during the message processing, it SHOULD send a DHCPLEASEQUERYDONE 1286 containing a status-code option. It MAY close the connection after 1287 this error is signaled, but that is not required. 1289 If the server does not find any bindings satisfying a query, it MUST 1290 send a DHCPLEASEQUERYDONE. It SHOULD NOT include a status-code 1291 option with a Success status unless there is a useful string to 1292 include in the status-code option. Otherwise, the server sends each 1293 binding's data in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message. 1295 The response to a DHCPBULKLEASEQUERY may involve examination of 1296 multiple DHCPv4 IP address bindings maintained by the DHCPv4 server. 1297 The Bulk Leasequery protocol does not require any ordering of the IP 1298 addresses returned in DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED 1299 messages. 1301 When responding to a DHCPBULKLEASEQUERY message, the DHCPv4 server 1302 MUST NOT send more than one message for each applicable IP address, 1303 even if the state of some of those IP addresses changes during the 1304 processing of the message. Updates to such IP address state are 1305 already handled by normal protocol processing, so no special effort 1306 is needed here. 1308 If the ciaddr, yiaddr, or siaddr is non-zero in a DHCPBULKLEASEQUERY 1309 request, the request must be terminated immediately by a 1310 DHCPLEASEQUERYDONE message with a status-code status of 1311 MalformedQuery. 1313 Any DHCPBULKLEASEQUERY which has more than one of the following 1314 primary query types specified MUST be terminated immediately by a 1315 DHCPLEASEQUERYDONE message with a status-code option status code of 1316 NotAllowed. 1318 The allowable queries in a DHCPBULKLEASEQUERY message are processed 1319 as follows. Note that the descriptions of the primary queries below 1320 must be constrained by the actions of any of the three qualifiers 1321 described subsequently as well. 1323 The following table discusses how to process the various queries. 1324 For information on how to identify the query, see the information in 1325 Section 7.2. 1327 o Query by MAC address 1329 Every IP address that has a current binding to a DHCPv4 client 1330 matching the chaddr, htype, and hlen in the DHCPBULKLEASEQUERY 1331 request MUST be returned in a DHCPLEASEACTIVE message. 1333 o Query by Client-Id 1335 Every IP address that has a current binding to a DHCPv4 client 1336 matching the client-id option in the DHCPBULKLEASEQUERY request 1337 MUST be returned in a DHCPLEASEACTIVE message. 1339 o Query by Remote-Id 1341 Every IP address that has a current binding to a DHCPv4 client 1342 matching the remote-id sub-option of the relay-agent-information 1343 option in the DHCPBULKLEASEQUERY request MUST be returned in a 1344 DHCPLEASEACTIVE message. 1346 o Query by Relay-Id 1348 Every IP address that has a current binding to a DHCPv4 client 1349 matching the relay-id sub-option of the relay-agent-information 1350 option in the DHCPBULKLEASEQUERY request MUST be returned in a 1351 DHCPLEASEACTIVE message. 1353 o Query for All Configured IP Addresses 1355 A Query for All Configured IP addresses is signaled by the 1356 absence of any other primary query. That is, if there is no 1357 value in the chaddr, hlen, htype, no client-id option, no 1358 remote-id sub-option or relay-id sub-option of the relay-agent- 1359 information option, then the request is a query for information 1360 concerning all configured IP addresses. In this case, every 1361 configured IP address that has a current binding to a DHCPv4 1362 client MUST be returned in a DHCPLEASEACTIVE message. In 1363 addition, every configured IP address that does not have a 1364 current binding to a DHCPv4 client MUST be returned in a 1365 DHCPLEASEUNASSIGNED message. 1367 In this form of query, each configured IP address MUST be 1368 returned at most one time. If the absence of qualifiers 1369 restricting the number of IP addresses returned, every 1370 configured IP address MUST be returned exactly once. 1372 There are three qualifiers that can be applied to any of the above 1373 primary queries. These qualifiers can appear individually or 1374 together in any combination, but only one of each can appear. 1376 o Query Start Time 1378 If a query-start-time option appears in the DHCPBULKLEASEQUERY 1379 request, only IP address bindings that have changed on or after the 1380 time specified in the query-start-time option should be returned. 1382 o Query End Time 1384 If a query-end-time option appears in the DHCPBULKLEASEQUERY 1385 request, only IP address bindings that have changed on or before 1386 the time specified in the query-end-time option should be returned. 1388 o VPN Id 1390 If no vpn-id option appears in the DHCPBULKLEASEQUERY, the default 1391 (global) VPN is used to satisfy the query. A vpn-id option 1392 [RFC6607] value other than the wildcard value (254) allows the 1393 requestor to specify a single VPN other than the default VPN. In 1394 addition, the vpn-id option has been extended as part of this 1395 document to allow specification of a type 254 which indicates that 1396 all configured VPN's be searched in order to satisfy the primary 1397 query. 1399 In all cases, if the information returned in a DHCPLEASEACTIVE or 1400 DHCPLEASEUNASSIGNED message is for a VPN other than the default 1401 (global) VPN, a vpn-id option MUST appear in the packet. 1403 The query-start-time and query-end-time qualifiers are used to 1404 constrain the amount of data returned by a Bulk Leasequery request by 1405 returning only IP addresses whose address bindings have changed in 1406 some way during the time window specified by the query-start-time and 1407 query-end-time. 1409 A DHCPv4 server SHOULD consider an address binding to have changed 1410 during a specified time window if either the client-last- 1411 transaction-time or the start-time-of-state of the address binding 1412 changed during that time window. 1414 The DHCPv4 server MAY return address binding data in any order, as 1415 long as binding information for any given IP address is not repeated. 1416 When all binding data for a given DHCPBULKLEASEQUERY has been sent, 1417 the DHCPv4 server MUST send a DHCPBULKLEASEQUERYDONE message. 1419 8.3. Building a Single Reply for Bulk Leasequery 1421 The DHCPv4 Leasequery [RFC4388] specification describes the initial 1422 construction of DHCPLEASEQUERY reply messages using the 1423 DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types in Section 1424 6.4.2. All of the reply messages in Bulk Leasequery are similar to 1425 the reply messages for an IP address query. Message transmission and 1426 framing for TCP is described in this document in Section 6.1. 1428 [RFC2131] and [RFC4388] specify that every response message MUST 1429 contain the server-identifier option. However, that option will be 1430 the same for every response from a particular DHCPBULKLEASEQUERY 1431 request. Thus, the DHCPv4 server MUST include the server-identifier 1432 option in the first message sent in response to a DHCPBULKLEASEQUERY. 1433 It SHOULD NOT include the server-identifier in later messages. 1435 The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based 1436 on the value of the dhcp-state option. If the dhcp-state option 1437 value is ACTIVE, then the message type is DHCPLEASEACTIVE, otherwise 1438 the message type is DHCPLEASEUNASSIGNED. 1440 In addition to the basic message construction described in [RFC4388], 1441 the following guidelines exist: 1443 1. If the dhcp-state option code appears in the dhcp-parameter- 1444 request-list, the DHCPv4 server SHOULD include a dhcp-state 1445 option whose value corresponds most closely to the state held 1446 by the DHCPv4 server for the IP address associated with this 1447 reply. If the state is ACTIVE and the message being returned 1448 is DHCPLEASEACTIVE, then the DHCPv4 server MAY choose to not 1449 send the dhcp-state option. The requestor SHOULD assume that 1450 any DHCPLEASEACTIVE message arriving without a requested dhcp- 1451 state option has a dhcp-state of ACTIVE. 1453 2. If the base-time option code appears in the dhcp-parameter- 1454 request-list, the DHCPv4 server MUST include a base-time 1455 option, which is the current time in the DHCPv4 server's 1456 context and the time from which the start-time-of-state, dhcp- 1457 lease-time, client-last-transaction-time, and other duration- 1458 style times are based upon. 1460 3. If the start-time-of-state option code appears in the dhcp- 1461 parameter-request-list, the DHCPv4 server MUST include a 1462 start-time-of-state option whose value represents the time at 1463 which the dhcp-state option's state became valid. 1465 4. If the dhcp-lease-time option code appears in the dhcp- 1466 parameter-request-list, the DHCPv4 server MUST include a dhcp- 1467 lease-time option for any state that has a time-out value 1468 associated with it. 1470 5. If the data-source option code appears in the dhcp-parameter- 1471 request-list, the DHCPv4 server MUST include the data-source 1472 option in any situation where any of the bits would be non- 1473 zero. Thus, in the absence of the data-source option, the 1474 assumption is that all of the flags were zero. 1476 6. If the client-last-transaction-time option code appears in the 1477 dhcp-parameter-request-list, The DHCPv4 server MUST include the 1478 client-last-transaction-time option in any situation where the 1479 information is available. 1481 7. If there is a dhcp-parameter-request-list in the initial 1482 DHCPBULKLEASEQUERY request, then it should be used for all of 1483 the replies generated by that request. Some options can be 1484 sent from a DHCPv4 client to the server or from the DHCPv4 1485 server to a DHCPv4 client. Option 125 is such an option. If 1486 the option code for one of these options appears in the dhcp- 1487 parameter-request-list, it SHOULD result in returning the value 1488 of the option sent by the DHCPv4 client to the server if one 1489 exists. 1491 Note that there may be other requirements for a reply to a 1492 DHCPBULKLEASEQUERY request discussed in Section 8.2. 1494 8.4. Multiple or Parallel Queries 1496 As discussed in Section 7.3, requestors may want to use a connection 1497 that has already been established when they need to make additional 1498 queries. Servers SHOULD support reading and processing multiple 1499 queries from a single connection and SHOULD allow configuration of 1500 the number of simultaneous queries it may process. A server MUST NOT 1501 read more query messages from a connection than it is prepared to 1502 process simultaneously. 1504 This SHOULD be a feature that is administratively controlled. 1505 Servers SHOULD offer configuration that limits the number of 1506 simultaneous queries permitted from any one requestor, in order to 1507 control resource use if there are multiple requestors seeking 1508 service. 1510 8.5. Closing Connections 1512 The DHCPv4 server SHOULD close connections in a graceful manner and 1513 not abort the connection. The DHCPv4 server SHOULD NOT assume that 1514 the manner in which the requestor closed a connection carries any 1515 special meaning. 1517 Typically, the DHCPv4 server will only close the connection after 1518 some form of an exception or a timeout on the connection. 1520 Using a timer to detect when a connection is idle, and then closing 1521 that connection is designed to protect the DHCPv4 server from 1522 consuming unnecessary resources. 1524 The DHCPv4 server should start a timer for BULK_LQ_DATA_TIMEOUT 1525 seconds for a particular connection after it sends a 1526 DHCPLEASEQUERYDONE message over that connection and if there is no 1527 current query outstanding for that connection. It should restart 1528 this timer if a query arrives over that connection. If the timer 1529 expires, the DHCPv4 server should close the connection. 1531 The server MUST close its end of the TCP connection if it encounters 1532 an error sending data on the connection. The server MUST close its 1533 end of the TCP connection if it finds that it has to abort an in- 1534 process request. A server aborting an in-process request SHOULD 1535 attempt to signal that to its requestors by using the QueryTerminated 1536 status code in the status-code option in a DHCPLEASEQUERYDONE 1537 message, including a message string indicating details of the reason 1538 for the abort. If the connection is closed for any reason, all of 1539 the data flows associated with any currently outstanding 1540 DHCPBULKLEASEQUERY messages will be terminated. 1542 If the server detects that the requesting end of the connection has 1543 been closed, the server MUST close its end of the connection. 1545 9. Security Considerations 1547 The "Security Considerations" section of [RFC2131] details the 1548 general threats to DHCPv4. The DHCPv4 Leasequery specification 1549 [RFC4388] describes recommendations for the Leasequery protocol, 1550 especially with regard to authentication of LEASEQUERY messages, 1551 mitigation of packet-flooding DOS attacks, and restriction to trusted 1552 requestors. 1554 The use of TCP introduces some additional concerns. Attacks that 1555 attempt to exhaust the DHCPv4 server's available TCP connection 1556 resources, such as SYN flooding attacks, can compromise the ability 1557 of legitimate requestors to receive service. Malicious requestors 1558 who succeed in establishing connections, but who then send invalid 1559 queries, partial queries, or no queries at all also can exhaust a 1560 server's pool of available connections. We recommend that servers 1561 offer configuration to limit the sources of incoming connections, 1562 that they limit the number of accepted connections and the number of 1563 in-process queries from any one connection, and that they limit the 1564 period of time during which an idle connection will be left open. 1566 There are two specific issues regarding Bulk Leasequery security that 1567 deserve explicit mention. The first is preventing information that 1568 Bulk Leasequery can provide from reaching clients who are not 1569 authorized to receive such information. The second is ensuring that 1570 authorized clients of the Bulk Leasequery capability receive accurate 1571 information from the Server (and that this information is not 1572 disrupted in transit). 1574 To prevent information leakage to unauthorized clients Servers SHOULD 1575 restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages 1576 to certain requestors, either through explicit configuration of the 1577 Server itself or by employing external network elements to provide 1578 such restrictions. In particular, the typical DHCPv4 client SHOULD 1579 NOT be allowed to receive a response to a Bulk Leasequery request, 1580 and some technique MUST exist to allow prevention of such access in 1581 any environment where Bulk Leasequery is deployed. 1583 Connections not from permitted requestors SHOULD be closed 1584 immediately, to avoid server connection resource exhaustion or 1585 alternatively, simply not be allowed to reach the server at all. 1586 Servers SHOULD have the capability to restrict certain requestors to 1587 certain query types. Servers MAY reply to queries that are not 1588 permitted with the DHCPLEASEQUERYDONE message with a status-code 1589 option status of NotAllowed, or MAY simply close the connection. 1591 To prevent disruption and malicious corruption of Bulk Leasequery 1592 data flows between the server and authorized clients these data flows 1593 SHOULD transit only secured networks. These data flows are 1594 typically infrastructure oriented, and there is usually no reason to 1595 have them flowing over networks where such attacks are likely. In 1596 the rare cases where these data flows might need to be sent through 1597 unsecured networks, they MUST sent over connections secured through 1598 means external to the DHCPv4/DHCPv6 server and its client(s) (e.g., 1599 through VPN's). 1601 Authentication for DHCP Messages [RFC3118] MUST NOT be used to 1602 attempt to secure transmission of the messages described in this 1603 document. In particular, the message framing would not be protected 1604 by using the mechanisms described in [RFC3118] (which was designed 1605 only with UDP transport in mind). 1607 10. IANA Considerations 1609 IANA is requested to assign the following new DHCPv4 option codes 1610 from the registry "BOOTP Vendor Extensions and DHCP Options" 1611 maintained at http://www.iana.org/assignments/bootp-dhcp-parameters 1613 1. An option code of TBD1 for status-code. 1615 2. An option code of TBD2 for base-time. 1617 3. An option code of TBD3 for start-time-of-state. 1619 4. An option code of TBD4 for query-start-time. 1621 5. An option code of TBD5 for query-end-time. 1623 6. An option code of TBD6 for dhcp-state. 1625 7. An option code of TBD7 for data-source. 1627 IANA is requested to assign the following new DHCP message types from 1628 the registry "DHCP Message Type 53 Values" maintained at 1629 http://www.iana.org/assignments/bootp-dhcp-parameters 1631 1. A dhcp-message-type of TBD8 for DHCPBULKLEASEQUERY. 1633 2. A dhcp-message-type of TBD9 for DHCPLEASEQUERYDONE. 1635 IANA is requested to create a new registry on the same assignments 1636 page, titled "DHCP State TBD6 Values" (where TBD6 corresponds to the 1637 assigned value of the dhcp-state option, above). This registry will 1638 have the following initial values: 1640 State 1641 ----- 1642 1 AVAILABLE 1643 2 ACTIVE 1644 3 EXPIRED 1645 4 RELEASED 1646 5 ABANDONED 1647 6 RESET 1648 7 REMOTE 1649 8 TRANSITIONING 1651 New values for this name space may only be defined by IETF Review, as 1652 described in [RFC5226]. 1654 IANA is requested to create a new registry on the same assignments 1655 page, titled "DHCP Status Code TBD1 Values" (where TBD1 corresponds 1656 to the assigned value of the status-code option, above). This 1657 registry will have the following initial values: 1659 Name status-code 1660 ---- ----------- 1661 Success 000 1662 UnspecFail 001 1663 QueryTerminated 002 1664 MalformedQuery 003 1665 NotAllowed 004 1667 New values for this name space may only be defined by IETF Review, as 1668 described in [RFC5226]. 1670 IANA is requested to revise the registry "VSS Type Options" created 1671 by [RFC6607] in the overall area "Dynamic Host Configuration Protocol 1672 (DHCP) and Bootstrap Protocol (BOOTP) Parameters". It should be 1673 revised to appear as follows. Note that the number range for 1674 "Unassigned" has changed as well as the new line for "All VPN's 1675 (wildcard)" which was added. 1677 Type VSS Information Format 1678 ------------------------------------------------------------ 1679 0 Network Virtual Terminal (NVT) ASCII VPN identifier 1680 1 RFC 2685 VPN-ID 1681 2-253 Unassigned 1682 254 All VPN's (wildcard) 1683 255 Global, default VPN 1685 11. Contributing Authors 1687 The following authors were full participants in creating this 1688 document. In order to facilitate the process of approval for this 1689 work, they graciously volunteered to have their names appear in this 1690 section instead of on the title page. 1692 Pavan Kurapati 1693 Juniper Networks Ltd. 1694 Embassy Prime Buildings, C.V.Raman Nagar 1695 Bangalore 560 093 1696 India 1698 Email: kurapati@juniper.net 1699 URI: http://www.juniper.net/ 1701 Bernie Volz 1702 Cisco Systems 1703 1414 Massachusetts Ave. 1704 Boxborough, Massachusetts 01719 1706 Phone: (978) 936-0000 1708 EMail: volz@cisco.com 1710 12. Acknowledgements 1712 This draft is a collaboration between the authors of draft-dtv-dhc- 1713 dhcpv4-bulk-leasequery-00.txt and draft-kkinnear-dhc-dhcpv4-bulk- 1714 leasequery-00.txt. Both documents acknowledged that significant text 1715 as well as important ideas were borrowed in whole or in part from the 1716 DHCPv6 Bulk Leasequery RFC, [RFC5460] written by Mark Stapp. Further 1717 suggestions and improvements were made by participants in the DHC 1718 working group, including Alfred Hoenes. 1720 13. References 1722 13.1. Normative References 1724 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1725 E. Lear, "Address Allocation for Private Internets", RFC 1918, 1726 February 1996. 1728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1729 Requirement Levels", RFC 2119, March 1997. 1731 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1732 March 1997. 1734 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1735 Extensions", RFC 2132, March 1997. 1737 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 1738 3046, January 2001. 1740 [RFC3118] Droms, R. "Authentication for DHCP Messages", RFC 3118, 1741 June 2001. 1743 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 1744 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 1746 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1747 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 1749 [RelayId] Joshi, B., Rao, D., and M. Stapp, "The DHCPv4 Relay Agent 1750 Identifier Suboption", draft-ietf-dhc-relay-id-suboption-11.txt, 1751 (work in progress) July 2012. 1753 [RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet 1754 Selection Options for DHCPv4 and DHCPv6", RFC 6607, April 2012. 1756 13.2. Informative References 1758 [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 1759 951, September 1985. 1761 [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap 1762 Protocol", RFC 1542, October 1993. 1764 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 1765 for Transmission Control Protocol (TCP) Specification Documents", 1766 RFC 4614, September 2006. 1768 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 1769 2009. 1771 Authors' Addresses 1773 Kim Kinnear 1774 Cisco Systems 1775 1414 Massachusetts Ave. 1776 Boxborough, Massachusetts 01719 1778 Phone: (978) 936-0000 1780 EMail: kkinnear@cisco.com 1782 Neil Russell 1783 BMC Software 1784 10 Maguire Rd., Bldg. 3, Ste. 320 1785 Lexington, MA 02421 1787 Phone: (781) 257-3105 1789 EMail: neil_russell@bmc.com 1791 Mark Stapp 1792 Cisco Systems 1793 1414 Massachusetts Ave. 1794 Boxborough, Massachusetts 01719 1796 Phone: (978) 936-0000 1797 EMail: mjs@cisco.com 1799 Ramakrishna Rao DTV 1800 Infosys Technologies Ltd. 1801 44 Electronics City, Hosur Road 1802 Bangalore 560 100 1803 India 1805 EMail: ramakrishnadtv@infosys.com 1806 URI: http://www.infosys.com/ 1808 Bharat Joshi 1809 Infosys Technologies Ltd. 1810 44 Electronics City, Hosur Road 1811 Bangalore 560 100 1812 India 1814 EMail: bharat_joshi@infosys.com 1815 URI: http://www.infosys.com/