Network Working Group                                             J. Hui
Internet-Draft                                     Arch Rock Corporation
Intended status: Standards Track                          March 10, 2008
Expires: September 11, 2008


       Compression Format for IPv6 Datagrams in 6LoWPAN Networks
                        draft-hui-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 September 11, 2008.

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 September 11, 2008               [Page 1]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 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
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13































Hui                    Expires September 11, 2008               [Page 2]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 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, there currently is no defined
   mechanism to elide the UDP Checksum.  In some cases, the same or
   stronger integrity checks may be provided by other mechanisms, such
   as end-to-end security.  Such security may be provided at the network
   layer similar to IPsec or at the transport-layer similar to TLS.  In
   either case, security mechanisms that cover the IPv6 pseudo-header
   and transport-layer header and payload may limit the utility of UDP



Hui                    Expires September 11, 2008               [Page 3]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 2008


   checksums.  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
   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 single octet, with uncompressed



Hui                    Expires September 11, 2008               [Page 4]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 2008


   fields following, as shown in Figure 1.  With the above scenario, the
   LOWPAN_IPHC can compress the IPv6 header down to a single octet (the
   LOWPAN_IPHC encoding octet) with link-local communication.  When
   communicating over multiple IP hops, LOWPAN_IPHC can compress the
   IPv6 header down to 6 octets (1-octet LOWPAN_IPHC, 1-octet Hop Limit,
   2-octet Source Address, and 2-octet Destination Address).

2.1.  LOWPAN_IPHC Encoding Format

                0     1     2     3     4     5     6     7
             +-----+-----+-----+-----+-----+-----+-----+-----+
             | VTF | NH  |HLIM |    SC     |    DC     | rsv |
             +-----+-----+-----+-----+-----+-----+-----+-----+

                      Figure 2: LOWPAN_IPHC Encoding

   VTF: Version, Traffic Class, and Flow Label (bit 0):
      0: Full 4 bits for Version, 8 bits for Traffic Class, and 20 bits
         for Flow Label are carried in-line.
      1: Version, Traffic Class, and Flow Label are elided.  Version is
         implicitly 6.  Traffic Class and Flow Label are implicitly 0.

   NH: Next Hop (bit 1):
      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 (bit 2):
      0: All 8 bits of Hop Limit are carried in-line.
      1: All 8 bits of Hop Limit are elided.  If the IPv6 destination
         address is not assigned to the receiving interface, Hop Limit
         is assumed to be 64 (TBD).  If the IPv6 destination address is
         assigned to the receiving interface, Hop Limit is assumed to be
         1.  XXX: What is the correct way to specify when the Hop Limit
         can be elided?

   SRC: Source Address (bits 3 and 4):
      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.

   DST: Destination Address (bits 5 and 6):
      00:  All 128 bits of Destination Address are carried in-line.







Hui                    Expires September 11, 2008               [Page 5]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 2008


      01:  64-bit Compressed IPv6 address.
      10:  16-bit Compressed IPv6 address.
      11:  All 128 bits of Destination Address are elided.

   rsv: Reserved (bit 7).

   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 elided bits are implicitly
   the Common Prefix (CP).  The CP can either be the link-local prefix
   or Common Routable Prefix (CRP).  The 6LoWPAN dispatch value
   identifies which CP is being used.  A 6LoWPAN dispatch value of 0x03
   (TBD) indicates a LOWPAN_IPHC compressed IPv6 header and the CP is
   the link-local prefix.  A 6LoWPAN dispatch value of 0x04 (TBD)
   indicates a LOWPAN_IPHC compressed IPv6 header and the CP is the
   Common Routable Prefix.  The Common Routable Prefix may be obtained
   with IPv6 Stateless Address Autoconfiguration when autoconfiguring an
   address[RFC4862].  Other mechanisms for obtaining the CRP or
   selecting a CRP among two or more routable prefixes are out of scope
   of this document.

   There may be cases where the compressor and decompressor are out of
   sync on the CRP.  In this cases, the decompressor may reconstruct the
   IPv6 address using the incorrect CRP.  Fortunately, end-to-end
   integrity checks that cover the pseudo-header (e.g.  UDP checksum)
   should catch this error and is why they are required.  The time spent
   in the inconsistent state with respect to the CRP should be
   minimized.

   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 September 11, 2008               [Page 6]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 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 CP.  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 by setting the first 48 bits
   to zero and the remaining 16 bits to the short address.  Note that
   the most significant bit in the short address must be zero.  XXX:
   RFC4944 requires the PANID to be included, but is this really
   necessary?

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].







Hui                    Expires September 11, 2008               [Page 7]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 2008


   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
   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).

   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 utilzies 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 September 11, 2008               [Page 8]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 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.  The following bits are specific to
   the next header compression format.  In this document, we define a
   compression format for UDP headers.  Because we expect UDP to be used
   most frequently, it is identified by only a single bit.

               +----------------+---------------------------
               | 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.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     |ID | S | D | C |      rsv      |
                     +---+---+---+---+---+---+---+---+

           Figure 7: Compressed IPv6 Multicast Address Encoding







Hui                    Expires September 11, 2008               [Page 9]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 2008


   ID: Identifier (bit 0):
      0: Identities an IPv6 Next Header value of 17 and the LOWPAN_UDP
         compression format.
      1: Identifies an IPv6 Next Header value other than 17, the
         following bits are used to identify the particular Next Header
         value and compression format.  The bit-patterns for other Next
         Header values are left undefined in this document.

   S: Source Port (bit 1):
      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 2):
      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).

   C: Checksum (bit 3):
      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.

   rsv: Reserved (bits 4-7).

   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) when using LOWPAN_IPHC with link-local addresses and
   0x04 (TBD) when using LOWPAN_IPHC with addresses formed using a
   Common Routable Prefix.

   This document reserves another 16-bit short address range from RFC
   4944 for use with 16-bit compressed well-known IPv6 multicast



Hui                    Expires September 11, 2008              [Page 10]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 2008


   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

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.




Hui                    Expires September 11, 2008              [Page 11]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 2008


   [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.


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 September 11, 2008              [Page 12]


Internet-Draft    6LoWPAN Compression of IPv6 Datagrams       March 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 September 11, 2008              [Page 13]