idnits 2.17.1 draft-ietf-6lo-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 (September 15, 2015) is 3145 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-6man-default-iids' is defined on line 744, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-16) exists of draft-ietf-6man-default-iids-07 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 3 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: March 18, 2016 Z. Shelby 6 ARM 7 M. Van de Logt 8 Gigaset Communications GmbH 9 D. Barthel 10 Orange Labs 11 September 15, 2015 13 Transmission of IPv6 Packets over DECT Ultra Low Energy 14 draft-ietf-6lo-dect-ule-03 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 March 18, 2016. 55 Copyright Notice 57 Copyright (c) 2015 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 . . . . . . . . . . . . . . 6 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. Subnets and Internet connectivity scenarios . . . . . . . 13 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 91 8.2. Informative References . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 ULE devices with 100 requirements on power consumption will operate on special power 101 optimized silicon, but can connect to a DECT Gateway supporting 102 traditional DECT / CAT-iq for cordless telephony and data as well as 103 the ULE extensions. DECT terminology operates with two major role 104 definitions: The Portable Part (PP) is the power constrained device, 105 while the Fixed Part (FP) is the Gateway or base station. This FP 106 may be connected to the Internet. An example of a use case for DECT 107 ULE is a home security sensor transmitting small amounts of data (few 108 bytes) at periodic intervals through the FP, but is able to wake up 109 upon an external event (burglar) and communicate with the FP. 110 Another example incorporating both DECT ULE as well as traditional 111 CAT-iq telephony is an elderly pendant (broche) which can transmit 112 periodic status messages to a care provider using very little 113 battery, but in the event of urgency, the elderly person can 114 establish a voice connection through the pendant to an alarm service. 115 It is expected that DECT ULE will be integrated into many residential 116 gateways, as many of these already implements DECT CAT-iq for 117 cordless telephony. DECT ULE can be added as a software option for 118 the FP. It is desirable to consider IPv6 for DECT ULE devices due to 119 the large address space and well-known infrastructure. This document 120 describes how IPv6 is used on DECT ULE links to optimize power while 121 maintaining the many benefits of IPv6 transmission. [RFC4944], 122 [RFC6282] and [RFC6775] specify the transmission of IPv6 over IEEE 123 802.15.4. DECT ULE has many characteristics similar to those of IEEE 124 802.15.4, but also differences. Many of the mechanisms defined for 125 transmission of IPv6 over IEEE 802.15.4 can be applied to the 126 transmission of IPv6 on DECT ULE links. 128 This document specifies how to map IPv6 over DECT ULE inspired by 129 [RFC4944], [RFC6282], [RFC6775] and [I-D.ietf-6lo-btle]. 131 1.1. Requirements Notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 1.2. Terms Used 139 PP: DECT Portable Part, typically the sensor node 141 FP: DECT Fixed Part, the gateway 142 LLME: Lower Layer Management Entity 144 RFPI: Radio Fixed Part Identity 146 IPEI: International Portable Equipment Identity 148 TPUI: Temporary Portable User Identity 150 PMID: Portable MAC Identity 152 PVC: Permanent Virtual Circuit 154 6LN: DECT Portable part having a role as defined in [RFC6775] 156 6LBR: DECT Fixed Part having a role as defined in [RFC6775] 158 2. DECT Ultra Low Energy 160 DECT ULE is a low power air interface technology that is designed to 161 support both circuit switched for service, such as voice 162 communication, and for packet mode data services at modest data rate. 163 This draft is only addressing the packet mode data service of DECT 164 ULE. 166 2.1. The DECT ULE Protocol Stack 168 The DECT ULE protocol stack consists of the PHY layer operating at 169 frequencies in the 1880 - 1920 MHz frequency band depending on the 170 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 171 allocated by use of FDMA/TDMA/TDD technics. 173 In its generic network topology, DECT is defined as a cellular 174 network technology. However, the most common configuration is a star 175 network with a single FP defining the network with a number of PP 176 attached. The MAC layer supports both traditional DECT as this is 177 used for services like discovery, pairing, security features etc. 178 All these features have been reused from DECT. 180 The DECT ULE device can switch to the ULE mode of operation, 181 utilizing the new ULE MAC layer features. The DECT ULE Data Link 182 Control (DLC) provides multiplexing as well as segmentation and re- 183 assembly for larger packets from layers above. The DECT ULE layer 184 also implements per-message authentication and encryption. The DLC 185 layer ensures packet integrity and preserves packet order, but 186 delivery is based on best effort. 188 The current DECT ULE MAC layer standard supports low bandwidth data 189 broadcast. However the usage of this broadcast service has not yet 190 been standardized for higher layers. This document is not 191 considering usage of this DECT ULE MAC broadcast service in current 192 version. 194 In general, communication sessions can be initiated from both FP and 195 PP side. Depending on power down modes employed in the PP, latency 196 may occur when initiating sessions from FP side. MAC layer 197 communication can take place using either connection oriented packet 198 transfer with low overhead for short sessions or take place using 199 connection oriented bearers including media reservation. The MAC 200 layer autonomously selects the radio spectrum positions that are 201 available within the band and can rearrange these to avoid 202 interference. The MAC layer has built-in retransmission procedures 203 in order to improve transmission reliability. 205 The DECT ULE device will typically incorporate an Application 206 Programmers Interface (API) as well as common elements known as 207 Generic Access Profile (GAP) for enrolling into the network. The 208 DECT ULE stack establishes a permanent virtual circuit (PVC) for the 209 application layers and provides support for a range of different 210 application protocols. The used application protocol is negotiated 211 between the PP and FP when the PVC communication service is 212 established. This draft defines 6LoWPAN as one of the possible 213 protocols to negotiate. 215 +----------------------------------------+ 216 | Applications | 217 +----------------------------------------+ 218 | Generic Access | ULE Profile | 219 | Profile | | 220 +----------------------------------------+ 221 | DECT/Service API | ULE Data API | 222 +--------------------+-------------------+ 223 | LLME | NWK (MM,CC)| | 224 +--------------------+-------------------+ 225 | DECT DLC | DECT ULE DLC | 226 +--------------------+-------------------+ 227 | MAC Layer | 228 +--------------------+-------------------+ 229 | Physical Layer | 230 +--------------------+-------------------+ 231 (C-plane) (U-plane) 233 Figure 1: DECT ULE Protocol Stack 235 The DECT ULE stack can be divided into control (C-plane) and user- 236 data (U-plane) parts shown to the left and to the right in figure 1, 237 respectively. 239 2.2. Link layer roles and topology 241 A FP is assumed to be less constrained than a PP. Hence, in the 242 primary scenario FP and PP will act as 6LBR and a 6LN, respectively. 243 This document does only address this primary scenario. 245 In DECT ULE, at link layer the communication only takes place between 246 a FP and a PP. A FP is able to handle multiple simultaneous 247 connections with a number of PP. Hence, in a DECT ULE network using 248 IPv6, a radio hop is equivalent to an IPv6 link and vice versa. 250 [DECT ULE PP]-----\ /-----[DECT ULE PP] 251 \ / 252 [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP] 253 / \ 254 [DECT ULE PP]-----/ \-----[DECT ULE PP] 256 Figure 2: DECT ULE star topology 258 DECT ULE repeaters are not considered in this document. 260 2.3. Addressing Model 262 Each DECT PP is assigned an IPEI during manufacturing. This identity 263 has the size of 40 bits and is DECT globally unique for the PP and 264 can be used to constitute the MAC address. However, it cannot be 265 used to derive a globally unique IID. 267 When bound to a FP, a PP is assigned a 20 bit TPUI which is unique 268 within the FP. This TPUI is used for addressing (layer 2) in 269 messages between FP and PP. 271 Each DECT FP is assigned a RFPI during manufacturing. This identity 272 has the size of 40 bits and is globally unique for a FP and can be 273 used to constitute the MAC address. However, it cannot be used to 274 derive a globally unique IID. 276 Alternatively each DECT PP and DECT FP can be assigned a unique 277 (IEEE) MAC-48 address additionally to the DECT identities to be used 278 by the 6LoWPAN. With such an approach, the FP and PP have to 279 implement a mapping between used MAC-48 addresses and DECT 280 identities. 282 2.4. MTU Considerations 284 Generally the DECT ULE FP and PP may be generating data that fits 285 into a single MAC Layer packet (38 octets) for periodically 286 transferred information, depending on application. IP data packets 287 may be much larger and hence MTU size should be the size of the IP 288 data packet. The DECT ULE DLC procedures supports segmentation and 289 reassembly of any MTU size below 65536 octets, but most 290 implementations do only support smaller values. The default MTU size 291 in DECT ULE is 500 octets, but it SHALL be configured to fit the 292 requirements from IPv6 data packets, hence [RFC4944] fragmentation/ 293 reassembly is not required. 295 It is expected that the LOWPAN_IPHC packet will fulfill all the 296 requirements for header compression without spending unnecessary 297 overhead for mesh addressing. 299 It is important to realize that the usage of larger packets will be 300 at the expense of battery life, as a large packet inside the DECT ULE 301 stack will be fragmented into several or many MAC layer packets, each 302 consuming power to transmit / receive. 304 2.5. Additional Considerations 306 The DECT ULE standard allows PP to be registered (bind) to multiple 307 FP and roaming between these FP. This draft does not consider the 308 scenarios of PP roaming between multiple FP. The use of repeater 309 functionality is also not considered in this draft. 311 3. Specification of IPv6 over DECT ULE 313 Before any IP-layer communications can take place over DECT ULE, DECT 314 ULE enabled nodes such as 6LNs and 6LBRs have to find each other and 315 establish a suitable link-layer connection. The obtain-access-rights 316 registration and location registration procedures are documented by 317 ETSI in the specifications [EN300.175-part1-7], [TS102.939-1] and 318 [TS102.939-2]. 320 DECT ULE technology sets strict requirements for low power 321 consumption and thus limits the allowed protocol overhead. 6LoWPAN 322 standards [RFC4944], [RFC6775], and [RFC6282] provide useful 323 functionality for reducing overhead which can be applied to DECT ULE. 324 This functionality comprises link-local IPv6 addresses and stateless 325 IPv6 address autoconfiguration, Neighbor Discovery and header 326 compression. 328 The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC 329 layer. Figure 3 illustrates IPv6 over DECT ULE stack. 331 A significant difference between IEEE 802.15.4 and DECT ULE is that 332 the former supports both star and mesh topology (and requires a 333 routing protocol), whereas DECT ULE in it's primary configuration 334 does not support the formation of multihop networks at the link 335 layer. In consequence, the mesh header defined in [RFC4944] for mesh 336 under routing MUST NOT be used in DECT ULE networks. In addition, a 337 DECT ULE PP node MUST NOT play the role of a 6LoWPAN Router (6LR). 339 3.1. Protocol stack 341 In order to enable transmission of IPv6 packets over DECT ULE, a 342 Permanent Virtual Circuit (PVC) has to be opened between FP and PP. 343 This MUST be done by setting up a service call from PP to FP. The PP 344 SHALL specify the <> in a service-change (other) 345 message before sending a service-change (resume) message as defined 346 in [TS102.939-1]. The <> SHALL define the ULE 347 Application Protocol Identifier to 0x06 and the MTU size to 1280 348 octets or larger. The FP MUST send a service-change-accept (resume) 349 containing a valid paging descriptor. The PP MUST be pageable. 351 +-------------------+ 352 | UDP/TCP/other | 353 +-------------------+ 354 | IPv6 | 355 +-------------------+ 356 |6LoWPAN adapted to | 357 | DECT ULE | 358 +-------------------+ 359 | DECT ULE DLC | 360 +-------------------+ 361 | DECT ULE MAC | 362 +-------------------+ 363 | DECT ULE PHY | 364 +-------------------+ 366 Figure 3: IPv6 over DECT ULE Stack 368 3.2. Link model 370 The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is 371 layer 2. The DECT ULE implements fragmentation and reassembly 372 functionality and [RFC4944] fragmentation and reassembly function 373 MUST NOT be used. Since IPv6 requires MTU size of at least 1280 374 octets, the DECT ULE connection (PVC) MUST be configured with 375 equivalent MTU size. 377 Per this specification, the IPv6 header compression format specified 378 in [RFC6282] MUST be used. The IPv6 payload length can be derived 379 from the ULE DLC packet length and the possibly elided IPv6 address 380 can be reconstructed from the link-layer address, used at the time of 381 DECT ULE connection establishment, from the ULE MAC packet address, 382 compression context if any, and from address registration information 383 (see Section 3.2.2). 385 Due to DECT ULE star topology, each branch of the star is considered 386 to be an individual link and thus the PPs cannot directly hear one 387 another and cannot talk to one another with link-local addresses. 388 However, the FP acts as a 6LBR for communication between the PPs. 389 After the FP and PPs have connected at the DECT ULE level, the link 390 can be considered up and IPv6 address configuration and transmission 391 can begin. The FP ensures address collisions do not occur. 393 3.2.1. Stateless address autoconfiguration 395 A DECT ULE 6LN performs stateless address autoconfiguration as per 396 [RFC4862]. Following the guidance of [RFC7136], a 64-bit Interface 397 identifier (IID) for a DECT ULE interface MAY be formed by utilizing 398 a MAC-48 device address as defined in [RFC2464] "IPv6 over Ethernet" 399 specification. 401 Alternatively, the DECT device addresses IPEI, RFPI or TPUI, MAY be 402 used instead to derive the IID. These DECT devices addresses 403 consisting of 40, 40 and 20 bits respectively, MUST be expanded with 404 leading bits to form a 48 bit address. Least significant bit of this 405 address is the last bit in network order. The expanded leading bits 406 are all zeros except for 7th bit indicating not global unique. First 407 bit is set to a one for addresses derived from the RFPI and 2nd bit 408 is set to one when the address is derived from the PMID. For example 409 from IPEI=01.23.45.67.89 is derived MAC address equal 410 02:01:23:45:67:89 and from PMID=0.01.23 is derived MAC address equal 411 42:00:00:00:01:23. 413 As defined in [RFC4291], the IPv6 link-local address for a DECT ULE 414 node is formed by appending the IID, to the prefix FE80::/64, as 415 shown in Figure 4. 417 10 bits 54 bits 64 bits 418 +----------+-----------------+----------------------+ 419 |1111111010| zeros | Interface Identifier | 420 +----------+-----------------+----------------------+ 422 Figure 4: IPv6 link-local address in DECT ULE 424 A 6LN MUST join the all-nodes multicast address. 426 After link-local address configuration, 6LN sends Router Solicitation 427 messages as described in [RFC4861] Section 6.3.7. 429 For non-link-local addresses a 64-bit IID MAY be formed by utilizing 430 a MAC-48 device address. For non-link-local addresses, 6LNs SHOULD 431 NOT be configured to use IIDs derived from a MAC-48 device address. 432 By default a 6LN SHOULD use a randomly generated IID (see 433 Section 3.2.2), for example, as discussed in [I-D.ietf-6man-default- 434 iids], or use alternative schemes such as Cryptographically Generated 435 Addresses (CGA) [RFC3972], privacy extensions [RFC4941], Hash-Based 436 Addresses (HBA, [RFC5535]), DHCPv6 [RFC3315], or static, semantically 437 opaque addresses [RFC7217]. In situations where the devices address 438 embedded in the IID are required to support deployment constraints, 439 6LN MAY form a 64-bit IID by utilizing the MAC-48 device address. 440 The non-link-local addresses 6LN generates MUST be registered with 441 6LBR as described in Section 3.2.2. 443 The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT 444 ULE network is out of scope of this document, but can be, for 445 example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by 446 using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to 447 the link model of the DECT ULE the 6LBR MUST set the "on-link" flag 448 (L) to zero in the Prefix Information Option [RFC4861]. This will 449 cause 6LNs to always send packets to the 6LBR, including the case 450 when the destination is another 6LN using the same prefix. 452 3.2.2. Neighbor discovery 454 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 455 Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor 456 discovery approach as adapted for use in several 6LoWPAN topologies, 457 including the mesh topology. As DECT ULE is considered not to 458 support mesh networks, hence only those aspects that apply to a star 459 topology are considered. 461 The following aspects of the Neighbor Discovery optimizations 462 [RFC6775] are applicable to DECT ULE 6LNs: 464 1. For sending Router Solicitations and processing Router 465 Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections 466 5.3 and 5.4 of the [RFC6775]. 468 2. A DECT ULE 6LN MUST NOT register its link-local address. A DECT 469 ULE 6LN MUST register its non-link-local addresses with the 6LBR by 470 sending a Neighbor Solicitation (NS) message with the Address 471 Registration Option (ARO) and process the Neighbor Advertisement (NA) 472 accordingly. The NS with the ARO option MUST be sent irrespective of 473 the method used to generate the IID. The 6LN MUST register only one 474 IPv6 address per available IPv6 prefix. 476 3.2.3. Unicast and Multicast address mapping 478 The DECT MAC layer broadcast service is considered inadequate for IP 479 multicast. 481 Hence traffic is always unicast between two DECT ULE nodes. Even in 482 the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot 483 do a multicast to all the connected 6LNs. If the 6LBR needs to send 484 a multicast packet to all its 6LNs, it has to replicate the packet 485 and unicast it on each link. However, this may not be energy- 486 efficient and particular care should be taken if the FP is battery- 487 powered. To further conserve power, the 6LBR MUST keep track of 488 multicast listeners at DECT-ULE link level granularity and it MUST 489 NOT forward multicast packets to 6LNs that have not registered for 490 multicast groups the packets belong to. In the opposite direction, a 491 6LN can only transmit data to or through the 6LBR. Hence, when a 6LN 492 needs to transmit an IPv6 multicast packet, the 6LN will unicast the 493 corresponding DECT ULE packet to the 6LBR. The 6LBR will then 494 forward the multicast packet to other 6LNs. 496 3.2.4. Header Compression 498 Header compression as defined in [RFC6282], which specifies the 499 compression format for IPv6 datagrams on top of IEEE 802.15.4, is 500 REQUIRED in this document as the basis for IPv6 header compression on 501 top of DECT ULE. All headers MUST be compressed according to 502 [RFC6282] encoding formats. The DECT ULE's star topology structure 503 and ARO can be exploited in order to provide a mechanism for addess 504 compression. The following text describes the principles of IPv6 505 address compression on top of DECT ULE. 507 3.2.4.1. Link-local Header Compression 509 In a link-local communication terminated at 6LN and 6LBR, both the 510 IPv6 source and destination addresses MUST be elided, since the node 511 knows that the packet is destined for it even if the packet does not 512 have destination IPv6 address. A node SHALL learn the IID of the 513 other endpoint of each DECT ULE connection it participates in. By 514 exploiting this information, a node that receives a PDU containing an 515 IPv6 packet can infer the corresponding IPv6 source address. A node 516 MUST maintain a Neighbor Cache, in which the entries include both the 517 IID of the neighbor and the Device Address that identifies the 518 neighbor. For the type of communication considered in this 519 paragraph, the following settings MUST be used in the IPv6 compressed 520 header: CID=0, SAC=0, SAM=11, DAC=0, DAM=11. 522 3.2.4.2. Non-link-local Header Compression 524 To enable efficient header compression, the 6LBR MUST include 6LoWPAN 525 Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises 526 in Router Advertisements for use in stateless address 527 autoconfiguration. 529 When a 6LN transmits an IPv6 packet to a destination using global 530 Unicast IPv6 addresses, if a context is defined for the prefix of the 531 6LNs global IPv6 address, the 6LN MUST indicate this context in the 532 corresponding source fields of the compressed IPv6 header as per 533 Section 3.1 of [RFC6282], and MUST elide the IPv6 source address. 534 For this, the 6LN MUST use the following settings in the IPv6 535 compressed header: CID=1, SAC=1, SAM=11. In this case, the 6LBR can 536 infer the elided IPv6 source address since 1) the 6LBR has previously 537 assigned the prefix to the 6LNs; and 2) the 6LBR maintains a Neighbor 538 Cache that relates the Device Address and the IID of the 539 corresponding PP. If a context is defined for the IPv6 destination 540 address, the 6LN MUST also indicate this context in the corresponding 541 destination fields of the compressed IPv6 header, and MUST elide the 542 prefix of the destination IPv6 address. For this, the 6LN MUST set 543 the DAM field of the compressed IPv6 header as CID=1, DAC=1 and 544 DAM=01 or DAM=11. Note that when a context is defined for the IPv6 545 destination address, the 6LBR can infer the elided destination prefix 546 by using the context. 548 When a 6LBR receives a IPv6 packet having a global Unicast IPv6 549 address, and the destination of the packet is a 6LN, if a context is 550 defined for the prefix of the 6LN's global IPv6 address, the 6LBR 551 MUST indicate this context in the corresponding destination fields of 552 the compressed IPv6 header, and MUST elide the IPv6 destination 553 address of the packet before forwarding it to the 6LN. For this, the 554 6LBR MUST set the DAM field of the IPv6 compressed header as DAM=11. 555 CID and DAC MUST be set to CID=1 and DAC=1. If a context is defined 556 for the prefix of the IPv6 source address, the 6LBR MUST indicate 557 this context in the source fields of the compressed IPv6 header, and 558 MUST elide that prefix as well. For this, the 6LBR MUST set the SAM 559 field of the IPv6 compressed header as CID=1, SAC=1 and SAM=01 or 560 SAM=11. 562 3.3. Subnets and Internet connectivity scenarios 564 In a typical scenario, the DECT ULE network is connected to the 565 Internet as shown in the Figure 5. In this scenario, the DECT ULE 566 network is deployed as one subnet, using one /64 IPv6 prefix. The 567 6LBR is acting as router and forwarding packets between 6LNs and to 568 and from Internet. 570 A degenerate scenario can be imagined where a PP is acting as 6LBR 571 and providing Internet connectivity for the FP. How the FP could 572 then further provide Internet connectivity to other PP, possibly 573 connected to the FP, is out of the scope of this document. 575 6LN 576 \ ____________ 577 \ / \ 578 6LN ---- 6LBR --- | Internet | 579 / \____________/ 580 / 581 6LN 583 <-- DECT ULE --> 585 Figure 5: DECT ULE network connected to the Internet 587 In some scenarios, the DECT ULE network may transiently or 588 permanently be an isolated network as shown in the Figure 6. In this 589 case the whole DECT ULE network consists of a single subnet with 590 multiple links, where 6LBR is routing packets between 6LNs. 592 6LN 6LN 593 \ / 594 \ / 595 6LN --- 6LBR --- 6LN 596 / \ 597 / \ 598 6LN 6LN 600 <------ DECT ULE -----> 602 Figure 6: Isolated DECT ULE network 604 In the isolated network scenario, communications between 6LN and 6LBR 605 can use IPv6 link-local methodology, but for communications between 606 different PP, the FP has to act as 6LBR, number the network with ULA 607 prefix [RFC4193], and route packets between PP. 609 4. IANA Considerations 611 There are no IANA considerations related to this document. 613 5. Security Considerations 615 The secure transmission of speech over DECT will be based on the 616 DSAA2 and DSC2 work developed by the DF Security group / ETSI TC DECT 617 and the ETSI SAGE Security expert group. 619 DECT ULE communications are secured at the link-layer (DLC) by 620 encryption and per-message authentication through CCM mode (Counter 621 with CBC-MAC) similar to [RFC3610]. The underlying algorithm for 622 providing encryption and authentication is AES128. 624 The DECT ULE pairing procedure generates a master authentication key 625 (UAK) and during location registration procedure or when the 626 permanent virtual circuit are established, the session security keys 627 are generated. Session security keys may be renewed regularly. The 628 generated security keys (UAK and session security keys) are 629 individual for each FP-PP binding, hence all PP in a system have 630 different security keys. DECT ULE PPs do not use any shared 631 encryption key. 633 The IPv6 address configuration as described in Section 3.2.1 allows 634 implementations the choice to support, for example, [I-D.ietf-6man- 635 default-iids], [RFC3315], [RFC3972], [RFC4941], [RFC5535] or 636 [RFC7217] for non-link-local addresses. 638 6. ETSI Considerations 640 ETSI is standardizing a list of known application layer protocols 641 that can use the DECT ULE permanent virtual circuit packet data 642 service. Each protocol is identified by a unique known identifier, 643 which is exchanged in the service-change procedure as defined in 644 [TS102.939-1]. The IPv6/6LoWPAN as described in this document is 645 considered as an application layer protocol on top of DECT ULE. In 646 order to provide interoperability between 6LoWPAN / DECT ULE devices 647 a common protocol identifier for 6LoWPAN is standardized by ETSI. 649 The ETSI DECT ULE Application Protocol Identifier is specified to 650 0x06 for 6LoWPAN [TS102.939-1]. 652 7. Acknowledgements 654 We are grateful to the members of the IETF 6lo working group; this 655 document borrows liberally from their work. 657 Ralph Droms has provided valuable feedback for this draft. 659 8. References 661 8.1. Normative References 663 [EN300.175-part1-7] 664 ETSI, "Digital Enhanced Cordless Telecommunications 665 (DECT); Common Interface (CI);", March 2015. 667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", BCP 14, RFC 2119, 669 DOI 10.17487/RFC2119, March 1997, 670 . 672 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 673 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 674 . 676 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 677 Host Configuration Protocol (DHCP) version 6", RFC 3633, 678 DOI 10.17487/RFC3633, December 2003, 679 . 681 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 682 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 683 . 685 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 686 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 687 2006, . 689 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 690 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 691 DOI 10.17487/RFC4861, September 2007, 692 . 694 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 695 Address Autoconfiguration", RFC 4862, 696 DOI 10.17487/RFC4862, September 2007, 697 . 699 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 700 Extensions for Stateless Address Autoconfiguration in 701 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 702 . 704 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 705 "Transmission of IPv6 Packets over IEEE 802.15.4 706 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 707 . 709 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 710 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 711 DOI 10.17487/RFC6282, September 2011, 712 . 714 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 715 Bormann, "Neighbor Discovery Optimization for IPv6 over 716 Low-Power Wireless Personal Area Networks (6LoWPANs)", 717 RFC 6775, DOI 10.17487/RFC6775, November 2012, 718 . 720 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 721 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 722 February 2014, . 724 [TS102.939-1] 725 ETSI, "Digital Enhanced Cordless Telecommunications 726 (DECT); Ultra Low Energy (ULE); Machine to Machine 727 Communications; Part 1: Home Automation Network (phase 728 1)", March 2015. 730 [TS102.939-2] 731 ETSI, "Digital Enhanced Cordless Telecommunications 732 (DECT); Ultra Low Energy (ULE); Machine to Machine 733 Communications; Part 2: Home Automation Network (phase 734 2)", March 2015. 736 8.2. Informative References 738 [I-D.ietf-6lo-btle] 739 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 740 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 741 Energy", draft-ietf-6lo-btle-17 (work in progress), August 742 2015. 744 [I-D.ietf-6man-default-iids] 745 Gont, F., Cooper, A., Thaler, D., and S. LIU, 746 "Recommendation on Stable IPv6 Interface Identifiers", 747 draft-ietf-6man-default-iids-07 (work in progress), August 748 2015. 750 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 751 C., and M. Carney, "Dynamic Host Configuration Protocol 752 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 753 2003, . 755 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 756 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 757 2003, . 759 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 760 RFC 3972, DOI 10.17487/RFC3972, March 2005, 761 . 763 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 764 DOI 10.17487/RFC5535, June 2009, 765 . 767 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 768 Interface Identifiers with IPv6 Stateless Address 769 Autoconfiguration (SLAAC)", RFC 7217, 770 DOI 10.17487/RFC7217, April 2014, 771 . 773 Authors' Addresses 774 Peter B. Mariager 775 RTX A/S 776 Stroemmen 6 777 DK-9400 Noerresundby 778 Denmark 780 Email: pm@rtx.dk 782 Jens Toftgaard Petersen (editor) 783 RTX A/S 784 Stroemmen 6 785 DK-9400 Noerresundby 786 Denmark 788 Email: jtp@rtx.dk 790 Zach Shelby 791 Sensinode 792 150 Rose Orchard 793 San Jose, CA 95134 794 USA 796 Email: zach.shelby@arm.com 798 Marco van de Logt 799 Gigaset Communications GmbH 800 Frankenstrasse 2 801 D-46395 Bocholt 802 Germany 804 Email: marco.van-de-logt@gigaset.com 806 Dominique Barthel 807 Orange Labs 808 28 chemin du Vieux Chene 809 38243 Meylan 810 France 812 Email: dominique.barthel@orange.com