diff options
Diffstat (limited to 'doc/rfc/rfc8105.txt')
| -rw-r--r-- | doc/rfc/rfc8105.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc8105.txt b/doc/rfc/rfc8105.txt new file mode 100644 index 0000000..7e4e5a8 --- /dev/null +++ b/doc/rfc/rfc8105.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Mariager +Request for Comments: 8105 J. Petersen, Ed. +Category: Standards Track RTX A/S +ISSN: 2070-1721 Z. Shelby + ARM + M. van de Logt + Bosch Sensortec GmbH + D. Barthel + Orange Labs + May 2017 + + + Transmission of IPv6 Packets over Digital Enhanced Cordless + Telecommunications (DECT) Ultra Low Energy (ULE) + +Abstract + + Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy + (ULE) is a low-power air interface technology that is proposed by the + DECT Forum and is defined and specified by ETSI. + + The DECT air interface technology has been used worldwide in + communication devices for more than 20 years. It has primarily been + used to carry voice for cordless telephony but has also been deployed + for data-centric services. + + DECT ULE is a recent addition to the DECT interface primarily + intended for low-bandwidth, low-power applications such as sensor + devices, smart meters, home automation, etc. As the DECT ULE + interface inherits many of the capabilities from DECT, it benefits + from operation that is long-range and interference-free, worldwide- + reserved frequency band, low silicon prices, and maturity. There is + an added value in the ability to communicate with IPv6 over DECT ULE, + such as for Internet of Things applications. + + This document describes how IPv6 is transported over DECT ULE using + IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) + techniques. + + + + + + + + + + + + + +Mariager, et al. Standards Track [Page 1] + +RFC 8105 IPv6 over DECT ULE May 2017 + + +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 has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8105. + +Copyright Notice + + 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 review these documents + carefully, as 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 are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + +Mariager, et al. Standards Track [Page 2] + +RFC 8105 IPv6 over DECT ULE May 2017 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mariager, et al. Standards Track [Page 3] + +RFC 8105 IPv6 over DECT ULE May 2017 + + +1. Introduction + + Digital Enhanced Cordless Telecommunications (DECT) is a standard + series [EN300.175-part1-7] specified by ETSI, and 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 building on the key fundamentals of traditional + DECT/CAT-iq but with specific changes to significantly reduce the + power consumption at the expense of data throughput. DECT ULE + devices with requirements on power consumption, as specified by ETSI + in [TS102.939-1] and [TS102.939-2], will operate on special power- + optimized silicon but can connect to a DECT Gateway supporting + traditional DECT/CAT-iq for cordless telephony and data as well as + the ULE extensions. + + DECT terminology has two major role definitions: the Portable Part + (PP) is the power-constrained device while the Fixed Part (FP) is the + Gateway or base station. This FP may be connected to the Internet. + An example of a use case for DECT ULE is a home-security sensor + transmitting small amounts of data (few bytes) at periodic intervals + through the FP but that is able to wake up upon an external event + (e.g., a break-in) and communicate with the FP. Another example + incorporating both DECT ULE and traditional CAT-iq telephony would be + a pendant (brooch) for the elderly that generally transmits periodic + status messages to a care provider using very little battery, but in + the event of an emergency, the elderly person can establish a voice + connection through the pendant to an alarm service. It is expected + that DECT ULE will be integrated into many residential gateways, as + many of these already implement DECT CAT-iq for cordless telephony. + DECT ULE can be added as a software option for the FP. + + It is desirable to consider IPv6 for DECT ULE devices due to the + large address space and well-known infrastructure. This document + describes how IPv6 is used on DECT ULE links to optimize power while + maintaining the many benefits of IPv6 transmission. [RFC4944], + [RFC6282], and [RFC6775] specify the transmission of IPv6 over IEEE + 802.15.4. DECT ULE has many characteristics similar to those of IEEE + 802.15.4, but it also has differences. A subset of mechanisms + defined for transmission of IPv6 over IEEE 802.15.4 can be applied to + the transmission of IPv6 on DECT ULE links. + + This document specifies how to map IPv6 over DECT ULE inspired by + [RFC4944], [RFC6282], [RFC6775], and [RFC7668]. + + + + + + + +Mariager, et al. Standards Track [Page 4] + +RFC 8105 IPv6 over DECT ULE May 2017 + + +1.1. Requirements Notation + + 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 + + 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 + + + +Mariager, et al. Standards Track [Page 5] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + 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 a low-power air interface technology that is designed to + support both circuit-switched services, such as voice communication, + and packet-mode data services at a modest data rate. This document + is only addressing the packet-mode data service of DECT ULE. + +2.1. The DECT ULE Protocol Stack + + The DECT ULE Protocol Stack contains a PHY layer operating at + frequencies in the 1880 - 1920 MHz frequency band depending on the + region and uses a symbol rate of 1.152 Mbaud. Radio bearers are + allocated by use of FDMA/TDMA/TDD techniques. + + In its generic network topology, DECT is defined as a cellular + network technology. However, the most common configuration is a star + network with a single FP defining the network with a number of PPs + attached. The MAC layer supports both traditional DECT circuit mode + operation, as this is used for services like discovery, pairing, + security features, etc., and it supports new ULE packet-mode + operation. The circuit-mode features have been reused from DECT. + + The DECT ULE device can switch to the ULE mode of operation, + utilizing the new ULE MAC layer features. The DECT ULE Data Link + Control (DLC) provides multiplexing as well as segmentation and + reassembly for larger packets from layers above. The DECT ULE layer + also implements per-message authentication and encryption. The DLC + layer ensures packet integrity and preserves packet order, but + delivery is based on best effort. + + 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 initiated from both the FP + side and the PP side. Depending on power-down modes employed in the + PP, latency may occur when initiating sessions from the FP side. MAC + layer communication can take place using either connection-oriented + packet transfer with low overhead for short sessions or connection- + oriented bearers including media reservation. The MAC layer + autonomously selects the radio-spectrum positions that are available + + + + + +Mariager, et al. Standards Track [Page 6] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + within the band and can rearrange these to avoid interference. The + MAC layer has built-in retransmission procedures in order to improve + transmission reliability. + + The DECT ULE device will typically incorporate an Application + Programming Interface (API), as well as common elements known as + Generic Access Profiles (GAPs), for enrolling into the network. The + DECT ULE Stack establishes a Permanent Virtual Circuit (PVC) for the + application layers and provides support for a range of different + application protocols. The application protocol is 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 divided into the Control Plane + (C-plane) and User Data Plane (U-plane), to the left and to the + right, respectively. The shown entities in the Stack are the + Physical Layer (PHY), Media Access Control (MAC) Layer, Data Link + Control (DLC) Layer, and Network Layer (NWK), along with following + subcomponents: Lower-Layer Management Entity (LLME), Mobility + Management (MM), and Call Control (CC). Above there are the typical + Application Programmers Interface (API) and application-profile- + specific layers. + + + + + + + +Mariager, et al. Standards Track [Page 7] + +RFC 8105 IPv6 over DECT ULE May 2017 + + +2.2. Link Layer Roles and Topology + + An FP is assumed to be less constrained than a PP. Hence, 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 of an FP and PP are out + of scope. + + In DECT ULE, at the link layer, the communication only takes place + between an FP and a PP. An FP is able to handle multiple + simultaneous connections with a number of PPs. Hence, 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 significant difference between IEEE 802.15.4 and DECT ULE is that + the former supports both star and mesh topology (and requires a + routing protocol), whereas DECT ULE in its primary configuration does + not support the formation of multihop networks at the link layer. In + consequence, 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 are outside the scope of this document. + +2.3. Addressing Model + + Each DECT PP is assigned an IPEI during manufacturing. This identity + has the size of 40 bits and is globally unique within DECT addressing + space and can be used to constitute the MAC address used to derive + the IID for 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. Although the + TPUI is temporary by definition, many implementations assign the same + value repeatedly to any given PP, hence it seems not suitable for + construction of the IID (see [RFC8065]). + + + + + +Mariager, et al. Standards Track [Page 8] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + Each DECT FP is assigned an RFPI during manufacturing. This identity + has the size of 40 bits and is globally unique within DECT addressing + space and can be used to constitute the MAC address used to derive + the IID for 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 MAC-48 to + construct the IID. However, as these addresses are considered as + being 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 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. In order to support complete IPv6 packets, the DLC layer + of DECT ULE SHALL, per this specification, be configured with an MTU + size of 1280 octets, hence [RFC4944] fragmentation/reassembly is not + required. + + It is important to realize that the usage of larger packets will be + at the expense of battery life, as a large packet inside the DECT ULE + Stack will be fragmented into several or many MAC layer packets, each + consuming power to transmit/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 FP and to roam between them. These FP 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 communications 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]. + + + + + +Mariager, et al. Standards Track [Page 9] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + DECT ULE technology sets strict requirements for low power + consumption and, thus, limits the allowed protocol overhead. 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 and 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 the + formation of 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 + + In order 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. + Following 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 + + + +Mariager, et al. Standards Track [Page 10] + +RFC 8105 IPv6 over DECT ULE May 2017 + + +3.2. Link Model + + The general model is that IPv6 is Layer 3 and DECT ULE MAC and DECT + ULE DLC are Layer 2. DECT ULE already implements fragmentation and + reassembly functionality; hence, the fragmentation and reassembly + function described in [RFC4944] MUST NOT be used. + + After the FPs and PPs have connected at the DECT ULE level, the link + can be considered up and IPv6 address configuration and transmission + can begin. The 6LBR ensures address collisions do not occur. + + Per this specification, the IPv6 header compression format specified + in [RFC6282] MUST be used. The IPv6 payload length can be derived + from the ULE DLC packet length. The possibly elided IPv6 address can + be reconstructed from the lower layer address (see Section 3.2.4). + + Due to the DECT ULE star topology (see Section 2.2), each PP has a + separate link to the FP; thus, the PPs cannot directly hear one + another and cannot talk to one another. As discussed in [RFC4903], + conventional usage of IPv6 anticipates IPv6 subnets spanning a single + link at the link layer. In order to avoid the complexity of + implementing a separate subnet for each DECT ULE link, a Multi-Link + Subnet model [RFC4903] has been chosen, specifically Non-Broadcast + Multi-Access (NBMA) at Layer 2. Because of this, link-local + multicast communications can happen only within a single DECT ULE + connection; thus, 6LN-to-6LN communications using link-local + addresses are not possible. 6LNs connected to the same 6LBR have to + communicate with each other utilizing the shared prefix used on the + subnet. The 6LBR forwards packets sent by one 6LN to another. + +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] based on the DECT device addresses (see + Section 2.3) that were used for establishing 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. + + The rule for deriving IIDs from DECT device addresses is as follows: + the DECT device addresses that consist of 40 bits each MUST be + expanded with leading zero bits to form 48-bit intermediate + addresses. The most significant bit in this newly formed 48-bit + intermediate address is set to one for addresses derived from the + RFPI and set to zero for addresses derived from the IPEI. 64-bit IIDs + + + +Mariager, et al. Standards Track [Page 11] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + are derived from these intermediate 48-bit addresses following the + guidance in Appendix A of [RFC4291]. However, because DECT and IEEE + address spaces are different, this intermediate address cannot be + considered to be unique within an IEEE address space. In the derived + IIDs, the Universal/Local (U/L) bit (7th bit) will be zero, which + indicates that 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; 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 + as they should never be leaked outside the subnet domain. + + As defined in [RFC4291], the IPv6 link-local address is formed by + appending the IID to 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, 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. + Alternative schemes such as Cryptographically Generated Addresses + (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses + (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque + addresses [RFC7217] SHOULD be used by default. See also [RFC8065] + for guidance of needed entropy in IIDs and the recommended lifetime + of used IIDs. When generated IIDs are not globally unique, Duplicate + Address Detection (DAD) [RFC4862] MUST be used. In situations where + deployment constraints require the device's address to be embedded in + the IID, the 6LN MAY form a 64-bit IID by utilizing the MAC-48 device + address or DECT device addresses. The non-link-local addresses that + a 6LN generates MUST be registered with 6LBR as described in + Section 3.2.2. + + The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT + ULE network is out of scope of this document, but a prefix can be, + for example, assigned via DHCPv6 Prefix Delegation [RFC3633] or using + IPv6 Unicast Unique Local Addresses (ULAs) [RFC4193]. Due to the + + + +Mariager, et al. Standards Track [Page 12] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + link model of the DECT ULE, the 6LBR MUST set the "on-link" (L) flag + to zero in the Prefix Information Option [RFC4861]. This will cause + 6LNs to always send packets to the 6LBR, including the case 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 use in several 6LoWPAN topologies, + including the mesh topology. As DECT ULE does not support mesh + networks, only those aspects of [RFC6775] that apply to star topology + are considered. + + The following aspects of the Neighbor Discovery optimizations + [RFC6775] are applicable 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 the [RFC6775]. + + 2. A DECT ULE 6LN MUST NOT register its link-local address. Because + the IIDs used in link-local addresses are derived from DECT + addresses, there will always exist 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 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 required by IPv6. + + Hence, traffic is always unicast between two DECT ULE nodes. Even in + the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot + do a multicast to all 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. However, this may not be energy + efficient and particular care should be taken if the FP is battery- + powered. To further conserve 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 + multicast groups the packets belong to. In the opposite direction, a + 6LN can only transmit data to or through the 6LBR. Hence, when a 6LN + + + +Mariager, et al. Standards Track [Page 13] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + needs to transmit an IPv6 multicast packet, the 6LN will unicast the + corresponding DECT ULE packet to the 6LBR. The 6LBR will then + forward the multicast packet to 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 + encoding formats as described in [RFC6282]. The DECT ULE's star + topology structure, ARO and 6CO, can be exploited in order to provide + a mechanism for address compression. The following text describes + the principles of IPv6 address compression on top of DECT ULE. + +3.2.4.1. Link-Local Header Compression + + In a link-local communication terminated at 6LN and 6LBR, both the + IPv6 source and destination addresses MUST be elided since the used + IIDs map uniquely into 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 considered 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. + +3.2.4.2. Non-link-local Header Compression + + 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, if a context is defined for the prefix of the + 6LNs 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] and MUST 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 + + + +Mariager, et al. Standards Track [Page 14] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + 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 having a global unicast IPv6 + address and the destination of the packet is a 6LN, if 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 and MUST fully elide the IPv6 destination + address of the packet if the destination address is the latest + 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 + + In the DECT ULE star topology (see Section 2.2), each PP has a + separate link to the FP, and the FP acts as an IPv6 router rather + than a link layer switch. A Multi-Link Subnet model [RFC4903] has + been chosen, specifically Non-Broadcast Multi-Access (NBMA) at Layer + 2, as is further illustrated in Figure 5. The 6LBR forwards packets + sent by one 6LN to another. In a typical scenario, the DECT ULE + network is connected to the Internet as shown in the Figure 5. In + this scenario, the DECT ULE network is deployed as one subnet using + one /64 IPv6 prefix. The 6LBR acts as a router and forwards packets + between 6LNs to and from Internet. + + 6LN + \ ____________ + \ / \ + 6LN ---- 6LBR ------ | Internet | + / \____________/ + / + 6LN + + <-- One subnet --> + <-- DECT ULE --> + + Figure 5: DECT ULE Network Connected to the Internet + + In some scenarios, the DECT ULE network may transiently or + permanently be an isolated network as shown in the Figure 6. In this + case, the whole DECT ULE network consists of a single subnet with + multiple links, where 6LBR is routing packets between 6LNs. + + + +Mariager, et al. Standards Track [Page 15] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + 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. + + In other more advanced systems scenarios with multiple FPs and 6LBR, + each DECT ULE FP constitutes a wireless cell. The network can be + configured as a Multi-Link Subnet in which the 6LN can operate within + the same /64 subnet prefix in multiple cells as shown in the + 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 + + + + + + + + +Mariager, et al. Standards Track [Page 16] + +RFC 8105 IPv6 over DECT ULE May 2017 + + +4. IANA Considerations + + This document does not require any IANA actions. + +5. Security Considerations + + 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 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; hence, 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]. + + + + + + + + + + +Mariager, et al. Standards Track [Page 17] + +RFC 8105 IPv6 over DECT ULE May 2017 + + +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. + In order 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 + + [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>. + + + + + + + +Mariager, et al. Standards Track [Page 18] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + [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>. + + + + + + + + +Mariager, et al. Standards Track [Page 19] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + [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 + + [BACKBONE-ROUTER] + Thubert, P., "IPv6 Backbone Router", Work in Progress, + draft-ietf-6lo-backbone-router-03, January 2017. + + [CAT-iq] DECT Forum, "CAT-iq at a Glance", January 2016, + <http://www.dect.org/userfiles/Public/ + DF_CAT-iq%20at%20a%20Glance.pdf>. + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July + 2003, <http://www.rfc-editor.org/info/rfc3315>. + + [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with + CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September + 2003, <http://www.rfc-editor.org/info/rfc3610>. + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, DOI 10.17487/RFC3972, March 2005, + <http://www.rfc-editor.org/info/rfc3972>. + + [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, + DOI 10.17487/RFC4903, June 2007, + <http://www.rfc-editor.org/info/rfc4903>. + + [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, + DOI 10.17487/RFC5535, June 2009, + <http://www.rfc-editor.org/info/rfc5535>. + + [RFC7217] Gont, F., "A Method for Generating Semantically Opaque + Interface Identifiers with IPv6 Stateless Address + Autoconfiguration (SLAAC)", RFC 7217, + DOI 10.17487/RFC7217, April 2014, + <http://www.rfc-editor.org/info/rfc7217>. + + + + + + +Mariager, et al. Standards Track [Page 20] + +RFC 8105 IPv6 over DECT ULE May 2017 + + + [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., + Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low + Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, + <http://www.rfc-editor.org/info/rfc7668>. + + [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, + "Recommendation on Stable IPv6 Interface Identifiers", + RFC 8064, DOI 10.17487/RFC8064, February 2017, + <http://www.rfc-editor.org/info/rfc8064>. + + [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- + Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, + February 2017, <http://www.rfc-editor.org/info/rfc8065>. + +Acknowledgements + + We are grateful to the members of the IETF 6lo working group; this + document borrows liberally from their work. + + Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan, Pascal + Thubert, Tatuya Jinmei, Dale Worley, and Robert Sparks have provided + valuable feedback for this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mariager, et al. Standards Track [Page 21] + +RFC 8105 IPv6 over DECT ULE May 2017 + + +Authors' Addresses + + 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 + + + + + + +Mariager, et al. Standards Track [Page 22] + |