idnits 2.17.1 draft-ietf-mpls-over-l2tpv3-03.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 511. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 2006) is 6369 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Townsley 3 Internet-Draft C. Pignataro 4 Expiration Date: May 2007 S. Wainner 5 cisco Systems 6 T. Seely 7 Sprint Nextel 8 J. Young 10 November 2006 12 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 14 draft-ietf-mpls-over-l2tpv3-03.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a 42 protocol for tunneling a variety of payload types over IP networks. 43 This document defines how to carry an MPLS label stack and its 44 payload over the L2TPv3 data encapsulation. This enables an 45 application which traditionally requires an MPLS-enabled core network 46 to utilize an L2TPv3 encapsulation over an IP network instead. 48 Contents 50 Status of this Memo.......................................... 1 52 1. Introduction.............................................. 2 54 2. MPLS over L2TPv3 Encoding................................. 3 56 3. Assigning the L2TPv3 Session ID and Cookie................ 4 58 4. Applicability............................................. 4 60 5. Congestion Considerations................................. 6 62 6. Security Considerations................................... 6 63 6.1 In the Absence of IPsec............................... 7 64 6.2 Context Validation.................................... 7 65 6.3 Securing the Tunnel with IPsec........................ 8 67 7. IANA Considerations....................................... 9 69 8. Acknowledgements.......................................... 9 71 9. References................................................ 9 72 9.1 Normative References.................................. 9 73 9.2 Informative References................................ 9 75 10. Authors' Addresses....................................... 11 77 Specification of Requirements 79 In this document, several words are used to signify the requirements 80 of the specification. These words are often capitalized. The key 81 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 82 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 83 are to be interpreted as described in [RFC2119]. 85 1. Introduction 87 This document defines how to encapsulate an MPLS label stack and its 88 payload inside the L2TPv3 tunnel payload. After defining the MPLS 89 over L2TPv3 encapsulation procedure, other MPLS over IP encapsulation 90 options including IP, GRE and IPsec are discussed in context with 91 MPLS over L2TPv3 in an Applicability section. This document only 92 describes encapsulation and does not concern itself with all possible 93 MPLS-based applications which may be enabled over L2TPv3. 95 2. MPLS over L2TPv3 Encoding 97 MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] and its 98 payload over an IP network utilizing the L2TPv3 encapsulation defined 99 in [RFC3931]. The MPLS Label Stack and payload are carried in their 100 entirety following IP (either IPv4 or IPv6) and L2TPv3 headers. 102 +-+-+-+-+-+-+-+-+-+-+ 103 | IP | 104 +-+-+-+-+-+-+-+-+-+-+ 105 | L2TPv3 | 106 +-+-+-+-+-+-+-+-+-+-+ 107 | MPLS Label Stack | 108 +-+-+-+-+-+-+-+-+-+-+ 109 | MPLS Payload | 110 +-+-+-+-+-+-+-+-+-+-+ 112 Figure 2.1 MPLS Packet over L2TPv3/IP 114 The L2TPv3 encapsulation carrying a single MPLS label stack entry is 115 as follows: 117 0 1 2 3 118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Session ID | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Cookie (optional, maximum 64 bits)... 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 ... | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 126 | Label | Exp |S| TTL | Stack 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 129 Figure 2.2 MPLS over L2TPv3 encapsulation 131 When encapsulating MPLS over L2TPv3, the L2TPv3 L2-Specific Sublayer 132 MAY be present. It is generally not present and hence not included 133 in Figure 2.2. The L2TPv3 Session ID MUST be present. The Cookie MAY 134 be present. 136 Session ID 138 The L2TPv3 Session ID is a 32-bit identifier field locally 139 selected as a lookup key for the context of an L2TP Session. An 140 L2TP Session contains necessary context for processing a received 141 L2TP packet. At a minimum, such context contains whether the 142 Cookie (see description below) is present, the value it was 143 assigned, the presence and type of an L2TPv3 L2-Specific Sublayer, 144 as well as what type of tunneled encapsulation follows (i.e., 145 Frame Relay, Ethernet, MPLS, etc.) 147 Cookie 149 The L2TPv3 Cookie field contains a variable length (maximum 64 150 bits) randomly assigned value. It is intended to provide an 151 additional level of guarantee that a data packet has been directed 152 to the proper L2TP session by the Session ID. While the Session 153 ID may be encoded and assigned any value (perhaps optimizing for 154 local lookup capabilities, redirection in a distributed forwarding 155 architecture, etc.), the Cookie MUST be selected as a 156 cryptographically random value [RFC4086], with the added 157 restriction that it not be the same as a recently used value for a 158 given Session ID. A well-chosen Cookie will prevent inadvertent 159 misdirection of a stray packet containing a recently reused 160 Session ID, a Session ID that is subject to packet corruption, and 161 protection against some specific malicious packet insertion 162 attacks as described in more detail in Section 4 of this document. 164 Label Stack Entry 166 An MPLS label stack entry as defined in [RFC3032]. 168 The optional L2-Specific Sublayer defined in [RFC3931] is generally 169 not present for MPLS over L2TPv3. 171 Generic IP encapsulation procedures such as fragmentation and MTU 172 considerations, handling of TTL, EXP and DSCP bits, etc. are the same 173 as the "Common Procedures" for IP encapsulation of MPLS defined in 174 Section 5 of [RFC4023] and are not reiterated here. 176 3. Assigning the L2TPv3 Session ID and Cookie 178 Much like an MPLS label, the L2TPv3 Session ID and Cookie must be 179 selected and exchanged between participating nodes before L2TPv3 can 180 operate. These values may be configured manually, or distributed via 181 a signaling protocol. This document concerns itself only with the 182 encapsulation of MPLS over L2TPv3, thus the particular method of 183 assigning the Session ID and Cookie (if present) is out of scope. 185 4. Applicability 187 The methods defined [RFC4023], [MPLS-IPSEC] and this document all 188 describe methods for carrying MPLS over an IP network. Cases where 189 MPLS over L2TPv3 is comparable to other alternatives are discussed in 190 this section. 192 It is generally simpler to have one's border routers refuse to accept 193 an MPLS packet than to configure a router to refuse to accept certain 194 MPLS packets carried in IP or GRE to or from certain IP sources or 195 destinations. Thus, the use of IP or GRE to carry MPLS packets 196 increases the likelihood that an MPLS label spoofing attack will 197 succeed. L2TPv3 provides an additional level of protection against 198 packet spoofing before allowing a packet to enter a VPN (much like 199 IPsec provides an additional level of protection at a Provider Edge 200 (PE) router rather than relying on Access Control List (ACL) 201 filters). Checking the value of the L2TPv3 Cookie is similar to any 202 sort of ACL which inspects the contents of a packet header, except 203 that we give ourselves the luxury of "seeding" the L2TPv3 header with 204 a value that is very difficult to spoof. 206 MPLS over L2TPv3 may be advantageous compared to [RFC4023], if: 208 Two routers are already "adjacent" over an L2TPv3 tunnel 209 established for some other reason, and wish to exchange MPLS 210 packets over that adjacency. 212 Implementation considerations dictate the use of MPLS over L2TPv3. 213 For example, a hardware device may be able to take advantage of 214 the L2TPv3 encapsulation for faster or distributed processing. 216 Packet spoofing and insertion, service integrity and resource 217 protection are of concern, especially given the fact that an IP 218 tunnel potentially exposes the router to rogue or inappropriate IP 219 packets from unknown or untrusted sources. IP Access Control 220 Lists (ACLs) and numbering methods may be used to protect the 221 Provider Edge (PE) routers from rogue IP sources, but may be 222 subject to error and cumbersome to maintain at all edge points at 223 all times. The L2TPv3 Cookie provides a simple means of 224 validating the source of an L2TPv3 packet before allowing 225 processing to continue. This validation offers an additional level 226 of protection over and above IP ACLs, and a validation that the 227 Session ID was not corrupted in transit or suffered an internal 228 lookup error upon receipt and processing. If the Cookie value is 229 assigned and distributed automatically, it is less subject to 230 operator error, and if selected in a cryptographically random 231 nature, less subject to blind guesses than source IP addresses (in 232 the event that a hacker can insert packets within a VPN core 233 network). 235 (The first two of the above applicability statements were adopted 236 from [RFC4023]) 238 In summary, L2TPv3 can provide a balance between the limited security 239 against IP spoofing attacks offered by [RFC4023] vs. the greater 240 security and associated operational and processing overhead offered 241 by [MPLS-IPSEC]. Further, MPLS over L2TPv3 may be faster in some 242 hardware, particularly if that hardware is already optimized to 243 classify incoming L2TPv3 packets carrying IP framed in a variety of 244 ways. For example, IP encapsulated by HDLC or Frame Relay over L2TPv3 245 may be equivalent in complexity to IP encapsulated by MPLS over 246 L2TPv3. 248 5. Congestion Considerations 250 This document specifies an encapsulation method for MPLS inside the 251 L2TPv3 tunnel payload. MPLS can carry a number of different protocols 252 as payloads. When an MPLS/L2TPv3 flow carries IP-based traffic, the 253 aggregate traffic is assumed to be TCP friendly due to the congestion 254 control mechanisms used by the payload traffic. Packet loss will 255 trigger the necessary reduction in offered load, and no additional 256 congestion avoidance action is necessary. 258 When an MPLS/L2TPv3 flow carries payload traffic that is not known to 259 be TCP friendly and the flow runs across an unprovisioned path that 260 could potentially become congested, the application that uses the 261 encapsulation specified in this document MUST employ additional 262 mechanisms to ensure that the offered load is reduced appropriately 263 during periods of congestion. The MPLS/L2TPv3 flow should not exceed 264 the average bandwidth that a TCP flow across the same network path 265 and experiencing the same network conditions would achieve, measured 266 on a reasonable timescale. This is not necessary in the case of an 267 unprovisioned path through an overprovisioned network, where the 268 potential for congestion is avoided through the overprovisioning of 269 the network. 271 The comparison to TCP cannot be specified exactly but is intended as 272 an "order-of-magnitude" comparison in timescale and throughput. The 273 timescale on which TCP throughput is measured is the round-trip time 274 of the connection. In essence, this requirement states that it is not 275 acceptable to deploy an application using the encapsulation specified 276 in this document on the best-effort Internet, which consumes 277 bandwidth arbitrarily and does not compete fairly with TCP within an 278 order of magnitude. One method of determining an acceptable bandwidth 279 is described in [RFC3448]. Other methods exist, but are outside the 280 scope of this document. 282 6. Security Considerations 284 There are three main concerns when transporting MPLS labeled traffic 285 between PEs using IP tunnels. The first is the possibility that a 286 third party may insert packets into a packet stream between two PEs. 287 The second is that a third party might view the packet stream between 288 two PEs. The third is that a third party may alter packets in a 289 stream between two PEs. The security requirements of the 290 applications whose traffic is being sent through the tunnel 291 characterizes how significant these issues are. Operators may use 292 multiple methods to mitigate the risk including access lists, 293 authentication, encryption, and context validation. Operators should 294 consider the cost to mitigate the risk. 296 Security is also discussed as part of the applicability discussion in 297 section 4 of this document. 299 6.1 In the Absence of IPsec 301 If the tunnels are not secured with IPsec, then some other method 302 should be used to ensure that packets are decapsulated and processed 303 by the tunnel tail only if those packets were encapsulated by the 304 tunnel head. If the tunnel lies entirely within a single 305 administrative domain, address filtering at the boundaries can be 306 used to ensure that no packet with the IP source address of a tunnel 307 endpoint or with the IP destination address of a tunnel endpoint can 308 enter the domain from outside. 310 However, when the tunnel head and the tunnel tail are not in the same 311 administrative domain, this may become difficult, and filtering based 312 on the destination address can even become impossible if the packets 313 must traverse the public Internet. 315 Sometimes only source address filtering (but not destination address 316 filtering) is done at the boundaries of an administrative domain. If 317 this is the case, the filtering does not provide effective protection 318 at all unless the decapsulator of MPLS over L2TPv3 validates the IP 319 source address of the packet. 321 Additionally, the "Data Packet Spoofing" considerations in Section 322 8.2. of [RFC3931] and the "Context Validation" considerations in 323 Section 5.2 of this document apply. Those two sections highlight the 324 benefits of the L2TPv3 Cookie. 326 6.2 Context Validation 328 The L2TPv3 Cookie does not provide protection via encryption. 329 However, when used with a sufficiently random 64-bit value which is 330 kept secret from an off-path attacker, the L2TPv3 Cookie may be used 331 as a simple yet effective packet source authentication check which is 332 quite resistant to brute force packet spoofing attacks. It also 333 alleviates the need to rely solely on filter lists based on a list of 334 valid source IP addresses, and thwarts attacks which could benefit by 335 spoofing a permitted source IP address. The L2TPv3 Cookie provides a 336 means of validating the currently assigned Session ID on the packet 337 flow, providing context protection, and may be deemed complimentary 338 to securing the tunnel utilizing IPsec. In the absence of 339 cryptographic security on the data plane (such as that provided by 340 IPsec), the L2TPv3 Cookie provides a simple method of validating the 341 Session ID lookup performed on each L2TPv3 packet. If the Cookie is 342 sufficiently random and remains unknown to an attacker (that is, the 343 attacker has no way to predict Cookie values or monitor traffic 344 between PEs) then the Cookie provides an additional measure of 345 protection against malicious spoofed packets inserted at the PE over 346 and above that of typical IP address and port ACLs. 348 6.3 Securing the Tunnel with IPsec 350 L2TPv3 tunnels may also be secured using IPsec, as specified in 351 Section 4.1.3. of [RFC3931]. IPSec may provide authentication, 352 privacy protection, integrity checking and replay protection. These 353 functions may be deemed necessary by the operator. When using IPsec, 354 the tunnel head and the tunnel tail should be treated as the 355 endpoints of a Security Association. A single IP address of the 356 tunnel head is used as the source IP address, and a single IP address 357 of the tunnel tail is used as the destination IP address. The means 358 by which each node knows the proper address of the other is outside 359 the scope of this document. However, if a control protocol is used 360 to set up the tunnels, such control protocol MUST have an 361 authentication mechanism, and this MUST be used when the tunnel is 362 set up. If the tunnel is set up automatically as the result of, for 363 example, information distributed by BGP, then the use of BGP's MD5- 364 based authentication mechanism can serve this purpose. 366 The MPLS over L2TPv3 encapsulated packets should be considered as 367 originating at the tunnel head and as being destined for the tunnel 368 tail; IPsec transport mode SHOULD thus be used. 370 Note that the tunnel tail and the tunnel head are LSP adjacencies 371 (label distribution adjacencies, see [RFC3031]), which means that the 372 topmost label of any packet sent through the tunnel must be one that 373 was distributed by the tunnel tail to the tunnel head. The tunnel 374 tail MUST know precisely which labels it has distributed to the 375 tunnel heads of IPsec-secured tunnels. Labels in this set MUST NOT 376 be distributed by the tunnel tail to any LSP adjacencies other than 377 those that are tunnel heads of IPsec-secured tunnels. If an MPLS 378 packet is received without an IPsec encapsulation, and if its topmost 379 label is in this set, then the packet MUST be discarded. 381 Securing L2TPv3 using IPsec MUST provide authentication and 382 integrity. (Note that the authentication and integrity provided will 383 apply to the entire MPLS packet, including the MPLS label stack.) 384 Consequently, the implementation MUST support ESP with null 385 encryption. ESP with encryption MAY be supported if a source 386 requires confidentiality. If ESP is used, the tunnel tail MUST check 387 that the source IP address of any packet received on a given SA is 388 the one expected. 390 Key distribution may be done either manually or automatically by 391 means of IKE [RFC2409] or IKEv2 [RFC4306]. Manual keying MUST be 392 supported. If automatic keying is implemented, IKE in main mode with 393 preshared keys MUST be supported. A particular application may 394 escalate this requirement and request implementation of automatic 395 keying. Manual key distribution is much simpler, but also less 396 scalable, than automatic key distribution. If replay protection is 397 regarded as necessary for a particular tunnel, automatic key 398 distribution should be configured. 400 7. IANA Considerations 402 There are no IANA considerations for this document. 404 8. Acknowledgements 406 Thanks to Robert Raszuk, Clarence Filsfils and Eric Rosen for their 407 review of this document. Some text was adopted from [RFC4023]. 409 9. References 411 9.1 Normative References 413 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two 414 Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, 415 March 2005. 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 421 MPLS in IP or Generic Routing Encapsulation (GRE)", 422 RFC 4023, March 2005. 424 9.2 Informative References 426 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 427 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 428 Encoding", RFC 3032, January 2001. 430 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 431 Requirements for Security", BCP 106, RFC 4086, 432 June 2005. 434 [MPLS-IPSEC] Rosen, E., "Architecture for the Use of PE-PE IPsec 435 Tunnels in BGP/MPLS IP VPNs", 436 draft-ietf-l3vpn-ipsec-2547-05 (work in progress), 437 August 2005. 439 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, 440 "Multiprotocol Label Switching Architecture", RFC 3031, 441 January 2001. 443 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 444 (IKE)", RFC 2409, November 1998. 446 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 447 RFC 4306, December 2005. 449 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 450 Friendly Rate Control (TFRC): Protocol Specification", 451 RFC 3448, January 2003. 453 10. Authors' Addresses 455 W. Mark Townsley 456 cisco Systems 458 Phone: +1-919-392-3741 459 EMail: mark@townsley.net 461 Carlos Pignataro 462 cisco Systems 463 7025 Kit Creek Road 464 PO Box 14987 465 Research Triangle Park, NC 27709 467 Phone: +1-919-392-7428 468 EMail: cpignata@cisco.com 470 Scott Wainner 471 cisco Systems 472 13600 Dulles Technology Drive 473 Herndon, VA 20171 475 EMail: swainner@cisco.com 477 Ted Seely 478 Sprint Nextel 479 12502 Sunrise Valley Dr 480 Reston, VA 20196 482 Phone: +1-703-689-6425 483 EMail: tseely@sprint.net 485 Jeff Young 487 EMail: young@jsyoung.net 489 Intellectual Property Statement 491 The IETF takes no position regarding the validity or scope of any 492 Intellectual Property Rights or other rights that might be claimed to 493 pertain to the implementation or use of the technology described in 494 this document or the extent to which any license under such rights 495 might or might not be available; nor does it represent that it has 496 made any independent effort to identify any such rights. Information 497 on the procedures with respect to rights in RFC documents can be 498 found in BCP 78 and BCP 79. 500 Copies of IPR disclosures made to the IETF Secretariat and any 501 assurances of licenses to be made available, or the result of an 502 attempt made to obtain a general license or permission for the use of 503 such proprietary rights by implementers or users of this 504 specification can be obtained from the IETF on-line IPR repository at 505 http://www.ietf.org/ipr. 507 The IETF invites any interested party to bring to its attention any 508 copyrights, patents or patent applications, or other proprietary 509 rights that may cover technology that may be required to implement 510 this standard. Please address the information to the IETF at 511 ietf-ipr@ietf.org. 513 Disclaimer of Validity 515 This document and the information contained herein are provided on 516 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 517 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 518 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 519 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 520 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 521 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 522 FOR A PARTICULAR PURPOSE. 524 Copyright Statement 526 Copyright (C) The IETF Trust (2006). 528 This document is subject to the rights, licenses and restrictions 529 contained in BCP 78, and except as set forth therein, the authors 530 retain all their rights. 532 Acknowledgment 534 Funding for the RFC Editor function is currently provided by the 535 Internet Society.