idnits 2.17.1 draft-ietf-6lowpan-problem-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 537. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (February 24, 2006) is 6636 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: 'I-D.ietf-ipv6-2461bis' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'RFC3756' is defined on line 494, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-05 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802.15.4' Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Kushalnagar 3 Internet-Draft Intel Corp 4 Expires: August 28, 2006 G. Montenegro 5 Microsoft Corporation 6 February 24, 2006 8 6LoWPAN: Overview, Assumptions, Problem Statement and Goals 9 draft-ietf-6lowpan-problem-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 28, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes the assumptions, problem statement and goals 43 for transmitting IP over IEEE 802.15.4 networks. The set of goals 44 enumerated in this document form an initial set only. Additional 45 goals may be found necessary over time and may be added to this 46 document. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 52 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. IP Connectivity . . . . . . . . . . . . . . . . . . . . . 5 56 4.2. Topologies . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.3. Limited Packet Size . . . . . . . . . . . . . . . . . . . 6 58 4.4. Limited configuration and management . . . . . . . . . . . 6 59 4.5. Service discovery . . . . . . . . . . . . . . . . . . . . 7 60 4.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Intellectual Property and Copyright Statements . . . . . . . . . . 14 71 1. Introduction 73 Low-power wireless personal area networks (LoWPANs) comprise devices 74 that conform to the IEEE 802.15.4-2003 standard by the IEEE 75 [ieee802.15.4]. The IEEE 802.15.4 devices are characterized by short 76 range, low bit rate, low power and low cost. 78 This document gives an overview of LoWPANs and describes how they 79 benefit from IP and IPv6 networking. It describes the requirements 80 of LoWPANs with regards to IP layer and above. It spells out the 81 underlying assumptions of IP for LoWPANs. Finally, it describes 82 problems associated with enabling IP communication between devices in 83 LoWPAN, and defines goals to address these in a prioritized manner. 84 Admittedly, not all items on this list are necessarily appropriate 85 tasks for the IETF. Nevertheless, they are documented here to give a 86 general overview of the larger problem. This is useful both to 87 structure work within the IETF as well as to understand better how to 88 coordinate with external organizations. 90 1.1. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Overview 98 A LoWPAN is a simple low cost communication network that allows 99 wireless connectivity in applications with limited power and relaxed 100 throughput requirements. A LoWPAN typically includes devices that 101 work together to connect the physical environment to real-world 102 applications, e.g., wireless sensors. LoWPANs conform to the IEEE 103 802.15.4-2003 standard. [ieee802.15.4]. 105 Some of the characteristics of LoWPANs are: 107 1. Small packet size. Given that the maximum physical layer packet 108 is 127 bytes, the resulting maximum frame size at the media 109 access control layer is 102 octets. Link-layer security imposes 110 further overhead, which in the maximum case (21 octets of 111 overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 112 and AES-CCM-64, respectively) leaves 81 octets for data packets. 114 2. Support for both 16-bit short or IEEE 64-bit extended media 115 access control addresses. 117 3. Low bandwidth. Data rates of 250 kbps, 40 kbps and 20 kbps for 118 each of the currently defined physical layers (2.4 GHz, 915 MHz 119 and 868 MHz, respectively). 121 4. Topologies include star and mesh operation. 123 5. Low power, typically some or all devices are battery operated. 125 6. Low cost, typically associated with sensors, switches, etc. 126 These drive some of the other characteristics such as low 127 processing, low memory, etc. Numerical values for "low" have 128 not been explicitly mentioned here as historically the costs 129 tend to change over time. 131 7. Large number of devices expected to be deployed during the life- 132 time of the technology. This number is expected to dwarf the 133 number of deployed personal computers, for example. 135 8. Location of the devices are typically not predefined, thus these 136 devices are deployed in an adhoc fashion. Furthermore, 137 sometimes the location of these devices may not be easily 138 accessible. Additionally these devices may move to new 139 locations. 141 9. Devices within LoWPANs have a higher possibility of being 142 unreliable due to variety of reasons: uncertain radio 143 connectivity, battery drain, device lockups, physical tampering, 144 etc. 145 10. Devices within LoWPANs have a higher possibility of being 146 unavailable because often these devices are in sleep mode or in 147 a power down mode to conserve power. 149 The following sections take into account these characteristics in 150 describing the assumptions, problems statement and goals for LoWPANs. 152 3. Assumptions 154 Given the small packet size of LoWPANs, this document presumes 155 applications typically send small amounts of data. However, the 156 protocols themselves do not restrict bulk data transfers. 158 LoWPANs as described in this document are based on IEEE 802.15.4- 159 2003. It is possible that the specification may undergo changes in 160 the future and may change some of the requirements mentioned above. 162 Some of these assumptions are based on the limited capabilities of 163 devices within LoWPANs. As devices become more powerful, and consume 164 less power, some of the requirements mentioned above may be somewhat 165 relaxed. 167 Nevertheless, not all devices in a LoWPAN are expected to be 168 extremely limited. This is true of so-called "Reduced Function 169 Devices" (RFDs), but not necessarily of "Full Function Devices" 170 (FFDs). These will also be present albeit in much smaller numbers, 171 and will typically have more resources and be mains powered. 172 Accordingly, FFDs will aid RFDs by providing functions such as 173 network coordination, packet forwarding, interfacing with other types 174 of networks, etc. 176 IP technology is assumed to provide the following benefits: 178 1. The pervasive nature of IP networks allows use of existing 179 infrastructure. 180 2. IP based technologies already exist, are well known and proven to 181 be working. 182 3. An admittedly non-technical but important consideration is that 183 intellectual property conditions for IP networking technology are 184 either more favorable or at least better understood than 185 proprietary and newer solutions. 186 4. Tools for diagnostics, management and commissioning of IP 187 networks already exists. 188 5. IP based devices can more easily be connected to other IP based 189 networks, without the need for translation gateways and the like. 191 4. Problems 193 Based on the characteristics defined in the overview section, the 194 following sections elaborate on the main problems with IP for LoWPANs 195 Note that a common underlying goal is to reduce packet overhead, 196 bandwidth consumption, and processing requirements. 198 4.1. IP Connectivity 200 The requirement for IP connectivity within a LoWPAN is driven by the 201 following: 203 1. The many devices in a LoWPAN make network auto configuration and 204 statelessness highly desirable. And for this, IPv6 has ready 205 solutions. 206 2. The large number of devices poses the need for a large address 207 space, well met by IPv6. 208 3. Given the limited packet size of LoWPANs, the IPv6 address format 209 allows subsuming of IEEE 802.15.4 addresses if so desired. 211 4. Simple interconnectivity to other IP networks including the 212 Internet. 214 However, given the limited packet size, headers for IPv6 and above 215 layers must be compressed whenever possible. 217 4.2. Topologies 219 LoWPANs must support various topologies including mesh and star. 221 Mesh topologies imply multi-hop routing, to a desired destination. 222 In this case, intermediate devices act as packet forwarders at the 223 link layer (akin to routers at the network layer). Typically these 224 are "full function devices" that has more capabilities in terms of 225 power, computation, etc. The requirements that apply on the chosen 226 routing protocol are: 228 1. Given the minimal packet size of LoWPANs, the routing protocol 229 must impose low (or no) overhead on data packets, hopefully 230 independently of the number of hops. 231 2. The routing protocols should have low routing overhead (less 232 chatty) balanced with topology changes and power conservation. 233 3. The computation and memory requirements in the routing protocol 234 should be minimal to satisfy low cost and low power 235 characteristics. Thus storage and maintaining of large routing 236 tables may be detrimental. 238 As with mesh topologies, star topologies include provisioning a 239 subset of devices with packet forwarding functionality. If, in 240 addition to IEEE 802.15.4, these devices use other kinds of network 241 interfaces such as ethernet, IEEE 802.11, etc., the goal is to 242 seamlessly integrate the networks built over those different 243 technologies. This, or course, is a primary motivation to use IP to 244 begin with. 246 4.3. Limited Packet Size 248 Applications within LoWPANs are expected to originate small packets. 249 Adding all layers for IP connectivity should still allow transmission 250 in one frame without incurring excessive fragmentation and 251 reassembly. Furthermore, protocols must be designed or chosen so 252 that the individual "control/protocol packets" fit within a single 253 802.15.4 frame. 255 4.4. Limited configuration and management 257 As alluded to above, devices within LoWPANs are expected to be 258 deployed in exceedingly large numbers. Additionally, they are 259 expected to have limited display and input capabilities. 260 Furthermore, the location of some of these devices may be hard to 261 access. As such, protocols designed for LoWPANs should have minimal 262 configuration, preferably work "out of the box", provide easy 263 bootstrapping, and the network should be able to self heal given the 264 inherent unreliable characteristic of these devices. The network 265 management should have less overhead yet be powerful to control dense 266 deployment of devices. 268 4.5. Service discovery 270 LoWPANs require simple service discovery network protocols to 271 discover, control and maintain services provided by devices. In some 272 cases, especially in dense deployments, abstraction of several nodes 273 to provide a service may be beneficial. In order to enable such 274 features, new protocols may have to be designed. 276 4.6. Security 278 Security for LoWPAN devices must be carefully considered depending 279 upon the application needs. IEEE 802.15.4 provides AES link layer 280 security. Due to the nature of 6LoWPAN devices, security solutions 281 that need excessive computing, or bandwidth may not be suitable for 282 LoWPAN devices. Please refer to security consideration section below 283 for an in depth requirements for security. 285 5. Goals 287 Goals mentioned here may point at relevant work that can be done 288 within the IETF (e.g., specification required to transmit IP, profile 289 of best practices for transmitting IP packets, and associated upper 290 level protocols, etc). It may also point at work to be done in other 291 standards bodies that exist or may exist in the future (e.g., 292 desirable changes or profiles relevant to IEEE 802.15.4, W3C, etc). 293 When the goals fall under the IETF's purview, they serve to point out 294 what those efforts should strive to accomplish. Regardless of 295 whether they are pursued within one (or more) new (or existing) 296 working groups. When the goals do not fall under the purview of the 297 IETF, documenting them here serves as input to those other 298 organizations [liaison]. 300 The following are the goals according to priority for LoWPANs: 302 1. As mentioned in the overview, the protocol data units may be as 303 small 81 bytes. This is obviously far below the minimum IPv6 304 packet size of 1280 octets, and in keeping with section 5 of the 305 IPv6 specification [RFC2460], a fragmentation and reassembly 306 adaptation layer must be provided at the layer below IP. 308 2. Given that in the worst case the maximum size available for 309 transmitting IP packets over IEEE 802.15.4 frame is 81 octets, 310 and that the IPv6 header is 40 octets long, (without optional 311 headers), this leaves only 41 octets for upper-layer protocols, 312 like UDP and TCP. UDP uses 8 octets in the header and TCP uses 313 20 octets. This leaves 33 octets for data over UDP and 21 octets 314 for data over TCP. Additionally, as pointed above, there is also 315 a need for a fragmentation and reassembly layer, which will use 316 even more octets leaving very few octets for data. Thus if one 317 were to use the protocols as is, it would lead to excessive 318 fragmentation and reassembly even when data packets are just 10s 319 of octets long. This points to the need for header compression 320 As there is much published and in-progress standardization work 321 on header compression, this goal needs to investigate using 322 existing header compression techniques and if necessary specify 323 new ones. 325 3. [I-D.ietf-ipv6-rfc2462bis] specify methods for creating IPv6 326 stateless address auto configuration. Stateless auto 327 configuration has an advantage over stateful by having less 328 configuration overhead on the hosts suitable for LoWPANs. The 329 goal should specify a method to generate an "interface 330 identifier" from the EUI-64 [EUI64] assigned to the IEEE 802.15.4 331 device. 333 4. A routing protocol to support a multi-hop mesh network is 334 necessary. There is much published work on adhoc multi hop 335 routing for devices. Some examples include [RFC3561], [RFC3626], 336 [RFC3684], all experimental. Also, these protocols are designed 337 to use IP based addresses that have large overheads. For 338 example, the AODV [RFC3561] routing protocol uses 48 octets for a 339 route request based on IPv6 addressing. Given the packet size 340 constraints, transmitting this packet without fragmentation and 341 reassembly may be difficult. Thus care should be taken when 342 using existing protocols or designing new protocols for routing 343 so that the routing packets fit within a single IEEE 802.15.4 344 frame. 346 5. One of the points of transmitting IPv6 packets, is to reuse 347 existing protocols as much as possible. Network management 348 functionality is critical for LoWPANs. [RFC3411] specifies 349 SNMPv3 protocol operations. SNMP functionality may be translated 350 "as is" to LoWPANs. However, further investigation is required. 351 SNMPv3 may be found to be not suitable, or it may be only 352 suitable after adapting it appropriately. This adaptation could 353 include limiting the data types and simplifying the Basic 354 Encoding Rules so as to reduce the size and complexity of the 355 ASN.1 parser, thereby reducing the memory and processing needs to 356 better fit into the limited memory and power of LoWPAN devices. 358 6. It may be the case that transmitting IP over IEEE 802.15.4 would 359 become more beneficial if implemented in a "certain" way. 360 Accordingly, implementation considerations are to be documented. 362 7. As header compression becomes more prevalent, overall performance 363 will depend even more on efficiency of application protocols. 364 Heavyweight protocols based on XML such as SOAP [SOAP], may not 365 be suitable for LoWPANs. As such, more compact encodings (and 366 perhaps protocols) may become necessary. The goal here is to 367 specify or suggest modifications to existing protocols so that it 368 is suitable for LoWPANs. Furthermore, application level 369 interoperability specifications may also become necessary in the 370 future and may thus be specified. 372 8. Security threats at different layers must be clearly understood 373 and documented. Bootstrapping of devices into a secure network 374 could also be considered given the location, limited display, 375 high density and ad hoc deployment of devices. 377 6. IANA Considerations 379 This document contains no IANA considerations. 381 7. Security Considerations 383 6lowpan applications often require confidentiality and integrity 384 protection. This can be provided at the application or transport 385 level, at the network layer, and/or at the link layer, i.e. within 386 the 6lowpan set of specifications. In all these cases, 6LoWPAN 387 constraints will influence the choice of a particular protocol. Some 388 of the more relevant constraints are small code size, low power 389 operation, low complexity, and small bandwidth requirements. 391 It is understandable that these constraints have associated 392 tradeoffs. Thus a threat model for 6LoWPAN devices needs to be first 393 developed in order to weight any risks against the cost of security 394 and at the same time make meaningful assumptions and simplifications. 395 Some examples for threats that would be considered are man in the 396 middle attacks, denial of service attacks. 398 A separate set of security considerations might apply to 399 bootstrapping a 6lowpan device into the network, in particular 400 initial key establishment processes. This is generally involved with 401 other application level transactions and may rely on an application- 402 specific trust model; thus it will not be part of 6LoWPAN. Some 403 choices may be to use out of band communication techniques such as 404 USB, infrared or NFC (Near Field Communication) for the initial key 405 establishment. 407 After the initial key establishment, subsequent key management 408 protocols would fall under the purview of 6LoWPAN. In order to be 409 able to select (or design) this next set of protocols, there needs to 410 be a common model of the keying material created by the initial key 411 establishment. There are a few cryptographic protocols to choose 412 from. It is to be seen if the protocols available as part of IPsec 413 meet the constraints of 6LoWPAN. 415 One argument for using link layer security is that most IEEE 802.15.4 416 chips already have support for AES link layer security. AES is a 417 block cipher operating on blocks of fixed length, i.e., 128 bits. To 418 encrypt longer messages, several modes of operation may be used. The 419 earliest modes described, such as ECB, CBC, OFB and CFB provide only 420 confidentiality, and this does not ensure message integrity. Other 421 modes have been designed which ensure both confidentiality and 422 message integrity, such as CCM* mode. 6LoWPAN could choose to operate 423 in one of the modes of operation, but it is desirable to utilize as 424 much of link level security as possible and build upon it. 426 For network layer security, two models are applicable: end-to-end 427 security, e.g. using IPsec transport mode, or security that is 428 limited to the wireless portion of the network, e.g. using a security 429 gateway and IPsec tunnel mode. The disadvantage of the latter is the 430 larger header size, which is significant at the 6lowpan frame MTUs. 431 To simplify 6lowpan implementations, it would be beneficial to 432 consider security model needed and identify a preferred set of cipher 433 suites that are appropriate given the 6lowpan constraints. 435 8. Acknowledgements 437 Thanks to : 439 Geoff Mulligan 441 Soohong Daniel Park 443 Samita Chakrabarti 445 Brijesh Kumar 446 for their comments and help shaping this document. 448 9. References 450 9.1. Normative References 452 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 453 REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/ 454 regauth/oui/tutorials/EUI64.html. 456 [I-D.ietf-ipv6-2461bis] 457 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 458 draft-ietf-ipv6-2461bis-05 (work in progress), 459 October 2005. 461 [I-D.ietf-ipv6-rfc2462bis] 462 Thomson, S., "IPv6 Stateless Address Autoconfiguration", 463 draft-ietf-ipv6-rfc2462bis-08 (work in progress), 464 May 2005. 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, March 1997. 469 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 470 (IPv6) Specification", RFC 2460, December 1998. 472 [ieee802.15.4] 473 IEEE Computer Society, "IEEE Std. 802.15.4-2003", 474 October 2003. 476 9.2. Informative References 478 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 479 Architecture for Describing Simple Network Management 480 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 481 December 2002. 483 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 484 Demand Distance Vector (AODV) Routing", RFC 3561, 485 July 2003. 487 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 488 Protocol (OLSR)", RFC 3626, October 2003. 490 [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology 491 Dissemination Based on Reverse-Path Forwarding (TBRPF)", 492 RFC 3684, February 2004. 494 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 495 Discovery (ND) Trust Models and Threats", RFC 3756, 496 May 2004. 498 [SOAP] "SOAP", W3C http://www.w3c.org/2000/xp/Group/. 500 [liaison] "LIASONS", 501 IETF http://www.ietf.org/liaisonActivities.html. 503 Authors' Addresses 505 Nandakishore Kushalnagar 506 Intel Corp 508 Email: nandakishore.kushalnagar@intel.com 510 Gabriel Montenegro 511 Microsoft Corporation 513 Email: gabriel_montenegro_2000@yahoo.com 515 Intellectual Property Statement 517 The IETF takes no position regarding the validity or scope of any 518 Intellectual Property Rights or other rights that might be claimed to 519 pertain to the implementation or use of the technology described in 520 this document or the extent to which any license under such rights 521 might or might not be available; nor does it represent that it has 522 made any independent effort to identify any such rights. Information 523 on the procedures with respect to rights in RFC documents can be 524 found in BCP 78 and BCP 79. 526 Copies of IPR disclosures made to the IETF Secretariat and any 527 assurances of licenses to be made available, or the result of an 528 attempt made to obtain a general license or permission for the use of 529 such proprietary rights by implementers or users of this 530 specification can be obtained from the IETF on-line IPR repository at 531 http://www.ietf.org/ipr. 533 The IETF invites any interested party to bring to its attention any 534 copyrights, patents or patent applications, or other proprietary 535 rights that may cover technology that may be required to implement 536 this standard. Please address the information to the IETF at 537 ietf-ipr@ietf.org. 539 Disclaimer of Validity 541 This document and the information contained herein are provided on an 542 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 543 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 544 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 545 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 546 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 547 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 Copyright Statement 551 Copyright (C) The Internet Society (2006). This document is subject 552 to the rights, licenses and restrictions contained in BCP 78, and 553 except as set forth therein, the authors retain all their rights. 555 Acknowledgment 557 Funding for the RFC Editor function is currently provided by the 558 Internet Society.