idnits 2.17.1 draft-ietf-6lowpan-problem-08.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 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 543. 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 (February 26, 2007) is 6262 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group N. Kushalnagar 2 Internet-Draft Intel Corp 3 Intended status: Informational G. Montenegro 4 Expires: August 30, 2007 Microsoft Corporation 5 C. Schumacher 6 Danfoss A/S 7 February 26, 2007 9 6LoWPAN: Overview, Assumptions, Problem Statement and Goals 10 draft-ietf-6lowpan-problem-08.txt 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 August 30, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes the assumptions, problem statement and goals 44 for transmitting IP over IEEE 802.15.4 networks. The set of goals 45 enumerated in this document form an initial set only. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4.1. IP Connectivity . . . . . . . . . . . . . . . . . . . . . 5 54 4.2. Topologies . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4.3. Limited Packet Size . . . . . . . . . . . . . . . . . . . 6 56 4.4. Limited configuration and management . . . . . . . . . . . 7 57 4.5. Service discovery . . . . . . . . . . . . . . . . . . . . 7 58 4.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 67 Intellectual Property and Copyright Statements . . . . . . . . . . 13 69 1. Introduction 71 Low-power wireless personal area networks (LoWPANs) comprise devices 72 that conform to the IEEE 802.15.4-2003 standard by the IEEE 73 [ieee802.15.4]. IEEE 802.15.4 devices are characterized by short 74 range, low bit rate, low power and low cost. Many of the devices 75 employing IEEE 802.15.4 radios will be limited in their computational 76 power, memory, and/or energy availability. 78 This document gives an overview of LoWPANs and describes how they 79 benefit from IP and in particular IPv6 networking. It describes 80 LoWPAN requirements with regards to the IP layer and above, and 81 spells out the underlying assumptions of IP for LoWPANs. Finally, it 82 describes problems associated with enabling IP communication with 83 devices in a LoWPAN, and defines goals to address these in a 84 prioritized manner. Admittedly, not all items on this list may be 85 necessarily appropriate tasks for the IETF. Nevertheless, they are 86 documented here to give a general overview of the larger problem. 87 This is useful both to structure work within the IETF as well as to 88 understand better how to coordinate with external organizations. 90 2. Overview 92 A LoWPAN is a simple low cost communication network that allows 93 wireless connectivity in applications with limited power and relaxed 94 throughput requirements. A LoWPAN typically includes devices that 95 work together to connect the physical environment to real-world 96 applications, e.g., wireless sensors. LoWPANs conform to the IEEE 97 802.15.4-2003 standard. [ieee802.15.4]. 99 Some of the characteristics of LoWPANs are: 101 1. Small packet size. Given that the maximum physical layer packet 102 is 127 bytes, the resulting maximum frame size at the media 103 access control layer is 102 octets. Link-layer security imposes 104 further overhead, which in the maximum case (21 octets of 105 overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 106 and AES-CCM-64, respectively) leaves 81 octets for data packets. 108 2. Support for both 16-bit short or IEEE 64-bit extended media 109 access control addresses. 111 3. Low bandwidth. Data rates of 250 kbps, 40 kbps and 20 kbps for 112 each of the currently defined physical layers (2.4 GHz, 915 MHz 113 and 868 MHz, respectively). 115 4. Topologies include star and mesh operation. 117 5. Low power. Typically, some or all devices are battery operated. 119 6. Low cost. These devices are typically associated with sensors, 120 switches, etc. This drives some of the other characteristics 121 such as low processing, low memory, etc. Numerical values for 122 "low" elided on purpose since costs tend to change over time. 124 7. Large number of devices expected to be deployed during the life- 125 time of the technology. This number is expected to dwarf the 126 number of deployed personal computers, for example. 128 8. Location of the devices is typically not predefined, as they 129 tend to be deployed in an ad-hoc fashion. Furthermore, 130 sometimes the location of these devices may not be easily 131 accessible. Additionally, these devices may move to new 132 locations. 134 9. Devices within LoWPANs tend to be unreliable due to variety of 135 reasons: uncertain radio connectivity, battery drain, device 136 lockups, physical tampering, etc. 138 10. In many environments, devices connected to a LoWPAN may sleep 139 for long periods of time in order to conserve energy, and are 140 unable to communicate during these sleep periods. 142 The following sections take into account these characteristics in 143 describing the assumptions, problems statement and goals for LoWPANs, 144 and, in particular, for 6LoWPANs (IPv6-based LoWPAN networks). 146 3. Assumptions 148 Given the small packet size of LoWPANs, this document presumes 149 applications typically send small amounts of data. However, the 150 protocols themselves do not restrict bulk data transfers. 152 LoWPANs as described in this document are based on IEEE 802.15.4- 153 2003. It is possible that the specification may undergo changes in 154 the future and may change some of the requirements mentioned above. 156 Some of these assumptions are based on the limited capabilities of 157 devices within LoWPANs. As devices become more powerful, and consume 158 less power, some of the requirements mentioned above may be somewhat 159 relaxed. 161 While some LoWPAN devices are expected to be extremely limited (the 162 so-called "Reduced Function Devices" or RFDs), more capable "Full 163 Function Devices" (FFDs) will also be present, albeit in much smaller 164 numbers. FFDs will typically have more resources and may be mains 165 powered. Accordingly, FFDs will aid RFDs by providing functions such 166 as network coordination, packet forwarding, interfacing with other 167 types of networks, etc. 169 The application of IP technology is assumed to provide the following 170 benefits: 172 1. The pervasive nature of IP networks allows use of existing 173 infrastructure. 174 2. IP-based technologies already exist, are well known and proven to 175 be working. 176 3. An admittedly non-technical but important consideration is that 177 intellectual property conditions for IP networking technology are 178 either more favorable or at least better understood than 179 proprietary and newer solutions. 180 4. Tools for diagnostics, management and commissioning of IP 181 networks already exist. 182 5. IP-based devices can be connected readily to other IP-based 183 networks, without the need for intermediate entities like 184 translation gateways or proxies. 186 4. Problems 188 Based on the characteristics defined in the overview section, the 189 following sections elaborate on the main problems with IP for 190 LoWPANs. 192 4.1. IP Connectivity 194 The requirement for IP connectivity within a LoWPAN is driven by the 195 following: 197 1. The many devices in a LoWPAN make network auto configuration and 198 statelessness highly desirable. And for this, IPv6 has ready 199 solutions. 200 2. The large number of devices poses the need for a large address 201 space, well met by IPv6. 202 3. Given the limited packet size of LoWPANs, the IPv6 address format 203 allows subsuming of IEEE 802.15.4 addresses if so desired. 204 4. Simple interconnectivity to other IP networks including the 205 Internet. 207 However, given the limited packet size, headers for IPv6 and layers 208 above must be compressed whenever possible. 210 4.2. Topologies 212 LoWPANs must support various topologies including mesh and star. 214 Mesh topologies imply multi-hop routing, to a desired destination. 215 In this case, intermediate devices act as packet forwarders at the 216 link layer (akin to routers at the network layer). Typically these 217 are "full function devices" that have more capabilities in terms of 218 power, computation, etc. The requirements on the routing protocol 219 are: 221 1. Given the minimal packet size of LoWPANs, the routing protocol 222 must impose low (or no) overhead on data packets, hopefully 223 independently of the number of hops. 224 2. The routing protocols should have low routing overhead (low 225 chattiness) balanced with topology changes and power 226 conservation. 227 3. The computation and memory requirements in the routing protocol 228 should be minimal to satisfy the low cost and low power 229 objectives. Thus, storage and maintenance of large routing 230 tables is detrimental. 231 4. Support for network topologies in which either FFDs or RFDs may 232 be battery or mains-powered. This implies the appropriate 233 considerations for routing in the presence of sleeping nodes. 235 As with mesh topologies, star topologies include provisioning a 236 subset of devices with packet forwarding functionality. If, in 237 addition to IEEE 802.15.4, these devices use other kinds of network 238 interfaces such as ethernet or IEEE 802.11, the goal is to seamlessly 239 integrate the networks built over those different technologies. 240 This, of course, is a primary motivation to use IP to begin with. 242 4.3. Limited Packet Size 244 Applications within LoWPANs are expected to originate small packets. 245 Adding all layers for IP connectivity should still allow transmission 246 in one frame without incurring excessive fragmentation and 247 reassembly. Furthermore, protocols must be designed or chosen so 248 that the individual "control/protocol packets" fit within a single 249 802.15.4 frame. Along these lines, IPv6's requirement of sub-IP 250 reassembly (see Section 5) may pose challenges for low-end LoWPAN 251 devices that do not have enough RAM or storage for a 1280-octet 252 packet. 254 4.4. Limited configuration and management 256 As alluded to above, devices within LoWPANs are expected to be 257 deployed in exceedingly large numbers. Additionally, they are 258 expected to have limited display and input capabilities. 259 Furthermore, the location of some of these devices may be hard to 260 reach. Accordingly, protocols used in LoWPANs should have minimal 261 configuration, preferably work "out of the box", be easy to 262 bootstrap, and enable the network to self heal given the inherent 263 unreliable characteristic of these devices. Network management 264 should have little overhead yet be powerful enough to control dense 265 deployment of devices. 267 4.5. Service discovery 269 LoWPANs require simple service discovery network protocols to 270 discover, control and maintain services provided by devices. In some 271 cases, especially in dense deployments, abstraction of several nodes 272 to provide a service may be beneficial. In order to enable such 273 features, new protocols may have to be designed. 275 4.6. Security 277 IEEE 802.15.4 mandates link-layer security based on AES, but it omits 278 any details about topics like bootstrapping, key management and 279 security at higher layers. Of course, a complete security solution 280 for LoWPAN devices must consider application needs very carefully. 281 Please refer to the security consideration section below for a more 282 detailed discussion and in-depth security requirements. 284 5. Goals 286 The goals mentioned below are general and not limited to IETF 287 activities. As such, they may not only refer to work that can be 288 done within the IETF (e.g., specification required to transmit IP, 289 profile of best practices for transmitting IP packets, and associated 290 upper level protocols, etc). They also point at work more relevant 291 to other standards bodies (e.g., desirable changes to or profiles 292 relevant to IEEE 802.15.4, W3C, etc). When the goals fall under the 293 IETF's purview, they serve to point out what those efforts should 294 strive to accomplish, regardless of whether they are pursued within 295 one (or more) new (or existing) working groups. When the goals do 296 not fall under the purview of the IETF, documenting them here serves 297 as input to other organizations [liaison]. 299 Note that a common underlying goal is to reduce packet overhead, 300 bandwidth consumption, processing requirements and power consumption. 302 The following are the goals according to priority for LoWPANs: 304 1. Fragmentation and Reassembly layer: As mentioned in the overview, 305 the protocol data units may be as small 81 bytes. This is 306 obviously far below the minimum IPv6 packet size of 1280 octets, 307 and in keeping with section 5 of the IPv6 specification 308 [RFC2460], a fragmentation and reassembly adaptation layer must 309 be provided at the layer below IP. 311 2. Header Compression: Given that in the worst case the maximum size 312 available for transmitting IP packets over IEEE 802.15.4 frame is 313 81 octets, and that the IPv6 header is 40 octets long, (without 314 optional headers), this leaves only 41 octets for upper-layer 315 protocols, like UDP and TCP. UDP uses 8 octets in the header and 316 TCP uses 20 octets. This leaves 33 octets for data over UDP and 317 21 octets for data over TCP. Additionally, as pointed above, 318 there is also a need for a fragmentation and reassembly layer, 319 which will use even more octets leaving very few octets for data. 320 Thus if one were to use the protocols as is, it would lead to 321 excessive fragmentation and reassembly even when data packets are 322 just 10s of octets long. This points to the need for header 323 compression. As there is much published and in-progress 324 standardization work on header compression, the 6LoWPAN community 325 needs to investigate using existing header compression 326 techniques, and, if necessary, specify new ones. 328 3. Address Autoconfiguration: [I-D.ietf-ipv6-rfc2462bis] specifies 329 methods for creating IPv6 stateless address auto configuration. 330 Stateless auto configuration (as compared to stateful) is 331 attractive for 6LoWPANs, because it reduces the configuration 332 overhead on the hosts. There is a need for a method to generate 333 an "interface identifier" from the EUI-64 [EUI64] assigned to the 334 IEEE 802.15.4 device. 336 4. Mesh Routing Protocol: A routing protocol to support a multi-hop 337 mesh network is necessary. There is much published work on ad- 338 hoc multi hop routing for devices. Some examples include 339 [RFC3561], [RFC3626], [RFC3684], all experimental. Also, these 340 protocols are designed to use IP-based addresses that have large 341 overheads. For example, the AODV [RFC3561] routing protocol uses 342 48 octets for a route request based on IPv6 addressing. Given 343 the packet-size constraints, transmitting this packet without 344 fragmentation and reassembly may be difficult. Thus, care should 345 be taken when using existing routing protocols (or designing new 346 ones) so that the routing packets fit within a single IEEE 347 802.15.4 frame. 349 5. Network Management: One of the points of transmitting IPv6 350 packets, is to reuse existing protocols as much as possible. 351 Network management functionality is critical for LoWPANs. 352 [RFC3411] specifies SNMPv3 protocol operations. SNMP 353 functionality may be translated "as is" to LoWPANs. However, 354 further investigation is required to determine if it is suitable, 355 or if an appropriate adaption is in order. This adaptation could 356 include limiting the data types and simplifying the Basic 357 Encoding Rules so as to reduce the size and complexity of the 358 ASN.1 parser, thereby reducing the memory and processing needs to 359 better fit into the limited memory and power of LoWPAN devices. 361 6. Implementation Considerations: It may be the case that 362 transmitting IP over IEEE 802.15.4 would become more beneficial 363 if implemented in a "certain" way. Accordingly, implementation 364 considerations are to be documented. 366 7. Application and higher layer Considerations: As header 367 compression becomes more prevalent, overall performance will 368 depend even more on efficiency of application protocols. 369 Heavyweight protocols based on XML such as SOAP [SOAP], may not 370 be suitable for LoWPANs. As such, more compact encodings (and 371 perhaps protocols) may become necessary. The goal here is to 372 specify or suggest modifications to existing protocols so that 373 they are suitable for LoWPANs. Furthermore, application level 374 interoperability specifications may also become necessary in the 375 future and may thus be specified. 377 8. Security Considerations: Security threats at different layers 378 must be clearly understood and documented. Bootstrapping of 379 devices into a secure network could also be considered given the 380 location, limited display, high density and ad-hoc deployment of 381 devices. 383 6. IANA Considerations 385 This document contains no IANA considerations. 387 7. Security Considerations 389 IPv6 over LoWPAN (6LoWPAN) applications often require confidentiality 390 and integrity protection. This can be provided at the application, 391 transport, network, and/or at the link layer (i.e., within the 392 6LoWPAN set of specifications). In all these cases, prevailing 393 constraints will influence the choice of a particular protocol. Some 394 of the more relevant constraints are small code size, low power 395 operation, low complexity, and small bandwidth requirements. 397 Given these constraints, first, a threat model for 6LoWPAN devices 398 needs to be developed in order to weigh any risks against the cost of 399 their mitigations while making meaningful assumptions and 400 simplifications. Some examples for threats that should be considered 401 are man-in-the-middle attacks and denial of service attacks. 403 A separate set of security considerations apply to bootstrapping a 404 6LoWPAN device into the network (e.g., for initial key 405 establishment). This generally involves application level exchanges 406 or out-of-band techniques for the initial key establishment, and may 407 rely on application- specific trust models; thus, it is considered 408 extraneous to 6LoWPAN and is not addressed in these specifications. 409 In order to be able to select (or design) this next set of protocols, 410 there needs to be a common model of the keying material created by 411 the initial key establishment. 413 Beyond initial key establishment, protocols for subsequent key 414 management as well as to secure the data traffic do fall under the 415 purview of 6LoWPAN. Here, the different alternatives (TLS, IKE/ 416 IPsec, etc.) must be evaluated in light of the 6LoWPAN constraints. 418 One argument for using link layer security is that most IEEE 802.15.4 419 devices already have support for AES link-layer security. AES is a 420 block cipher operating on blocks of fixed length, i.e., 128 bits. To 421 encrypt longer messages, several modes of operation may be used. The 422 earliest modes described, such as ECB, CBC, OFB and CFB provide only 423 confidentiality, and this does not ensure message integrity. Other 424 modes have been designed which ensure both confidentiality and 425 message integrity, such as CCM* mode. 6LoWPAN networks can operate in 426 any of the previous modes, but it is desirable to utilize the most 427 secure modes available for link-layer security (e.g., CCM*), and 428 build upon it. 430 For network layer security, two models are applicable: end-to-end 431 security, e.g. using IPsec transport mode, or security that is 432 limited to the wireless portion of the network, e.g. using a security 433 gateway and IPsec tunnel mode. The disadvantage of the latter is the 434 larger header size, which is significant at the 6LoWPAN frame MTUs. 435 To simplify 6LoWPAN implementations, it is beneficial to identify the 436 relevant security model, and to identify a preferred set of cipher 437 suites that are appropriate given the constraints. 439 8. Acknowledgements 441 Thanks to Geoff Mulligan, Soohong Daniel Park, Samita Chakrabarti, 442 Brijesh Kumar and Miguel Garcia for their comments and help in 443 shaping this document. 445 9. References 447 9.1. Normative References 449 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 450 (IPv6) Specification", RFC 2460, December 1998. 452 [ieee802.15.4] 453 IEEE Computer Society, "IEEE Std. 802.15.4-2003", 454 October 2003. 456 9.2. Informative References 458 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 459 REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/ 460 regauth/oui/tutorials/EUI64.html. 462 [I-D.ietf-ipv6-rfc2462bis] 463 Thomson, S., "IPv6 Stateless Address Autoconfiguration", 464 draft-ietf-ipv6-rfc2462bis-08 (work in progress), 465 May 2005. 467 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 468 Architecture for Describing Simple Network Management 469 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 470 December 2002. 472 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 473 Demand Distance Vector (AODV) Routing", RFC 3561, 474 July 2003. 476 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 477 Protocol (OLSR)", RFC 3626, October 2003. 479 [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology 480 Dissemination Based on Reverse-Path Forwarding (TBRPF)", 481 RFC 3684, February 2004. 483 [SOAP] "SOAP", W3C http://www.w3c.org/2000/xp/Group/. 485 [liaison] "LIASONS", 486 IETF http://www.ietf.org/liaisonActivities.html. 488 Authors' Addresses 490 Nandakishore Kushalnagar 491 Intel Corp 493 Email: nandakishore.kushalnagar@intel.com 495 Gabriel Montenegro 496 Microsoft Corporation 498 Email: g_e_montenegro@yahoo.com 500 Christian Peter Pii Schumacher 501 Danfoss A/S 503 Email: schumacher@danfoss.com 505 Full Copyright Statement 507 Copyright (C) The IETF Trust (2007). 509 This document is subject to the rights, licenses and restrictions 510 contained in BCP 78, and except as set forth therein, the authors 511 retain all their rights. 513 This document and the information contained herein are provided on an 514 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 515 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 516 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 517 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 518 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 519 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 521 Intellectual Property 523 The IETF takes no position regarding the validity or scope of any 524 Intellectual Property Rights or other rights that might be claimed to 525 pertain to the implementation or use of the technology described in 526 this document or the extent to which any license under such rights 527 might or might not be available; nor does it represent that it has 528 made any independent effort to identify any such rights. Information 529 on the procedures with respect to rights in RFC documents can be 530 found in BCP 78 and BCP 79. 532 Copies of IPR disclosures made to the IETF Secretariat and any 533 assurances of licenses to be made available, or the result of an 534 attempt made to obtain a general license or permission for the use of 535 such proprietary rights by implementers or users of this 536 specification can be obtained from the IETF on-line IPR repository at 537 http://www.ietf.org/ipr. 539 The IETF invites any interested party to bring to its attention any 540 copyrights, patents or patent applications, or other proprietary 541 rights that may cover technology that may be required to implement 542 this standard. Please address the information to the IETF at 543 ietf-ipr@ietf.org. 545 Acknowledgment 547 Funding for the RFC Editor function is provided by the IETF 548 Administrative Support Activity (IASA).