idnits 2.17.1 draft-ietf-pwe3-vccv-bfd-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 501. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 (November 9, 2007) is 6006 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) == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-06 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-06 == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-05 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 T. Nadeau, Ed. 3 Internet-Draft BT 4 Intended status: Standards Track C. Pignataro, Ed. 5 Expires: May 12, 2008 Cisco Systems, Inc. 6 November 9, 2007 8 Bi-directional Forwarding Detection (BFD) for the Pseudowire Virtual 9 Circuit Connectivity Verification (VCCV) 10 draft-ietf-pwe3-vccv-bfd-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 12, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes new Connectivity Verification (CV) types for 44 using Bi-directional Forwarding Detection (BFD) with Virtual Circuit 45 Connectivity Verification (VCCV). VCCV provides a control channel 46 that is associated with a Pseudowire (PW), as well as the 47 corresponding operations and management functions such as 48 connectivity verification to be used over that control channel. 50 Table of Contents 52 1. Specification of Requirements . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Bidirectional Forwarding Detection Connectivity 57 Verification . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. BFD CV Type Operation . . . . . . . . . . . . . . . . . . 4 59 3.2. BFD Encapsulation . . . . . . . . . . . . . . . . . . . . 5 60 3.3. CV Types for BFD . . . . . . . . . . . . . . . . . . . . . 5 62 4. Capability Selection . . . . . . . . . . . . . . . . . . . . . 7 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV . 7 66 5.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 8 67 5.3. L2TPv3 CV Types for the VCCV Capability AVP . . . . . . . 8 69 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 9 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 Intellectual Property and Copyright Statements . . . . . . . . . . 12 82 1. Specification of Requirements 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Introduction 90 This document describes new Connectivity Verification (CV) types for 91 using Bi-directional Forwarding Detection (BFD) with Virtual Circuit 92 Connectivity Verification (VCCV). VCCV [I-D.ietf-pwe3-vccv] provides 93 a control channel that is associated with a Pseudowire (PW), as well 94 as the corresponding operations and management functions such as 95 connectivity/fault verification to be used over that control channel. 97 Some BFD CV Types can additionally carry fault status between the 98 endpoints of the Pseudowire. Furthermore, this information can then 99 be translated into the native OAM status codes used by the native 100 access technologies, such as ATM, Frame-Relay or Ethernet. The 101 specific details of such status interworking are out of the scope of 102 this document, and are only noted here to illustrate the utility of 103 BFD over VCCV for such purposes. Those details can be found in 104 [I-D.ietf-pwe3-oam-msg-map]. 106 The new BFD CV Types are PSN-agnostic, and hence applicable for both 107 MPLS and L2TPv3 PSNs. This document concerns itself with the BFD 108 VCCV operation over Single-Segment Pseudowires (SS-PW). 110 3. Bidirectional Forwarding Detection Connectivity Verification 112 VCCV can support several Connectivity Verification types (CV types) 113 or protocols. This section defines new CV types for use when BFD is 114 used as the VCCV payload. These types apply to both MPLS and L2TPv3 115 Pseudowire demultiplexors. 117 The CV Type indicator field is defined as a bitmask used to indicate 118 the specific CV type or types (i.e., none, one or more) of VCCV 119 packets that may be sent on the VCCV control channel. The values 120 shown below augment those already defined in [I-D.ietf-pwe3-vccv]. 121 They represent the numerical value corresponding to the actual bit 122 being set in the CV Type bitfield. 124 BFD CV Types: 126 The defined values for the different BFD CV Types for MPLS and 127 L2TPv3 PWs are: 129 Bit (Value) Description 130 ============ ========================================== 131 Bit 2 (0x04) - BFD for PW Fault Detection Only. 132 Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault 133 Status Signaling. 134 Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD 135 payload without IP/UDP headers. 136 Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault 137 Status Signaling, carrying BFD payload without 138 IP/UDP headers. 140 It should be noted that two pairs of BFD CV Types have been defined, 141 see Section 3.3. 143 3.1. BFD CV Type Operation 145 When heart-beat indication is necessary for one or more PWs, the 146 Bidirectional Forwarding Detection (BFD) [I-D.ietf-bfd-base] provides 147 a means of continuous monitoring of the PW data path and propagation 148 of forward and reverse defect indications. 150 In order to use BFD, both ends of the PW connection must have 151 signaled the existence of a control channel and the ability to run 152 BFD on it (see Section 3.3 and Section 4). Once a node has both 153 signaled and received signaling from its peer of these capabilities, 154 it begins sending BFD control packets. The packets are sent on the 155 VCCV control channel. The use of the control channel provides the 156 context required to bind and bootstrap the BFD session; the 157 Pseudowire demultiplexer field (e.g., MPLS PW Label or L2TPv3 Session 158 ID) provides the context to demultiplex the first BFD control packet, 159 and thus single-hop BFD initialization procedures are followed (see 160 Section 3 of [I-D.ietf-bfd-v4v6-1hop]). BFD MUST be run in 161 asynchronous mode (see [I-D.ietf-bfd-base]). 163 When the downstream PE (D-PE) does not receive control messages from 164 its upstream peer PE (U-PE) during a certain number of transmission 165 intervals (a number provisioned by the operator), D-PE declares that 166 the PW in its receive direction is down. In other words, D-PE enters 167 the "forward defect" state for this PW. D-PE then sends a message to 168 U-PE with H=0 (i.e., "I do not hear you") and with Diagnostic code 1. 169 In turn, U-PE declares the PW is down in its transmit direction and 170 it uses Diagnostic code 3 in its control messages to D-PE. U-PE 171 enters the "reverse defect" state for this PW. How it further 172 processes this error condition, and conveys this status the 173 attachment circuits is out of the scope of this specification, and is 174 instead defined in [I-D.ietf-pwe3-oam-msg-map]. 176 The VCCV message comprises a BFD packet [I-D.ietf-bfd-base] 177 encapsulated as specified by the CV Type (see Section 3.2). 179 3.2. BFD Encapsulation 181 This document defines two pairs of BFD CV Types (see Section 3) which 182 specify two ways in which a BFD connectivity verification packet may 183 be encapsulated over the VCCV control channel. Table 1 in 184 Section 3.3 summarizes the BFD CV Types. 186 When the BFD CV Type used is either 0x04 or 0x08, the VCCV 187 encapsulation of BFD includes the IP/UDP headers as defined in 188 Section 4 of [I-D.ietf-bfd-v4v6-1hop]. The IP Protocol Number and 189 UDP Port numbers discriminate among the possible VCCV payloads (i.e., 190 differentiate among ICMP Ping and LSP Ping defined in 191 [I-D.ietf-pwe3-vccv] and BFD). 193 However, when BFD CV Types of 0x10 or 0x20 are employed, the IP/UDP 194 headers are omitted from the BFD encapsulation. Therefore, these BFD 195 CV Types can only be used when the Pseudowire utilizes a Control Word 196 (CW) or Layer-2 Specific Sublayer (L2SS) that can take the PW 197 Associated Channel Header (PW-ACH) Control Word format. The PW 198 Associated Channel (PW-AC) is defined in Section 5 of [RFC4385], and 199 its Channel Type field is used as a payload type identifier to 200 discriminate the VCCV payload types. The usage of the PW-AC for VCCV 201 is specified in Sections 5.1.1, 5.1.2 and 5.1.3 of 202 [I-D.ietf-pwe3-vccv]. When VCCV carries raw BFD, the Pseudowire CW's 203 or L2SS' Channel Type MUST be set to 0x0007 to indicate "BFD Without 204 IP/UDP Headers" (see Section 5.2), to allow the identification of the 205 encased BFD payload when demultiplexing the control channel. 207 In summary, if a PW Associated Channel Header is used, the Channel 208 Type can indicate IPv4 (0x0021) or IPv6 (0x0057) for CV Types 0x04 209 and 0x08, or BFD without IP/UDP headers (0x0007) for CV Types 0x10 210 and 0x20. 212 3.3. CV Types for BFD 214 Two distinctive pairs of CV Types are defined for BFD. Table 1 215 summarizes the BFD CV Types, grouping them by encapsulation (i.e., 216 with and without IP/UDP headers) and by functionality (i.e., fault 217 detection only, or fault detection and status signaling). 219 +---------------------+-----------------+---------------------------+ 220 | | Fault Detection | Fault Detection and | 221 | | Only | Status Signaling | 222 +---------------------+-----------------+---------------------------+ 223 | BFD with IP/UDP | 0x04 | 0x08 | 224 | Headers | | | 225 | | | | 226 | BFD without IP/UDP | 0x10 | 0x20 | 227 | Headers | | | 228 +---------------------+-----------------+---------------------------+ 230 Table 1: Bitmask Values for BFD CV Types 232 Given the bidirectional nature of BFD, before selecting a given BFD 233 CV Type capability to be used, there MUST be a match in the given CV 234 Type capability advertised and received. That is, only BFD CV Types 235 that were both advertised and received are available to be selected. 236 Additionally, only one BFD CV Type can be used (selecting a BFD CV 237 Type excludes all the remaining BFD CV Types). 239 The following list enumerates restrictions and their corollaries on 240 the usage of BFD CV Types: 242 1. CV Types 0x08 and 0x20, SHOULD NOT be used when a control 243 protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available 244 that can signal the AC/PW status to the remote endpoint of the 245 PW. 247 A. In the case of CV Type 0x08 or 0x20, the AC and PW status is 248 conveyed via BFD status codes as specified in 249 [I-D.ietf-pwe3-oam-msg-map]. 251 2. Similarly, CV Types 0x04 and 0x10 SHOULD NOT be used when there 252 is no control protocol available to signal the AC/PW status. 254 A. In the case of type 0x04 or 0x10, BFD is used exclusively to 255 detect faults on the PW and the status of those faults are to 256 be conveyed using some means other than BFD, such as using 257 LDP status messages when using MPLS as a transport (see 258 Section 5.4 of [RFC4447]), or the Circuit Status AVP in an 259 L2TPv3 SLI message for L2TPv3 (see Section 5.4.5 of 260 [RFC3931]). 262 3. Only a single BFD CV Type can be seleced and used. 264 4. Capability Selection 266 The precedence rules for selection of various CC and CV types is 267 clearly outlined in Section 7 of [I-D.ietf-pwe3-vccv]. This section 268 augments these rules when the BFD CV types defined herein are 269 supported. The selection of a specific BFD CV Type to use out of the 270 four available CV Types defined is tied to multiple factors, as 271 detained in Section 3.3. Given that BFD is bidirectional in nature, 272 only CV Types that are both received and sent in VCCV capability 273 signaling advertisement can be selected. 275 As already enumerated, when a control protocol that can signal the 276 AC/PW status is not available, CV Types CV Types 0x04 and 0x10 (i.e., 277 for Fault Detection only) SHOULD NOT be used. When a control 278 protocol that can signal the AC/PW status (such as LDP [RFC4447] or 279 L2TPv3 [RFC3931]) is available, CV Types 0x08 and 0x20 (i.e., for 280 Fault Detection and Status Signaling) SHOULD NOT be used. All BFD CV 281 Types are mutually exclusive with the rest, selecting a BFD CV Type 282 prevents the use of any of the other three BFD CV Types. 284 Finally, only Pseudowires that use a CW or L2SS using the PW 285 Associated Channel Header support the use of BFD CV Types 0x10 or 286 0x20 (i.e., encapsulation of BFD without IP/UDP headers), and 287 consequently the their concurrent use along with another CV Type that 288 uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping). 289 PWs that use a PW-ACH include CC Type 1 (for both MPLS and L2TPv3 as 290 defined in Sections 5.1.1 and 6.1 of [I-D.ietf-pwe3-vccv]), and MPLS 291 CC Types 2 and 3 when using a Control Word (as specified in Sections 292 5.1.2 and 5.1.3 of [I-D.ietf-pwe3-vccv]). This restriction stems 293 from the fact that the PW-ACH contains a Protocol Identification 294 (PID) field, the Channel Type. 296 5. IANA Considerations 298 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV 300 The VCCV Interface Parameters Sub-TLV codepoint is defined in 301 [RFC4446], and the VCCV CV Types registry is defined in 302 [I-D.ietf-pwe3-vccv]. This section lists the new BFD CV Types. 304 IANA is requested to augment the "VCCV Connectivity Verification 305 Types" registry in the Pseudo Wires Name Spaces, reachable from 306 [IANA.pwe3-parameters]. These are bitfield values. CV Type values 307 0x04 0x08, 0x10 and 0x20 are specified in Section 3. 309 MPLS Connectivity Verification (CV) Types: 311 Bit (Value) Description 312 ============ ========================================== 313 Bit 2 (0x04) - BFD for PW Fault Detection Only. 314 Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault Status 315 Signaling. 316 Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD 317 payload without IP/UDP headers. 318 Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault Status 319 Signaling, carrying BFD payload without IP/UDP 320 headers. 322 5.2. PW Associated Channel Type 324 The PW Associated Channel Types used by VCCV rely on previously 325 allocated numbers from the Pseudowire Associated Channel Types 326 Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from 327 [IANA.pwe3-parameters]. In particular, 0x21 (Internet Protocol 328 version 4) is used whenever an IPv4 payload follows the Pseudowire 329 Associated Channel Header, or 0x57 is used when an IPv6 payload 330 follows the Pseudowire Associated Channel Header. 332 In cases where raw BFD follows the Pseudowire Associated Channel as 333 specified in Section 3.2 (i.e., when the IP/UDP encapsulation as 334 specified in [I-D.ietf-bfd-v4v6-1hop] is be present), a new 335 Pseudowire Associated Channel Types Registry [RFC4385] entry of 0x07 336 is used. IANA is requested to reserve a new Pseudowire Associated 337 Channel Type value as follows: 339 Value (in hex) Protocol Name Reference 340 -------------- ------------------------------- --------- 342 0x0007 BFD Without IP/UDP Headers [This document] 344 5.3. L2TPv3 CV Types for the VCCV Capability AVP 346 This section lists the new BFD CV Types to be added to the existing 347 "VCCV Capability AVP" registry in the L2TP name spaces. The Layer 348 Two Tunneling Protocol "L2TP" Name Spaces are reachable from 349 [IANA.l2tp-parameters]. 351 IANA is requested to reserve the following L2TPv3 Connectivity 352 Verification (CV) Types in the VCCV Capability AVP Values registry. 354 VCCV Capability AVP (Attribute Type AVP-TBD) Values 355 --------------------------------------------------- 357 L2TPv3 Connectivity Verification (CV) Types: 359 Bit (Value) Description 360 ============ ========================================== 361 Bit 2 (0x04) - BFD for PW Fault Detection Only. 362 Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault 363 Status Signaling. 364 Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD 365 payload without IP/UDP headers. 366 Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault 367 Status Signaling, carrying BFD payload without 368 IP/UDP headers. 370 6. Congestion Considerations 372 The congestion considerations that apply to [I-D.ietf-pwe3-vccv] 373 apply to this mode of operation as well. 375 7. Security Considerations 377 Routers that implement the additional CV Types defined herein are 378 subject to the same security considerations as defined in 379 [I-D.ietf-pwe3-vccv], [I-D.ietf-bfd-base], and 380 [I-D.ietf-bfd-v4v6-1hop]. 382 8. Acknowledgements 384 This work forks from a previous revision of the PWE3 WG document 385 [I-D.ietf-pwe3-vccv], to which a number of people contributed, 386 including Rahul Aggarwal, Peter B. Busschbach, Yuichi Ikejiri, Kenji 387 Kumaki, Luca Martini, Monique Morrow, George Swallow, and others. 389 9. References 391 9.1. Normative References 393 [I-D.ietf-bfd-base] 394 Katz, D. and D. Ward, "Bidirectional Forwarding 395 Detection", draft-ietf-bfd-base-06 (work in progress), 396 March 2007. 398 [I-D.ietf-bfd-v4v6-1hop] 399 Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single 400 Hop)", draft-ietf-bfd-v4v6-1hop-06 (work in progress), 401 March 2007. 403 [I-D.ietf-pwe3-vccv] 404 Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 405 Connectivity Verification (VCCV) A Control Channel for 406 Pseudowires", draft-ietf-pwe3-vccv-15 (work in progress), 407 September 2007. 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 413 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 414 Use over an MPLS PSN", RFC 4385, February 2006. 416 9.2. Informative References 418 [I-D.ietf-pwe3-oam-msg-map] 419 Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping", 420 draft-ietf-pwe3-oam-msg-map-05 (work in progress), 421 March 2007. 423 [IANA.l2tp-parameters] 424 Internet Assigned Numbers Authority, "Layer Two Tunneling 425 Protocol "L2TP"", April 2007, 426 . 428 [IANA.pwe3-parameters] 429 Internet Assigned Numbers Authority, "Pseudo Wires Name 430 Spaces", June 2007, 431 . 433 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 434 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 436 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 437 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 439 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 440 Heron, "Pseudowire Setup and Maintenance Using the Label 441 Distribution Protocol (LDP)", RFC 4447, April 2006. 443 Authors' Addresses 445 Thomas D. Nadeau (editor) 446 BT 447 BT Centre 448 81 Newgate Street 449 London, EC1A 7AJ 450 United Kingdom 452 Email: thomas.nadeau@bt.com 454 Carlos Pignataro (editor) 455 Cisco Systems, Inc. 456 7200 Kit Creek Road 457 PO Box 14987 458 Research Triangle Park, NC 27709 459 USA 461 Email: cpignata@cisco.com 463 Full Copyright Statement 465 Copyright (C) The IETF Trust (2007). 467 This document is subject to the rights, licenses and restrictions 468 contained in BCP 78, and except as set forth therein, the authors 469 retain all their rights. 471 This document and the information contained herein are provided on an 472 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 473 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 474 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 475 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 476 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 477 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 479 Intellectual Property 481 The IETF takes no position regarding the validity or scope of any 482 Intellectual Property Rights or other rights that might be claimed to 483 pertain to the implementation or use of the technology described in 484 this document or the extent to which any license under such rights 485 might or might not be available; nor does it represent that it has 486 made any independent effort to identify any such rights. Information 487 on the procedures with respect to rights in RFC documents can be 488 found in BCP 78 and BCP 79. 490 Copies of IPR disclosures made to the IETF Secretariat and any 491 assurances of licenses to be made available, or the result of an 492 attempt made to obtain a general license or permission for the use of 493 such proprietary rights by implementers or users of this 494 specification can be obtained from the IETF on-line IPR repository at 495 http://www.ietf.org/ipr. 497 The IETF invites any interested party to bring to its attention any 498 copyrights, patents or patent applications, or other proprietary 499 rights that may cover technology that may be required to implement 500 this standard. Please address the information to the IETF at 501 ietf-ipr@ietf.org. 503 Acknowledgment 505 Funding for the RFC Editor function is provided by the IETF 506 Administrative Support Activity (IASA).