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