Network Working Group J. Hui Internet-Draft Arch Rock Corporation Intended status: Standards Track October 6, 2008 Expires: April 9, 2009 Compression Format for IPv6 Datagrams in 6LoWPAN Networks draft-ietf-6lowpan-hc-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 9, 2009. Abstract This document specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPAN networks. The compression format relies on shared context to allow compression of arbitrary prefixes. This document specifies compression of well-known multicast addresses and a framework for compressing next headers. UDP compression is specified within this framework. Hui Expires April 9, 2009 [Page 1] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 4 2.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5 2.2. IPv6 Unicast Address Compression . . . . . . . . . . . . . 6 2.3. IPv6 Multicast Address Compression . . . . . . . . . . . . 7 2.4. 16-bit Compressed Address Ranges . . . . . . . . . . . . . 8 3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 9 3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 9 3.2. LOWPAN_UDP Header Compression . . . . . . . . . . . . . . 9 3.3. ISA100_UDP Header Compression . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Hui Expires April 9, 2009 [Page 2] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 1. Introduction The IEEE 802.15.4 standard specifies an MTU of 128 bytes, (including the length byte) on a wireless link with a link throughput of 250 kbps or less[ieee802.15.4]. The 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 datagrams over IEEE 802.15.4 links, taking into account limited bandwidth, memory, or energy resources that are expected in IEEE 802.15.4 applications. The 6LoWPAN adaptation format defines a Mesh Addressing header to support sub-IP forwarding, a Fragmentation header to support the IPv6 minimum MTU requirement [RFC2460], and stateless header compression for IPv6 datagrams (LOWPAN_HC1 and LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down to (in the best case) several bytes. LOWPAN_HC1 is most effective for link-local unicast communication, where IPv6 addresses carry the link-local prefix and an Interface Identifier (IID) directly derived from IEEE 802.15.4 addresses. In this case, both addresses may be completely elided. This scenario is most effective when communication remains local to a mesh-under network where any forwarding occurs below IP and all 6LoWPAN nodes are connected by a single IP hop. Even so, LOWPAN_HC1 cannot elide the IPv6 Hop Limit. In cases where communication only occurs over a single IP hop, there may be cases where a common IPv6 Hop Limit is used. Routable addresses must be used when communicating in a route-over network where forwarding occurs at IP or when communicating with devices external to the 6LoWPAN network. In this scenario, LOWPAN_HC1 requires both IPv6 source and destination addresses to carry the prefix in-line. Furthermore, in route-over networks, the Mesh Addressing header may not be used and the IID must be carried in-line. However LOWPAN_HC1 requires 64-bits for the IID when carried in-line and cannot be shortened even when it is derived directly from the IEEE 802.15.4 16-bit short address. When sending to an IPv6 multicast address, LOWPAN_HC1 requires the full 128-bit multicast address to be carried in-line. Multicast addresses are commonly used for neighbor discovery, such as in IPv6 ND. LOWPAN_HC1 can be extended to include a LOWPAN_HC2 octet to support compression of UDP, TCP, or ICMPv6. RFC 4944 [RFC4944] only defines compression for UDP, where UDP ports may be compressed and the UDP Length may be elided. However, LOWPAN_HC1 also does not provide any flexibility in supporting future compression mechanisms for next headers other than UDP, TCP or ICMPv6. This document specifies a header compression format for IPv6 datagrams. This format improves on the header compression format defined in RFC 4944 [RFC4944] by generalizing it to support a broader Hui Expires April 9, 2009 [Page 3] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 range of communication paradigms, including both mesh-under and route-over configurations; communication to nodes internal and external to the 6LoWPAN network; and multicast communication. This document also defines a flexible framework for compressing arbitrary next headers and defines UDP header compression within this framework. This compression format carries forward the design concepts in RFC 4944 [RFC4944], minimizing any state and relying on shared context among all nodes in a 6LoWPAN network. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. IPv6 Header Compression In this section, we define the LOWPAN_IPHC encoding format for compressing the IPv6 header. To enable effective compression LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN network. LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label are both zero; Payload Length can be inferred from lower layers from either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; Hop Limit will be set to a well-known value by the source; addresses assigned to 6LoWPAN interfaces will be formed using the link-local prefix or a single routable prefix assigned to the entire 6LoWPAN network; addresses assigned to 6LoWPAN interfaces are formed with an IID derived directly from either the 64-bit extended or 16-bit short IEEE 802.15.4 addresses. 1 2 3 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LOWPAN_IPHC | Uncompressed fields follow... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: LOWPAN_IPHC Header The LOWPAN_IPHC encoding utilizes a two octets, with uncompressed fields following, as shown in Figure 1. With the above scenario, the LOWPAN_IPHC can compress the IPv6 header down to two octets (the LOWPAN_IPHC encoding) with link-local communication. When communicating over multiple IP hops, LOWPAN_IPHC can compress the IPv6 header down to 7 octets (2-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination Address). Hui Expires April 9, 2009 [Page 4] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 2.1. LOWPAN_IPHC Encoding Format 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | T |VF |NH | HLIM | rsv | SAM | SAC | DAM | DAC | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 2: LOWPAN_IPHC Encoding T: Traffic Class (bit 0): 0: Full 8 bits for Traffic Class are carried in-line. 1: Traffic Class is elided and implicitly 0. VF: Version and Flow Label (bit 1): 0: Full 4 bits for Version and 20 bits for Flow Label are carried in-line. 1: Version and Flow Label are elided. Version is implicitly 6. Traffic Class and Flow Label are implicitly 0. NH: Next Hop (bit 2): 0: Full 8 bits for Next Hop are carried in-line. 1: Next Hop is elided and the next header is compressed using LOWPAN_NHC, which is discussed in Section 3. HLIM: Hop Limit (bits 3-4): 00: All 8 bits of Hop Limit are carried in-line. 01: All 8 bits of Hop Limit are elided and the Hop Limit is assumed to be 1. 10: All 8 bits of Hop Limit are elided and the Hop Limit is assumed to be 64. 11: All 8 bits of Hop Limit are elided and the Hop Limit is assumed to be 255. rsv: Reserved (bit 5-7) SAC: Source Address Mode (bits 8-9): 00: All 128 bits of Source Address are carried in-line. 01: 64-bit Compressed IPv6 address. 10: 16-bit Compressed IPv6 address. 11: All 128 bits of Source Address are elided. SAC: Source Address Context (bits 10-11): Identifies the compression context when the source address is compressed. The value '00' is reserved and indicates a link-local address. Hui Expires April 9, 2009 [Page 5] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 DAM: Destination Address Mode (bits 12-13): 00: All 128 bits of Destination Address are carried in-line. 01: 64-bit Compressed IPv6 address. 10: 16-bit Compressed IPv6 address. 11: All 128 bits of Destination Address are elided. DAC: Destination Address Context (bits 14-15): Identifies the compression context when the destination address is compressed. The value '00' is reserved and indicates a link-local address. Fields carried in-line (in part or in whole) appear in the same order as they do in the IPv6 header format [RFC2460]. IPv6 addresses may be compressed to 64 or 16 bits or completely elided. The IPv6 Payload Length field MUST always be elided and inferred from lower layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 2.2. IPv6 Unicast Address Compression IPv6 unicast addresses may be compressed to 64, 16, or 0 bits. When an IPv6 unicast address is compressed, the compression context identifies the value of the elided bits. A compression value of '00' indicates the link-local prefix. The mapping between a specific context and prefix may be obtained through simple modifications to IPv6 Neighbor Discovery. However, the specification of those mechanisms are out of scope of this document. Care should be taken when renumbering a network. Nodes SHOULD only use a context after all of its neighbors have been configured with the same context information with high probability. New information within a context SHOULD only be assigned after all nodes in the network have received notification of its deprecation with high probability. There may be cases where the compressor and decompressor are out of sync within a context. In this cases, the decompressor may reconstruct the IPv6 address using the incorrect prefix. To prevent such errors, upper-layer integrity checks (e.g. psuedo-header checksum) that cover both source and destination addresses SHOULD be used. When an IPv6 unicast address is compressed to 64 bits, the last 64 bits are carried in-line. When an IPv6 unicast address is compressed to 16 bits, the last 16 bits are carried in line. Because the 16-bit compressed form is also used for IPv6 multicast address compression, the 16-bit address space is divided into multiple ranges. For unicast addresses, the first bit carried in-line must be zero. Hui Expires April 9, 2009 [Page 6] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Last 15 bits of IPv6 Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: 16-bit Compressed IPv6 Unicast Address Encoding When an address is completely elided, the IID is inferred from lower layers (either from the 6LoWPAN Mesh Addressing header or from the IEEE 802.15.4 header). The prefix is inferred from the identified context. Any remaining bits in between are implicitly zero. To elide the IID, it MUST be derivable from IEEE 802.15.4 addresses. An IID may be derived from the IEEE EUI-64 address by creating a Modified EUI-64 IID from the IEEE EUI-64 address, as defined in RFC 4291 [RFC4291]. The universal/local bit in the Modified IEEE EUI-64 IID must be set to '1', indicating universal scope. An IID may also be derived from the 16-bit short address and PAN ID, as defined in RFC 4944 [RFC4944]. Note, however, that the most significant bit in the short address must be zero. 2.3. IPv6 Multicast Address Compression IPv6 multicast addresses may be compressed to 16 bits by utilizing a different 6LoWPAN short address range. This document allocates another range of 8192 values to be used for well-known IPv6 multicast addresses. 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Range| Scope | Mapped Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Compressed IPv6 Multicast Address Encoding Range (bits 0-2): Must be set to '101' (TBD), which identifies the 6LoWPAN short address range for compressed IPv6 multicast addresses. Scope (bits 3-6): 4-bit multicast scope as specified in RFC 4007 [RFC4007]. Mapped Group ID (bits 7-15): 9-bit mapped multicast group identifier. The full 128-bit multicast address can be reconstructed from the 16- bit mapped multicast address. By definition, the 3-bit range identifier indicates the well-known multicast prefix (0xFF) in Hui Expires April 9, 2009 [Page 7] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 addition to a flags field set to all zeros (indicating a permanently assigned multicast address, that the multicast address is not assigned based on the network prefix, and that it doesn't embed the address of a Rendezvous Point). The 4-bit scope is carried in-line and the 112-bit group ID is derived from the 9-bit mapped group ID using a well-known mapping maintained by the Internet Assigned Numbers Authority (IANA). Nodes MUST accept both the compressed and uncompressed form of well- known multicast addresses that they subscribe to. Doing so removes any ambiguity of which form to use as both will work. Conversely, nodes MUST NOT subscribe to well-known multicast addresses that are not defined by the well-known mapping. This document defines an initial mapping. Additional mappings between 9-bit mapped group IDs and 112-bit group IDs may be specified in the future. +-------+---------+-----------------------+ | 9-bit | 112-bit | Description | +-------+---------+-----------------------+ | 1 | 1 | All Nodes Addresses | | 2 | 2 | All Routers Addresses | +-------+---------+-----------------------+ 9-bit to 112-bit Group ID Mapping 2.4. 16-bit Compressed Address Ranges To use the 16-bit compressed address format for different kinds of addresses (e.g. unicast or multicast), LOWPAN_IPHC utilizes the 16- bit short address ranges as specified in RFC 4944. This document specifies another range, for compressed multicast addresses. Range 0, 0xxxxxxxxxxxxxxx: As specified in RFC 4944. Range 2, 100xxxxxxxxxxxxx: As specified in RFC 4944. Range 1, 101xxxxxxxxxxxxx: The remaining 13 bits represent a compressed IPv6 multicast address, as described in Section 2.3. Range 3, 110xxxxxxxxxxxxx: Reserved. Range 4, 111xxxxxxxxxxxxx: Reserved. Hui Expires April 9, 2009 [Page 8] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 3. IPv6 Next Header Compression LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set to 1. It also indicates the use of 6LoWPAN next header compression, LOWPAN_NHC. The value of IPv6 Next Header is recovered from the first bits in the LOWPAN_NHC encoding. The following bits are specific to the IPv6 Next Header value. Figure 5 shows the structure of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC. +-------------+-------------+-------------+-----------------+-------- | LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload | Encoding | IP Fields | Encoding | Header Fields | +-------------+-------------+-------------+-----------------+-------- Figure 5: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration 3.1. LOWPAN_NHC Format Compression formats for different next headers are identified by a variable length bit-pattern immediately following the LOWPAN_IPHC compressed header. When defining a next header compression format, the number of bits used SHOULD be determined by the perceived frequency of using that format. However, the number of bits and any remaining encoding bits SHOULD respect octet alignment. The following bits are specific to the next header compression format. In this document, we define a compression format for UDP headers. +----------------+--------------------------- | var-len NHC ID | compressed next header... +----------------+--------------------------- Figure 6: LOWPAN_NHC Encoding 3.2. LOWPAN_UDP Header Compression This document defines a compression format for UDP headers using LOWPAN_NHC. The LOWPAN_UDP compression format is shown in Figure 7. Bits 0 through 5 represent the NHC ID and '111110' indicates the specific UDP header compression encoding defined in this section. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 1 | 1 | 1 | 0 | S | D | +---+---+---+---+---+---+---+---+ Figure 7: Compressed UDP Header Encoding Hui Expires April 9, 2009 [Page 9] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 S: Source Port (bit 6): 0: All 16 bits of Source Port are carried in-line. 1: First 12 bits of Source Port are elided and the remaining 4 bits are carried in-line. The Source Port is recovered by: P + short_port, where P is 61616 (0xF0B0). D: Destination Port (bit 7): 0: All 16 bits of Destination Port are carried in-line. 1: First 12 bits of Destination Port are elided and the remaining 4 bits are carried in-line. The Destination Port is recovered by: P + short_port, where P is 61616 (0xF0B0). Fields carried in-line (in part or in whole) appear in the same order as they do in the IPv6 header format [RFC0768]. IPv6 addresses may be compressed to 64 or 16 bits or completely elided. The UDP Length field MUST always be elided and is inferred from lower layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 3.3. ISA100_UDP Header Compression This document defines a compression format for UDP headers using LOWPAN_NHC. The LOWPAN_UDP compression format is shown in Figure 8. Bits 0 through 4 represent the NHC ID and '11110' indicates the specific UDP header compression encoding defined in this section. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 1 | 1 | 0 | C | S | D | +---+---+---+---+---+---+---+---+ Figure 8: Compressed ISA100.11a UDP Header Encoding C: Checksum (bit 5): 0: All 16 bits of Checksum are carried in-line. The Checksum MUST be included if there are no other end-to-end integrity checks that are stronger than what is provided by the UDP checksum. Such an integrity check MUST be end-to-end and cover the IPv6 pseudo-header, UDP header, and UDP payload. 1: All 16 bits of Checksum are elided. The Checksum is recovered by recomputing it. S: Source Port (bit 6): 0: All 16 bits of Source Port are carried in-line. 1: First 12 bits of Source Port are elided and the remaining 4 bits are carried in-line. The Source Port is recovered by: P + short_port, where P is 61616 (0xF0B0). Hui Expires April 9, 2009 [Page 10] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 D: Destination Port (bit 7): 0: All 16 bits of Destination Port are carried in-line. 1: First 12 bits of Destination Port are elided and the remaining 4 bits are carried in-line. The Destination Port is recovered by: P + short_port, where P is 61616 (0xF0B0). Fields carried in-line (in part or in whole) appear in the same order as they do in the IPv6 header format [RFC0768]. IPv6 addresses may be compressed to 64 or 16 bits or completely elided. The UDP Length field MUST always be elided and is inferred from lower layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 4. IANA Considerations This document defines a new IPv6 header compression format for 6LoWPAN networks. The document allocates a new Dispatch type value of 0x03 (TBD) for LOWPAN_IPHC. This document reserves another 16-bit short address range from RFC 4944 for use with 16-bit compressed well-known IPv6 multicast addresses. This document creates a new IANA registry for mapped well-known multicast addresses, mapping 112-bit group identifiers to compressed 9-bit ones. The registry MUST include the All Nodes Address (1) and the All Routers Address (2). 5. Security Considerations The definition of LOWPAN_IPHC permits the compression of header information on communication that could take place in its absence, albeit in a less efficient form. It recognizes that a IEEE 802.15.4 PAN may have associated with it a global prefix. How that global prefix is assigned and managed is beyond the scope of this document. 6. Acknowledgements Thanks to Pascal Thubert for useful discussions in helping shape the header compression mechanisms. Thanks to Carsten Bormann for useful feedback and discussion. 7. References Hui Expires April 9, 2009 [Page 11] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 7.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2006", October 2006. 7.2. Informative References [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. Hui Expires April 9, 2009 [Page 12] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 Author's Address Jonathan W. Hui Arch Rock Corporation 501 2nd St. Ste. 410 San Francisco, California 94107 USA Phone: +415 692 0828 Email: jhui@archrock.com Hui Expires April 9, 2009 [Page 13] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Hui Expires April 9, 2009 [Page 14]