idnits 2.17.1 draft-ietf-dhc-l2ra-02.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 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 579. 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 (October 1, 2008) is 5686 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 499, but no explicit reference was found in the text == Unused Reference: 'RFC3118' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC3232' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 518, 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 (==), 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: April 4, 2009 Infosys Technologies Ltd. 5 October 1, 2008 7 Layer 2 Relay Agent Information 8 draft-ietf-dhc-l2ra-02.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 April 4, 2009. 35 Abstract 37 In some networks, DHCP servers rely on Relay Agent Information option 38 appended by Relay Agents for IP address and other parameter 39 assignment policies. This works fine when end hosts are directly 40 connected to Relay Agents. In some network configurations, one or 41 more Layer 2 devices may reside between DHCP clients and Relay agent. 42 In these network scenarios, it is difficult to use the Relay Agent 43 Information option for IP address and other parameter assignment 44 policies effectively. So there is a need for the device that is 45 closest to the end hosts to append Relay Agent Information option in 46 DHCP messages. These devices are typically known as Layer 2 Relay 47 Agents. 49 This document aims to describe the network scenarios where Layer 2 50 Relay Agent is in use and also how it handles DHCP messages. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 6 57 4. Layer 2 Relay Agent in various network scenarios . . . . . . . 7 58 4.1. DHCP server and client on same subnet . . . . . . . . . . 7 59 4.1.1. Client-server interaction . . . . . . . . . . . . . . 7 60 4.1.2. Issues due to introduction of Layer 2 Relay Agent . . 9 61 4.2. Multiple DHCP server and Client on same subnet . . . . . . 9 62 4.2.1. Client-server interaction . . . . . . . . . . . . . . 10 63 4.2.2. Issues due to introduction of Layer 2 Relay Agent . . 10 64 4.3. DHCP server on another subnet with one Layer 3 Relay 65 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3.1. Client-server interaction . . . . . . . . . . . . . . 11 67 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 13 68 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 69 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17 73 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 75 Intellectual Property and Copyright Statements . . . . . . . . . . 19 77 1. Introduction 79 DHCP Relay Agents eliminate the necessity of having a DHCP server on 80 each physical network. Relay Agents populate the 'giaddr' field and 81 also append the 'Relay Agent Information' option to the DHCP 82 messages. DHCP servers use this option for IP address and other 83 parameter assignment policies. These DHCP Relay Agents are typically 84 an IP routing aware device and are referred as Layer 3 Relay Agents. 86 In some network configurations, there is a need for Layer 2 devices 87 to append the Relay Agent Information option as they are closer to 88 the end hosts. These Layer 2 devices are typically operating only as 89 bridges for the network and may not have an IPv4 address on the 90 network in question. Lacking a valid IPv4 source address, they 91 cannot relay packets directly to a DHCP server located on another 92 network. These Layer 2 devices append the Relay Agent Information 93 option and broadcast the DHCP message. A Layer 3 Relay Agent relays 94 it to the DHCP server. 96 This document provides information about where a Layer 2 Relay Agent 97 fits in and how it is used. This document also looks at various 98 network scenarios with Layer 2 Relay Agent and discusses various 99 issues caused by introduction of Layer 2 Relay Agent. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 This document uses the following terms: 109 o "DHCP client" 111 A DHCP client is an Internet host using DHCP to obtain configuration 112 parameters such as a network address. 114 o "Layer 3 Relay Agent" 116 A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap 117 Protocol (BOOTP) and DHCP messages between clients and servers 118 residing on different subnets, per RFC951 [RFC951] and 119 RFC1542[RFC1542]. 121 o "DHCP server" 123 A DHCP server is an Internet host that returns configuration 124 parameters to DHCP clients. 126 o "Unnumbered Interfaces" 128 An interface with no IP address associated with it. IP packets 129 received on this interface will be processed like any other numbered 130 IP interface. It may use a local IP address while generating IP 131 packets. 133 3. Need of Layer 2 Relay Agent 135 A Layer 2 device intercepts DHCP messages for following reasons: 137 1. In some network deployments like xDSL, the subscriber aggregation 138 devices (also known as Access Concentrator or a DSLAM in case of 139 DSL) are configured to act as bridges. As these devices are 140 closest to the subscriber, they are in the best position to 141 provide a unique Relay Agent Information option to enforce 142 policies in DHCP server. 144 2. In some network deployments, a Layer 2 device can append Relay 145 Agent Information in DHCP messages so that it can use this 146 information to forward the DHCP Replies to the specific port on 147 which request was received. 149 3. In some networks, the Layer 2 Switch which is closest to the end 150 users, snoops the DHCP messages. These switches extract DHCP 151 Lease Information and use this information to install packet 152 filters. This helps in preventing the Layer 2 and Layer 3 153 spoofing attempts by the subscribers. A point to note here is 154 that in cases where switches maintain the Lease Information, they 155 have to intercept unicast DHCP messages as well to keep this 156 information up to date. 158 4. NOTE: Please send an email to the authors if you are aware of any 159 other functionality of Layer 2 Relay Agent. It will be helpful 160 in updating this list. This note will be removed before moving 161 it for IESG review. 163 4. Layer 2 Relay Agent in various network scenarios 165 This section describes the various network scenarios where a Layer 2 166 Relay Agent fits in. It also describes how it handles different DHCP 167 messages. 169 4.1. DHCP server and client on same subnet 171 In certain network configurations, DHCP server may reside on the same 172 subnet as the DHCP clients. A Layer 2 aggregation device resides 173 between the DHCP clients and DHCP server. Following points describe 174 how this Layer 2 device handles various DHCP messages if it acts as a 175 Layer 2 Relay Agent. Figure #1 shows a typical network setup. 177 +--------+ 178 | End | +--------+ | 179 | Host#1 +-----------| | | +-----------+ 180 +--------+ | Layer +-----| | | 181 | 2 | +-----| DHCP | 182 +--------+ | device | | | Server#1 | 183 | End +-----------| #1 | | +-----------+ 184 | Host#2 | +--------+ | 185 +--------+ | 186 | 187 +--------+ | 188 | End | +--------+ | 189 | Host#3 +-----------| | | 190 +--------+ | Layer +-----| 191 | 2 | | 192 +--------+ | device | | 193 | End +-----------| #2 | 194 | Host#n | +--------+ 195 +--------+ 197 Figure 1 199 4.1.1. Client-server interaction 201 The following summary of protocol message exchanges between clients 202 and DHCP servers describes how they are handled in Layer 2 Relay 203 Agent. 205 1. The client [End Host #1] broadcasts a DHCPDISCOVER message on its 206 local physical subnet. Layer 2 Relay Agent [#1] intercepts this 207 message, appends the Relay Agent Information option and 208 broadcasts it to all the ports except on which it was received. 210 Relay Agent Information option could be created as suggested in 211 RFC 3046[RFC3046]. Layer 2 Relay Agent does not set the 'giaddr' 212 field. 214 2. Layer 2 device [#2] would also receive this DHCPDISCOVER message 215 from Layer 2 device [#1]. If it is configured as Layer 2 Relay 216 Agent, it intercepts this message but does not append another 217 Relay Agent Information option to the message. It may discard 218 this message if it is coming from an untrusted entity. 219 Otherwise, it will broadcast this on all the ports except on 220 which the message was received. 222 3. Server responds with a DHCPOFFER message after applying its local 223 policies. DHCP server echoes back the Relay Agent Information 224 option in the DHCPOFFER message. DHCP server can either unicast 225 the reply to MAC address of End Host #1 or broadcast the reply. 226 If reply is broadcast, the Layer 2 Relay Agent intercepts this 227 message and removes the Relay Agent Information option. It 228 identifies the outgoing port using Relay Agent Information option 229 and forwards to the identified interface. A Layer 2 Relay Agent 230 may be configured to intercept unicast DHCP messages. In such a 231 case, Layer 2 Relay Agent intercepts unicast DHCP messages and 232 handle them similar to broadcast messages. 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. Layer 2 Relay Agent [#1] handles this 243 message similar to how it handles a DHCPDISCOVER message. 245 6. The server receives the DHCPREQUEST message from the client and 246 responds with a DHCPACK/DHCPNACK message A DHCP server may 247 unicast the DHCPACK message. Layer 2 Relay Agent processes the 248 DHCPACK message similar to DHCPOFFER message. 250 7. Layer 2 Relay Agent process a DHCPNAK messages similar to DHCPACK 251 message. 253 8. Layer 2 Relay Agent process a DHCPDECLINE message similar to 254 DHCPDISCOVER message. 256 9. DHCP client can unicast some of the DHCP messages. Layer 2 Relay 257 Agent may or may not intercept these messages based on internal 258 configuration. If Layer 2 Relay Agents intercept these messages, 259 they append Relay Agent Information option and forward it towards 260 the DHCP server. They also intercept the reply messages and 261 remove Relay Agent Information option before forwarding them. 263 4.1.2. Issues due to introduction of Layer 2 Relay Agent 265 1. A DHCP server should be able to handle a DHCP message that 266 contains the Relay Agent Information option without 'giaddr' 267 field set in the message. Some existing DHCP server 268 implementations do not echo back the Relay Agent Information 269 option if giaddr is not set. This may lead to issues at Layer 2 270 Relay Agents as they will not be able to identify the outgoing 271 port correctly and would broadcast it to all ports. Some Layer 2 272 Relay Agents discard the reply messages if they do not find a 273 Relay Agent Information option in a DHCP reply. 275 2. There is a case when DHCP clients may receive unicast reply 276 messages like DHCPACK with Relay Agent Information option. This 277 may happen when DHCP server unicast the DHCPACK message and Layer 278 2 Relay Agent is configured not to intercept unicast messages. 279 In such a case, DHCP client can ignore the Relay Agent 280 Information option. 282 3. A DHCP server should be able to handle a unicast DHCP message 283 containing Relay Agent Information option. Some existing DHCP 284 server implementations do not echo back the Relay Agent 285 Information option in responses to unicast messages. 287 4.2. Multiple DHCP server and Client on same subnet 289 In certain network scenarios, there could be multiple DHCP server on 290 the same subnet. Figure #2 shows a typical network setup. 292 +--------+ 293 | End | +--------+ | 294 | Host#1 +-----------| | | +-----------+ 295 +--------+ | Layer +-----| | | 296 | 2 | +-----| DHCP | 297 +--------+ | device | | | Server#1 | 298 | End +-----------| #1 | | +-----------+ 299 | Host#2 | +--------+ | 300 +--------+ | 301 | +-----------+ 302 +--------+ | | DHCP | 303 | End | +--------+ |-----| Server #2 | 304 | Host#3 +-----------| | | | | 305 +--------+ | Layer +-----| +-----------+ 306 | 2 | | 307 +--------+ | device | 308 | End +-----------| #2 | 309 | Host#n | +--------+ 310 +--------+ 312 Figure 2 314 4.2.1. Client-server interaction 316 The message exchange are same as explained in 4.1.1. However, due to 317 introduction of multiple DHCP servers the below additional message 318 exchanges may happen 320 1. When Host [#1] sends DHCPDISCOVER, it will be received by both 321 the DHCP Servers connected to Layer 2 Relay Agent #1 and both the 322 servers will respond with a DHCPOFFER. So instead of one 323 DHCPOFFER message, Layer 2 Relay Agent would receive two 324 messages. Processing of DHCP messages in the Layer 2 Relay Agent 325 remains the same. 327 4.2.2. Issues due to introduction of Layer 2 Relay Agent 329 1. Layer 2 relay agents which maintain persistent state, such as 330 updating filters or client registration, must be prepared to 331 handle potentially conflicting responses from different DHCP 332 Servers. Some Layer 2 relay agents may use "the most recent DHCP 333 packet" to update this persistent state but this may not 334 necessarily reflect the actual state of the client. The above is 335 possible when two DHCP servers ack the request of a DHCP client 336 with same address but has different lease times. In this case, 337 if the relay agent selects the server reply which has a shorter 338 lease time, it would expire its state possibly before the client 339 even has a chance to renew it. Therefore, Layer 2 relay agents 340 SHOULD select the longest lease time of two conflicting but 341 similar replies, by discarding replies that shorten the lease 342 time. 344 2. Other issues are same as described in section 4.1.2. 346 4.3. DHCP server on another subnet with one Layer 3 Relay Agent 348 In certain network scenarios, there could be a Layer 3 Relay Agent 349 which relays the DHCP messages from one subnet to DHCP server on 350 another subnet and vice versa. In typical deployments, Access 351 Concentrator acts as Layer 2 Relay Agent and IP edge device (BRAS or 352 IP Services Switch) acts as Layer 3 Relay Agent. 354 +--------+ 355 | End | +--------+ | | 356 | Host#1 +--------| | | +-----------+ | 357 +--------+ | Layer +-----| | | | 358 | 2 | +--| Layer 3 |----| 359 +--------+ | device | | | Relay | | 360 | End +--------| #1 | | | Agent #1 | | 361 | Host#2 | +--------+ | +-----------+ | +---------+ 362 +--------+ | | | | 363 | +--| DHCP | 364 +--------+ | | | Server | 365 | End | +--------+ | | | #1 | 366 | Host#3 +--------| | | +---------+ 367 +--------+ | Layer +-----| 368 | 2 | | 369 +--------+ | device | | 370 | End +--------| #2 + 371 | Host#n | +--------+ 372 +--------+ 374 Figure 3 376 4.3.1. Client-server interaction 378 As far as DHCP message processing is concerned, the presence of Layer 379 3 Relay Agent is transparent to Layer 2 Relay Agent. So all the 380 messages are handled in the same way as defined in section 4.1.1 by 381 Layer 2 Relay Agent. 383 Layer 3 Relay Agent are configured to trust/untrust an entity based 384 on a specific criteria (For example : VLAN/interface on which the 385 message was received). If the DHCP messages coming from the client 386 has a relay agent option present, Layer 3 Relay Agent checks if it is 387 coming on a trusted interface. If it is coming from a trusted 388 interface, it will set the 'giaddr' with one of the local interface 389 address and unicasts it to the configured servers. If the message is 390 coming from an untrusted interface Layer 3 Relay Agent discards the 391 message. 393 Typical message processing in this scenario is given below. 395 1. When client sends a DHCPDISCOVER message, Layer 2 Relay Agent 396 forwards it as described in section 4.1.1. Layer 3 Relay Agent 397 receives this message and finds that it contains Relay Agent 398 Information option. It verifies whether the message is from a 399 trusted entity or not. If it is from trusted entity it populates 400 the 'giaddr' as it deems appropriate and relay it to the DHCP 401 server. 403 2. DHCP Server process the message in the same way as described in 404 section 4.1 and will unicast the DHCPOFFER to Layer 3 Relay Agent 405 on the address specified in 'giaddr' field. 407 3. Layer 3 Relay Agent process the DHCPOFFER and identifies the 408 outgoing interface. It resets the giaddr and broadcasts the 409 message on the identified outgoing interface 411 4. Clients receive DHCPOFFER and generate DHCPREQUEST message. 412 Layer 2 Relay Agent process it as described in section 4.1.1. 413 Layer 3 Relay Agent receives the DHCPREQUEST message and process 414 it similar to the DHCPDISCOVER message described in step #1. 416 5. DHCP Server process the DHCPREQUEST and unicasts the DHCP ACK 417 message to layer 3 Relay Agent if 'broadcast' flag is set or 418 directly to the client if 'broadcast' flag is not set. If Layer 419 3 Relay Agent receives this message, it will process it similar 420 to DHCPOFFER as described in step #3. 422 6. In case of unicast messages [For example: DHCPREQUEST in case of 423 DHCPRENEW], a Layer 3 Relay Agent may or may not intercept the 424 message. If it intercepts a unicast DHCP request message, it 425 populates the 'giaddr' and relay it to the DHCP server. When 426 DHCP server sends a reply for this request message, it resets the 427 'giaddr' field, identifies outgoing interface and forwards the 428 reply on the identified interface. 430 4.3.2. Issues due to introduction of Layer 2 Relay Agent 432 Though the processing of DHCP messages remain the same in Layer 2 433 Relay Agent, we see some more issues when a Layer 3 Relay Agent is 434 present to relay the DHCP messages to the DHCP server. 436 1. When a Layer 2 Relay Agent is configured to intercept unicast 437 messages as well, it appends Relay Agent Information option 438 before forwarding them. A Layer 3 Relay Agent may not intercept 439 these unicast messages. Due to this, a DHCP server may not echo 440 back the Relay Agent Information option because the giaddr is not 441 populated. 443 2. Existing Layer 3 Relay Agents populate the 'giaddr' with the IP 444 address of the interface on which the request was received. This 445 helps Layer 3 Relay Agent to identify the outgoing interface for 446 the DHCP replies. In some cases, a Layer 3 Relay Agent may use 447 unnumbered interfaces. In this case, it has to use a system wide 448 IP address to populate the 'giaddr' field. Due to this, it 449 becomes difficult to identify the correct outgoing interface for 450 the messages received from the DHCP server. In these cases, some 451 existing Layer 3 Relay Agent implementations maintain an internal 452 state for each DHCP messages and use this state to identify the 453 outgoing interface. 455 3. DHCP server uses certain parameters to differentiate the RENEW 456 and REBIND state of a client. A DHCP client unicasts a RENEW 457 request to the DHCP server, so DHCP server sees a DHCPREQUEST 458 without 'giaddr' and Relay Agent Information option as RENEW 459 request. While a REBIND request is broadcast and so DHCP server 460 expect it to contain 'giaddr' and Relay Agent Information option. 461 If Layer 2 Relay Agent is configured to intercept unicast 462 messages, it will append Relay Agent Information option to the 463 unicast DHCP messages. Because of this, it could be difficult 464 for DHCP server to differentiate between a RENEWING and REBINDING 465 state. 467 5. Acknowledgments 469 This document is the result of a discussion on DHC WG mailing list. 470 Thanks to David W. Hankins and Michael Wacker for providing inputs on 471 some of the existing implementations. Thanks to Ted Lemon, Mukund 472 Kamath and Stefaan.De.Cnodder for reviewing the draft and providing 473 valuable suggestions. 475 6. Security Consideration 477 o A Layer 2 Relay Agent should always be configured to identify a 478 trustable entity so that it appends Relay Agent Information option 479 to DHCP messages coming from a trustable entity and forward it. 480 If a DHCP message is received from a non-trustable entity, it 481 should discard it and may report to the administrator. 483 o Introduction of Layer 2 Relay Agent does not introduce any new 484 security issue. Security issues pertaining to Relay Agents in 485 general applies to Layer 2 Relay Agents as well. 487 7. IANA Considerations 489 This document does not introduce any new namespaces for the IANA to 490 manage. 492 8. References 494 8.1. Normative Reference 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, March 1997. 499 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 500 RFC 2131, March 1997. 502 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 503 RFC 3046, January 2001. 505 [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP 506 Messages", RFC 3118, June 2001. 508 [RFC3232] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. 510 8.2. Informative Reference 512 [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", 513 RFC 951, September 1985. 515 [RFC1542] Wimer, W., "Clarifications and Extensions for the 516 Bootstrap Protocol", RFC 1542, October 1993. 518 [RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor 519 Extensions", RFC 2132, March 1997. 521 Authors' Addresses 523 Bharat Joshi 524 Infosys Technologies Ltd. 525 44 Electronics City, Hosur Road 526 Bangalore 560 100 527 India 529 Email: bharat_joshi@infosys.com 530 URI: http://www.infosys.com/ 532 Pavan Kurapati 533 Infosys Technologies Ltd. 534 44 Electronics City, Hosur Road 535 Bangalore 560 100 536 India 538 Email: pavan_kurapati@infosys.com 539 URI: http://www.infosys.com/ 541 Full Copyright Statement 543 Copyright (C) The IETF Trust (2008). 545 This document is subject to the rights, licenses and restrictions 546 contained in BCP 78, and except as set forth therein, the authors 547 retain all their rights. 549 This document and the information contained herein are provided on an 550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 552 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 553 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 554 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 557 Intellectual Property 559 The IETF takes no position regarding the validity or scope of any 560 Intellectual Property Rights or other rights that might be claimed to 561 pertain to the implementation or use of the technology described in 562 this document or the extent to which any license under such rights 563 might or might not be available; nor does it represent that it has 564 made any independent effort to identify any such rights. Information 565 on the procedures with respect to rights in RFC documents can be 566 found in BCP 78 and BCP 79. 568 Copies of IPR disclosures made to the IETF Secretariat and any 569 assurances of licenses to be made available, or the result of an 570 attempt made to obtain a general license or permission for the use of 571 such proprietary rights by implementers or users of this 572 specification can be obtained from the IETF on-line IPR repository at 573 http://www.ietf.org/ipr. 575 The IETF invites any interested party to bring to its attention any 576 copyrights, patents or patent applications, or other proprietary 577 rights that may cover technology that may be required to implement 578 this standard. Please address the information to the IETF at 579 ietf-ipr@ietf.org.