doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc6282.txt b/doc/rfc/rfc6282.txt
new file mode 100644
index 0000000..71dc208
--- /dev/null
+++ b/doc/rfc/rfc6282.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       J. Hui, Ed.
+Request for Comments: 6282                         Arch Rock Corporation
+Updates: 4944                                                 P. Thubert
+Category: Standards Track                                          Cisco
+ISSN: 2070-1721                                           September 2011
+
+
+                 Compression Format for IPv6 Datagrams
+                   over IEEE 802.15.4-Based Networks
+
+Abstract
+
+   This document updates RFC 4944, "Transmission of IPv6 Packets over
+   IEEE 802.15.4 Networks".  This document specifies an IPv6 header
+   compression format for IPv6 packet delivery in Low Power Wireless
+   Personal Area Networks (6LoWPANs).  The compression format relies on
+   shared context to allow compression of arbitrary prefixes.  How the
+   information is maintained in that shared context is out of scope.
+   This document specifies compression of multicast addresses and a
+   framework for compressing next headers.  UDP header compression is
+   specified within this framework.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6282.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hui & Thubert                Standards Track                    [Page 1]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Requirements Language ......................................4
+   2. Specific Updates to RFC 4944 ....................................4
+   3. IPv6 Header Compression .........................................5
+      3.1. LOWPAN_IPHC Encoding Format ................................6
+           3.1.1. Base Format .........................................6
+           3.1.2. Context Identifier Extension .......................10
+      3.2. IPv6 Header Encoding ......................................11
+           3.2.1. Traffic Class and Flow Label Compression ...........11
+           3.2.2. Deriving IIDs from the Encapsulating Header ........12
+           3.2.3. Stateless Multicast Address Compression ............13
+           3.2.4. Stateful Multicast Address Compression .............14
+   4. IPv6 Next Header Compression ...................................15
+      4.1. LOWPAN_NHC Format .........................................15
+      4.2. IPv6 Extension Header Compression .........................15
+      4.3. UDP Header Compression ....................................17
+           4.3.1. Compressing UDP Ports ..............................17
+           4.3.2. Compressing UDP Checksum ...........................18
+           4.3.3. UDP LOWPAN_NHC Format ..............................20
+   5. IANA Considerations ............................................20
+   6. Security Considerations ........................................21
+   7. Acknowledgements ...............................................22
+   8. References .....................................................22
+      8.1. Normative References ......................................22
+      8.2. Informative References ....................................23
+
+
+
+
+
+
+
+
+
+Hui & Thubert                Standards Track                    [Page 2]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+1.  Introduction
+
+   The [IEEE802.15.4] standard specifies an MTU of 127 bytes, yielding
+   about 80 octets of actual Media Access Control (MAC) payload with
+   security enabled, on a wireless link with a link throughput of 250
+   kbps or less.  The 6LoWPAN adaptation format [RFC4944] was specified
+   to carry IPv6 datagrams over such constrained links, taking into
+   account limited bandwidth, memory, or energy resources that are
+   expected in applications such as wireless sensor networks.  [RFC4944]
+   defines a Mesh Addressing header to support sub-IP forwarding, a
+   Fragmentation header to support the IPv6 minimum MTU requirement
+   [RFC2460], and stateless header compression for IPv6 datagrams
+   (LOWPAN_HC1 and LOWPAN_HC2) to reduce the relatively large IPv6 and
+   UDP headers down to (in the best case) several bytes.
+
+   LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of
+   IPv6 in 6LoWPANs.  LOWPAN_HC1 is most effective for link-local
+   unicast communication, where IPv6 addresses carry the link-local
+   prefix and an Interface Identifier (IID) directly derived from IEEE
+   802.15.4 addresses.  In this case, both addresses may be completely
+   elided.  However, though link-local addresses are commonly used for
+   local protocol interactions such as IPv6 Neighbor Discovery
+   [RFC4861], DHCPv6 [RFC3315], or routing protocols, they are usually
+   not used for application-layer data traffic, so the actual value of
+   this compression mechanism is limited.
+
+   Routable addresses must be used when communicating with devices
+   external to the 6LoWPAN or in a route-over configuration where IP
+   forwarding occurs within the 6LoWPAN.  For routable addresses,
+   LOWPAN_HC1 requires both IPv6 source and destination addresses to
+   carry the prefix in-line.  In cases where the Mesh Addressing header
+   is not used, the IID of a routable address must be carried in-line.
+   However, LOWPAN_HC1 requires 64 bits for the IID when carried in-line
+   and cannot be shortened even when it is derived from the IEEE
+   802.15.4 16-bit short address.  When the destination is an IPv6
+   multicast address, LOWPAN_HC1 requires the full 128-bit address to be
+   carried in-line.
+
+   As a result, this document defines an encoding format, LOWPAN_IPHC,
+   for effective compression of Unique Local, Global, and multicast IPv6
+   Addresses based on shared state within contexts.  In addition, this
+   document also introduces a number of additional improvements over the
+   header compression format defined in [RFC4944].
+
+   LOWPAN_IPHC allows for compression of some commonly used IPv6 Hop
+   Limit values.  If the 6LoWPAN is a mesh-under stub, a Hop Limit of 1
+   for inbound and a default value such as 64 for outbound are usually
+   enough for application-layer data traffic.  Additionally, a Hop Limit
+
+
+
+Hui & Thubert                Standards Track                    [Page 3]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   value of 255 is often used to verify that a communication occurs over
+   a single-hop.  This specification enables compression of the IPv6 Hop
+   Limit field in those common cases, whereas LOWPAN_HC1 does not.
+
+   This document also defines LOWPAN_NHC, an encoding format for
+   arbitrary next headers.  LOWPAN_IPHC indicates whether the following
+   header is encoded using LOWPAN_NHC.  If so, the bits immediately
+   following the compressed IPv6 header start the LOWPAN_NHC encoding.
+   In contrast, LOWPAN_HC1 could be extended to support compression of
+   next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6.
+   Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet
+   and uncompressed IPv6 header fields.  This specification moves the
+   next header encoding bits to follow all IPv6-related bits, allowing
+   for a properly layered structure and direct support for IPv6
+   extension headers.
+
+   Using LOWPAN_NHC, this document defines a compression mechanism for
+   UDP.  While [RFC4944] defines a compression mechanism for UDP, 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
+   elide the UDP checksum over the 6LoWPAN, which enables saving of a
+   further two octets.
+
+   Also, using LOWPAN_NHC, this document defines encoding formats for
+   IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers.  With
+   LOWPAN_HC1 and LOWPAN_HC2, chains of next headers cannot be encoded
+   efficiently.
+
+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.  Specific Updates to RFC 4944
+
+   This document specifies a header compression format that is intended
+   to replace that defined in Section 10 of [RFC4944].  Implementation
+   of Section 10 of [RFC4944] is now NOT RECOMMENDED.  New
+   implementations MAY implement decompression according to Section 10
+   of [RFC4944] but SHOULD NOT send packets compressed according to
+   Section 10 of [RFC4944].
+
+   A compliant implementation of [RFC4944] as updated by this document
+   MUST be able to properly process a packet received that makes use of
+   the provisions of this document.  A compliant implementation MAY
+   implement additional LOWPAN_NHC types (Section 4) that may be
+
+
+
+Hui & Thubert                Standards Track                    [Page 4]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   registered (Section 5) in the future.  It is out of scope of this
+   document how a compressor learns that a decompressor has additional
+   capabilities.
+
+   Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6
+   datagrams that do not fit within a single link frame.  Section 5.3 of
+   [RFC4944] defines the fragment header's datagram_size and
+   datagram_offset values as the size and offset of the IPv6 datagram
+   before compression.  As a result, all fragment payload outside the
+   first fragment must carry their respective portions of the IPv6
+   datagram before compression.  This document does not change that
+   requirement.  When using the fragmentation mechanism described in
+   Section 5.3 of [RFC4944], any header that cannot fit within the first
+   fragment MUST NOT be compressed.
+
+   The header compression format defined in this document preempts the
+   ESC dispatch value defined in Section 5.1 of [RFC4944].  Instead, the
+   value of 01 000000 is reserved as a replacement value for ESC, to be
+   finally assigned with the first assignment of extension bytes.
+
+3.  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.
+   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 small set of routable prefixes assigned to the entire
+   6LoWPAN; addresses assigned to 6LoWPAN interfaces are formed with an
+   IID derived directly from either the 64-bit extended or the 16-bit
+   short IEEE 802.15.4 addresses.
+
+    +-------------------------------------+----------------------------
+    | Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields
+    +-------------------------------------+----------------------------
+
+                       Figure 1: LOWPAN_IPHC Header
+
+   The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are taken from
+   the rightmost bits of the dispatch type.  The encoding may be
+   extended by another octet to support additional contexts.  Any
+   information from the uncompressed IPv6 header fields carried in-line
+
+
+
+
+
+Hui & Thubert                Standards Track                    [Page 5]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   follow the LOWPAN_IPHC encoding, as shown in Figure 1.  In the best
+   case, the LOWPAN_IPHC can compress the IPv6 header down to two octets
+   (the dispatch octet and the LOWPAN_IPHC encoding) with link-local
+   communication.
+
+   When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6
+   header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC,
+   1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination
+   Address).  The Hop Limit may not be compressed because it needs to
+   decremented at each hop and may take any value.  Stateful address
+   compression must be applied to the source and destination IPv6
+   addresses because they do not statelessly match the source and
+   destination link-layer addresses on intermediate hops.
+
+3.1.  LOWPAN_IPHC Encoding Format
+
+   This section specifies the format of the LOWPAN_IPHC encoding that
+   describes how an IPv6 header is compressed.  The encoding can be 2
+   octets long for the base encoding or 3 octets long when an additional
+   context encoding is present.  The IPv6 header fields that are not
+   fully elided are placed immediately after the LOWPAN_IPHC, either in
+   a compressed form if the field is partially elided or literally.
+
+3.1.1.  Base Format
+
+       0                                       1
+       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+     | 0 | 1 | 1 |  TF   |NH | HLIM  |CID|SAC|  SAM  | M |DAC|  DAM  |
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+                    Figure 2: LOWPAN_IPHC base Encoding
+
+   TF: Traffic Class, Flow Label:  As specified in [RFC3168], the 8-bit
+      IPv6 Traffic Class field is split into two fields: 2-bit Explicit
+      Congestion Notification (ECN) and 6-bit Differentiated Services
+      Code Point (DSCP).
+
+      00:  ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
+
+      01:  ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided.
+
+      10:  ECN + DSCP (1 byte), Flow Label is elided.
+
+      11:  Traffic Class and Flow Label are elided.
+
+
+
+
+
+
+Hui & Thubert                Standards Track                    [Page 6]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   NH: Next Header:
+
+      0: Full 8 bits for Next Header are carried in-line.
+
+      1: The Next Header field is compressed and the next header is
+         encoded using LOWPAN_NHC, which is discussed in Section 4.1.
+
+   HLIM: Hop Limit:
+
+      00:  The Hop Limit field is carried in-line.
+
+      01:  The Hop Limit field is compressed and the hop limit is 1.
+
+      10:  The Hop Limit field is compressed and the hop limit is 64.
+
+      11:  The Hop Limit field is compressed and the hop limit is 255.
+
+   CID: Context Identifier Extension:
+
+      0: No additional 8-bit Context Identifier Extension is used.  If
+         context-based compression is specified in either Source Address
+         Compression (SAC) or Destination Address Compression (DAC),
+         context 0 is used.
+
+      1: An additional 8-bit Context Identifier Extension field
+         immediately follows the Destination Address Mode (DAM) field.
+
+   SAC: Source Address Compression
+
+      0: Source address compression uses stateless compression.
+
+      1: Source address compression uses stateful, context-based
+         compression.
+
+   SAM: Source Address Mode:
+
+      If SAC=0:
+
+         00:  128 bits.  The full address is carried in-line.
+
+         01:  64 bits.  The first 64-bits of the address are elided.
+            The value of those bits is the link-local prefix padded with
+            zeros.  The remaining 64 bits are carried in-line.
+
+
+
+
+
+
+
+
+Hui & Thubert                Standards Track                    [Page 7]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+         10:  16 bits.  The first 112 bits of the address are elided.
+            The value of the first 64 bits is the link-local prefix
+            padded with zeros.  The following 64 bits are 0000:00ff:
+            fe00:XXXX, where XXXX are the 16 bits carried in-line.
+
+         11:  0 bits.  The address is fully elided.  The first 64 bits
+            of the address are the link-local prefix padded with zeros.
+            The remaining 64 bits are computed from the encapsulating
+            header (e.g., 802.15.4 or IPv6 source address) as specified
+            in Section 3.2.2.
+
+      If SAC=1:
+
+         00:  The UNSPECIFIED address, ::
+
+         01:  64 bits.  The address is derived using context information
+            and the 64 bits carried in-line.  Bits covered by context
+            information are always used.  Any IID bits not covered by
+            context information are taken directly from the
+            corresponding bits carried in-line.  Any remaining bits are
+            zero.
+
+         10:  16 bits.  The address is derived using context information
+            and the 16 bits carried in-line.  Bits covered by context
+            information are always used.  Any IID bits not covered by
+            context information are taken directly from their
+            corresponding bits in the 16-bit to IID mapping given by
+            0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-
+            line.  Any remaining bits are zero.
+
+         11:  0 bits.  The address is fully elided and is derived using
+            context information and the encapsulating header (e.g.,
+            802.15.4 or IPv6 source address).  Bits covered by context
+            information are always used.  Any IID bits not covered by
+            context information are computed from the encapsulating
+            header as specified in Section 3.2.2.  Any remaining bits
+            are zero.
+
+   M: Multicast Compression
+
+      0: Destination address is not a multicast address.
+
+      1: Destination address is a multicast address.
+
+
+
+
+
+
+
+
+Hui & Thubert                Standards Track                    [Page 8]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   DAC: Destination Address Compression
+
+      0: Destination address compression uses stateless compression.
+
+      1: Destination address compression uses stateful, context-based
+         compression.
+
+   DAM: Destination Address Mode:
+
+      If M=0 and DAC=0  This case matches SAC=0 but for the destination
+         address:
+
+         00:  128 bits.  The full address is carried in-line.
+
+         01:  64 bits.  The first 64-bits of the address are elided.
+            The value of those bits is the link-local prefix padded with
+            zeros.  The remaining 64 bits are carried in-line.
+
+         10:  16 bits.  The first 112 bits of the address are elided.
+            The value of the first 64 bits is the link-local prefix
+            padded with zeros.  The following 64 bits are 0000:00ff:
+            fe00:XXXX, where XXXX are the 16 bits carried in-line.
+
+         11:  0 bits.  The address is fully elided.  The first 64 bits
+            of the address are the link-local prefix padded with zeros.
+            The remaining 64 bits are computed from the encapsulating
+            header (e.g., 802.15.4 or IPv6 destination address) as
+            specified in Section 3.2.2.
+
+      If M=0 and DAC=1:
+
+         00:  Reserved.
+
+         01:  64 bits.  The address is derived using context information
+            and the 64 bits carried in-line.  Bits covered by context
+            information are always used.  Any IID bits not covered by
+            context information are taken directly from the
+            corresponding bits carried in-line.  Any remaining bits are
+            zero.
+
+         10:  16 bits.  The address is derived using context information
+            and the 16 bits carried in-line.  Bits covered by context
+            information are always used.  Any IID bits not covered by
+            context information are taken directly from their
+            corresponding bits in the 16-bit to IID mapping given by
+            0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-
+            line.  Any remaining bits are zero.
+
+
+
+
+Hui & Thubert                Standards Track                    [Page 9]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+         11:  0 bits.  The address is fully elided and is derived using
+            context information and the encapsulating header (e.g.
+            802.15.4 or IPv6 destination address).  Bits covered by
+            context information are always used.  Any IID bits not
+            covered by context information are computed from the
+            encapsulating header as specified in Section 3.2.2.  Any
+            remaining bits are zero.
+
+      If M=1 and DAC=0:
+
+         00:  128 bits.  The full address is carried in-line.
+
+         01:  48 bits.  The address takes the form ffXX::00XX:XXXX:XXXX.
+
+         10:  32 bits.  The address takes the form ffXX::00XX:XXXX.
+
+         11:  8 bits.  The address takes the form ff02::00XX.
+
+      If M=1 and DAC=1:
+
+         00:  48 bits.  This format is designed to match Unicast-Prefix-
+            based IPv6 Multicast Addresses as defined in [RFC3306] and
+            [RFC3956].  The multicast address takes the form ffXX:XXLL:
+            PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. where the X are the nibbles
+            that are carried in-line, in the order in which they appear
+            in this format.  P denotes nibbles used to encode the prefix
+            itself.  L denotes nibbles used to encode the prefix length.
+            The prefix information P and L is taken from the specified
+            context.
+
+         01:  reserved
+
+         10:  reserved
+
+         11:  reserved
+
+3.1.2.  Context Identifier Extension
+
+   This specification expects that a conceptual context is shared
+   between the node that compresses a packet and the node(s) that needs
+   to expand it.  How the contexts are shared and maintained is out of
+   scope.  What information is contained within a context information is
+   out of scope.  Actions in response to unknown and/or invalid contexts
+   are out of scope.  The specification enables a node to use up to 16
+   contexts.  The context used to encode the source address does not
+   have to be the same as the context used to encode the destination
+   address.
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 10]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   If the CID field is set to '1' in the LOWPAN_IPHC encoding, then an
+   additional octet extends the LOWPAN_IPHC encoding following the DAM
+   bits but before the IPv6 header fields that are carried in-line.  The
+   additional octet identifies the pair of contexts to be used when the
+   IPv6 source and/or destination address is compressed.  The context
+   identifier is 4 bits for each address, supporting up to 16 contexts.
+   Context 0 is the default context.  The encoding is shown in Figure 3.
+
+                       0   1   2   3   4   5   6   7
+                     +---+---+---+---+---+---+---+---+
+                     |      SCI      |      DCI      |
+                     +---+---+---+---+---+---+---+---+
+
+                      Figure 3: LOWPAN_IPHC Encoding
+
+   SCI: Source Context Identifier.  Identifies the prefix that is used
+      when the IPv6 source address is statefully compressed.
+
+   DCI: Destination Context Identifier.  Identifies the prefix that is
+      used when the IPv6 destination address is statefully compressed.
+
+3.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, 32, or 48 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.
+
+3.2.1.  Traffic Class and Flow Label Compression
+
+   The Traffic Class field in the IPv6 header comprises 6 bits of
+   Diffserv extension [RFC2474] and 2 bits of Explicit Congestion
+   Notification (ECN) [RFC3168].  The TF field in the LOWPAN_IPHC
+   encoding indicates 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:
+
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 11]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+                          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                |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Figure 4: TF = 00: Traffic Class and Flow Label carried in-line
+
+                          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                |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+               Figure 5: TF = 01: Flow Label carried in-line
+
+      0 1 2 3 4 5 6 7
+     +-+-+-+-+-+-+-+-+
+     |ECN|   DSCP    |
+     +-+-+-+-+-+-+-+-+
+
+             Figure 6: TF = 10: Traffic Class carried in-line
+
+3.2.2.  Deriving IIDs from the Encapsulating Header
+
+   LOWPAN_IPHC elides the IIDs of source or destination addresses when
+   SAM = 3 or DAM = 3, respectively.  In this mode, the IID is derived
+   from the encapsulating header.  When the encapsulating header carries
+   IPv6 addresses, bits for the source and destination addresses are
+   copied from the source and destination addresses of the encapsulating
+   IPv6 header.
+
+   The remainder of this section defines the mapping from IEEE 802.15.4
+   [IEEE802.15.4] link-layer addresses to IIDs for both short and
+   extended IEEE 802.15.4 addresses.  IID bits not covered by the
+   context information MAY be elided if they match the link-layer
+   address mapping and MUST NOT be elided if they do not.
+
+   An extended IEEE 802.15.4 address takes the form of an IEEE EUI-64
+   address.  Generating an IID from an extended address is identical to
+   that defined in Appendix A of [RFC4291].  The only change needed to
+   transform an IEEE EUI-64 identifier to an interface identifier is to
+   invert the universal/local bit.
+
+
+
+
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 12]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   A short IEEE 802.15.4 address is 16 bits in length.  Short addresses
+   are mapped into the restricted space of IEEE EUI-64 addresses by
+   setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short
+   address, and all other bits to zero.  As a result, an IID generated
+   from a short address has the form:
+
+      0000:00ff:fe00:XXXX
+
+   where XXXX carries the short address.  The universal/local bit is
+   zero to indicate local scope.
+
+   This mapping for non-EUI-64 identifiers differs from that presented
+   in Appendix A of [RFC4291].  Using the restricted space ensures no
+   overlap with IIDs generated from unrestricted IEEE EUI-64 addresses.
+   Also, including 0xfffe in the middle of the IID helps avoid overlap
+   with other locally managed IIDs.
+
+   This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is
+   also used to reconstruct any part of an IID not covered by context
+   information.
+
+3.2.3.  Stateless Multicast Address Compression
+
+   LOWPAN_IPHC supports stateless compression of multicast addresses
+   when M = 1 and DAC = 0.  An IPv6 multicast address may be compressed
+   down to 48, 32, or 8 bits using stateless compression.  The format
+   supports compression of the Solicited-Node Multicast Address (ff02::
+   1:ffXX:XXXX) as well as any IPv6 multicast address where the upper
+   bits of the multicast group identifier are zero.  The 8-bit
+   compressed form only carries the least-significant bits of the
+   multicast group identifier.  The 48- and 32-bit compressed forms
+   carry the multicast scope and flags in-line, in addition to the
+   least-significant bits of the multicast group identifier.
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Flags | Scope |              Group Identifier                 |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        Group Identifier       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          Figure 7: DAM = 01. 48-bit Compressed Multicast Address
+                          (ffFS::00GG:GGGG:GGGG)
+
+
+
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 13]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Flags | Scope |              Group Identifier                 |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          Figure 8: DAM = 10. 32-bit Compressed Multicast Address
+                             (ffFS::00GG:GGGG)
+
+      0 1 2 3 4 5 6 7
+     +-+-+-+-+-+-+-+-+
+     |   Group ID    |
+     +-+-+-+-+-+-+-+-+
+
+     Figure 9: DAM = 11. 8-bit Compressed Multicast Address (ff02::GG)
+
+3.2.4.  Stateful Multicast Address Compression
+
+   LOWPAN_IPHC supports stateful compression of multicast addresses when
+   M = 1 and DAC = 1.  This document currently defines DAM = 00:
+   context-based compression of Unicast-Prefix-based IPv6 Multicast
+   Addresses [RFC3306][RFC3956].  In particular, the Prefix Length and
+   Network Prefix can be taken from a context.  As a result, LOWPAN_IPHC
+   can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6
+   octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit
+   Rendezvous Point Interface ID (RIID), and 32-bit Group Identifier in-
+   line.
+
+                          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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Flags | Scope | Rsvd / RIID   |       Group Identifier        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |        Group Identifier       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Figure 10: DAM = 00.  Unicast-Prefix-based IPv6 Multicast
+                            Address Compression
+
+   Note that the Reserved field MUST carry the reserved bits from the
+   multicast address format as described in [RFC3306].  When a
+   Rendezvous Point is encoded in the multicast address as described in
+   [RFC3956], the Reserved field carries the RIID bits in-line.
+
+
+
+
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 14]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+4.  IPv6 Next Header Compression
+
+   LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set
+   to 1.  This 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 11 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 11: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration
+
+4.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.
+   This document defines a compression format for IPv6 Extension and UDP
+   headers.
+
+               +----------------+---------------------------
+               | var-len NHC ID | compressed next header...
+               +----------------+---------------------------
+
+                      Figure 12: LOWPAN_NHC Encoding
+
+4.2.  IPv6 Extension Header Compression
+
+   A necessary property of encoding headers using LOWPAN_NHC is that the
+   immediately preceding header must be encoded using either LOWPAN_IPHC
+   or LOWPAN_NHC.  In other words, all headers encoded using the 6LoWPAN
+   encoding format defined in this document must be contiguous.  As a
+   result, this document defines a set of LOWPAN_NHC encodings for
+   selected IPv6 Extension Headers such that the UDP Header Compression
+   defined in Section 4.3 may be used in the presence of those extension
+   headers.
+
+
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 15]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   The LOWPAN_NHC encodings for IPv6 Extension Headers are composed of a
+   single LOWPAN_NHC octet followed by the IPv6 Extension Header.  The
+   format of the LOWPAN_NHC octet is shown in Figure 13.  The first 7
+   bits serve as an identifier for the IPv6 Extension Header immediately
+   following the LOWPAN_NHC octet.  The remaining bit indicates whether
+   or not the following header utilizes LOWPAN_NHC encoding.
+
+                       0   1   2   3   4   5   6   7
+                     +---+---+---+---+---+---+---+---+
+                     | 1 | 1 | 1 | 0 |    EID    |NH |
+                     +---+---+---+---+---+---+---+---+
+
+                 Figure 13: IPv6 Extension Header Encoding
+
+   EID: IPv6 Extension Header ID:
+
+      0: IPv6 Hop-by-Hop Options Header [RFC2460]
+
+      1: IPv6 Routing Header [RFC2460]
+
+      2: IPv6 Fragment Header [RFC2460]
+
+      3: IPv6 Destination Options Header [RFC2460]
+
+      4: IPv6 Mobility Header [RFC6275]
+
+      5: Reserved
+
+      6: Reserved
+
+      7: IPv6 Header
+
+   NH: Next Header:
+
+      0: Full 8 bits for Next Header are carried in-line.
+
+      1: The Next Header field is elided and the next header is encoded
+         using LOWPAN_NHC, which is discussed in Section 4.1.
+
+   For the most part, the IPv6 Extension Header is carried unmodified in
+   the bytes immediately following the LOWPAN_NHC octet, with two
+   important exceptions: Length field and Next Header field.
+
+   The Next Header field contained in IPv6 Extension Headers is elided
+   when the NH bit is set in the LOWPAN_NHC encoding octet.  Note that
+   doing so allows LOWPAN_NHC to utilize no more overhead than the non-
+   encoded IPv6 Extension Header.
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 16]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   The Length field contained in a compressed IPv6 Extension Header
+   indicates the number of octets that pertain to the (compressed)
+   extension header following the Length field.  Note that this changes
+   the Length field definition in [RFC2460] from indicating the header
+   size in 8-octet units, not including the first 8 octets.  Changing
+   the Length field to be in units of octets removes wasteful internal
+   fragmentation.
+
+   IPv6 Hop-by-Hop and Destination Options Headers may use a trailing
+   Pad1 or PadN to achieve 8-octet alignment.  When there is a single
+   trailing Pad1 or PadN option of 7 octets or less and the containing
+   header is a multiple of 8 octets, the trailing Pad1 or PadN option
+   MAY be elided by the compressor.  A decompressor MUST ensure that the
+   containing header is padded out to a multiple of 8 octets in length,
+   using a Pad1 or PadN option if necessary.  Note that Pad1 and PadN
+   options that appear in locations other than the end MUST be carried
+   in-line as they are used to align subsequent options.
+
+   Note that specifying units in octets means that LOWPAN_NHC MUST NOT
+   be used to encode IPv6 Extension Headers that have more than 255
+   octets following the Length field after compression.
+
+   When the identified next header is an IPv6 Header (EID=7), the NH bit
+   of the LOWPAN_NHC encoding is unused and MUST be set to zero.  The
+   following bytes MUST be encoded using LOWPAN_IPHC as defined in
+   Section 3.
+
+4.3.  UDP Header Compression
+
+   This document defines a compression format for UDP headers using
+   LOWPAN_NHC.  The UDP compression format is shown in Figure 14.  Bits
+   0 through 4 represent the NHC ID and '11110' indicates the specific
+   UDP header compression encoding defined in this section.
+
+4.3.1.  Compressing UDP Ports
+
+   This specification allows a particular range of ports number (0xf0b0
+   to 0xf0bf) to be compressed down to 4 bits.  This is a stateless
+   compression that is inherited from [RFC4944], as opposed to a new
+   stateful compression.
+
+   The range of ports compressible down to 4 bits is not in a reserved
+   range.  A network stack implementation that is designed to
+   communicate over a 6LoWPAN should avoid using those ports as dynamic
+   ports whenever possible.
+
+
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 17]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   Considering that this represents only 16 contiguous ports, it can be
+   expected that many incompatible applications will use the same value
+   of port numbers for their own end-to-end needs.  Thus, a port number
+   in the (0xf0b0 to 0xf0bf) range provides very little information
+   about the application at the remote end.
+
+   The overloading of the 0xf0bX ports increases the risk of getting the
+   wrong type of payload and misinterpreting the content compared to
+   ports that are reserved at IANA.  As a result, it is recommended that
+   the use of those ports be associated with a mechanism such as a
+   Transport Layer Security (TLS) [RFC5246] Message Integrity Check
+   (MIC) that makes sure that the content is what is expected and is
+   checked.
+
+4.3.2.  Compressing UDP Checksum
+
+   The UDP checksum operation is mandatory with IPv6 [RFC2460] for all
+   packets.  For that reason, [RFC4944] disallows the compression of the
+   UDP checksum.
+
+   With this specification, a compressor in the source transport
+   endpoint MAY elide the UDP Checksum if it is authorized by the upper
+   layer.  The compressor MUST NOT set the C bit unless it has received
+   such authorization.  Requiring upper-layer authorization ensures that
+   the intended transport peer will have sufficient means to deal with
+   any data corruption that occurs before reaching the destination.  The
+   upper layer MUST NOT provide the authorization unless one of the
+   following cases is satisfied:
+
+   Tunneling:  In this case, 6LoWPAN is deployed as a wireless pseudo-
+      fieldbus by tunneling existing field protocols over UDP.  If the
+      tunneled Protocol Data Unit (PDU) possesses its own addressing,
+      security and integrity check (e.g., IPsec Encapsulating Security
+      Payload tunnel mode [RFC4303] or IP over UDP encapsulation), the
+      tunneling mechanism MAY authorize eliding the UDP checksum in
+      order to save on the encapsulation overhead.
+
+   Message Integrity Check:  In this case, either IPsec Authentication
+      Header [RFC4302] or some other form of integrity check in the UDP
+      payload that covers at least the same information as the UDP
+      checksum (pseudo-header, data) and has at least the same strength.
+
+   To help ensure that the UDP Checksum will be properly restored when
+   expanding a 6LoWPAN packet, an additional integrity check (e.g., a
+   Layer 2 (L2) Message Integrity Check) MUST be used whenever
+   transmitting link frames that carry a compressed UDP datagram that
+
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 18]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   elides the checksum.  Without this additional integrity check, a UDP
+   packet may be delivered to an unintended destination since corruption
+   in data covered by the pseudo-header can go undetected.
+
+   A compressor MUST verify the UDP Checksum before it is elided and
+   MUST ensure that the additional integrity check is in place before
+   verifying and eliding the checksum.  If verification of the UDP
+   Checksum fails, the compressor MUST drop the packet.
+
+   A decompressor that expands a 6LoWPAN packet with the C bit set MUST
+   compute the UDP Checksum on behalf of the source node and place that
+   value in the restored UDP header as specified in the incumbent
+   standards [RFC0768], [RFC2460].  The decompressor MUST unambiguously
+   determine that an additional integrity check was put in place by the
+   compressor and verify the integrity check and SHOULD do so after
+   restoring the UDP Checksum.  If the decompressor cannot unambiguously
+   determine the presence of an integrity check or verification fails,
+   the decompressor MUST drop the packet.
+
+   The recommended ordering of computing and verifying the UDP Checksum
+   and additional integrity check ensures that data is never stored
+   unprotected in memory.  In practice, functionality separation between
+   layers may preclude the recommended ordering.  However, implementors
+   should take special note and understand the risks when dealing with
+   unprotected data covered by the pseudo-header.
+
+   To allow intermediate nodes to compress the UDP Checksum, a
+   forwarding node MAY infer upper-layer authorization for an incoming
+   packet if it has the C bit set and it can unambiguously determine
+   that an integrity check covering the same data as the UDP Checksum
+   was in place while the UDP Checksum was elided.  A forwarding node
+   MUST NOT infer authorization if it cannot unambiguously determine the
+   presence of and verify an integrity check while the UDP Checksum was
+   elided.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 19]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+4.3.3.  UDP LOWPAN_NHC Format
+
+                       0   1   2   3   4   5   6   7
+                     +---+---+---+---+---+---+---+---+
+                     | 1 | 1 | 1 | 1 | 0 | C |   P   |
+                     +---+---+---+---+---+---+---+---+
+
+                      Figure 14: UDP Header Encoding
+
+   C: Checksum:
+
+      0: All 16 bits of Checksum are carried in-line.
+
+      1: All 16 bits of Checksum are elided.  The Checksum is recovered
+         by recomputing it on the 6LoWPAN termination point.
+
+   P: Ports:
+
+      00:  All 16 bits for both Source Port and Destination Port are
+         carried in-line.
+
+      01:  All 16 bits for Source Port are carried in-line.  First 8
+         bits of Destination Port is 0xf0 and elided.  The remaining 8
+         bits of Destination Port are carried in-line.
+
+      10:  First 8 bits of Source Port are 0xf0 and elided.  The
+         remaining 8 bits of Source Port are carried in-line.  All 16
+         bits for Destination Port are carried in-line.
+
+      11:  First 12 bits of both Source Port and Destination Port are
+         0xf0b and elided.  The remaining 4 bits for each are carried
+         in-line.
+
+   Fields carried in-line (in part or in whole) appear in the same order
+   as they do in the UDP header format [RFC0768].  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.
+
+5.  IANA Considerations
+
+   This document defines a new IPv6 header compression format for
+   6LoWPAN.  The document allocates the following 32 Dispatch type field
+   values for LOWPAN_IPHC:
+
+     01 100000
+      through
+     01 111111
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 20]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   This assignment preempts the assignment of 01 111111 for ESC
+   [RFC4944]; this preemption is possible because extension bytes that
+   would enable the use of ESC have not been allocated yet.  Instead,
+   the value:
+
+     01 000000
+
+   is reserved as a replacement value for ESC, to be finally assigned
+   with the first assignment of extension bytes.
+
+   This document also creates a new IANA registry for the LOWPAN_NHC
+   header type, with the following initial content:
+
+     00000000 to 11011111: (unassigned)
+     1110000N: IPv6 Hop-by-Hop Options Header       [RFC6282]
+     1110001N: IPv6 Routing Header                  [RFC6282]
+     1110010N: IPv6 Fragment Header                 [RFC6282]
+     1110011N: IPv6 Destination Options Header      [RFC6282]
+     1110100N: IPv6 Mobility Header                 [RFC6282]
+     1110111N: IPv6 Header                          [RFC6282]
+     11110CPP: UDP Header                           [RFC6282]
+     11111000 to 11111110: (unassigned)
+
+   Capital letters in bit positions represent class-specific bit
+   assignments.  N indicates whether or not additional LOWPAN_NHC
+   encodings follow, as defined in Section 4.2.  CPP represents
+   variables specific to UDP header compression defined in Section 4.3.
+
+   The policy for this registry [RFC5226] is IETF Review.  In this
+   process, new values SHOULD be assigned in a way that preserves the
+   NHC ID abstraction of Section 4 (i.e., k one-bits followed by one
+   zero-bit identify the general class of NHC, followed by class-
+   specific bit assignments).
+
+6.  Security Considerations
+
+   The definition of LOWPAN_IPHC permits the compression of header
+   information on communication that could take place in its absence,
+   albeit in a less efficient form.  It recognizes that a IEEE 802.15.4
+   PAN may have associated with it a number of prefixes through shared
+   context.  How the shared context is assigned and managed is beyond
+   the scope of this document.
+
+   The overloading of the 0xf0bX ports increases the risk of getting the
+   wrong type of payload and misinterpreting the content compared to
+   ports that reserved at IANA.  It is thus recommended that the use of
+
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 21]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   those ports be associated with a mechanism such as a Transport Layer
+   Security (TLS) [RFC5246] Message Integrity Check (MIC) that validates
+   that the content is expected and checked for integrity.
+
+7.  Acknowledgements
+
+   Thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, Carsten
+   Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde Durvy, Erik
+   Nordmark, Christos Polyzois, Joseph Reddy, Shoichi Sakane, Zach
+   Shelby, Dario Tedeschi, Tony Viscardi, and Jay Werb for useful design
+   consideration and implementation feedback.  Special thanks to David
+   Black, Lars Eggert, and Carsten Bormann for their contribution in
+   closing the security issues around UDP compression.
+
+8.  References
+
+8.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.
+
+   [RFC2474]       Nichols, K., Blake, S., Baker, F., and D. Black,
+                   "Definition of the Differentiated Services Field (DS
+                   Field) in the IPv4 and IPv6 Headers", RFC 2474,
+                   December 1998.
+
+   [RFC3168]       Ramakrishnan, K., Floyd, S., and D. Black, "The
+                   Addition of Explicit Congestion Notification (ECN) to
+                   IP", RFC 3168, September 2001.
+
+   [RFC4291]       Hinden, R. and S. Deering, "IP Version 6 Addressing
+                   Architecture", RFC 4291, February 2006.
+
+   [RFC4944]       Montenegro, G., Kushalnagar, N., Hui, J., and D.
+                   Culler, "Transmission of IPv6 Packets over IEEE
+                   802.15.4 Networks", RFC 4944, September 2007.
+
+   [RFC5226]       Narten, T. and H. Alvestrand, "Guidelines for Writing
+                   an IANA Considerations Section in RFCs", BCP 26,
+                   RFC 5226, May 2008.
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 22]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+   [RFC6275]       Perkins, C., Ed., Johnson, D., and J. Arkko,
+                   "Mobility Support in IPv6", RFC 6275, July 2011.
+
+8.2.  Informative References
+
+   [IEEE802.15.4]  IEEE Computer Society, "IEEE Std. 802.15.4-2006",
+                   October 2006.
+
+   [RFC3306]       Haberman, B. and D. Thaler, "Unicast-Prefix-based
+                   IPv6 Multicast Addresses", RFC 3306, August 2002.
+
+   [RFC3315]       Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
+                   C., and M. Carney, "Dynamic Host Configuration
+                   Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3956]       Savola, P. and B. Haberman, "Embedding the Rendezvous
+                   Point (RP) Address in an IPv6 Multicast Address",
+                   RFC 3956, November 2004.
+
+   [RFC4302]       Kent, S., "IP Authentication Header", RFC 4302,
+                   December 2005.
+
+   [RFC4303]       Kent, S., "IP Encapsulating Security Payload (ESP)",
+                   RFC 4303, December 2005.
+
+   [RFC4861]       Narten, T., Nordmark, E., Simpson, W., and H.
+                   Soliman, "Neighbor Discovery for IP version 6
+                   (IPv6)", RFC 4861, September 2007.
+
+   [RFC5246]       Dierks, T. and E. Rescorla, "The Transport Layer
+                   Security (TLS) Protocol Version 1.2", RFC 5246,
+                   August 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 23]
+
+RFC 6282             IPv6 Datagrams on IEEE 802.15.4      September 2011
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hui & Thubert                Standards Track                   [Page 24]
+