Transmission of IPv6 Packets over DECT Ultra Low Energy

DECT (Digital Enhanced Cordless Telecommunications) 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 operates with 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 is able to wake up upon an external event (burglar) and communicate with the FP. Another example incorporating both DECT ULE as well as traditional CAT-iq telephony is an elderly pendant (broche) which can transmit periodic status messages to a care provider using very little battery, but in the event of urgency, 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 implements 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 also 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].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

6CO: 6LoWPAN Context Option [RFC6775] 6BBR: 6loWPAN Backbone Router 6LBR: 6LoWPAN Border Router as defined in [RFC6775]. The DECT Fixed Part is having this role 6LN: 6LoWPAN Node as defined in [RFC6775]. The DECT Portable part is having this role 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network AES128: Advanced Encryption Standard with 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 Multiplex 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 Multiplex TPUI: Temporary Portable User Identity; (DECT identity) UAK: User Authentication Key, DECT master security key ULA: Unique Local Address [RFC4193]

DECT ULE is a low power air interface technology that is designed to support both circuit switched for service, such as voice communication, and for packet mode data services at modest data rate. This draft is only addressing the packet mode data service of DECT ULE.

The DECT ULE protocol stack consists of the PHY layer operating at frequencies in the 1880 - 1920 MHz frequency band depending on the region and uses a symbol rate of 1.152 Mbps. 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 PP 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 re-assembly 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 FP and PP side. Depending on power down modes employed in the PP, latency may occur when initiating sessions from FP side. MAC layer communication can take place using either connection oriented packet transfer with low overhead for short sessions or take place using connection oriented bearers including media reservation. The MAC layer autonomously selects the radio spectrum positions that are available 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 Programmers Interface (API) as well as common elements known as Generic Access Profile (GAP) 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 used application protocol is negotiated between the PP and FP when the PVC communication service is established. This draft defines 6LoWPAN as one of the possible protocols to negotiate.

+----------------------------------------+ | 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 above shows the DECT ULE Stack divided into the Control-plane and User-data path, to left and to the right, respectively. The shown entities in the Stack are the (PHY) Physical Layer, (MAC) Media Access Control Layer, (DLC) Data Link Control Layer, (NWK) Network Layer with subcomponents: (LLME) Lower Layer Management Entity, (MM) Mobility Management and (CC) Call Control. Above there are the typically (API) Application Programmers Interface and application profile specific layers.

A FP is assumed to be less constrained than a PP. Hence, in the primary scenario FP and PP will act as 6LBR and a 6LN, respectively. This document only addresses this primary scenario and all other scenarios are out of scope. In DECT ULE, at link layer the communication only takes place between a FP and a PP. A FP is able to handle multiple simultaneous connections with a number of PP. 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 it's primary configuration does not support the formation of multihop networks at the link layer. In consequence, the mesh header defined in [RFC4944] for mesh under routing are not used in DECT ULE networks. DECT ULE repeaters are considered to operate in the DECT protocol domain and are outside the scope of this document.

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 FP and PP. Although the TPUI is temporary by definition, the same value is usually repeatedly assigned to any given PP, hence it seems not suitable for construction of IID, see [I-D.ietf-6lo-privacy-considerations]. Each DECT FP is assigned a 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 additionally 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 scheme is not recommended as per [I-D.ietf-6lo-privacy-considerations].

Ideally the DECT ULE FP and PP may generate data that fits into a single MAC Layer packets (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 a MTU size of 1280 octets, hence [RFC4944] fragmentation/reassembly is not required. It is expected that the LOWPAN_IPHC packet will fulfil all the requirements for header compression without spending unnecessary overhead for mesh addressing. 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.

The DECT ULE standard allows PP to be DECT-registered (bind) to multiple FP and roaming between them. These FP and their 6LBR functionalities can either operate individual or connected through a Backbone Router as per [I-D.ietf-6lo-backbone-router].

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]. 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 which 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 IPv6 over DECT ULE stack. As consequence of DECT ULE in it's 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, a DECT ULE PP node MUST NOT play the role of a 6LoWPAN Router (6LR).

In order to enable data transmission over DECT ULE, a Permanent Virtual Circuit (PVC) has to be configured and opened between FP and PP. This is done by setting up a DECT service call from PP to FP. In 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-ATTRIBTES>> SHALL define 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 be pageable. 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

The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is layer 2. The DECT ULE implements already fragmentation and reassembly functionality, hence [RFC4944] fragmentation and reassembly function MUST NOT be used. After the FP 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 and the possibly elided IPv6 address can be reconstructed from the link-layer address, used at the time of DECT ULE connection establishment, from the ULE MAC packet address, compression context if any, and from address registration information (see Section 3.2.2). Due to the DECT ULE star topology (see Section 2.2), PP each have a separate link to the FP, and 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 avoid the complexity of implementing separate subnet for each DECT ULE link, a Multi-Link Subnet model 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 by using the shared prefix used on the subnet. The 6LBR forwards packets sent by one 6LN to another.

At network interface initialization, both 6LN and 6LBR SHALL generate and assign to the DECT ULE network interface IPv6 link-local addresses [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 (IID) for 6LN and 6LBR, respectively. The rule for deriving IID from DECT device addresses is as follows: The DECT device addresses that are consisting of 40 bits each, MUST be expanded with leading zero bits to form 48 bit intermediate addresses. 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. From these intermediate 48 bit addresses are derived 64 bit IIDs similar to the guidance of [RFC4291]. However, because DECT and IEEE address spaces are different, this intermediate address cannot be considered as unique within IEEE address space. In the derived IIDs the U/L bit (7th bit) will be zero, indicating that derived IID's 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. Globally uniqueness of IID in link-local addresses are 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 [RFC4861] Section 6.3.7 and [RFC6775] Section 5.3. 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 [I-D.ietf-6lo-privacy-considerations] for guidance of needed entropy in IIDs. When generated IID's are not globally unique, Duplicate Address Detection (DAD) [RFC4862] MUST be used. In situations where the devices address embedded in the IID are required to support deployment constraints, 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 can be, for example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to the link model of the DECT ULE the 6LBR MUST set the "on-link" flag (L) 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.

'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 is considered not to support mesh networks, hence only those aspects that apply to a 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.

The DECT MAC layer broadcast service is considered inadequate for IP multicast. 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 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.

Header compression as defined in [RFC6282], which specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4, is REQUIRED in this document as the basis for IPv6 header compression on top of DECT ULE. All headers MUST be compressed according to [RFC6282] encoding formats. 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.

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, DAM=11.

To enable efficient header compression, the 6LBR MUST include 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, 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 a 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.

In the DECT ULE star topology (see Section 2.2), PP each have 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 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 is acting as router and forwarding packets between 6LNs and 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.

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 ULA prefix [RFC4193], and route packets between PP. In other more advanced systems scenarios with multiple FP and 6LBR, each DECT ULE FP constitutes a wireless cell. The network can be configured as a Multi-Link Subnet, in which the can 6LN operate within the same /64 subnet prefix in multiple cells as shown in the Figure 7. The FPs operation role in such scenario are rather like Backbone Routers (6BBR) than 6LBR, as per [I-D.ietf-6lo-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

There are no IANA considerations related to this document.

The secure transmission of speech over DECT will be based on the DSAA2 and DSC/DSC2 specification developed by ETSI TC DECT and the ETSI SAGE Security expert group. DECT ULE communications are secured at the link-layer (DLC) by encryption and per-message authentication through CCM mode (Counter with CBC-MAC) similar to [RFC3610]. The underlying algorithm for providing encryption and authentication is AES128. The DECT ULE pairing procedure generates a master authentication key (UAK). During location registration procedure or when the permanent virtual circuit are established, the session security keys are generated. 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 PP in a system have different security keys. DECT ULE PPs do not use any shared encryption key. From 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 [I-D.ietf-6man-default-iids], or use alternative schemes such as Cryptographically Generated Addresses (CGA) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBA, [RFC5535]), or static, semantically opaque addresses [RFC7217].

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 as 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 specified to 0x06 for 6LoWPAN [TS102.939-1].

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 and Tatuya Jinmei have provided valuable feedback for this draft.