doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc4944.txt b/doc/rfc/rfc4944.txt
new file mode 100644
index 0000000..57a5513
--- /dev/null
+++ b/doc/rfc/rfc4944.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group                                      G. Montenegro
+Request for Comments: 4944                         Microsoft Corporation
+Category: Standards Track                                 N. Kushalnagar
+                                                              Intel Corp
+                                                                  J. Hui
+                                                               D. Culler
+                                                          Arch Rock Corp
+                                                          September 2007
+
+
+        Transmission of IPv6 Packets over IEEE 802.15.4 Networks
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes the frame format for transmission of IPv6
+   packets and the method of forming IPv6 link-local addresses and
+   statelessly autoconfigured addresses on IEEE 802.15.4 networks.
+   Additional specifications include a simple header compression scheme
+   using shared context and provisions for packet delivery in IEEE
+   802.15.4 meshes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Montenegro, et al.          Standards Track                     [Page 1]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  3
+     1.2.  Terms Used . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  IEEE 802.15.4 Mode for IP  . . . . . . . . . . . . . . . . . .  3
+   3.  Addressing Modes . . . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Maximum Transmission Unit  . . . . . . . . . . . . . . . . . .  5
+   5.  LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . .  6
+     5.1.  Dispatch Type and Header . . . . . . . . . . . . . . . . .  8
+     5.2.  Mesh Addressing Type and Header  . . . . . . . . . . . . . 10
+     5.3.  Fragmentation Type and Header  . . . . . . . . . . . . . . 11
+   6.  Stateless Address Autoconfiguration  . . . . . . . . . . . . . 13
+   7.  IPv6 Link Local Address  . . . . . . . . . . . . . . . . . . . 14
+   8.  Unicast Address Mapping  . . . . . . . . . . . . . . . . . . . 14
+   9.  Multicast Address Mapping  . . . . . . . . . . . . . . . . . . 16
+   10. Header Compression . . . . . . . . . . . . . . . . . . . . . . 16
+     10.1. Encoding of IPv6 Header Fields . . . . . . . . . . . . . . 17
+     10.2. Encoding of UDP Header Fields  . . . . . . . . . . . . . . 19
+     10.3. Non-Compressed Fields  . . . . . . . . . . . . . . . . . . 21
+       10.3.1.  Non-Compressed IPv6 Fields  . . . . . . . . . . . . . 21
+       10.3.2.  Non-Compressed and Partially Compressed UDP Fields  . 21
+   11. Frame Delivery in a Link-Layer Mesh  . . . . . . . . . . . . . 21
+     11.1. LoWPAN Broadcast . . . . . . . . . . . . . . . . . . . . . 23
+   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
+   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
+   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
+   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
+     15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
+     15.2. Informative References . . . . . . . . . . . . . . . . . . 26
+   Appendix A.  Alternatives for Delivery of Frames in a Mesh . . . . 28
+
+1.  Introduction
+
+   The IEEE 802.15.4 standard [ieee802.15.4] targets low-power personal
+   area networks.  This document defines the frame format for
+   transmission of IPv6 [RFC2460] packets as well as the formation of
+   IPv6 link-local addresses and statelessly autoconfigured addresses on
+   top of IEEE 802.15.4 networks.  Since IPv6 requires support of packet
+   sizes much larger than the largest IEEE 802.15.4 frame size, an
+   adaptation layer is defined.  This document also defines mechanisms
+   for header compression required to make IPv6 practical on IEEE
+   802.15.4 networks, and the provisions required for packet delivery in
+   IEEE 802.15.4 meshes.  However, a full specification of mesh routing
+   (the specific protocol used, the interactions with neighbor
+   discovery, etc) is out of the scope of this document.
+
+
+
+
+
+Montenegro, et al.          Standards Track                     [Page 2]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+1.1.  Requirements Notation
+
+   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 [RFC2119].
+
+1.2.  Terms Used
+
+   AES:  Advanced Encryption Scheme
+
+   CSMA/CA:  Carrier Sense Multiple Access / Collision Avoidance
+
+   FFD:  Full Function Device
+
+   GTS:  Guaranteed Time Service
+
+   MTU:  Maximum Transmission Unit
+
+   MAC:  Media Access Control
+
+   PAN:  Personal Area Network
+
+   RFD:  Reduced Function Device
+
+2.  IEEE 802.15.4 Mode for IP
+
+   IEEE 802.15.4 defines four types of frames: beacon frames, MAC
+   command frames, acknowledgement frames, and data frames.  IPv6
+   packets MUST be carried on data frames.  Data frames may optionally
+   request that they be acknowledged.  In keeping with [RFC3819], it is
+   recommended that IPv6 packets be carried in frames for which
+   acknowledgements are requested so as to aid link-layer recovery.
+
+   IEEE 802.15.4 networks can either be nonbeacon-enabled or beacon-
+   enabled [ieee802.15.4].  The latter is an optional mode in which
+   devices are synchronized by a so-called coordinator's beacons.  This
+   allows the use of superframes within which a contention-free
+   Guaranteed Time Service (GTS) is possible.  This document does not
+   require that IEEE networks run in beacon-enabled mode.  In nonbeacon-
+   enabled networks, data frames (including those carrying IPv6 packets)
+   are sent via the contention-based channel access method of unslotted
+   CSMA/CA.
+
+   In nonbeacon-enabled networks, beacons are not used for
+   synchronization.  However, they are still useful for link-layer
+   device discovery to aid in association and disassociation events.
+   This document recommends that beacons be configured so as to aid
+   these functions.  A further recommendation is for these events to be
+
+
+
+Montenegro, et al.          Standards Track                     [Page 3]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+   available at the IPv6 layer to aid in detecting network attachment, a
+   problem being worked on at the IETF at the time of this writing.
+
+   The specification allows for frames in which either the source or
+   destination addresses (or both) are elided.  The mechanisms defined
+   in this document require that both source and destination addresses
+   be included in the IEEE 802.15.4 frame header.  The source or
+   destination PAN ID fields may also be included.
+
+3.  Addressing Modes
+
+   IEEE 802.15.4 defines several addressing modes: it allows the use of
+   either IEEE 64-bit extended addresses or (after an association event)
+   16-bit addresses unique within the PAN [ieee802.15.4].  This document
+   supports both 64-bit extended addresses, and 16-bit short addresses.
+   For use within 6LoWPANs, this document imposes additional constraints
+   (beyond those imposed by IEEE 802.15.4) on the format of the 16-bit
+   short addresses, as specified in Section 12.  Short addresses being
+   transient in nature, a word of caution is in order: since they are
+   doled out by the PAN coordinator function during an association
+   event, their validity and uniqueness is limited by the lifetime of
+   that association.  This can be cut short by the expiration of the
+   association or simply by any mishap occurring to the PAN coordinator.
+   Because of the scalability issues posed by such a centralized
+   allocation and single point of failure at the PAN coordinator,
+   deployers should carefully weigh the tradeoffs (and implement the
+   necessary mechanisms) of growing such networks based on short
+   addresses.  Of course, IEEE 64-bit extended addresses may not suffer
+   from these drawbacks, but still share the remaining scalability
+   issues concerning routing, discovery, configuration, etc.
+
+   This document assumes that a PAN maps to a specific IPv6 link.  This
+   complies with the recommendation that shared networks support link-
+   layer subnet [RFC3819] broadcast.  Strictly speaking, it is multicast
+   not broadcast that exists in IPv6.  However, multicast is not
+   supported natively in IEEE 802.15.4.  Hence, IPv6 level multicast
+   packets MUST be carried as link-layer broadcast frames in IEEE
+   802.15.4 networks.  This MUST be done such that the broadcast frames
+   are only heeded by devices within the specific PAN of the link in
+   question.  As per Section 7.5.6.2 in [ieee802.15.4], this is
+   accomplished as follows:
+
+   1.  A destination PAN identifier is included in the frame, and it
+       MUST match the PAN ID of the link in question.
+
+   2.  A short destination address is included in the frame, and it MUST
+       match the broadcast address (0xffff).
+
+
+
+
+Montenegro, et al.          Standards Track                     [Page 4]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+   Additionally, support for mapping of IPv6 multicast addresses per
+   Section 9 MUST only be used in a mesh configuration.  A full
+   specification of such functionality is out of the scope of this
+   document.
+
+   As usual, hosts learn IPv6 prefixes via router advertisements as per
+   [RFC4861].
+
+4.  Maximum Transmission Unit
+
+   The MTU size for IPv6 packets over IEEE 802.15.4 is 1280 octets.
+   However, a full IPv6 packet does not fit in an IEEE 802.15.4 frame.
+   802.15.4 protocol data units have different sizes depending on how
+   much overhead is present [ieee802.15.4].  Starting from a maximum
+   physical layer packet size of 127 octets (aMaxPHYPacketSize) and a
+   maximum frame overhead of 25 (aMaxFrameOverhead), the resultant
+   maximum frame size at the media access control layer is 102 octets.
+   Link-layer security imposes further overhead, which in the maximum
+   case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13
+   for AES-CCM-32 and AES-CCM-64, respectively) leaves only 81 octets
+   available.  This is obviously far below the minimum IPv6 packet size
+   of 1280 octets, and in keeping with Section 5 of the IPv6
+   specification [RFC2460], a fragmention and reassembly adaptation
+   layer must be provided at the layer below IP.  Such a layer is
+   defined below in Section 5.
+
+   Furthermore, since the IPv6 header is 40 octets long, this leaves
+   only 41 octets for upper-layer protocols, like UDP.  The latter uses
+   8 octets in the header which leaves only 33 octets for application
+   data.  Additionally, as pointed out above, there is a need for a
+   fragmentation and reassembly layer, which will use even more octets.
+
+   The above considerations lead to the following two observations:
+
+   1.  The adaptation layer must be provided to comply with the IPv6
+       requirements of a minimum MTU.  However, it is expected that (a)
+       most applications of IEEE 802.15.4 will not use such large
+       packets, and (b) small application payloads in conjunction with
+       the proper header compression will produce packets that fit
+       within a single IEEE 802.15.4 frame.  The justification for this
+       adaptation layer is not just for IPv6 compliance, as it is quite
+       likely that the packet sizes produced by certain application
+       exchanges (e.g., configuration or provisioning) may require a
+       small number of fragments.
+
+   2.  Even though the above space calculation shows the worst-case
+       scenario, it does point out the fact that header compression is
+       compelling to the point of almost being unavoidable.  Since we
+
+
+
+Montenegro, et al.          Standards Track                     [Page 5]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+       expect that most (if not all) applications of IP over IEEE
+       802.15.4 will make use of header compression, it is defined below
+       in Section 10.
+
+5.  LoWPAN Adaptation Layer and Frame Format
+
+   The encapsulation formats defined in this section (subsequently
+   referred to as the "LoWPAN encapsulation") are the payload in the
+   IEEE 802.15.4 MAC protocol data unit (PDU).  The LoWPAN payload
+   (e.g., an IPv6 packet) follows this encapsulation header.
+
+   All LoWPAN encapsulated datagrams transported over IEEE 802.15.4 are
+   prefixed by an encapsulation header stack.  Each header in the header
+   stack contains a header type followed by zero or more header fields.
+   Whereas in an IPv6 header the stack would contain, in the following
+   order, addressing, hop-by-hop options, routing, fragmentation,
+   destination options, and finally payload [RFC2460]; in a LoWPAN
+   header, the analogous header sequence is mesh (L2) addressing, hop-
+   by-hop options (including L2 broadcast/multicast), fragmentation, and
+   finally payload.  These examples show typical header stacks that may
+   be used in a LoWPAN network.
+
+   A LoWPAN encapsulated IPv6 datagram:
+
+      +---------------+-------------+---------+
+      | IPv6 Dispatch | IPv6 Header | Payload |
+      +---------------+-------------+---------+
+
+   A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram:
+
+      +--------------+------------+---------+
+      | HC1 Dispatch | HC1 Header | Payload |
+      +--------------+------------+---------+
+
+   A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that
+   requires mesh addressing:
+
+      +-----------+-------------+--------------+------------+---------+
+      | Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload |
+      +-----------+-------------+--------------+------------+---------+
+
+   A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that
+   requires fragmentation:
+
+      +-----------+-------------+--------------+------------+---------+
+      | Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload |
+      +-----------+-------------+--------------+------------+---------+
+
+
+
+
+Montenegro, et al.          Standards Track                     [Page 6]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+   A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that
+   requires both mesh addressing and fragmentation:
+
+      +-------+-------+-------+-------+---------+---------+---------+
+      | M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
+      +-------+-------+-------+-------+---------+---------+---------+
+
+   A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that
+   requires both mesh addressing and a broadcast header to support mesh
+   broadcast/multicast:
+
+      +-------+-------+-------+-------+---------+---------+---------+
+      | M Typ | M Hdr | B Dsp | B Hdr | HC1 Dsp | HC1 Hdr | Payload |
+      +-------+-------+-------+-------+---------+---------+---------+
+
+   When more than one LoWPAN header is used in the same packet, they
+   MUST appear in the following order:
+
+      Mesh Addressing Header
+
+      Broadcast Header
+
+      Fragmentation Header
+
+   All protocol datagrams (e.g., IPv6, compressed IPv6 headers, etc.)
+   SHALL be preceded by one of the valid LoWPAN encapsulation headers,
+   examples of which are given above.  This permits uniform software
+   treatment of datagrams without regard to the mode of their
+   transmission.
+
+   The definition of LoWPAN headers, other than mesh addressing and
+   fragmentation, consists of the dispatch value, the definition of the
+   header fields that follow, and their ordering constraints relative to
+   all other headers.  Although the header stack structure provides a
+   mechanism to address future demands on the LoWPAN adaptation layer,
+   it is not intended to provided general purpose extensibility.  This
+   format document specifies a small set of header types using the
+   header stack for clarity, compactness, and orthogonality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Montenegro, et al.          Standards Track                     [Page 7]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+5.1.  Dispatch Type and Header
+
+   The dispatch type is defined by a zero bit as the first bit and a one
+   bit as the second bit.  The dispatch type and header are shown here:
+
+                        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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0 1| Dispatch  |  type-specific header
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Dispatch               6-bit selector.  Identifies the type of header
+                          immediately following the Dispatch Header.
+
+   type-specific header   A header determined by the Dispatch Header.
+
+                    Figure 1: Dispatch Type and Header
+
+   The dispatch value may be treated as an unstructured namespace.  Only
+   a few symbols are required to represent current LoWPAN functionality.
+   Although some additional savings could be achieved by encoding
+   additional functionality into the dispatch byte, these measures would
+   tend to constrain the ability to address future alternatives.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Montenegro, et al.          Standards Track                     [Page 8]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+           Pattern    Header Type
+         +------------+-----------------------------------------------+
+         | 00  xxxxxx | NALP       - Not a LoWPAN frame               |
+         | 01  000001 | IPv6       - Uncompressed IPv6 Addresses      |
+         | 01  000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6       |
+         | 01  000011 | reserved   - Reserved for future use          |
+         |   ...      | reserved   - Reserved for future use          |
+         | 01  001111 | reserved   - Reserved for future use          |
+         | 01  010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast             |
+         | 01  010001 | reserved   - Reserved for future use          |
+         |   ...      | reserved   - Reserved for future use          |
+         | 01  111110 | reserved   - Reserved for future use          |
+         | 01  111111 | ESC        - Additional Dispatch byte follows |
+         | 10  xxxxxx | MESH       - Mesh Header                      |
+         | 11  000xxx | FRAG1      - Fragmentation Header (first)     |
+         | 11  001000 | reserved   - Reserved for future use          |
+         |   ...      | reserved   - Reserved for future use          |
+         | 11  011111 | reserved   - Reserved for future use          |
+         | 11  100xxx | FRAGN      - Fragmentation Header (subsequent)|
+         | 11  101000 | reserved   - Reserved for future use          |
+         |   ...      | reserved   - Reserved for future use          |
+         | 11  111111 | reserved   - Reserved for future use          |
+         +------------+-----------------------------------------------+
+
+                   Figure 2: Dispatch Value Bit Pattern
+
+   NALP:  Specifies that the following bits are not a part of the LoWPAN
+      encapsulation, and any LoWPAN node that encounters a dispatch
+      value of 00xxxxxx shall discard the packet.  Other non-LoWPAN
+      protocols that wish to coexist with LoWPAN nodes should include a
+      byte matching this pattern immediately following the 802.15.4.
+      header.
+
+   IPv6:  Specifies that the following header is an uncompressed IPv6
+      header [RFC2460].
+
+   LOWPAN_HC1:  Specifies that the following header is a LOWPAN_HC1
+      compressed IPv6 header.  This header format is defined in
+      Figure 9.
+
+   LOWPAN_BC0:  Specifies that the following header is a LOWPAN_BC0
+      header for mesh broadcast/multicast support and is described in
+      Section 11.1.
+
+   ESC:  Specifies that the following header is a single 8-bit field for
+      the Dispatch value.  It allows support for Dispatch values larger
+      than 127.
+
+
+
+
+Montenegro, et al.          Standards Track                     [Page 9]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+5.2.  Mesh Addressing Type and Header
+
+   The mesh type is defined by a one bit and zero bit as the first two
+   bits.  The mesh type and header are shown here:
+
+                           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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |1 0|V|F|HopsLft| originator address, final address
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 3: Mesh Addressing Type and Header
+
+   Field definitions are as follows:
+
+   V: This 1-bit field SHALL be zero if the Originator (or "Very first")
+      Address is an IEEE extended 64-bit address (EUI-64), or 1 if it is
+      a short 16-bit addresses.
+
+   F: This 1-bit field SHALL be zero if the Final Destination Address is
+      an IEEE extended 64-bit address (EUI-64), or 1 if it is a short
+      16-bit addresses.
+
+   Hops Left:  This 4-bit field SHALL be decremented by each forwarding
+      node before sending this packet towards its next hop.  The packet
+      is not forwarded any further if Hops Left is decremented to zero.
+      The value 0xF is reserved and signifies an 8-bit Deep Hops Left
+      field immediately following, and allows a source node to specify a
+      hop limit greater than 14 hops.
+
+   Originator Address:  This is the link-layer address of the
+      Originator.
+
+   Final Destination Address:  This is the link-layer address of the
+      Final Destination.
+
+   Note that the 'V' and 'F' bits allow for a mix of 16 and 64-bit
+   addresses.  This is useful at least to allow for mesh layer
+   "broadcast", as 802.15.4 broadcast addresses are defined as 16-bit
+   short addresses.
+
+   A further discussion of frame delivery within a mesh is in
+   Section 11.
+
+
+
+
+
+
+
+
+Montenegro, et al.          Standards Track                    [Page 10]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+5.3.  Fragmentation Type and Header
+
+   If an entire payload (e.g., IPv6) datagram fits within a single
+   802.15.4 frame, it is unfragmented and the LoWPAN encapsulation
+   should not contain a fragmentation header.  If the datagram does not
+   fit within a single IEEE 802.15.4 frame, it SHALL be broken into link
+   fragments.  As the fragment offset can only express multiples of
+   eight bytes, all link fragments for a datagram except the last one
+   MUST be multiples of eight bytes in length.  The first link fragment
+   SHALL contain the first fragment header as defined 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |1 1 0 0 0|    datagram_size    |         datagram_tag          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                         Figure 4: First Fragment
+
+   The second and subsequent link fragments (up to and including the
+   last) SHALL contain a fragmentation header that conforms to the
+   format 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |1 1 1 0 0|    datagram_size    |         datagram_tag          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |datagram_offset|
+      +-+-+-+-+-+-+-+-+
+
+                      Figure 5: Subsequent Fragments
+
+   datagram_size:  This 11-bit field encodes the size of the entire IP
+      packet before link-layer fragmentation (but after IP layer
+      fragmentation).  The value of datagram_size SHALL be the same for
+      all link-layer fragments of an IP packet.  For IPv6, this SHALL be
+      40 octets (the size of the uncompressed IPv6 header) more than the
+      value of Payload Length in the IPv6 header [RFC2460] of the
+      packet.  Note that this packet may already be fragmented by hosts
+      involved in the communication, i.e., this field needs to encode a
+      maximum length of 1280 octets (the IEEE 802.15.4 link MTU, as
+      defined in this document).
+
+      NOTE: This field does not need to be in every packet, as one could
+      send it with the first fragment and elide it subsequently.
+      However, including it in every link fragment eases the task of
+      reassembly in the event that a second (or subsequent) link
+
+
+
+Montenegro, et al.          Standards Track                    [Page 11]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+      fragment arrives before the first.  In this case, the guarantee of
+      learning the datagram_size as soon as any of the fragments arrives
+      tells the receiver how much buffer space to set aside as it waits
+      for the rest of the fragments.  The format above trades off
+      simplicity for efficiency.
+
+   datagram_tag:  The value of datagram_tag (datagram tag) SHALL be the
+      same for all link fragments of a payload (e.g., IPv6) datagram.
+      The sender SHALL increment datagram_tag for successive, fragmented
+      datagrams.  The incremented value of datagram_tag SHALL wrap from
+      65535 back to zero.  This field is 16 bits long, and its initial
+      value is not defined.
+
+   datagram_offset:  This field is present only in the second and
+      subsequent link fragments and SHALL specify the offset, in
+      increments of 8 octets, of the fragment from the beginning of the
+      payload datagram.  The first octet of the datagram (e.g., the
+      start of the IPv6 header) has an offset of zero; the implicit
+      value of datagram_offset in the first link fragment is zero.  This
+      field is 8 bits long.
+
+   The recipient of link fragments SHALL use (1) the sender's 802.15.4
+   source address (or the Originator Address if a Mesh Addressing field
+   is present), (2) the destination's 802.15.4 address (or the Final
+   Destination address if a Mesh Addressing field is present), (3)
+   datagram_size, and (4) datagram_tag to identify all the link
+   fragments that belong to a given datagram.
+
+   Upon receipt of a link fragment, the recipient starts constructing
+   the original unfragmented packet whose size is datagram_size.  It
+   uses the datagram_offset field to determine the location of the
+   individual fragments within the original unfragmented packet.  For
+   example, it may place the data payload (except the encapsulation
+   header) within a payload datagram reassembly buffer at the location
+   specified by datagram_offset.  The size of the reassembly buffer
+   SHALL be determined from datagram_size.
+
+   If a link fragment that overlaps another fragment is received, as
+   identified above, and differs in either the size or datagram_offset
+   of the overlapped fragment, the fragment(s) already accumulated in
+   the reassembly buffer SHALL be discarded.  A fresh reassembly may be
+   commenced with the most recently received link fragment.  Fragment
+   overlap is determined by the combination of datagram_offset from the
+   encapsulation header and "Frame Length" from the 802.15.4 Physical
+   Layer Protocol Data Unit (PPDU) packet header.
+
+   Upon detection of a IEEE 802.15.4 Disassociation event, fragment
+   recipients MUST discard all link fragments of all partially
+
+
+
+Montenegro, et al.          Standards Track                    [Page 12]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+   reassembled payload datagrams, and fragment senders MUST discard all
+   not yet transmitted link fragments of all partially transmitted
+   payload (e.g., IPv6) datagrams.  Similarly, when a node first
+   receives a fragment with a given datagram_tag, it starts a reassembly
+   timer.  When this time expires, if the entire packet has not been
+   reassembled, the existing fragments MUST be discarded and the
+   reassembly state MUST be flushed.  The reassembly timeout MUST be set
+   to a maximum of 60 seconds (this is also the timeout in the IPv6
+   reassembly procedure [RFC2460]).
+
+6.  Stateless Address Autoconfiguration
+
+   This section defines how to obtain an IPv6 interface identifier.
+
+   The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may
+   be based on the EUI-64 identifier [EUI64] assigned to the IEEE
+   802.15.4 device.  In this case, the Interface Identifier is formed
+   from the EUI-64 according to the "IPv6 over Ethernet" specification
+   [RFC2464].
+
+   All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short
+   addresses (Section 3 and Section 12) are also possible.  In these
+   cases, a "pseudo 48-bit address" is formed as follows.  First, the
+   left-most 32 bits are formed by concatenating 16 zero bits to the 16-
+   bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be
+   used).  This produces a 32-bit field as follows:
+
+      16_bit_PAN:16_zero_bits
+
+   Then, these 32 bits are concatenated with the 16-bit short address.
+   This produces a 48-bit address as follows:
+
+      32_bits_as_specified_previously:16_bit_short_address
+
+   The interface identifier is formed from this 48-bit address as per
+   the "IPv6 over Ethernet" specification [RFC2464].  However, in the
+   resultant interface identifier, the "Universal/Local" (U/L) bit SHALL
+   be set to zero in keeping with the fact that this is not a globally
+   unique value.  For either address format, all zero addresses MUST NOT
+   be used.
+
+   A different MAC address set manually or by software MAY be used to
+   derive the Interface Identifier.  If such a MAC address is used, its
+   global uniqueness property should be reflected in the value of the
+   U/L bit.
+
+   An IPv6 address prefix used for stateless autoconfiguration [RFC4862]
+   of an IEEE 802.15.4 interface MUST have a length of 64 bits.
+
+
+
+Montenegro, et al.          Standards Track                    [Page 13]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+7.  IPv6 Link Local Address
+
+   The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 interface
+   is formed by appending the Interface Identifier, as defined above, to
+   the prefix FE80::/64.
+
+          10 bits            54 bits                  64 bits
+       +----------+-----------------------+----------------------------+
+       |1111111010|         (zeros)       |    Interface Identifier    |
+       +----------+-----------------------+----------------------------+
+
+                                 Figure 6
+
+8.  Unicast Address Mapping
+
+   The address resolution procedure for mapping IPv6 non-multicast
+   addresses into IEEE 802.15.4 link-layer addresses follows the general
+   description in Section 7.2 of [RFC4861], unless otherwise specified.
+
+   The Source/Target Link-layer Address option has the following forms
+   when the link layer is IEEE 802.15.4 and the addresses are EUI-64 or
+   16-bit short addresses, respectively.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Montenegro, et al.          Standards Track                    [Page 14]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+                       0                   1
+                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                      |     Type      |    Length=2   |
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                      |                               |
+                      +-        IEEE 802.15.4        -+
+                      |          EUI-64               |
+                      +-                             -+
+                      |                               |
+                      +-         Address             -+
+                      |                               |
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                      |                               |
+                      +-         Padding             -+
+                      |                               |
+                      +-        (all zeros)          -+
+                      |                               |
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       0                   1
+                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                      |     Type      |    Length=1   |
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                      |     16-bit short Address      |
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                      |                               |
+                      +-         Padding             -+
+                      |         (all zeros)           |
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                                 Figure 7
+
+   Option fields:
+
+   Type:
+
+      1: for Source Link-layer address.
+
+      2: for Target Link-layer address.
+
+   Length:  This is the length of this option (including the type and
+      length fields) in units of 8 octets.  The value of this field is 2
+      if using EUI-64 addresses, or 1 if using 16-bit short addresses.
+
+   IEEE 802.15.4 Address:  The 64-bit IEEE 802.15.4 address, or the 16-
+      bit short address (as per the format in Section 9), in canonical
+
+
+
+Montenegro, et al.          Standards Track                    [Page 15]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+      bit order.  This is the address the interface currently responds
+      to.  This address may be different from the built-in address used
+      to derive the Interface Identifier, because of privacy or security
+      (e.g., of neighbor discovery) considerations.
+
+9.  Multicast Address Mapping
+
+   The functionality in this section MUST only be used in a mesh-enabled
+   LoWPAN.  An IPv6 packet with a multicast destination address (DST),
+   consisting of the sixteen octets DST[1] through DST[16], is
+   transmitted to the following 802.15.4 16-bit multicast address:
+
+                       0                   1
+                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                      |1 0 0|DST[15]* |   DST[16]     |
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                                 Figure 8
+
+   Here, DST[15]* refers to the last 5 bits in octet DST[15], that is,
+   bits 3-7 within DST[15].  The initial 3-bit pattern of "100" follows
+   the 16-bit address format for multicast addresses (Section 12).
+
+   This allows for multicast support within 6LoWPAN networks, but the
+   full specification of such support is out of the scope of this
+   document.  Example mechanisms are: flooding, controlled flooding,
+   unicasting to the PAN coordinator, etc.  It is expected that this
+   would be specified by the different mesh routing mechanisms.
+
+10.  Header Compression
+
+   There is much published and in-progress standardization work on
+   header compression.  Nevertheless, header compression for IPv6 over
+   IEEE 802.15.4 has differing constraints summarized as follows:
+
+      Existing work assumes that there are many flows between any two
+      devices.  Here, we assume a very simple and low-context flavor of
+      header compression.  Whereas this works independently of flows
+      (potentially several), it does not use any context specific to any
+      flow.  Thus, it cannot achieve as much compression as schemes that
+      build a separate context for each flow to be compressed.
+
+      Given the very limited packet sizes, it is highly desirable to
+      integrate layer 2 with layer 3 compression, something
+      traditionally not done (although now changing due to the ROHC
+      (RObust Header Compression) working group).
+
+
+
+
+Montenegro, et al.          Standards Track                    [Page 16]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+      It is expected that IEEE 802.15.4 devices will be deployed in
+      multi-hop networks.  However, header compression in a mesh departs
+      from the usual point-to-point link scenario in which the
+      compressor and decompressor are in direct and exclusive
+      communication with each other.  In an IEEE 802.15.4 network, it is
+      highly desirable for a device to be able to send header compressed
+      packets via any of its neighbors, with as little preliminary
+      context-building as possible.
+
+   Any new packet formats required by header compression reuse the basic
+   packet formats defined in Section 5 by using different dispatch
+   values.
+
+   Header compression may result in alignment not falling on an octet
+   boundary.  Since hardware typically cannot transmit data in units
+   less than an octet, padding must be used.  Padding is done as
+   follows: First, the entire series of contiguous compressed headers is
+   laid out (this document only defines IPv6 and UDP header compression
+   schemes, but others may be defined elsewhere).  Then, zero bits
+   SHOULD be added as appropriate to align to an octet boundary.  This
+   counteracts any potential misalignment caused by header compression,
+   so subsequent fields (e.g., non-compressed headers or data payloads)
+   start on an octet boundary and follow as usual.
+
+10.1.  Encoding of IPv6 Header Fields
+
+   By virtue of having joined the same 6LoWPAN network, devices share
+   some state.  This makes it possible to compress headers without
+   explicitly building any compression context state.  Therefore,
+   6LoWPAN header compression does not keep any flow state; instead, it
+   relies on information pertaining to the entire link.  The following
+   IPv6 header values are expected to be common on 6LoWPAN networks, so
+   the HC1 header has been constructed to efficiently compress them from
+   the onset: Version is IPv6; both IPv6 source and destination
+   addresses are link local; the IPv6 interface identifiers (bottom 64
+   bits) for the source or destination addresses can be inferred from
+   the layer two source and destination addresses (of course, this is
+   only possible for interface identifiers derived from an underlying
+   802.15.4 MAC address); the packet length can be inferred either from
+   layer two ("Frame Length" in the IEEE 802.15.4 PPDU) or from the
+   "datagram_size" field in the fragment header (if present); both the
+   Traffic Class and the Flow Label are zero; and the Next Header is
+   UDP, ICMP or TCP.  The only field in the IPv6 header that always
+   needs to be carried in full is the Hop Limit (8 bits).  Depending on
+   how closely the packet matches this common case, different fields may
+   not be compressible thus needing to be carried "in-line" as well
+   (Section 10.3.1).  This common IPv6 header (as mentioned above) can
+   be compressed to 2 octets (1 octet for the HC1 encoding and 1 octet
+
+
+
+Montenegro, et al.          Standards Track                    [Page 17]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+   for the Hop Limit), instead of 40 octets.  Such a packet is
+   compressible via the LOWPAN_HC1 format by using a Dispatch value of
+   LOWPAN_HC1 followed by a LOWPAN_HC1 header "HC1 encoding" field (8
+   bits) to encode the different combinations as shown below.  This
+   header may be preceded by a fragmentation header, which may be
+   preceded by a mesh header.
+
+                           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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | HC1 encoding  |     Non-Compressed fields follow...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Figure 9: LOWPAN_HC1 (common compressed header encoding)
+
+   As can be seen below (bit 7), an HC2 encoding may follow an HC1
+   octet.  In this case, the non-compressed fields follow the HC2
+   encoding field (Section 10.3).
+
+   The address fields encoded by "HC1 encoding" are interpreted as
+   follows:
+
+      PI:  Prefix carried in-line (Section 10.3.1).
+
+      PC:  Prefix compressed (link-local prefix assumed).
+
+      II:  Interface identifier carried in-line (Section 10.3.1).
+
+      IC:  Interface identifier elided (derivable from the corresponding
+         link-layer address).  If applied to the interface identifier of
+         either the source or destination address when routing in a mesh
+         (Section 11), the corresponding link-layer address is that
+         found in the "Mesh Addressing" field (Section 5.2).
+
+   The "HC1 encoding" is shown below (starting with bit 0 and ending at
+   bit 7):
+
+      IPv6 source address (bits 0 and 1):
+
+         00:  PI, II
+
+         01:  PI, IC
+
+         10:  PC, II
+
+         11:  PC, IC
+
+
+
+
+
+Montenegro, et al.          Standards Track                    [Page 18]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+      IPv6 destination address (bits 2 and 3):
+
+         00:  PI, II
+
+         01:  PI, IC
+
+         10:  PC, II
+
+         11:  PC, IC
+
+      Traffic Class and Flow Label (bit 4):
+
+         0: not compressed; full 8 bits for Traffic Class and 20 bits
+            for Flow Label are sent
+
+         1: Traffic Class and Flow Label are zero
+
+      Next Header (bits 5 and 6):
+
+         00:  not compressed; full 8 bits are sent
+
+         01:  UDP
+
+         10:  ICMP
+
+         11:  TCP
+
+      HC2 encoding(bit 7):
+
+         0: No more header compression bits
+
+         1: HC1 encoding immediately followed by more header compression
+            bits per HC2 encoding format.  Bits 5 and 6 determine which
+            of the possible HC2 encodings apply (e.g., UDP, ICMP, or TCP
+            encodings).
+
+10.2.  Encoding of UDP Header Fields
+
+   Bits 5 and 6 of the LOWPAN_HC1 allows compressing the Next Header
+   field in the IPv6 header (for UDP, TCP, and ICMP).  Further
+   compression of each of these protocol headers is also possible.  This
+   section explains how the UDP header itself may be compressed.  The
+   HC2 encoding in this section is the HC_UDP encoding, and it only
+   applies if bits 5 and 6 in HC1 indicate that the protocol that
+   follows the IPv6 header is UDP.  The HC_UDP encoding (Figure 10)
+   allows compressing the following fields in the UDP header: source
+   port, destination port, and length.  The UDP header's checksum field
+   is not compressed and is therefore carried in full.  The scheme
+
+
+
+Montenegro, et al.          Standards Track                    [Page 19]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+   defined below allows compressing the UDP header to 4 octets instead
+   of the original 8 octets.
+
+   The only UDP header field whose value may be deduced from information
+   available elsewhere is the Length.  The other fields must be carried
+   in-line either in full or in a partially compressed manner
+   (Section 10.3.2).
+
+                           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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |HC_UDP encoding|     Fields carried in-line follow...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Figure 10: HC_UDP (UDP common compressed header encoding)
+
+   The "HC_UDP encoding" for UDP is shown below (starting with bit 0 and
+   ending at bit 7):
+
+      UDP source port (bit 0):
+
+         0: Not compressed, carried "in-line" (Section 10.3.2)
+
+         1: Compressed to 4 bits.  The actual 16-bit source port is
+            obtained by calculating: P + short_port value.  The value of
+            P is the number 61616 (0xF0B0).  The short_port is expressed
+            as a 4-bit value which is carried "in-line" (Section 10.3.2)
+
+      UDP destination port (bit 1):
+
+         0: Not compressed, carried "in-line" (Section 10.3.2)
+
+         1: Compressed to 4 bits.  The actual 16-bit destination port is
+            obtained by calculating: P + short_port value.  The value of
+            P is the number 61616 (0xF0B0).  The short_port is expressed
+            as a 4-bit value which is carried "in-line" (Section 10.3.2)
+
+      Length (bit 2):
+
+         0: not compressed, carried "in-line" (Section 10.3.2)
+
+         1: compressed, length computed from IPv6 header length
+            information.  The value of the UDP length field is equal to
+            the Payload Length from the IPv6 header, minus the length of
+            any extension headers present between the IPv6 header and
+            the UDP header.
+
+      Reserved (bit 3 through 7)
+
+
+
+Montenegro, et al.          Standards Track                    [Page 20]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+10.3.  Non-Compressed Fields
+
+10.3.1.  Non-Compressed IPv6 Fields
+
+   This scheme allows the IPv6 header to be compressed to different
+   degrees.  Hence, instead of the entire (standard) IPv6 header, only
+   non-compressed fields need to be sent.  The subsequent header (as
+   specified by the Next Header field in the original IPv6 header)
+   immediately follows the IPv6 non-compressed fields.
+
+   Uncompressed IPv6 addressing is described by a dispatch type
+   containing an IPv6 dispatch value followed by the uncompressed IPv6
+   header.  This dispatch type may be preceded by additional LoWPAN
+   headers.
+
+   The non-compressed IPv6 field that MUST be always present is the Hop
+   Limit (8 bits).  This field MUST always follow the encoding fields
+   (e.g., "HC1 encoding" as shown in Figure 9), perhaps including other
+   future encoding fields).  Other non-compressed fields MUST follow the
+   Hop Limit as implied by the "HC1 encoding" in the exact same order as
+   shown above (Section 10.1): source address prefix (64 bits) and/or
+   interface identifier (64 bits), destination address prefix (64 bits)
+   and/or interface identifier (64 bits), Traffic Class (8 bits), Flow
+   Label (20 bits) and Next Header (8 bits).  The actual next header
+   (e.g., UDP, TCP, ICMP, etc) follows the non-compressed fields.
+
+10.3.2.  Non-Compressed and Partially Compressed UDP Fields
+
+   This scheme allows the UDP header to be compressed to different
+   degrees.  Hence, instead of the entire (standard) UDP header, only
+   non-compressed or partially compressed fields need to be sent.
+
+   The non-compressed or partially compressed fields in the UDP header
+   MUST always follow the IPv6 header and any of its associated in-line
+   fields.  Any UDP header in-line fields present MUST appear in the
+   same order as the corresponding fields appear in a normal UDP header
+   [RFC0768], e.g., source port, destination port, length, and checksum.
+   If either the source or destination ports are in "short_port"
+   notation (as indicated in the compressed UDP header), then instead of
+   taking 16 bits, the inline port numbers take 4 bits.
+
+11.  Frame Delivery in a Link-Layer Mesh
+
+   Even though 802.15.4 networks are expected to commonly use mesh
+   routing, the IEEE 802.15.4-2003 specification [ieee802.15.4] does not
+   define such capability.  In such cases, Full Function Devices (FFDs)
+   run an ad hoc or mesh routing protocol to populate their routing
+   tables (outside the scope of this document).  In such mesh scenarios,
+
+
+
+Montenegro, et al.          Standards Track                    [Page 21]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+   two devices do not require direct reachability in order to
+   communicate.  Of these devices, the sender is known as the
+   "Originator", and the receiver is known as the "Final Destination".
+   An originator device may use other intermediate devices as forwarders
+   towards the final destination.  In order to achieve such frame
+   delivery using unicast, it is necessary to include the link-layer
+   addresses of the originator and final destinations, in addition to
+   the hop-by-hop source and destination.
+
+   This section defines how to effect delivery of layer 2 frames in a
+   mesh, given a target "Final Destination" link-layer address.
+
+   Mesh delivery is enabled by including a Mesh Addressing header prior
+   to any other headers of the LoWPAN encapsulation (Section 5), an
+   unfragmented and fragmented header; a full-blown IPv6 header; or a
+   compressed IPv6 header as per Section 10 or any others defined
+   elsewhere.
+
+   If a node wishes to use a default mesh forwarder to deliver a packet
+   (i.e., because it does not have direct reachability to the
+   destination), it MUST include a Mesh Addressing header with the
+   originator's link-layer address set to its own, and the final
+   destination's link-layer address set to the packet's ultimate
+   destination.  It sets the source address in the 802.15.4 header to
+   its own link-layer address, and puts the forwarder's link-layer
+   address in the 802.15.4 header's destination address field.  Finally,
+   it transmits the packet.
+
+   Similarly, if a node receives a frame with a Mesh Addressing header,
+   it must look at the Mesh Addressing header's "Final Destination"
+   field to determine the real destination.  If the node is itself the
+   final destination, it consumes the packet as per normal delivery.  If
+   it is not the final destination, the device then reduces the "Hops
+   Left" field, and if the result is zero, discards the packet.
+   Otherwise, the node consults its link-layer routing table, determines
+   what the next hop towards the final destination should be, and puts
+   that address in the destination address field of the 802.15.4 header.
+   Finally, the node changes the source address in the 802.15.4 header
+   to its own link-layer address and transmits the packet.
+
+   Whereas a node must participate in a mesh routing protocol to be a
+   forwarder, no such requirement exists for simply using mesh
+   forwarding.  Only "Full Function Devices" (FFDs) are expected to
+   participate as routers in a mesh.  "Reduced Function Devices" (RFDs)
+   limit themselves to discovering FFDs and using them for all their
+   forwarding, in a manner similar to how IP hosts typically use default
+   routers to forward all their off-link traffic.  For an RFD using mesh
+   delivery, the "forwarder" is always the appropriate FFD.
+
+
+
+Montenegro, et al.          Standards Track                    [Page 22]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+11.1.  LoWPAN Broadcast
+
+   Additional mesh routing functionality is encoded using a routing
+   header immediately following the Mesh header.  In particular, a
+   broadcast header consists of a LOWPAN_BC0 dispatch followed by a
+   sequence number field.  The sequence number is used to detect
+   duplicate packets (and hopefully suppress them).
+
+                           1
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|1|LOWPAN_BC0 |Sequence Number|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 11: Broadcast Header
+
+   Field definitions are as follows:
+
+   Sequence Number:  This 8-bit field SHALL be incremented by the
+      originator whenever it sends a new mesh broadcast or multicast
+      packet.  Full specification of how to handle this field is out of
+      the scope of this document.
+
+   Further implications of such mesh-layer broadcast, e.g., whether it
+   maps to a controlled flooding mechanism or its role in, say, topology
+   discovery, is out of the scope of this document.
+
+   Additional mesh routing capabilities, such as specifying the mesh
+   routing protocol, source routing, and so on may be expressed by
+   defining additional routing headers that precede the fragmentation or
+   addressing header in the header stack.  The full specification of
+   such mesh routing capabilities are out of the scope of this document.
+
+12.  IANA Considerations
+
+   This document creates two new IANA registries, as discussed below.
+   Future assignments in these registries are to be coordinated via IANA
+   under the policy of "Specification Required" [RFC2434].  It is
+   expected that this policy will allow for other (non-IETF)
+   organizations to more easily obtain assignments.
+
+   This document creates a new IANA registry for the Dispatch type field
+   shown in the header definitions in Section 5.  This document defines
+   the values IPv6, LOWPAN_HC1 header compression, BC0 broadcast and two
+   escape patterns (NALP to indicate not a LOWPAN frame and ESC to allow
+   additional dispatch bytes).  This document defines this field to be 8
+   bits long.  The values 00xxxxxx being reserved and not used, allows
+   for a total of 192 different values, which should be more than
+
+
+
+Montenegro, et al.          Standards Track                    [Page 23]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+   enough.  If header compression formats in addition to HC1 are defined
+   or if additional TCP, ICMP HC2 formats are defined, it is expected
+   that these will use reserved dispatch values following LOWPAN_HC1.
+   If additional mesh delivery formats are defined these will use
+   reserved values following LOWPAN_BC0.
+
+   This document creates a new IANA registry for the 16-bit short
+   address fields as used in 6LoWPAN packets.
+
+                       0                   1
+                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                      |     16-bit short Address      |
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                                 Figure 12
+
+   This registry MUST include the addresses 0xffff (16-bit broadcast
+   address accepted by all devices currently listening to the channel)
+   and 0xfffe as defined in [ieee802.15.4].  Additionally, within
+   6LoWPAN networks, 16-bit short addresses MUST follow this format
+   (referring to bit fields in the order from 0 to 7), where "x" is a
+   place holder for an unspecified bit value:
+
+   Range 1, 0xxxxxxxxxxxxxxx:  The first bit (bit 0) SHALL be zero if
+      the 16-bit address is a unicast address.  This leaves 15 bits for
+      the actual address.
+
+   Range 2, 100xxxxxxxxxxxxx:  Bits 0, 1, and 2 SHALL follow this
+      pattern if the 16-bit address is a multicast address (see
+      Section 9).  This leaves 13 bits for the actual multicast address.
+
+   Range 3, 101xxxxxxxxxxxxx:  This pattern for bits 0, 1, and 2 is
+      reserved.  Any future assignment shall follow the policy mentioned
+      above.
+
+   Range 4, 110xxxxxxxxxxxxx:  This pattern for bits 0, 1, and 2 is
+      reserved.  Any future assignment shall follow the policy mentioned
+      above.
+
+   Range 5, 111xxxxxxxxxxxxx:  This pattern for bits 0, 1, and 2 is
+      reserved.  Any future assignment shall follow the policy mentioned
+      above.
+
+
+
+
+
+
+
+
+Montenegro, et al.          Standards Track                    [Page 24]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+13.  Security Considerations
+
+   The method of derivation of Interface Identifiers from EUI-64 MAC
+   addresses is intended to preserve global uniqueness when possible.
+   However, there is no protection from duplication through accident or
+   forgery.
+
+   Neighbor Discovery in IEEE 802.15.4 links may be susceptible to
+   threats as detailed in [RFC3756].  Mesh routing is expected to be
+   common in IEEE 802.15.4 networks.  This implies additional threats
+   due to ad hoc routing as per [KW03].  IEEE 802.15.4 provides some
+   capability for link-layer security.  Users are urged to make use of
+   such provisions if at all possible and practical.  Doing so will
+   alleviate the threats stated above.
+
+   A sizeable portion of IEEE 802.15.4 devices is expected to always
+   communicate within their PAN (i.e., within their link, in IPv6
+   terms).  In response to cost and power consumption considerations,
+   and in keeping with the IEEE 802.15.4 model of "Reduced Function
+   Devices" (RFDs), these devices will typically implement the minimum
+   set of features necessary.  Accordingly, security for such devices
+   may rely quite strongly on the mechanisms defined at the link layer
+   by IEEE 802.15.4.  The latter, however, only defines the Advanced
+   Encryption Standard (AES) modes for authentication or encryption of
+   IEEE 802.15.4 frames, and does not, in particular, specify key
+   management (presumably group oriented).  Other issues to address in
+   real deployments relate to secure configuration and management.
+   Whereas such a complete picture is out of the scope of this document,
+   it is imperative that IEEE 802.15.4 networks be deployed with such
+   considerations in mind.  Of course, it is also expected that some
+   IEEE 802.15.4 devices (the so-called "Full Function Devices", or
+   "FFDs") will implement coordination or integration functions.  These
+   may communicate regularly with off-link IPv6 peers (in addition to
+   the more common on-link exchanges).  Such IPv6 devices are expected
+   to secure their end-to-end communications with the usual mechanisms
+   (e.g., IPsec, TLS, etc).
+
+14.  Acknowledgements
+
+   Thanks to the authors of RFC 2464 and RFC 2734, as parts of this
+   document are patterned after theirs.  Thanks to Geoff Mulligan for
+   useful discussions which helped shape this document.  Erik Nordmark's
+   suggestions were instrumental for the header compression section.
+   Also thanks to Shoichi Sakane, Samita Chakrabarti, Vipul Gupta,
+   Carsten Bormann, Ki-Hyung Kim, Mario Mao, Phil Levis, Magnus
+   Westerlund, and Jari Arkko.
+
+
+
+
+
+Montenegro, et al.          Standards Track                    [Page 25]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+15.  References
+
+15.1.  Normative References
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]       Narten, T. and H. Alvestrand, "Guidelines for Writing
+                   an IANA Considerations Section in RFCs", BCP 26,
+                   RFC 2434, October 1998.
+
+   [RFC2460]       Deering, S. and R. Hinden, "Internet Protocol,
+                   Version 6 (IPv6) Specification", RFC 2460,
+                   December 1998.
+
+   [RFC2464]       Crawford, M., "Transmission of IPv6 Packets over
+                   Ethernet Networks", RFC 2464, December 1998.
+
+   [RFC4291]       Hinden, R. and S. Deering, "IP Version 6 Addressing
+                   Architecture", RFC 4291, February 2006.
+
+   [RFC4861]       Narten, T., Nordmark, E., Simpson, W., and H.
+                   Soliman, "Neighbor Discovery for IP version 6
+                   (IPv6)", RFC 4861, September 2007.
+
+   [RFC4862]       Thomson, S., Narten, T., and T. Jinmei, "IPv6
+                   Stateless Address Autoconfiguration", RFC 4862,
+                   September 2007.
+
+   [ieee802.15.4]  IEEE Computer Society, "IEEE Std. 802.15.4-2003",
+                   October 2003.
+
+15.2.  Informative References
+
+   [EUI64]         "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
+                   REGISTRATION AUTHORITY", IEEE http://
+                   standards.ieee.org/regauth/oui/tutorials/EUI64.html.
+
+   [KW03]          Karlof, Chris and Wagner, David, "Secure Routing in
+                   Sensor Networks: Attacks and Countermeasures",
+                   Elsevier's AdHoc Networks Journal, Special Issue on
+                   Sensor Network Applications and Protocols vol 1,
+                   issues 2-3, September 2003.
+
+   [RFC0768]       Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+                   August 1980.
+
+
+
+
+
+Montenegro, et al.          Standards Track                    [Page 26]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+   [RFC3756]       Nikander, P., Kempf, J., and E. Nordmark, "IPv6
+                   Neighbor Discovery (ND) Trust Models and Threats",
+                   RFC 3756, May 2004.
+
+   [RFC3819]       Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
+                   Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
+                   and L. Wood, "Advice for Internet Subnetwork
+                   Designers", BCP 89, RFC 3819, July 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Montenegro, et al.          Standards Track                    [Page 27]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+Appendix A.  Alternatives for Delivery of Frames in a Mesh
+
+   Before settling on the mechanism finally adopted for delivery in a
+   mesh (Section 11), several alternatives were considered.  In addition
+   to the hop-by-hop source and destination link-layer addresses,
+   delivering a packet in a LoWPAN mesh requires the end-to-end
+   originator and destination addresses.  These could be expressed
+   either as layer 2 or as layer 3 (i.e., IP ) addresses.  In the latter
+   case, there would be no need to provide any additional header support
+   in this document (i.e., within the LoWPAN header itself).  The link-
+   layer destination address would point to the next hop destination
+   address while the IP header destination address would point to the
+   final destination (IP) address (possibly multiple hops away from the
+   source), and similarly for the source addresses.  Thus, while
+   forwarding data, the single-hop source and destination addresses
+   would change at each hop (always pointing to the node doing the
+   forwarding and the "best" next link-layer hop, respectively), while
+   the source and destination IP addresses would remain unchanged.
+   Notice that if an IP packet is fragmented, the individual fragments
+   may arrive at any node out of order.  If the initial fragment (which
+   contains the IP header) is delayed for some reason, a node that
+   receives a subsequent fragment would lack the required information.
+   It would be forced to wait until it receives the IP header (within
+   the first fragment) before being able to forward the fragment any
+   further.  This imposes some additional buffering requirements on
+   intermediate nodes.  Additionally, such a specification would only
+   work for one type of LoWPAN payload: IPv6.  In general, it would have
+   to be adapted for any other payload, and would require that payload
+   to provide its own end-to-end addressing information.
+
+   On the other hand, the approach finally followed (Section 11) creates
+   a mesh at the LoWPAN layer (below layer 3).  Accordingly, the link-
+   layer originator and final destination address are included within
+   the LoWPAN header.  This enables mesh delivery for any protocol or
+   application layered on the LoWPAN adaptation layer (Section 5).  For
+   IPv6 as supported in this document, another advantage of expressing
+   the originator and final destinations as layer 2 addresses is that
+   the IPv6 addresses can be compressed as per the header compression
+   specified in Section 10.  Furthermore, the number of octets needed to
+   maintain routing tables is reduced due to the smaller size of
+   802.15.4 addresses (either 64 bits or 16 bits) as compared to IPv6
+   addresses (128 bits).  A disadvantage is that applications on top of
+   IP do not address packets to link-layer destination addresses, but to
+   IP (layer 3) destination addresses.  Thus, given an IP address, there
+   is a need to resolve the corresponding link-layer address.
+   Accordingly, a mesh routing specification needs to clarify the
+   Neighbor Discovery implications, although in some special cases, it
+   may be possible to derive a device's address at layer 2 from its
+
+
+
+Montenegro, et al.          Standards Track                    [Page 28]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 2007
+
+
+   address at layer 3 (and vice versa).  Such complete specification is
+   outside the scope of this document.
+
+Authors' Addresses
+
+   Gabriel Montenegro
+   Microsoft Corporation
+
+   EMail: gabriel.montenegro@microsoft.com
+
+
+   Nandakishore Kushalnagar
+   Intel Corp
+
+   EMail: nandakishore.kushalnagar@intel.com
+
+
+   Jonathan W. Hui
+   Arch Rock Corp
+
+   EMail: jhui@archrock.com
+
+
+   David E. Culler
+   Arch Rock Corp
+
+   EMail: dculler@archrock.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Montenegro, et al.          Standards Track                    [Page 29]
+
+RFC 4944                IPv6 over IEEE 802.15.4           September 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Montenegro, et al.          Standards Track                    [Page 30]
+