RFC 4944

Transmission of IPv6 Packets over IEEE 802.15.4 Networks

📅 published September 2007, from ietf

RFC 4944: Transmission of IPv6 Packets over IEEE 802.15.4 Networks 🦋

Okay bestie, let's get into it. This is RFC 4944 from September 2007, a Standards Track document from the Network Working Group 💖. The authors are G. Montenegro (Microsoft Corporation), N. Kushalnagar (Intel Corp), J. Hui, and D. Culler (Arch Rock Corp) 🫶. The title block doesn't list anything it obsoletes or updates, so there's no drama there ✨.

Status of This Memo 🎀

This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸.

Abstract ✨

So the vibe is this: the doc describes the frame format for sending IPv6 packets over IEEE 802.15.4 networks 🧚. It also covers how to form IPv6 link-local addresses and statelessly autoconfigured addresses on those networks. Extra stuff includes a simple header compression scheme that uses shared context, plus provisions for packet delivery in IEEE 802.15.4 meshes 💜.

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] is all about low-power personal area networks 🔋. This document defines the frame format for sending IPv6 [RFC2460] packets, and it covers forming IPv6 link-local addresses and statelessly autoconfigured addresses on top of IEEE 802.15.4 networks. IPv6 needs support for packet sizes way bigger than the largest IEEE 802.15.4 frame, so an adaptation layer gets defined to bridge that gap 😭. The doc also defines the header compression mechanisms that make IPv6 practical on IEEE 802.15.4 networks, plus the provisions needed for packet delivery in IEEE 802.15.4 meshes. The one thing it doesn't cover is a full spec for mesh routing (which protocol you use, how it interacts with neighbor discovery, and so on). That's out of scope here 🙈.

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, no exceptions bestie 🚫. Data frames may optionally ask to be acknowledged. Following [RFC3819], it is recommended that IPv6 packets ride in frames where acknowledgements are requested, so link-layer recovery gets some help 🛟.

IEEE 802.15.4 networks can be either nonbeacon-enabled or beacon-enabled [ieee802.15.4]. Beacon-enabled is the optional mode where devices sync up using the coordinator's beacons. That's what lets you use superframes, and inside those a contention-free Guaranteed Time Service (GTS) becomes possible ⭐. This document does not require that IEEE networks run in beacon-enabled mode. In nonbeacon-enabled networks, data frames (including the ones carrying IPv6 packets) get sent using the contention-based channel access method of unslotted CSMA/CA.

In nonbeacon-enabled networks, beacons aren't used for synchronization. They're still useful for link-layer device discovery, though, which helps with association and disassociation events 🦋. This document recommends that beacons be configured so they help with those functions. There's also a further recommendation that these events be available at the IPv6 layer, so detecting network attachment gets easier. That's a problem the IETF was working on when this was written 🔍.

The specification allows frames where 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 has several addressing modes. It lets you use either IEEE 64-bit extended addresses, or (after an association event) 16-bit addresses that are 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 adds extra constraints (on top of the ones from IEEE 802.15.4) on the format of the 16-bit short addresses, as specified in Section 12 📐.

Short addresses are kind of temporary, so here's a word of caution. They get doled out by the PAN coordinator function during an association event, which means their validity and uniqueness only last as long as that association does 😬. The association can be cut short by it expiring, or simply by any mishap happening to the PAN coordinator. Because this kind of centralized allocation creates scalability issues and a single point of failure at the PAN coordinator, deployers should carefully weigh the tradeoffs (and implement the necessary mechanisms) before growing networks based on short addresses 🧐. Of course, IEEE 64-bit extended addresses may not have these drawbacks, but they still share the remaining scalability issues around routing, discovery, configuration, and so on.

This document assumes that a PAN maps to a specific IPv6 link. That matches the recommendation that shared networks support link-layer subnet [RFC3819] broadcast 🔗. Strictly speaking, IPv6 has multicast and not broadcast. But multicast isn't supported natively in IEEE 802.15.4, so IPv6 level multicast packets MUST be carried as link-layer broadcast frames in IEEE 802.15.4 networks 📡. That MUST be done in a way where the broadcast frames only get 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).

Also, support for mapping IPv6 multicast addresses per Section 9 MUST only be used in a mesh configuration. A full spec for that functionality is out of scope for 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. Okay but here's the plot twist: a full IPv6 packet does not fit in an IEEE 802.15.4 frame 😭. IEEE 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 maximum frame size at the media access control layer comes out to 102 octets. Link-layer security adds more overhead. 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), that leaves only 81 octets available 💀. This is obviously way below the minimum IPv6 packet size of 1280 octets. So, in keeping with Section 5 of the IPv6 specification [RFC2460], a fragmentation and reassembly adaptation layer must be provided at the layer below IP. Such a layer is defined below in Section 5 🧩.

Also, since the IPv6 header is 40 octets long, that leaves only 41 octets for upper-layer protocols like UDP. UDP uses 8 octets in its header, which leaves only 33 octets for application data 🫠. On top of that, as pointed out above, there's a need for a fragmentation and reassembly layer, and that uses 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 combined with proper header compression will produce packets that fit within a single IEEE 802.15.4 frame 🌟. The justification for this adaptation layer isn't just IPv6 compliance. Packet sizes produced by certain application exchanges (for example, configuration or provisioning) may quite likely require a small number of fragments 📦.
  2. Even though the space calculation above shows the worst-case scenario, it proves that header compression is compelling to the point of being almost unavoidable 🤏. Since we 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 ✨

okay bestie, this section is where the LoWPAN magic happens 🧚. The encapsulation formats here (we'll call them the "LoWPAN encapsulation" 💅) are the payload inside an IEEE 802.15.4 MAC protocol data unit (PDU). Your LoWPAN payload, like an IPv6 packet, sits right after this encapsulation header.

Every LoWPAN datagram sent over IEEE 802.15.4 gets a little encapsulation header stack in front of it 🎀. Each header in that stack has a header type, then zero or more header fields. In an IPv6 header the stack goes addressing, hop-by-hop options, routing, fragmentation, destination options, then payload [RFC2460]. In a LoWPAN header the vibe is different: mesh (L2) addressing, then hop-by-hop options (including L2 broadcast/multicast), then fragmentation, then payload. Here are some typical stacks you might see 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 |
+-----------+-------------+--------------+------------+---------+

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 shows up in the same packet, they MUST appear in this order 👑:

  1. Mesh Addressing Header
  2. Broadcast Header
  3. Fragmentation Header

All protocol datagrams (IPv6, compressed IPv6 headers, and so on) SHALL be preceded by one of the valid LoWPAN encapsulation headers, like the examples above 💖. That's what makes software treat every datagram the same way, no matter how it was sent 🫶.

The definition of a LoWPAN header, other than mesh addressing and fragmentation, is made of three things: the dispatch value, the header fields that follow it, and where it's allowed to sit in the stack compared to all the other headers. The header stack gives the adaptation layer room to handle future needs, but it's not meant to be general-purpose extensibility 🙈. This format document only defines a small set of header types, using the stack for clarity, compactness, and orthogonality ✨.

5.1. Dispatch Type and Header

The dispatch type is marked by a zero bit as the first bit and a one bit as the second bit 🌸. Here's what the dispatch type and header look like:

                    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 is a 6-bit selector that tells you what kind of header comes right after the Dispatch Header. The type-specific header is whatever the Dispatch Header says it is. (See Figure 1 for the layout.)

The dispatch value can be treated as an unstructured namespace 🎀. Only a few symbols are required to represent the current LoWPAN functionality. You could squeeze extra savings out of the dispatch byte by packing more functionality into it, but that would make it harder to add future alternatives 😭, so it's a no from the authors.

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

That table is the full dispatch value bit pattern (Figure 2), so here's what each header type means 🦋:

  • NALP: this says the bits that follow are not part of the LoWPAN encapsulation. Any LoWPAN node that runs into a dispatch value of 00xxxxxx shall discard the packet. Other non-LoWPAN protocols that want to live alongside LoWPAN nodes should put a byte matching this pattern right after the 802.15.4 header.
  • IPv6: the following header is an uncompressed IPv6 header [RFC2460].
  • LOWPAN_HC1: the following header is a LOWPAN_HC1 compressed IPv6 header. The format for this header is defined in Figure 9.
  • LOWPAN_BC0: the following header is a LOWPAN_BC0 header, used for mesh broadcast/multicast support. It's described in Section 11.1.
  • ESC: the following header is a single 8-bit field for the Dispatch value. It lets you use Dispatch values bigger than 127 🌈.

5.2. Mesh Addressing Type and Header

The mesh type is marked by a one bit and then a zero bit as its first two bits 🍓. Here's the layout:

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

Now let's go field by field 💅:

  • V: this 1-bit field SHALL be zero if the Originator (or "Very first") Address is an IEEE extended 64-bit address (EUI-64). It's 1 if the address is a short 16-bit address.
  • F: this 1-bit field SHALL be zero if the Final Destination Address is an IEEE extended 64-bit address (EUI-64). It's 1 if the address is a short 16-bit address.
  • Hops Left: this 4-bit field SHALL be decremented by each forwarding node before it sends the packet toward its next hop. If Hops Left gets decremented to zero, the packet isn't forwarded any further. The value 0xF is reserved and means an 8-bit Deep Hops Left field comes right after it, which lets a source node set a hop limit bigger 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.

Quick bestie note 🫶: the V and F bits let you mix 16-bit and 64-bit addresses in the same packet. That's useful, at least for mesh layer "broadcast", because 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. Stay tuned for that one 👀💜

5.3. Fragmentation Type and Header ✨

okay so if the whole payload datagram (like IPv6) fits in one 802.15.4 frame, it's unfragmented and the LoWPAN encapsulation should not contain a fragmentation header. no chopping needed 💅

but if it doesn't fit, it SHALL be broken into link fragments 🧩 the fragment offset can only count in multiples of eight bytes, so every link fragment for a datagram except the last one MUST be a multiple of eight bytes long 🎀 and the first link fragment SHALL carry the first fragment header, 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 0 0 0|    datagram_size    |         datagram_tag          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 4: First Fragment

the second and subsequent link fragments (up to and including the last) SHALL have a fragmentation header in this format 🦋

                        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

let's break down each field 🌸

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. the packet may already be fragmented by hosts in the conversation, so 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 doesn't have to be in every packet, since you could send it with the first fragment and leave it out after that. but including it in every link fragment makes reassembly way easier if a second (or later) link fragment shows up before the first. then the very first fragment you see tells you how much buffer space to set aside while you wait for the rest 🧠 the format above trades simplicity for efficiency, which is very on-brand for it 💅

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 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 only present in the second and subsequent link fragments, and it 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, and the implicit value of datagram_offset in the first link fragment is zero. this field is 8 bits long 🧚

now for reassembly, which is giving puzzle energy 🧩✨ 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 🔥

when a link fragment comes in, the recipient starts building the original unfragmented packet, whose size is datagram_size. it uses datagram_offset to figure out where each fragment goes inside that packet. for example, it might drop the data payload (except the encapsulation header) into a payload datagram reassembly buffer at the spot datagram_offset points to. the size of the reassembly buffer SHALL be determined from datagram_size 👑

if a link fragment overlaps another fragment (as identified above) and differs in either the size or datagram_offset of the overlapped fragment, then the fragment(s) already piled up in the reassembly buffer SHALL be discarded. a fresh reassembly may be commenced with the most recently received link 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 💀

and the timeouts are where it gets dramatic 😭 upon detection of an IEEE 802.15.4 Disassociation event, fragment recipients MUST discard all link fragments of all partially 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 is all about getting 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 that case, the Interface Identifier is formed from the EUI-64 according to the "IPv6 over Ethernet" specification [RFC2464] 🎀

every 802.15.4 device has an IEEE EUI-64 address, but 16-bit short addresses (Section 3 and Section 12) are also possible. when you're using those, a "pseudo 48-bit address" gets built like this 🧚 first, the left-most 32 bits come from 16 zero bits concatenated with the 16-bit PAN ID (or, if no PAN ID is known, 16 zero bits may be used instead). that gives you a 32-bit field that looks like this:

   16_bit_PAN:16_zero_bits

then those 32 bits get concatenated with the 16-bit short address, which makes a 48-bit address that looks like this:

   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]. BUT in the resulting interface identifier, the "Universal/Local" (U/L) bit SHALL be set to zero, because this value is not globally unique, so it would be lying otherwise 🙈 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 you do that, its global uniqueness should be reflected in the value of the U/L bit 💜

one more rule: an IPv6 address prefix used for stateless autoconfiguration [RFC4862] of an IEEE 802.15.4 interface MUST have a length of 64 bits 🌈

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 🌙 here's how the bits line up:

       10 bits            54 bits                  64 bits
    +----------+-----------------------+----------------------------+
    |1111111010|         (zeros)       |    Interface Identifier    |
    +----------+-----------------------+----------------------------+

                              Figure 6

8. Unicast Address Mapping

okay this one is about mapping IPv6 non-multicast addresses to IEEE 802.15.4 link-layer addresses 🗺️ the address resolution procedure follows the general description in Section 7.2 of [RFC4861], unless otherwise specified. the Source/Target Link-layer Address option has these forms when the link layer is IEEE 802.15.4 and the addresses are EUI-64 or 16-bit short addresses, respectively 💅

the EUI-64 version looks like this:

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

and the 16-bit short address version looks like this:

                    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

the option fields work like this 🌷

  • 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 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 bit order. this is the address the interface currently responds to. it 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 🦋

okay bestie, this bit only applies in a mesh-enabled LoWPAN 🕸️ The functionality in this section MUST only be used in a mesh-enabled LoWPAN. An IPv6 packet with a multicast destination address (DST), which is sixteen octets long (DST[1] through DST[16]), gets sent to this 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

so DST[15]* just means the last 5 bits of DST[15], which is bits 3-7 inside that octet 💅 The starting 100 pattern follows the 16-bit address format for multicast addresses (Section 12), so it's all lined up.

this lets 6LoWPAN networks do multicast, but the full spec for how that works is out of scope for this document 🙈 Some example mechanisms are flooding, controlled flooding, unicasting to the PAN coordinator, etc. It's expected that the different mesh routing mechanisms will be the ones to define it.

10. Header Compression 💖

there's already a lot of published and in-progress standards work on header compression ✨ but header compression for IPv6 over IEEE 802.15.4 has its own constraints, and they go like this:

  • Existing work assumes there are lots of flows between any two devices. This one is a super simple, low-context flavor of header compression. It works no matter how many flows (potentially several) there are, but it doesn't use any context specific to any one flow. So it can't compress as much as schemes that build a separate context for each flow being compressed 😭
  • Packets are super small, so it's really desirable to integrate layer 2 with layer 3 compression, which isn't traditionally done (although that's changing thanks to the ROHC (RObust Header Compression) working group) 🔥
  • IEEE 802.15.4 devices are expected to end up in multi-hop networks. Header compression in a mesh is a whole different vibe from the usual point-to-point link, where the compressor and decompressor only talk to each other directly and exclusively. In an IEEE 802.15.4 network, it's highly desirable for a device to send header compressed packets through any of its neighbors, with as little preliminary context-building as possible 🦋

any new packet formats needed for header compression reuse the basic packet formats from Section 5 by using different dispatch values 🎀

header compression might leave the alignment off an octet boundary 💀 Since hardware typically can't transmit anything smaller than an octet, padding has to be used. Here's how padding works: first, the whole series of contiguous compressed headers gets 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 needed to align to an octet boundary. This fixes any misalignment that header compression caused, so later fields (like non-compressed headers or data payloads) start on an octet boundary and carry on as usual ✨

10.1. Encoding of IPv6 Header Fields

bestie, once devices have joined the same 6LoWPAN network, they share some state 🫶 That means headers can be compressed without explicitly building any compression context state. So 6LoWPAN header compression doesn't keep any flow state. It relies on information about the entire link instead.

The IPv6 header values expected to be common on 6LoWPAN networks are the reason the HC1 header exists, so it can compress them right off the bat 👑 Here's the common case:

  • Version is IPv6.
  • Both the 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 only works for interface identifiers derived from an underlying 802.15.4 MAC address.
  • The packet length can be inferred either from layer two (the "Frame Length" in the IEEE 802.15.4 PPDU) or from the "datagram_size" field in the fragment header, if that's present.
  • Both the Traffic Class and the Flow Label are zero.
  • The Next Header is UDP, ICMP or TCP.

The only field in the IPv6 header that always has to be carried in full is the Hop Limit (8 bits) 🧚 Depending on how closely a packet matches this common case, other fields might not be compressible, so they'd need to be carried "in-line" as well (Section 10.3.1). This common IPv6 header can be compressed to 2 octets (1 octet for the HC1 encoding and 1 octet for the Hop Limit) instead of 40 octets 🌈 A packet like that is compressible via the LOWPAN_HC1 format: use a Dispatch value of LOWPAN_HC1, followed by a LOWPAN_HC1 header "HC1 encoding" field (8 bits) that encodes the different combinations, shown below. This header may be preceded by a fragmentation header, which may itself 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 you can see (bit 7), an HC2 encoding may follow an HC1 octet 👀 When that happens, the non-compressed fields come after the HC2 encoding field (Section 10.3).

The address fields encoded by "HC1 encoding" work like this:

  • 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 this is 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 the one found in the "Mesh Addressing" field (Section 5.2).

The "HC1 encoding" is laid out 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
  • 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 LOWPAN_HC1 let you compress the Next Header field in the IPv6 header (for UDP, TCP, and ICMP) 💜 You can compress each of those protocol headers even further, and this section explains how the UDP header itself gets compressed. The HC2 encoding here is the HC_UDP encoding, and it only applies if bits 5 and 6 in HC1 say the protocol after the IPv6 header is UDP. HC_UDP (Figure 10) lets you compress these UDP header fields: source port, destination port, and length. The checksum field isn't compressed, so it's always carried in full. With this scheme, the UDP header shrinks to 4 octets instead of the original 8 octets 🍓

The only UDP header field whose value can be figured out from information available elsewhere is the Length. The other fields have to be carried in-line, either in full or partially compressed (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 laid out 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 equals 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)

10.3. Non-Compressed Fields 🧁

10.3.1. Non-Compressed IPv6 Fields

this scheme lets the IPv6 header be compressed to different degrees ✨ So instead of the whole standard IPv6 header, you only send the non-compressed fields. The subsequent header (whatever the Next Header field in the original IPv6 header says) comes right after the non-compressed IPv6 fields.

Uncompressed IPv6 addressing is described by a dispatch type that contains 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 always be present is the Hop Limit (8 bits) 💅 This field MUST always follow the encoding fields (for example, the "HC1 encoding" shown in Figure 9), perhaps along with other future encoding fields. Other non-compressed fields MUST follow the Hop Limit, as implied by the "HC1 encoding", in the exact same order 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 ✨

Okay so this scheme lets the UDP header get squished down to different degrees 💅. That means you don't have to send the whole standard UDP header. You only send the fields that are non-compressed or partially compressed 🧚.

The non-compressed or partially compressed UDP fields MUST always come right after the IPv6 header and any of its in-line fields 💖. Any UDP in-line fields that are present MUST show up in the same order they'd have in a normal UDP header [RFC0768], so source port, destination port, length, and checksum 🎀. If the source or destination port is in "short_port" notation (the compressed UDP header tells you which), that port number takes 4 bits instead of 16 🌸.

Even though 802.15.4 networks are expected to commonly use mesh routing, the IEEE 802.15.4-2003 specification [ieee802.15.4] doesn't define that capability at all 🙈. So Full Function Devices (FFDs) run an ad hoc or mesh routing protocol to fill up their routing tables. That protocol is outside the scope of this document, so don't worry about it here 🫶.

In mesh scenarios, two devices don't need direct reachability to talk to each other 🦋. The sender is called the "Originator" and the receiver is called the "Final Destination". The Originator can use other intermediate devices as forwarders on the way to the Final Destination. To get unicast frame delivery working, you need the link-layer addresses of the Originator and the Final Destination, on top of the hop-by-hop source and destination 🧠.

This section explains how to deliver layer 2 frames in a mesh when you're given a target "Final Destination" link-layer address 💜.

Mesh delivery gets turned on by putting a Mesh Addressing header before any other headers in the LoWPAN encapsulation (Section 5) ✨. That includes an unfragmented or fragmented header, a full-blown IPv6 header, or a compressed IPv6 header as per Section 10, or any others defined elsewhere 🎀.

Say a node wants to use a default mesh forwarder to deliver a packet, because it doesn't have direct reachability to the destination 🍓. It MUST include a Mesh Addressing header where the originator's link-layer address is its own and the final destination's link-layer address is 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 💅. Then it transmits the packet 🚀.

Now flip it. If a node gets a frame with a Mesh Addressing header, it must look at the "Final Destination" field to figure out the real destination 👀. If the node is the final destination, it consumes the packet like normal delivery 🥰. If it isn't, the node reduces the "Hops Left" field, and if the result is zero, it discards the packet 💀. Otherwise, it checks its link-layer routing table, figures out the next hop toward the final destination, and puts that address in the destination address field of the 802.15.4 header 🧚. Last step: it changes the source address in the 802.15.4 header to its own link-layer address and transmits the packet 🌈.

Being a forwarder means a node must participate in a mesh routing protocol, but simply using mesh forwarding doesn't require that 🙌. Only Full Function Devices (FFDs) are expected to participate as routers in a mesh 👑. Reduced Function Devices (RFDs) just find FFDs and send all their forwarding through them, kinda like how IP hosts use default routers for all their off-link traffic 🫶. For an RFD using mesh delivery, the "forwarder" is always the appropriate FFD 💖.

11.1. LoWPAN Broadcast 📢

Extra mesh routing functionality is encoded with a routing header that comes right after the Mesh header 🎀. Specifically, a broadcast header is a LOWPAN_BC0 dispatch followed by a sequence number field 🌸. The sequence number is there 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

Here's what the fields mean 🍓:

  • Sequence Number: This 8-bit field SHALL be incremented by the originator whenever it sends a new mesh broadcast or multicast packet. How to fully handle this field is out of the scope of this document 🙃.

Whether mesh-layer broadcast maps to a controlled flooding mechanism, or what its role is in something like topology discovery, is also out of the scope of this document 🫠.

Extra mesh routing capabilities, like specifying the mesh routing protocol, source routing, and so on, can be expressed by defining more routing headers that come before the fragmentation or addressing header in the header stack 🧩. The full specification of those mesh routing capabilities is out of the scope of this document too ✨.

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's expected that this policy will make it easier for other (non-IETF) organizations to get assignments too 🌈.

This document creates a new IANA registry for the Dispatch type field shown in the header definitions in Section 5 🎀. It 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 field is defined to be 8 bits long 💖. The values 00xxxxxx are reserved and not used, which gives a total of 192 different values, and honestly that should be more than enough 💅. If header compression formats beyond HC1 get defined, or if additional TCP or ICMP HC2 formats get defined, those are expected to use reserved dispatch values following LOWPAN_HC1 🌸. If additional mesh delivery formats get defined, they'll use reserved values following LOWPAN_BC0 🦋.

This document also creates a new IANA registry for the 16-bit short address fields 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 (the 16-bit broadcast address accepted by all devices currently listening to the channel) and 0xfffe, as defined in [ieee802.15.4] 📡. On top of that, inside 6LoWPAN networks, 16-bit short addresses MUST follow this format 🔢. Bit fields are referred to in order from 0 to 7, and "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 💖. That 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) 📢. That 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 📋.

13. Security Considerations 🔐

Okay, security time, bestie 🥺. The way Interface Identifiers are derived from EUI-64 MAC addresses is meant to keep them globally unique when possible ✨. But there's no protection from duplication through accident or forgery 💀.

Neighbor Discovery on IEEE 802.15.4 links may be susceptible to the threats detailed in [RFC3756] 😬. Mesh routing is expected to be common in IEEE 802.15.4 networks, and that brings extra threats because of ad hoc routing, as per [KW03] 🕸️. IEEE 802.15.4 gives you some capability for link-layer security 🔒. Users are strongly urged to use those provisions if at all possible and practical 🫶. Doing so will ease the threats stated above 💖.

A big chunk of IEEE 802.15.4 devices are expected to always communicate within their PAN (which means within their link, in IPv6 terms) 🏠. Because of cost and power consumption concerns, and since IEEE 802.15.4 models "Reduced Function Devices" (RFDs), these devices will typically implement the minimum set of features they need 🔋. So their security may lean pretty hard on the mechanisms IEEE 802.15.4 defines at the link layer 🛡️. But that only defines the Advanced Encryption Standard (AES) modes for authenticating or encrypting IEEE 802.15.4 frames 🔑. It doesn't specify key management in particular, which is presumably group oriented 🤷‍♀️. Other issues to sort out in real deployments involve secure configuration and management ⚙️. A complete picture of that is out of the scope of this document, but it is imperative that IEEE 802.15.4 networks get deployed with those considerations in mind 🚨.

Of course, some IEEE 802.15.4 devices (the so-called "Full Function Devices", or "FFDs") are expected to implement coordination or integration functions 🧠. These may regularly talk to off-link IPv6 peers, on top of the more common on-link exchanges 🌐. Such IPv6 devices are expected to secure their end-to-end communications with the usual mechanisms, like IPsec, TLS, etc 🔐💜.

14. Acknowledgements 🫶

Thanks to the authors of RFC 2464 and RFC 2734, since parts of this document are patterned after theirs 💖. Thanks to Geoff Mulligan for useful discussions that 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 🎀✨.

15. References 📚

15.1. Normative References ✨

okay so these are the receipts 🧾 the stuff this doc needs you to have read first. the list is alphabetical by tag, and the tags are how the text points back to them:

  • [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 🌸

these ones are the extra reading. helpful, not mandatory, but honestly worth a look 👀

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

Appendix A. Alternatives for Delivery of Frames in a Mesh 🧚

okay so before we settled on the mesh delivery method we actually went with (that's Section 11 🦋), the team looked at a bunch of other options. delivering a packet across a LoWPAN mesh needs the hop-by-hop source and destination link-layer addresses, PLUS the end-to-end originator and destination addresses. those end-to-end addresses could be written as layer 2 addresses or as layer 3 (i.e., IP) addresses. if they're layer 3, this document wouldn't need any extra header support inside the LoWPAN header itself. the link-layer destination points at the next hop, while the IP header destination points at the final destination (which could be several hops away from the source), and the source addresses work the same way. so while forwarding, the single-hop source and destination addresses change at every hop (always pointing at the node doing the forwarding and the "best" next link-layer hop, respectively), but the source and destination IP addresses stay the same. ✨

now for the fragmentation tea ☕ fragments can show up at any node out of order. if the initial fragment (the one carrying the IP header) gets delayed for some reason, a node that receives a later fragment doesn't have the info it needs. it has to wait for the IP header inside that first fragment before it can forward the fragment any further. that means intermediate nodes need some extra buffering, which is a whole vibe 😭 and honestly, this approach would only work for one type of LoWPAN payload: IPv6. for anything else, it'd have to be adapted, and that payload would need to bring its own end-to-end addressing information.

the approach we actually followed (Section 11) creates a mesh at the LoWPAN layer, which is below layer 3. so the link-layer originator and final destination addresses get included within the LoWPAN header 💖 this means mesh delivery works for any protocol or application layered on the LoWPAN adaptation layer (Section 5). for IPv6 as supported in this document, another perk of expressing the originator and final destinations as layer 2 addresses is that the IPv6 addresses can be compressed using the header compression in Section 10. plus, the number of octets needed to keep routing tables is smaller, since 802.15.4 addresses (either 64 bits or 16 bits) are tinier than IPv6 addresses (128 bits) 🍓

the downside? apps on top of IP don't address packets to link-layer destination addresses, they address them to IP (layer 3) destination addresses. so given an IP address, you need to resolve the matching link-layer address. that means a mesh routing spec has to clarify the Neighbor Discovery implications 🙈 although in some special cases, you may be able to derive a device's address at layer 2 from its address at layer 3 (and vice versa). the complete specification for all that is outside the scope of this document.

Authors' Addresses 🎀

meet the squad 🫶

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

okay now the legal stuff. i'm keeping this word-for-word because it's giving serious lawyer energy and we don't mess with that 😭

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 on 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 on the extent to which any license under such rights might or might not be available. it also doesn't say it has made any independent effort to identify any such rights. info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use those proprietary rights 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 required to implement this standard. please send that info to the IETF at ietf-ipr@ietf.org 💜

📦 where this page comes from