idnits 2.17.1 draft-atlas-icmp-unnumbered-04.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 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 580. 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 (Nov 16, 2007) is 6004 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet A. Atlas, Ed. 3 Internet-Draft BT 4 Expires: May 19, 2008 R. Bonica 5 Juniper Networks 6 JR. Rivers 7 Nuova Systems 8 N. Shen 9 E. Chen 10 Cisco Systems 11 Nov 16, 2007 13 Extending ICMP to Identify the Receiving Interface 14 draft-atlas-icmp-unnumbered-04 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/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 19, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This memo defines ICMP extensions, using ICMP multi-part messages, 48 through which a router or host can explicitly identify the interface 49 upon which an undeliverable datagram anrrived. The incoming 50 interface can be identified by ifIndex, name, and/or address, as 51 already used in MIBs and by OSPF. The extensions defined herein are 52 particularly useful when troubleshooting networks with unnumbered 53 interfaces, parallel interfaces and/or asymmetric routing. 55 Table of Contents 57 1. Conventions Used In This Document . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Application to TRACEROUTE . . . . . . . . . . . . . . . . 4 61 3.2. Policy and MTU Detection . . . . . . . . . . . . . . . . . 4 62 4. Interface Information Object . . . . . . . . . . . . . . . . . 5 63 4.1. C-type meaning in an Interface Information Object . . . . 5 64 4.2. Interface Name Sub-Object . . . . . . . . . . . . . . . . 7 65 4.3. Interface Information Object Description . . . . . . . . . 8 66 4.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Intellectual Property and Copyright Statements . . . . . . . . . . 14 76 1. Conventions Used In This Document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC2119 [RFC2119]. 82 2. Introduction 84 IP devices use the Internet Control Message Protocol (ICMP) [RFC0792] 85 (ICMPv6) [RFC4443] to convey control information. In particular, 86 when an IP device receives a datagram that it cannot forward, it may 87 send an ICMP message to the datagram's originator. Network operators 88 and higher level protocols use these ICMP messages to detect and 89 diagnose network issues. 91 In the nominal case, the source address of the ICMP message 92 identifies the interface upon which the non-forwardable datagram 93 arrived. However, in many cases, the incoming interface is not 94 identified by the ICMP message at all. Details follow: 96 According to RFC1812 [RFC1812], when a router generates an ICMP 97 message, the source address of that ICMP message MUST be one of the 98 following: 100 o one of the IP addresses associated with the physical interface 101 over which the ICMP message is transmitted 102 o if that interface has no IP addresses associated with it, the 103 device's router-id or host-id is used instead. 105 If the following conditions are true, the source address of the ICMP 106 message identifies the interface upon which the non-forwardable 107 datagram arrived: 109 o the device originates an ICMP message through the same interface 110 upon which the non-forwardable datagram was received. 111 o that interface is numbered. 113 However, the transmitting and incoming interfaces may be different 114 due to an asymmetric return path, which can occur due to asymmetric 115 link costs, parallel links or ECMP. 117 For ICMPv6, the asymmetric issues need not be an issue, since there 118 is more flexibility for ICMPv6, as defined in RFC4443 [RFC4443]. For 119 responses to messages sent to addresses that aren't the router's, the 120 source address must be chosen as follows: 122 o the Source Address of the ICMPv6 packet MUST be a unicast address 123 belonging to the node. The address SHOULD be chosen according to 124 the rules that would be used to select the source address for any 125 other packet originated by the node, given the destination address 126 of the packet. However, it MAY be selected in an alternative way 127 if this would lead to a more informative choice of address 128 reachable from the destination of the ICMPv6 packet. 130 For both ICMP and ICMPv6, when a network uses unnumbered interfaces, 131 it is not possible to identify the incoming interface. The 132 extensions defined in this memo permit an ICMP originator to identify 133 the interface through which the datagram that elicited the ICMP 134 messages arrived. 136 Using the extension defined herein, an IP device can explicitly 137 identify the incoming interface by any or all of the following: 139 o IPv4 address 140 o IPv6 address 141 o name 142 o ifIndex 144 Using the extension defined herein, an IP device can explicitly 145 identify by the above the outgoing interface over which a datagram 146 would have been forwarded if that datagram had been deliverable. 147 This can be used for creating a downstream map. 149 The extensions defined herein use the ICMP multi-part message 150 framework defined in [RFC4884]. The same backward compatibility 151 issues that apply to [RFC4884] apply to these extensions. 153 3. Applications 155 3.1. Application to TRACEROUTE 157 ICMP extensions defined in this memo require enhancements ([RFC4884]) 158 and provide additional capability to TRACEROUTE. The enhanced 159 TRACEROUTE application, like older implementations, indicates which 160 nodes the original datagram visited en route to its destination. It 161 differs from older implementations in that it also reflects the 162 incoming interface on which the original triggering packet arrived, 163 even when that interface is unnumbered. 165 3.2. Policy and MTU Detection 167 A general application would be to identify which outgoing interface 168 triggered a given function for the original packet. For example, if 169 an ACL drops the packet and Dest Unreachable/Admin Prohibited denies 170 the packet, being able to identify that might be useful. Another 171 example would be support PMTU, since this would allow identification 172 of which outgoing interface can't support a given MTU size. 174 4. Interface Information Object 176 This section defines an ICMP extension object that can be appended to 177 the ICMPv4 Time Exceeded, ICMPv4 Destination Unreachable, ICMPv4 178 Parameter Problem, ICMPv6 Time Exceeded, and ICMPv6 Destination 179 Unreachable messages, as described in [RFC4884]. For the description 180 of the Interface Information Object, the incoming interface is the 181 one upon which the packet which triggered the ICMP message was 182 received. If desired, information about a sub-IP member of the 183 incoming interface can be included. An example of such a sub-IP 184 member would be a member of an Ethernet Link Aggregation Group that 185 forms the incoming interface. To minimize the use of extra octets 186 required for this extension, there are four different pieces of 187 information that can appear in an Interface Information Object. 189 1. If the interface of interest has at least one IPv4 address and 190 the triggering packet was IPv4, then one of the interface's IPv4 191 addresses MAY be included. 192 2. If the interface of interest has at least one IPv6 address and 193 the triggering packet was IPv6, then one of the interface's IPv6 194 addresses MAY be included. 195 3. The ifIndex of the interface of interest MAY be included. This 196 is the ifIndex assigned to the interface by the router in as 197 specified by the Interfaces Group MIB [RFC2863]. 198 4. An Interface Name Sub-Object, containing a string of no more than 199 62 octets, MAY be included. 201 4.1. C-type meaning in an Interface Information Object 203 For this object, the c-type is split into two fields, a 2-bit 204 interface-role field and a 6-bit included-information field. This is 205 illustrated below. 207 Bit 7 6 | 5 4 3 2 1 0 208 +-------+-------+-------+-------+-------+-------+-------+-------+ 209 | Interface Role| Rsvd | Rsvd | index | IP | Rsvd | descr | 210 +-------+-------+-------+-------+-------+-------+-------+-------+ 212 Interface Role: This 2-bit field [6:7] indicates the role of the 213 interface being identified. The enumerated values 214 are given below. 215 0 : This object describes the incoming interface. 216 1 : This object describes the outgoing interface. 217 2 : This object describes a sub-IP member of the 218 incoming interface. 219 3 : Reserved 221 Included Information: This 6-bit field [0:5] indicates what 222 information is included in the object. The 223 information must be included in the same order 224 as the bits (leftmost, from highest, 5, to 225 lowest, 0,). 227 bit 228 5 : This bit is reserved for future use and MUST be set to 0 and 229 MUST be ignored on receipt. 231 4 : This bit is reserved for future use and MUST be set to 0 and 232 MUST be ignored on receipt. 234 3 : When set, this bit indicates the ifIndex of the interface 235 is included. When clear, the ifIndex is not included. 237 2 : When set, this indicates an IP address of the interface 238 is included. When clear, no IP address is included. The 239 version of the IP packet containing the ICMP message will 240 indicate the type of IP address. An IPv4 packet will have an 241 IPv4 address and an IPv6 packet will have an IPv6 address. 243 1 : This bit is reserved for future use and MUST be set to 0 and 244 MUST be ignored on receipt. 246 0 : When set, this indicates an Interface Name Sub-object for 247 the interface is included. When clear, it is not included. 249 Figure 1: C-Type for the Interface Information Object 251 The information/sub-objects MUST be sent and received inside the 252 Interface Information Object in the order that they are listed in the 253 final 6-bits included-information field. With the exception of the 254 Interface Name sub-object, the information included does not self- 255 identify, so this is required to ensure correct parsing. 257 The sender of an Interface Information Object MUST NOT set the 258 Interface Role to 3 and an Interface Role value of 3 MUST be ignored 259 on receipt and the Interface Information Object discarded. It is 260 valid (though pointless until additional bits are assigned by IANA) 261 to receive an Interface Information Object where bits 3,2, and 0 are 262 all 0; this MUST NOT generate a warning or error. 264 4.2. Interface Name Sub-Object 266 The Interface Name Sub-Object MUST have a length that is a multiple 267 of 4 octets and MUST NOT exceed 64 octets. A one octet "charset 268 type" and a one octet "length" are required and the interface name 269 can be at most 62 octets long. The interface name SHOULD be the 270 MIB-II ifName [RFC2863] but MAY be some other human-meaningful name 271 of the interface. It is useful to rovide the ifName for cross- 272 correlation with other MIB information and for human-reader 273 familiarity. 275 The Interface Name Sub-Object consists of three fields. The first 276 1-octet field indicates the character set type used by the second 277 field. The second field contains the length of the Interface name 278 Sub-object, including the charset type, the length, and the human- 279 readable name in octets. The maximum valid length is 64 octets. The 280 length is constrained to ensure there is space for the start of the 281 original packet and additional information. The third field contains 282 the human-readable name. 284 octet 0 1 2 63 285 +--------------+--------+---..............-----------------+ 286 | charset type | length | interface name octets 1-62 | 287 +--------------+--------+---..............-----------------+ 289 Figure 2: Interface Name Sub-Object 291 charset type 0 : This indicates that the human-readable interface 292 name MUST be provided in the US-ASCII charset [US-ASCII] using the 293 Default Language [RFC2277]. 295 charset type 1 : This indicates that the human-readable interface 296 name MUST be provided in the UTF-8 charset [RFC3629] using the 297 Default Language [RFC2277]. 299 4.3. Interface Information Object Description 301 Figure 3 shows a full ICMPv4 Time Exceeded message, including the 302 Interface Information Object, which must be preceded by an ICMP 303 Extension Structure Header and an ICMP Object Header. Both are 304 defined in [RFC4884]. 306 Figure 4 depicts the Interface Information Object, with two of the 307 valid permutations. 309 Although all examples show an Interface Name Sub-object of length 64, 310 this is only for illustration and depicts the maximum allowable 311 length. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type | Code | Checksum | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | unused | Length | unused | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Internet Header + leading octets of original datagram | 321 | | 322 | // | 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Ver=2 | (Reserved) | Checksum | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Length | Class-Num=2 | C-Type=9 | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Interface ifIndex | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Interface Name, 32-bit word 1 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 ... ... 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Interface Name , 32-bit word 16 | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 3: ICMPv4 Time Exceeded message with Interface Information 339 Object 341 Class-Num = 2 343 Example 1: Unnumbered Interface with ifIndex and interface name 344 C-Type = 00001001b // Indicates incoming interface 345 Length = 40 (4 + 4 + 32) 347 0 1 2 3 348 +--------------+--------------+--------------+--------------+ 349 | Interface ifIndex | 350 +--------------+--------------+--------------+--------------+ 351 | Interface Name, 32-bit word 1 | 352 +--------------+--------------+--------------+--------------+ 353 ... ... 354 +--------------+--------------+--------------+--------------+ 355 | Interface Name , 32-bit word 16 | 356 +--------------+--------------+--------------+--------------+ 358 Example 2: IPv4 interface with IPv4 address, 359 ifIndex and interface name 361 C-Type = 00001101b // Indicates incoming interface 362 Length = 44 (4 + 4 + 4 + 32) 364 0 1 2 3 365 +--------------+--------------+--------------+--------------+ 366 | Interface ifIndex | 367 +--------------+--------------+--------------+--------------+ 368 | IPv4 address | 369 +--------------+--------------+--------------+--------------+ 370 | Interface Name, 32-bit word 1 | 371 +--------------+--------------+--------------+--------------+ 372 ... ... 373 +--------------+--------------+--------------+--------------+ 374 | Interface Name, 32-bit word 16 | 375 +--------------+--------------+--------------+--------------+ 377 Example 3: IPv6 interface with IPv6 address and ifIndex 379 C-Type = 00001100b // Indicates incoming interface 380 Length = 24 (4 + 4 + 16) 382 0 1 2 3 383 +--------------+--------------+--------------+--------------+ 384 | Interface ifIndex | 385 +--------------+--------------+--------------+--------------+ 386 | IPv6 address, 32-bit word 1 | 387 +--------------+--------------+--------------+--------------+ 388 | IPv6 address, 32-bit word 2 | 389 +--------------+--------------+--------------+--------------+ 390 | IPv6 address, 32-bit word 3 | 391 +--------------+--------------+--------------+--------------+ 392 | IPv6 address, 32-bit word 4 | 393 +--------------+--------------+--------------+--------------+ 395 Figure 4: Interface Information Object 397 4.4. Usage 399 For each interface described by an included Interface Information 400 Object, these are the rules for the information to be included. If 401 the interface in question is unnumbered, then the Interface 402 Information Object SHOULD include the ifIndex and SHOULD NOT include 403 an IP address. If the interface in question is numbered, then the 404 Interface Information Object SHOULD include the IP address. Other 405 fields MAY be included in the Interface Information Object. 407 In an ICMP message, more than one Interface Information Object with a 408 given interface role MUST NOT be included. Multiple Interface 409 Information Objects, each with a different interface role, MAY be 410 included. 412 5. Security Considerations 414 This extension can provide the user of traceroute with additional 415 network information that is not currently available. It may be 416 desirable to provide this information to a particular network's 417 operators and not to others. If such policy controls are desirable, 418 then an implementation could determine what sub-objects to include 419 based upon the destination IP address of the ICMP message that will 420 contain the sub-objects. 422 For instance, the IP address may be included for all potential 423 recipients. The ifIndex and interface name could be included as well 424 if the destination IP address is a management address of the network 425 that has administrative control of the router. 427 Another example use case would be where the detailed information in 428 these extensions may be provided to ICMP destinations within the 429 local administrative domain, but only traditional information is 430 provided to 'external' or untrusted ICMP destinations. 432 Another issue is when a device inside a private region generates an 433 ICMP message with some of these extensions and that ICMP message will 434 transit a NAT to reach its destination. A NAT may choose to remove 435 or overwrite the extensions. 437 6. IANA Considerations 439 IANA should should reserve from the ICMP Extension Object registry: 2 440 for the Interface Information Object. 442 From the Interface ID Object's c-type, IANA should reserve as 443 follows: 445 o Bit 0: Interface Name Sub-Object included 446 o Bit 1: Unallocated - allocatable with Standards Action 447 o Bit 2: IP address included 448 o Bit 3: ifIndex include 449 o Bit 4: Unallocated - allocatable with Standards Action 450 o Bit 5: Unallocated - allocatable with Standards Action 451 o Bit 6-7: Interface Role field 452 * Value 0: Incoming Interface 453 * Value 1: Outgoing Interface 454 * Value 2: Incoming Interface - Sub-IP Member 455 * Value 3: Unallocated - allocatable with Standards Action 457 Additionally, the Interface Name Sub-Object has a 1 octet charset 458 type field. IANA should create a registry for it and allocate as 459 follows: 461 o 0 : encoded in ASCII 462 o 1 : encoded in UTF-8 463 o 2-127: Unallocated - allocatable with Standards Action 464 o 128-255: Unallocated - allocated on first come basis. 466 7. Acknowledgements 468 The authors would like to thank Carlos Pignataro, Sasha Vainshtein, 469 and Joe Touch for their comments and suggestions. 471 8. References 473 8.1. Normative References 475 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 476 RFC 792, September 1981. 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 482 MIB", RFC 2863, June 2000. 484 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 485 Message Protocol (ICMPv6) for the Internet Protocol 486 Version 6 (IPv6) Specification", RFC 4443, March 2006. 488 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 489 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 490 April 2007. 492 8.2. Informative References 494 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 495 RFC 1812, June 1995. 497 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 498 Languages", BCP 18, RFC 2277, January 1998. 500 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 501 10646", STD 63, RFC 3629, November 2003. 503 [US-ASCII] 504 "Coded Character Set -- 7-bit American Standard Code for 505 Information Interchange, ANSI X3.4-1986". 507 Authors' Addresses 509 Alia K. Atlas (editor) 510 BT 512 Email: alia.atlas@bt.com 514 Ronald P. Bonica 515 Juniper Networks 516 2251 Corporate Park Drive 517 Herndon, VA 20171 518 USA 520 Email: rbonica@juniper.net 522 J.R. Rivers 523 Nuova Systems 525 Email: jrrivers@nuovasystems.com 526 Naiming Shen 527 Cisco Systems 528 225 West Tasman Drive 529 San Jose, CA 95134 530 USA 532 Email: naiming@cisco.com 534 Enke Chen 535 Cisco Systems 536 170 West Tasman Drive 537 San Jose, CA 95134 538 USA 540 Email: enkechen@cisco.com 542 Full Copyright Statement 544 Copyright (C) The IETF Trust (2007). 546 This document is subject to the rights, licenses and restrictions 547 contained in BCP 78, and except as set forth therein, the authors 548 retain all their rights. 550 This document and the information contained herein are provided on an 551 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 552 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 553 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 554 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 555 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 556 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 558 Intellectual Property 560 The IETF takes no position regarding the validity or scope of any 561 Intellectual Property Rights or other rights that might be claimed to 562 pertain to the implementation or use of the technology described in 563 this document or the extent to which any license under such rights 564 might or might not be available; nor does it represent that it has 565 made any independent effort to identify any such rights. Information 566 on the procedures with respect to rights in RFC documents can be 567 found in BCP 78 and BCP 79. 569 Copies of IPR disclosures made to the IETF Secretariat and any 570 assurances of licenses to be made available, or the result of an 571 attempt made to obtain a general license or permission for the use of 572 such proprietary rights by implementers or users of this 573 specification can be obtained from the IETF on-line IPR repository at 574 http://www.ietf.org/ipr. 576 The IETF invites any interested party to bring to its attention any 577 copyrights, patents or patent applications, or other proprietary 578 rights that may cover technology that may be required to implement 579 this standard. Please address the information to the IETF at 580 ietf-ipr@ietf.org. 582 Acknowledgment 584 Funding for the RFC Editor function is provided by the IETF 585 Administrative Support Activity (IASA).