Network Working Group                                        J. Hui Hui, Ed.
Internet-Draft                                     Arch Rock Corporation
Updates: 4944 (if approved)                                   P. Thubert
Intended status: Standards Track                         October 6, 2008                                   Cisco
Expires: April 9, 12, 2009                                  October 9, 2008

       Compression Format for IPv6 Datagrams in 6LoWPAN Networks
                        draft-ietf-6lowpan-hc-00
                        draft-ietf-6lowpan-hc-01

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, 12, 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.  This framework specifies UDP
   compression and is
   specified within this framework. 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.2.  IPv6 Unicast Address Compression
       2.1.1.  Base Format  . . . . . . . . . . . . .  6
     2.3.  IPv6 Multicast Address Compression . . . . . . . .  5
       2.1.2.  Context Identifier Extension . . . . . . . . . . . . .  7
     2.4.  16-bit Compressed Address Ranges
     2.2.  IPv6 Header Encoding . . . . . . . . . . . . . . . .  8
   3.  IPv6 Next Header Compression . . .  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.1.  LOWPAN_NHC Format
   3.  IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 11
     3.1.  LOWPAN_NHC Format  . . .  9
     3.2.  LOWPAN_UDP Header Compression . . . . . . . . . . . . . .  9
     3.3.  ISA100_UDP . . . 11
     3.2.  UDP Header Compression . . . . . . . . . . . . . . 10 . . . . 12
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11 13
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12 13
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Author's Address . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 14 15

1.  Introduction

   The IEEE 802.15.4 [IEEE 802.15.4] standard specifies an MTU of 128 bytes, (including
   the length byte) 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[ieee802.15.4]. less.  The
   6LoWPAN adaptation format [RFC4944] was specified to carry IPv6
   datagrams over IEEE 802.15.4 such constrained links, taking into account limited
   bandwidth, memory, or energy resources that are expected in IEEE 802.15.4 applications.  The 6LoWPAN
   adaptation format
   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.  This scenario is
   most effective when communication remains  However, though link local to a mesh-under
   network where any forwarding occurs below IP and all 6LoWPAN nodes addresses 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 commonly used for
   local protocol interactions such as IPv6 Hop Limit 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
   used. limited.

   Routable addresses must be used when communicating with devices
   external to the LoWPAN or in a route-over
   network configuration where IP
   forwarding occurs at IP or when communicating with
   devices external to within the 6LoWPAN network.  In this scenario, LoWPAN.  For routable addresses,
   LOWPAN_HC1 requires both IPv6 source and destination addresses to
   carry the prefix in-line.  Furthermore, in route-over networks,  In cases where the Mesh Addressing header may
   is not be used and used, the IID of a routable address must be carried in-line.  However
   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 the destination is an IPv6 multicast address, LOWPAN_HC1
   requires the full 128-bit
   multicast address to be carried in-line.  Multicast addresses  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
   commonly used useful in many practical cases.
   For instance, if the LoWPAN is a mesh-under stub, a Hop Limit of 1
   for neighbor discovery, inbound and a default value such as in IPv6 ND. 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.  RFC 4944 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] only defines a compression mechanism for UDP, where UDP ports may be compressed and 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
   Length may be elided.  However, checksum over the LoWPAN, which enables to save an
   additional pair of octets.

   Finally, LOWPAN_HC1 also does not provide any lacks the flexibility in supporting future to support the compression
   of additional transport mechanisms for next
   headers other than UDP, TCP or ICMPv6. 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 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-------------------------------------+------------------------
      | Dispatch + LOWPAN_IPHC (2-3 octets) |  Uncompressed fields follow...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Compressed IPv6 Header
      +-------------------------------------+------------------------

                       Figure 1: LOWPAN_IPHC Header

   The LOWPAN_IPHC encoding utilizes a two octets, with uncompressed 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 following, 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
   communicating routing over multiple IP hops,
   LOWPAN_IPHC can compress the IPv6 header down to 7 octets (2-octet (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
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | T |VF |NH 0 | HLIM 1 |    rsv 0 |  SAM 0 |  SAC 1 |  DAM  TF   |NH |  DAC HLIM  |  DDF  |  SAM  |  DAM  |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                      Figure 2: LOWPAN_IPHC Encoding

   T: Traffic Class (bit 0):
      0: Full 8 bits for

   TF: Traffic Class are carried in-line.
      1: Class, Flow Label:
      00:  4-bit Pad + 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 (4 bytes)
      01:  ECN + 2-bit Pad + Flow Label are elided.  Version is implicitly 6. (3 bytes)
      10:  Traffic Class (1 byte)
      11:  Version, Traffic Class, and Flow Label are implicitly 0. compressed.
   NH: Next Hop (bit 2): Header:

      0: Full 8 bits for Next Hop Header are carried in-line.
      1: The Next Hop Header field is elided compressed and the next header is
         compressed using LOWPAN_NHC, which is discussed in Section 3.
   HLIM: Hop Limit (bits 3-4): Limit:
      00:  All 8 bits of  The Hop Limit are field is carried in-line.
      01:  All 8 bits of  The Hop Limit are elided field is compressed and the Hop Limit the hop limit is
         assumed to be 1.
      10:  All 8 bits of  The Hop Limit are elided field is compressed and the Hop Limit the hop limit is
         assumed to be
         64.
      11:  All 8 bits of  The Hop Limit are elided field is compressed and the Hop Limit hop limit is
         assumed to be 255.

   rsv: Reserved (bit 5-7)

   SAC: Source Address Mode (bits 8-9):
   DDF: Destination Dependant Field:
      00:  All 128 bits of  Destination and Source Address are carried in-line. Global or Unique Local Addresses
      01:  64-bit Compressed IPv6 address.
      10:  16-bit Compressed IPv6 address.
      11:  All 128 bits of  Destination and Source Address are elided.

   SAC: Source Address Context (bits 10-11):  Identifies the compression Global or Unique Local Addresses
         and one additional context when octet extends the source LOWPAN_IPHC field
         to disambiguate an elided prefix or address described by the
         SAM or DAM fields.
      10:  Destination and Source are Link Local Addresses
      11:  Destination is compressed.  The value '00' a Multicast Address, Source is
      reserved and indicates either the
         unspecified address or a link-local address.

   DAM: Destination Link Local Address
   SAM: Source Address Mode (bits 12-13): Mode:
      When the Destination is a Global or Unique Local Addresses:
         00:  All  128 bits of Destination bits: The whole Source Address are is carried in-line.
         01:  64-bit Compressed IPv6 address.  64 bits: the prefix of Source Address is elided.
         10:  16-bit Compressed IPv6 address.
      11:  All 128  16 bits: the first 112 bits of Destination the Source Address are
            elided.

   DAC: Destination Address Context (bits 14-15):  Identifies
         11:  0 bit: The Source Address is fully elided.
      When the Destination is a Link Local Addresses:
         00:  Reserved, should not be used
         01:  64 bits: the prefix of Source Address is elided.
         10:  16 bits: the first 112 bits of the Source Address are
            elided.
         11:  0 bit: The Source Address is fully elided.
      When the Destination is a Multicast Addresses:  For the value 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 Address is the unspecified address and
            it is fully elided.
         01:  64 bits: the prefix of Source Address is elided.
         10:  16 bits: the first 112 bits of the Source Address are
            elided.
         11:  0 bit: The Source Address 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: the first 112 bits of the Destination Address are
            elided.
         11:  0 bit: The Destination Address is fully elided.
      When the Destination is a Link Local Addresses:
         00:  Reserved, should not be used
         01:  64 bits: the prefix of Source Address is elided.
         10:  16 bits: the first 112 bits of the Source Address are
            elided.
         11:  0 bit: The Source Address is fully elided.
      When the Destination is a Multicast Addresses:
         00:  8 bits.  Used to compress the most used permanently-
            assigned multicast addresses.  A prefix of FF02::/120 is
            elided.
         01:  24 bits.  Used to compress Solicited-Node multicast
            addresses.  A prefix of FF02:0:0:0:0:1:FF00/104 is elided.
         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.
         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.

2.1.2.  Context Identifier Extension

   If the DDF 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
      compression context prefix when the IPv6 source and/or
   destination address is compressed.  The value '00' context identifier is reserved and indicates a link-local address. 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.

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 Unicast Address Compression Encoding for Unicast Destinations

   IPv6 unicast addresses may be carried in-line in full or or
   compressed to 64, 16, or 0 bits.  When
   an IPv6 unicast address is compressed, the compression context
   identifies bits carried
   in-line represent the value least significant bits of the elided bits.  A compression suffix.  The
   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, depends on 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 value 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 DDF field and
   possibly the SAC field in the network have received
   notification of its deprecation Context Identifier Extension.

   Destination is Global with high probability.

   There may be cases where No Context ID (DDF = 00):   When the compressor and decompressor
      source and/or destination addresses are out of
   sync within a context.  In this cases, the decompressor may
   reconstruct compressed, the IPv6 address using prefix is
      identified by context 0.
   Destination is Global with Context ID (DDF = 01):   When the incorrect prefix.  To prevent
   such errors, upper-layer integrity checks (e.g. psuedo-header
   checksum) that cover both source and
      and/or 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 compressed, the prefix is compressed
   to 16 bits,
      identified by the last 16 bits are carried SAC and DAC fields in line.  Because the 16-bit
   compressed form is also used for IPv6 multicast address compression, the 16-bit address space Context Identifier
      Extension, respectively.
   Destination is divided into multiple ranges.  For
   unicast addresses, the first bit carried in-line must be zero.

                                          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 Link-Local Unicast Address Encoding (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 IID is lower bits are 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  Specifically, if the IID, it MUST be derivable from IEEE lower-layer
   header contains an extended 802.15.4 addresses.
   An IID may be address, then a 64-bit suffix is
   derived from the IEEE EUI-64 address by creating a
   Modified EUI-64 IID from lower-layer header.  If the IEEE EUI-64 lower-layer header
   contains short 802.15.4 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 then a 16-bit suffix is 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. lower-layer header.

2.2.3.  IPv6 Multicast Address Compression Encoding for Multicast Destinations

   IPv6 multicast source addresses with link-local scope 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 when
   the
      6LoWPAN short destination 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 is a multicast group
      identifier. address.  The full 128-bit multicast IPv6 source
   address can may be reconstructed from the 16-
   bit mapped multicast address.  By definition, compressed to 64, 16, or 0 bits.  The encoding also
   supports the 3-bit range
   identifier indicates compression of the well-known multicast prefix (0xFF) in
   addition to a flags field set to all zeros (indicating a permanently
   assigned multicast address, that unspecified address (::).

   SAM = 00:  Source Address is the multicast unspecified address and all 128 bits
      are elided.
   SAM = 01:  64-bit prefix is elided and is not
   assigned based on the network prefix, link-local (FE80::/10).
      64-bit Suffix is carried in-line.
   SAM = 10:  112-bit prefix is elided and that it doesn't embed is the
   address link-local
      (FE80::/10). 16-bit Suffix is carried in-line.
   SAM = 11:  All 128 bits of a Rendezvous Point). Source Address are elided.  The 4-bit scope prefix is carried in-line
   and
      the 112-bit group ID 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 9-bit mapped group ID
   using a well-known mapping maintained by Solicited-Node Multicast
   Address (FF02::1:FFXX:XXXX) as well as any IPv6 multicast address
   where the Internet Assigned
   Numbers Authority (IANA).

   Nodes MUST accept both upper 104 bits of the multicast group identifier are zero
   (FFXX::XXXX).  The encoding format also compressed and uncompressed form of well-
   known link-local
   multicast addresses that they subscribe to.  Doing so removes
   any ambiguity of which the form (FF02::00XX) down to use as both will work.  Conversely,
   nodes MUST NOT subscribe to well-known multicast addresses that are
   not defined by a single byte.
   The compressed form only carries least-significant bits of the well-known mapping.

   This document defines an initial mapping.  Additional mappings
   between 9-bit mapped group IDs and 112-bit
   multicast group IDs may be specified
   in the future.

                +-------+---------+-----------------------+
                | 9-bit identifier.

            0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+
           | 112-bit   Group ID    | Description
           +-+-+-+-+-+-+-+-+

         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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           | All Nodes Addresses Flags | Scope |   2   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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           | All Routers Addresses Flags |
                +-------+---------+-----------------------+

                     9-bit to 112-bit Scope |   Last 16 bits of Group ID Mapping

2.4.  16-bit    |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        DAM = 11. 24-bit Compressed Multicast 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. (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 5 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 5: 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 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
   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 compressed next header...
               +----------------+---------------------------
                       Figure 5: LOWPAN_NHC Encoding

3.2.  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 UDP compression format is shown in Figure 8. 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 | S | D   P   |
                     +---+---+---+---+---+---+---+---+

                       Figure 8: Compressed ISA100.11a 6: UDP Header Encoding

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

   S:
   P: Ports:
      00:  All 16 bits for both Source Port (bit 6):
      0: and Destination Port are
         carried in-line.
      01:  All 16 bits of for Source Port are carried in-line.
      1:  First 12 8
         bits of Source Destination Port are elided is 0xF0 and the elided.  The remaining 4 8
         bits of Destination Port are carried in-line.  The
      10:  First 8 bits of Source Port is recovered by: P +
         short_port, where P is 61616 (0xF0B0).

   D: Destination are 0xF0 and elided.  The
         remaining 8 bits of Source Port (bit 7):
      0: are carried in-line.  All 16
         bits of for Destination Port are carried in-line.
      1:
      11:  First 12 bits of both Source Port and Destination Port are elided
         0xF0B and the elided.  The remaining 4 bits for each 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]. [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 a new Dispatch type value values of 0x03
   0x08-0x0F (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. number of prefixes through shared
   context.  How that global
   prefix the shared context 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 Julien Abeille, Carsten Bormann Bormann, Christos Polyzois, and Jay
   Werb 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.

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

7.2.  Informative References

   [IEEE 802.15.4]
              IEEE Computer Society, "IEEE Std. 802.15.4-2006",
              October 2006.

7.2.  Informative References

   [RFC3552]  Rescorla, E.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and B. Korver, "Guidelines M. Carney, "Dynamic Host Configuration Protocol for Writing RFC
              Text on Security Considerations", BCP 72,
              IPv6 (DHCPv6)", RFC 3552, 3315, July 2003.

Author's Address

   [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: jhui@archrock.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: pthubert@cisco.com

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.