idnits 2.17.00 (12 Aug 2021) /tmp/idnits4831/draft-ietf-6lo-dect-ule-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 3, 2016) is 2056 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-6man-default-iids' is defined on line 858, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 == Outdated reference: draft-ietf-6lo-privacy-considerations has been published as RFC 8065 == Outdated reference: draft-ietf-6man-default-iids has been published as RFC 8064 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group P. Mariager 3 Internet-Draft J. Petersen, Ed. 4 Intended status: Standards Track RTX A/S 5 Expires: April 6, 2017 Z. Shelby 6 ARM 7 M. Van de Logt 8 Gigaset Communications GmbH 9 D. Barthel 10 Orange Labs 11 October 3, 2016 13 Transmission of IPv6 Packets over DECT Ultra Low Energy 14 draft-ietf-6lo-dect-ule-06 16 Abstract 18 DECT Ultra Low Energy is a low power air interface technology that is 19 defined by the DECT Forum and specified by ETSI. 21 The DECT air interface technology has been used world-wide in 22 communication devices for more than 20 years, primarily carrying 23 voice for cordless telephony but has also been deployed for data 24 centric services. 26 The DECT Ultra Low Energy is a recent addition to the DECT interface 27 primarily intended for low-bandwidth, low-power applications such as 28 sensor devices, smart meters, home automation etc. As the DECT Ultra 29 Low Energy interface inherits many of the capabilities from DECT, it 30 benefits from long range, interference free operation, world wide 31 reserved frequency band, low silicon prices and maturity. There is 32 an added value in the ability to communicate with IPv6 over DECT ULE 33 such as for Internet of Things applications. 35 This document describes how IPv6 is transported over DECT ULE using 36 6LoWPAN techniques. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 6, 2017. 55 Copyright Notice 57 Copyright (c) 2016 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 74 1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 5 76 2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 5 77 2.2. Link Layer Roles and Topology . . . . . . . . . . . . . . 6 78 2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 7 79 2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 8 80 2.5. Additional Considerations . . . . . . . . . . . . . . . . 8 81 3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 8 82 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 9 83 3.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 10 84 3.3. Subnets and Internet Connectivity Scenarios . . . . . . . 14 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 8.2. Informative References . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 DECT (Digital Enhanced Cordless Telecommunications) is a standard 97 series [EN300.175-part1-7] specified by ETSI and CAT-iq (Cordless 98 Advanced Technology - internet and quality) is a set of product 99 certification and interoperability profiles [CAT-iq] defined by DECT 100 Forum. DECT Ultra Low Energy (DECT ULE or just ULE) is an air 101 interface technology building on the key fundamentals of traditional 102 DECT / CAT-iq but with specific changes to significantly reduce the 103 power consumption at the expense of data throughput. DECT ULE 104 devices with requirements on power consumption as specified by ETSI 105 in [TS102.939-1] and [TS102.939-2], will operate on special power 106 optimized silicon, but can connect to a DECT Gateway supporting 107 traditional DECT / CAT-iq for cordless telephony and data as well as 108 the ULE extensions. DECT terminology operates with two major role 109 definitions: The Portable Part (PP) is the power constrained device, 110 while the Fixed Part (FP) is the Gateway or base station. This FP 111 may be connected to the Internet. An example of a use case for DECT 112 ULE is a home security sensor transmitting small amounts of data (few 113 bytes) at periodic intervals through the FP, but is able to wake up 114 upon an external event (burglar) and communicate with the FP. 115 Another example incorporating both DECT ULE as well as traditional 116 CAT-iq telephony is an elderly pendant (broche) which can transmit 117 periodic status messages to a care provider using very little 118 battery, but in the event of urgency, the elderly person can 119 establish a voice connection through the pendant to an alarm service. 120 It is expected that DECT ULE will be integrated into many residential 121 gateways, as many of these already implements DECT CAT-iq for 122 cordless telephony. DECT ULE can be added as a software option for 123 the FP. It is desirable to consider IPv6 for DECT ULE devices due to 124 the large address space and well-known infrastructure. This document 125 describes how IPv6 is used on DECT ULE links to optimize power while 126 maintaining the many benefits of IPv6 transmission. [RFC4944], 127 [RFC6282] and [RFC6775] specify the transmission of IPv6 over IEEE 128 802.15.4. DECT ULE has many characteristics similar to those of IEEE 129 802.15.4, but also differences. A subset of mechanisms defined for 130 transmission of IPv6 over IEEE 802.15.4 can be applied to the 131 transmission of IPv6 on DECT ULE links. 133 This document specifies how to map IPv6 over DECT ULE inspired by 134 [RFC4944], [RFC6282], [RFC6775] and [RFC7668]. 136 1.1. Requirements Notation 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 1.2. Terms Used 144 6CO: 6LoWPAN Context Option [RFC6775] 145 6BBR: 6loWPAN Backbone Router 146 6LBR: 6LoWPAN Border Router as defined in [RFC6775]. The DECT Fixed 147 Part is having this role 148 6LN: 6LoWPAN Node as defined in [RFC6775]. The DECT Portable part 149 is having this role 150 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 151 AES128: Advanced Encryption Standard with key size of 128 bits 152 API: Application Programming Interface 153 ARO: Address Registration Option [RFC6775] 154 CAT-iq: Cordless Advanced Technology - internet and quality 155 CID: Context Identifier [RFC6775] 156 DAC: Destination Address Compression 157 DAM: Destination Address Mode 158 DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315] 159 DLC: Data Link Control 160 DSAA2: DECT Standard Authentication Algorithm #2 161 DSC: DECT Standard Cipher 162 DSC2: DECT Standard Cipher #2 163 FDMA: Frequency Division Multiplex 164 FP: DECT Fixed Part, the gateway 165 GAP: Generic Access Profile 166 IID: Interface Identifier 167 IPEI: International Portable Equipment Identity; (DECT identity) 168 MAC-48: 48 bit global unique MAC address managed by IEEE 169 MAC: Media Access Control 170 MTU: Maximum Transmission Unit 171 NBMA: Non-broadcast multi-access 172 ND: Neighbor Discovery [RFC4861] [RFC6775] 173 PDU: Protocol Data Unit 174 PHY: Physical Layer 175 PMID: Portable MAC Identity; (DECT identity) 176 PP: DECT Portable Part, typically the sensor node (6LN) 177 PVC: Permanent Virtual Circuit 178 RFPI: Radio Fixed Part Identity; (DECT identity) 179 SAC: Source Address Compression 180 SAM: Source Address Mode 181 TDD: Time Division Duplex 182 TDMA: Time Division Multiplex 183 TPUI: Temporary Portable User Identity; (DECT identity) 184 UAK: User Authentication Key, DECT master security key 185 ULA: Unique Local Address [RFC4193] 187 2. DECT Ultra Low Energy 189 DECT ULE is a low power air interface technology that is designed to 190 support both circuit switched for service, such as voice 191 communication, and for packet mode data services at modest data rate. 192 This draft is only addressing the packet mode data service of DECT 193 ULE. 195 2.1. The DECT ULE Protocol Stack 197 The DECT ULE protocol stack consists of the PHY layer operating at 198 frequencies in the 1880 - 1920 MHz frequency band depending on the 199 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 200 allocated by use of FDMA/TDMA/TDD techniques. 202 In its generic network topology, DECT is defined as a cellular 203 network technology. However, the most common configuration is a star 204 network with a single FP defining the network with a number of PP 205 attached. The MAC layer supports both traditional DECT circuit mode 206 operation as this is used for services like discovery, pairing, 207 security features etc, and it supports new ULE packet mode operation. 208 The circuit mode features have been reused from DECT. 210 The DECT ULE device can switch to the ULE mode of operation, 211 utilizing the new ULE MAC layer features. The DECT ULE Data Link 212 Control (DLC) provides multiplexing as well as segmentation and re- 213 assembly for larger packets from layers above. The DECT ULE layer 214 also implements per-message authentication and encryption. The DLC 215 layer ensures packet integrity and preserves packet order, but 216 delivery is based on best effort. 218 The current DECT ULE MAC layer standard supports low bandwidth data 219 broadcast. However, this document is not considering usage of the 220 DECT ULE MAC layer broadcast service for IPv6 over DECT ULE. 222 In general, communication sessions can be initiated from both FP and 223 PP side. Depending on power down modes employed in the PP, latency 224 may occur when initiating sessions from FP side. MAC layer 225 communication can take place using either connection oriented packet 226 transfer with low overhead for short sessions or take place using 227 connection oriented bearers including media reservation. The MAC 228 layer autonomously selects the radio spectrum positions that are 229 available within the band and can rearrange these to avoid 230 interference. The MAC layer has built-in retransmission procedures 231 in order to improve transmission reliability. 233 The DECT ULE device will typically incorporate an Application 234 Programmers Interface (API) as well as common elements known as 235 Generic Access Profile (GAP) for enrolling into the network. The 236 DECT ULE stack establishes a permanent virtual circuit (PVC) for the 237 application layers and provides support for a range of different 238 application protocols. The used application protocol is negotiated 239 between the PP and FP when the PVC communication service is 240 established. This draft defines 6LoWPAN as one of the possible 241 protocols to negotiate. 243 +----------------------------------------+ 244 | Application Layers | 245 +----------------------------------------+ 246 | Generic Access | ULE Profile | 247 | Profile | | 248 +----------------------------------------+ 249 | DECT/Service API | ULE Data API | 250 +--------------------+-------------------+ 251 | LLME | NWK (MM,CC)| | 252 +--------------------+-------------------+ 253 | DECT DLC | DECT ULE DLC | 254 +--------------------+-------------------+ 255 | MAC Layer | 256 +--------------------+-------------------+ 257 | PHY Layer | 258 +--------------------+-------------------+ 259 (C-plane) (U-plane) 261 Figure 1: DECT ULE Protocol Stack 263 Figure 1 above shows the DECT ULE Stack divided into the Control- 264 plane and User-data path, to left and to the right, respectively. 265 The shown entities in the Stack are the (PHY) Physical Layer, (MAC) 266 Media Access Control Layer, (DLC) Data Link Control Layer, (NWK) 267 Network Layer with subcomponents: (LLME) Lower Layer Management 268 Entity, (MM) Mobility Management and (CC) Call Control. Above there 269 are the typically (API) Application Programmers Interface and 270 application profile specific layers. 272 2.2. Link Layer Roles and Topology 274 A FP is assumed to be less constrained than a PP. Hence, in the 275 primary scenario FP and PP will act as 6LBR and a 6LN, respectively. 276 This document only addresses this primary scenario and all other 277 scenarios are out of scope. 279 In DECT ULE, at link layer the communication only takes place between 280 a FP and a PP. A FP is able to handle multiple simultaneous 281 connections with a number of PP. Hence, in a DECT ULE network using 282 IPv6, a radio hop is equivalent to an IPv6 link and vice versa (see 283 Section 3.3). 285 [DECT ULE PP]-----\ /-----[DECT ULE PP] 286 \ / 287 [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP] 288 / \ 289 [DECT ULE PP]-----/ \-----[DECT ULE PP] 291 Figure 2: DECT ULE star topology 293 A significant difference between IEEE 802.15.4 and DECT ULE is that 294 the former supports both star and mesh topology (and requires a 295 routing protocol), whereas DECT ULE in it's primary configuration 296 does not support the formation of multihop networks at the link 297 layer. In consequence, the mesh header defined in [RFC4944] for mesh 298 under routing are not used in DECT ULE networks. 300 DECT ULE repeaters are considered to operate in the DECT protocol 301 domain and are outside the scope of this document. 303 2.3. Addressing Model 305 Each DECT PP is assigned an IPEI during manufacturing. This identity 306 has the size of 40 bits and is globally unique within DECT addressing 307 space and can be used to constitute the MAC address used to derive 308 the IID for link-local address. However, it cannot be used to derive 309 a globally unique IID. 311 During a DECT location registration procedure, the FP assigns a 20 312 bit TPUI to a PP. The FP creates a unique mapping between the 313 assigned TPUI and the IPEI of each PP. This TPUI is used for 314 addressing (layer 2) in messages between FP and PP. Although the 315 TPUI is temporary by definition, the same value is usually repeatedly 316 assigned to any given PP, hence it seems not suitable for 317 construction of IID, see [I-D.ietf-6lo-privacy-considerations]. 319 Each DECT FP is assigned a RFPI during manufacturing. This identity 320 has the size of 40 bits and is globally unique within DECT addressing 321 space and can be used to constitute the MAC address used to derive 322 the IID for link-local address. However, it cannot be used to derive 323 a globally unique IID. 325 Optionally each DECT PP and DECT FP can be assigned a unique (IEEE) 326 MAC-48 address additionally to the DECT identities to be used by the 327 6LoWPAN. During the address registration of non-link-local addresses 328 as specified by this document, the FP and PP can use such MAC-48 to 329 construct the IID. However, as these addresses are considered as 330 being permanent, such scheme is not recommended as per [I-D.ietf-6lo- 331 privacy-considerations]. 333 2.4. MTU Considerations 335 Ideally the DECT ULE FP and PP may generate data that fits into a 336 single MAC Layer packets (38 octets) for periodically transferred 337 information, depending on application. However, IP packets may be 338 much larger. The DECT ULE DLC procedures natively support 339 segmentation and reassembly and provide any MTU size below 65536 340 octets. The default MTU size defined in DECT ULE [TS102.939-1] is 341 500 octets. In order to support complete IPv6 packets, the DLC layer 342 of DECT ULE shall per this specification be configured with a MTU 343 size of 1280 octets, hence [RFC4944] fragmentation/reassembly is not 344 required. 346 It is expected that the LOWPAN_IPHC packet will fulfil all the 347 requirements for header compression without spending unnecessary 348 overhead for mesh addressing. 350 It is important to realize that the usage of larger packets will be 351 at the expense of battery life, as a large packet inside the DECT ULE 352 stack will be fragmented into several or many MAC layer packets, each 353 consuming power to transmit / receive. The increased MTU size does 354 not change the MAC layer packet and PDU size. 356 2.5. Additional Considerations 358 The DECT ULE standard allows PP to be DECT-registered (bind) to 359 multiple FP and roaming between them. These FP and their 6LBR 360 functionalities can either operate individual or connected through a 361 Backbone Router as per [I-D.ietf-6lo-backbone-router]. 363 3. Specification of IPv6 over DECT ULE 365 Before any IP-layer communications can take place over DECT ULE, DECT 366 ULE enabled nodes such as 6LNs and 6LBRs have to find each other and 367 establish a suitable link-layer connection. The obtain-access-rights 368 registration and location registration procedures are documented by 369 ETSI in the specifications [EN300.175-part1-7], [TS102.939-1] and 370 [TS102.939-2]. 372 DECT ULE technology sets strict requirements for low power 373 consumption and thus limits the allowed protocol overhead. 6LoWPAN 374 standards [RFC4944], [RFC6775], and [RFC6282] provide useful 375 functionality for reducing overhead which can be applied to DECT ULE. 376 This functionality comprises link-local IPv6 addresses and stateless 377 IPv6 address autoconfiguration, Neighbor Discovery and header 378 compression. 380 The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC 381 layer. Figure 3 illustrates IPv6 over DECT ULE stack. 383 As consequence of DECT ULE in it's primary configuration does not 384 support the formation of multihop networks at the link layer, the 385 mesh header defined in [RFC4944] for mesh under routing MUST NOT be 386 used. In addition, a DECT ULE PP node MUST NOT play the role of a 387 6LoWPAN Router (6LR). 389 3.1. Protocol Stack 391 In order to enable data transmission over DECT ULE, a Permanent 392 Virtual Circuit (PVC) has to be configured and opened between FP and 393 PP. This is done by setting up a DECT service call from PP to FP. 394 In DECT protocol domain the PP SHALL specify the <> 395 in a service-change (other) message before sending a service-change 396 (resume) message as defined in [TS102.939-1]. The <> 397 SHALL define the ULE Application Protocol Identifier to 0x06 and the 398 MTU size to 1280 octets or larger. The FP sends a service-change- 399 accept (resume) that MUST contain a valid paging descriptor. The PP 400 MUST be pageable. Following this, transmission of IPv6 packets can 401 start. 403 +-------------------+ 404 | UDP/TCP/other | 405 +-------------------+ 406 | IPv6 | 407 +-------------------+ 408 |6LoWPAN adapted to | 409 | DECT ULE | 410 +-------------------+ 411 | DECT ULE DLC | 412 +-------------------+ 413 | DECT ULE MAC | 414 +-------------------+ 415 | DECT ULE PHY | 416 +-------------------+ 418 Figure 3: IPv6 over DECT ULE Stack 420 3.2. Link Model 422 The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is 423 layer 2. The DECT ULE implements already fragmentation and 424 reassembly functionality, hence [RFC4944] fragmentation and 425 reassembly function MUST NOT be used. 427 After the FP and PPs have connected at the DECT ULE level, the link 428 can be considered up and IPv6 address configuration and transmission 429 can begin. The 6LBR ensures address collisions do not occur. 431 Per this specification, the IPv6 header compression format specified 432 in [RFC6282] MUST be used. The IPv6 payload length can be derived 433 from the ULE DLC packet length and the possibly elided IPv6 address 434 can be reconstructed from the link-layer address, used at the time of 435 DECT ULE connection establishment, from the ULE MAC packet address, 436 compression context if any, and from address registration information 437 (see Section 3.2.2). 439 Due to the DECT ULE star topology (see Section 2.2), PP each have a 440 separate link to the FP, and thus the PPs cannot directly hear one 441 another and cannot talk to one another. As discussed in [RFC4903], 442 conventional usage of IPv6 anticipates IPv6 subnets spanning a single 443 link at the link layer. In order avoid the complexity of 444 implementing separate subnet for each DECT ULE link, a Multi-Link 445 Subnet model has been chosen, specifically Non-broadcast multi-access 446 (NBMA) at layer 2. Because of this, link-local multicast 447 communications can happen only within a single DECT ULE connection; 448 thus, 6LN-to-6LN communications using link-local addresses are not 449 possible. 6LNs connected to the same 6LBR have to communicate with 450 each other by using the shared prefix used on the subnet. The 6LBR 451 forwards packets sent by one 6LN to another. 453 3.2.1. Stateless Address Autoconfiguration 455 At network interface initialization, both 6LN and 6LBR SHALL generate 456 and assign to the DECT ULE network interface IPv6 link-local 457 addresses [RFC4862] based on the DECT device addresses (see 458 Section 2.3) that were used for establishing the underlying DECT ULE 459 connection. 461 The DECT device addresses IPEI and RFPI MUST be used to derive the 462 IPv6 link-local 64 bit Interface Identifiers (IID) for 6LN and 6LBR, 463 respectively. 465 The rule for deriving IID from DECT device addresses is as follows: 466 The DECT device addresses that are consisting of 40 bits each, MUST 467 be expanded with leading zero bits to form 48 bit intermediate 468 addresses. Most significant bit in this newly formed 48-bit 469 intermediate address is set to one for addresses derived from the 470 RFPI and set to zero for addresses derived from the IPEI. From these 471 intermediate 48 bit addresses are derived 64 bit IIDs similar to the 472 guidance of [RFC4291]. However, because DECT and IEEE address spaces 473 are different, this intermediate address cannot be considered as 474 unique within IEEE address space. In the derived IIDs the U/L bit 475 (7th bit) will be zero, indicating that derived IID's are not 476 globally unique, see [RFC7136]. For example from RFPI=11.22.33.44.55 477 the derived IID is 80:11:22:ff:fe:33:44:55 and from 478 IPEI=01.23.45.67.89 the derived IID is 00:01:23:ff:fe:45:67:89. 480 As defined in [RFC4291], the IPv6 link-local address is formed by 481 appending the IID, to the prefix FE80::/64, as shown in Figure 4. 483 From privacy perspective such constructed link-local address should 484 never be used by application layers that could leak it outside the 485 subnet domain. 487 10 bits 54 bits 64 bits 488 +----------+-----------------+----------------------+ 489 |1111111010| zeros | Interface Identifier | 490 +----------+-----------------+----------------------+ 492 Figure 4: IPv6 link-local address in DECT ULE 494 A 6LN MUST join the all-nodes multicast address. 496 After link-local address configuration, 6LN sends Router Solicitation 497 messages as described in [RFC4861] Section 6.3.7. 499 For non-link-local addresses, 6LNs SHOULD NOT be configured to use 500 IIDs derived from a MAC-48 device address or DECT device addresses. 501 Alternative schemes such as Cryptographically Generated Addresses 502 (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses 503 (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque 504 addresses [RFC7217] SHOULD be used by default. See also [I-D.ietf- 505 6lo-privacy-considerations] for guidance of needed entropy in IIDs. 506 In situations where the devices address embedded in the IID are 507 required to support deployment constraints, 6LN MAY form a 64-bit IID 508 by utilizing the MAC-48 device address or DECT device addresses. The 509 non-link-local addresses that a 6LN generates MUST be registered with 510 6LBR as described in Section 3.2.2. 512 The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT 513 ULE network is out of scope of this document, but can be, for 514 example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by 515 using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to 516 the link model of the DECT ULE the 6LBR MUST set the "on-link" flag 517 (L) to zero in the Prefix Information Option [RFC4861]. This will 518 cause 6LNs to always send packets to the 6LBR, including the case 519 when the destination is another 6LN using the same prefix. 521 3.2.2. Neighbor Discovery 523 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 524 Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor 525 discovery approach as adapted for use in several 6LoWPAN topologies, 526 including the mesh topology. As DECT ULE is considered not to 527 support mesh networks, hence only those aspects that apply to a star 528 topology are considered. 530 The following aspects of the Neighbor Discovery optimizations 531 [RFC6775] are applicable to DECT ULE 6LNs: 533 1. For sending Router Solicitations and processing Router 534 Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections 535 5.3 and 5.4 of the [RFC6775]. 537 2. A DECT ULE 6LN MUST NOT register its link-local address. Because 538 the IIDs used in link-local addresses are derived from DECT 539 addresses, there will always exist a unique mapping between link- 540 local and layer-2 addresses. 542 3. A DECT ULE 6LN MUST register its non-link-local addresses with 543 the 6LBR by sending a Neighbor Solicitation (NS) message with the 544 Address Registration Option (ARO) and process the Neighbor 545 Advertisement (NA) accordingly. The NS with the ARO option MUST be 546 sent irrespective of the method used to generate the IID. 548 3.2.3. Unicast and Multicast Address Mapping 550 The DECT MAC layer broadcast service is considered inadequate for IP 551 multicast. 553 Hence traffic is always unicast between two DECT ULE nodes. Even in 554 the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot 555 do a multicast to all the connected 6LNs. If the 6LBR needs to send 556 a multicast packet to all its 6LNs, it has to replicate the packet 557 and unicast it on each link. However, this may not be energy- 558 efficient and particular care should be taken if the FP is battery- 559 powered. To further conserve power, the 6LBR MUST keep track of 560 multicast listeners at DECT-ULE link level granularity and it MUST 561 NOT forward multicast packets to 6LNs that have not registered for 562 multicast groups the packets belong to. In the opposite direction, a 563 6LN can only transmit data to or through the 6LBR. Hence, when a 6LN 564 needs to transmit an IPv6 multicast packet, the 6LN will unicast the 565 corresponding DECT ULE packet to the 6LBR. The 6LBR will then 566 forward the multicast packet to other 6LNs. 568 3.2.4. Header Compression 570 Header compression as defined in [RFC6282], which specifies the 571 compression format for IPv6 datagrams on top of IEEE 802.15.4, is 572 REQUIRED in this document as the basis for IPv6 header compression on 573 top of DECT ULE. All headers MUST be compressed according to 574 [RFC6282] encoding formats. The DECT ULE's star topology structure, 575 ARO and 6CO can be exploited in order to provide a mechanism for 576 address compression. The following text describes the principles of 577 IPv6 address compression on top of DECT ULE. 579 3.2.4.1. Link-local Header Compression 581 In a link-local communication terminated at 6LN and 6LBR, both the 582 IPv6 source and destination addresses MUST be elided, since the used 583 IIDs map uniquely into the DECT link end point addresses. A 6LN or 584 6LBR that receives a PDU containing an IPv6 packet can infer the 585 corresponding IPv6 source address. For the unicast type of 586 communication considered in this paragraph, the following settings 587 MUST be used in the IPv6 compressed header: CID=0, SAC=0, SAM=11, 588 DAC=0, DAM=11. 590 3.2.4.2. Non-link-local Header Compression 592 To enable efficient header compression, the 6LBR MUST include 6LoWPAN 593 Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises 594 in Router Advertisements for use in stateless address 595 autoconfiguration. 597 When a 6LN transmits an IPv6 packet to a destination using global 598 Unicast IPv6 addresses, if a context is defined for the prefix of the 599 6LNs global IPv6 address, the 6LN MUST indicate this context in the 600 corresponding source fields of the compressed IPv6 header as per 601 Section 3.1 of [RFC6282], and MUST fully elide the latest registered 602 IPv6 source address. For this, the 6LN MUST use the following 603 settings in the IPv6 compressed header: CID=1, SAC=1, SAM=11. In 604 this case, the 6LBR can infer the elided IPv6 source address since 1) 605 the 6LBR has previously assigned the prefix to the 6LNs; and 2) the 606 6LBR maintains a Neighbor Cache that relates the Device Address and 607 the IID of the corresponding PP. If a context is defined for the 608 IPv6 destination address, the 6LN MUST also indicate this context in 609 the corresponding destination fields of the compressed IPv6 header, 610 and MUST elide the prefix of the destination IPv6 address. For this, 611 the 6LN MUST set the DAM field of the compressed IPv6 header as 612 CID=1, DAC=1 and DAM=01 or DAM=11. Note that when a context is 613 defined for the IPv6 destination address, the 6LBR can infer the 614 elided destination prefix by using the context. 616 When a 6LBR receives a IPv6 packet having a global Unicast IPv6 617 address, and the destination of the packet is a 6LN, if a context is 618 defined for the prefix of the 6LN's global IPv6 address, the 6LBR 619 MUST indicate this context in the corresponding destination fields of 620 the compressed IPv6 header, and MUST fully elide the IPv6 destination 621 address of the packet if the destination address is the latest 622 registered by the 6LN for the indicated context. For this, the 6LBR 623 MUST set the DAM field of the IPv6 compressed header as DAM=11. CID 624 and DAC MUST be set to CID=1 and DAC=1. If a context is defined for 625 the prefix of the IPv6 source address, the 6LBR MUST indicate this 626 context in the source fields of the compressed IPv6 header, and MUST 627 elide that prefix as well. For this, the 6LBR MUST set the SAM field 628 of the IPv6 compressed header as CID=1, SAC=1 and SAM=01 or SAM=11. 630 3.3. Subnets and Internet Connectivity Scenarios 632 In the DECT ULE star topology (see Section 2.2), PP each have a 633 separate link to the FP and the FP acts as an IPv6 router rather than 634 a link-layer switch. A Multi-Link Subnet model [RFC4903] has been 635 chosen, specifically Non-broadcast multi-access (NBMA) at layer 2 as 636 further illustrated in Figure 5. The 6LBR forwards packets sent by 637 one 6LN to another. In a typical scenario, the DECT ULE network is 638 connected to the Internet as shown in the Figure 5. In this 639 scenario, the DECT ULE network is deployed as one subnet, using one 640 /64 IPv6 prefix. The 6LBR is acting as router and forwarding packets 641 between 6LNs and to and from Internet. 643 6LN 644 \ ____________ 645 \ / \ 646 6LN ---- 6LBR ------ | Internet | 647 / \____________/ 648 / 649 6LN 651 <-- One subnet --> 652 <-- DECT ULE --> 654 Figure 5: DECT ULE network connected to the Internet 656 In some scenarios, the DECT ULE network may transiently or 657 permanently be an isolated network as shown in the Figure 6. In this 658 case the whole DECT ULE network consists of a single subnet with 659 multiple links, where 6LBR is routing packets between 6LNs. 661 6LN 6LN 662 \ / 663 \ / 664 6LN --- 6LBR --- 6LN 665 / \ 666 / \ 667 6LN 6LN 669 <---- One subnet ----> 670 <------ DECT ULE -----> 672 Figure 6: Isolated DECT ULE network 674 In the isolated network scenario, communications between 6LN and 6LBR 675 can use IPv6 link-local methodology, but for communications between 676 different PP, the FP has to act as 6LBR, number the network with ULA 677 prefix [RFC4193], and route packets between PP. 679 In other more advanced systems scenarios with multiple FP and 6LBR, 680 each DECT ULE FP constitutes a wireless cell. The network can be 681 configured as a Multi-Link Subnet, in which the can 6LN operate 682 within the same /64 subnet prefix in multiple cells as shown in the 683 Figure 7. The FPs operation role in such scenario are rather like 684 Backbone Routers (6BBR) than 6LBR, as per [I-D.ietf-6lo-backbone- 685 router]. 687 ____________ 688 / \ 689 | Internet | 690 \____________/ 691 | 692 | 693 | 694 | 695 6BBR/ | 6BBR/ 696 6LN ---- 6LBR -------+------- 6LBR ---- 6LN 697 / \ / \ 698 / \ / \ 699 6LN 6LN 6LN 6LN 701 <------------------One subnet ------------------> 702 <-- DECT ULE Cell --> <-- DECT ULE Cell --> 704 Figure 7: Multiple DECT ULE cells in a single Multi-Link subnet 706 4. IANA Considerations 708 There are no IANA considerations related to this document. 710 5. Security Considerations 712 The secure transmission of speech over DECT will be based on the 713 DSAA2 and DSC/DSC2 specification developed by ETSI TC DECT and the 714 ETSI SAGE Security expert group. 716 DECT ULE communications are secured at the link-layer (DLC) by 717 encryption and per-message authentication through CCM mode (Counter 718 with CBC-MAC) similar to [RFC3610]. The underlying algorithm for 719 providing encryption and authentication is AES128. 721 The DECT ULE pairing procedure generates a master authentication key 722 (UAK). During location registration procedure or when the permanent 723 virtual circuit are established, the session security keys are 724 generated. Session security keys may be renewed regularly. The 725 generated security keys (UAK and session security keys) are 726 individual for each FP-PP binding, hence all PP in a system have 727 different security keys. DECT ULE PPs do not use any shared 728 encryption key. 730 From privacy point of view, the IPv6 link-local address configuration 731 described in Section 3.2.1 only reveals information about the 6LN to 732 the 6LBR that the 6LBR already knows from the link-layer connection. 733 For non-link-local IPv6 addresses, by default a 6LN SHOULD use a 734 randomly generated IID, for example, as discussed in [I-D.ietf-6man- 735 default-iids], or use alternative schemes such as Cryptographically 736 Generated Addresses (CGA) [RFC3972], privacy extensions [RFC4941], 737 Hash-Based Addresses (HBA, [RFC5535]), or static, semantically opaque 738 addresses [RFC7217]. 740 6. ETSI Considerations 742 ETSI is standardizing a list of known application layer protocols 743 that can use the DECT ULE permanent virtual circuit packet data 744 service. Each protocol is identified by a unique known identifier, 745 which is exchanged in the service-change procedure as defined in 746 [TS102.939-1]. The IPv6/6LoWPAN as described in this document is 747 considered as an application layer protocol on top of DECT ULE. In 748 order to provide interoperability between 6LoWPAN / DECT ULE devices 749 a common protocol identifier for 6LoWPAN is standardized by ETSI. 751 The ETSI DECT ULE Application Protocol Identifier is specified to 752 0x06 for 6LoWPAN [TS102.939-1]. 754 7. Acknowledgements 756 We are grateful to the members of the IETF 6lo working group; this 757 document borrows liberally from their work. 759 Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan and 760 Pascal Thubert have provided valuable feedback for this draft. 762 8. References 764 8.1. Normative References 766 [EN300.175-part1-7] 767 ETSI, "Digital Enhanced Cordless Telecommunications 768 (DECT); Common Interface (CI);", March 2015, 769 . 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 779 Host Configuration Protocol (DHCP) version 6", RFC 3633, 780 DOI 10.17487/RFC3633, December 2003, 781 . 783 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 784 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 785 . 787 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 788 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 789 2006, . 791 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 792 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 793 DOI 10.17487/RFC4861, September 2007, 794 . 796 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 797 Address Autoconfiguration", RFC 4862, 798 DOI 10.17487/RFC4862, September 2007, 799 . 801 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 802 Extensions for Stateless Address Autoconfiguration in 803 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 804 . 806 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 807 "Transmission of IPv6 Packets over IEEE 802.15.4 808 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 809 . 811 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 812 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 813 DOI 10.17487/RFC6282, September 2011, 814 . 816 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 817 Bormann, "Neighbor Discovery Optimization for IPv6 over 818 Low-Power Wireless Personal Area Networks (6LoWPANs)", 819 RFC 6775, DOI 10.17487/RFC6775, November 2012, 820 . 822 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 823 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 824 February 2014, . 826 [TS102.939-1] 827 ETSI, "Digital Enhanced Cordless Telecommunications 828 (DECT); Ultra Low Energy (ULE); Machine to Machine 829 Communications; Part 1: Home Automation Network (phase 830 1)", March 2015, . 834 [TS102.939-2] 835 ETSI, "Digital Enhanced Cordless Telecommunications 836 (DECT); Ultra Low Energy (ULE); Machine to Machine 837 Communications; Part 2: Home Automation Network (phase 838 2)", March 2015, . 842 8.2. Informative References 844 [CAT-iq] DECT Forum, "Cordless Advanced Technology - internet and 845 quality", January 2016, 846 . 849 [I-D.ietf-6lo-backbone-router] 850 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 851 backbone-router-02 (work in progress), September 2016. 853 [I-D.ietf-6lo-privacy-considerations] 854 Thaler, D., "Privacy Considerations for IPv6 over Networks 855 of Resource-Constrained Nodes", draft-ietf-6lo-privacy- 856 considerations-03 (work in progress), September 2016. 858 [I-D.ietf-6man-default-iids] 859 Gont, F., Cooper, A., Thaler, D., and S. LIU, 860 "Recommendation on Stable IPv6 Interface Identifiers", 861 draft-ietf-6man-default-iids-16 (work in progress), 862 September 2016. 864 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 865 C., and M. Carney, "Dynamic Host Configuration Protocol 866 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 867 2003, . 869 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 870 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 871 2003, . 873 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 874 RFC 3972, DOI 10.17487/RFC3972, March 2005, 875 . 877 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 878 DOI 10.17487/RFC4903, June 2007, 879 . 881 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 882 DOI 10.17487/RFC5535, June 2009, 883 . 885 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 886 Interface Identifiers with IPv6 Stateless Address 887 Autoconfiguration (SLAAC)", RFC 7217, 888 DOI 10.17487/RFC7217, April 2014, 889 . 891 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 892 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 893 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 894 . 896 Authors' Addresses 898 Peter B. Mariager 899 RTX A/S 900 Stroemmen 6 901 DK-9400 Noerresundby 902 Denmark 904 Email: pm@rtx.dk 906 Jens Toftgaard Petersen (editor) 907 RTX A/S 908 Stroemmen 6 909 DK-9400 Noerresundby 910 Denmark 912 Email: jtp@rtx.dk 913 Zach Shelby 914 ARM 915 150 Rose Orchard 916 San Jose, CA 95134 917 USA 919 Email: zach.shelby@arm.com 921 Marco van de Logt 922 Gigaset Communications GmbH 923 Frankenstrasse 2 924 D-46395 Bocholt 925 Germany 927 Email: marco.van-de-logt@gigaset.com 929 Dominique Barthel 930 Orange Labs 931 28 chemin du Vieux Chene 932 38243 Meylan 933 France 935 Email: dominique.barthel@orange.com