idnits 2.17.1 draft-ietf-dhc-l2ra-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 13, 2009) is 5581 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) == Unused Reference: 'RFC2131' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC3118' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC3232' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 537, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3232 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group B. Joshi 3 Internet-Draft P. Kurapati 4 Expires: July 17, 2009 Infosys Technologies Ltd. 5 January 13, 2009 7 Layer 2 Relay Agent Information 8 draft-ietf-dhc-l2ra-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 17, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 In some networks, DHCP servers rely on Relay Agent Information option 48 appended by Relay Agents for IP address and other parameter 49 assignment policies. This works fine when end hosts are directly 50 connected to Relay Agents. In some network configurations, one or 51 more Layer 2 devices may reside between DHCP clients and Relay agent. 52 In these network scenarios, it is difficult to use the Relay Agent 53 Information option for IP address and other parameter assignment 54 policies effectively. So there is a need for the device that is 55 closest to the end hosts to append a Relay Agent Information option 56 in DHCP messages. These devices are typically known as Layer 2 Relay 57 Agents. 59 This document aims to describe the network scenarios where a Layer 2 60 Relay Agent is in use and also how it handles DHCP messages. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 6 67 4. Layer 2 Relay Agent in various network scenarios . . . . . . . 7 68 4.1. DHCP server and client on same subnet . . . . . . . . . . 7 69 4.1.1. Client-server interaction . . . . . . . . . . . . . . 7 70 4.1.2. Issues due to introduction of Layer 2 Relay Agent . . 9 71 4.2. Multiple DHCP server and Client on same subnet . . . . . . 9 72 4.2.1. Client-server interaction . . . . . . . . . . . . . . 10 73 4.2.2. Issues due to introduction of Layer 2 Relay Agent . . 10 74 4.3. DHCP server on another subnet with one Layer 3 Relay 75 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.3.1. Client-server interaction . . . . . . . . . . . . . . 11 77 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 13 78 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 79 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17 83 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 DHCP Relay Agents eliminate the necessity of having a DHCP server on 89 each physical network. Relay Agents populate the 'giaddr' field and 90 also append the 'Relay Agent Information' option to the DHCP 91 messages. DHCP servers use this option for IP address and other 92 parameter assignment policies. These DHCP Relay Agents are typically 93 an IP routing aware device and are referred as Layer 3 Relay Agents. 95 In some network configurations, there is a need for Layer 2 devices 96 to append the Relay Agent Information option as they are closer to 97 the end hosts. These Layer 2 devices are typically operating only as 98 bridges for the network and may not have an IPv4 address on the 99 network in question. Lacking a valid IPv4 source address, they 100 cannot relay packets directly to a DHCP server located on another 101 network. These Layer 2 devices append the Relay Agent Information 102 option and broadcast the DHCP message. A Layer 3 Relay Agent relays 103 it to the DHCP server. 105 This document provides information about where a Layer 2 Relay Agent 106 fits in and how it is used. This document also looks at various 107 network scenarios with Layer 2 Relay Agents and discusses various 108 issues caused by the introduction of Layer 2 Relay Agents. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 This document uses the following terms: 118 o "DHCP client" 120 A DHCP client is an Internet host using DHCP to obtain configuration 121 parameters such as a network address. 123 o "Layer 3 Relay Agent" 125 A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap 126 Protocol (BOOTP) and DHCP messages between clients and servers 127 residing on different subnets, per [RFC951] and [RFC1542]. 129 o "BRAS" 131 BRAS or Broadband Remote Access Server is a network element which 132 acts as an aggregation device terminating end user sessions. BRAS is 133 usually the first IP edge device in Layer 2 Access Network 134 architecture. 136 o "DHCP server" 138 A DHCP server is an Internet host that returns configuration 139 parameters to DHCP clients. 141 o "Unnumbered Interfaces" 143 An interface with no IP address associated with it. IP packets 144 generated from this interface may use a local loopback address which 145 may be shared with other unnumbered interfaces. 147 3. Need of Layer 2 Relay Agent 149 A Layer 2 device intercepts DHCP messages for the following reasons: 151 1. In some network deployments like xDSL, the subscriber aggregation 152 devices (also known as Access Concentrator or a DSLAM in case of 153 DSL) are configured to act as bridges. As these devices are 154 closest to the subscriber, they are in the best position to 155 provide a unique Relay Agent Information option to enforce 156 policies in the DHCP server. 158 2. In some network deployments, a Layer 2 device can append Relay 159 Agent Information in DHCP messages so that it can use this 160 information to forward the DHCP Replies to the specific port on 161 which the request was received. 163 3. In some networks, the Layer 2 Switch which is closest to the end 164 users, snoops the DHCP messages. These switches extract DHCP 165 Lease Information and use this information to install packet 166 filters. This helps in preventing Layer 2 and Layer 3 spoofing 167 attempts by the subscribers. A point to note here is that in 168 cases where switches maintain the Lease Information, they have to 169 intercept unicast DHCP messages as well to keep this information 170 up to date. 172 4. NOTE: Please send an email to the authors if you are aware of any 173 other functionality of Layer 2 Relay Agent. It will be helpful 174 in updating this list. This note will be removed before moving 175 this draft for IESG review. 177 4. Layer 2 Relay Agent in various network scenarios 179 This section describes the various network scenarios where a Layer 2 180 Relay Agent fits in. It also describes how it handles different DHCP 181 messages. 183 4.1. DHCP server and client on same subnet 185 In certain network configurations, a DHCP server may reside on the 186 same subnet as the DHCP clients. A Layer 2 aggregation device 187 resides between the DHCP clients and DHCP server. Following points 188 describe how this Layer 2 device handles various DHCP messages if it 189 acts as a Layer 2 Relay Agent. Figure 1 shows a typical network 190 setup. 192 +--------+ 193 | End | +--------+ | 194 | Host#1 +-----------| | | +-----------+ 195 +--------+ | Layer +-----| | | 196 | 2 | +-----| DHCP | 197 +--------+ | device | | | Server#1 | 198 | End +-----------| #1 | | +-----------+ 199 | Host#2 | +--------+ | 200 +--------+ | 201 | 202 +--------+ | 203 | End | +--------+ | 204 | Host#3 +-----------| | | 205 +--------+ | Layer +-----| 206 | 2 | | 207 +--------+ | device | | 208 | End +-----------| #2 | 209 | Host#n | +--------+ 210 +--------+ 212 Figure 1 214 4.1.1. Client-server interaction 216 The following summary of protocol message exchanges between clients 217 and DHCP servers describes how they are handled in Layer 2 Relay 218 Agent. 220 1. The client (End Host #1) broadcasts a DHCPDISCOVER message on its 221 local physical subnet. Layer 2 Relay Agent #1 intercepts this 222 message, appends the Relay Agent Information option and 223 broadcasts it to all the ports except the one on which it was 224 received. The Relay Agent Information option could be created as 225 suggested in RFC 3046 [RFC3046]. The Layer 2 Relay Agent does 226 not set the 'giaddr' field. 228 2. Layer 2 device #2 would also receive this DHCPDISCOVER message 229 from Layer 2 device #1. If it is configured as Layer 2 Relay 230 Agent, it intercepts this message but does not append another 231 Relay Agent Information option to the message. It may discard 232 this message if it is coming from an untrusted entity. 233 Otherwise, it will broadcast this on all the ports except the one 234 on which the message was received. 236 3. The DHCP server responds with a DHCPOFFER message after applying 237 its local policies. It echoes back the Relay Agent Information 238 option in the DHCPOFFER message. The DHCP server can either 239 unicast the reply to the MAC address of End Host #1 or broadcast 240 the reply. If the reply is broadcast, the Layer 2 Relay Agent 241 intercepts this message and removes the Relay Agent Information 242 option. It identifies the outgoing port using the Relay Agent 243 Information option and forwards the message to the identified 244 interface. A Layer 2 Relay Agent may be configured to intercept 245 unicast DHCP messages. In such a case, the Layer 2 Relay Agent 246 intercepts unicast DHCP messages and handles them similar to 247 broadcast messages. 249 4. The same DHCPOFFER message will be received by Layer 2 Device #2. 250 If it is configured as Layer 2 Relay Agent, it broadcasts this 251 message normally without removing the Relay Agent option since it 252 had not added the same. A Layer 2 Relay Agent uses the Relay 253 Agent Information option to find out if it had appended it to the 254 request message. 256 5. The client receives this DHCPOFFER message and it broadcasts a 257 DHCPREQUEST message. Layer 2 Relay Agent #1 handles this message 258 similar to how it handles a DHCPDISCOVER message. 260 6. The server receives the DHCPREQUEST message from the client and 261 responds with a DHCPACK/DHCPNACK message. A DHCP server may 262 unicast the DHCPACK message. The Layer 2 Relay Agent processes 263 the DHCPACK message similar to a DHCPOFFER message. 265 7. The Layer 2 Relay Agent process a DHCPNAK messages similar to a 266 DHCPACK message. 268 8. The Layer 2 Relay Agent process a DHCPDECLINE message similar to 269 a DHCPDISCOVER message. 271 9. The DHCP client can unicast some of the DHCP messages. The Layer 272 2 Relay Agent may or may not intercept these messages based on 273 internal configuration. If Layer 2 Relay Agents intercept these 274 messages, they append a Relay Agent Information option and 275 forward the message towards the DHCP server. They also intercept 276 the reply messages and remove the Relay Agent Information option 277 before forwarding them. 279 4.1.2. Issues due to introduction of Layer 2 Relay Agent 281 1. A DHCP server should be able to handle a DHCP message that 282 contains the Relay Agent Information option without 'giaddr' 283 field set in the message. Some existing DHCP server 284 implementations do not echo back the Relay Agent Information 285 option if giaddr is not set. This may lead to issues at Layer 2 286 Relay Agents as they will not be able to identify the outgoing 287 port correctly and would broadcast it to all ports. Some Layer 2 288 Relay Agents discard the reply messages if they do not find a 289 Relay Agent Information option in a DHCP reply. 291 2. There is a case when the DHCP client receives a unicast reply 292 message like DHCPACK with a Relay Agent Information option. This 293 may happen when the DHCP server unicast the DHCPACK message and 294 the Layer 2 Relay Agent is configured not to intercept unicast 295 messages. In such a case, the DHCP client can ignore the Relay 296 Agent Information option. 298 3. A DHCP server should be able to handle a unicast DHCP message 299 containing a Relay Agent Information option. Some existing DHCP 300 server implementations do not echo back the Relay Agent 301 Information option in responses to unicast messages. 303 4.2. Multiple DHCP server and Client on same subnet 305 In certain network scenarios, there could be multiple DHCP servers on 306 the same subnet. Figure 2 shows a typical network setup. 308 +--------+ 309 | End | +--------+ | 310 | Host#1 +-----------| | | +-----------+ 311 +--------+ | Layer +-----| | | 312 | 2 | +-----| DHCP | 313 +--------+ | device | | | Server#1 | 314 | End +-----------| #1 | | +-----------+ 315 | Host#2 | +--------+ | 316 +--------+ | 317 | +-----------+ 318 +--------+ | | DHCP | 319 | End | +--------+ |-----| Server #2 | 320 | Host#3 +-----------| | | | | 321 +--------+ | Layer +-----| +-----------+ 322 | 2 | | 323 +--------+ | device | 324 | End +-----------| #2 | 325 | Host#n | +--------+ 326 +--------+ 328 Figure 2 330 4.2.1. Client-server interaction 332 The message exchanges are the same as explained in 4.1.1. However, 333 due to the introduction of multiple DHCP servers the below additional 334 message exchange may happen 336 1. When Host #1 sends DHCPDISCOVER, it will be received by both the 337 DHCP Servers connected to Layer 2 Relay Agent #1 and both the 338 servers will respond with a DHCPOFFER. So instead of one 339 DHCPOFFER message, the Layer 2 Relay Agent would receive two 340 messages. The processing of DHCP messages in the Layer 2 Relay 341 Agents remains the same. 343 4.2.2. Issues due to introduction of Layer 2 Relay Agent 345 1. Layer 2 relay agents which maintain persistent state, such as 346 updating filters or client registration, must be prepared to 347 handle potentially conflicting responses from different DHCP 348 Servers. Some Layer 2 relay agents may use "the most recent DHCP 349 packet" to update this persistent state but this may not 350 necessarily reflect the actual state of the client. The above is 351 possible when two DHCP servers acknowledge the request of a DHCP 352 client with the same address but has different lease times. In 353 this case, if the relay agent selects the server reply with the 354 shorter lease time, it would expire its state possibly before the 355 client even has a chance to renew it. Therefore, Layer 2 relay 356 agents SHOULD select the longest lease time of two conflicting 357 but similar replies, by discarding replies that shorten the lease 358 time. 360 2. Other issues are the same as described in section 4.1.2. 362 4.3. DHCP server on another subnet with one Layer 3 Relay Agent 364 In certain network scenarios, there could be a Layer 3 Relay Agent 365 which relays the DHCP messages from one subnet to the DHCP server on 366 another subnet and vice versa. In typical deployments, the Access 367 Concentrator acts as Layer 2 Relay Agent and IP edge device (BRAS or 368 IP Services Switch) acts as Layer 3 Relay Agent. 370 +--------+ 371 | End | +--------+ | | 372 | Host#1 +--------| | | +-----------+ | 373 +--------+ | Layer +-----| | | | 374 | 2 | +--| Layer 3 |----| 375 +--------+ | device | | | Relay | | 376 | End +--------| #1 | | | Agent #1 | | 377 | Host#2 | +--------+ | +-----------+ | +---------+ 378 +--------+ | | | | 379 | +--| DHCP | 380 +--------+ | | | Server | 381 | End | +--------+ | | | #1 | 382 | Host#3 +--------| | | +---------+ 383 +--------+ | Layer +-----| 384 | 2 | | 385 +--------+ | device | | 386 | End +--------| #2 + 387 | Host#n | +--------+ 388 +--------+ 390 Figure 3 392 4.3.1. Client-server interaction 394 As far as DHCP message processing is concerned, the presence of Layer 395 3 Relay Agents is transparent to Layer 2 Relay Agents. So all the 396 messages are handled in the same way as defined in section 4.1.1 for 397 the Layer 2 Relay Agent. 399 The Layer 3 Relay Agents are configured to trust/untrust an entity 400 based on specific criteria (For example : VLAN/interface on which the 401 message was received). If the DHCP message coming from the client 402 has a relay agent option present, Layer 3 Relay Agent checks if it is 403 coming in on a trusted interface. If it is coming from a trusted 404 interface, it will set the 'giaddr' field to one of the local 405 interface addresses and unicasts it to the configured servers. If 406 the message is coming from an untrusted interface, the Layer 3 Relay 407 Agent discards the message. 409 Typical message processing in this scenario is given below. 411 1. When the client sends a DHCPDISCOVER message, the Layer 2 Relay 412 Agent forwards it as described in section 4.1.1. The Layer 3 413 Relay Agent receives this message and finds that it contains 414 Relay Agent Information option. It verifies whether the message 415 is from a trusted entity or not. If it is from a trusted entity 416 the Layer 2 Relay Agent populates the 'giaddr' field as it deems 417 appropriate and relays the message to the DHCP server. 419 2. The DHCP Server processes the message in the same way as 420 described in section 4.1 and will unicast the DHCPOFFER to the 421 Layer 3 Relay Agent on the address specified in the 'giaddr' 422 field. 424 3. The Layer 3 Relay Agent processes the DHCPOFFER and identifies 425 the outgoing interface. It resets the 'giaddr' field and 426 broadcasts the message on the identified outgoing interface. 428 4. The client receives the DHCPOFFER and generates a DHCPREQUEST 429 message. The Layer 2 Relay Agent processes it as described in 430 section 4.1.1. The Layer 3 Relay Agent receives the DHCPREQUEST 431 message and processes it similar to the DHCPDISCOVER message 432 described in step #1. 434 5. The DHCP Server process the DHCPREQUEST and unicasts the DHCP ACK 435 message to the layer 3 Relay Agent if the 'broadcast' flag is 436 set, or directly to the client if the 'broadcast' flag is not 437 set. If the Layer 3 Relay Agent receives this message, it will 438 process it similar to the DHCPOFFER as described in step #3. 440 6. In the case of unicast messages (For example: DHCPREQUEST in case 441 of DHCPRENEW), a Layer 3 Relay Agent may or may not intercept the 442 message. If it intercepts a unicast DHCP request message, it 443 populates the 'giaddr' field and relays the message to the DHCP 444 server. When the DHCP server sends a reply for this request 445 message, it resets the 'giaddr' field, identifies the outgoing 446 interface, and forwards the reply on the identified interface. 448 4.3.2. Issues due to introduction of Layer 2 Relay Agent 450 Though the processing of DHCP messages remains the same in Layer 2 451 Relay Agents, we see some more issues when a Layer 3 Relay Agent is 452 present to relay the DHCP messages to the DHCP server. 454 1. When a Layer 2 Relay Agent is configured to intercept unicast 455 messages as well, it appends a Relay Agent Information option 456 before forwarding the request message. A Layer 3 Relay Agent may 457 not intercept these unicast messages. Due to this, a DHCP server 458 may not echo back the Relay Agent Information option because the 459 giaddr is not populated. 461 2. Existing Layer 3 Relay Agents populate the 'giaddr' with the IP 462 address of the interface on which the request was received. This 463 helps the Layer 3 Relay Agent to identify the outgoing interface 464 for the DHCP replies. In some cases, a Layer 3 Relay Agent may 465 use unnumbered interfaces. In this case, it has to use a system 466 wide IP address to populate the 'giaddr' field. Due to this, it 467 becomes difficult to identify the correct outgoing interface for 468 the messages received from the DHCP server. In these cases, some 469 existing Layer 3 Relay Agent implementations maintain an internal 470 state for each DHCP message and use this state to identify the 471 outgoing interface. 473 3. A DHCP server uses certain parameters to differentiate the RENEW 474 and REBIND state of a client. A DHCP client unicasts a RENEW 475 request to the DHCP server, so the DHCP server sees a DHCPREQUEST 476 without 'giaddr' and Relay Agent Information option as a RENEW 477 request. On the other hand, a REBIND request is broadcast and so 478 the DHCP server expect it to contain 'giaddr' and a Relay Agent 479 Information option. If the Layer 2 Relay Agent is configured to 480 intercept unicast messages, it will append a Relay Agent 481 Information option to the unicast DHCP messages. Because of 482 this, it could be difficult for the DHCP server to differentiate 483 between a RENEWING and REBINDING state. 485 5. Acknowledgments 487 This document is the result of a discussion on DHC WG mailing list. 488 Thanks to David W. Hankins and Michael Wacker for providing inputs on 489 some of the existing implementations. Thanks to Ted Lemon, Mukund 490 Kamath, Alfred Hoenes and Stefaan De Cnodder for reviewing the draft 491 and providing valuable suggestions. 493 6. Security Consideration 495 o A Layer 2 Relay Agent should always be configured to identify a 496 trustable entity so that it appends a Relay Agent Information 497 option to a DHCP messages coming from a trustable entity and 498 forward it. If a DHCP message is received from a non-trustable 499 entity, the Layer 2 Relay Agent should discard it and may report 500 to the administrator. 502 o The introduction of Layer 2 Relay Agent does not introduce any new 503 security issues. Security issues pertaining to Relay Agents in 504 general apply to the Layer 2 Relay Agents as well. 506 7. IANA Considerations 508 This document does not introduce any new namespaces for the IANA to 509 manage and does not request any new code point assignments. 511 8. References 513 8.1. Normative Reference 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, March 1997. 518 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 519 RFC 2131, March 1997. 521 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 522 RFC 3046, January 2001. 524 [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP 525 Messages", RFC 3118, June 2001. 527 [RFC3232] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. 529 8.2. Informative Reference 531 [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", 532 RFC 951, September 1985. 534 [RFC1542] Wimer, W., "Clarifications and Extensions for the 535 Bootstrap Protocol", RFC 1542, October 1993. 537 [RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor 538 Extensions", RFC 2132, March 1997. 540 Authors' Addresses 542 Bharat Joshi 543 Infosys Technologies Ltd. 544 44 Electronics City, Hosur Road 545 Bangalore 560 100 546 India 548 Email: bharat_joshi@infosys.com 549 URI: http://www.infosys.com/ 551 Pavan Kurapati 552 Infosys Technologies Ltd. 553 44 Electronics City, Hosur Road 554 Bangalore 560 100 555 India 557 Email: pavan_kurapati@infosys.com 558 URI: http://www.infosys.com/