Network Working Group J. Hui, Ed. Internet-Draft Arch Rock Corporation Updates: 4944 (if approved) P. Thubert Intended status: Standards Track Cisco Expires:
April 12,May 5, 2009 October 9,November 1, 2008 Compression Format for IPv6 Datagrams in 6LoWPAN Networks draft-ietf-6lowpan-hc-01draft-ietf-6lowpan-hc-02 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 12,May 5, 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 multicast addresses and a framework for compressing next headers. This framework specifies UDP compression and is prepared for additional transports. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 4 2.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5 2.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Context Identifier Extension . . . . . . . . . . . . . 7 2.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 8 2.2.1. Traffic Class and Flow Label Encoding . . . . . . . . 8 2.2.2. IPv6 Address Encoding for Unicast Destinations . . . . 9 2.2.3. IPv6 Address Encoding for Multicast Destinations . . . 9 3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 11 3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 11 3.2. UDP Header Compression . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 22.214.171.124. Normative References . . . . . . . . . . . . . . . . . . . 13 126.96.36.199. Informative References . . . . . . . . . . . . . . . . . . 1314 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 1516 1. Introduction The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding about 80 octets of actual MAC payload once security is turned on, on a wireless link with a link throughput of 250 kbps or less. The 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 datagrams over such constrained links, taking into account limited bandwidth, memory, or energy resources that are expected in applications such as wireless Sensor Networks. [RFC4944] 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 and LOWPAN_HC2 are insufficient for most practical uses of 6LoWPAN networks. 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. However, though link local addresses are commonly used for local protocol interactions such as IPv6 ND [RFC4861], DHCPv6 [RFC3315] or routing protocols, they are usually not used for application layer data traffic, so the actual value of this compression mechanism is limited. Routable addresses must be used when communicating with devices external to the LoWPAN or in a route-over configuration where IP forwarding occurs within the LoWPAN. For routable addresses, LOWPAN_HC1 requires both IPv6 source and destination addresses to carry the prefix in-line. In cases where the Mesh Addressing header is not used, the IID of a routable address 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 from the IEEE 802.15.4 16-bit short address. When the destination is an IPv6 multicast address, LOWPAN_HC1 requires the full 128-bit address to be carried in-line. This specification provides an additional mechanism to compress Unique Local, Global and multicast IPv6 Addresses based on shared states within contexts. It also introduces a number of additional improvements over [RFC4944]. LOWPAN_HC1 cannot elide the IPv6 Hop Limit in the IPv6 header, even though a limited set of values are useful in many practical cases. For instance, if the LoWPAN is a mesh-under stub, a Hop Limit of 1 for inbound and a default value such as 64 for outbound are usually enough for application layer data traffic. Compressing that field enables saving one octet per packet. LOWPAN_HC1 can be extended to include a LOWPAN_HC2 octet to support compression of UDP, TCP, or ICMPv6; that LOWPAN_HC2 octet is placed right after the LOWPAN_HC1 octet and before the uncompressed IP fields. This specification moves the transport control octet after the uncompressed IP fields for a more properly layered structure. [RFC4944] defines a compression mechanism for UDP, but that mechanism does not enable checksum compression when rendered possible by additional upper layer mechanisms such as upper layer Message Integrity Check (MIC). This specification adds the capability to compress the UDP checksum over the LoWPAN, which enables to save an additional pair of octets. Finally, LOWPAN_HC1 lacks the flexibility to support the compression of additional transport mechanisms that could be introduced in the future. This document specifies a header compression format for IPv6 datagrams. This format improves on the header compression format defined in [RFC4944] by generalizing it to support a broader 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. +-------------------------------------+------------------------ | Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header +-------------------------------------+------------------------ Figure 1: LOWPAN_IPHC Header The LOWPAN_IPHC encoding utilizes 11 bits, 3 of which are taken from the rightmost bit of the dispatch type. The encoding may be extended by another octet to support additional contexts. Uncompressed IPv6 header fields follow the LOWPAN_IPHC encoding, as shown in Figure 1. With the above scenario, the LOWPAN_IPHC can compress the IPv6 header down to two octets (the dispatch octet and the LOWPAN_IPHC encoding) with link-local communication. When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6 header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination Address). 2.1. LOWPAN_IPHC Encoding Format 2.1.1. Base Format 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | DDFCM | SAM | DAM | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 2: LOWPAN_IPHC Encoding TF: Traffic Class, Flow Label: 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) 01: ECN + 2-bit Pad + Flow Label (3 bytes) 10: Traffic Class (1 byte) 11: Version, Traffic Class, and Flow Label are compressed. NH: Next Header: 0: Full 8 bits for Next Header are carried in-line. 1: The Next Header field is compressed and the next header is compressed using LOWPAN_NHC, which is discussed in Section 3. HLIM: Hop Limit: 00: The Hop Limit field is carried in-line. 01: The Hop Limit field is compressed and the the hop limit is 1. 10: The Hop Limit field is compressed and the the hop limit is 64. 11: The Hop Limit field is compressed and the hop limit is 255. DDF: Destination Dependant Field:CM: Compression Mode: 00: DestinationStateful compression using a default context. In this case the context for SAM and Source are Global or Unique Local AddressesDAM is the default context. 01: Destination and Source are Global or Unique Local AddressesStateful compression using an indexed context; In this case the context for SAM and oneDAM is indicated in additional context octetoctets that extends the LOWPAN_IPHC field to disambiguate an elided prefix or address described by the SAM or DAM fields. 10: Destination and Source areStateless compression using a well-know (Link-Local) prefix; In this case, the context is the Link Local Addresses 11: Destinationcontext and the prefix is a Multicast Address, SourceFE80::/64. This compression mode is eitherused for link local to link local communication. 11: Stateless compression using a well-know pattern; In this case, the unspecifiedcontext for the source address or ais the Link Local Address SAM:context and the prefix is FE80::/64. The compression for the destination address does not use a context but a well-known pattern used in multicast addresses. This compression mode is used for link local to link scoped multicast group communication. SAM & DAM: Source and Destination Address Mode: WhenThe values for the Destination is a Global or Unique Local Addresses:SAM field are generally are generically as follows: 00: 128 bits: The whole SourceAddress is carried in-line. 01: 64 bits: the prefix of Source Address is elided. 10: 16 bits: thefirst 11264 bits of the SourceAddress are elided. 11: 0 bit:The Source Address is fully elided. Whenvalue of those bits are taken from the Destination is a Link Local Addresses: 00: Reserved, should not be used 01:context and padded with zeroes. The remaining 64 bits: the prefix of Source Address is elided.bits are carried inline. 10: 16 bits: the first 112 bits of the SourceAddress are elided. 11: 0 bit:The Source Address is fully elided. When the Destination is a Multicast Addresses: For thevalue of SAM of 00, the Source Address is the unspecified address. For all values of SAM except 00, the Source Address is the Link Local Address of the node. 00: 0 bit: The Source Addressthose bits is taken from the unspecified addresscontext and it is fully elided. 01: 64 bits: the prefix of Source Address is elided. 10:padded with zeroes. The remaining 16 bits: the first 112bits of the Source Addressare elided.carried inline. 11: 0 bit:bit. The SourceAddress is fully elided. DAM: Destination Address Mode: When the Destination is a Global or Unique Local Addresses: 00: 128 bits:The whole Destination Address is carried in- line. 01: 64 bits: the prefix of Destination Address is elided. 10: 16 bits: thefirst 11264 bits of the DestinationAddress are elided. 11: 0 bit: The Destination Address is fully elided. Whenelided taken from the Destination is a Link Local Addresses: 00: Reserved, should not be used 01:context. The remaining 64 bits:bits are computed from the prefixlink layer address as defined in [RFC4944]. This generic rule applies depending on the CM field and with exceptions as follows: CM field of Source Address10 (well-known prefix): The value of 00 is elided. 10: 16 bits: the first 112 bitsreserved for SAM and DAM. CM field of the Source Address are elided. 11: 0 bit:11 (well-known pattern): The SAM value of 00 indicates that the Source Address is fully elided. Whenthe unspecified address. The compression of the Destination is a Multicast Addresses:Address relies on well-known patterns for multicast addresses as follows: 00: 8 bits. Used to compress the most used permanently- assigned multicast addresses. A prefix of FF02::/120 is elided. The remaining 8 bits are carried inline. 01: 24 bits. Used to compress Solicited-Node multicast addresses. A prefix of FF02:0:0:0:0:1:FF00/104FF02::1:FF00:0/104 is elided. The remaining 24 bits are carried inline. 10: 16 bits: The Compressed Multicast address fsmg where f is 4-bit flags, s is 4-bit scope, and mg is the least significant 8 bits of the multicast group identifier FFfs:: 00mg. The 16 bits of fsmg are carried inline. 11: 24 bits: The Compressed Multicast address fsmgmg where f is 4-bit flags, s is 4-bit scope, and mgmg is the least significant 16 bits of the multicast group identifier FFfs:: mgmg. The 24 bits of fsmgmg are carried inline. 2.1.2. Context Identifier Extension This specification expects that a concept of context is shared between the node that compresses a packet and the node(s) that need to expand it. The specification enables a node to use of up to 16 contexts. How the contexts are shared and maintained is out of scope. Actions in response to unknown and/or invalid contexts are out of scope. If the DDFCM field is set to '01' in the LOWPAN_HC encoding, then an additional octet extends the LOWPAN_HC encoding following the DAM bits but before the IPv6 header fields that are carried in-line. The additional octet identifies the prefix when the IPv6 source and/or destination address is compressed. The context identifier is 4 bits for each address, supporting up to 16 contexts. The encoding is shown in Figure 3. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | SAC | DAC | +---+---+---+---+---+---+---+---+ Figure 3: LOWPAN_IPHC Encoding SAC: Source Address Context Identifies the prefix that is used when the IPv6 source address is compressed. DAC: Destination Address Context Identifies the prefix that is used when the IPv6 destination address is compressed. 2.2. IPv6 Header Encoding Fields carried in-line (in part or in whole) appear in the same order as they do in the IPv6 header format [RFC2460]. The Version field is always elided. Unicast IPv6 addresses may be compressed to 64 or 16 bits or completely elided. Multicast IPv6 addresses may be compressed to 8, 16, or 24 bits. 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.1. Traffic Class and Flow Label Encoding The TF field in the LOWPAN_HC encoding indicate whether the Traffic Class and Flow Label are carried in-line in the compressed IPv6 header. When Flow Label is included while the Traffic Class is compressed, an additional 4 bits are included to maintain byte- alignment. Two of the 4 bits contain the ECN bits from the Traffic Class field. To ensure that the ECN bits appear in the same location for all encodings that include them, the Traffic Class field is rotated right by 2 bits in the compressed IPv6 header. The encodings are shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ECN| DSCP | rsv | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TF = 00 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ECN|rsv| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TF = 01 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |ECN| DSCP | +-+-+-+-+-+-+-+-+ TF = 10 2.2.2. IPv6 Address Encoding for Unicast Destinations IPv6 unicast addresses may be carried in-line in full or or compressed to 64, 16, or 0 bits. When compressed, the bits carried in-line represent the least significant bits of the suffix. The value of the prefix depends on the value of the DDF field and possibly the SAC field in the Context Identifier Extension. Destination is Global with No Context ID (DDF = 00): When the source and/or destination addresses are compressed, the prefix is identified by context 0. Destination is Global with Context ID (DDF = 01): When the source and/or destination addresses are compressed, the prefix is identified by the SAC and DAC fields in the Context Identifier Extension, respectively. Destination is Link-Local Unicast (DDF = 10): When the source and/or destination addresses are compressed, the prefix is the link-local unicast prefix (FE80::/10). When an address is completely elided, the lower bits are inferred from lower layers (either from the 6LoWPAN Mesh Addressing header or from the IEEE 802.15.4 header). Specifically, if the lower-layer header contains an extended 802.15.4 address, then a 64-bit suffix is derived from the lower-layer header. If the lower-layer header contains short 802.15.4 address, then a 16-bit suffix is derived from the lower-layer header. 2.2.3. IPv6 Address Encoding for Multicast Destinations IPv6 source addresses with link-local scope may be compressed when the destination address is a multicast address. The IPv6 source address may be compressed to 64, 16, or 0 bits. The encoding also supports the compression of the unspecified address (::). SAM = 00: Source Address is the unspecified address and all 128 bits are elided. SAM = 01: 64-bit prefix is elided and is the link-local (FE80::/10). 64-bit Suffix is carried in-line. SAM = 10: 112-bit prefix is elided and is the link-local (FE80::/10). 16-bit Suffix is carried in-line. SAM = 11: All 128 bits of Source Address are elided. The prefix is the link-local prefix (FE80::/10). The suffix is derived from lower-layer headers. IPv6 multicast addresses may be comrpessed down to 24, 16, or 8 bits. The format supports compression of the Solicited-Node Multicast Address (FF02::1:FFXX:XXXX) as well as any IPv6 multicast address where the upper 104 bits of the multicast group identifier are zero (FFXX::XXXX). The encoding format also compressed link-local multicast addresses of the form (FF02::00XX) down to a single byte. The compressed form only carries least-significant bits of the multicast group identifier. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+ DAM = 00. 8-bit Compressed Multicast Address (FF02::00mg) 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last 24 bits of Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DAM = 01. Compressed Solicited-Node Address (FF02::1:FFXX:XXXX). 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Scope | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DAM = 10. 16-bit Compressed Multicast Address (FFfs::00mg). 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Scope | Last 16 bits of Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DAM = 11. 24-bit Compressed Multicast Address (FFfs::mgmg). 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 4 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 4: 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 5: LOWPAN_NHC Encoding 3.2. UDP Header Compression This document defines a compression format for UDP headers using LOWPAN_NHC. The UDP compression format is shown in Figure 6. 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 | P | +---+---+---+---+---+---+---+---+ Figure 6: UDP Header Encoding C: Checksum: 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. P: Ports: 00: All 16 bits for both Source Port and Destination Port are carried in-line. 01: All 16 bits for Source Port are carried in-line. First 8 bits of Destination Port is 0xF0 and elided. The remaining 8 bits of Destination Port are carried in-line. 10: First 8 bits of Source Port are 0xF0 and elided. The remaining 8 bits of Source Port are carried in-line. All 16 bits for Destination Port are carried in-line. 11: First 12 bits of both Source Port and Destination Port are 0xF0B and elided. The remaining 4 bits for each are carried in-line. 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 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 Dispatch type values of 0x08-0x0F (TBD) for LOWPAN_IPHC. 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 number of prefixes through shared context. How the shared context is assigned and managed is beyond the scope of this document. 6. Acknowledgements Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, and Jay Werb for useful feedback and discussion. 7. Changes Draft 02: - Updated wording with compression mode to clarify that a compression mode does not enforce what kind of destination address is being used. Specifically changed Destination Dependent Field to Compression Mode. - Specify that the configuration and management of contexts is out of scope of this document. Draft 01: - HC back to 1 byte by default by stealing a few bits from the dispatch field. - Added better support for multicast address compression. - Fixed alignment for UDP port compression. - Better support for Traffic Class and Flow Label compression. - Pascal joined as an author. 8. References 188.8.131.52. Normative References [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. [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. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. 184.108.40.206. Informative References [IEEE 802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2006", October 2006. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. Authors' Addresses Jonathan W. Hui (editor) Arch Rock Corporation 501 2nd St. Ste. 410 San Francisco, California 94107 USA Phone: +415 692 0828 Email: email@example.com Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 4 97 23 26 34 Email: firstname.lastname@example.org 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 email@example.com.