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