idnits 2.17.1 draft-delcarpio-6lo-wlanah-01.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 (October 19, 2015) is 3105 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) == Missing Reference: 'TBD' is mentioned on line 604, but not defined == Unused Reference: 'I-D.ietf-6lo-btle' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'IEEE802-2014' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 709, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.11ah' == Outdated reference: A later version (-16) exists of draft-ietf-6man-default-iids-08 == Outdated reference: A later version (-11) exists of draft-vanderstok-core-comi-08 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group L. Del Carpio Vega 3 Internet-Draft M. Robles 4 Intended status: Standards Track R. Morabito 5 Expires: April 21, 2016 Ericsson 6 October 19, 2015 8 IPv6 over 802.11ah 9 draft-delcarpio-6lo-wlanah-01 11 Abstract 13 IEEE 802.11 is an established Wireless LAN (WLAN) technology which 14 provides radio connectivity to a wide range of devices. The IEEE 15 802.11ah amendment defines a WLAN system operating at sub 1 GHz 16 license-exempt bands designed to operate with low-rate/low-power 17 consumption. This amendment supports large number of stations and 18 extends the radio coverage to several hundreds of meters. This 19 document describes how IPv6 is transported over 802.11ah using 20 6LoWPAN techniques. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 21, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology and Language Requirements . . . . . . . . . . . . 3 58 3. Overview of 802.11ah . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Link Layer Topology of 802.11ah . . . . . . . . . . . . . 4 60 3.2. Device Addressing and Frame Structure . . . . . . . . . . 5 61 3.3. Protocol Version 0 . . . . . . . . . . . . . . . . . . . 6 62 3.4. Protocol Version 1 . . . . . . . . . . . . . . . . . . . 6 63 3.5. Link Layer Control . . . . . . . . . . . . . . . . . . . 7 64 3.6. Ad Hoc Mode and Extended Service Set . . . . . . . . . . 8 65 3.7. Relation with other 802.11 Versions . . . . . . . . . . . 9 66 4. Uses Cases . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. 6LoWPAN over 802.11ah . . . . . . . . . . . . . . . . . . . . 9 68 6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 11 69 7. Neighbour Discovery in 802.11ah . . . . . . . . . . . . . . . 12 70 8. Header Compression . . . . . . . . . . . . . . . . . . . . . 12 71 9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 13 72 10. Multicast at IP Level . . . . . . . . . . . . . . . . . . . . 13 73 11. Internet Connection . . . . . . . . . . . . . . . . . . . . . 13 74 12. Management of the Network . . . . . . . . . . . . . . . . . . 13 75 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 16.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 16.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 IEEE 802.11 [IEEE802.11], also known as Wi-Fi, is an established 86 Wireless LAN (WLAN) technology operating in unlicensed Industrial, 87 Scientific and Medical (ISM) bands. Its IEEE 802.11ah [IEEE802.11ah] 88 amendment is tailored for Internet of Things (IoT) use-cases and at 89 the moment of writing this draft it is in the final stages of IEEE 90 standardization. 92 IEEE 802.11ah operates in the Sub-1 GHz spectrum which helps reducing 93 the power consumption. It also supports a larger number of stations 94 on a single Basic Service Set (BSS) and it provides power-saving 95 mechanisms that allow radio stations to sleep in order to save power. 97 However, the system achieves lower throughput compared to 802.11n/ac 98 amendments. 100 IEEE 802.11 specifies only the MAC and PHY layers of the radio 101 technology. In other words, 802.11 does not specify a networking 102 layer but it is compatible with commonly used internet protocol such 103 as IPv4 and IPv6. As 802.11ah is a low-rate/low-power technology, 104 the communication protocols used above MAC should also take power- 105 efficiency into consideration. This motivates the introduction of 106 6LoWPAN techniques [RFC4944] [RFC6282] for efficient transport of 107 IPv6 packets over IEEE 802.11ah radio networks. 109 This document specifies how to use 6LoWPAN techniques for 802.11ah. 111 2. Terminology and Language Requirements 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 Terminology from 802.11ah: 119 Station (STA): defined in 802.11-2012 [IEEE802.11-2012] as a wireless 120 station which is an addressable unit. 122 Sensor-STA: defined in 802.11ah as a device having low-power 123 consumption requirements. This device might be a battery operated 124 device. 126 Non-sensor STA: defined in 802.11ah as device which usually does not 127 have low-power consumption requirements. 129 In this document, any type STA (sensor STA/non-sensor STA) is 130 associated with a 6LoWPAN Node(6LN). 132 Access Point (AP): entity maintaining the WLAN Basic Service Set 133 (BSS) and it is associated with the 6LoWPAN Border Router (6LBR). It 134 is assumed that APs are connected to the power-line. 136 The terms 6LoWPAN Router (6LR) and 6LoWPAN Border Router (6LBR) are 137 defined as in [RFC6775] and in this context 6LoWPAN Nodes (6LN) do 138 not refer to a router (Access Point), just to a host (STA). 140 3. Overview of 802.11ah 142 The IEEE 802.11 technology uses the unlicensed spectrum in different 143 ISM bands, using CSMA/CA techniques. Specifically 802.11ah is 144 designed to operate in ISM band below Sub-1 Ghz with a basic 145 bandwidth of 1Mhz/2Mhz (depending of configuration). The system is 146 formed by an Access Point (AP) which maintains a Basic Service Set 147 (BSS) and stations (STAs). STAs are connected to the AP in a star 148 topology. 150 The 802.11ah is more energy efficient compared to other conventional 151 802.11 technologies because of it uses mechanisms which allow STAs to 152 doze periodically and STAs request downlink data when switching to 153 active mode i.e. Traffic Indication Map (TIM) operation, non-TIM 154 operation, Target Wakeup Time (TWT) 156 An exemplary deployment of a 802.11ah BSS may include a large number 157 of STAs associated to a BSS where STAs are sleeping (dozing) most of 158 the time and they may monitor periodic beacon-frame transmissions 159 containing Traffic Indication Maps (TIM). Data packets intended to 160 STAs cannot be delivered when STAs sleep, thus the TIM indicates 161 which STAs have downlink data buffered at the AP. After reading the 162 TIM, STAs request their buffered data by transmitting a Power-Saving 163 Poll (PS-Poll) frame to the AP. After the downlink data is 164 delivered, STAs enter into sleep mode again. For uplink data 165 delivery, STAs might transmit as soon as their data is available. 167 There might be STAs that do not monitor constantly the TIM and 168 request downlink data sporadically after waking up. 170 3.1. Link Layer Topology of 802.11ah 172 The 802.11ah defines a star topology at L2 link connectivity, where 173 the STAs are connected to the AP and any communication between STAs 174 passes through the AP. It also includes L2 relays to extend the 175 range of the system. As in other 802.11 amendments, the ad-hoc 176 topology is also suported. Finally, the 802.11 standard does not 177 define its own networking layer but is compatible with commonly used 178 protocols e.g. IPv4, IPv6 via the Link Layer Control. 180 +---+ 181 |STA| 182 +-+-+ 183 +---+ | 184 |STA+------+ | 185 +---+ | | 186 +---+---+ +---+ 187 | AP +----+STA| 188 ++-----++ +---+ 189 +----+ | | 190 |STA +-----+ | 191 +----+ +-+--+ 192 |STA | 193 +----+ 195 Figure 1: Star Link Layer Topology 197 It is important to note that the communication link is unidirectional 198 at any given point in time and that the medium is shared by CSMA/CA 199 techniques which avoid that two or more STAs utilize the medium 200 simultaneously. 202 3.2. Device Addressing and Frame Structure 204 The 802.11 physical transmission is composed by a preamble which is 205 used to prepare a receiver for frame decoding, basic physical layer 206 information, and the physical layer payload which encapsulates the 207 MAC Protocol Data Unit (MPDU). 209 There can be different classes of MAC frames in 802.11, the MAC data 210 frame is the only one carrying higher layer data. Other frames are 211 control and management frames which are used to maintain MAC layer 212 functions. In general in 802.11 MAC addresses use the EUI-48 bit 213 address space. 215 A MAC data frame in 802.11 is composed by a MAC header, a MAC payload 216 and a Frame Check Sequence (FCS) which are encoded in an MPDU. The 217 MAC payload carries Link Layer Control PDUs which encapsulates, for 218 example, IP packets. There are two protocol versions for MAC frame 219 formats, the Protocol Version 0 (PV0) which is the default format of 220 802.11 and it is inherited to 802.11ah and the Protocol Version 1 221 (PV1) which has less overhead that PV0 and can be optionally 222 supported by 802.11ah non-sensor STA and it is mandatory supported 223 for 802.11ah sensor STA. 225 In 802.11ah, the maximum size of the MSDU (MAC payload) is given by 226 the maximum size of a A-MSDU which is constrained by the maximum size 227 of the A-MPDU of 7991 bytes. This maximum of the A-MPDU is 228 independent of Protocol Version. 230 In addition, segmentation at 802.11 MAC layer level is supported if 231 required. 233 3.3. Protocol Version 0 235 The elements of the MAC data frame with PV0 are defined in 236 802.11-2012, Section 8.2 [IEEE802.11-2012] and are depicted in the 237 picture below. 239 +-------+--------+----+----+----+------+----+-----+----+-------+---+ 240 + Frame +Duration+ A1 + A2 + A3 + Seq. + A4 + QoS + HT + Frame +FCS+ 241 +Control+ /ID + + + + Ctrl + + Crl +Crl + Body + + 242 +-------+--------+----+----+----+------+----+-----+----+-------+---+ 243 2 2 6 6 6 2 6/0 2 4 0-7951 4 245 Figure 2: MAC frame PV0 247 Frame Control: contains information relevant in link layer such as 248 the Protocol Version, frame type and subtype, Power Management, 249 Fragmentation Information, among others. 251 A1, A2, A3: indicate the recipient, the transmitter and the BSSID 252 which in infraestructure mode is the value of the STA contained in 253 the AP (AP MAC address in practice). They follow 48-bits MAC address 254 format. 256 A4, Sequence control, QoS control, HT control: The meaning of these 257 field are out of scope of this draft. Please refer to 802.11-2012, 258 Section 8.2.4 [IEEE802.11-2012] for further information. 260 Frame Body: is of variable-length field and contains the MAC payload 261 for example L3 packets. 263 FCS: The Frame Check Sequence field is a 32-bit field containing a 264 32-bit CRC which is calculated over all the fields of the MAC header 265 and the Frame Body field 267 3.4. Protocol Version 1 269 The MAC header for the PV1 format is at least formed by a Frame 270 Control field and the address fields. Other fields are optional. 271 Please refer to 802.11-2012, Section 8.8.1 [IEEE802.11ah] for further 272 information. 274 +---------------+-------+--------+---------------------+ 275 + Frame Control + A1 + A2 + Frame Body + FCS + 276 +---------------+-------+--------+---------------------+ 277 Bytes: 2 6/2 2/6 0-7951 4 279 Figure 3: MAC frame PV1 of 802.11ah 281 Frame control: see above. 283 A1, A2: indicates the recipient and the transmitter respectively of 284 the frame and it contains the 6-bytes MAC address or the Short ID 285 (2-bytes) provided by the AP after association in a given BSS. Short 286 ID includes the Association Identifier (AID) field which is used in 287 TIM and power-saving mode. 289 Frame Body: The minimum length for non-data frames is 0 bytes. The 290 maximum length of A-MSDU is constrained by the maximum size of the 291 A-MPDU of 7991 bytes. 293 3.5. Link Layer Control 295 The Logical Link Control (LLC) layers works as the interface between 296 higher layers, for example IP, and the 802.11 MAC. It supports 297 higher layer protocol discrimination via the EtherType value 298 utilizing the LLC SNAP or RFC1042. 300 +----------------------------------------------------+ 301 | DSAP | SSAP | CTL | OUI | Ethertype | SDU | 302 | 0xAA | 0xAA | 0x03=UI| 00+00+00 | | | 303 +----------------------------------------------------+ 305 Figure 4: Format of LPD compatible with current 802.11 306 recommendations 308 Examples of EtherTypes are 0x0800 and 0x8DD, which are used to 309 identify IPv4 and IPv6, respectively. 311 +-----------------------+ 312 | Upper Layer | 313 +-----------------------+ 314 | 802 LLC | 315 +-----------------------+ 316 | MAC Layer (802.11ah) | 317 +-----------------------+ 318 | PHY Layer (802.11ah) | 319 +-----------------------+ 321 Figure 5: WLAN Protocol Stack 323 3.6. Ad Hoc Mode and Extended Service Set 325 The standard allows to connect devices through ad-hoc mechanisms. In 326 this mode the devices are connected using implementation specific 327 protocols e.g. between two STAs or between two APs and the power- 328 saving mechanism of 802.11ah cannot be used (as AP-STA hierarchy is 329 required). The following figure describes STAs connected to AP 330 through 802.11ah and connections between APs are not based on 331 802.11ah, but are implementation specific. 333 +---+ +---+ +----+ +-----+ 334 |STA+-----+AP +-----------+AP +------+STA | 335 +---+ +--++ +--+-+ +-----+ 336 | | 337 | | 338 | +---+-+ +-----+ 339 +-----------+AP +------+STA | 340 +-----+ +-----+ 342 Figure 6: WLAN Ad Hoc Mode 344 In an Extented Service Set(ESS), the connections between Base Service 345 Station (BSS) happen through a distribution system. The distribution 346 system (DS) maybe realised by a different technology or it can be 347 composed by AP connections. 349 +------------------+ +------------------+ 350 | +---+ +---+ | | +----+ +----+ | 351 | |STA+-----+AP +------------ DS -----------+AP +----+STA | | 352 | +---+ +---+ | | +----+ +----+ | 353 +----------+-------+ +------------------+ 354 BSS | | BSS 355 +---------------> ESS <-----------------+ 357 Figure 7: WLAN Protocol Stack 359 3.7. Relation with other 802.11 Versions 361 In principle, the 6Lo stack might be used for other 802.11 versions 362 such as 802.11b, 802.11n and 802.11ac, due to these standards support 363 LLC compatibility. LLC 6lo indentifier would be the same for all 364 mentioned WiFi versions. 366 4. Uses Cases 368 [RFC7548] defines use cases for the management of constrained 369 networks: Environmental Monitoring, Infrastructure Monitoring, 370 Industrial Applications, Energy Management, Medical Applications, 371 Building Automation, Home Automation, Transport Applications, 372 Community Network Applications and Field Operations. These uses 373 cases are apply as well to 802.11ah. 375 As a starting point in 802.11ah specification work, the Task Group AH 376 proposed the following use-case categories 377 [ReferenceUseCase802.11ah]: 379 - Sensor and Meters, where large number of sensor deliver data 380 through 802.11ah connectivity 382 - Backhaul Sensor and meter data, where 802.11ah STA can be either 383 directly integrated with a sensor or it will aggregate data from 384 other tree of wireless sensors and then deliver 802.11ah connectivity 386 - Extended Range Wi-Fi, where the typical range of the Wi-Fi 387 connection will extended due to the use of lower frequencies and 388 other techniques. 390 5. 6LoWPAN over 802.11ah 392 IPv4 and IPv6 are compatible with 802.11ah via the LLC. However, 393 802.11ah technology presents a trade-off between energy consumption 394 and link bitrate. Consequently, 6LoWPAN techniques are beneficial to 395 reduce the overhead of transmissions, save energy and improve 396 throughput. With 6LoWPAN, the nodes, i.e. 6LN, 6LBR, are co-located 397 on the same devices with 802.11 features. The typical 802.11ah 398 network uses a star topology where the 6LBR functionally is co- 399 located with the AP. 6LNs are co-located with STAs and are connected 400 to the 6LBR through 802.11ah links. As mesh topology at MAC level is 401 not defined by the 802.11ah standard, 6LBR is the only router present 402 in the network. Thus, there is no presence of 6LR. 404 +---------+ 405 |+-------+| +---------+ 406 || 6LN || 802.11ah |+-------+| 407 |+-------+| || 6LN || 408 |+-------++------------+---------|+-------+| 409 || STA || | |+-------+| 410 |+-------+| | || STA || 411 +---------+ | |+-------+| 412 6LN-STA | +---------+ 413 +-----+-----+ 414 |+----+----+| 415 || 6LBR || 416 |+---------+| 417 +---------+ | | +---------+ 418 |+-------+| |+---------++ ++-------+| 419 || 6LN || || AP || || 6LN || 420 |+-------+| |+---------+| |+-------+| 421 |+-------++---+----+------+ | | 422 || STA || | 6LBR-AP |+-------+| 423 |+-------+| | || STA || 424 +--------+| | |+-------+| 425 +---------+ +-----------+---------+ 427 Figure 8: Network Topology 429 There exists the possibility to have a 802.11ah relay node at L2 to 430 extend the range of an AP. This however is an L2 feature and it is 431 experienced as a single hop by the 6LoWPAN network. In case there is 432 need to connect wirelessly several APs and ad hoc solution needs to 433 be considered. 435 Devices in this kind of networks, not necessarily have constrained 436 resources (memory, CPU, etc), but the radio link capacity is limited. 437 It might be that APs are connected to mains power and STAs might be 438 for example battery operated sensors. Therefore 6LoWPAN techniques 439 might be good to support transmission of IPv6 packets over 802.11ah 440 battery operated devices. Related to performance gain, a reduction 441 in air-time is achieved if the stack is compressed. The 442 communication 6LN-6LN is not supported directly using link-local 443 addresses, it is done through the 6LBR using the shared prefix used 444 on the subnet. This specification requires IPv6 header compression 445 format specified in [RFC6282]. 447 The Figure below shows the stack for PHY/MAC and IPv6 including 448 6LoWPAN 449 +---------------------+ 450 | Upper Layers | 451 +---------------------+ 452 | IPv6 | 453 +---------------------+ 454 | 6LoWPAN | 455 +---------------------+ 456 | 802 LLC | 457 +---------------------+ 458 | MAC Layer(802.11ah) | 459 +---------------------+ 460 | PHY Layer(802.11ah) | 461 +---------------------+ 463 Figure 9: Protocol Stack with 6LoWPAN 465 6. Stateless Address Autoconfiguration 467 The IPv6 link local address follows Section 5.3 of [RFC4862] based on 468 the 48-bit MAC device address. 470 To get the 64-bit Interface Identifier (IID) RFC 7136 [RFC7136] MUST 471 be followed. Section 5 of this RFC states: 473 "For all unicast addresses, except those that start with the binary 474 value 000, Interface IDs are required to be 64 bits long. If derived 475 from an IEEE MAC-layer address, they must be constructed in Modified 476 EUI-64 format." 478 10 bits 54 bits 64 bits 479 +----------+-----------------+----------------------+ 480 |1111111010| 0 | Interface Identifier | 481 +----------+-----------------+----------------------+ 483 Figure 10: IPv6 link local address 485 Following Appendix-A of RFC 4291 [RFC4291] the IID is formed 486 inserting two octets, with hexadecimal values of 0xFF and 0xFE in the 487 middle of the 48-bit MAC. The IID would be as follow where "a" is a 488 bit of the 48 MAC address. 490 |0 1|1 3|3 4|4 6| 491 |0 5|6 1|2 7|8 3| 492 +----------------+----------------+----------------+----------------+ 493 |aaaaaaaaaaaaaaaa|aaaaaaaa11111111|11111110aaaaaaaa|aaaaaaaaaaaaaaaa| 494 +----------------+----------------+----------------+----------------+ 496 Figure 11: Modified EUI-64 format 498 For non-link-local addresses a 64-bit IID MAY be formed by utilizing 499 the 48-bit MAC device address. Random IID can be generated for 6LN 500 using alternative methods such as [I-D.ietf-6man-default-iids]. 502 7. Neighbour Discovery in 802.11ah 504 Neighbour Discovery approach for 6LoWPAN [RFC6775] is applicable to 505 802.11ah topologies. Related to Host-initiated process, use of 506 Address Registration Option (ARO), through the Neighbour Solicitation 507 (NS) and Neighbour Advertisement (NA). Router Solicitation and 508 Router Advertisement are applicable as well following [RFC6775]. 510 As the topology is star, Multihop Distribution of prefix and 6LoWPAN 511 header compression; and Multihop Duplicated Address Detection (DAD) 512 mechanism are not applicable, since this technology does not cover 513 multihop topology. 515 8. Header Compression 517 For header compression, the rules proposed in [RFC6282] are 518 applicable. Section 3.1.1 mentions the base Encoding principle 519 applicable to 802.11ah. 521 0 1 522 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 523 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 524 | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | 525 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 527 Figure 12: LOWPAN_IPHC base Encoding 529 TF: Traffic Class; Flow Label; For 802.11ah case would apply this 530 field as defined in [RFC6282]. 532 NH: Next Header; as defined in [RFC6282]. 534 HLIM: Hop Limit; as star topology the common value would be HLIM=1. 536 CID: Context Identifier Extension; as defined in [RFC6282]. 538 SAC: Source Address Compression; as defined in [RFC6282]. 540 SAM: Source Address Mode; In this case, the combinations for 16-bits 541 are not applicable to this technology since 802.11 uses 48-bits for 542 addresses. 544 M: Multicast Compression; as defined in [RFC6282]. 546 DAC: Destination Address Compression; as defined in [RFC6282]. 548 DAM: Destination Address Mode. In this case, the combinations for 549 16-bits are not applicable to this technology since 802.11 uses 550 48-bits for addresses. 552 9. Fragmentation 554 802.11ah perform fragmentation at L2, thus the fragmentation at L3 555 would be not necessary. 557 10. Multicast at IP Level 559 802.11ah supports broadcast and multicast at link layer level, both 560 can be used to carry multicast IP transmission depending on the 561 system's configuration. TBD: add an example. 563 11. Internet Connection 565 For Internet connection, the 6LBR acts as router and forwarding 566 packets between 6LNs to and from Internet. 568 +-----+ 569 | 6LN +--------+ 570 +-----+ | 571 | +-----------+ 572 +----+----+ | | 573 | | | Internet | 574 +------+ 6LBR +----+ | 575 +--+--+ | | | | 576 | 6LN | +----+----+ +-----------+ 577 +-----+ | 578 +--+--+ 579 | 6LN | 580 +-----+ 582 Figure 13: Internet connection of 6Lo network 584 12. Management of the Network 586 TBD: how LightWeight Machine to Machine (LWM2M) or CoAP Management 587 Interface (COMI) [I-D.vanderstok-core-comi] aspects can be applied to 588 this technology, considering [RFC7547] 590 13. IANA Considerations 592 There are no IANA considerations related to this document. 594 14. Security Considerations 596 The security considerations defined in [RFC4944] and its update 597 [RFC6282] can be assumed valid for the 802.11ah case as well. 598 Indeed, the transmission of IPv6 over 802.11ah links meets all the 599 requirements for security as for IEEE 802.15.4. The standard IEEE 600 802.11ah defines all those aspects related with Link Layer security. 601 As well as for other existing WiFi solutions, 802.11ah Link Layer 602 supports security mechanism such as WPA, WPS, 802.1X. To have a 603 deeper understanding on how the Key Management processes are handled 604 in 802.11ah, please refer to [TBD] 606 Implementations defined in [I-D.ietf-6man-default-iids], [RFC3972], 607 [RFC4941], or [RFC5535], can be considered, for example, as methods 608 to support non-link local addresses. 610 For what concerns privacy issues, the draft 611 [I-D.thaler-6lo-privacy-considerations] introduces a series of 612 recommendations which can be applied in order to overcome possible 613 privacy threats in the particular case of technologies designed for 614 IPv6 over networks of resource-constrained nodes. 616 15. Acknowledgements 618 This work is partially funded by the FP7 Marie Curie Initial Training 619 Network (ITN) METRICS project (grant agreement No. 607728). 621 The authors are thankful to the members of IEEE Task Group AH for 622 their valuable comments. 624 16. References 626 16.1. Normative References 628 [IEEE802.11ah] 629 Institute of Electrical and Electronics Engineers (IEEE), 630 "Wireless LAN Medium Access Control (MAC) and Physical 631 Layer (PHY) Specifications: Amendment- Sub 1 GHz License- 632 Exempt Operation", January 2015. 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, 636 DOI 10.17487/RFC2119, March 1997, 637 . 639 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 640 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 641 2006, . 643 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 644 Address Autoconfiguration", RFC 4862, 645 DOI 10.17487/RFC4862, September 2007, 646 . 648 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 649 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 650 DOI 10.17487/RFC6282, September 2011, 651 . 653 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 654 Bormann, "Neighbor Discovery Optimization for IPv6 over 655 Low-Power Wireless Personal Area Networks (6LoWPANs)", 656 RFC 6775, DOI 10.17487/RFC6775, November 2012, 657 . 659 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 660 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 661 February 2014, . 663 16.2. Informative References 665 [I-D.ietf-6lo-btle] 666 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 667 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 668 Energy", draft-ietf-6lo-btle-17 (work in progress), August 669 2015. 671 [I-D.ietf-6man-default-iids] 672 Gont, F., Cooper, A., Thaler, D., and S. LIU, 673 "Recommendation on Stable IPv6 Interface Identifiers", 674 draft-ietf-6man-default-iids-08 (work in progress), 675 October 2015. 677 [I-D.thaler-6lo-privacy-considerations] 678 Thaler, D., "Privacy Considerations for IPv6 over Networks 679 of Resource-Constrained Nodes", draft-thaler-6lo-privacy- 680 considerations-01 (work in progress), October 2015. 682 [I-D.vanderstok-core-comi] 683 Stok, P., Bierman, A., Schoenwaelder, J., and A. Sehgal, 684 "CoAP Management Interface", draft-vanderstok-core-comi-08 685 (work in progress), October 2015. 687 [IEEE802-2014] 688 Institute of Electrical and Electronics Engineers (IEEE), 689 "IEEE Standard for Local and Metropolitan Area Networks: 690 Overview and Architecture", 2014. 692 [IEEE802.11] 693 Institute of Electrical and Electronics Engineers (IEEE), 694 "Wireless LAN", 2011. 696 [IEEE802.11-2012] 697 Institute of Electrical and Electronics Engineers (IEEE), 698 "Wireless LAN Medium Access Control (MAC) and Physical 699 Layer (PHY) Specifications", 2012. 701 [ReferenceUseCase802.11ah] 702 Institute of Electrical and Electronics Engineers (IEEE), 703 "Potential compromise of 80211ah use case", 2012. 705 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 706 RFC 3972, DOI 10.17487/RFC3972, March 2005, 707 . 709 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 710 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 711 . 713 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 714 Extensions for Stateless Address Autoconfiguration in 715 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 716 . 718 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 719 "Transmission of IPv6 Packets over IEEE 802.15.4 720 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 721 . 723 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 724 DOI 10.17487/RFC5535, June 2009, 725 . 727 [RFC7547] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and U. 728 Herberg, "Management of Networks with Constrained Devices: 729 Problem Statement and Requirements", RFC 7547, 730 DOI 10.17487/RFC7547, May 2015, 731 . 733 [RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. 734 Sehgal, "Management of Networks with Constrained Devices: 735 Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015, 736 . 738 Authors' Addresses 740 Luis Felipe Del Carpio Vega 741 Ericsson 742 Hirsalantie 11 743 Jorvas 02420 744 Finland 746 Email: felipe.del.carpio@ericsson.com 748 Maria Ines Robles 749 Ericsson 750 Hirsalantie 11 751 Jorvas 02420 752 Finland 754 Email: maria.ines.robles@ericsson.com 756 Roberto Morabito 757 Ericsson 758 Hirsalantie 11 759 Jorvas 02420 760 Finland 762 Email: roberto.morabito@ericsson.com