idnits 2.17.1 draft-mariager-6lowpan-v6over-dect-ule-03.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 (July 15, 2013) is 3935 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6282' is mentioned on line 350, but not defined == Missing Reference: 'RFC6775' is mentioned on line 410, but not defined == Missing Reference: 'RFC4941' is mentioned on line 404, but not defined ** Obsolete undefined reference: RFC 4941 (Obsoleted by RFC 8981) == Missing Reference: 'RFC4193' is mentioned on line 530, but not defined == Unused Reference: 'I-D.ietf-6lowpan-hc' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6lowpan-nd' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 593, but no explicit reference was found in the text -- No information found for draft-ietf-6lowpan-hc - is the name correct? Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN P. Mariager, Ed. 3 Internet-Draft J. Petersen 4 Intended status: Informational RTX A/S 5 Expires: January 16, 2014 Z. Shelby 6 Sensinode 7 July 15, 2013 9 Transmission of IPv6 Packets over DECT Ultra Low Energy 10 draft-mariager-6lowpan-v6over-dect-ule-03 12 Abstract 14 DECT Ultra Low Energy is a low power air interface technology that is 15 defined by the DECT Forum and specified by ETSI. 17 The DECT air interface technology has been used world-wide in 18 communication devices for more than 15 years, primarily carrying 19 voice for cordless telephony but has also been deployed for data 20 centric services. 22 The DECT Ultra Low Energy is a recent addition to the DECT interface 23 primarily intended for low-bandwidth, low-power applications such as 24 sensor devices, smart meters, home automation etc. As the DECT Ultra 25 Low Energy interface inherits many of the capabilities from DECT, it 26 benefits from long range, interference free operation, world wide 27 reserved frequency band, low silicon prices and maturity. There is 28 an added value in the ability to communicate with IPv6 over DECT ULE 29 such as for Internet of Things applications. 31 This document describes how IPv6 is transported over DECT ULE using 32 6LoWPAN techniques. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 16, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 69 1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 4 71 2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 4 72 2.2. Link layer roles and topology . . . . . . . . . . . . . . 6 73 2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 7 74 2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7 75 2.5. Additional Considerations . . . . . . . . . . . . . . . . 8 76 3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 8 77 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 8 78 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8 79 3.3. Internet connectivity scenarios . . . . . . . . . . . . . 11 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 84 8. Normative References . . . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface 90 technology building on the key fundamentals of traditional DECT / 91 CAT-iq but with specific changes to significantly reduce the power 92 consumption on the expense of data throughput. DECT ULE devices with 93 requirements to power consumption will operate on special power 94 optimized silicon, but can connect to a DECT Gateway supporting 95 traditional DECT / CAT-iq for cordless telephony and data as well as 96 the ULE extensions. DECT terminology operates with two major role 97 definitions: The Portable Part (PP) is the power constrained device, 98 while the Fixed Part (FP) is the Gateway or base station. This FP 99 may be connected to the Internet. An example of a use case for DECT 100 ULE is a home security sensor transmitting small amounts of data (few 101 bytes) at periodic intervals through the FP, but is able to wake up 102 upon an external event (burglar) and communicate with the FP. 103 Another example incorporating both DECT ULE as well as traditional 104 CAT-iq telephony is an elderly pendant (broche) which can transmit 105 periodic status messages to a care provider using very little 106 battery, but in the event of urgency, the elderly person can 107 establish a voice connection through the pendant to an alarm service. 108 It is expected that DECT ULE will be integrated into many residential 109 gateways, as many of these already implements DECT CAT-iq for 110 cordless telephony. DECT ULE can be added as a software option for 111 the FP. It is desirable to consider IPv6 for DECT ULE devices due to 112 the large address space and well-known infrastructure. This document 113 describes how IPv6 is used on DECT ULE links to optimize power while 114 maintaining the many benefits of IPv6 transmission. [RFC4944] 115 specifies the transmission of IPv6 over IEEE 802.15.4. DECT ULE has 116 in many ways similar characteristics of IEEE 802.15.4, but also 117 differences. Many of the mechanisms defined in [RFC4944] can be 118 applied to the transmission of IPv6 on DECT ULE links. 120 This document specifies how to map IPv6 over DECT ULE inspired by 121 RFC4944 123 1.1. Requirements Notation 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 1.2. Terms Used 131 PP: DECT Portable Part, typically the sensor node 133 FP: DECT Fixed Part, the gateway 135 LLME: Lower Layer Management Entity 137 NWK: Network 139 2. DECT Ultra Low Energy 141 DECT ULE is a low power air interface technology that is designed to 142 support both circuit switched for service, such as voice 143 communication, and for packet mode data services at modest data rate. 144 This draft is only addressing the packet mode data service of DECT 145 ULE. 147 2.1. The DECT ULE Protocol Stack 149 The DECT ULE protocol stack consists of the PHY layer operating at 150 frequencies in the 1880 - 1920 MHz frequency band depending on the 151 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 152 allocated by use of FDMA/TDMA/TDD technics. 154 In its generic network topology, DECT is defined as a cellular 155 network technology. However, the most common configuration is a star 156 network with a single FP defining the network with a number of PP 157 attached. The MAC layer supports both traditional DECT as this is 158 used for services like discovery, pairing, security features etc. 159 All these features have been reused from DECT. 161 The DECT ULE device can then switch to the ULE mode of operation, 162 utilizing the new ULE MAC layer features. The DECT ULE Data Link 163 Control (DLC) provides multiplexing as well as segmentation and re- 164 assembly for larger packets from layers above. The DECT ULE layer 165 also implements per-message authentication and encryption. The DLC 166 layer ensures packet integrity and preserves packet order, but 167 delivery is based on best effort. 169 The current DECT ULE MAC layer standard supports low bandwidth data 170 broadcast. However the usage of this broadcast service has not yet 171 been standardized for higher layers and no security has been 172 developed been developed yet. This document is not considering usage 173 of this DECT ULE MAC broadcast service in current version. 175 In general, communication sessions can be initiated from both FP and 176 PP side. Depending of power down modes employed in the PP, latency 177 may occur when initiating sessions from FP side. MAC layer 178 communication can either take place using connection oriented packet 179 transfer with low overhead for short sessions or take place using 180 connection oriented bearers including media reservation. The MAC 181 layer autonomously selects the radio spectrum positions that are 182 available within the band and can rearrange these to avoid 183 interference. The MAC layer has built-in retransmission procedures 184 in order to improve transmission reliability. 186 The DECT ULE device will typically incorporate an Application 187 Programmers Interface (API) as well as common elements known as 188 Generic Access Profile (GAP) for enrolling into the network. The 189 DECT ULE stack establishes a permanent virtual circuit (PVC) for the 190 application layers and provides support for a range of different 191 application protocols. The used application protocol is negotiated 192 between the PP and FP when the PVC communication service is 193 established. This draft proposes to define 6LoWPAN as one of the 194 possible protocols to negotiate. 196 +----------------------------------------+ 197 | Applications | 198 +----------------------------------------+ 199 | Generic Access | ULE Profile | 200 | Profile | | 201 +----------------------------------------+ 202 | DECT/Service API | ULE Data API | 203 +--------------------+-------------------+ 204 | LLME | NWK (MM,CC)| | 205 +--------------------+-------------------+ 206 | DECT DLC | DECT ULE DLC | 207 +--------------------+-------------------+ 208 | MAC Layer | 209 +--------------------+-------------------+ 210 | Physical Layer | 211 +--------------------+-------------------+ 212 (C-plane) (U-plane) 214 Figure 1: DECT ULE Protocol Stack 216 The DECT ULE stack can be divided into control (C-plane) and user- 217 data (U-plane) parts shown to the left and to the right in figure 1, 218 respectively. 220 It is expected that the ULE 6LoWPAN adaptation layer can run directly 221 on this U-plane DLC layer. Figure 2 illustrates IPv6 over DECT ULE 222 stack. 224 Constrained Application Protocol (CoAP) is an application protocol 225 specifically designed for resource constrained environments. CoAP 226 could be run on top of IPv6 supporting requests from the server and 227 requests of cached replies from a CoAP/HTTP proxy in the DECT Fixed 228 Part or in an external network infrastructure. 230 +-------------------+ 231 | Applications | 232 +-------------------+ 233 | CoAP/HTTP | 234 +-------------------+ 235 |IPv6 adaption layer| 236 +-------------------+ 237 | DECT ULE DLC | 238 +-------------------+ 239 | DECT ULE MAC | 240 +-------------------+ 241 | DECT ULE PHY | 242 +-------------------+ 244 Figure 2: IPv6 over DECT ULE Stack 246 2.2. Link layer roles and topology 248 A FP is assumed to be less constrained than a PP. Hence, in the 249 primary scenario FP and PP will act as 6LoWPAN Border Router (6LBR) 250 and a 6LoWPAN Node (6LN), respectively. This document does only 251 address this primary scenario. 253 In DECT ULE, communication only takes place between a FP and a PP. A 254 FP is able to handle multiple simultaneous connections with a number 255 of PP. Hence, in a DECT ULE network using IPv6, a radio hop is 256 equivalent to an IPv6 link and vice versa. 258 [DECT ULE PP]-----\ /-----[DECT ULE PP] 259 \ / 260 [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP] 261 / \ 262 [DECT ULE PP]-----/ \-----[DECT ULE PP] 264 Figure 3: DECT ULE star topology 266 DECT ULE repeaters are not considered in this proposal. 268 2.3. Addressing Model 270 Each DECT PP is assigned an (International Portable Equipment 271 Identity) during manufacturing. This identity has the size of 40 272 bits and is globally unique for the PP and can be used to constitute 273 the MAC address. 275 When bound to a FP, a PP is assigned a 20 bit TPUI (Temporary 276 Portable User Identity) which is unique within the FP. This TPUI is 277 used for addressing (layer 2) in messages between FP and PP. 279 Each DECT FP is assigned a (Radio Fixed Part Identity) during 280 manufacturing. This identity has the size of 40 bits and is globally 281 unique for a FP and can be used to constitute the MAC address. 283 Alternatively each DECT PP and DECT FP can be assigned a unique 284 (IEEE) MAC-48 address additionally to the DECT identities to be used 285 by the 6LoWPAN. When such approach, the FP and PP have to implement 286 a mapping between used MAC-48 addresses and DECT identities. 288 2.4. MTU Considerations 290 Generally the DECT ULE FP and PP may be generating data that fits 291 into one MAC Layer packet (38 bytes) for periodically transferred 292 information, depending on application. IP data packets may be much 293 larger and hence MTU size should be the size of the IP data packet. 294 The DECT ULE DLC procedures supports segmentation and reassembly of 295 any MTU size below 65536 bytes, but most implementations do only 296 support smaller values. 298 If an implementation cannot support the sufficient MTU size (due to 299 implementation cost) then SAR needs to be supported at upper layers. 300 The SAR feature of [RFC4944] section 5 could be considered. 302 It is expected that the LOWPAN_IPHC packet will fulfill all the 303 requirements for header compression without spending unnecessary 304 overhead for mesh addressing. 306 It is important to realize that the support of larger packets will be 307 on the expense of battery life, as a large packet will be fragmented 308 into several or many MAC layer packets, each consuming power to 309 transmit / receive. 311 2.5. Additional Considerations 313 The DECT ULE standard allows PP to be registered (bind) to multiple 314 FP and roaming between these FP. This draft does not considered the 315 scenarios of PP roaming between multiple FP. The use of repeater 316 functionality is also not considered in this draft 318 3. Specification of IPv6 over DECT ULE 320 DECT ULE technology sets strict requirements for low power 321 consumption and thus limits the allowed protocol overhead. 6LoWPAN 322 standard [RFC4944] provides useful functionality for reducing 323 overhead which can be applied to DECT ULE. This functionality 324 comprises of link-local IPv6 addresses and stateless IPv6 address 325 autoconfiguration, Neighbor Discovery and header compression. 327 A significant difference between IEEE 802.15.4 and DECT ULE is that 328 the former supports both star and mesh topology (and requires a 329 routing protocol), whereas DECT ULE in it's primary configuration 330 does not support the formation of multihop networks at the link 331 layer. In consequence, the mesh header defined in [RFC4944] for mesh 332 under routing MUST NOT be used in DECT ULE networks. In addition, a 333 DECT ULE PP node MUST NOT play the role of a 6LoWPAN Router (6LR). 335 3.1. Protocol stack 337 DECT ULE standardization of protocol identifier in negotiation of 338 higher layer application protocol 6LoWPAN: xx. This identifier is 339 reserved for 6LoWPAN and has to be standardized by ETSI. 341 3.2. Link model 343 The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is 344 layer 2. The DECT ULE implements FAR functionality and RFC4944 MUST 345 NOT be used.Since IPv6 requires MTU size of at least 1280 octets, the 346 DECT ULE connection (PVC) must be configured with configured with 347 equivalent MTU size. 349 This specification also assumes the IPv6 header compression format 350 specified in [RFC6282]. It is also assumed that the IPv6 payload 351 length can be inferred from the ULE DLC packet length and the IID 352 value inferred from the link-layer address. 354 Due to DECT ULE star topology, each branch of the star is considered 355 to be an individual link and thus the PP cannot directly hear each 356 other and also cannot talk to each other with link-local addresses. 357 After the FP and PP have connected at the DECT ULE level, the link 358 can be considered up and IPv6 address configuration and transmission 359 can begin. The FP ensures address collisions do not occur. 361 3.2.1. IPv6 Address Configuration 363 A DECT ULE 6LN performs stateless address autoconfiguration as per 364 RFC 4862. A 64-bit Interface identifier (IID) for a DECT ULE 365 interface MAY be formed by utilizing a MAC-48 device address as 366 defined in RFC 2464 "IPv6 over Ethernet" specification. 367 Alternatively, the DECT device addresses IPEI, RFPI or TPUI, MAY be 368 used instead to derive the IID. In the case of randomly generated 369 IID or use of IID derived from DECT devices addresses, the "Universal 370 /Local" bit MUST be set to 0. Only if a global unique MAC-48 is used 371 the "Universal/Local" bit can be set to 1. 373 As defined in RFC 4291, the IPv6 link-local address for a DECT ULE 374 node is formed by appending the IID, to the prefix FE80::/64. 376 The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT 377 ULE network is out of scope of this document, but can be, for 378 example, accomplished via DHCPv6 Prefix Delegation or by using Unique 379 Local IPv6 Unicast Addresses (ULA). Due to the link model of the 380 DECT ULE the 6LBR MUST set the "on-link" flag (L) to zero in the 381 Prefix Information Option. This will cause 6LNs to always send 382 packets to the 6LBR, including the case when the destination is 383 another 6LN using the same prefix. 385 3.2.2. Neighbor discovery 387 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 388 Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor 389 discovery approach as adapted for use in several 6LoWPAN topologies, 390 including the mesh topology. As DECT ULE is considered not to 391 support mesh networks, hence only those aspects that apply to a star 392 topology are considered. 394 The following aspects of the Neighbor Discovery optimizations 395 [RFC6775] are applicable to DECT ULE 6LNs: 397 1. A DECT ULE 6LN MUST register its address with the 6LBR by sending 398 a Neighbor Solicitation (NS) message with the ARO option and process 399 the Neighbor Advertisement (NA) accordingly. The NS with the ARO 400 option SHOULD be sent irrespective of whether the IID is derived from 401 a unique MAC-48 bit device address, DECT ULE device addresses or the 402 IID is a random value that is generated as per the privacy extensions 403 for stateless address autoconfiguration [RFC4941]. Although RFC 4941 404 [RFC4941] permits the use of deprecated addresses for old 405 connections, in this specification we mandate that one interface MUST 406 NOT use more than one IID at any one time. 408 2. For sending Router Solicitations and processing Router 409 Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections 410 5.3 and 5.4 of the [RFC6775]. 412 3.2.3. Unicast and Multicast address mapping 414 The DECT MAC layer broadcast service is considered inadequate for IP 415 multicast. 417 Hence traffic is always unicast between two DECT ULE nodes. Even in 418 the case where a FP is attached to multiple PPs, the FP cannot do a 419 multicast to all the connected PPs. If the FP needs to send a 420 multicast packet to all its PPs, it has to replicate the packet and 421 unicast it on each link. However, this may not be energy-efficient 422 and particular care must be taken if the FP is battery-powered. In 423 the opposite direction, a PPs can only transmit data to a single 424 destination (i.e. the FP). Hence, when a PP needs to transmit an 425 IPv6 multicast packet, the PP will unicast the corresponding DECT ULE 426 packet to the FP. As described in the linkmodel section FP will not 427 forward link-local multicast messages to other PPs connected to the 428 FP. 430 3.2.4. Header Compression 432 Header compression as defined in RFC 6282, which specifies the 433 compression format for IPv6 datagrams on top of IEEE 802.15.4, is 434 REQUIRED in this document as the basis for IPv6 header compression on 435 top of DECT ULE. All headers MUST be compressed according to RFC 436 6282 encoding formats. The DECT ULE's star topology structure can be 437 exploited in order to provide a mechanism for IID compression. The 438 following text describes the principles of IPv6 address compression 439 on top of DECT ULE. 441 In a link-local communication, both the IPv6 source and destination 442 addresses MUST be elided, since the node knows that the packet is 443 destined for it even if the packet does not have destination IPv6 444 address. On the other hand, a node SHALL learn the IID of the other 445 endpoint of each DECT ULE connection it participates in. By 446 exploiting this information, a node that receives a data channel PDU 447 containing an IPv6 packet can infer the corresponding IPv6 source 448 address. A node MUST maintain a Neighbor Cache, in which the entries 449 include both the IID of the neighbor and the Device Address that 450 identifies the neighbor. For the type of communication considered in 451 this paragraph, the following settings MUST be used in the IPv6 452 compressed header: CID=0, SAC=0, SAM=11, DAC=0, DAM=11. 454 When a 6LN transmits an IPv6 packet to a remote destination using 455 global Unicast IPv6 addresses, if a context is defined for the prefix 456 of the 6LNs global IPv6 address, the 6LN MUST indicate this context 457 in the corresponding source fields of the compressed IPv6 header as 458 per Section 3.1 of RFC 6282, and MUST elide the IPv6 source address. 459 For this, the 6LN MUST use the following settings in the IPv6 460 compressed header: CID=1, SAC=1, SAM=11. In this case, the 6LBR can 461 infer the elided IPv6 source address since 1) the 6LBR has previously 462 assigned the prefix to the 6LNs; and 2) the 6LBR maintains a Neighbor 463 Cache that relates the Device Address and the IID of the 464 corresponding PP. If a context is defined for the IPv6 destination 465 address, the 6LN MUST also indicate this context in the corresponding 466 destination fields of the compressed IPv6 header, and MUST elide the 467 prefix of the destination IPv6 address. For this, the 6LN MUST set 468 the DAM field of the compressed IPv6 header as DAM=01 (if the context 469 covers a 64-bit prefix) or as DAM=11 (if the context covers a full, 470 128-bit address). CID and DAC MUST be set to CID=1 and DAC=1. Note 471 that when a context is defined for the IPv6 destination address, the 472 6LBR can infer the elided destination prefix by using the context. 474 When a 6LBR receives an IPv6 packet sent by a remote node outside the 475 DECT ULE network, and the destination of the packet is a 6LN, if a 476 context is defined for the prefix of the 6LN's global IPv6 address, 477 the 6LBR MUST indicate this context in the corresponding destination 478 fields of the compressed IPv6 header, and MUST elide the IPv6 479 destination address of the packet before forwarding it to the 6LN. 480 For this, the 6LBR MUST set the DAM field of the IPv6 compressed 481 header as DAM=11. CID and DAC MUST be set to CID=1 and DAC=1. If a 482 context is defined for the prefix of the IPv6 source address, the 483 6LBR MUST indicate this context in the source fields of the 484 compressed IPv6 header, and MUST elide that prefix as well. For 485 this, the 6LBR MUST set the SAM field of the IPv6 compressed header 486 as SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the 487 context covers a full, 128-bit address). CID and SAC MUST be set to 488 CID=1 and SAC=1. 490 3.3. Internet connectivity scenarios 492 In a typical scenario, the DECT ULE network is connected to the 493 Internet as shown in the Figure 4. 495 A degenerate scenario can be imagined where a PP is acting as 6LBR 496 and providing Internet connectivity for the FP. How the FP could 497 then further provide Internet connectivity to other PP, possibly 498 connected to the FP, is out of the scope of this document. 500 6LN 501 \ ____________ 502 \ / \ 503 6LN ---- 6LBR --- | Internet | 504 / \____________/ 505 / 506 6LN 508 <-- DECT ULE --> 510 Figure 4: DECT ULE network connected to the Internet 512 In some scenarios, the DECT ULE network may transiently or 513 permanently be an isolated network as shown in the Figure 5. 515 6LN 6LN 516 \ / 517 \ / 518 6LN --- 6LBR --- 6LN 519 / \ 520 / \ 521 6LN 6LN 523 <------ DECT ULE -----> 525 Figure 5: Isolated DECT ULE network 527 In the isolated network scenario communications between 6LN and 6LBR 528 can use IPv6 link-local methodology, but for communications between 529 different PP, the FP has to act as 6LBR, number the network with ULA 530 prefix [RFC4193], and route packets between PP. 532 4. IANA Considerations 534 There are no IANA considerations related to this document. 536 5. Security Considerations 538 The secure transmission of speech over DECT will be based on the 539 DSAA2 and DSC2 work being developed by the DF Security group / ETSI 540 TC DECT and the ETSI SAGE Security expert group. 542 DECT ULE communication are secured by encryption and per-message 543 authentication through CCM mode (Counter with CBC-MAC) similar to 544 RFC3610, which has been defined in the ETSI TC-DECT ULE group. DECT 545 ULE DLC layer implements this per-message authentication and 546 encryption to provide link-layer security mechanisms as defined by 547 ETSI TC-DECT. 549 The underlying algorithm for providing authentication and encryption 550 is based on AES128. Individual authentication key (UAK) for each ULE 551 PP are generated during the binding procedure. Session encryption 552 keys are renewed regularly. DECT ULE PPs do not use any shared 553 encryption key. 555 The DECT ULE pairing procedure generates a master security key and 556 during location registration procedure or when the permanent virtual 557 circuit are established, the session security keys are generated. 558 The generated security keys are individual for each FP-PP binding, 559 hence all PP in a system have different security keys. 561 6. ETSI Considerations 563 ETSI is standardizing a list of known application layer protocols 564 that can use the DECT ULE permanent virtual circuit packet data 565 service. Each protocol is identified by a unique known identifier. 566 The IPv6/6LoWPAN as described in this document is considered as an 567 application layer protocol on top of DECT ULE. In order to provide 568 interoperability between 6LoWPAN / DECT ULE devices a common protocol 569 identifier for 6LoWPAN has to be standardized by ETSI. 571 It is proposed to used ETSI DECT ULE protocol identifier 0x06 = 572 6LoWPAN. 574 7. Acknowledgements 576 8. Normative References 578 [ETSI-EN300.175-part1-7] 579 , . 581 [ETSI-TS102.939-1] 582 , . 584 [I-D.ietf-6lowpan-hc] 585 , . 587 [I-D.ietf-6lowpan-nd] 588 , . 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 [RFC4291] , . 595 [RFC4944] , . 597 Authors' Addresses 599 Peter B. Mariager (editor) 600 RTX A/S 601 Stroemmen 6 602 DK-9400 Noerresundby 603 Denmark 605 Email: pm@rtx.dk 607 Jens Toftgaard Petersen 608 RTX A/S 609 Stroemmen 6 610 DK-9400 Noerresundby 611 Denmark 613 Email: jtp@rtx.dk 615 Zach Shelby 616 Sensinode 617 Hallituskatu 13-17D 618 FI-90100 Oulu 619 Finland 621 Email: zach.shelby@sensinode.com