idnits 2.17.1 draft-ietf-dhc-l2ra-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 568. 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 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 (May 16, 2008) is 5823 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: '2' is defined on line 504, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 510, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 513, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 523, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '5') Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 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: November 17, 2008 Infosys Technologies Ltd. 5 May 16, 2008 7 Layer 2 Relay Agent Information 8 draft-ietf-dhc-l2ra-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 17, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 In some networks, DHCP servers rely on Relay Agent Information option 42 appended by Relay Agents for IP address and other parameter 43 assignment policies. This works fine when end hosts are directly 44 connected to Relay Agents. In some network configurations, one or 45 more Layer 2 devices may reside between DHCP clients and Relay agent. 46 In these network scenarios, it is difficult to use the Relay Agent 47 Information option for IP address and other parameter assignment 48 policies effectively. So there is a need for the device that is 49 closest to the end hosts to append Relay Agent Information option in 50 DHCP messages. These devices are typically known as Layer 2 Relay 51 Agents. 53 This document aims to describe the network scenarios where Layer 2 54 Relay Agent is in use and also how it handles DHCP messages. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 5 61 4. Layer 2 Relay Agent in various network scenarios . . . . . . . 6 62 4.1. DHCP server and client on same subnet . . . . . . . . . . 6 63 4.1.1. Client-server interaction . . . . . . . . . . . . . . 6 64 4.1.2. Issues due to introduction of Layer 2 Relay Agent . . 8 65 4.2. Multiple DHCP server and Client on same subnet . . . . . . 8 66 4.2.1. Client-server interaction . . . . . . . . . . . . . . 9 67 4.2.2. Issues due to introduction of Layer 2 Relay Agent . . 9 68 4.3. DHCP server on another subnet with one Layer 3 Relay 69 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.3.1. Client-server interaction . . . . . . . . . . . . . . 10 71 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 12 72 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 16 77 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 79 Intellectual Property and Copyright Statements . . . . . . . . . . 18 81 1. Introduction 83 DHCP Relay Agents eliminate the necessity of having a DHCP server on 84 each physical network. Relay Agents populate the 'giaddr' field and 85 also append the 'Relay Agent Information' option to the DHCP 86 messages. DHCP servers use this option for IP address and other 87 parameter assignment policies. These DHCP Relay Agents are typically 88 an IP routing aware device and are referred as Layer 3 Relay Agents. 90 In some network configurations, there is a need for Layer 2 devices 91 to append the Relay Agent Information option as they are closer to 92 the end hosts. These Layer 2 devices are typically operating only as 93 bridges for the network and may not have an IPv4 address on the 94 network in question. Lacking a valid IPv4 source address, they 95 cannot relay packets directly to a DHCP server located on another 96 network. These Layer 2 devices append the Relay Agent Information 97 option and broadcast the DHCP message. A Layer 3 Relay Agent relays 98 it to the DHCP server. 100 This document provides information about where a Layer 2 Relay Agent 101 fits in and how it is used. This document also looks at various 102 network scenarios with Layer 2 Relay Agent and discusses various 103 issues caused by introduction of Layer 2 Relay Agent. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [1]. 111 This document uses the following terms: 113 o "DHCP client" 115 A DHCP client is an Internet host using DHCP to obtain configuration 116 parameters such as a network address. 118 o "Layer 3 Relay Agent" 120 A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap 121 Protocol (BOOTP) and DHCP messages between clients and servers 122 residing on different subnets, per RFC951 [6] and RFC1542[7]. 124 o "DHCP server" 126 A DHCP server is an Internet host that returns configuration 127 parameters to DHCP clients. 129 o "Unnumbered Interfaces" 131 An interface with no IP address associated with it. IP packets 132 received on this interface will be processed like any other numbered 133 IP interface. It may use a local IP address while generating IP 134 packets. 136 3. Need of Layer 2 Relay Agent 138 A Layer 2 device intercepts DHCP messages for following reasons: 140 1. In some network deployments like xDSL, the subscriber aggregation 141 devices (also known as Access Concentrator or a DSLAM in case of 142 DSL) are configured to act as bridges. As these devices are 143 closest to the subscriber, they are in the best position to 144 provide a unique Relay Agent Information option to enforce 145 policies in DHCP server. 147 2. In some network deployments, a Layer 2 device can append Relay 148 Agent Information in DHCP messages so that it can use this 149 information to forward the DHCP Replies to the specific port on 150 which request was received. 152 3. In some networks, the Layer 2 Switch which is closest to the end 153 users, snoops the DHCP messages. These switches extract DHCP 154 Lease Information and use this information to install packet 155 filters. This helps in preventing the Layer 2 and Layer 3 156 spoofing attempts by the subscribers. A point to note here is 157 that in cases where switches maintain the Lease Information, they 158 have to intercept unicast DHCP messages as well to keep this 159 information up to date. 161 4. NOTE: Please send an email to the authors if you are aware of any 162 other functionality of Layer 2 Relay Agent. It will be helpful 163 in updating this list. This note will be removed before moving 164 it for IESG review. 166 4. Layer 2 Relay Agent in various network scenarios 168 This section describes the various network scenarios where a Layer 2 169 Relay Agent fits in. It also describes how it handles different DHCP 170 messages. 172 4.1. DHCP server and client on same subnet 174 In certain network configurations, DHCP server may reside on the same 175 subnet as the DHCP clients. A Layer 2 aggregation device resides 176 between the DHCP clients and DHCP server. Following points describe 177 how this Layer 2 device handles various DHCP messages if it acts as a 178 Layer 2 Relay Agent. Figure #1 shows a typical network setup. 180 +--------+ 181 | End | +--------+ | 182 | Host#1 +-----------| | | +-----------+ 183 +--------+ | Layer +-----| | | 184 | 2 | +-----| DHCP | 185 +--------+ | device | | | Server#1 | 186 | End +-----------| #1 | | +-----------+ 187 | Host#2 | +--------+ | 188 +--------+ | 189 | 190 +--------+ | 191 | End | +--------+ | 192 | Host#3 +-----------| | | 193 +--------+ | Layer +-----| 194 | 2 | | 195 +--------+ | device | | 196 | End +-----------| #2 | 197 | Host#n | +--------+ 198 +--------+ 200 Figure 1 202 4.1.1. Client-server interaction 204 The following summary of protocol message exchanges between clients 205 and DHCP servers describes how they are handled in Layer 2 Relay 206 Agent. 208 1. The client [End Host #1] broadcasts a DHCPDISCOVER message on its 209 local physical subnet. Layer 2 Relay Agent [#1] intercepts this 210 message, appends the Relay Agent Information option and 211 broadcasts it to all the ports except on which it was received. 213 Relay Agent Information option could be created as suggested in 214 RFC 3046[3]. Layer 2 Relay Agent does not set the 'giaddr' 215 field. 217 2. Layer 2 device [#2] would also receive this DHCPDISCOVER message 218 from Layer 2 device [#1]. If it is configured as Layer 2 Relay 219 Agent, it intercepts this message but does not append another 220 Relay Agent Information option to the message. It may discard 221 this message if it is coming from an untrusted entity. 222 Otherwise, it will broadcast this on all the ports except on 223 which the message was received. 225 3. Server responds with a DHCPOFFER message after applying its local 226 policies. DHCP server echoes back the Relay Agent Information 227 option in the DHCPOFFER message. DHCP server can either unicast 228 the reply to MAC address of End Host #1 or broadcast the reply. 229 In both the cases, the Layer 2 Relay Agent intercepts this 230 message and removes the Relay Agent Information option. It 231 identifies the outgoing port using Relay Agent Information option 232 and forwards to the identified interface. 234 4. Same DHCPOFFER message will be received by the other Layer 2 235 Device [#2]. If it is configured as Layer 2 Relay Agent, it 236 broadcasts this message normally without removing the Relay Agent 237 option since it had not added the same. A Layer 2 Relay Agent 238 uses the Relay Agent Information option to find out if it had 239 appended it to the request message. 241 5. The client receives this DHCPOFFER message and it broadcasts a 242 DHCPREQUEST message that contains the 'server identifier' option 243 to indicate the server it has selected. Layer 2 Relay Agent [#1] 244 handles this message similar to how it handles DHCPDISCOVER 245 message. 247 6. The server receives the DHCPREQUEST message from the client and 248 responds with a DHCPACK message containing the configuration 249 parameters for the requesting client. A DHCP server may unicast 250 the DHCPACK message if the broadcast bit in the DHCPREQUEST 251 message is not set. DHCP server would echo back the Relay Agent 252 Information option in the reply message. A Layer 2 Relay Agent 253 may intercept this unicast message and process it similar to the 254 DHCPOFFER message. 256 7. A server that is unable to satisfy the DHCPREQUEST message, 257 responds with DHCPNACK. Layer 2 Relay Agent process this similar 258 to DHCPACK message. 260 8. The client receives the DHCPACK message with configuration 261 parameters. If client detects that the address is already in 262 use, it sends a DHCPDECLINE message to the server. Layer 2 Relay 263 Agent process this message similar to DHCPDISCOVER message. 265 9. When client knows the address of a DHCP server, it may unicast 266 DHCPDISCOVER, DHCPREQUEST messages to the server. DHCP clients 267 unicast the DHCP messages like DHCPRELEASE and DHCPREQUEST when 268 renewing the lease to the DHCP server. Layer 2 Relay Agent may 269 or may not intercept these messages based on internal 270 configuration. If Layer 2 Relay Agents intercept these messages, 271 they append Relay Agent Information option and forward it towards 272 the DHCP server. They also intercept the reply messages and 273 remove Relay Agent Information option before forwarding them. 275 4.1.2. Issues due to introduction of Layer 2 Relay Agent 277 1. A DHCP server should be able to handle a DHCP message that 278 contains the Relay Agent Information option without 'giaddr' 279 field set in the message. Some existing DHCP server 280 implementations do not echo back the Relay Agent Information 281 option if giaddr is not set. This may lead to issues at Layer 2 282 Relay Agents as they will not be able to identify the outgoing 283 port correctly and would broadcast it to all ports. Some Layer 2 284 Relay Agents discard the reply messages if they do not find a 285 Relay Agent Information option in a DHCP reply. 287 2. A DHCP server should be able to handle a unicast DHCP message 288 containing Relay Agent Information option. Some existing DHCP 289 server implementations do not echo back the Relay Agent 290 Information option in DHCP reply messages. 292 4.2. Multiple DHCP server and Client on same subnet 294 In certain network scenarios, there could be multiple DHCP server on 295 the same subnet. Figure #2 shows a typical network setup. 297 +--------+ 298 | End | +--------+ | 299 | Host#1 +-----------| | | +-----------+ 300 +--------+ | Layer +-----| | | 301 | 2 | +-----| DHCP | 302 +--------+ | device | | | Server#1 | 303 | End +-----------| #1 | | +-----------+ 304 | Host#2 | +--------+ | 305 +--------+ | 306 | +-----------+ 307 +--------+ | | DHCP | 308 | End | +--------+ |-----| Server #2 | 309 | Host#3 +-----------| | | | | 310 +--------+ | Layer +-----| +-----------+ 311 | 2 | | 312 +--------+ | device | 313 | End +-----------| #2 | 314 | Host#n | +--------+ 315 +--------+ 317 Figure 2 319 4.2.1. Client-server interaction 321 The message exchange are same as explained in 4.1.1. However, due to 322 introduction of multiple DHCP servers the below additional message 323 exchanges may happen 325 1. When Host [#1] sends DHCPDISCOVER, it will be received by both 326 the DHCP Servers connected to Layer 2 Relay Agent #1 and both the 327 servers will respond with a DHCPOFFER. So instead of one 328 DHCPOFFER message, Layer 2 Relay Agent would receive two 329 messages. Processing of DHCP messages in the Layer 2 Relay Agent 330 remains the same. 332 4.2.2. Issues due to introduction of Layer 2 Relay Agent 334 1. Layer 2 relay agents which maintain persistent state, such as 335 updating filters or client registration, must be prepared to 336 handle potentially conflicting responses from different DHCP 337 Servers. Some Layer 2 relay agents may use "the most recent DHCP 338 packet" to update this persistent state but this may not 339 necessarily reflect the actual state of the client. The above is 340 possible when two DHCP servers ack the request of a DHCP client 341 with same address but has different lease times. In this case, 342 if the relay agent selects the server reply which has a shorter 343 lease time, it would expire its state possibly before the client 344 even has a chance to renew it. Therefore, Layer 2 relay agents 345 SHOULD select the longest lease time of two conflicting but 346 similar replies, by discarding replies that shorten the lease 347 time. 349 2. Other issues are same as described in section 4.1.2. 351 4.3. DHCP server on another subnet with one Layer 3 Relay Agent 353 In certain network scenarios, there could be a Layer 3 Relay Agent 354 which relays the DHCP messages from one subnet to DHCP server on 355 another subnet and vice versa. In typical deployments, Access 356 Concentrator acts as Layer 2 Relay Agent and IP edge device (BRAS or 357 IP Services Switch) acts as Layer 3 Relay Agent. 359 +--------+ 360 | End | +--------+ | | 361 | Host#1 +--------| | | +-----------+ | 362 +--------+ | Layer +-----| | | | 363 | 2 | +--| Layer 3 |----| 364 +--------+ | device | | | Relay | | 365 | End +--------| #1 | | | Agent #1 | | 366 | Host#2 | +--------+ | +-----------+ | +---------+ 367 +--------+ | | | | 368 | +--| DHCP | 369 +--------+ | | | Server | 370 | End | +--------+ | | | #1 | 371 | Host#3 +--------| | | +---------+ 372 +--------+ | Layer +-----| 373 | 2 | | 374 +--------+ | device | | 375 | End +--------| #2 + 376 | Host#n | +--------+ 377 +--------+ 379 Figure 3 381 4.3.1. Client-server interaction 383 As far as DHCP message processing is concerned, the presence of Layer 384 3 Relay Agent is transparent to Layer 2 Relay Agent. So all the 385 messages are handled in the same way as defined in section 4.1.1 by 386 Layer 2 Relay Agent. 388 Layer 3 Relay Agent are configured to trust/untrust an entity based 389 on a specific criteria (For example : VLAN/interface on which the 390 message was received). If the DHCP messages coming from the client 391 has a relay agent option present, Layer 3 Relay Agent checks if it is 392 coming on a trusted interface. If it is coming from a trusted 393 interface, it will set the 'giaddr' with one of the local interface 394 address and unicasts it to the configured servers. If the message is 395 coming from an untrusted interface Layer 3 Relay Agent discards the 396 message. 398 Typical message processing in this scenario is given below. 400 1. When client sends a DHCPDISCOVER message, Layer 2 Relay Agent 401 forwards it as described in section 4.1.1. Layer 3 Relay Agent 402 receives this message and finds that it contains Relay Agent 403 Information option. It verifies whether the message is from a 404 trusted entity or not. If it is from trusted entity it populates 405 the 'giaddr' as it deems appropriate and relay it to the DHCP 406 server. 408 2. DHCP Server process the message in the same way as described in 409 section 4.1 and will unicast the DHCPOFFER to Layer 3 Relay Agent 410 on the address specified in 'giaddr' field. 412 3. Layer 3 Relay Agent process the DHCPOFFER and identifies the 413 outgoing interface. It resets the giaddr and broadcasts the 414 message on the identified outgoing interface 416 4. Clients receive DHCPOFFER and generate DHCPREQUEST message. 417 Layer 2 Relay Agent process it as described in section 4.1.1. 418 Layer 3 Relay Agent receives the DHCPREQUEST message and process 419 it similar to the DHCPDISCOVER message described in step #1. 421 5. DHCP Server process the DHCPREQUEST and unicasts the DHCP ACK 422 message to layer 3 Relay Agent if 'broadcast' flag is set or 423 directly to the client if 'broadcast' flag is not set. If Layer 424 3 Relay Agent receives this message, it will process it similar 425 to DHCPOFFER as described in step #3. 427 6. In case of unicast messages [For example: DHCPREQUEST in case of 428 DHCPRENEW], a Layer 3 Relay Agent may or may not intercept the 429 message. If it intercepts a unicast DHCP request message, it 430 populates the 'giaddr' and relay it to the DHCP server. When 431 DHCP server sends a reply for this request message, it resets the 432 'giaddr' field, identifies outgoing interface and forwards the 433 reply on the identified interface. 435 4.3.2. Issues due to introduction of Layer 2 Relay Agent 437 Though the processing of DHCP messages remain the same in Layer 2 438 Relay Agent, we see some more issues when a Layer 3 Relay Agent is 439 present to relay the DHCP messages to the DHCP server. 441 1. When a Layer 2 Relay Agent is configured to intercept unicast 442 messages as well, it appends Relay Agent Information option 443 before forwarding them. A Layer 3 Relay Agent may not intercept 444 these unicast messages. Due to this, a DHCP server may not echo 445 back the Relay Agent Information option because the giaddr is not 446 populated. 448 2. Existing Layer 3 Relay Agents populate the 'giaddr' with the IP 449 address of the interface on which the request was received. This 450 helps Layer 3 Relay Agent to identify the outgoing interface for 451 the DHCP replies. In some cases, a Layer 3 Relay Agent may use 452 unnumbered interfaces. In this case, it has to use a system wide 453 IP address to populate the 'giaddr' field. Due to this, it 454 becomes difficult to identify the correct outgoing interface for 455 the messages received from the DHCP server. In these cases, some 456 existing Layer 3 Relay Agent implementations maintain an internal 457 state for each DHCP messages and use this state to identify the 458 outgoing interface. 460 3. DHCP server uses certain parameters to differentiate the RENEW 461 and REBIND state of a client. A DHCP client unicasts a RENEW 462 request to the DHCP server, so DHCP server sees a DHCPREQUEST 463 without 'giaddr' and Relay Agent Information option as RENEW 464 request. While a REBIND request is broadcast and so DHCP server 465 expect it to contain 'giaddr' and Relay Agent Information option. 466 If Layer 2 Relay Agent is configured to intercept unicast 467 messages, it will append Relay Agent Information option to the 468 unicast DHCP messages. Because of this, it could be difficult 469 for DHCP server to differentiate between a RENEWING and REBINDING 470 state. 472 5. Acknowledgments 474 This document is the result of a discussion on DHC WG mailing list. 475 Thanks to David W. Hankins and Michael Wacker for providing inputs on 476 some of the existing implementations. Thanks to Stefaan.De.Cnodder 477 and Mukund Kamath for reviewing the draft and providing valuable 478 suggestions 480 6. Security Consideration 482 o A Layer 2 Relay Agent should always be configured to identify a 483 trustable entity so that it appends Relay Agent Information option 484 to DHCP messages coming from a trustable entity and forward it. 485 If a DHCP message is received from a non-trustable entity, it 486 should discard it and may report to the administrator. 488 o Introduction of Layer 2 Relay Agent does not introduce any new 489 security issue. Security issues pertaining to Relay Agents in 490 general applies to Layer 2 Relay Agents as well. 492 7. IANA Considerations 494 This document does not introduce any new namespaces for the IANA to 495 manage. 497 8. References 499 8.1. Normative Reference 501 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 502 Levels", BCP 14, RFC 2119, March 1997. 504 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 505 March 1997. 507 [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 508 January 2001. 510 [4] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", 511 RFC 3118, June 2001. 513 [5] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. 515 8.2. Informative Reference 517 [6] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, 518 September 1985. 520 [7] Wimer, W., "Clarifications and Extensions for the Bootstrap 521 Protocol", RFC 1542, October 1993. 523 [8] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor 524 Extensions", RFC 2132, March 1997. 526 Authors' Addresses 528 Bharat Joshi 529 Infosys Technologies Ltd. 530 44 Electronics City, Hosur Road 531 Bangalore 560 100 532 India 534 Email: bharat_joshi@infosys.com 535 URI: http://www.infosys.com/ 537 Pavan Kurapati 538 Infosys Technologies Ltd. 539 44 Electronics City, Hosur Road 540 Bangalore 560 100 541 India 543 Email: pavan_kurapati@infosys.com 544 URI: http://www.infosys.com/ 546 Intellectual Property Statement 548 The IETF takes no position regarding the validity or scope of any 549 Intellectual Property Rights or other rights that might be claimed to 550 pertain to the implementation or use of the technology described in 551 this document or the extent to which any license under such rights 552 might or might not be available; nor does it represent that it has 553 made any independent effort to identify any such rights. Information 554 on the procedures with respect to rights in RFC documents can be 555 found in BCP 78 and BCP 79. 557 Copies of IPR disclosures made to the IETF Secretariat and any 558 assurances of licenses to be made available, or the result of an 559 attempt made to obtain a general license or permission for the use of 560 such proprietary rights by implementers or users of this 561 specification can be obtained from the IETF on-line IPR repository at 562 http://www.ietf.org/ipr. 564 The IETF invites any interested party to bring to its attention any 565 copyrights, patents or patent applications, or other proprietary 566 rights that may cover technology that may be required to implement 567 this standard. Please address the information to the IETF at 568 ietf-ipr@ietf.org. 570 Disclaimer of Validity 572 This document and the information contained herein are provided on an 573 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 574 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 575 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 576 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 577 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 578 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 580 Copyright Statement 582 Copyright (C) The IETF Trust (2008). This document is subject to the 583 rights, licenses and restrictions contained in BCP 78, and except as 584 set forth therein, the authors retain all their rights. 586 Acknowledgment 588 Funding for the RFC Editor function is currently provided by the 589 Internet Society.