RFC 8105

Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)

📅 published May 2017, from ietf

RFC 8105: Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) 🎀

okay so this one is the IETF's Request for Comments 8105 🦋, and it came out in May 2017. It's a Standards Track doc, so it's official, not just vibes. The ISSN is 2070-1721. The authors are P. Mariager, J. Petersen (who is the editor, so Ed.), Z. Shelby, M. van de Logt, and D. Barthel 💖. Mariager and Petersen are at RTX A/S, Shelby is at ARM, van de Logt is at Bosch Sensortec GmbH, and Barthel is at Orange Labs. The title block doesn't list any RFCs that this one obsoletes or updates, so it's not replacing or patching anything else 🧚.

Abstract ✨

Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology. The DECT Forum proposed it, and ETSI defined and specified it 🔋.

DECT has been used around the world in communication devices for more than 20 years 🌍. It mostly carried voice for cordless phones, but it's also been deployed for data-centric services 📞.

DECT ULE is the newer addition to the DECT interface, and it's built for low-bandwidth, low-power stuff like sensor devices, smart meters, home automation, etc. 🏠 Because it inherits a lot of DECT's abilities, it gets long range, interference-free operation, a worldwide-reserved frequency band, low silicon prices, and maturity. Being able to talk IPv6 over DECT ULE is a big bonus, especially for Internet of Things applications 🌸.

This document describes how IPv6 gets transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques 💜.

Status of This Memo

This is an Internet Standards Track document 🎀.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨. For more on Internet Standards, check Section 2 of RFC 7841 📚.

For the current status of this document, any errata, and how to give feedback on it, go to http://www.rfc-editor.org/info/rfc8105 🔗.

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 🩷.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these documents carefully, because they describe your rights and restrictions with respect to this document 📜. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💅.

Table of Contents 🗂️

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   5
     1.2.  Terms Used  . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . .   6
     2.1.  The DECT ULE Protocol Stack . . . . . . . . . . . . . . .   6
     2.2.  Link Layer Roles and Topology . . . . . . . . . . . . . .   8
     2.3.  Addressing Model  . . . . . . . . . . . . . . . . . . . .   8
     2.4.  MTU Considerations  . . . . . . . . . . . . . . . . . . .   9
     2.5.  Additional Considerations . . . . . . . . . . . . . . . .   9
   3.  Specification of IPv6 over DECT ULE . . . . . . . . . . . . .   9
     3.1.  Protocol Stack  . . . . . . . . . . . . . . . . . . . . .  10
     3.2.  Link Model  . . . . . . . . . . . . . . . . . . . . . . .  11
     3.3.  Subnets and Internet Connectivity Scenarios . . . . . . .  15
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   6.  ETSI Considerations . . . . . . . . . . . . . . . . . . . . .  18
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1. Introduction ✨

Okay bestie, let's get into it 💖.

Digital Enhanced Cordless Telecommunications (DECT) is a standard series, [EN300.175-part1-7], specified by ETSI 📘. CAT-iq (Cordless Advanced Technology - internet and quality) is a set of product certification and interoperability profiles, [CAT-iq], defined by DECT Forum 🩵. DECT Ultra Low Energy (DECT ULE, or just ULE) is an air interface technology that builds on the core basics of traditional DECT/CAT-iq. The big change is that it cuts power consumption way down, and the tradeoff is less data throughput 🔋. DECT ULE devices with power consumption requirements, as specified by ETSI in [TS102.939-1] and [TS102.939-2], run on special power-optimized silicon. They can still connect to a DECT Gateway that supports traditional DECT/CAT-iq for cordless telephony and data, plus the ULE extensions 🌸.

So DECT has two main roles 🎀. The Portable Part (PP) is the power-constrained device, and the Fixed Part (FP) is the Gateway or base station. The FP is allowed to connect to the Internet 🌐. Picture a home-security sensor that sends tiny bits of data (a few bytes) at regular intervals through the FP. It can also wake up when something external happens (like a break-in) and talk to the FP 🚨. Another example mixes DECT ULE with traditional CAT-iq telephony: a pendant (brooch) for the elderly that sends periodic status messages to a care provider on very little battery. If there's an emergency, the person can set up a voice connection through the pendant to an alarm service 🆘. DECT ULE is expected to get built into lots of residential gateways, since many of them already do DECT CAT-iq for cordless telephony 🏡. DECT ULE can also be added as a software option for the FP 💅.

IPv6 is really desirable for DECT ULE devices because of its huge address space and well-known infrastructure 🌈. This document explains how IPv6 gets used on DECT ULE links to optimize power while still keeping all the perks of IPv6 transmission 💜. [RFC4944], [RFC6282], and [RFC6775] specify the transmission of IPv6 over IEEE 802.15.4 🧚. DECT ULE has a lot of traits in common with IEEE 802.15.4, but it also has its own differences 🫶. Some of the mechanisms defined for sending IPv6 over IEEE 802.15.4 can be applied to sending IPv6 on DECT ULE links ✨.

This document specifies how to map IPv6 over DECT ULE, inspired by [RFC4944], [RFC6282], [RFC6775], and [RFC7668] 🦋.

1.1. Requirements Notation 🎀

Here's the fine print. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📏.

1.2. Terms Used 💅

These are the acronyms and terms you'll see throughout, so bookmark this one bestie 🔖.

   6CO      6LoWPAN Context Option [RFC6775]
   6BBR     6loWPAN Backbone Router
   6LBR     6LoWPAN Border Router, as defined in [RFC6775].
            The DECT Fixed Part has this role.
   6LN      6LoWPAN Node as defined in [RFC6775].
            The DECT Portable Part has this role
   6LoWPAN  IPv6 over Low-Power Wireless Personal Area Network
   AES128   Advanced Encryption Standard with a key size of 128 bits
   API      Application Programming Interface
   ARO      Address Registration Option [RFC6775]
   CAT-iq   Cordless Advanced Technology - internet and quality
   CID      Context Identifier [RFC6775]
   DAC      Destination Address Compression
   DAD      Duplicate Address Detection [RFC4862]
   DAM      Destination Address Mode
   DHCPv6   Dynamic Host Configuration Protocol for IPv6 [RFC3315]
   DLC      Data Link Control
   DSAA2    DECT Standard Authentication Algorithm #2
   DSC      DECT Standard Cipher
   DSC2     DECT Standard Cipher #2
   FDMA     Frequency-Division Multiple Access
   FP       DECT Fixed Part; the Gateway
   GAP      Generic Access Profile
   IID      Interface Identifier
   IPEI     International Portable Equipment Identity; DECT identity
   MAC-48   48-bit global unique MAC address managed by IEEE
   MAC      Media Access Control
   MTU      Maximum Transmission Unit
   NBMA     Non-Broadcast Multi-Access
   ND       Neighbor Discovery [RFC4861] [RFC6775]
   PDU      Protocol Data Unit
   PHY      Physical Layer
   PMID     Portable MAC Identity; DECT identity
   PP       DECT Portable Part; typically the sensor node (6LN)
   PVC      Permanent Virtual Circuit
   RFPI     Radio Fixed Part Identity; DECT identity
   SAC      Source Address Compression
   SAM      Source Address Mode
   TDD      Time Division Duplex
   TDMA     Time-Division Multiple Access
   TPUI     Temporary Portable User Identity; DECT identity
   UAK      User Authentication Key; DECT master security key
   ULA      Unique Local Address [RFC4193]

2. DECT Ultra Low Energy 🦋

DECT ULE is giving low-power air interface energy 🔋💜. It's designed to support both circuit-switched services, like voice calls, and packet-mode data services at a modest data rate 📡. This document only covers the packet-mode data service of DECT ULE 💖.

2.1. The DECT ULE Protocol Stack ✨

okay so the DECT ULE Protocol Stack has a PHY layer that operates at frequencies in the 1880 - 1920 MHz frequency band 📡, depending on the region, and it uses a symbol rate of 1.152 Mbaud. Radio bearers get allocated using FDMA/TDMA/TDD techniques 🎀.

In its generic network topology, DECT is defined as a cellular network technology. The most common setup, though, is a star network 🌟 with a single FP defining the network and a bunch of PPs attached. The MAC layer supports both traditional DECT circuit mode operation (used for stuff like discovery, pairing, security features, etc.) and the new ULE packet-mode operation 💖. The circuit-mode features were reused from DECT, so iykyk 🙈.

The DECT ULE device can switch to the ULE mode of operation and use the new ULE MAC layer features 🦋. The DECT ULE Data Link Control (DLC) gives you multiplexing, plus segmentation and reassembly for larger packets coming from the layers above. The DECT ULE layer also does per-message authentication and encryption 🔐. The DLC layer keeps packet integrity and preserves packet order, but delivery is based on best effort, so there are no delivery guarantees there 💀.

The current DECT ULE MAC layer standard supports low-bandwidth data broadcast. However, this document is not considering usage of the DECT ULE MAC layer broadcast service for IPv6 over DECT ULE 🙅‍♀️.

In general, communication sessions can be started from both the FP side and the PP side. Depending on the power-down modes used in the PP, latency may happen when starting sessions from the FP side 😭. MAC layer communication can use either connection-oriented packet transfer (low overhead, for short sessions) or connection-oriented bearers that include media reservation. The MAC layer picks the radio-spectrum positions that are available within the band on its own, and it can rearrange them to avoid interference 🌈. It also has built-in retransmission procedures to improve transmission reliability 💪.

The DECT ULE device will typically include an Application Programming Interface (API), plus common elements called Generic Access Profiles (GAPs) for enrolling into the network. The DECT ULE Stack sets up a Permanent Virtual Circuit (PVC) for the application layers and supports a range of different application protocols. The application protocol gets negotiated between the PP and FP when the PVC communication service is established. [TS102.939-1] defines this negotiation and specifies an Application Protocol Identifier set to 0x06 for 6LoWPAN. This document defines the behavior of that application protocol 👑.

              +----------------------------------------+
              |          Application Layers            |
              +----------------------------------------+
              | Generic Access     |     ULE Profile   |
              |       Profile      |                   |
              +----------------------------------------+
              | DECT/Service API   | ULE Data API      |
              +--------------------+-------------------+
              | LLME  | NWK (MM,CC)|                   |
              +--------------------+-------------------+
              | DECT DLC           | DECT ULE DLC      |
              +--------------------+-------------------+
              |                MAC Layer               |
              +--------------------+-------------------+
              |                PHY Layer               |
              +--------------------+-------------------+
                    (C-plane)             (U-plane)

Figure 1: DECT ULE Protocol Stack

Figure 1 shows the DECT ULE Stack split into the Control Plane (C-plane) and User Data Plane (U-plane), to the left and to the right, respectively. The entities shown in the Stack are the Physical Layer (PHY), Media Access Control (MAC) Layer, Data Link Control (DLC) Layer, and Network Layer (NWK), along with these subcomponents: Lower-Layer Management Entity (LLME), Mobility Management (MM), and Call Control (CC). Above those sit the typical Application Programmers Interface (API) and the application-profile-specific layers 🧚.

An FP is assumed to be less constrained than a PP. So, in the primary scenario, the FP and PP will act as 6LBR and a 6LN, respectively. This document only addresses this primary scenario, and all other scenarios with different roles for an FP and PP are out of scope 🎯.

In DECT ULE, at the link layer, communication only happens between an FP and a PP. An FP can handle multiple simultaneous connections with a number of PPs. That means that in a DECT ULE network using IPv6, a radio hop is equivalent to an IPv6 link, and vice versa (see Section 3.3) 🔗✨.

       [DECT ULE PP]-----\                 /-----[DECT ULE PP]
                          \               /
       [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]
                          /               \
       [DECT ULE PP]-----/                 \-----[DECT ULE PP]

Figure 2: DECT ULE Star Topology

A big difference between IEEE 802.15.4 and DECT ULE is this: the former supports both star and mesh topology (and requires a routing protocol), whereas DECT ULE in its primary configuration does not support forming multihop networks at the link layer. As a result, the mesh header defined in [RFC4944] is not used in DECT ULE networks 🙃.

DECT ULE repeaters are considered to operate transparently in the DECT protocol domain, and they are outside the scope of this document 🌸.

2.3. Addressing Model

Each DECT PP is assigned an IPEI during manufacturing. This identity is 40 bits in size and is globally unique within the DECT addressing space. It can be used to build the MAC address that gets used to derive the IID for the link-local address 🪪.

During a DECT location registration procedure, the FP assigns a 20-bit TPUI to a PP. The FP creates a unique mapping between the assigned TPUI and the IPEI of each PP. This TPUI is used for addressing (Layer 2) in messages between the FP and PP. The TPUI is temporary by definition, but many implementations assign the same value over and over to any given PP. So it seems not suitable for constructing the IID (see [RFC8065]) 🙈.

Each DECT FP is assigned an RFPI during manufacturing. This identity is 40 bits in size and is globally unique within the DECT addressing space. It can be used to build the MAC address that gets used to derive the IID for the link-local address 💜.

Optionally, each DECT PP and DECT FP can be assigned a unique (IEEE) MAC-48 address in addition to the DECT identities, to be used by the 6LoWPAN. During the address registration of non-link-local addresses as specified by this document, the FP and PP can use such a MAC-48 to construct the IID. However, because these addresses are considered permanent, such a scheme is NOT RECOMMENDED as per [RFC8065] 🚫.

2.4. MTU Considerations

Ideally, the DECT ULE FP and PP may generate data that fits into a single MAC layer packet (38 octets) for periodically transferred information, depending on the application. However, IP packets may be much larger. The DECT ULE DLC procedures natively support segmentation and reassembly and provide any MTU size below 65536 octets. The default MTU size defined in DECT ULE [TS102.939-1] is 500 octets. To support complete IPv6 packets, the DLC layer of DECT ULE SHALL, per this specification, be configured with an MTU size of 1280 octets, so [RFC4944] fragmentation/reassembly is not required 🧩.

It is important to realize that using larger packets will cost you battery life 🔋. A large packet inside the DECT ULE Stack gets fragmented into several (or many) MAC layer packets, and each one consumes power to transmit and receive. The increased MTU size does not change the MAC layer packet and PDU size.

2.5. Additional Considerations

The DECT ULE standard allows the PP to be DECT-registered (bound) to multiple FPs and to roam between them. These FPs and their 6LBR functionalities can operate either individually or connected through a Backbone Router as per [BACKBONE-ROUTER] 🌐.

3. Specification of IPv6 over DECT ULE

Before any IP-layer communication can take place over DECT ULE, DECT-ULE-enabled nodes such as 6LNs and 6LBRs have to find each other and establish a suitable link layer connection. The obtain-access-rights registration and location registration procedures are documented by ETSI in the specifications [EN300.175-part1-7], [TS102.939-1], and [TS102.939-2] 📜.

DECT ULE technology sets strict requirements for low power consumption, and thus it limits the allowed protocol overhead. The 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provide useful functionality for reducing overhead that can be applied to DECT ULE. This functionality comprises link-local IPv6 addresses, stateless IPv6 address autoconfiguration, Neighbor Discovery, and header compression 🦋.

The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC layer. Figure 3 illustrates an IPv6 over DECT ULE Stack.

Because DECT ULE in its primary configuration does not support forming multihop networks at the link layer, the mesh header defined in [RFC4944] for mesh under routing MUST NOT be used. In addition, the role of a 6LoWPAN Router (6LR) is not defined per this specification 🚧.

3.1. Protocol Stack

To enable data transmission over DECT ULE, a Permanent Virtual Circuit (PVC) has to be configured and opened between the FP and PP. This is done by setting up a DECT service call between the PP and FP. In the DECT protocol domain, the PP SHALL specify the <<IWU-ATTRIBUTES>> in a service-change (other) message before sending a service-change (resume) message, as defined in [TS102.939-1]. The <<IWU-ATTRIBUTES>> SHALL set the ULE Application Protocol Identifier to 0x06 and the MTU size to 1280 octets or larger. The FP sends a service-change-accept (resume) that MUST contain a valid paging descriptor. The PP MUST listen to paging messages from the FP according to the information in the received paging descriptor. After this, transmission of IPv6 packets can start 🎀✨.

                     +-------------------+
                     |    UDP/TCP/other  |
                     +-------------------+
                     |       IPv6        |
                     +-------------------+
                     |6LoWPAN adapted to |
                     |    DECT ULE       |
                     +-------------------+
                     |  DECT ULE DLC     |
                     +-------------------+
                     |  DECT ULE MAC     |
                     +-------------------+
                     |  DECT ULE PHY     |
                     +-------------------+

Figure 3: IPv6 over DECT ULE Stack

okay so the big picture is: IPv6 is Layer 3, and DECT ULE MAC and DECT ULE DLC are Layer 2. 💅 DECT ULE already does fragmentation and reassembly on its own, so the one from [RFC4944] MUST NOT be used. no double-doing it bestie 🙅‍♀️

once the FPs and PPs have connected at the DECT ULE level, the link can be considered up 🎉 and that's when IPv6 address configuration and transmission can begin. the 6LBR makes sure address collisions do not occur, so it's the responsible one 👑

per this specification, the IPv6 header compression format in [RFC6282] MUST be used 🎀. the IPv6 payload length can be derived from the ULE DLC packet length, and the possibly elided IPv6 address can be rebuilt from the lower layer address (see Section 3.2.4) 🧚

now the lowkey tricky part 😭. because of the DECT ULE star topology (see Section 2.2), every PP has its own separate link to the FP. so the PPs cannot directly hear one another and cannot talk to one another. 🙈 as discussed in [RFC4903], normal IPv6 usage expects subnets to span a single link at the link layer. but making a separate subnet for every DECT ULE link would be a whole mess, so the designers picked a Multi-Link Subnet model [RFC4903], specifically Non-Broadcast Multi-Access (NBMA) at Layer 2 🌸. the consequence is that link-local multicast can only happen inside a single DECT ULE connection, so 6LN-to-6LN communication using link-local addresses is not possible. 6LNs connected to the same 6LBR have to talk to each other using the shared prefix on the subnet, and the 6LBR forwards packets sent by one 6LN to another. it's giving middleman energy 🦋

3.2.1. Stateless Address Autoconfiguration 💖

at network interface initialization, both 6LN and 6LBR SHALL generate and assign IPv6 link-local addresses to the DECT ULE network interfaces [RFC4862]. they're based on the DECT device addresses (see Section 2.3) that were used to set up the underlying DECT ULE connection 🔥

the DECT device addresses IPEI and RFPI MUST be used to derive the IPv6 link-local 64-bit Interface Identifiers (IIDs) for 6LN and 6LBR, respectively 🫶

here's the rule for turning DECT device addresses into IIDs. any DECT device address that is 40 bits MUST be expanded with leading zero bits to form a 48-bit intermediate address 🧮. the most significant bit of that new 48-bit intermediate address is set to one for addresses derived from the RFPI, and set to zero for addresses derived from the IPEI. then the 64-bit IIDs come from these intermediate 48-bit addresses, following the guidance in Appendix A of [RFC4291] ✨. BUT (this is the plot twist 😭) DECT and IEEE address spaces are different, so this intermediate address cannot be considered unique within an IEEE address space. in the derived IIDs, the Universal/Local (U/L) bit (7th bit) will be zero, which means the derived IIDs are not globally unique, see [RFC7136] 🙃. for example, from RFPI=11.22.33.44.55 the derived IID is 80:11:22:ff:fe:33:44:55, and from IPEI=01.23.45.67.89 the derived IID is 00:01:23:ff:fe:45:67:89 💜

global uniqueness of an IID in link-local addresses is not required, because they should never be leaked outside the subnet domain 🤫

as defined in [RFC4291], the IPv6 link-local address is made by sticking the IID onto the prefix FE80::/64, as shown in Figure 4 🌈

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

           Figure 4: IPv6 Link-Local Address in DECT ULE

a 6LN MUST join the all-nodes multicast address 🧚‍♀️.

after link-local address configuration, the 6LN sends Router Solicitation messages as described in Section 6.3.7 of [RFC4861] and Section 5.3 of [RFC6775] 📣.

for non-link-local addresses, 6LNs SHOULD NOT be configured to use IIDs derived from a MAC-48 device address or DECT device addresses 🙅‍♀️. the better options are things like Cryptographically Generated Addresses (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque addresses [RFC7217], and those SHOULD be used by default 💅. see also [RFC8065] for guidance on the entropy needed in IIDs and the recommended lifetime of used IIDs 🍓. when generated IIDs are not globally unique, Duplicate Address Detection (DAD) [RFC4862] MUST be used 🔍. if deployment constraints mean the device's address has to be embedded in the IID, the 6LN MAY form a 64-bit IID by using the MAC-48 device address or DECT device addresses 🎀. the non-link-local addresses a 6LN generates MUST be registered with the 6LBR as described in Section 3.2.2 📝.

the way a 6LBR gets an IPv6 prefix for numbering the DECT ULE network is out of scope for this document 🙆‍♀️. but a prefix can be assigned, for example, via DHCPv6 Prefix Delegation [RFC3633] or by using IPv6 Unicast Unique Local Addresses (ULAs) [RFC4193] 🌸. because of the DECT ULE link model, the 6LBR MUST set the "on-link" (L) flag to zero in the Prefix Information Option [RFC4861] 🚫. this makes 6LNs always send packets to the 6LBR, even when the destination is another 6LN using the same prefix 🔁.

3.2.2. Neighbor Discovery 🫧

"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] describes the Neighbor Discovery approach as adapted for several 6LoWPAN topologies, including the mesh topology. but DECT ULE doesn't support mesh networks, so only the parts of [RFC6775] that apply to star topology are considered 🌟.

these are the Neighbor Discovery optimization [RFC6775] aspects that apply to DECT ULE 6LNs 💜:

  1. for sending Router Solicitations and processing Router Advertisements, the DECT ULE 6LNs MUST, respectively, follow Sections 5.3 and 5.4 of [RFC6775] 📮.
  2. a DECT ULE 6LN MUST NOT register its link-local address. the IIDs used in link-local addresses are derived from DECT addresses, so there will always be a unique mapping between link-local and Layer 2 addresses 🧷.
  3. a DECT ULE 6LN MUST register its non-link-local addresses with the 6LBR by sending a Neighbor Solicitation (NS) message with the Address Registration Option (ARO), and then process the Neighbor Advertisement (NA) accordingly 🤝. the NS with the ARO option MUST be sent irrespective of the method used to generate the IID 🙌.

3.2.3. Unicast and Multicast Address Mapping 🦋

the DECT MAC layer broadcast service is considered inadequate for IP multicast, because it does not support the MTU size IPv6 requires 🙅‍♀️.

so traffic is always unicast between two DECT ULE nodes 💌. even when a 6LBR is attached to multiple 6LNs, the 6LBR cannot do a multicast to all of the connected 6LNs. if the 6LBR needs to send a multicast packet to all its 6LNs, it has to replicate the packet and unicast it on each link 😩. this may not be energy efficient, so particular care should be taken if the FP is battery-powered 🔋. to save even more power, the 6LBR MUST keep track of multicast listeners at DECT ULE link-level granularity, and it MUST NOT forward multicast packets to 6LNs that have not registered for the multicast groups those packets belong to 🧠✨.

in the other direction, a 6LN can only transmit data to or through the 6LBR. so when a 6LN needs to transmit an IPv6 multicast packet, it unicasts the corresponding DECT ULE packet to the 6LBR, and then the 6LBR forwards the multicast packet to the other 6LNs 🎀.

3.2.4. Header Compression 🗜️

as defined in [RFC6282], which specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4, header compression is REQUIRED in this document as the basis for IPv6 header compression on top of DECT ULE 👑. all headers MUST be compressed according to the encoding formats described in [RFC6282] 📦. the DECT ULE star topology, ARO and 6CO can be exploited to provide a mechanism for address compression 🌈. the following text describes the principles of IPv6 address compression on top of DECT ULE 💖.

in a link-local communication terminated at 6LN and 6LBR, both the IPv6 source and destination addresses MUST be elided, because the IIDs used map uniquely to the DECT link end-point addresses 🧩. a 6LN or 6LBR that receives a PDU containing an IPv6 packet can infer the corresponding IPv6 source address 🔮. for the unicast type of communication covered in this paragraph, the following settings MUST be used in the IPv6 compressed header: CID=0, SAC=0, SAM=11, DAC=0, and DAM=11 🎯.

to enable efficient header compression, the 6LBR MUST include the 6LoWPAN Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises in Router Advertisements for use in stateless address autoconfiguration 📋.

when a 6LN transmits an IPv6 packet to a destination using global unicast IPv6 addresses, and a context is defined for the prefix of the 6LN's global IPv6 address, the 6LN MUST indicate this context in the corresponding source fields of the compressed IPv6 header as per Section 3.1 of [RFC6282] 🗂️. it MUST also fully elide the latest registered IPv6 source address 🫥. for this, the 6LN MUST use the following settings in the IPv6 compressed header: CID=1, SAC=1, and SAM=11 🎀. in this case, the 6LBR can infer the elided IPv6 source address since 1) the 6LBR has previously assigned the prefix to the 6LNs, and 2) the 6LBR maintains a Neighbor Cache that relates the device address and the IID of the corresponding PP 🕵️‍♀️. if a context is defined for the IPv6 destination address, the 6LN MUST also indicate this context in the corresponding destination fields of the compressed IPv6 header, and MUST elide the prefix of the destination IPv6 address 🪄. for this, the 6LN MUST set the DAM field of the compressed IPv6 header as CID=1, DAC=1, and DAM=01 or DAM=11 ✨. note that when a context is defined for the IPv6 destination address, the 6LBR can infer the elided destination prefix by using the context 🧠.

when a 6LBR receives an IPv6 packet with a global unicast IPv6 address, and the packet's destination is a 6LN, and a context is defined for the prefix of the 6LN's global IPv6 address, the 6LBR MUST indicate this context in the corresponding destination fields of the compressed IPv6 header 📬. it MUST fully elide the IPv6 destination address of the packet if the destination address is the latest one registered by the 6LN for the indicated context 💫. for this, the 6LBR MUST set the DAM field of the IPv6 compressed header as DAM=11 🎯. CID and DAC MUST be set to CID=1 and DAC=1 🌸. if a context is defined for the prefix of the IPv6 source address, the 6LBR MUST indicate this context in the source fields of the compressed IPv6 header and MUST elide that prefix as well 🫶. for this, the 6LBR MUST set the SAM field of the IPv6 compressed header as CID=1, SAC=1, and SAM=01 or SAM=11 💜.

3.3. Subnets and Internet Connectivity Scenarios

okay bestie, let's talk about how the DECT ULE network is laid out 🦋 In the star topology (see Section 2.2), every PP gets its own separate link to the FP, and the FP acts as an IPv6 router instead of a link layer switch 💅 We went with a Multi-Link Subnet model [RFC4903], specifically Non-Broadcast Multi-Access (NBMA) at Layer 2 🌸, which Figure 5 shows. The 6LBR forwards packets sent by one 6LN to another 💖 In a typical setup, the DECT ULE network connects to the Internet like in Figure 5. Here the whole DECT ULE network is one subnet using one /64 IPv6 prefix ✨ The 6LBR acts as a router and forwards packets between 6LNs and to and from the Internet 👑

                          6LN
                           \               ____________
                            \             /            \
                    6LN ---- 6LBR ------ |  Internet    |
                            /             \____________/
                           /
                          6LN

                <--  One subnet -->
                <--   DECT ULE  -->

           Figure 5: DECT ULE Network Connected to the Internet

Sometimes the DECT ULE network is transiently or permanently an isolated network, as shown in Figure 6 🧚 In this case, the whole DECT ULE network is a single subnet with multiple links, and the 6LBR is routing packets between 6LNs.

                         6LN      6LN
                          \      /
                           \    /
                    6LN --- 6LBR --- 6LN
                           /    \
                          /      \
                         6LN      6LN

                    <----  One subnet ---->
                    <------ DECT ULE ----->

                    Figure 6: Isolated DECT ULE Network

In the isolated network scenario, communications between 6LN and 6LBR can use IPv6 link-local methodology 🫶 But for communications between different PP, the FP has to act as 6LBR, number the network with a ULA prefix [RFC4193], and route packets between the PP. Main character energy from the FP, honestly 👑

Then there are the more advanced systems with multiple FPs and 6LBRs 🌈 Each DECT ULE FP makes up a wireless cell. The network can be configured as a Multi-Link Subnet, where the 6LN can operate within the same /64 subnet prefix in multiple cells, as shown in Figure 7. The FPs in such a scenario should behave as Backbone Routers (6BBR) as defined in [BACKBONE-ROUTER] 🔥

                           ____________
                          /            \
                         |  Internet    |
                          \____________/
                                |
                                |
                                |
                                |
                    6BBR/       |        6BBR/
           6LN ---- 6LBR -------+------- 6LBR ---- 6LN
                   /  \                   /  \
                  /    \                 /    \
                 6LN   6LN              6LN   6LN

     <------------------ One subnet ------------------>
     <-- DECT ULE Cell -->       <-- DECT ULE Cell -->

      Figure 7: Multiple DECT ULE Cells in a Single Multi-link Subnet

4. IANA Considerations ✨

This document does not require any IANA actions. Nothing to register here, bestie 🎀

5. Security Considerations 💀

This part is serious, so pay attention 🙈 The secure transmission of circuit mode services in DECT is based on the DSAA2 and DSC/DSC2 specifications developed by ETSI Technical Committee (TC) DECT and the ETSI Security Algorithms Group of Experts (SAGE).

DECT ULE communications are secured at the link layer (DLC) by encryption and per-message authentication through CCM (Counter with Cipher Block Chaining Message Authentication Code (CBC-MAC)) mode, similar to [RFC3610]. The underlying algorithm for providing encryption and authentication is AES128 🔐

The DECT ULE pairing procedure generates a master User Authentication Key (UAK). During the location registration procedure, or when the permanent virtual circuits are established, the session security keys are generated. Both the master authentication key and the session security keys are generated by use of the DSAA2 algorithm [EN300.175-part1-7], which uses AES128 as the underlying algorithm. Session security keys may be renewed regularly. The generated security keys (UAK and session security keys) are individual for each FP-PP binding, so all PPs in a system have different security keys. DECT ULE PPs do not use any shared encryption key ✨

Even though DECT ULE offers link layer security, it is still recommended to use secure transport or application protocols above 6LoWPAN 💅

From the privacy point of view, the IPv6 link-local address configuration described in Section 3.2.1 only reveals information about the 6LN to the 6LBR that the 6LBR already knows from the link layer connection 🦋 For non-link-local IPv6 addresses, by default, a 6LN SHOULD use a randomly generated IID, for example as discussed in [RFC8064], or use alternative schemes such as Cryptographically Generated Addresses (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBAs, [RFC5535]), or static, semantically opaque addresses [RFC7217] 🫶

6. ETSI Considerations 🌸

ETSI is standardizing a list of known application-layer protocols that can use the DECT ULE permanent virtual circuit packet data service. Each protocol is identified by a unique known identifier, which is exchanged in the service-change procedure as defined in [TS102.939-1]. The IPv6/6LoWPAN as described in this document is considered to be an application-layer protocol on top of DECT ULE. To provide interoperability between 6LoWPAN / DECT ULE devices, a common protocol identifier for 6LoWPAN is standardized by ETSI 🧚

The ETSI DECT ULE Application Protocol Identifier is set to 0x06 for 6LoWPAN [TS102.939-1] 💖

7. References 📚

7.1. Normative References

Here's the full normative reference list, copied exactly so nothing gets lost 🎀

   [EN300.175-part1-7]
              ETSI, "Digital Enhanced Cordless Telecommunications
              (DECT); Common Interface (CI); Part 1: Overview", European
              Standard, ETSI EN 300 175-1, V2.6.1, July 2015,
              <https://www.etsi.org/deliver/
              etsi_en/300100_300199/30017501/02.06.01_60/
              en_30017501v020601p.pdf>.

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

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <http://www.rfc-editor.org/info/rfc3633>.

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

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, 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,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <http://www.rfc-editor.org/info/rfc4941>.

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

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

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

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
              February 2014, <http://www.rfc-editor.org/info/rfc7136>.

   [TS102.939-1]
              ETSI, "Digital Enhanced Cordless Telecommunications
              (DECT); Ultra Low Energy (ULE); Machine to Machine
              Communications; Part 1: Home Automation Network (phase
              1)", Technical Specification, ETSI TS 102 939-1, V1.2.1,
              March 2015, <https://www.etsi.org/deliver/
              etsi_ts/102900_102999/10293901/01.02.01_60/
              ts_10293901v010201p.pdf>.

   [TS102.939-2]
              ETSI, "Digital Enhanced Cordless Telecommunications
              (DECT); Ultra Low Energy (ULE); Machine to Machine
              Communications; Part 2: Home Automation Network (phase
              2)", Technical Specification, ETSI TS 102 939-2, V1.1.1,
              March 2015, <https://www.etsi.org/deliver/
              etsi_ts/102900_102999/10293902/01.01.01_60/
              ts_10293902v010101p.pdf>.

7.2. Informative References

Acknowledgements ✨

Huge thank-you to the members of the IETF 6lo working group, bestie! 🫶 This document borrows liberally from their work, and honestly, it would not be this iconic without them. 👑

Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan, Pascal Thubert, Tatuya Jinmei, Dale Worley, and Robert Sparks also gave valuable feedback on this document, and we are so grateful. 💖

Authors' Addresses 🎀

The authors, and where to find them:

Peter B. Mariager
RTX A/S
Stroemmen 6
DK-9400 Noerresundby
Denmark

Email: pm@rtx.dk
Jens Toftgaard Petersen (editor)
RTX A/S
Stroemmen 6
DK-9400 Noerresundby
Denmark

Email: jtp@rtx.dk
Zach Shelby
ARM
150 Rose Orchard
San Jose, CA 95134
United States of America

Email: zach.shelby@arm.com
Marco van de Logt
Bosch Sensortec GmbH
Gerhard-Kindler-Str. 9
72770 Reutlingen
Germany

Email: marco.vandelogt@bosch-sensortec.com
Dominique Barthel
Orange Labs
28 chemin du Vieux Chene
38243 Meylan
France

Email: dominique.barthel@orange.com
📦 where this page comes from