RFC 7428

Transmission of IPv6 Packets over ITU-T G.9959 Networks

📅 published February 2015, from ietf

RFC 7428: Transmission of IPv6 Packets over ITU-T G.9959 Networks 🎀

okay bestie, this one is from the IETF and it's a Standards Track doc (ISSN 2070-1721), dated February 2015 🦋 The authors are A. Brandt and J. Buron, both from Sigma Designs. The header doesn't list any RFCs this one obsoletes or updates, so it's standing on its own 💅

Abstract ✨

okay so this doc describes the frame format for sending IPv6 packets, plus how to form IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks 🫶

Status of This Memo 🌸

this is an Internet Standards Track document, no cap 🔥

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 💜

for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7428 🧚

Copyright Notice 🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. please actually read these, because they spell out your rights and restrictions for this doc 🙈

if you pull Code Components out of this doc, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License ✨

Table of Contents 🍓

   1. Introduction ....................................................2
      1.1. Terms Used .................................................3
      1.2. Requirements Language ......................................4
   2. G.9959 Parameters to Use for IPv6 Transport .....................5
      2.1. Addressing Mode ............................................5
      2.2. IPv6 Multicast Support .....................................6
      2.3. G.9959 MAC PDU Size and IPv6 MTU ...........................6
      2.4. Transmission Status Indications ............................7
      2.5. Transmission Security ......................................7
   3. 6LoWPAN Adaptation Layer and Frame Format .......................7
      3.1. Dispatch Header ............................................8
   4. 6LoWPAN Addressing ..............................................9
      4.1. Stateless Address Autoconfiguration of Routable IPv6
           Addresses ..................................................9
      4.2. IPv6 Link-Local Address ...................................10
      4.3. Unicast Address Mapping ...................................10
      4.4. On the Use of Neighbor Discovery Technologies .............11
           4.4.1. Prefix and CID Management (Route-Over) .............11
           4.4.2. Prefix and CID Management (Mesh-Under) .............11
   5. Header Compression .............................................12
   6. Security Considerations ........................................13
   7. Privacy Considerations .........................................14
   8. References .....................................................14
      8.1. Normative References ......................................14
      8.2. Informative References ....................................16
   Appendix A. G.9959 6LoWPAN Datagram Example .......................17
   Acknowledgements ..................................................21
   Authors' Addresses ................................................21

1. Introduction ✨

okay so the ITU-T G.9959 recommendation [G.9959] is aimed at low-power Personal Area Networks (PANs) 🦋 This doc defines the frame format for sending IPv6 [RFC2460] packets, plus how to form IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on G.9959 networks.

the general vibe is to adapt parts of [RFC4944] for G.9959 networks 💅 G.9959 gives you a Segmentation and Reassembly (SAR) layer so you can send datagrams bigger than the G.9959 Media Access Control Protocol Data Unit (MAC PDU) 🎀

[RFC6775] updates [RFC4944] with 6LoWPAN optimizations for IPv6 Neighbor Discovery (ND), which was originally defined by [RFC4861] 🌸 This doc only uses [RFC6775] for prefix and Context ID assignment. an Interface Identifier (IID) can be built from a G.9959 link-layer address, which gives you a "link-layer-derived IPv6 address" 😭 if you go that route, Duplicate Address Detection (DAD) is not needed. or you can get IPv6 addresses centrally through DHCP, which gives you a "non-link-layer-derived IPv6 address". address registration is only needed in certain cases 🧚

the frame format in this doc can also be used by IPv6 routing protocols, like the Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] or Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks (P2P-RPL) [RFC6997], to do IPv6 routing over G.9959 networks 👑

the encapsulation frame defined here may optionally be carried via mesh routing below the 6LoWPAN layer. mesh-under and route-over routing protocol specs are out of scope for this doc 🙈

1.1. Terms Used 🍓

6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
ABR: Authoritative 6LoWPAN Border Router (Authoritative 6LBR) [RFC6775]
Ack: Acknowledgement
AES: Advanced Encryption Standard
CID: Context Identifier [RFC6775]
DAD: Duplicate Address Detection [RFC6775]
DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315]
EUI-64: Extended Unique Identifier [EUI64]
G.9959: Short range narrow-band digital radiocommunication transceiver [G.9959]
GHC: Generic Header Compression [RFC7400]
HomeID: G.9959 Link-Layer Network Identifier
IID: Interface Identifier
Link-layer-derived address: IPv6 address constructed on the basis of link-layer address information
MAC: Media Access Control
Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer
MTU: Maximum Transmission Unit
ND: Neighbor Discovery [RFC4861] [RFC6775]
NodeID: G.9959 Link-Layer Node Identifier
Non-link-layer-derived address: IPv6 address assigned by a managed process, e.g., DHCPv6
P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks [RFC6997]
PAN: Personal Area Network
PDU: Protocol Data Unit
PHY: Physical Layer
RA: Router Advertisement [RFC4861] [RFC6775]
Route-over: Forwarding via IP routing above the 6LoWPAN layer
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [RFC6550]
SAR: G.9959 Segmentation and Reassembly
ULA: Unique Local Address [RFC4193]

1.2. Requirements Language 💖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in [RFC2119] 🫶

2. G.9959 Parameters to Use for IPv6 Transport 🌈

this section lays out the properties of the G.9959 PHY and MAC layers, and how to use them for IPv6 transport 💅

2.1. Addressing Mode 🦋

G.9959 defines how a unique 32-bit HomeID network identifier gets assigned by a network controller, and how an 8-bit NodeID host identifier gets allocated to each node 🎀 NodeIDs are unique within the network the HomeID identifies. the G.9959 HomeID stands for an IPv6 subnet, which is identified by one or more IPv6 prefixes ✨

an IPv6 host MUST build its link-local IPv6 address from the link-layer-derived IID so that IP header compression works as described in [RFC6282] 🔥

a node interface MAY support the M flag of the RA message for building routable IPv6 addresses. a cost-optimized node implementation may save memory by skipping M flag support 💜 the M flag MUST be interpreted as defined in Figure 1 🍓

    +--------+--------+---------------------------------------------+
    | M flag | M flag |  Required node behavior                     |
    | support| value  |                                             |
    +--------+--------+---------------------------------------------+
    | No     |(ignore)| Node MUST use link-layer-derived addressing |
    +--------+--------+---------------------------------------------+
    | Yes    |    0   | Node MUST use link-layer-derived addressing |
    |        +--------+---------------------------------------------+
    |        |    1   | Node MUST use DHCPv6-based addressing, and  |
    |        |        | node MUST comply fully with [RFC6775]       |
    +--------+--------+---------------------------------------------+

              Figure 1: RA M Flag Support and Interpretation

a node that uses DHCPv6-based addressing MUST comply fully with the text of [RFC6775] 🧚

if you're using DHCPv6-based addressing, the DHCPv6 client must use a DHCPv6 Unique Identifier (DUID) of type DUID-UUID, as described in [RFC6355]. the Universally Unique Identifier (UUID) inside the DUID-UUID must be generated as specified in [RFC4122], Section 4.5, starting at the third paragraph of that section (the 47-bit random number-based UUID). the DUID must be stored persistently by the node as specified in Section 3 of [RFC6355] 😭

⚠️ a word of caution, bestie: HomeIDs and NodeIDs are handed out by a network controller function during inclusion, so identifier validity and uniqueness only last as long as the network membership does. a mishap at the network controller can cut that short. having one single point of failure at the network controller means high-reliability deployments may benefit from a redundant network controller function 💀

this warning applies to link-layer-derived addressing AND non-link-layer-derived addressing deployments 🙈

2.2. IPv6 Multicast Support 🌸

[RFC3819] recommends that IP subnetworks support (subnet-wide) multicast 💖 G.9959 supports direct-range IPv6 multicast, but it doesn't natively support subnet-wide multicast 😭 subnet-wide multicast can be provided by an IP routing protocol or a mesh routing protocol running below the 6LoWPAN layer. routing protocol specs are out of scope for this doc 🦋

IPv6 multicast packets MUST be carried via G.9959 broadcast 🔥

as per [G.9959], this works like so:

the destination HomeID of the G.9959 MAC PDU MUST be the HomeID of the network.
the destination NodeID of the G.9959 MAC PDU MUST be the broadcast NodeID (0xff).

G.9959 broadcast MAC PDUs are only intercepted by nodes within the network identified by the HomeID 🧚✨

2.3. G.9959 MAC PDU Size and IPv6 MTU 📦

okay bestie, the big rule first: IPv6 packets MUST be transmitted using G.9959 transmission profile R3 or higher. no cap, that's a hard requirement 💅

[RFC2460] says any link that can't carry a 1280-octet packet in one piece has to do link-specific fragmentation and reassembly at a layer below IPv6 🧩

G.9959 handles segmentation and reassembly for payloads up to 1350 octets. IPv6 header compression [RFC6282] makes it way more likely that a short IPv6 packet fits in a single G.9959 frame ✨ That's why Section 3 of this document says [RFC6282] MUST be supported. With the mandatory link-layer security turned on, a G.9959 R3 MAC PDU can hold 6LoWPAN datagrams up to 130 octets without triggering G.9959 segmentation and reassembly. Longer 6LoWPAN datagrams will lead to multiple G.9959 PDUs.

2.4. Transmission Status Indications 📡

The G.9959 MAC layer has native acknowledgement and retransmission of MAC PDUs. The G.9959 SAR layer does the same for larger datagrams. A mesh routing layer may offer something similar for routed communication. An IPv6 routing stack talking over G.9959 may use link-layer status indications, like delivery confirmation and Ack timeout from the MAC layer 🦋

2.5. Transmission Security 🔐

Implementations claiming conformance with this document MUST enable G.9959 shared network key security. No skipping this one, bestie 🙅‍♀️

The shared network key is meant to cover security requirements in the home at the normal level. For applications with high or very high requirements for confidentiality and/or integrity, you may need extra application-layer security for end-to-end authentication and encryption. (The availability of the network relies on the security properties of the network key in any case.) 🫶

3. 6LoWPAN Adaptation Layer and Frame Format 🧚

The 6LoWPAN encapsulation formats in this section ride along as payload inside the G.9959 MAC PDU. IPv6 header compression [RFC6282] MUST be supported by implementations of this specification. Also, implementations MAY support Generic Header Compression (GHC) [RFC7400]. A node implementing [RFC7400] MUST probe its peers for GHC support before applying GHC 👀

Every 6LoWPAN datagram sent over G.9959 starts with a 6LoWPAN encapsulation header stack, and the 6LoWPAN payload comes right after it. Each header in the stack has a header type followed by zero or more header fields. An IPv6 header stack may contain, in this order, addressing, hop-by-hop options, routing, fragmentation, destination options, and finally payload [RFC2460]. The 6LoWPAN header format is structured the same way. Right now, only one payload option is defined for the G.9959 6LoWPAN header format.

The definition of a 6LoWPAN header is made up of the dispatch value, the definition of the header fields that follow, and their ordering rules relative to all other headers. The header stack structure gives a way to handle future demands on the 6LoWPAN adaptation layer, but it isn't meant to be general-purpose extensibility, so don't get it twisted 🙃

An example of a complete G.9959 6LoWPAN datagram can be found in Appendix A ✨

3.1. Dispatch Header 🎀

The Dispatch Header looks like this:

  0                   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 6LoWPAN CmdCls|   Dispatch    |  Type-specific header         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 2: Dispatch Type and Header

6LoWPAN CmdCls: the 6LoWPAN Command Class identifier. This field MUST carry the value 0x4F [G.9959]. The ITU-T assigns the value, and it says the following bits are a 6LoWPAN encapsulated datagram. 6LoWPAN protocols MUST ignore the G.9959 frame if the 6LoWPAN Command Class identifier deviates from 0x4F.
Dispatch: identifies the header type immediately following the Dispatch Header.
Type-specific header: a header determined by the Dispatch Header.

The dispatch value can be treated as an unstructured namespace. Only a few symbols are needed to represent current 6LoWPAN functionality. Some extra savings could be had by encoding more functionality into the dispatch byte, but those measures would tend to limit the ability to handle future alternatives 🧠

+------------+--------------------+-----------+
| Pattern    | Header Type        | Reference |
+------------+--------------------+-----------+
| 01  1xxxxx | 6LoWPAN_IPHC       | [RFC6282] |
+------------+--------------------+-----------+

Other IANA-assigned 6LoWPAN dispatch values do not apply to this document.

Figure 3: Dispatch Values

6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282].

4. 6LoWPAN Addressing 🏡

IPv6 addresses may be autoconfigured from IIDs, and those IIDs may in turn be built from link-layer address information. This saves memory in devices and makes IP header compression efficient as per [RFC6282]. The catch: link-layer-derived addresses are static and may involuntarily expose private usage data on public networks, so see Section 7 🕵️‍♀️

A NodeID gets mapped into an IEEE EUI-64 identifier like this:

                     IID = 0000:00ff:fe00:YYXX

              Figure 4: Constructing a Compressible IID

Where XX carries the G.9959 NodeID and YY is a 1-byte value chosen by the individual node. The default YY value MUST be zero. A node MAY use values of YY other than zero to form additional IIDs in order to instantiate multiple IPv6 interfaces. The YY value MUST be ignored when computing the corresponding NodeID (the XX value) from an IID.

Building IIDs from the link-layer address obviously doesn't support addresses assigned or constructed by other means. A node MUST NOT compute the NodeID from the IID if the first 6 bytes of the IID don't comply with the format defined in Figure 4. In that case, the address resolution mechanisms of [RFC6775] apply 💁‍♀️

4.1. Stateless Address Autoconfiguration of Routable IPv6 Addresses 🌐

The IID defined above MUST be used whether you're autoconfiguring a ULA IPv6 address [RFC4193] or a globally routable IPv6 address [RFC3587] in G.9959 subnets.

4.2. IPv6 Link-Local Address 🔗

The IPv6 link-local address [RFC4291] for a G.9959 interface is formed by appending the IID defined above to the IPv6 link-local prefix fe80::/64.

The "Universal/Local" (U/L) bit MUST be set to zero, since this isn't a globally unique value [EUI64] 🙈

The resulting link-local address is formed like this:

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

                  Figure 5: IPv6 Link-Local Address

4.3. Unicast Address Mapping 🗺️

The address resolution procedure for mapping IPv6 unicast addresses into G.9959 link-layer addresses follows the general description in Section 7.2 of [RFC4861]. The Source/Target Link-layer Address option MUST have the following form when the link layer is G.9959.

                   0                   1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |     Type      |    Length=1   |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |     0x00      |    NodeID     |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |            Padding            |
                  +-                             -+
                  |          (All zeros)          |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 6: IPv6 Unicast Address Mapping

Option fields:

Type: the value 1 signifies the Source Link-layer address. The value 2 signifies the Destination Link-layer address.
Length: the length of this option (including the Type and Length fields) in units of 8 octets. The value of this field is always 1 for G.9959 NodeIDs.
NodeID: the G.9959 NodeID to which the actual interface currently responds. The link-layer address may change if the interface joins another network at a later time.

4.4. On the Use of Neighbor Discovery Technologies 📣

[RFC4861] specifies how IPv6 nodes may resolve link-layer addresses from IPv6 addresses using link-local IPv6 multicast. [RFC6775] is an optimization of [RFC4861], specifically aimed at 6LoWPAN networks. [RFC6775] defines how a 6LoWPAN node may register IPv6 addresses with an authoritative border router (ABR). Mesh-under networks MUST NOT use [RFC6775] address registration. However, [RFC6775] address registration MUST be used if the first 6 bytes of the IID don't comply with the format defined in Figure 4 🧐

4.4.1. Prefix and CID Management (Route-Over) 🛣️

In route-over environments, IPv6 hosts MUST use [RFC6775] address registration. A node implementation for route-over operation MAY use [RFC6775] mechanisms for obtaining IPv6 prefixes and corresponding header compression context information [RFC6282]. [RFC6775] route-over requirements apply with no modifications.

4.4.2. Prefix and CID Management (Mesh-Under) 🕸️

An implementation for mesh-under operation MUST use [RFC6775] mechanisms for managing IPv6 prefixes and corresponding header compression context information [RFC6282]. [RFC6775] Duplicate Address Detection (DAD) MUST NOT be used, since the link-layer inclusion process of G.9959 ensures that a NodeID is unique for a given HomeID 🔑

With this exception and the specific redefinition of the RA Router Lifetime value 0xFFFF (refer to Section 4.4.2.3), the text of the following subsections complies with [RFC6775].

4.4.2.1. Prefix Assignment Considerations 🏷️

As stated by [RFC6775], an ABR is responsible for managing prefix(es). Global routable prefixes may change over time. A ULA prefix is RECOMMENDED to be assigned to the 6LoWPAN subnet, which helps keep site-local application associations based on IPv6 addresses stable 💜 A node MAY support the M flag of the RA message. This influences the way IPv6 addresses are assigned. Refer to Section 2.1 for details.

4.4.2.2. Robust and Efficient CID Management 🧩

The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an RA to disseminate Context IDs (CIDs) for compressing prefixes. One or more prefixes and corresponding Context IDs MUST be assigned during initial node inclusion.

When updating context information, a CID may have its lifetime set to zero to obsolete it. The CID MUST NOT be reused immediately; rather, the next vacant CID should be assigned. Header compression based on CIDs MUST NOT be used for RA messages carrying context information. An expired CID and the associated prefix MUST NOT be reset but rather must be retained in receive-only mode if there is no other current need for the CID value. This lets an ABR detect if a sleeping node without a clock uses an expired CID, and in response, the ABR MUST return an RA with fresh context information to the originator 🫧

4.4.2.3. Infinite Prefix Lifetime Support for Island-Mode Networks ✨

okay so nodes MUST renew the prefix and CID according to whatever lifetime the ABR signals 🔄💖 [RFC6775] says the RA Router Lifetime field MAY go all the way up to 0xFFFF 🌸 and this doc adds that 0xFFFF MUST be read as an infinite lifetime ♾️ ABRs MUST NOT use that value 🙅‍♀️ it's only for a sleepy network controller, like a battery-powered remote acting as the master for a tiny island-mode network of light modules 💡🛋️ so cute!!

5. Header Compression ✨

IPv6 header compression [RFC6282] MUST be implemented 🫶 and GHC [RFC7400] compression for higher layers MAY be implemented too 💅 this section is basically a cheat sheet of swaps you should make whenever you're reading the text of [RFC6282] and [RFC7400] 📝

in general, you should make these substitutions:

Replace "802.15.4" with "G.9959".
Replace "802.15.4 short address" with "<Interface><G.9959 NodeID>".
Replace "802.15.4 PAN ID" with "G.9959 HomeID".

when a 16-bit address is called for (aka an IEEE 802.15.4 "short address") 🧚 it MUST be built by sticking an Interface label byte in front of the G.9959 NodeID 🔥 picture it like this:

                   0                   1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |   Interface   |    NodeID     |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

a transmitting node might be sending to an IPv6 destination address that the receiver can rebuild from the link-layer destination address 🦋 if the Interface number is zero (which is the default 💜) all the IPv6 address bytes may be elided ✂️ and the other way round: a receiving node can rebuild the Interface number of a fully elided IPv6 address (that's SAM/DAM=11) as zero 🌈

the 64-bit 802.15.4 address details just don't apply here, bestie 🙅‍♀️

6. Security Considerations 💀

okay this one is SERIOUS, so grab a snack 🍓 the way Interface Identifiers get derived from 8-bit NodeIDs does keep them unique inside the network ✅ BUT there's zero protection against duplication through forgery 😭 Neighbor Discovery on G.9959 links may be vulnerable to the threats laid out in [RFC3756] 🙈 and G.9959 networks can do mesh routing, which brings extra ad hoc routing threats as described in [KW03] 🕸️

G.9959 does come with link-layer security built in 🔐 and G.9959 nodes MUST use link-layer security with a shared key 🔑 doing that takes care of most of the threats listed above, so it's a huge deal 🫶 a big chunk of G.9959 devices are expected to always talk within their PAN (aka their subnet, if we're speaking IPv6) 🏠 since cost and power use matter so much to them, these devices will usually only implement the bare-minimum set of features 🪫 so their security can lean on the link-layer mechanisms G.9959 defines 💖 G.9959 uses the Advanced Encryption Standard (AES) for authenticating and encrypting frames, and it also uses challenge-response handshaking to stop replay attacks 🛡️

some G.9959 devices (think billing and/or safety-critical products 🚨) are also expected to handle coordination or integration jobs 🎀 those might regularly talk to IPv6 peers outside the subnet 🌍 those IPv6 devices are expected to lock down their end-to-end traffic with standard security mechanisms, like IPsec, Transport Layer Security (TLS), and so on 🔒✨

7. Privacy Considerations 🦋

IP addresses can be used to track devices across the Internet 👀 and those devices can then be tied back to real people and what they get up to 😬 depending on the application and how it's actually used, that might not be ideal 💭 so to slow down tracking, you should avoid globally unique, non-changing bits of IP addresses 🌸 for example, you can keep changing the global prefix and skip IIDs derived from the link-layer address 🔄

some link layers use a 48-bit or 64-bit link-layer address that uniquely identifies a node globally, even when the global prefix changes 🌐 the risk of exposing a G.9959 device through a link-layer-derived IID is pretty low, because its link-layer address is only 8 bits short 🙌

DHCPv6 address assignment is meant for central address management, but it also decouples the IPv6 address from the link-layer address 🧩 addresses can be made dynamic with a short DHCP lease period plus an assignment policy where the DHCP server hands out a fresh IP address every single time 🔁 for extra privacy, DHCP-assigned addresses should only be logged for the length of the lease, as long as the implementation still allows logging for longer durations according to the operational policies 📋

heads up: privacy and constantly changing addresses come with a cost 💸 non-link-layer-derived IIDs need address registration 📝 they also can't be compressed, which means longer datagrams and more link-layer segmentation 📦 and frequent prefix changes mean more Context Identifier updates, which not only adds traffic but can also hurt the battery life of sleeping nodes 🪫

8. References 📚

8.1. Normative References

[G.9959] International Telecommunication Union, "Short range narrow-band digital radiocommunication transceivers - PHY and MAC layer specifications", ITU-T Recommendation G.9959, January 2015, <http://www.itu.int/rec/T-REC-G.9959>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.

[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.

[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 2011, <http://www.rfc-editor.org/info/rfc6355>.

[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012, <http://www.rfc-editor.org/info/rfc6775>.

[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, November 2014, <http://www.rfc-editor.org/info/rfc7400>.

8.2. Informative References

[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64TM)", November 2012, <http://standards.ieee.org/regauth/oui/tutorials/EUI64.html>.

[KW03] Karlof, C. and D. Wagner, "Secure Routing in Sensor Networks: Attacks and Countermeasures", Elsevier Ad Hoc Networks Journal, Special Issue on Sensor Network Applications and Protocols, vol. 1, issues 2-3, September 2003.

[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, <http://www.rfc-editor.org/info/rfc3315>.

[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003, <http://www.rfc-editor.org/info/rfc3587>.

[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004, <http://www.rfc-editor.org/info/rfc3756>.

[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, <http://www.rfc-editor.org/info/rfc3819>.

[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012, <http://www.rfc-editor.org/info/rfc6550>.

[RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. Martocci, "Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks", RFC 6997, August 2013, <http://www.rfc-editor.org/info/rfc6997>.

Appendix A. G.9959 6LoWPAN Datagram Example ✨

okay so this appendix is a full walkthrough 🧚 of one sample IPv6 UDP packet. it starts at a host on the Internet, goes through a PAN border router, and lands on a G.9959 node, and we go bit by bit the whole way. it's giving textbook, but make it cute 🎀

In the G.9959 PAN, the complete frame has the following fields:

G.9959:

  +------+---------+----------+---+-----+----------...
  |HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID|
  +------+---------+----------+---+-----+----------+-...

6LoWPAN:

  ...+--------------+----------------+-----------------------...
     |6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers|
    ...-------------+----------------+-----------------------+-...

IPv6, TCP/UDP, App payload:

    ...+-------------------------+------------+-----------+
       |Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload|
      ...------------------------+------------+-----------+

so the frame comes from the source IPv6 address 2001:0db8:ac10:ef01::ff:fe00:1206 💅. the source prefix 2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3 🌸

the frame is delivered in direct range from the gateway that has source NodeID = 1. the Interface Identifier (IID) ff:fe00:1206 is recognized as a link-layer-derived address, and it gets compressed down to the 16-bit value 0x1206 ✨

the frame is sent to the destination IPv6 address 2001:0db8:27ef:42ca::ff:fe00:0004. the destination prefix 2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2 🦋

the IID ff:fe00:0004 is recognized as a link-layer-derived address too 💜

thanks to those link-layer-derived addressing rules, the sender knows this is going to G.9959 NodeID = 4, targeting IPv6 interface instance number 0 (the default). iconic, honestly 👑

to reach the 6LoWPAN stack of the G.9959 node (skipping the G.9959 header fields), the first octet has to be the 6LoWPAN Command Class 0x4F 🫶

     0
     0 1 2 3 4 5 6 7 8
    +-+-+-+-+-+-+-+-+-...
    |     0x4F      |
    +-+-+-+-+-+-+-+-+-...

next up, the Dispatch Header bits 011 advertise a compressed IPv6 header 🌈

     0                   1
     0 1 2 3 4 5 6 7 8 9 0
    +-+-+-+-+-+-+-+-+-+-+-...
    |     0x4F      |0 1 1
    +-+-+-+-+-+-+-+-+-+-+-+-...

then the following bits encode the first IPv6 header fields. this part is so satisfying 😭

TF = '11'   : Traffic Class and Flow Label are elided
NH = '1'    : Next Header is elided
HLIM = '10' : Hop limit is 64

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
     |     0x4F      |0 1 1 1 1 1 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

and now the address compression bits 🍓

CID = '1'   : CI data follows the DAM field
SAC = '1'   : Src addr uses stateful, context-based compression
SAM = '10'  : Use src CID and 16 bits for link-layer-derived addr
M = '0'     : Dest addr is not a multicast addr
DAC = '1'   : Dest addr uses stateful, context-based compression
DAM = '11'  : Use dest CID and dest NodeID to link-layer-derived addr

     0                   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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
    |     0x4F      |0 1 1 1 1 1 1 0|1 1 1 0 0 1 1 1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

the address compression context identifiers are:

SCI =  0x3
DCI =  0x2

       2           3
       4 5 6 7 8 9 0 1
   ...+-+-+-+-+-+-+-+-...
      |  0x3  |  0x2  |
     ...+-+-+-+-+-+-+-+-...

for the IPv6 header fields, we skip "version", "Traffic Class", "flow label", and "payload length" 🙈

(skipping "version" field)
(skipping "Traffic Class")
(skipping "flow label")
(skipping "payload length")

the IPv6 header address fields are:

SrcIP = 0x1206 : Use SCI and 16 least significant bits of
link-layer-derived address

(skipping DestIP ) - completely reconstructed from dest NodeID
                     and DCI

       2           3                   4
       4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
   ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
      |  0x3  |  0x2  |     0x12      |     0x06      |
     ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

next is the Next Header encoding for the UDP header, which is giving main character energy 🦋

Dispatch = '11110': Next Header dispatch code for UDP header
C =      '0'      : 16-bit checksum carried inline
P =      '00'     : Both src port and dest port are carried in-line

      4   5
      8 9 0 1 2 3 4 5
  ...+-+-+-+-+-+-+-+-...
     |1 1 1 1 0|0|0 0|
    ...+-+-+-+-+-+-+-+-...

and the UDP header fields are:

src port  = 0x1234
dest port = 0x5678

 5       6                   7                   8
 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 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
   |     0x12      |     0x34      |     0x56      |     0x78      |
  ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..

we skip "length" 🙃, and the checksum is .... (the actual checksum value depends on the actual UDP payload)

                                1
       8   9                   0
       8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
      |         (UDP checksum)        |
     ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

and that's the whole journey! 🎉 the last note in the original says "Add your own UDP payload here...", so go ahead and add yours 💖

Acknowledgements 🫶

thanks to the authors of RFC 4944 and RFC 6282, plus the members of the IETF 6LoWPAN working group. this document borrows extensively from their work 😭💜

thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn, Michael Richardson, and Tommas Jess Christensen for useful comments 🌸

thanks to Carsten Bormann for extensive feedback that improved this document significantly 👑

and thanks to Brian Haberman for pointing out unclear details 🧚

Authors' Addresses 💅

Anders Brandt
Sigma Designs
Emdrupvej 26A, 1.
Copenhagen O  2100
Denmark

EMail: anders_brandt@sigmadesigns.com

Jakob Buron
Sigma Designs
Emdrupvej 26A, 1.
Copenhagen O  2100
Denmark

EMail: jakob_buron@sigmadesigns.com

📦 where this page comes from

ietf: rfc7428 2015-02
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms