idnits 2.17.1 draft-joshi-dhc-l2ra-00.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 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 534. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (November 10, 2007) is 6011 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 470, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 476, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 479, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 489, 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 (~~), 7 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: May 13, 2008 Infosys Technologies Ltd. 5 November 10, 2007 7 Layer 2 Relay Agent Information 8 draft-joshi-dhc-l2ra-00.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 May 13, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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 closest Layer 2 49 device to append Relay Agent Information option in DHCP messages. 50 These devices are typically known as Layer 2 Relay Agents. 52 This document aims to describe the network scenarios where Layer 2 53 Relay Agent is in use and also how it handles DHCP messages. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 5 60 4. Layer 2 Relay Agent in various network scenarios . . . . . . . 6 61 4.1. DHCP server and client on same subnet . . . . . . . . . . 6 62 4.1.1. Client-server interaction . . . . . . . . . . . . . . 6 63 4.1.2. Issues due to introduction of Layer 2 Relay Agent . . 8 64 4.2. Multiple DHCP server and Client on same subnet . . . . . . 8 65 4.2.1. Client-server interaction . . . . . . . . . . . . . . 9 66 4.2.2. Issues due to introduction of Layer 2 Relay Agent . . 9 67 4.3. DHCP server on another subnet with one Layer 3 Relay 68 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.3.1. Client-server interaction . . . . . . . . . . . . . . 10 70 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 10 71 5. Enhancements in Layer 2 Relay Agent . . . . . . . . . . . . . 12 72 5.1. Broadcasting DHCP requests on all ports . . . . . . . . . 12 73 5.2. A Layer 3 Relay Agent broadcasting a DHCP reply . . . . . 12 74 5.3. Maintaining Lease Information by Layer 2 Relay Agent . . . 12 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 16 80 9.2. Informative Reference . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 82 Intellectual Property and Copyright Statements . . . . . . . . . . 18 84 1. Introduction 86 DHCP Relay Agents eliminate the necessity of having a DHCP server on 87 each physical network. Relay Agents populate the 'giaddr' field as 88 they deem appropriate and also add 'Relay Agent Information' option 89 to the DHCP messages. DHCP servers use this option for IP address 90 and other parameter assignment policies. These DHCP Relay Agents are 91 typically a IP routing aware device and sometimes are referred as 92 Layer 3 Relay Agent. 94 In some networks, there is a need for Layer 2 devices to add Relay 95 Agent Information option as they are closer to the end hosts. These 96 Layer 2 devices can not relay the message to the DHCP servers as they 97 are confiured in bridging mode. These Layer 2 devices append the 98 Relay Agent Information option and broadcast the DHCP message. A 99 Layer 3 Relay Agent relays it to the DHCP server. 101 This document provides information about where a Layer 2 Relay Agent 102 fits in and how it is used. This document also looks at various 103 network scenarios with Layer 2 Relay Agent and issues that are 104 involved. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [1]. 112 This document uses the following terms: 114 o "DHCP client" 116 A DHCP client is an Internet host using DHCP to obtain configuration 117 parameters such as a network address. 119 o "Layer 3 Relay Agent" 121 A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap 122 Protocol (BOOTP) and DHCP messages between clients and servers 123 residing on different subnets, per RFC951 [6] and RFC1542[7]. 125 o "DHCP server" 127 A DHCP server is an Internet host that returns configuration 128 parameters to DHCP clients. 130 o "Unnumbered Interfaces" 132 An interface with no IP address associated with it. IP packets 133 received on this interface will be processed like any other numbered 134 IP interface. It may use a local IP address while generating IP 135 packets. 137 3. Need of Layer 2 Relay Agent 139 A Layer 2 device intercepts DHCP messages for following reasons: 141 1. In some network deployments like xDSL, the subscriber aggregation 142 devices (also known as Access Concentrator or a DSLAM in case of 143 DSL) are configured to act as bridges. As these devices are 144 closest to the subscriber, they are in the best postion to 145 provide a unique Relay Agent Information option to enforce 146 policies in DHCP server. Some existing implementation intercepts 147 only broadcast messages while some of them intercepts unicast 148 messages as well. If a Layer 2 Relay Agent intercepts a DHCP 149 message, it appends Relay Agent Information option in DHCP 150 message and forwards it. 152 2. 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 upto date. 161 3. 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. 165 4. Layer 2 Relay Agent in various network scenarios 167 This section describes the various network scenarios where a Layer 2 168 Relay Agent fits in. It also describes how it handles different DHCP 169 messages. 171 4.1. DHCP server and client on same subnet 173 In certain network configurations, DHCP server may reside on the same 174 subnet as the DHCP clients. A Layer 2 aggregation device resides 175 between the DHCP clients and DHCP server. Following points describe 176 how this Layer 2 device handles various DHCP messages if it acts as a 177 Layer 2 Relay Agent. Figure #1 shows a typical network setup. 179 +--------+ 180 | End | +--------+ | 181 | Host#1 +-----------| | | +-----------+ 182 +--------+ | Layer +-----| | | 183 | 2 | +-----| DHCP | 184 +--------+ | device | | | Server#1 | 185 | End +-----------| #1 | | +-----------+ 186 | Host#2 | +--------+ | 187 +--------+ | 188 | 189 +--------+ | 190 | End | +--------+ | 191 | Host#3 +-----------| | | 192 +--------+ | Layer +-----| 193 | 2 | | 194 +--------+ | device | | 195 | End +-----------| #2 | 196 | Host#n | +--------+ 197 +--------+ 199 Figure 1 201 4.1.1. Client-server interaction 203 The following summary of protocol message exchanges between clients 204 and DHCP servers describes how they are handlded in Layer 2 Relay 205 Agent. 207 1. The client [End Host #1] broadcasts a DHCPDISCOVER message on its 208 local physical subnet. Layer 2 Relay Agent [#1] intercepts this 209 message, appends Relay Agent Information option and broadcasts it 210 to all the ports except on which it was received. Relay Agent 211 Information option could be created as suggested in RFC 3046[3]. 212 Layer 2 Relay Agent does not set the 'giaddr' 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 add another Relay 217 Agent Information option to the message. It may discard this 218 message if it is coming from an untrusted entity. Otherwise, it 219 will broadcast this on all the ports except on which the message 220 was received. If the device is not configured as Layer 2 Relay 221 Agent, it will switch/bridge the message normally. 223 3. Server responds with a DHCPOFFER message that includes an 224 available network address in the 'yiaddr' field (and other 225 configuration parameters in DHCP options). DHCP server echoes 226 back the Relay Agent Information option in the DHCPOFFER message. 227 Layer 2 Relay Agent intercepts this message and removes the Relay 228 Agent Information option. It usually identify the outgoing port 229 using Relay Agent Information option. If the broadcast bit is 230 clear, it unicasts this message to the identified port otherwise 231 broadcasts it to all the ports except from which this reply 232 message was received. 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 broadcast this message normally. This is because it can find out 237 that it had not forwarded the DHCPDISCOVER request. A Layer 2 238 Relay Agent uses the Relay Agent Information option to find out 239 if it had 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 intercepts this unicast message and remove Relay Agent 254 Information option. It usually identify the outgoing port using 255 Relay Agent Information option. If the broadcast bit is clear, 256 it unicasts this message to the identified port otherwise 257 broadcast it to all the ports except from which this reply 258 message was received. 260 7. A server that is unable to satisfy the DHCPREQUEST message, 261 responds with DHCPNACK. Layer 2 Relay Agent process this similar 262 to DHCPACK message. 264 8. The client receives the DHCPACK message with configuration 265 parameters. If client detects that the address is already in 266 use, it sends a DHCPDECLINE message to the server. Layer 2 Relay 267 Agent process this messages similar to DHCPDISCOVER message. 269 9. When client knows the address of a DHCP server, it may unicast 270 DHCPDISCOVER, DHCPREQUEST messages to the server. DHCP clients 271 unicast the DHCP messages like DHCPRELEASE and DHCPREQUEST when 272 renewing the lease to the DHCP server. Layer 2 Relay Agent may 273 or may not intercept these messages based on internal 274 configuration. If Layer 2 Relay Agents intercept these messages, 275 they append Relay Agent Information option and forward it towards 276 the DHCP server. They also intercepts the reply messages and 277 remove Relay Agent Information option 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 but the 'giaddr' 283 field in the message is not set. 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. A DHCP server should be able to handle a unicast DHCP message 292 containing Relay Agent Information option. Some existing DHCP 293 server implementations do not echo back the Relay Agent 294 Information option in DHCP reply messages. 296 4.2. Multiple DHCP server and Client on same subnet 298 In certain network scenarios, there could be multiple DHCP server on 299 the same subnet. Figure #2 shows a typical network setup. 301 +--------+ 302 | End | +--------+ | 303 | Host#1 +-----------| | | +-----------+ 304 +--------+ | Layer +-----| | | 305 | 2 | +-----| DHCP | 306 +--------+ | device | | | Server#1 | 307 | End +-----------| #1 | | +-----------+ 308 | Host#2 | +--------+ | 309 +--------+ | 310 | +-----------+ 311 +--------+ | | DHCP | 312 | End | +--------+ |-----| Server #2 | 313 | Host#3 +-----------| | | | | 314 +--------+ | Layer +-----| +-----------+ 315 | 2 | | 316 +--------+ | device | 317 | End +-----------| #2 | 318 | Host#n | +--------+ 319 +--------+ 321 Figure 2 323 4.2.1. Client-server interaction 325 The message exchange are same as explained in 4.1.1. However, due to 326 introduction of multiple DHCP servers the below additional message 327 exchanges may happen 329 1. When Host [#1] sends DHCPDISCOVER, it will be received by both 330 the DHCP Servers connected to L2RA #1 and both the servers will 331 respond with a DHCPOFFER. So instead of one DHCPOFFER message, 332 Layer 2 Relay Agent would receive two messages. Processing of 333 DHCP messages in the Layer 2 Relay Agent remains the same. 335 4.2.2. Issues due to introduction of Layer 2 Relay Agent 337 1. This is same as described in section 4.1.2. 339 4.3. DHCP server on another subnet with one Layer 3 Relay Agent 341 In certain network scenarios, there could be a Layer 3 Relay Agent 342 which relays the DHCP messages from/to one subnet to/from the DHCP 343 server on another subnet. In access network scenarios, its seen that 344 Access Concentrator works as Layer 2 Relay Agent. 346 +--------+ 347 | End | +--------+ | | 348 | Host#1 +--------| | | +-----------+ | 349 +--------+ | Layer +-----| | | | 350 | 2 | +--| Layer 3 |----| 351 +--------+ | device | | | Relay | | 352 | End +--------| #1 | | | Agent #1 | | 353 | Host#2 | +--------+ | +-----------+ | +---------+ 354 +--------+ | | | | 355 | +--| DHCP | 356 +--------+ | | | Server | 357 | End | +--------+ | | | #1 | 358 | Host#3 +--------| | | +---------+ 359 +--------+ | Layer +-----| 360 | 2 | | 361 +--------+ | device | | 362 | End +--------| #2 + 363 | Host#n | +--------+ 364 +--------+ 366 Figure 3 368 4.3.1. Client-server interaction 370 As far as DHCP message processing is concerned, the presence of Layer 371 3 Relay Agent is transparent to Layer 2 Relay Agent. So all the 372 messages are handled in the same way as defined in section 4.1.1. 374 4.3.2. Issues due to introduction of Layer 2 Relay Agent 376 Though the processing of DHCP messages remain the same in Layer 2 377 Relay Agent, we see some more issues when a Layer 3 Relay Agent is 378 present to relay the DHCP messages to the DHCP server. 380 1. When a Layer 2 Relay Agent is configured to intercept unicast 381 messages as well, it appends Relay Agent Information option 382 before forwarding them. A Layer 3 Relay Agent may not intercept 383 these unicast messages. Due to this, a DHCP server may not echo 384 back the Relay Agent Information option because the giaddr is not 385 populated. 387 2. Existing Layer 3 Relay Agents populate the 'giaddr' with the IP 388 address of the interface on which the request was received. This 389 helps Layer 3 Relay Agent to identify the outgoing interface for 390 the DHCP replies. In some case, a Layer 3 Relay Agent may use 391 unnumbered interfaces. In this case, it has to use a system wide 392 IP address to populate the 'giaddr' field. Due to this, it 393 becomes difficult to identify the correct outgoing interface for 394 the messages received from the DHCP server. In these cases, some 395 existing Layer 3 Relay Agent implementations maintain an internal 396 state for each DHCP messages and use this state to identify the 397 outgoing interface. 399 3. DHCP server uses certain parameters to differentiate the RENEW 400 and REBIND state of a client. A DHCP client unicasts a RENEW 401 request to the DHCP server, so DHCP server sees a DHCPREQUEST 402 without 'giaddr' and Relay Agent Information option as RENEW 403 request. While a REBIND request is broadcast and so DHCP server 404 expect it to contain 'giaddr' and Relay Agent Information option. 405 If Layer 2 Relay Agent is configured to intercepts unicast 406 messages, it will append Relay Agent Information option to the 407 unicast DHCP messages. Because of this, it could be difficult 408 for DHCP server to differentiate between a RENEWING and REBINDING 409 state. 411 5. Enhancements in Layer 2 Relay Agent 413 This section looks at various possible enhancements in Layer 2 Relay 414 Agents. These enhancements is aimed in increasing the flexibility 415 and efficiency of Layer 2 Relay Agent in general. 417 5.1. Broadcasting DHCP requests on all ports 419 A normal Layer 2 Relay Agent would broadcast a DHCP request message 420 to all its port except on which the message was received. Because of 421 this, a DHCP request message is received by those devices which would 422 not be interested in it. A configuration of uplink port that leads 423 to a Layer 3 Relay Agent or DHCP server can solve this issue. Some 424 of the existing implementation [Mostly in xDSL Access Concentrators] 425 already supports this. 427 5.2. A Layer 3 Relay Agent broadcasting a DHCP reply 429 In most of the cases, a Layer 3 Relay Agent would broadcast a DHCP 430 reply. This will again be received by those devices which would not 431 be interested in it. A new sub-option in Relay Agent Information 432 option can solve this issue. 434 5.3. Maintaining Lease Information by Layer 2 Relay Agent 436 A Layer 2 Relay Agent may maintain the lease information. This 437 information is lost if the Layer 2 Relay Agent reboots. DHCPv4 438 Leasequery can be extended to solve this issue. 440 6. Acknowledgments 442 This document is the result of a discussion on DHC WG mailing list. 443 David W. Hankins and Michael Wacker provided inputs on some of the 444 existing implementations. 446 7. Security Consideration 448 o A Layer 2 Relay Agent should always be configured to identify a 449 trustable entity so that it appends Relay Agent Information option 450 to DHCP messages coming from this and forward it. If a DHCP 451 message is received from a non-trustable entity, it should discard 452 it and may report to the administrator. 454 o Introduction of Layer 2 Relay Agent does not introduce any new 455 security issue. Security issues pertaining to Relay Agents in 456 general applies to Layer 2 Relay Agents as well. 458 8. IANA Considerations 460 This document does not introduce any new namespaces for the IANA to 461 manage. 463 9. References 465 9.1. Normative Reference 467 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 468 Levels", BCP 14, RFC 2119, March 1997. 470 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 471 March 1997. 473 [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 474 January 2001. 476 [4] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", 477 RFC 3118, June 2001. 479 [5] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. 481 9.2. Informative Reference 483 [6] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, 484 September 1985. 486 [7] Wimer, W., "Clarifications and Extensions for the Bootstrap 487 Protocol", RFC 1542, October 1993. 489 [8] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor 490 Extensions", RFC 2132, March 1997. 492 Authors' Addresses 494 Bharat Joshi 495 Infosys Technologies Ltd. 496 44 Electronics City, Hosur Road 497 Bangalore 560 100 498 India 500 Email: bharat_joshi@infosys.com 501 URI: http://www.infosys.com/ 503 Pavan Kurapati 504 Infosys Technologies Ltd. 505 44 Electronics City, Hosur Road 506 Bangalore 560 100 507 India 509 Email: pavan_kurapati@infosys.com 510 URI: http://www.infosys.com/ 512 Intellectual Property Statement 514 The IETF takes no position regarding the validity or scope of any 515 Intellectual Property Rights or other rights that might be claimed to 516 pertain to the implementation or use of the technology described in 517 this document or the extent to which any license under such rights 518 might or might not be available; nor does it represent that it has 519 made any independent effort to identify any such rights. Information 520 on the procedures with respect to rights in RFC documents can be 521 found in BCP 78 and BCP 79. 523 Copies of IPR disclosures made to the IETF Secretariat and any 524 assurances of licenses to be made available, or the result of an 525 attempt made to obtain a general license or permission for the use of 526 such proprietary rights by implementers or users of this 527 specification can be obtained from the IETF on-line IPR repository at 528 http://www.ietf.org/ipr. 530 The IETF invites any interested party to bring to its attention any 531 copyrights, patents or patent applications, or other proprietary 532 rights that may cover technology that may be required to implement 533 this standard. Please address the information to the IETF at 534 ietf-ipr@ietf.org. 536 Disclaimer of Validity 538 This document and the information contained herein are provided on an 539 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 540 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 541 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 542 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 543 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 544 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 546 Copyright Statement 548 Copyright (C) The IETF Trust (2007). This document is subject to the 549 rights, licenses and restrictions contained in BCP 78, and except as 550 set forth therein, the authors retain all their rights. 552 Acknowledgment 554 Funding for the RFC Editor function is currently provided by the 555 Internet Society.