RFC 6282

Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks

📅 published September 2011, from ietf

RFC 6282: Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks ✨

okay bestie, this is the one 🎀 RFC 6282 from the IETF, a Standards Track doc from September 2011 (ISSN 2070-1721). Its authors are J. Hui, Ed. from Arch Rock Corporation and P. Thubert from Cisco. It updates RFC 4944, so it's basically a glow-up for the old 6LoWPAN header compression 💅

Abstract

okay so the abstract is giving "here's the whole vibe" 🦋 This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". It specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs) 🌸 The compression format relies on shared context so it can compress arbitrary prefixes. How that shared context gets maintained is out of scope, so don't come for this doc about it 🙅‍♀️ It also specifies compression of multicast addresses and a framework for compressing next headers, and UDP header compression is specified within that framework 💖

Status of This Memo

ngl this section is the paperwork, but it matters 📝 This is an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ For more on Internet Standards, check Section 2 of RFC 5741. For the current status, errata, and where to send feedback, go to http://www.rfc-editor.org/info/rfc6282 🧚

the legal bit, bestie 💅 Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this document 👀 Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶

Table of Contents

   1. Introduction ....................................................3
      1.1. Requirements Language ......................................4
   2. Specific Updates to RFC 4944 ....................................4
   3. IPv6 Header Compression .........................................5
      3.1. LOWPAN_IPHC Encoding Format ................................6
           3.1.1. Base Format .........................................6
           3.1.2. Context Identifier Extension .......................10
      3.2. IPv6 Header Encoding ......................................11
           3.2.1. Traffic Class and Flow Label Compression ...........11
           3.2.2. Deriving IIDs from the Encapsulating Header ........12
           3.2.3. Stateless Multicast Address Compression ............13
           3.2.4. Stateful Multicast Address Compression .............14
   4. IPv6 Next Header Compression ...................................15
      4.1. LOWPAN_NHC Format .........................................15
      4.2. IPv6 Extension Header Compression .........................15
      4.3. UDP Header Compression ....................................17
           4.3.1. Compressing UDP Ports ..............................17
           4.3.2. Compressing UDP Checksum ...........................18
           4.3.3. UDP LOWPAN_NHC Format ..............................20
   5. IANA Considerations ............................................20
   6. Security Considerations ........................................21
   7. Acknowledgements ...............................................22
   8. References .....................................................22
      8.1. Normative References ......................................22
      8.2. Informative References ....................................23

1. Introduction ✨

so, the [IEEE802.15.4] standard sets an MTU of 127 bytes, which leaves about 80 octets of actual Media Access Control (MAC) payload when security is on, over a wireless link with throughput of 250 kbps or less 📉 The 6LoWPAN adaptation format [RFC4944] was made to carry IPv6 datagrams over these constrained links, where bandwidth, memory, and energy are limited, like in wireless sensor networks 🌱 [RFC4944] brings a Mesh Addressing header for sub-IP forwarding, a Fragmentation header to meet the IPv6 minimum MTU requirement [RFC2460], and stateless header compression (LOWPAN_HC1 and LOWPAN_HC2) that shrinks the big IPv6 and UDP headers down to, in the best case, a few bytes 🍓

LOWPAN_HC1 and LOWPAN_HC2 just aren't enough for most real-life uses of IPv6 in 6LoWPANs 😭 LOWPAN_HC1 works best for link-local unicast, where the addresses carry the link-local prefix and an Interface Identifier (IID) derived straight from the IEEE 802.15.4 addresses, so both addresses can be totally elided 🙈 BUT link-local addresses are mostly used for local protocol stuff like IPv6 Neighbor Discovery [RFC4861], DHCPv6 [RFC3315], or routing protocols. They usually aren't carrying application-layer data, so the win from this compression is pretty limited 💀

Routable addresses have to be used when talking to devices outside the 6LoWPAN, or in a route-over setup where IP forwarding happens inside the 6LoWPAN 🦋 For routable addresses, LOWPAN_HC1 needs both the IPv6 source and destination addresses to carry the prefix in-line. When the Mesh Addressing header isn't used, the IID of a routable address must be carried in-line too. LOWPAN_HC1 needs 64 bits for that IID when it's in-line, and it can't be shortened even when it's derived from the IEEE 802.15.4 16-bit short address 😤 And when the destination is an IPv6 multicast address, LOWPAN_HC1 has to carry the full 128-bit address in-line 🙃

So this document defines LOWPAN_IPHC, an encoding format that effectively compresses Unique Local, Global, and multicast IPv6 addresses using shared state within contexts 🧚 It also brings a bunch of other improvements over the header compression format in [RFC4944] 🎀

LOWPAN_IPHC lets us compress some commonly used IPv6 Hop Limit values. If the 6LoWPAN is a mesh-under stub, a Hop Limit of 1 for inbound traffic and a default value such as 64 for outbound are usually enough for application-layer data 💅 Also, a Hop Limit of 255 is often used to check that a communication happens over a single hop. This spec enables compression of the IPv6 Hop Limit field in those common cases, which LOWPAN_HC1 can't do 🌸

This document also defines LOWPAN_NHC, an encoding format for arbitrary next headers. LOWPAN_IPHC indicates whether the following header is encoded using LOWPAN_NHC. If it is, the bits right after the compressed IPv6 header start the LOWPAN_NHC encoding 👑 Compare that with LOWPAN_HC1, which could be extended to compress next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6. Even worse, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet and the uncompressed IPv6 header fields 😵 This spec moves the next header encoding bits to come after all the IPv6-related bits. That gives us a properly layered structure and direct support for IPv6 extension headers, which is honestly so iconic 🌈

Using LOWPAN_NHC, this document defines a compression mechanism for UDP. [RFC4944] already has a UDP compression mechanism, but it can't compress the checksum when upper-layer mechanisms like an upper-layer Message Integrity Check (MIC) make that possible. This spec adds the ability to elide the UDP checksum over the 6LoWPAN, which saves another two octets ✨

Also, using LOWPAN_NHC, this document defines encoding formats for IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. With LOWPAN_HC1 and LOWPAN_HC2, chains of next headers just can't be encoded efficiently 🫶

1.1. Requirements Language

the key words are the rules-of-the-game part 📖 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥

2. Specific Updates to RFC 4944 💖

this section is the main event for anyone who already implemented RFC 4944 🦋 This document specifies a header compression format meant to replace the one defined in Section 10 of [RFC4944]. Implementing Section 10 of [RFC4944] is now NOT RECOMMENDED 🙅‍♀️ New implementations MAY implement decompression according to Section 10 of [RFC4944], but they SHOULD NOT send packets compressed according to Section 10 of [RFC4944] 🌸

A compliant implementation of [RFC4944] as updated by this document MUST be able to properly process a packet that uses the provisions of this document 💅 A compliant implementation MAY implement additional LOWPAN_NHC types (Section 4) that may be registered (Section 5) in the future. How a compressor finds out that a decompressor has those extra capabilities is out of scope for this document 🧚

Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6 datagrams that don't fit in a single link frame. Section 5.3 of [RFC4944] defines the fragment header's datagram_size and datagram_offset values as the size and offset of the IPv6 datagram before compression. So all fragment payload outside the first fragment must carry its own portion of the IPv6 datagram before compression. This document does not change that requirement 🍓 When using the fragmentation mechanism described in Section 5.3 of [RFC4944], any header that cannot fit within the first fragment MUST NOT be compressed 🙈

Last thing for this part, bestie: the header compression format in this document preempts the ESC dispatch value defined in Section 5.1 of [RFC4944] 😤 Instead, the value 01 000000 is reserved as a replacement value for ESC, to be finally assigned with the first assignment of extension bytes 🎀

3. IPv6 Header Compression 🎀

Okay bestie, this is the good part 🫶 Section 3 is where LOWPAN_IPHC lives, the encoding that squishes the IPv6 header way down. Its whole trick is that it relies on info about the entire 6LoWPAN, so it can skip a ton of stuff. It assumes the common case looks like this 💅:

  • Version is 6
  • Traffic Class and Flow Label are both zero
  • Payload Length can be inferred from lower layers, either from the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header
  • Hop Limit will be set to a well-known value by the source
  • addresses assigned to 6LoWPAN interfaces will be formed using the link-local prefix or a small set of routable prefixes assigned to the entire 6LoWPAN
  • addresses assigned to 6LoWPAN interfaces are formed with an IID derived directly from either the 64-bit extended or the 16-bit short IEEE 802.15.4 addresses

Here's the layout, so you can see the vibe 🦋

    +-------------------------------------+----------------------------
    | Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields
    +-------------------------------------+----------------------------

                       Figure 1: LOWPAN_IPHC Header

The LOWPAN_IPHC encoding uses 13 bits, and 5 of those are borrowed from the rightmost bits of the dispatch type 🌸 Any info from the uncompressed IPv6 header fields that gets carried in-line just shows up right after the LOWPAN_IPHC encoding, like Figure 1 shows. The encoding can also be stretched by one more octet if you need extra contexts ✨

Now the best case is chef's kiss 🤌 With link-local communication, LOWPAN_IPHC can squash the whole IPv6 header down to just two octets: the dispatch octet and the LOWPAN_IPHC encoding. Iconic.

When you're routing over multiple IP hops, it's a little less dreamy but still slay 💀 The header can get down to 7 octets: 1-octet dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination Address.

Two things don't get to be compressed on those multi-hop trips. The Hop Limit stays uncompressed, because it has to be decremented at each hop and it can take any value. Also, the source and destination IPv6 addresses need stateful address compression, since they don't statelessly match the source and destination link-layer addresses on intermediate hops. Not me being picky, it's just the rules 🙈

3.1. LOWPAN_IPHC Encoding Format

Here's where we get into the nitty gritty 🧚 This part spells out exactly how the LOWPAN_IPHC encoding describes the compression of an IPv6 header. The encoding is 2 octets for the base version, or 3 octets when an extra context encoding shows up too. Any IPv6 header fields that aren't fully elided get tucked in right after the LOWPAN_IPHC, either in a compressed form (if the field is only partly elided) or just sent literally 💖

3.1.1. Base Format

Here is the bit map, bestie, read it carefully 👑

       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 0 | 1 | 1 |  TF   |NH | HLIM  |CID|SAC|  SAM  | M |DAC|  DAM  |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                    Figure 2: LOWPAN_IPHC base Encoding

Let's break down each field, one vibe at a time 🌈

TF: Traffic Class, Flow Label: As specified in [RFC3168], the 8-bit IPv6 Traffic Class field gets split into two fields: the 2-bit Explicit Congestion Notification (ECN) and the 6-bit Differentiated Services Code Point (DSCP).

  • 00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
  • 01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided.
  • 10: ECN + DSCP (1 byte), Flow Label is elided.
  • 11: Traffic Class and Flow Label are elided.

NH: Next Header:

  • 0: Full 8 bits for Next Header are carried in-line.
  • 1: The Next Header field is compressed and the next header is encoded using LOWPAN_NHC, which is discussed in Section 4.1.

HLIM: Hop Limit:

  • 00: The Hop Limit field is carried in-line.
  • 01: The Hop Limit field is compressed and the hop limit is 1.
  • 10: The Hop Limit field is compressed and the hop limit is 64.
  • 11: The Hop Limit field is compressed and the hop limit is 255.

CID: Context Identifier Extension:

  • 0: No additional 8-bit Context Identifier Extension is used. If context-based compression is specified in either Source Address Compression (SAC) or Destination Address Compression (DAC), context 0 is used.
  • 1: An additional 8-bit Context Identifier Extension field immediately follows the Destination Address Mode (DAM) field.

SAC: Source Address Compression

  • 0: Source address compression uses stateless compression.
  • 1: Source address compression uses stateful, context-based compression.

SAM: Source Address Mode:

If SAC=0:

  • 00: 128 bits. The full address is carried in-line.
  • 01: 64 bits. The first 64-bits of the address are elided. The value of those bits is the link-local prefix padded with zeros. The remaining 64 bits are carried in-line.
  • 10: 16 bits. The first 112 bits of the address are elided. The value of the first 64 bits is the link-local prefix padded with zeros. The following 64 bits are 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line.
  • 11: 0 bits. The address is fully elided. The first 64 bits of the address are the link-local prefix padded with zeros. The remaining 64 bits are computed from the encapsulating header (e.g., 802.15.4 or IPv6 source address) as specified in Section 3.2.2.

If SAC=1:

  • 00: The UNSPECIFIED address, ::
  • 01: 64 bits. The address is derived using context information and the 64 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from the corresponding bits carried in-line. Any remaining bits are zero.
  • 10: 16 bits. The address is derived using context information and the 16 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line. Any remaining bits are zero.
  • 11: 0 bits. The address is fully elided and is derived using context information and the encapsulating header (e.g., 802.15.4 or IPv6 source address). Bits covered by context information are always used. Any IID bits not covered by context information are computed from the encapsulating header as specified in Section 3.2.2. Any remaining bits are zero.

M: Multicast Compression

  • 0: Destination address is not a multicast address.
  • 1: Destination address is a multicast address.

DAC: Destination Address Compression

  • 0: Destination address compression uses stateless compression.
  • 1: Destination address compression uses stateful, context-based compression.

DAM: Destination Address Mode:

If M=0 and DAC=0, this case matches SAC=0 but for the destination address:

  • 00: 128 bits. The full address is carried in-line.
  • 01: 64 bits. The first 64-bits of the address are elided. The value of those bits is the link-local prefix padded with zeros. The remaining 64 bits are carried in-line.
  • 10: 16 bits. The first 112 bits of the address are elided. The value of the first 64 bits is the link-local prefix padded with zeros. The following 64 bits are 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line.
  • 11: 0 bits. The address is fully elided. The first 64 bits of the address are the link-local prefix padded with zeros. The remaining 64 bits are computed from the encapsulating header (e.g., 802.15.4 or IPv6 destination address) as specified in Section 3.2.2.

If M=0 and DAC=1:

  • 00: Reserved.
  • 01: 64 bits. The address is derived using context information and the 64 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from the corresponding bits carried in-line. Any remaining bits are zero.
  • 10: 16 bits. The address is derived using context information and the 16 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line. Any remaining bits are zero.
  • 11: 0 bits. The address is fully elided and is derived using context information and the encapsulating header (e.g. 802.15.4 or IPv6 destination address). Bits covered by context information are always used. Any IID bits not covered by context information are computed from the encapsulating header as specified in Section 3.2.2. Any remaining bits are zero.

If M=1 and DAC=0:

  • 00: 128 bits. The full address is carried in-line.
  • 01: 48 bits. The address takes the form ffXX::00XX:XXXX:XXXX.
  • 10: 32 bits. The address takes the form ffXX::00XX:XXXX.
  • 11: 8 bits. The address takes the form ff02::00XX.

If M=1 and DAC=1:

  • 00: 48 bits. This format is designed to match Unicast-Prefix-based IPv6 Multicast Addresses as defined in [RFC3306] and [RFC3956]. The multicast address takes the form ffXX:XXLL:PPPP:PPPP:PPPP:PPPP:XXXX:XXXX, where the X are the nibbles that are carried in-line, in the order in which they appear in this format. P denotes nibbles used to encode the prefix itself. L denotes nibbles used to encode the prefix length. The prefix information P and L is taken from the specified context.
  • 01: reserved
  • 10: reserved
  • 11: reserved

3.1.2. Context Identifier Extension

okay so bestie, this spec assumes there's a shared context between the node that compresses the packet and the node(s) that have to expand it 🧚 how contexts get shared and maintained is out of scope, what info goes inside a context is out of scope, and what to do with unknown or invalid contexts is also out of scope 🙈 the spec lets a node use up to 16 contexts ✨ and the context used for the source address doesn't have to match the one used for the destination address 💅

if the CID field is set to '1' in the LOWPAN_IPHC encoding, then one extra octet tucks in right after the DAM bits and before the in-line IPv6 header fields 🎀 that octet picks the pair of contexts used when the IPv6 source and/or destination address gets compressed. each address gets a 4-bit context identifier, which is how you get up to 16 contexts 🌸 context 0 is the default one 👑 Figure 3 shows the layout:

                   0   1   2   3   4   5   6   7
                 +---+---+---+---+---+---+---+---+
                 |      SCI      |      DCI      |
                 +---+---+---+---+---+---+---+---+

Figure 3: LOWPAN_IPHC Encoding

  • SCI: Source Context Identifier. Identifies the prefix that is used when the IPv6 source address is statefully compressed. 💜
  • DCI: Destination Context Identifier. Identifies the prefix that is used when the IPv6 destination address is statefully compressed. 🦋

3.2. IPv6 Header Encoding

the fields carried in-line (partly or fully) show up in the same order they do in the IPv6 header format [RFC2460] 📋 the Version field is always elided 🙈 unicast IPv6 addresses can be squished down to 64 or 16 bits, or elided completely 🫶 multicast IPv6 addresses can be squished to 8, 32, or 48 bits ✨ the IPv6 Payload Length field MUST always be elided and inferred from lower layers, using either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. no skipping this one, bestie 😭

3.2.1. Traffic Class and Flow Label Compression

the Traffic Class field in the IPv6 header is made of 6 bits of Diffserv extension [RFC2474] and 2 bits of Explicit Congestion Notification (ECN) [RFC3168] 🌈 the TF field in the LOWPAN_IPHC encoding tells you whether the Traffic Class and Flow Label are carried in-line in the compressed IPv6 header 💖 when the Flow Label is included but the Traffic Class is compressed, an extra 4 bits get added to keep byte alignment. two of those 4 bits hold the ECN bits from the Traffic Class field 🍓

so the ECN bits always land in the same spot for every encoding that includes them, the Traffic Class field gets rotated right by 2 bits in the compressed IPv6 header 🔄 the encodings look like this:

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN|   DSCP    |  rsv  |             Flow Label                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: TF = 00: Traffic Class and Flow Label carried in-line

                    1                   2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN|rsv|             Flow Label                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: TF = 01: Flow Label carried in-line

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|ECN|   DSCP    |
+-+-+-+-+-+-+-+-+

Figure 6: TF = 10: Traffic Class carried in-line

3.2.2. Deriving IIDs from the Encapsulating Header

LOWPAN_IPHC skips the IIDs of the source or destination addresses when SAM = 3 or DAM = 3, respectively 🫣 in this mode, the IID gets derived from the encapsulating header. when that header carries IPv6 addresses, the source and destination address bits get copied from the source and destination addresses of the encapsulating IPv6 header 🪞

the rest of this section defines how IEEE 802.15.4 [IEEE802.15.4] link-layer addresses map to IIDs, for both short and extended IEEE 802.15.4 addresses 🧩 IID bits that aren't covered by the context information MAY be elided if they match the link-layer address mapping, and they MUST NOT be elided if they don't match 🫶

an extended IEEE 802.15.4 address is basically an IEEE EUI-64 address. making an IID from an extended address is exactly the same as what's defined in Appendix A of [RFC4291] 💅 the only change needed to turn an IEEE EUI-64 identifier into an interface identifier is to invert the universal/local bit 🔁

a short IEEE 802.15.4 address is 16 bits long 🌸 short addresses get mapped into the restricted space of IEEE EUI-64 addresses by setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short address, and every other bit to zero 🎀 so an IID made from a short address looks like this:

0000:00ff:fe00:XXXX

where XXXX carries the short address ✨ the universal/local bit is zero, which means local scope 🌙

this mapping for non-EUI-64 identifiers is different from the one in Appendix A of [RFC4291] 👀 using the restricted space makes sure there's no overlap with IIDs made from unrestricted IEEE EUI-64 addresses 🛡️ and putting 0xfffe in the middle of the IID helps avoid overlap with other locally managed IIDs 💜

this short-address-to-64-bit-IID mapping is also used to rebuild any part of an IID that isn't covered by context information 🧠

3.2.3. Stateless Multicast Address Compression

LOWPAN_IPHC supports stateless compression of multicast addresses when M = 1 and DAC = 0 🦋 an IPv6 multicast address can get compressed down to 48, 32, or 8 bits using stateless compression. the format supports compressing the Solicited-Node Multicast Address (ff02:: 1:ffXX:XXXX), along with any IPv6 multicast address where the upper bits of the multicast group identifier are zero 🌈 the 8-bit compressed form only carries the least-significant bits of the multicast group identifier 🍓 the 48- and 32-bit compressed forms carry the multicast scope and flags in-line too, on top of the least-significant bits of the group identifier 🫶

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope |              Group Identifier                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Group Identifier       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: DAM = 01. 48-bit Compressed Multicast Address (ffFS::00GG:GGGG:GGGG)

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope |              Group Identifier                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: DAM = 10. 32-bit Compressed Multicast Address (ffFS::00GG:GGGG)

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

Figure 9: DAM = 11. 8-bit Compressed Multicast Address (ff02::GG)

3.2.4. Stateful Multicast Address Compression

LOWPAN_IPHC supports stateful compression of multicast addresses when M = 1 and DAC = 1 🧚 this document currently defines DAM = 00: context-based compression of Unicast-Prefix-based IPv6 Multicast Addresses [RFC3306][RFC3956] 🔮 the Prefix Length and Network Prefix can be pulled from a context. so LOWPAN_IPHC can squish a Unicast-Prefix-based IPv6 Multicast Address down to 6 octets, carrying only the 4-bit Flags, 4-bit Scope, 8-bit Rendezvous Point Interface ID (RIID), and 32-bit Group Identifier in-line 🎀

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Rsvd / RIID   |       Group Identifier        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Group Identifier       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: DAM = 00. Unicast-Prefix-based IPv6 Multicast Address Compression

note that the Reserved field MUST carry the reserved bits from the multicast address format described in [RFC3306] 📝 when a Rendezvous Point is encoded in the multicast address as described in [RFC3956], the Reserved field carries the RIID bits in-line 💜

4. IPv6 Next Header Compression ✨

LOWPAN_IPHC skips the IPv6 Next Header field when the NH bit is set to 1 🙈 that also signals the use of 6LoWPAN next header compression, which is LOWPAN_NHC 💅 the value of the IPv6 Next Header gets recovered from the first bits of the LOWPAN_NHC encoding, and the bits after that are specific to whichever Next Header value it is 🧩 Figure 11 shows how an IPv6 datagram looks when it's compressed with LOWPAN_IPHC and LOWPAN_NHC 🦋

+-------------+-------------+-------------+-----------------+--------
| LOWPAN_IPHC | In-line     | LOWPAN_NHC  | In-line Next    | Payload
|   Encoding  |   IP Fields |   Encoding  |   Header Fields |
+-------------+-------------+-------------+-----------------+--------

Figure 11: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration

4.1. LOWPAN_NHC Format

compression formats for different next headers are identified by a variable-length bit pattern that sits right after the LOWPAN_IPHC compressed header 🌷 when you define a next header compression format, the number of bits used SHOULD be decided by how often that format is expected to be used 📊 but the number of bits and any remaining encoding bits SHOULD respect octet alignment 🫶 the bits after that are specific to the next header compression format. this document defines a compression format for IPv6 Extension and UDP headers 🎀

           +----------------+---------------------------
           | var-len NHC ID | compressed next header...
           +----------------+---------------------------

Figure 12: LOWPAN_NHC Encoding

4.2. IPv6 Extension Header Compression ✨

okay so here's the big rule for LOWPAN_NHC 🧚: the header right before it has to be encoded with either LOWPAN_IPHC or LOWPAN_NHC. Basically, every header that uses this 6LoWPAN encoding format has to be contiguous, no gaps allowed 🫶. Because of that, this document defines a set of LOWPAN_NHC encodings for certain IPv6 Extension Headers. That's what lets the UDP Header Compression from Section 4.3 work even when those extension headers are hanging out 💅

Each LOWPAN_NHC encoding for an extension header is one LOWPAN_NHC octet followed by the extension header itself. The LOWPAN_NHC octet is shown in Figure 13 🌸. The first 7 bits identify the extension header right after the octet, and the last bit tells you whether that next header is also LOWPAN_NHC encoded 💜

                   0   1   2   3   4   5   6   7
                 +---+---+---+---+---+---+---+---+
                 | 1 | 1 | 1 | 0 |    EID    |NH |
                 +---+---+---+---+---+---+---+---+

             Figure 13: IPv6 Extension Header Encoding

EID is the IPv6 Extension Header ID 🦋:

  • 0: IPv6 Hop-by-Hop Options Header [RFC2460]
  • 1: IPv6 Routing Header [RFC2460]
  • 2: IPv6 Fragment Header [RFC2460]
  • 3: IPv6 Destination Options Header [RFC2460]
  • 4: IPv6 Mobility Header [RFC6275]
  • 5: Reserved
  • 6: Reserved
  • 7: IPv6 Header

NH is the Next Header bit 🍓:

  • 0: Full 8 bits for Next Header are carried in-line.
  • 1: The Next Header field is elided and the next header is encoded using LOWPAN_NHC, which is discussed in Section 4.1.

Mostly, the extension header just gets carried unmodified in the bytes right after the LOWPAN_NHC octet. There are two exceptions though, and they're the Length field and the Next Header field 👀

The Next Header field inside the extension header gets elided whenever the NH bit is set in the LOWPAN_NHC octet. This is honestly so clever, because it means LOWPAN_NHC ends up with no more overhead than the non-encoded extension header would have had 🤌

The Length field in a compressed extension header counts the octets that belong to the (compressed) extension header after the Length field. This changes the definition from [RFC2460], which counted the header size in 8-octet units and didn't include the first 8 octets. Switching to octets gets rid of wasteful internal fragmentation, which is so iconic of it 💖

Hop-by-Hop and Destination Options Headers can use a trailing Pad1 or PadN to get to 8-octet alignment. When there's a single trailing Pad1 or PadN option that's 7 octets or less, and the containing header is a multiple of 8 octets, the compressor MAY elide that trailing Pad1 or PadN option. A decompressor MUST ensure that the containing header is padded out to a multiple of 8 octets in length, using a Pad1 or PadN option if necessary 🎀. Heads up though: Pad1 and PadN options that show up anywhere other than the end MUST be carried in-line, because they're used to line up the options that come after them 👑

Specifying units in octets means LOWPAN_NHC MUST NOT be used to encode IPv6 Extension Headers that have more than 255 octets following the Length field after compression. Not me saying "no" to a 256-octet header 💀

When the identified next header is an IPv6 Header (EID=7), the NH bit of the LOWPAN_NHC encoding is unused and MUST be set to zero. The bytes after that MUST be encoded using LOWPAN_IPHC as defined in Section 3 🌈

4.3. UDP Header Compression 🦋

This document defines a compression format for UDP headers using LOWPAN_NHC. The UDP compression format is shown in Figure 14. Bits 0 through 4 are the NHC ID, and '11110' tells you it's this specific UDP header compression encoding from this section ✨

4.3.1. Compressing UDP Ports 🌸

This spec lets a particular range of port numbers (0xf0b0 to 0xf0bf) get compressed down to 4 bits. It's stateless, which the spec inherits from [RFC4944], so it's not a brand new stateful compression thing 🧚

The range of ports that can compress down to 4 bits is not in a reserved range. So a network stack built to talk over a 6LoWPAN should avoid using those ports as dynamic ports whenever possible 🫶

Since that's only 16 contiguous ports, lots of incompatible applications are probably going to end up using the same port numbers for their own end-to-end stuff 😭. That means a port in the (0xf0b0 to 0xf0bf) range tells you very little about the application on the other end.

Overloading the 0xf0bX ports makes it more likely you'll get the wrong type of payload and misread the content, compared to ports that are reserved at IANA. So it's recommended that those ports be paired with a mechanism like a Transport Layer Security (TLS) [RFC5246] Message Integrity Check (MIC), which makes sure the content is what's expected and gets checked 🔥

4.3.2. Compressing UDP Checksum 💅

The UDP checksum is mandatory with IPv6 [RFC2460] for all packets, no exceptions 👑. For that reason, [RFC4944] doesn't allow the UDP checksum to be compressed.

With this spec, a compressor in the source transport endpoint MAY elide the UDP Checksum if the upper layer authorizes it. The compressor MUST NOT set the C bit unless it has gotten that authorization. Requiring upper-layer authorization makes sure the intended transport peer has enough tools to deal with any data corruption that happens before it reaches the destination 🎀. The upper layer MUST NOT provide that authorization unless one of the following cases is satisfied:

Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo-fieldbus by tunneling existing field protocols over UDP. If the tunneled Protocol Data Unit (PDU) has its own addressing, security, and integrity check (for example, IPsec Encapsulating Security Payload tunnel mode [RFC4303] or IP over UDP encapsulation), the tunneling mechanism MAY authorize eliding the UDP checksum in order to save on the encapsulation overhead 🦋

Message Integrity Check: In this case, either IPsec Authentication Header [RFC4302] or some other form of integrity check in the UDP payload is used. It has to cover at least the same information as the UDP checksum (pseudo-header, data) and have at least the same strength 💜

To help make sure the UDP Checksum gets properly restored when a 6LoWPAN packet is expanded, an additional integrity check (for example, a Layer 2 (L2) Message Integrity Check) MUST be used whenever link frames carry a compressed UDP datagram that elides the checksum. Without that extra integrity check, a UDP packet could get delivered to an unintended destination, because corruption in data covered by the pseudo-header could go undetected. Scary stuff 🙈

A compressor MUST verify the UDP Checksum before it gets elided, and MUST ensure that the additional integrity check is in place before verifying and eliding the checksum. If verifying the UDP Checksum fails, the compressor MUST drop the packet 💀

A decompressor that expands a 6LoWPAN packet with the C bit set MUST compute the UDP Checksum on behalf of the source node and place that value in the restored UDP header, as specified in the incumbent standards [RFC0768], [RFC2460]. The decompressor MUST unambiguously determine that the compressor put an additional integrity check in place, and it MUST verify that integrity check. It SHOULD do this after restoring the UDP Checksum 🌈. If the decompressor can't unambiguously determine the presence of an integrity check, or the verification fails, the decompressor MUST drop the packet.

The recommended order for computing and verifying the UDP Checksum and the additional integrity check makes sure data is never stored unprotected in memory 🧚. In practice, separating functionality between layers might rule out that recommended order. Even so, implementors should take special note and understand the risks when dealing with unprotected data covered by the pseudo-header 🔥

To let intermediate nodes compress the UDP Checksum, a forwarding node MAY infer upper-layer authorization for an incoming packet if it has the C bit set and it can unambiguously determine that an integrity check covering the same data as the UDP Checksum was in place while the UDP Checksum was elided. A forwarding node MUST NOT infer authorization if it can't unambiguously determine the presence of, and verify, an integrity check while the UDP Checksum was elided 👑

4.3.3. UDP LOWPAN_NHC Format 🎀

                   0   1   2   3   4   5   6   7
                 +---+---+---+---+---+---+---+---+
                 | 1 | 1 | 1 | 1 | 0 | C |   P   |
                 +---+---+---+---+---+---+---+---+

                  Figure 14: UDP Header Encoding

C is the Checksum bit 🌸:

  • 0: All 16 bits of Checksum are carried in-line.
  • 1: All 16 bits of Checksum are elided. The Checksum is recovered by recomputing it on the 6LoWPAN termination point.

P is the Ports field 🍓:

  • 00: All 16 bits for both Source Port and Destination Port are carried in-line.
  • 01: All 16 bits for Source Port are carried in-line. First 8 bits of Destination Port is 0xf0 and elided. The remaining 8 bits of Destination Port are carried in-line.
  • 10: First 8 bits of Source Port are 0xf0 and elided. The remaining 8 bits of Source Port are carried in-line. All 16 bits for Destination Port are carried in-line.
  • 11: First 12 bits of both Source Port and Destination Port are 0xf0b and elided. The remaining 4 bits for each are carried in-line.

Fields that are carried in-line (in part or in whole) show up in the same order they do in the UDP header format [RFC0768] ✨. The UDP Length field MUST always be elided, and it gets inferred from lower layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header 💖

5. IANA Considerations ✨

okay so this section is all about who gets which numbers 🔢 this doc hands out a brand new IPv6 header compression format for 6LoWPAN 🎀 and it claims 32 Dispatch type field values for LOWPAN_IPHC, from 01 100000 all the way to 01 111111 🦋

01 100000
 through
01 111111

this claim knocks out 01 111111, which was previously set aside for ESC [RFC4944] 😭 it's allowed because the extension bytes that would make ESC useful haven't been handed out yet. so instead, the value below is reserved as a stand-in for ESC, to get its final assignment with the first batch of extension bytes 🧚

01 000000

and then there's the new LOWPAN_NHC registry 🌸 it starts out looking like this:

00000000 to 11011111: (unassigned)
1110000N: IPv6 Hop-by-Hop Options Header       [RFC6282]
1110001N: IPv6 Routing Header                  [RFC6282]
1110010N: IPv6 Fragment Header                 [RFC6282]
1110011N: IPv6 Destination Options Header      [RFC6282]
1110100N: IPv6 Mobility Header                 [RFC6282]
1110111N: IPv6 Header                          [RFC6282]
11110CPP: UDP Header                           [RFC6282]
11111000 to 11111110: (unassigned)

capital letters in the bit positions are class-specific bit assignments 💅 the N tells you whether more LOWPAN_NHC encodings follow (see Section 4.2), and CPP holds the UDP-specific variables from Section 4.3 ✨

the policy for this registry is IETF Review [RFC5226] 👑 and the rule here is that new values SHOULD be assigned in a way that keeps the NHC ID abstraction from Section 4 alive 🫶 aka k one-bits followed by one zero-bit pick out the general class of NHC, and then the class-specific bits come after 🌈

6. Security Considerations 🙈

this part is serious, bestie 😭 LOWPAN_IPHC lets you compress header info for communication that could've happened without it, just in a less efficient way 🍓 it also recognizes that an IEEE 802.15.4 PAN can have a bunch of prefixes tied to it through shared context. how that shared context gets assigned and managed is beyond the scope of this document 🫣

the overloading of the 0xf0bX ports raises the risk of getting the wrong type of payload and misreading the content, compared to ports that are reserved at IANA 💀

so it's recommended that those ports come with something like a Transport Layer Security (TLS) [RFC5246] Message Integrity Check (MIC), which confirms the content is what's expected and checks its integrity 🔐 no cap, this part matters a lot 💜

7. Acknowledgements 💖

huge thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, Carsten Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde Durvy, Erik Nordmark, Christos Polyzois, Joseph Reddy, Shoichi Sakane, Zach Shelby, Dario Tedeschi, Tony Viscardi, and Jay Werb 🫶 for useful design consideration and implementation feedback 🎀 and a special shout-out to David Black, Lars Eggert, and Carsten Bormann for their work closing the security issues around UDP compression 👑✨

8. References 📚

8.1. Normative References

[RFC0768]       Postel, J., "User Datagram Protocol", STD 6, RFC 768,
                August 1980.

[RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2460]       Deering, S. and R. Hinden, "Internet Protocol,
                Version 6 (IPv6) Specification", RFC 2460,
                December 1998.

[RFC2474]       Nichols, K., Blake, S., Baker, F., and D. Black,
                "Definition of the Differentiated Services Field (DS
                Field) in the IPv4 and IPv6 Headers", RFC 2474,
                December 1998.

[RFC3168]       Ramakrishnan, K., Floyd, S., and D. Black, "The
                Addition of Explicit Congestion Notification (ECN) to
                IP", RFC 3168, September 2001.

[RFC4291]       Hinden, R. and S. Deering, "IP Version 6 Addressing
                Architecture", RFC 4291, February 2006.

[RFC4944]       Montenegro, G., Kushalnagar, N., Hui, J., and D.
                Culler, "Transmission of IPv6 Packets over IEEE
                802.15.4 Networks", RFC 4944, September 2007.

[RFC5226]       Narten, T. and H. Alvestrand, "Guidelines for Writing
                an IANA Considerations Section in RFCs", BCP 26,
                RFC 5226, May 2008.

[RFC6275]       Perkins, C., Ed., Johnson, D., and J. Arkko,
                "Mobility Support in IPv6", RFC 6275, July 2011.

8.2. Informative References

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

[RFC3306]       Haberman, B. and D. Thaler, "Unicast-Prefix-based
                IPv6 Multicast Addresses", RFC 3306, August 2002.

[RFC3315]       Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
                C., and M. Carney, "Dynamic Host Configuration
                Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC3956]       Savola, P. and B. Haberman, "Embedding the Rendezvous
                Point (RP) Address in an IPv6 Multicast Address",
                RFC 3956, November 2004.

[RFC4302]       Kent, S., "IP Authentication Header", RFC 4302,
                December 2005.

[RFC4303]       Kent, S., "IP Encapsulating Security Payload (ESP)",
                RFC 4303, December 2005.

[RFC4861]       Narten, T., Nordmark, E., Simpson, W., and H.
                Soliman, "Neighbor Discovery for IP version 6
                (IPv6)", RFC 4861, September 2007.

[RFC5246]       Dierks, T. and E. Rescorla, "The Transport Layer
                Security (TLS) Protocol Version 1.2", RFC 5246,
                August 2008.

Authors' Addresses 🦋

Jonathan W. Hui (editor)
Arch Rock Corporation
501 2nd St. Ste. 410
San Francisco, California  94107
USA

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


Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis  06410
FRANCE

Phone: +33 4 97 23 26 34
EMail: pthubert@cisco.com

that's the whole RFC, bestie 🌈💜 the people who wrote this are the reason our tiny IoT devices can talk over IPv6 without wasting bytes 👑🫶

📦 where this page comes from