[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                             J. Hui
Internet-Draft                                                 D. Culler
Intended status: Standards Track                   Arch Rock Corporation
Expires: December 30, 2007                                 June 28, 2007


   Stateless IPv6 Header Compression for Globally Routable Packets in
                          6LoWPAN Subnetworks
                       draft-hui-6lowpan-hc1g-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 December 30, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies a stateless IP header compression scheme for
   IPv6 packet delivery in 6LoWPAN subnetworks.  The compression scheme
   focuses on LoWPAN nodes that may have global unicast addresses
   assigned to their interfaces.






Hui & Culler            Expires December 30, 2007               [Page 1]


Internet-Draft   6LoWPAN Compression of Global Addresses       June 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Header Compression . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  LOWPAN_HC1g Encoding of IPv6 Header Fields . . . . . . . .  5
     2.2.  LOWPAN_HC2 Encoding of UDP Header Fields . . . . . . . . .  7
     2.3.  ICMP and TCP Header Compression  . . . . . . . . . . . . .  7
   3.  Modified IEEE EUI-64 Interface Identifiers . . . . . . . . . .  8
   4.  16-bit Short Addresses . . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 12


































Hui & Culler            Expires December 30, 2007               [Page 2]


Internet-Draft   6LoWPAN Compression of Global Addresses       June 2007


1.  Introduction

   The IEEE 802.15.4 standard specifies an MTU of 128 bytes, including
   the length byte [ieee802.15.4] on a 250 kbps wireless link.  Because
   the link MTU is small, in fact smaller than the required 1280-byte
   MTU of IPv6 [RFC2460], and because bandwidth, memory, or power
   resources are critical in many IEEE 802.15.4 applications, 6LoWPAN
   has defined an adaptation layer to support layer 3 (LOWPAN_HC1) and
   layer 4 (LOWPAN_HC2) header compression, and sub-IP fragmentation,
   for packet delivery over IEEE 802.15.4 links
   [I-D.ietf-6lowpan-format].  Substantial portions of the headers are
   elided, where they can be derived by the receiver from information
   contained in the IEEE 802.15.4 frame with basic assumptions of shared
   context.

   The IPv6 addressing architecture supports a notion of scoping
   [RFC4291].  Addresses defined within a scope must not extend beyond
   their scope.  Currently, IPv6 defines three unicast address scopes:
   link-local, site-local, and global.  Link-local addresses are
   composed of a well-known 64-bit prefix and a 64-bit interface
   identifier.  Link-local addresses are intended for addressing on a
   single link.  They are commonly used for configuration protocols or
   communication between nodes when no router exists.  Site-local
   addresses were originally intended for use within an
   administratively-defined domain, but their use has since been
   deprecated.  Global addresses are intended for addressing any node
   connected to the IPv6 network, including nodes within a local scope
   once configured.  A global address is composed of a n-bit global
   routing prefix, m-bit subnet identifier, and a 128-n-m-bit interface
   identifier.  Global addresses not starting with a binary 000 are
   required to have a 64-bit interface identifier, where n+m=64.

   LOWPAN_HC1 supports eliding the prefix and/or interface identifier of
   IPv6 source and destination addresses, but only for the link-local
   prefix.  Thus, for any LoWPAN node with a global unicast address
   assigned to its 802.15.4 interface and using it for communication,
   the full 128-bit address must be carried within packets to or from
   the node.  Carrying full source and destination addresses in an IEEE
   802.15.4 packet consumes a quarter of the link-layer's MTU.  This
   overhead occurs in many important situations.  For example, an IPv6
   packet communicated between two nodes within a PAN, whether over a
   single L2 hop or multiple L2 mesh-routed hops, utilizes extensive
   header compression if their link-local addresses are specified, but
   the same communication between the same nodes foregoes HC1 header
   compression if their global address is specified.  For monitoring
   networks, the data collection point is often a machine that is
   connected to the PAN by way of other non-802.15.4 links.  Similarly,
   in automation and control settings, the controller is often a machine



Hui & Culler            Expires December 30, 2007               [Page 3]


Internet-Draft   6LoWPAN Compression of Global Addresses       June 2007


   on existing IP links.  Communication to and from nodes external to
   the PAN utilize global address, so no HC1 header compression is
   permitted, even when only a single IEEE 802.15.4 hop is involved.
   Even where no other kinds of links are involved, IP routing among
   nodes utilizing IEEE 803.15.4 links, as might occur among 802.15.4
   subnets, perhaps using different PAN IDs, different channels, or
   different MACs, cannot utilize HC1 header compression, because the
   link-local address cannot be used.

   This document specifies a stateless header compression scheme for
   layer 3 (LOWPAN_HC1g) that allows compression of global unicast
   addresses and permits existing compression of the layer 4 header.
   Similar to LOWPAN_HC1, LOWPAN_HC1g recognizes that a prefix is shared
   throughout the PAN, but in the LOWPAN_HC1g case it is a shared global
   prefix, rather than the shared link local prefix.  Indeed, link-local
   communication is important to protocols like IPv6 Neighbor Discovery
   [RFC2461] and LOWPAN_HC1 may be used to compress link-local
   addresses.

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.  Header Compression

   The LOWPAN_HC1g header compression scheme proposed in this section
   maintains many of LOWPAN_HC1's design considerations.  First,
   LOWPAN_HC1g is a very simple and low-context form of header
   compression.  Second, it integrates layer 2 with layer 3 compression.
   Finally, it also allows LoWPAN devices to send header compressed
   packets via any of its neighbors, with as little preliminary context-
   building as possible.

   LOWPAN_HC1g operates directly on top of the basic LoWPAN header
   formats defined in Section 5 of the 6LoWPAN format document.
   LOWPAN_HC1g is identified by dispatch value 0x30, whereas LOWPAN_HC1
   is identified by dispatch value 0x10.

   Layer 4 header compression uses LOWPAN_HC2; the only, yet
   significant, difference is where the layer 4 encoding bits appear in
   the header stack.  In LOWPAN_HC1g, the LOWPAN_HC2 encoding bits
   immediately precede the uncompressed layer 4 fields.

   Typical LOWPAN_HC1g/HC2 header configurations are shown in Figure 1.




Hui & Culler            Expires December 30, 2007               [Page 4]


Internet-Draft   6LoWPAN Compression of Global Addresses       June 2007


   +-------------------+--------------+--------------+-----
   | HC1g Header       | Uncompressed | Uncompressed | Data
   |   L4 Uncompressed |   IP Fields  |   UDP Header |
   +-------------------+--------------+--------------+-----

   +-----------------+--------------+-------------+--------------+------
   | HC1g Header     | Uncompressed | HC2 Header  | Uncompressed | Data
   |   L4 Compressed |   IP Fields  |             |   UDP Fields |
   +-----------------+--------------+-------------+--------------+------

          Figure 1: Typical LOWPAN_HC1g/HC2 Header Configurations

2.1.  LOWPAN_HC1g Encoding of IPv6 Header Fields

   The LOWPAN_HC1g header compression scheme supports the expected
   common case on 6LoWPAN networks with no added overhead to LOWPAN_HC1.
   Version is IPv6, Payload Length is derived from the 802.15.4 header
   or "datagram_size" field from the fragmentation header, Traffic Class
   and Flow Label are zero, Next Header is UDP, ICMP, or TCP, one or
   both of IPv6 source and destination addresses are local to the PAN,
   and the source and destination interface identifiers are derived
   directly from the link-layer.  The only field that cannot be
   compressed is the Hops Left field.  Thus, in the local case, the IP
   header is compressed to 2 octets.

   To support compression of global unicast addresses, LOWPAN_HC1g
   assumes that a PAN is assigned one compressible 64-bit global IP
   prefix.  When either the source or destination address matches the
   compressible global IP prefix, the prefix can be elided.  Note that
   additional global IP prefixes may be assigned to an interface, but
   those prefixes are not compressible when using LOWPAN_HC1g.

   Additionally, if interfaces are assigned a 64-bit interface
   identifier, where the upper 49-bits is zero, the 64-bit global prefix
   and the upper 48-bits of the interface identifier may be elided.
   Such interface identifiers represent those with local scope, with the
   universal/global bit set to "0".  The 49th bit is not elided to
   maintain alignment on octet boundaries.  However, enforcing the 49th
   bit to be "0", borrows from the 16-bit short address encoding
   specified in I-D.ietf-6lowpan-format.  [I-D.ietf-6lowpan-format]
   Section 4 discusses how the encoding can be useful for commonly-used
   multicast addresses.

   The address compression encoding in LOWPAN_HC1g has four possible
   forms:






Hui & Culler            Expires December 30, 2007               [Page 5]


Internet-Draft   6LoWPAN Compression of Global Addresses       June 2007


      Full 128-bit Address:  Full 128-bit IPv6 address carried
         unmodified in-line.
      Compressed 64-bit Address:  64-bit prefix elided, 64-bit interface
         identifier carried in-line.  The 64-bit prefix is derived from
         the 64-bit prefix assigned to the PAN.
      Compressed 16-bit Address:  64-bit prefix elided, least
         significant 16 bits of 64-bit interface identifier inline.  The
         64-bit prefix is derived from the 64-bit prefix assigned to the
         PAN.  The upper 48 bits of the interface identifier are assumed
         to be all zeros.
      Full 128-bit IPv6 address elided:  The prefix identifier is
         derived from the 64-bit global prefix assigned to the PAN.  The
         64-bit interface identifier is derived either from the LoWPAN
         Mesh Addressing header or from the IEEE 802.15.4 link header.
         The link-layer addresses used to derive the 64-bit interface
         identifier is a short address, the short address describes the
         lower 16 bits of the interface identifier.  The upper 48 bits
         are assumed to be all zeros.

   The LOWPAN_HC1g encoding field is shown in Figure 2.

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

             Figure 2: LOWPAN_HC1g Header Compression Encoding

   SC: IPv6 source address compression (bits 0 and 1):
      00:  Full 128-bit address
      01:  Compressed 64-bit address
      10:  Compressed 16-bit address
      11:  Full 128-bit IPv6 address elided

   DC: IPv6 destination address compression (bits 2 and 3):
      00:  Full 128-bit address
      01:  Compressed 64-bit address
      10:  Compressed 16-bit address
      11:  Full 128-bit IPv6 address elided

   VTF: Version, Traffic Class, and Flow Label (bit 4):
      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 and assumed
         to be zero.






Hui & Culler            Expires December 30, 2007               [Page 6]


Internet-Draft   6LoWPAN Compression of Global Addresses       June 2007


   NH: Next Header (bits 5 and 6):
      00:  Next header field carried in-line.
      01:  UDP
      10:  ICMP
      11:  TCP

   L4C: Layer 4 Compression (bit 7):
      0: Full layer 4 header is carried in-line.  An HC2 encoding does
         not precede the layer 4 header.
      1: Layer 4 header is compressed.  An HC2 encoding follows the IP
         header but precedes the layer 4 header.  Currently, this
         indicator only supports UDP compression.

   Of the fields in the IPv6 header, the uncompressed field that MUST
   always be carried in-line is Hop Limit.  Payload Length MUST never
   appear, as it is always derived from the IEEE 802.15.4 header or the
   "datagram_size" field in the LoWPAN fragmentation header.  All other
   fields, when carried in-line, MUST appear in the same order as
   specified in RFC 2460 [RFC2460].  When all fields are carried in-
   line, the header looks identical to a full IPv6 header without the
   Payload Length field.  This differs from LOWPAN_HC1, where fields do
   not appear in this order.  While it is possible to always assume IPv6
   for the Version field, it is carried in-line whenever Traffic Class
   and Flow Label are carried in-line.  Not doing so will result in
   field alignment not falling on an octet boundary.  The actual next
   header specified by the LOWPAN_HC1g encoding immediately follows all
   IPv6 header fields carried in-line.

2.2.  LOWPAN_HC2 Encoding of UDP Header Fields

   Bit 7 in the LOWPAN_HC1g encoding specifies whether or not the layer
   4 header is compressed.  If layer 4 compression is specified, then
   the LOWPAN_HC2g encoding replaces the uncompressed form of the layer
   4 header.  For UDP, the HC_UDP encoding scheme remains unchanged from
   the 6LoWPAN format document [I-D.ietf-6lowpan-format].  The only
   difference is that the HC_UDP encoding field immediately precedes the
   in-line UDP fields, rather than sitting between the HC1 encoding and
   in-line IPv6 fields.  This co-locates the bits describing UDP headers
   with the in-line fields.

2.3.  ICMP and TCP Header Compression

   This document does not specify a compression scheme for ICMP and TCP.
   Such compression schemes may be specified in the future.







Hui & Culler            Expires December 30, 2007               [Page 7]


Internet-Draft   6LoWPAN Compression of Global Addresses       June 2007


3.  Modified IEEE EUI-64 Interface Identifiers

   For LOWPAN_HC1g to compress a 128-bit address down to 16-bits, two
   conditions must be satisfied: (i) the prefix matches the compressible
   global prefix assigned to the PAN and (ii) the upper 49-bits of the
   interface identifier must be zeros.  This interface identifier is
   constructed in Modified EUI-64 format, MUST have scope limited to the
   assigned compressible global subnet-prefix, and MUST be subnet-prefix
   unique.  Included in the upper 49-bits is the universal/local bit,
   which is set to "0" to indicate local scope.  As suggested in RFC
   4291 [RFC4291], possible approaches to select such a PAN-unique
   interface identifier may include:

      Manual Configuration
      Node Serial Number
      Other Node-Specific Token


4.  16-bit Short Addresses

   [I-D.ietf-6lowpan-format] specifies an encoding for 16-bit short
   addresses to be used in 6LoWPAN packets.  The document reserves
   0xffff (16-bit broadcast) and 0xfffe as defined in IEEE 802.15.4
   [ieee802.15.4].  The document also specifies five different value
   ranges.  The lower 32,768 values are reserved for unicast addresses
   and the next 8192 values are reserved for a link-layer multicast
   address mapping.

   This document allocates another range of 8192 values to be used for
   commonly used, well-known IPv6 multicast addresses.  By creating a
   mapping between full 128-bit well-known multicast addresses to 16-bit
   short addresses, commonly-used multicast addresses can be compressed
   to 16-bits.  The multicast mapping can be used with the 6LoWPAN Mesh
   Delivery header or a LoWPAN_HC1g header by specifying use of the 16-
   bit short address form.  The encoding used for the 13-bits is as
   follows:

                      0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |Range| Scope | Mapped Group ID |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 3: LOWPAN_HC1g Header Compression Encoding







Hui & Culler            Expires December 30, 2007               [Page 8]


Internet-Draft   6LoWPAN Compression of Global Addresses       June 2007


   Range:  3-bit range identifier which indicates the use of a mapped
      well-known IPv6 multicast address.
   Scope:  4-bit multicast scope as specified in RFC 4007 [RFC4007].
   Mapped Group ID:  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 128-bit Group ID Mapping


5.  IANA Considerations

   This document defines a new layer 3 header compression scheme for
   6LoWPAN networks.  The document allocate a new Dispatch type value of
   0x30 that indicates the use of LOWPAN_HC1g.

   This document requests another range, preferably Range 3 in the 16-
   bit short address field specified in [I-D.ietf-6lowpan-format].

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


6.  Security Considerations

   The definition of LOWPAN_HC1g permits the compression of header



Hui & Culler            Expires December 30, 2007               [Page 9]


Internet-Draft   6LoWPAN Compression of Global Addresses       June 2007


   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.

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.


7.  References

7.1.  Normative References

   [I-D.ietf-6lowpan-format]
              Montenegro, G., "Transmission of IPv6 Packets over IEEE
              802.15.4 Networks", draft-ietf-6lowpan-format-13 (work in
              progress), April 2007.

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

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

7.2.  Informative References

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.







Hui & Culler            Expires December 30, 2007              [Page 10]


Internet-Draft   6LoWPAN Compression of Global Addresses       June 2007


Authors' Addresses

   Jonathan W. Hui
   Arch Rock Corporation
   657 Mission St. Ste. 600
   San Francisco, California  94105
   USA

   Phone: +415 692 0828
   Email: jhui@archrock.com


   David E. Culler
   Arch Rock Corporation
   657 Mission St. Ste. 600
   San Francisco, California  94105
   USA

   Phone: +415 692 0828
   Email: dculler@archrock.com































Hui & Culler            Expires December 30, 2007              [Page 11]


Internet-Draft   6LoWPAN Compression of Global Addresses       June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hui & Culler            Expires December 30, 2007              [Page 12]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/