idnits 2.17.1 draft-ietf-6lo-dect-ule-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 19, 2014) is 3570 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) ** Downref: Normative reference to an Informational RFC: RFC 3610 ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group P. Mariager, Ed. 3 Internet-Draft J. Petersen 4 Intended status: Standards Track RTX A/S 5 Expires: December 21, 2014 Z. Shelby 6 Sensinode 7 M. Van de Logt 8 Gigaset Communications GmbH 9 D. Barthel 10 Orange Labs 11 June 19, 2014 13 Transmission of IPv6 Packets over DECT Ultra Low Energy 14 draft-ietf-6lo-dect-ule-00 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 15 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 December 21, 2014. 55 Copyright Notice 57 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 4 76 2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 4 77 2.2. Link layer roles and topology . . . . . . . . . . . . . . 5 78 2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 6 79 2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7 80 2.5. Additional Considerations . . . . . . . . . . . . . . . . 7 81 3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 7 82 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 8 83 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8 84 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 12 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 89 8. Normative References . . . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface 95 technology building on the key fundamentals of traditional DECT / 96 CAT-iq but with specific changes to significantly reduce the power 97 consumption on the expense of data throughput. DECT ULE devices with 98 requirements to power consumption will operate on special power 99 optimized silicon, but can connect to a DECT Gateway supporting 100 traditional DECT / CAT-iq for cordless telephony and data as well as 101 the ULE extensions. DECT terminology operates with two major role 102 definitions: The Portable Part (PP) is the power constrained device, 103 while the Fixed Part (FP) is the Gateway or base station. This FP 104 may be connected to the Internet. An example of a use case for DECT 105 ULE is a home security sensor transmitting small amounts of data (few 106 bytes) at periodic intervals through the FP, but is able to wake up 107 upon an external event (burglar) and communicate with the FP. 108 Another example incorporating both DECT ULE as well as traditional 109 CAT-iq telephony is an elderly pendant (broche) which can transmit 110 periodic status messages to a care provider using very little 111 battery, but in the event of urgency, the elderly person can 112 establish a voice connection through the pendant to an alarm service. 113 It is expected that DECT ULE will be integrated into many residential 114 gateways, as many of these already implements DECT CAT-iq for 115 cordless telephony. DECT ULE can be added as a software option for 116 the FP. It is desirable to consider IPv6 for DECT ULE devices due to 117 the large address space and well-known infrastructure. This document 118 describes how IPv6 is used on DECT ULE links to optimize power while 119 maintaining the many benefits of IPv6 transmission. [RFC4944] 120 specifies the transmission of IPv6 over IEEE 802.15.4. DECT ULE has 121 in many ways similar characteristics of IEEE 802.15.4, but also 122 differences. Many of the mechanisms defined in [RFC4944] can be 123 applied to the transmission of IPv6 on DECT ULE links. 125 This document specifies how to map IPv6 over DECT ULE inspired by 126 [RFC4944]. 128 1.1. Requirements Notation 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 1.2. Terms Used 136 PP: DECT Portable Part, typically the sensor node 138 FP: DECT Fixed Part, the gateway 139 LLME: Lower Layer Management Entity 141 NWK: Network 143 PVC: Permanent Virtual Circuit 145 FAR: Fragmentation and Reassembly 147 2. DECT Ultra Low Energy 149 DECT ULE is a low power air interface technology that is designed to 150 support both circuit switched for service, such as voice 151 communication, and for packet mode data services at modest data rate. 152 This draft is only addressing the packet mode data service of DECT 153 ULE. 155 2.1. The DECT ULE Protocol Stack 157 The DECT ULE protocol stack consists of the PHY layer operating at 158 frequencies in the 1880 - 1920 MHz frequency band depending on the 159 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 160 allocated by use of FDMA/TDMA/TDD technics. 162 In its generic network topology, DECT is defined as a cellular 163 network technology. However, the most common configuration is a star 164 network with a single FP defining the network with a number of PP 165 attached. The MAC layer supports both traditional DECT as this is 166 used for services like discovery, pairing, security features etc. 167 All these features have been reused from DECT. 169 The DECT ULE device can switch to the ULE mode of operation, 170 utilizing the new ULE MAC layer features. The DECT ULE Data Link 171 Control (DLC) provides multiplexing as well as segmentation and re- 172 assembly for larger packets from layers above. The DECT ULE layer 173 also implements per-message authentication and encryption. The DLC 174 layer ensures packet integrity and preserves packet order, but 175 delivery is based on best effort. 177 The current DECT ULE MAC layer standard supports low bandwidth data 178 broadcast. However the usage of this broadcast service has not yet 179 been standardized for higher layers. This document is not 180 considering usage of this DECT ULE MAC broadcast service in current 181 version. 183 In general, communication sessions can be initiated from both FP and 184 PP side. Depending of power down modes employed in the PP, latency 185 may occur when initiating sessions from FP side. MAC layer 186 communication can either take place using connection oriented packet 187 transfer with low overhead for short sessions or take place using 188 connection oriented bearers including media reservation. The MAC 189 layer autonomously selects the radio spectrum positions that are 190 available within the band and can rearrange these to avoid 191 interference. The MAC layer has built-in retransmission procedures 192 in order to improve transmission reliability. 194 The DECT ULE device will typically incorporate an Application 195 Programmers Interface (API) as well as common elements known as 196 Generic Access Profile (GAP) for enrolling into the network. The 197 DECT ULE stack establishes a permanent virtual circuit (PVC) for the 198 application layers and provides support for a range of different 199 application protocols. The used application protocol is negotiated 200 between the PP and FP when the PVC communication service is 201 established. This draft proposes to define 6LoWPAN as one of the 202 possible protocols to negotiate. 204 +----------------------------------------+ 205 | Applications | 206 +----------------------------------------+ 207 | Generic Access | ULE Profile | 208 | Profile | | 209 +----------------------------------------+ 210 | DECT/Service API | ULE Data API | 211 +--------------------+-------------------+ 212 | LLME | NWK (MM,CC)| | 213 +--------------------+-------------------+ 214 | DECT DLC | DECT ULE DLC | 215 +--------------------+-------------------+ 216 | MAC Layer | 217 +--------------------+-------------------+ 218 | Physical Layer | 219 +--------------------+-------------------+ 220 (C-plane) (U-plane) 222 Figure 1: DECT ULE Protocol Stack 224 The DECT ULE stack can be divided into control (C-plane) and user- 225 data (U-plane) parts shown to the left and to the right in figure 1, 226 respectively. 228 2.2. Link layer roles and topology 230 A FP is assumed to be less constrained than a PP. Hence, in the 231 primary scenario FP and PP will act as 6LoWPAN Border Router (6LBR) 232 and a 6LoWPAN Node (6LN), respectively. This document does only 233 address this primary scenario. 235 In DECT ULE, communication only takes place between a FP and a PP. A 236 FP is able to handle multiple simultaneous connections with a number 237 of PP. Hence, in a DECT ULE network using IPv6, a radio hop is 238 equivalent to an IPv6 link and vice versa. 240 [DECT ULE PP]-----\ /-----[DECT ULE PP] 241 \ / 242 [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP] 243 / \ 244 [DECT ULE PP]-----/ \-----[DECT ULE PP] 246 Figure 2: DECT ULE star topology 248 DECT ULE repeaters are not considered in this proposal. 250 2.3. Addressing Model 252 Each DECT PP is assigned an (International Portable Equipment 253 Identity) during manufacturing. This identity has the size of 40 254 bits and is DECT globally unique for the PP and can be used to 255 constitute the MAC address. However, it can not be used to derive a 256 globally unique IID. 258 When bound to a FP, a PP is assigned a 20 bit TPUI (Temporary 259 Portable User Identity) which is unique within the FP. This TPUI is 260 used for addressing (layer 2) in messages between FP and PP. 262 Each DECT FP is assigned a (Radio Fixed Part Identity) during 263 manufacturing. This identity has the size of 40 bits and is globally 264 unique for a FP and can be used to constitute the MAC address. 265 However, it can not be used to derive a globally unique IID. 267 Alternatively each DECT PP and DECT FP can be assigned a unique 268 (IEEE) MAC-48 address additionally to the DECT identities to be used 269 by the 6LoWPAN. With such an approach, the FP and PP have to 270 implement a mapping between used MAC-48 addresses and DECT 271 identities. 273 2.4. MTU Considerations 275 Generally the DECT ULE FP and PP may be generating data that fits 276 into a single MAC Layer packet (38 bytes) for periodically 277 transferred information, depending on application. IP data packets 278 may be much larger and hence MTU size should be the size of the IP 279 data packet. The DECT ULE DLC procedures supports segmentation and 280 reassembly of any MTU size below 65536 bytes, but most 281 implementations do only support smaller values. The default MTU size 282 in DECT ULE is 500 octets, but it is assumed it is configured to fit 283 the requirements from IPv6 data packets, hence [RFC4944] 284 fragmentation/reassembly is not required. 286 It is expected that the LOWPAN_IPHC packet will fulfill all the 287 requirements for header compression without spending unnecessary 288 overhead for mesh addressing. 290 It is important to realize that the usage of larger packets will be 291 on the expense of battery life, as a large packet inside the DECT ULE 292 stack will be fragmented into several or many MAC layer packets, each 293 consuming power to transmit / receive. 295 2.5. Additional Considerations 297 The DECT ULE standard allows PP to be registered (bind) to multiple 298 FP and roaming between these FP. This draft does not consider the 299 scenarios of PP roaming between multiple FP. The use of repeater 300 functionality is also not considered in this draft. 302 3. Specification of IPv6 over DECT ULE 304 DECT ULE technology sets strict requirements for low power 305 consumption and thus limits the allowed protocol overhead. 6LoWPAN 306 standards [RFC4944], [RFC6775], and [RFC6282] provide useful 307 functionality for reducing overhead which can be applied to DECT ULE. 308 This functionality comprises link-local IPv6 addresses and stateless 309 IPv6 address autoconfiguration, Neighbor Discovery and header 310 compression. 312 The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC 313 layer. Figure 3 illustrates IPv6 over DECT ULE stack. 315 A significant difference between IEEE 802.15.4 and DECT ULE is that 316 the former supports both star and mesh topology (and requires a 317 routing protocol), whereas DECT ULE in it's primary configuration 318 does not support the formation of multihop networks at the link 319 layer. In consequence, the mesh header defined in [RFC4944] for mesh 320 under routing MUST NOT be used in DECT ULE networks. In addition, a 321 DECT ULE PP node MUST NOT play the role of a 6LoWPAN Router (6LR). 323 3.1. Protocol stack 325 In order to enable transmission of IPv6 packets over DECT ULE, a 326 Permanent Virtual Circuit (PVC) has to be opened between FP and PP. 327 This MUST be done by setting up a service call from PP to FP. The PP 328 SHALL specify the <> in a service-change (other) 329 message before sending a service-change (resume) message as defined 330 in [TS102.939-1]. The <> SHALL define the ULE 331 Application Protocol Identifier to 0x06 (reserved for 6LoWPAN and has 332 to be standardized by ETSI) and the MTU size to 1280 octets or 333 larger. The FP MUST send a service-change-accept (resume) containing 334 a valid paging descriptor. The PP MUST be pageable. 336 +-------------------+ 337 | UDP/TCP/other | 338 +-------------------+ 339 | IPv6 | 340 +-------------------+ 341 |6LoWPAN adapted to | 342 | DECT ULE | 343 +-------------------+ 344 | DECT ULE DLC | 345 +-------------------+ 346 | DECT ULE MAC | 347 +-------------------+ 348 | DECT ULE PHY | 349 +-------------------+ 351 Figure 3: IPv6 over DECT ULE Stack 353 3.2. Link model 355 The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is 356 layer 2. The DECT ULE implements FAR functionality and [RFC4944] 357 fragmentation and reassembly function is not needed. Since IPv6 358 requires MTU size of at least 1280 octets, the DECT ULE connection 359 (PVC) must be configured with equivalent MTU size. 361 This specification also assumes the IPv6 header compression format 362 specified in [RFC6282]. It is also assumed that the IPv6 payload 363 length can be inferred from the ULE DLC packet length and the IID 364 value inferred from the link-layer address. 366 Due to DECT ULE star topology, each branch of the star is considered 367 to be an individual link and thus the PPs cannot directly hear one 368 another and also cannot talk to one another with link-local 369 addresses. After the FP and PPs have connected at the DECT ULE 370 level, the link can be considered up and IPv6 address configuration 371 and transmission can begin. The FP ensures address collisions do not 372 occur. 374 3.2.1. Stateless address autoconfiguration 376 A DECT ULE 6LN performs stateless address autoconfiguration as per 377 [RFC4862]. A 64-bit Interface identifier (IID) for a DECT ULE 378 interface MAY be formed by utilizing a MAC-48 device address as 379 defined in [RFC2464] "IPv6 over Ethernet" specification. 380 Alternatively, the DECT device addresses IPEI, RFPI or TPUI, MAY be 381 used instead to derive the IID. In the case of randomly generated 382 IID or use of IID derived from DECT devices addresses, the 383 "Universal/Local" bit MUST be set to 0. Only if a global unique 384 MAC-48 is used the "Universal/Local" bit can be set to 1. 386 As defined in [RFC4291], the IPv6 link-local address for a DECT ULE 387 node is formed by appending the IID, to the prefix FE80::/64, as 388 shown in Figure 4. 390 10 bits 54 bits 64 bits 391 +----------+-----------------+----------------------+ 392 |1111111010| zeros | Interface Identifier | 393 +----------+-----------------+----------------------+ 395 Figure 4: IPv6 link-local address in DECT ULE 397 The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT 398 ULE network is out of scope of this document, but can be, for 399 example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by 400 using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to 401 the link model of the DECT ULE the 6LBR MUST set the "on-link" flag 402 (L) to zero in the Prefix Information Option [RFC4861]. This will 403 cause 6LNs to always send packets to the 6LBR, including the case 404 when the destination is another 6LN using the same prefix. 406 3.2.2. Neighbor discovery 408 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 409 Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor 410 discovery approach as adapted for use in several 6LoWPAN topologies, 411 including the mesh topology. As DECT ULE is considered not to 412 support mesh networks, hence only those aspects that apply to a star 413 topology are considered. 415 The following aspects of the Neighbor Discovery optimizations 416 [RFC6775] are applicable to DECT ULE 6LNs: 418 1. A DECT ULE 6LN MUST register its address with the 6LBR by sending 419 a Neighbor Solicitation (NS) message with the ARO option and process 420 the Neighbor Advertisement (NA) accordingly. The NS with the ARO 421 option SHOULD be sent irrespective of whether the IID is derived from 422 a unique MAC-48 bit device address, from the DECT ULE device 423 addresses or the IID is a random value that is generated as per the 424 privacy extensions for stateless address autoconfiguration [RFC4941]. 425 Although [RFC4941] permits the use of deprecated addresses for old 426 connections, in this specification we mandate that one interface MUST 427 NOT use more than one IID at any one time. 429 2. For sending Router Solicitations and processing Router 430 Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections 431 5.3 and 5.4 of the [RFC6775]. 433 3.2.3. Unicast and Multicast address mapping 435 The DECT MAC layer broadcast service is considered inadequate for IP 436 multicast. 438 Hence traffic is always unicast between two DECT ULE nodes. Even in 439 the case where a FP is attached to multiple PPs, the FP cannot do a 440 multicast to all the connected PPs. If the FP needs to send a 441 multicast packet to all its PPs, it has to replicate the packet and 442 unicast it on each link. However, this may not be energy-efficient 443 and particular care must be taken if the FP is battery-powered. In 444 the opposite direction, a PP can only transmit data to a single 445 destination (i.e. the FP). Hence, when a PP needs to transmit an 446 IPv6 multicast packet, the PP will unicast the corresponding DECT ULE 447 packet to the FP. As described in the linkmodel section, the FP will 448 not forward link-local multicast messages to other PPs connected to 449 the FP. 451 3.2.4. Header Compression 453 Header compression as defined in [RFC6282], which specifies the 454 compression format for IPv6 datagrams on top of IEEE 802.15.4, is 455 REQUIRED in this document as the basis for IPv6 header compression on 456 top of DECT ULE. All headers MUST be compressed according to 457 [RFC6282] encoding formats. The DECT ULE's star topology structure 458 can be exploited in order to provide a mechanism for IID compression. 460 The following text describes the principles of IPv6 address 461 compression on top of DECT ULE. 463 In a link-local communication, both the IPv6 source and destination 464 addresses MUST be elided [RFC6282], since the node knows that the 465 packet is destined for it even if the packet does not have 466 destination IPv6 address. A node SHALL learn the IID of the other 467 endpoint of each DECT ULE connection it participates in. By 468 exploiting this information, a node that receives a PDU containing an 469 IPv6 packet can infer the corresponding IPv6 source address. A node 470 MUST maintain a Neighbor Cache, in which the entries include both the 471 IID of the neighbor and the Device Address that identifies the 472 neighbor. For the type of communication considered in this 473 paragraph, the following settings MUST be used in the IPv6 compressed 474 header: CID=0, SAC=0, SAM=11, DAC=0, DAM=11. 476 When a 6LN transmits an IPv6 packet to a remote destination using 477 global Unicast IPv6 addresses, if a context is defined for the prefix 478 of the 6LNs global IPv6 address, the 6LN MUST indicate this context 479 in the corresponding source fields of the compressed IPv6 header as 480 per Section 3.1 of [RFC6282], and MUST elide the IPv6 source address. 481 For this, the 6LN MUST use the following settings in the IPv6 482 compressed header: CID=1, SAC=1, SAM=11. In this case, the 6LBR can 483 infer the elided IPv6 source address since 1) the 6LBR has previously 484 assigned the prefix to the 6LNs; and 2) the 6LBR maintains a Neighbor 485 Cache that relates the Device Address and the IID of the 486 corresponding PP. If a context is defined for the IPv6 destination 487 address, the 6LN MUST also indicate this context in the corresponding 488 destination fields of the compressed IPv6 header, and MUST elide the 489 prefix of the destination IPv6 address. For this, the 6LN MUST set 490 the DAM field of the compressed IPv6 header as DAM=01 (if the context 491 covers a 64-bit prefix) or as DAM=11 (if the context covers a full, 492 128-bit address). CID and DAC MUST be set to CID=1 and DAC=1. Note 493 that when a context is defined for the IPv6 destination address, the 494 6LBR can infer the elided destination prefix by using the context. 496 When a 6LBR receives an IPv6 packet sent by a remote node outside the 497 DECT ULE network, and the destination of the packet is a 6LN, if a 498 context is defined for the prefix of the 6LN's global IPv6 address, 499 the 6LBR MUST indicate this context in the corresponding destination 500 fields of the compressed IPv6 header, and MUST elide the IPv6 501 destination address of the packet before forwarding it to the 6LN. 502 For this, the 6LBR MUST set the DAM field of the IPv6 compressed 503 header as DAM=11. CID and DAC MUST be set to CID=1 and DAC=1. If a 504 context is defined for the prefix of the IPv6 source address, the 505 6LBR MUST indicate this context in the source fields of the 506 compressed IPv6 header, and MUST elide that prefix as well. For 507 this, the 6LBR MUST set the SAM field of the IPv6 compressed header 508 as SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the 509 context covers a full, 128-bit address). CID and SAC MUST be set to 510 CID=1 and SAC=1. 512 3.3. Internet connectivity scenarios 514 In a typical scenario, the DECT ULE network is connected to the 515 Internet as shown in the Figure 5. 517 A degenerate scenario can be imagined where a PP is acting as 6LBR 518 and providing Internet connectivity for the FP. How the FP could 519 then further provide Internet connectivity to other PP, possibly 520 connected to the FP, is out of the scope of this document. 522 6LN 523 \ ____________ 524 \ / \ 525 6LN ---- 6LBR --- | Internet | 526 / \____________/ 527 / 528 6LN 530 <-- DECT ULE --> 532 Figure 5: DECT ULE network connected to the Internet 534 In some scenarios, the DECT ULE network may transiently or 535 permanently be an isolated network as shown in the Figure 6. 537 6LN 6LN 538 \ / 539 \ / 540 6LN --- 6LBR --- 6LN 541 / \ 542 / \ 543 6LN 6LN 545 <------ DECT ULE -----> 547 Figure 6: Isolated DECT ULE network 549 In the isolated network scenario, communications between 6LN and 6LBR 550 can use IPv6 link-local methodology, but for communications between 551 different PP, the FP has to act as 6LBR, number the network with ULA 552 prefix [RFC4193], and route packets between PP. 554 4. IANA Considerations 556 There are no IANA considerations related to this document. 558 5. Security Considerations 560 The secure transmission of speech over DECT will be based on the 561 DSAA2 and DSC2 work being developed by the DF Security group / ETSI 562 TC DECT and the ETSI SAGE Security expert group. 564 DECT ULE communications are secured at the link-layer (DLC) by 565 encryption and per-message authentication through CCM mode (Counter 566 with CBC-MAC) similar to [RFC3610]. The underlying algorithm for 567 providing encryption and authentication is AES128. 569 The DECT ULE pairing procedure generates a master authentication key 570 (UAK) and during location registration procedure or when the 571 permanent virtual circuit are established, the session security keys 572 are generated. Session security keys may be renewed regularly. The 573 generated security keys (UAK and session security keys) are 574 individual for each FP-PP binding, hence all PP in a system have 575 different security keys. DECT ULE PPs do not use any shared 576 encryption key. 578 6. ETSI Considerations 580 ETSI is standardizing a list of known application layer protocols 581 that can use the DECT ULE permanent virtual circuit packet data 582 service. Each protocol is identified by a unique known identifier, 583 which is exchanged in the service-change procedure as defined in 584 [TS102.939-1]. The IPv6/6LoWPAN as described in this document is 585 considered as an application layer protocol on top of DECT ULE. In 586 order to provide interoperability between 6LoWPAN / DECT ULE devices 587 a common protocol identifier for 6LoWPAN has to be standardized by 588 ETSI. 590 It is proposed to use ETSI DECT ULE Application Protocol Identifier 591 equal 0x06 for 6LoWPAN. 593 7. Acknowledgements 595 8. Normative References 597 [EN300.175-part1-7] 598 ETSI, "Digital Enhanced Cordless Telecommunications 599 (DECT); Common Interface (CI);", August 2013. 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 605 Networks", RFC 2464, December 1998. 607 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 608 CBC-MAC (CCM)", RFC 3610, September 2003. 610 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 611 Host Configuration Protocol (DHCP) version 6", RFC 3633, 612 December 2003. 614 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 615 Addresses", RFC 4193, October 2005. 617 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 618 Architecture", RFC 4291, February 2006. 620 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 621 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 622 September 2007. 624 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 625 Address Autoconfiguration", RFC 4862, September 2007. 627 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 628 Extensions for Stateless Address Autoconfiguration in 629 IPv6", RFC 4941, September 2007. 631 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 632 "Transmission of IPv6 Packets over IEEE 802.15.4 633 Networks", RFC 4944, September 2007. 635 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 636 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 637 September 2011. 639 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 640 "Neighbor Discovery Optimization for IPv6 over Low-Power 641 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 642 November 2012. 644 [TS102.939-1] 645 ETSI, "Digital Enhanced Cordless Telecommunications 646 (DECT); Ultra Low Energy (ULE); Machine to Machine 647 Communications; Part 1: Home Automation Network (phase 648 1)", April 2013. 650 Authors' Addresses 652 Peter B. Mariager (editor) 653 RTX A/S 654 Stroemmen 6 655 DK-9400 Noerresundby 656 Denmark 658 Email: pm@rtx.dk 660 Jens Toftgaard Petersen 661 RTX A/S 662 Stroemmen 6 663 DK-9400 Noerresundby 664 Denmark 666 Email: jtp@rtx.dk 668 Zach Shelby 669 Sensinode 670 Hallituskatu 13-17D 671 FI-90100 Oulu 672 Finland 674 Email: zach.shelby@sensinode.com 676 Marco van de Logt 677 Gigaset Communications GmbH 678 Frankenstrasse 2 679 D-46395 Bocholt 680 Germany 682 Email: marco.van-de-logt@gigaset.com 683 Dominique Barthel 684 Orange Labs 686 Email: dominique.barthel@orange.com