idnits 2.17.1 draft-ietf-6lowpan-problem-05.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 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 553. ** 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 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 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 (August 3, 2006) is 6476 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 457, 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-07 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802.15.4' Summary: 4 errors (**), 0 flaws (~~), 5 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 Intended status: Standards Track G. Montenegro 5 Expires: February 4, 2007 Microsoft Corporation 6 August 3, 2006 8 6LoWPAN: Overview, Assumptions, Problem Statement and Goals 9 draft-ietf-6lowpan-problem-05.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 February 4, 2007. 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 . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . 12 69 Intellectual Property and Copyright Statements . . . . . . . . . . 13 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]. 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 LoWPAN 80 requirements with regards to the IP layer and above, and spells out 81 the underlying assumptions of IP for LoWPANs. Finally, it describes 82 problems associated with enabling IP communication between devices in 83 a 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. These devices are typically associated with sensors, 126 switches, etc. This drives some of the other characteristics 127 such as low processing, low memory, etc. Numerical values for 128 "low" elided on purpose since costs tend to change over time. 130 7. Large number of devices expected to be deployed during the life- 131 time of the technology. This number is expected to dwarf the 132 number of deployed personal computers, for example. 134 8. Location of the devices is typically not predefined, as they 135 tend to be deployed in an ad hoc fashion. Furthermore, 136 sometimes the location of these devices may not be easily 137 accessible. Additionally, these devices may move to new 138 locations. 140 9. Devices within LoWPANs tend to be unreliable due to variety of 141 reasons: uncertain radio connectivity, battery drain, device 142 lockups, physical tampering, etc. 144 10. Devices within LoWPANs tend to be unavailable because they often 145 are in sleep mode or in a power-down mode to conserve power. 147 The following sections take into account these characteristics in 148 describing the assumptions, problems statement and goals for LoWPANs, 149 and, in particular, for 6LoWPANs (IPv6-based LoWPAN networks). 151 3. Assumptions 153 Given the small packet size of LoWPANs, this document presumes 154 applications typically send small amounts of data. However, the 155 protocols themselves do not restrict bulk data transfers. 157 LoWPANs as described in this document are based on IEEE 802.15.4- 158 2003. It is possible that the specification may undergo changes in 159 the future and may change some of the requirements mentioned above. 161 Some of these assumptions are based on the limited capabilities of 162 devices within LoWPANs. As devices become more powerful, and consume 163 less power, some of the requirements mentioned above may be somewhat 164 relaxed. 166 While some LoWPAN devices are expected to be extremely limited (the 167 so-called "Reduced Function Devices" or RFDs), more capable "Full 168 Function Devices" (FFDs) will also be present, albeit in much smaller 169 numbers. FFDs will typically have more resources and may be mains 170 powered. Accordingly, FFDs will aid RFDs by providing functions such 171 as network coordination, packet forwarding, interfacing with other 172 types of networks, etc. 174 The application of IP technology is assumed to provide the following 175 benefits: 177 1. The pervasive nature of IP networks allows use of existing 178 infrastructure. 179 2. IP-based technologies already exist, are well known and proven to 180 be working. 181 3. An admittedly non-technical but important consideration is that 182 intellectual property conditions for IP networking technology are 183 either more favorable or at least better understood than 184 proprietary and newer solutions. 185 4. Tools for diagnostics, management and commissioning of IP 186 networks already exist. 187 5. IP-based devices can be connected readily to other IP-based 188 networks, without the need for intermediate entities like 189 translation gateways or proxies. 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 195 LoWPANs. 197 4.1. IP Connectivity 199 The requirement for IP connectivity within a LoWPAN is driven by the 200 following: 202 1. The many devices in a LoWPAN make network auto configuration and 203 statelessness highly desirable. And for this, IPv6 has ready 204 solutions. 205 2. The large number of devices poses the need for a large address 206 space, well met by IPv6. 207 3. Given the limited packet size of LoWPANs, the IPv6 address format 208 allows subsuming of IEEE 802.15.4 addresses if so desired. 210 4. Simple interconnectivity to other IP networks including the 211 Internet. 213 However, given the limited packet size, headers for IPv6 and layers 214 above must be compressed whenever possible. 216 4.2. Topologies 218 LoWPANs must support various topologies including mesh and star. 220 Mesh topologies imply multi-hop routing, to a desired destination. 221 In this case, intermediate devices act as packet forwarders at the 222 link layer (akin to routers at the network layer). Typically these 223 are "full function devices" that have more capabilities in terms of 224 power, computation, etc. The requirements on the routing protocol 225 are: 227 1. Given the minimal packet size of LoWPANs, the routing protocol 228 must impose low (or no) overhead on data packets, hopefully 229 independently of the number of hops. 230 2. The routing protocols should have low routing overhead (low 231 chattiness) balanced with topology changes and power 232 conservation. 233 3. The computation and memory requirements in the routing protocol 234 should be minimal to satisfy the low cost and low power 235 objectives. Thus, storage and maintenance of large routing 236 tables is detrimental. 237 4. Support for network topologies in which either FFDs or RFDs may 238 be battery or mains-powered. This implies the appropriate 239 considerations for routing in the presence of sleeping nodes. 241 As with mesh topologies, star topologies include provisioning a 242 subset of devices with packet forwarding functionality. If, in 243 addition to IEEE 802.15.4, these devices use other kinds of network 244 interfaces such as ethernet or IEEE 802.11, the goal is to seamlessly 245 integrate the networks built over those different technologies. 246 This, of course, is a primary motivation to use IP to begin with. 248 4.3. Limited Packet Size 250 Applications within LoWPANs are expected to originate small packets. 251 Adding all layers for IP connectivity should still allow transmission 252 in one frame without incurring excessive fragmentation and 253 reassembly. Furthermore, protocols must be designed or chosen so 254 that the individual "control/protocol packets" fit within a single 255 802.15.4 frame. Along these lines, IPv6's requirement of sub-IP 256 reassembly (see Section 5) may pose challenges for low-end LoWPAN 257 devices that do not have enough RAM or storage for a 1280-octet 258 packet. 260 4.4. Limited configuration and management 262 As alluded to above, devices within LoWPANs are expected to be 263 deployed in exceedingly large numbers. Additionally, they are 264 expected to have limited display and input capabilities. 265 Furthermore, the location of some of these devices may be hard to 266 reach. Accordingly, protocols used in LoWPANs should have minimal 267 configuration, preferably work "out of the box", be easy to 268 bootstrap, and enable the network to self heal given the inherent 269 unreliable characteristic of these devices. Network management 270 should have little overhead yet be powerful enough to control dense 271 deployment of devices. 273 4.5. Service discovery 275 LoWPANs require simple service discovery network protocols to 276 discover, control and maintain services provided by devices. In some 277 cases, especially in dense deployments, abstraction of several nodes 278 to provide a service may be beneficial. In order to enable such 279 features, new protocols may have to be designed. 281 4.6. Security 283 IEEE 802.15.4 mandates link-layer security based on AES, but it omits 284 any details about topics like bootstrapping, key management and 285 security at higher layers. Of course, a complete security solution 286 for LoWPAN devices must consider application needs very carefully. 287 Please refer to the security consideration section below for a more 288 detailed discussion and in-depth security requirements. 290 5. Goals 292 The goals mentioned below are general and not limited to IETF 293 activities. As such, they may not only refer to work that can be 294 done within the IETF (e.g., specification required to transmit IP, 295 profile of best practices for transmitting IP packets, and associated 296 upper level protocols, etc). They also point at work more relevant 297 to other standards bodies (e.g., desirable changes to or profiles 298 relevant to IEEE 802.15.4, W3C, etc). When the goals fall under the 299 IETF's purview, they serve to point out what those efforts should 300 strive to accomplish, regardless of whether they are pursued within 301 one (or more) new (or existing) working groups. When the goals do 302 not fall under the purview of the IETF, documenting them here serves 303 as input to other organizations [liaison]. 305 Note that a common underlying goal is to reduce packet overhead, 306 bandwidth consumption, processing requirements and power consumption. 308 The following are the goals according to priority for LoWPANs: 310 1. Fragmentation and Reassembly layer: As mentioned in the overview, 311 the protocol data units may be as small 81 bytes. This is 312 obviously far below the minimum IPv6 packet size of 1280 octets, 313 and in keeping with section 5 of the IPv6 specification 314 [RFC2460], a fragmentation and reassembly adaptation layer must 315 be provided at the layer below IP. 317 2. Header Compression: Given that in the worst case the maximum size 318 available for transmitting IP packets over IEEE 802.15.4 frame is 319 81 octets, and that the IPv6 header is 40 octets long, (without 320 optional headers), this leaves only 41 octets for upper-layer 321 protocols, like UDP and TCP. UDP uses 8 octets in the header and 322 TCP uses 20 octets. This leaves 33 octets for data over UDP and 323 21 octets for data over TCP. Additionally, as pointed above, 324 there is also a need for a fragmentation and reassembly layer, 325 which will use even more octets leaving very few octets for data. 326 Thus if one were to use the protocols as is, it would lead to 327 excessive fragmentation and reassembly even when data packets are 328 just 10s of octets long. This points to the need for header 329 compression. As there is much published and in-progress 330 standardization work on header compression, the 6LoWPAN community 331 needs to investigate using existing header compression 332 techniques, and, if necessary, specify new ones. 334 3. Address Autoconfiguration: [I-D.ietf-ipv6-rfc2462bis] specifies 335 methods for creating IPv6 stateless address auto configuration. 336 Stateless auto configuration (as compared to stateful) is 337 attractive for 6LoWPANs, because it reduces the configuration 338 overhead on the hosts. There is a need for a method to generate 339 an "interface identifier" from the EUI-64 [EUI64] assigned to the 340 IEEE 802.15.4 device. 342 4. Mesh Routing Protocol: A routing protocol to support a multi-hop 343 mesh network is necessary. There is much published work on adhoc 344 multi hop routing for devices. Some examples include [RFC3561], 345 [RFC3626], [RFC3684], all experimental. Also, these protocols 346 are designed to use IP-based addresses that have large overheads. 347 For example, the AODV [RFC3561] routing protocol uses 48 octets 348 for a route request based on IPv6 addressing. Given the packet- 349 size constraints, transmitting this packet without fragmentation 350 and reassembly may be difficult. Thus, care should be taken when 351 using existing routing protocols (or designing new ones) so that 352 the routing packets fit within a single IEEE 802.15.4 frame. 354 5. Network Management: One of the points of transmitting IPv6 355 packets, is to reuse existing protocols as much as possible. 356 Network management functionality is critical for LoWPANs. 357 [RFC3411] specifies SNMPv3 protocol operations. SNMP 358 functionality may be translated "as is" to LoWPANs. However, 359 further investigation is required to determine if it is suitable, 360 or if an appropriate adaption is in order. This adaptation could 361 include limiting the data types and simplifying the Basic 362 Encoding Rules so as to reduce the size and complexity of the 363 ASN.1 parser, thereby reducing the memory and processing needs to 364 better fit into the limited memory and power of LoWPAN devices. 366 6. Implementation Considerations: It may be the case that 367 transmitting IP over IEEE 802.15.4 would become more beneficial 368 if implemented in a "certain" way. Accordingly, implementation 369 considerations are to be documented. 371 7. Application and higher layer Considerations: As header 372 compression becomes more prevalent, overall performance will 373 depend even more on efficiency of application protocols. 374 Heavyweight protocols based on XML such as SOAP [SOAP], may not 375 be suitable for LoWPANs. As such, more compact encodings (and 376 perhaps protocols) may become necessary. The goal here is to 377 specify or suggest modifications to existing protocols so that 378 they are suitable for LoWPANs. Furthermore, application level 379 interoperability specifications may also become necessary in the 380 future and may thus be specified. 382 8. Security Considerations: Security threats at different layers 383 must be clearly understood and documented. Bootstrapping of 384 devices into a secure network could also be considered given the 385 location, limited display, high density and ad hoc deployment of 386 devices. 388 6. IANA Considerations 390 This document contains no IANA considerations. 392 7. Security Considerations 394 IPv6 over LoWPAN (6LoWPAN) applications often require confidentiality 395 and integrity protection. This can be provided at the application, 396 transport, network, and/or at the link layer (i.e., within the 397 6LoWPAN set of specifications). In all these cases, prevailing 398 constraints will influence the choice of a particular protocol. Some 399 of the more relevant constraints are small code size, low power 400 operation, low complexity, and small bandwidth requirements. 402 Given these constraints, first, a threat model for 6LoWPAN devices 403 needs to be developed in order to weigh any risks against the cost of 404 their mitigations while making meaningful assumptions and 405 simplifications. Some examples for threats that should be considered 406 are man-in-the-middle attacks and denial of service attacks. 408 A separate set of security considerations apply to bootstrapping a 409 6LoWPAN device into the network (e.g., for initial key 410 establishment). This generally involves application level exchanges 411 or out-of-band techniques for the initial key establishment, and may 412 rely on application- specific trust models; thus, it is considered 413 extraneous to 6LoWPAN and is not addressed in these specifications. 414 In order to be able to select (or design) this next set of protocols, 415 there needs to be a common model of the keying material created by 416 the initial key establishment. 418 Beyond initial key establishment, protocols for subsequent key 419 management as well as to secure the data traffic do fall under the 420 purview of 6LoWPAN. Here, the different alternatives (TLS, IKE/ 421 IPsec, etc.) must be evaluated in light of the 6LoWPAN constraints. 423 One argument for using link layer security is that most IEEE 802.15.4 424 devices already have support for AES link-layer security. AES is a 425 block cipher operating on blocks of fixed length, i.e., 128 bits. To 426 encrypt longer messages, several modes of operation may be used. The 427 earliest modes described, such as ECB, CBC, OFB and CFB provide only 428 confidentiality, and this does not ensure message integrity. Other 429 modes have been designed which ensure both confidentiality and 430 message integrity, such as CCM* mode. 6LoWPAN networks can operate in 431 any of the previous modes, but it is desirable to utilize the most 432 secure modes available for link-layer security (e.g., CCM*), and 433 build upon it. 435 For network layer security, two models are applicable: end-to-end 436 security, e.g. using IPsec transport mode, or security that is 437 limited to the wireless portion of the network, e.g. using a security 438 gateway and IPsec tunnel mode. The disadvantage of the latter is the 439 larger header size, which is significant at the 6LoWPAN frame MTUs. 440 To simplify 6LoWPAN implementations, it is beneficial to identify the 441 relevant security model, and to identify a preferred set of cipher 442 suites that are appropriate given the constraints. 444 8. Acknowledgements 446 Thanks to Geoff Mulligan, Soohong Daniel Park, Samita Chakrabarti and 447 Brijesh Kumar for their comments and help in shaping this document. 449 9. References 451 9.1. Normative References 453 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 454 REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/ 455 regauth/oui/tutorials/EUI64.html. 457 [I-D.ietf-ipv6-2461bis] 458 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 459 draft-ietf-ipv6-2461bis-07 (work in progress), May 2006. 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 Full Copyright Statement 517 Copyright (C) The Internet Society (2006). 519 This document is subject to the rights, licenses and restrictions 520 contained in BCP 78, and except as set forth therein, the authors 521 retain all their rights. 523 This document and the information contained herein are provided on an 524 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 525 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 526 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 527 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 528 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 529 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 531 Intellectual Property 533 The IETF takes no position regarding the validity or scope of any 534 Intellectual Property Rights or other rights that might be claimed to 535 pertain to the implementation or use of the technology described in 536 this document or the extent to which any license under such rights 537 might or might not be available; nor does it represent that it has 538 made any independent effort to identify any such rights. Information 539 on the procedures with respect to rights in RFC documents can be 540 found in BCP 78 and BCP 79. 542 Copies of IPR disclosures made to the IETF Secretariat and any 543 assurances of licenses to be made available, or the result of an 544 attempt made to obtain a general license or permission for the use of 545 such proprietary rights by implementers or users of this 546 specification can be obtained from the IETF on-line IPR repository at 547 http://www.ietf.org/ipr. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights that may cover technology that may be required to implement 552 this standard. Please address the information to the IETF at 553 ietf-ipr@ietf.org. 555 Acknowledgment 557 Funding for the RFC Editor function is provided by the IETF 558 Administrative Support Activity (IASA).