idnits 2.17.1 draft-ietf-ipwave-ipv6-over-80211ocb-52.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 (August 9, 2019) is 1684 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11-2016' == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-11 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group N. Benamar 3 Internet-Draft Moulay Ismail University of Meknes 4 Intended status: Standards Track J. Haerri 5 Expires: February 10, 2020 Eurecom 6 J. Lee 7 Sangmyung University 8 T. Ernst 9 YoGoKo 10 August 9, 2019 12 Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside 13 the Context of a Basic Service Set 14 draft-ietf-ipwave-ipv6-over-80211ocb-52 16 Abstract 18 This document provides methods and settings, for using IPv6 to 19 communicate among nodes within range of one another over a single 20 IEEE 802.11-OCB link. Support for these methods and settings require 21 minimal changes to existing stacks. This document also describes 22 limitations associated with using these methods. Optimizations and 23 usage of IPv6 over more complex scenarios is not covered in this 24 specification and is subject of future work. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 10, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4 63 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4 65 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 66 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 5 67 4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 5 68 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 6 69 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 6 70 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6 71 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8 74 5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 9 75 5.2. MAC Address and Interface ID Generation . . . . . . . . . 9 76 5.3. Pseudonymization impact on confidentiality and trust . . 10 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 9.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Appendix A. 802.11p . . . . . . . . . . . . . . . . . . . . . . 16 84 Appendix B. Aspects introduced by the OCB mode to 802.11 . . . . 16 85 Appendix C. Changes Needed on a software driver 802.11a to 86 become a 802.11-OCB driver . . . . . . . . . . . . . 20 87 Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 21 88 Appendix E. Design Considerations . . . . . . . . . . . . . . . 22 89 Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 22 90 Appendix G. Examples of Packet Formats . . . . . . . . . . . . . 23 91 G.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 24 92 G.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 26 93 Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 28 94 Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless 95 Links . . . . . . . . . . . . . . . . . . . . . . . 29 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 99 1. Introduction 101 This document provides a baseline for using IPv6 to communicate among 102 nodes in range of one another over a single IEEE 802.11-OCB link 103 [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, Appendix B and 104 Appendix C) with minimal changes to existing stacks. Moreover, the 105 document identifies limitations of such usage. Concretely, the 106 document describes the layering of IPv6 networking on top of the IEEE 107 Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame 108 translation underneath. The resulting stack is derived from IPv6 109 over Ethernet [RFC2464], but operates over 802.11-OCB to provide at 110 least P2P (Point to Point) connectivity using IPv6 ND and link-local 111 addresses. 113 The IPv6 network layer operates on 802.11-OCB in the same manner as 114 operating on Ethernet with the following exceptions: 116 o Exceptions due to different operation of IPv6 network layer on 117 802.11 than on Ethernet. The operation of IP on Ethernet is 118 described in [RFC1042] and [RFC2464]. 120 o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11. 121 This has impacts on security, privacy, subnet structure and 122 movement detection. Security and privacy recommendations are 123 discussed in Section 5 and Section 4.4. The subnet structure is 124 described in Section 4.6. The movement detection on OCB links is 125 not described in this document. Likewise, ND Extensions and 126 IPWAVE optimizations for vehicular communications are not in 127 scope. The expectation is that further specifications will be 128 edited to cover more complex vehicular networking scenarios. 130 The reader may refer to [I-D.ietf-ipwave-vehicular-networking] for an 131 overview of problems related to running IPv6 over 802.11-OCB. It is 132 out of scope of this document to reiterate those. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 The document makes uses of the following terms: IP-OBU (Internet 143 Protocol On-Board Unit): an IP-OBU denotes a computer situated in a 144 vehicle such as a car, bicycle, or similar. It has at least one IP 145 interface that runs in mode OCB of 802.11, and that has an "OBU" 146 transceiver. See the definition of the term "OBU" in section 147 Appendix H. 149 IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. It 150 has at least two distinct IP-enabled interfaces. The wireless PHY/ 151 MAC layer of at least one of its IP-enabled interfaces is configured 152 to operate in 802.11-OCB mode. An IP-RSU communicates with the IP- 153 OBU in the vehicle over 802.11 wireless link operating in OCB mode. 154 An IP-RSU is similar to an Access Network Router (ANR) defined in 155 [RFC3753], and a Wireless Termination Point (WTP) defined in 156 [RFC5415]. 158 OCB (outside the context of a basic service set - BSS): is a mode of 159 operation in which a STA is not a member of a BSS and does not 160 utilize IEEE Std 802.11 authentication, association, or data 161 confidentiality. 163 802.11-OCB: refers to the mode specified in IEEE Std 802.11-2016 when 164 the MIB attribute dot11OCBActivited is 'true'. 166 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 168 The IEEE 802.11-OCB networks are used for vehicular communications, 169 as 'Wireless Access in Vehicular Environments'. In particular, we 170 refer the reader to [I-D.ietf-ipwave-vehicular-networking], that 171 lists some scenarios and requirements for IP in Intelligent 172 Transportation Systems (ITS). 174 The link model is the following: STA --- 802.11-OCB --- STA. In 175 vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. All links 176 are assumed to be P2P and multiple links can be on one radio 177 interface. While 802.11-OCB is clearly specified, and a legacy IPv6 178 stack can operate on such links, the use of the operating environment 179 (vehicular networks) brings in new perspectives. 181 4. IPv6 over 802.11-OCB 183 4.1. Maximum Transmission Unit (MTU) 185 The default MTU for IP packets on 802.11-OCB is inherited from 186 [RFC2464] and is, as such, 1500 octets. As noted in [RFC8200], every 187 link on the Internet must have a minimum MTU of 1280 octets, as well 188 as follow the other recommendations, especially with regard to 189 fragmentation. 191 4.2. Frame Format 193 IP packets MUST be transmitted over 802.11-OCB media as QoS Data 194 frames whose format is specified in IEEE 802.11 spec 195 [IEEE-802.11-2016]. 197 The IPv6 packet transmitted on 802.11-OCB are immediately preceded by 198 a Logical Link Control (LLC) header and an 802.11 header. In the LLC 199 header, and in accordance with the EtherType Protocol Discrimination 200 (EPD, see Appendix D), the value of the Type field MUST be set to 201 0x86DD (IPv6). The mapping to the 802.11 data service SHOULD use a 202 'priority' value of 1 (QoS with a 'Background' user priority), 203 reserving higher priority values for safety-critical and time- 204 sensitive traffic, including the ones listed in [ETSI-sec-archi]. 206 To simplify the Application Programming Interface (API) between the 207 operating system and the 802.11-OCB media, device drivers MAY 208 implement IPv6-over-Ethernet as per [RFC2464] and then a frame 209 translation from 802.3 to 802.11 in order to minimize the code 210 changes. 212 4.3. Link-Local Addresses 214 There are several types of IPv6 addresses [RFC4291], [RFC4193], that 215 may be assigned to an 802.11-OCB interface. Among these types of 216 addresses only the IPv6 link-local addresses can be formed using an 217 EUI-64 identifier, in particular during transition time, (the time 218 spent before an interface starts using a different address than the 219 LL one). 221 If the IPv6 link-local address is formed using an EUI-64 identifier, 222 then the mechanism of forming that address is the same mechanism as 223 used to form an IPv6 link-local address on Ethernet links. Moreover, 224 whether or not the interface identifier is derived from the EUI-64 225 identifier, its length is 64 bits as is the case for Ethernet 226 [RFC2464]. 228 4.4. Stateless Autoconfiguration 230 The steps a host takes in deciding how to autoconfigure its 231 interfaces in IPv6 are described in [RFC4862]. This section 232 describes the formation of Interface Identifiers for IPv6 addresses 233 of type 'Global' or 'Unique Local'. Interface Identifiers for IPv6 234 address of type 'Link-Local' are discussed in Section 4.3. 236 The RECOMMENDED method for forming stable Interface Identifiers 237 (IIDs) is described in [RFC8064]. The method of forming IIDs 238 described in Section 4 of [RFC2464] MAY be used during transition 239 time, in particular for IPv6 link-local addresses. Regardless of how 240 to form the IID, its length is 64 bits, similarely to IPv6 over 241 Ethernet [RFC2464]. 243 The bits in the IID have no specific meaning and the identifier 244 should be treated as an opaque value. The bits 'Universal' and 245 'Group' in the identifier of an 802.11-OCB interface are significant, 246 as this is an IEEE link-layer address. The details of this 247 significance are described in [RFC7136]. 249 Semantically opaque IIDs, instead of meaningful IIDs derived from a 250 valid and meaningful MAC address ([RFC2464], Section 4), help avoid 251 certain privacy risks (see the risks mentioned in Section 5.1.1). If 252 semantically opaque IIDs are needed, they may be generated using the 253 method for generating semantically opaque IIDs with IPv6 Stateless 254 Address Autoconfiguration given in [RFC7217]. Typically, an opaque 255 IID is formed starting from identifiers different than the MAC 256 addresses, and from cryptographically strong material. Thus, privacy 257 sensitive information is absent from Interface IDs, because it is 258 impossible to calculate back the initial value from which the 259 Interface ID was first generated. 261 Some applications that use IPv6 packets on 802.11-OCB links (among 262 other link types) may benefit from IPv6 addresses whose IIDs don't 263 change too often. It is RECOMMENDED to use the mechanisms described 264 in RFC 7217 to permit the use of Stable IIDs that do not change 265 within one subnet prefix. A possible source for the Net-Iface 266 Parameter is a virtual interface name, or logical interface name, 267 that is decided by a local administrator. 269 4.5. Address Mapping 271 Unicast and multicast address mapping MUST follow the procedures 272 specified for Ethernet interfaces specified in Sections 6 and 7 of 273 [RFC2464]. 275 4.5.1. Address Mapping -- Unicast 277 This document is scoped for Address Resolution (AR) and Duplicate 278 Address Detection (DAD) per [RFC4862]. 280 4.5.2. Address Mapping -- Multicast 282 The multicast address mapping is performed according to the method 283 specified in section 7 of [RFC2464]. The meaning of the value "3333" 284 mentioned there is defined in section 2.3.1 of [RFC7042]. 286 Transmitting IPv6 packets to multicast destinations over 802.11 links 287 proved to have some performance issues 288 [I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be 289 exacerbated in OCB mode. A future improvement to this specification 290 should consider solutions for these problems. 292 4.6. Subnet Structure 294 When vehicles are in close range, a subnet may be formed over 295 802.11-OCB interfaces (not by their in-vehicle interfaces). A Prefix 296 List conceptual data structure ([RFC4861] Section 5.1) is maintained 297 for each 802.11-OCB interface. 299 IPv6 Neighbor Discovery protocol (ND) requires reflexive properties 300 (bidirectional connectivity) which is generally, though not always, 301 the case for P2P OCB links. IPv6 ND also requires transitive 302 properties for DAD and AR, so an IPv6 subnet can be mapped on an OCB 303 network only if all nodes in the network share a single physical 304 broadcast domain. The extension to IPv6 ND operating on a subnet 305 that covers multiple OCB links and not fully overlapping (NBMA) is 306 not in scope. Finally, IPv6 ND requires a permanent connectivity of 307 all nodes in the subnet to defend their addresses, in other words 308 very stable network conditions. 310 The structure of this subnet is ephemeral, in that it is strongly 311 influenced by the mobility of vehicles: the hidden terminal effects 312 appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc' 313 networks with an addressing model as described in [RFC5889]. On 314 another hand, the structure of the internal subnets in each vehicle 315 is relatively stable. 317 As recommended in [RFC5889], when the timing requirements are very 318 strict (e.g., fast-drive-through IP-RSU coverage), no on-link subnet 319 prefix should be configured on an 802.11-OCB interface. In such 320 cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED. 322 Additionally, even if the timing requirements are not very strict 323 (e.g., the moving subnet formed by two following vehicles is stable, 324 a fixed IP-RSU is absent), the subnet is disconnected from the 325 Internet (i.e., a default route is absent), and the addressing peers 326 are equally qualified (that is, it is impossible to determine that 327 some vehicle owns and distributes addresses to others) the use of 328 link-local addresses is RECOMMENDED. 330 The baseline ND protocol [RFC4861] MUST be supported over 802.11-OCB 331 links. Transmitting ND packets may prove to have some performance 332 issues as mentioned in Section 4.5.2, and Appendix I. These issues 333 may be exacerbated in OCB mode. Solutions for these problems should 334 consider the OCB mode of operation. Future solutions to OCB should 335 consider solutions for avoiding broadcast. The best of current 336 knowledge indicates the kinds of issues that may arise with ND in OCB 337 mode; they are described in Appendix I. 339 Protocols like Mobile IPv6 [RFC6275] , [RFC3963] and DNAv6 [RFC6059], 340 which depend on a timely movement detection, might need additional 341 tuning work to handle the lack of link-layer notifications during 342 handover. This is for further study. 344 5. Security Considerations 346 Any security mechanism at the IP layer or above that may be carried 347 out for the general case of IPv6 may also be carried out for IPv6 348 operating over 802.11-OCB. 350 The OCB operation does not use existing 802.11 link-layer security 351 mechanisms. There is no encryption applied below the network layer 352 running on 802.11-OCB. At the application layer, the IEEE 1609.2 353 document [IEEE-1609.2] provides security services for certain 354 applications to use; application-layer mechanisms are out of scope of 355 this document. On another hand, a security mechanism provided at 356 networking layer, such as IPsec [RFC4301], may provide data security 357 protection to a wider range of applications. 359 802.11-OCB does not provide any cryptographic protection, because it 360 operates outside the context of a BSS (no Association Request/ 361 Response, no Challenge messages). Therefore, an attacker can sniff 362 or inject traffic while within range of a vehicle or IP-RSU (by 363 setting an interface card's frequency to the proper range). Also, an 364 attacker may not heed to legal limits for radio power and can use a 365 very sensitive directional antenna; if attackers wishe to attack a 366 given exchange they do not necessarily need to be in close physical 367 proximity. Hence, such a link is less protected than commonly used 368 links (wired link or aforementioned 802.11 links with link-layer 369 security). 371 Therefore, any node can join a subnet, directly communicate with any 372 nodes on the subset to include potentially impersonating another 373 node. This design allows for a number of threats outlined in 374 Section 3 of [RFC6959]. While not widely deployed, SeND [RFC3971], 375 [RFC3972] is a solution that can address Spoof-Based Attack Vectors. 377 5.1. Privacy Considerations 379 As with all Ethernet and 802.11 interface identifiers ([RFC7721]), 380 the identifier of an 802.11-OCB interface may involve privacy, MAC 381 address spoofing and IP hijacking risks. A vehicle embarking an IP- 382 OBU whose egress interface is 802.11-OCB may expose itself to 383 eavesdropping and subsequent correlation of data. This may reveal 384 data considered private by the vehicle owner; there is a risk of 385 being tracked. In outdoors public environments, where vehicles 386 typically circulate, the privacy risks are more important than in 387 indoors settings. It is highly likely that attacker sniffers are 388 deployed along routes which listen for IEEE frames, including IP 389 packets, of vehicles passing by. For this reason, in the 802.11-OCB 390 deployments, there is a strong necessity to use protection tools such 391 as dynamically changing MAC addresses Section 5.2, semantically 392 opaque Interface Identifiers and stable Interface Identifiers 393 Section 4.4. An example of change policy is to change the MAC 394 address of the OCB interface each time the system boots up. This may 395 help mitigate privacy risks to a certain level. Furthermore, for 396 privacy concerns, ([RFC8065]) recommends using an address generation 397 scheme rather than addresses generated from a fixed link-layer 398 address. However, there are some specificities related to vehicles. 399 Since roaming is an important characteristic of moving vehicles, the 400 use of the same Link-Local Address over time can indicate the 401 presence of the same vehicle in different places and thus leads to 402 location tracking. Hence, a vehicle should get hints about a change 403 of environment (e.g. , engine running, GPS, etc..) and renew the IID 404 in its LLAs. 406 5.1.1. Privacy Risks of Meaningful info in Interface IDs 408 The privacy risks of using MAC addresses displayed in Interface 409 Identifiers are important. The IPv6 packets can be captured easily 410 in the Internet and on-link in public roads. For this reason, an 411 attacker may realize many attacks on privacy. One such attack on 412 802.11-OCB is to capture, store and correlate Company ID information 413 present in MAC addresses of many cars (e.g. listen for Router 414 Advertisements, or other IPv6 application data packets, and record 415 the value of the source address in these packets). Further 416 correlation of this information with other data captured by other 417 means, or other visual information (car color, others) may constitute 418 privacy risks. 420 5.2. MAC Address and Interface ID Generation 422 In 802.11-OCB networks, the MAC addresses may change during well 423 defined renumbering events. In the moment the MAC address is changed 424 on an 802.11-OCB interface all the Interface Identifiers of IPv6 425 addresses assigned to that interface MUST change. 427 Implementations should use a policy dictating when the MAC address is 428 changed on the 802.11-OCB interface. For more information on the 429 motivation of this policy please refer to the privacy discussion in 430 Appendix B. 432 A 'randomized' MAC address has the following characteristics: 434 o Bit "Local/Global" set to "locally administered". 436 o Bit "Unicast/Multicast" set to "Unicast". 438 o The 46 remaining bits are set to a random value, using a random 439 number generator that meets the requirements of [RFC4086]. 441 To meet the randomization requirements for the 46 remaining bits, a 442 hash function may be used. For example, the [SHA256] hash function 443 may be used with input a 256 bit local secret, the 'nominal' MAC 444 Address of the interface, and a representation of the date and time 445 of the renumbering event. 447 A randomized Interface ID has the same characteristics of a 448 randomized MAC address, except the length in bits. 450 5.3. Pseudonymization impact on confidentiality and trust 452 Vehicles 'and drivers' privacy relies on pseudonymization mechanisms 453 such as the ones described in Section 5.2. This pseudonymization 454 means that upper-layer protocols and applications SHOULD NOT rely on 455 layer-2 or layer-3 addresses to assume that the other participant can 456 be trusted. 458 6. IANA Considerations 460 No request to IANA. 462 7. Contributors 464 Christian Huitema, Tony Li. 466 Romain Kuntz contributed extensively about IPv6 handovers between 467 links running outside the context of a BSS (802.11-OCB links). 469 Tim Leinmueller contributed the idea of the use of IPv6 over 470 802.11-OCB for distribution of certificates. 472 Marios Makassikis, Jose Santa Lozano, Albin Severinson and Alexey 473 Voronov provided significant feedback on the experience of using IP 474 messages over 802.11-OCB in initial trials. 476 Michelle Wetterwald contributed extensively the MTU discussion, 477 offered the ETSI ITS perspective, and reviewed other parts of the 478 document. 480 8. Acknowledgements 482 The authors would like to thank Alexandre Petrescu for initiating 483 this work and for being the lead author until the version 43 of this 484 draft. 486 The authors would like to thank Pascal Thubert for reviewing, 487 proofreading and suggesting modifications of this document. 489 The authors would like to thank Mohamed Boucadair for proofreading 490 and suggesting modifications of this document. 492 The authors would like to thank Eric Vyncke for reviewing suggesting 493 modifications of this document. 495 The authors would like to thank Witold Klaudel, Ryuji Wakikawa, 496 Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan 497 Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray 498 Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, 499 Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, 500 Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, 501 Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra 502 Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun, 503 Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in 504 't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith, 505 Brian Carpenter, Julian Reschke, Mikael Abrahamsson, Dirk von Hugo, 506 Lorenzo Colitti, Pascal Thubert, Ole Troan, Jinmei Tatuya, Joel 507 Halpern, Eric Gray and William Whyte. Their valuable comments 508 clarified particular issues and generally helped to improve the 509 document. 511 Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB 512 drivers for linux and described how. 514 For the multicast discussion, the authors would like to thank Owen 515 DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and 516 participants to discussions in network working groups. 518 The authors would like to thank participants to the Birds-of- 519 a-Feather "Intelligent Transportation Systems" meetings held at IETF 520 in 2016. 522 Human Rights Protocol Considerations review by Amelia Andersdotter. 524 9. References 526 9.1. Normative References 528 [IEEE-802.11-2016] 529 "IEEE Standard 802.11-2016 - IEEE Standard for Information 530 Technology - Telecommunications and information exchange 531 between systems Local and metropolitan area networks - 532 Specific requirements - Part 11: Wireless LAN Medium 533 Access Control (MAC) and Physical Layer (PHY) 534 Specifications. Status - Active Standard. Description 535 retrieved freely; the document itself is also freely 536 available, but with some difficulty (requires 537 registration); description and document retrieved on April 538 8th, 2019, starting from URL 539 https://standards.ieee.org/findstds/ 540 standard/802.11-2016.html". 542 [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission 543 of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, 544 DOI 10.17487/RFC1042, February 1988, 545 . 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, 549 DOI 10.17487/RFC2119, March 1997, 550 . 552 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 553 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 554 . 556 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 557 "Randomness Requirements for Security", BCP 106, RFC 4086, 558 DOI 10.17487/RFC4086, June 2005, 559 . 561 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 562 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 563 November 2005, . 565 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 566 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 567 . 569 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 570 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 571 2006, . 573 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 574 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 575 December 2005, . 577 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 578 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 579 DOI 10.17487/RFC4861, September 2007, 580 . 582 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 583 Address Autoconfiguration", RFC 4862, 584 DOI 10.17487/RFC4862, September 2007, 585 . 587 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 588 Ed., "Control And Provisioning of Wireless Access Points 589 (CAPWAP) Protocol Specification", RFC 5415, 590 DOI 10.17487/RFC5415, March 2009, 591 . 593 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 594 Detecting Network Attachment in IPv6", RFC 6059, 595 DOI 10.17487/RFC6059, November 2010, 596 . 598 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 599 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 600 2011, . 602 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 603 IETF Protocol and Documentation Usage for IEEE 802 604 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 605 October 2013, . 607 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 608 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 609 February 2014, . 611 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 612 Interface Identifiers with IPv6 Stateless Address 613 Autoconfiguration (SLAAC)", RFC 7217, 614 DOI 10.17487/RFC7217, April 2014, 615 . 617 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 618 "Recommendation on Stable IPv6 Interface Identifiers", 619 RFC 8064, DOI 10.17487/RFC8064, February 2017, 620 . 622 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 623 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 624 May 2017, . 626 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 627 (IPv6) Specification", STD 86, RFC 8200, 628 DOI 10.17487/RFC8200, July 2017, 629 . 631 9.2. Informative References 633 [ETSI-sec-archi] 634 "ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical 635 Specification, Intelligent Transport Systems (ITS); 636 Security; ITS communications security architecture and 637 security management, November 2016. Downloaded on 638 September 9th, 2017, freely available from ETSI website at 639 URL http://www.etsi.org/deliver/ 640 etsi_ts/102900_102999/102940/01.02.01_60/ 641 ts_102940v010201p.pdf". 643 [I-D.ietf-ipwave-vehicular-networking] 644 Jeong, J., "IP Wireless Access in Vehicular Environments 645 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 646 ipwave-vehicular-networking-11 (work in progress), July 647 2019. 649 [I-D.ietf-mboned-ieee802-mcast-problems] 650 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 651 Zuniga, "Multicast Considerations over IEEE 802 Wireless 652 Media", draft-ietf-mboned-ieee802-mcast-problems-07 (work 653 in progress), July 2019. 655 [IEEE-1609.2] 656 "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access 657 in Vehicular Environments (WAVE) -- Security Services for 658 Applications and Management Messages. Example URL 659 http://ieeexplore.ieee.org/document/7426684/ accessed on 660 August 17th, 2017.". 662 [IEEE-1609.3] 663 "IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access 664 in Vehicular Environments (WAVE) -- Networking Services. 665 Example URL http://ieeexplore.ieee.org/document/7458115/ 666 accessed on August 17th, 2017.". 668 [IEEE-1609.4] 669 "IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access 670 in Vehicular Environments (WAVE) -- Multi-Channel 671 Operation. Example URL 672 http://ieeexplore.ieee.org/document/7435228/ accessed on 673 August 17th, 2017.". 675 [IEEE-802.11p-2010] 676 "IEEE Std 802.11p (TM)-2010, IEEE Standard for Information 677 Technology - Telecommunications and information exchange 678 between systems - Local and metropolitan area networks - 679 Specific requirements, Part 11: Wireless LAN Medium Access 680 Control (MAC) and Physical Layer (PHY) Specifications, 681 Amendment 6: Wireless Access in Vehicular Environments; 682 document freely available at URL 683 http://standards.ieee.org/getieee802/ 684 download/802.11p-2010.pdf retrieved on September 20th, 685 2013.". 687 [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related 688 Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, 689 . 691 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 692 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 693 RFC 3963, DOI 10.17487/RFC3963, January 2005, 694 . 696 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 697 "SEcure Neighbor Discovery (SEND)", RFC 3971, 698 DOI 10.17487/RFC3971, March 2005, 699 . 701 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 702 RFC 3972, DOI 10.17487/RFC3972, March 2005, 703 . 705 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 706 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 707 September 2010, . 709 [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address 710 Validation Improvement (SAVI) Threat Scope", RFC 6959, 711 DOI 10.17487/RFC6959, May 2013, 712 . 714 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 715 Considerations for IPv6 Address Generation Mechanisms", 716 RFC 7721, DOI 10.17487/RFC7721, March 2016, 717 . 719 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 720 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 721 February 2017, . 723 [SHA256] "Secure Hash Standard (SHS), National Institute of 724 Standards and Technology. 725 https://csrc.nist.gov/CSRC/media/Publications/fips/180/2/ 726 archive/2002-08-01/documents/fips180-2.pdf". 728 Appendix A. 802.11p 730 The term "802.11p" is an earlier definition. The behaviour of 731 "802.11p" networks is rolled in the document IEEE Std 802.11-2016. 732 In that document the term 802.11p disappears. Instead, each 802.11p 733 feature is conditioned by the IEEE Management Information Base (MIB) 734 attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated 735 is set to true the IEEE Std 802.11-OCB state is activated. For 736 example, an 802.11 STAtion operating outside the context of a basic 737 service set has the OCBActivated flag set. Such a station, when it 738 has the flag set, uses a BSS identifier equal to ff:ff:ff:ff:ff:ff. 740 Appendix B. Aspects introduced by the OCB mode to 802.11 742 In the IEEE 802.11-OCB mode, all nodes in the wireless range can 743 directly communicate with each other without involving authentication 744 or association procedures. In OCB mode, the manner in which channels 745 are selected and used is simplified compared to when in BSS mode. 746 Contrary to BSS mode, at link layer, it is necessary to set 747 statically the same channel number (or frequency) on two stations 748 that need to communicate with each other (in BSS mode this channel 749 set operation is performed automatically during 'scanning'). The 750 manner in which stations set their channel number in OCB mode is not 751 specified in this document. Stations STA1 and STA2 can exchange IP 752 packets only if they are set on the same channel. At IP layer, they 753 then discover each other by using the IPv6 Neighbor Discovery 754 protocol. The allocation of a particular channel for a particular 755 use is defined statically in standards authored by ETSI (in Europe), 756 FCC in America, and similar organisations in South Korea, Japan and 757 other parts of the world. 759 Briefly, the IEEE 802.11-OCB mode has the following properties: 761 o The use by each node of a 'wildcard' BSSID (i.e., each bit of the 762 BSSID is set to 1) 764 o No IEEE 802.11 Beacon frames are transmitted 766 o No authentication is required in order to be able to communicate 768 o No association is needed in order to be able to communicate 770 o No encryption is provided in order to be able to communicate 772 o Flag dot11OCBActivated is set to true 774 All the nodes in the radio communication range (IP-OBU and IP-RSU) 775 receive all the messages transmitted (IP-OBU and IP-RSU) within the 776 radio communications range. The eventual conflict(s) are resolved by 777 the MAC CDMA function. 779 The message exchange diagram in Figure 1 illustrates a comparison 780 between traditional 802.11 and 802.11 in OCB mode. The 'Data' 781 messages can be IP packets such as HTTP or others. Other 802.11 782 management and control frames (non IP) may be transmitted, as 783 specified in the 802.11 standard. For information, the names of 784 these messages as currently specified by the 802.11 standard are 785 listed in Appendix F. 787 STA AP STA1 STA2 788 | | | | 789 |<------ Beacon -------| |<------ Data -------->| 790 | | | | 791 |---- Probe Req. ----->| |<------ Data -------->| 792 |<--- Probe Res. ------| | | 793 | | |<------ Data -------->| 794 |---- Auth Req. ------>| | | 795 |<--- Auth Res. -------| |<------ Data -------->| 796 | | | | 797 |---- Asso Req. ------>| |<------ Data -------->| 798 |<--- Asso Res. -------| | | 799 | | |<------ Data -------->| 800 |<------ Data -------->| | | 801 |<------ Data -------->| |<------ Data -------->| 803 (i) 802.11 Infrastructure mode (ii) 802.11-OCB mode 805 Figure 1: Difference between messages exchanged on 802.11 (left) and 806 802.11-OCB (right) 808 The interface 802.11-OCB was specified in IEEE Std 802.11p (TM) -2010 809 [IEEE-802.11p-2010] as an amendment to IEEE Std 802.11 (TM) -2007, 810 titled "Amendment 6: Wireless Access in Vehicular Environments". 811 Since then, this amendment has been integrated in IEEE 802.11(TM) 812 -2012 and -2016 [IEEE-802.11-2016]. 814 In document 802.11-2016, anything qualified specifically as 815 "OCBActivated", or "outside the context of a basic service" set to be 816 true, then it is actually referring to OCB aspects introduced to 817 802.11. 819 In order to delineate the aspects introduced by 802.11-OCB to 802.11, 820 we refer to the earlier [IEEE-802.11p-2010]. The amendment is 821 concerned with vehicular communications, where the wireless link is 822 similar to that of Wireless LAN (using a PHY layer specified by 823 802.11a/b/g/n), but which needs to cope with the high mobility factor 824 inherent in scenarios of communications between moving vehicles, and 825 between vehicles and fixed infrastructure deployed along roads. 826 While 'p' is a letter identifying the Amendment, just like 'a, b, g' 827 and 'n' are, 'p' is concerned more with MAC modifications, and a 828 little with PHY modifications; the others are mainly about PHY 829 modifications. It is possible in practice to combine a 'p' MAC with 830 an 'a' PHY by operating outside the context of a BSS with OFDM at 831 5.4GHz and 5.9GHz. 833 The 802.11-OCB links are specified to be compatible as much as 834 possible with the behaviour of 802.11a/b/g/n and future generation 835 IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer 836 offers practically the same interface to IP as the 802.11a/b/g/n and 837 802.3. A packet sent by an IP-OBU may be received by one or multiple 838 IP-RSUs. The link-layer resolution is performed by using the IPv6 839 Neighbor Discovery protocol. 841 To support this similarity statement (IPv6 is layered on top of LLC 842 on top of 802.11-OCB, in the same way that IPv6 is layered on top of 843 LLC on top of 802.11a/b/g/n (for WLAN) or layered on top of LLC on 844 top of 802.3 (for Ethernet)) it is useful to analyze the differences 845 between 802.11-OCB and 802.11 specifications. During this analysis, 846 we note that whereas 802.11-OCB lists relatively complex and numerous 847 changes to the MAC layer (and very little to the PHY layer), there 848 are only a few characteristics which may be important for an 849 implementation transmitting IPv6 packets on 802.11-OCB links. 851 The most important 802.11-OCB point which influences the IPv6 852 functioning is the OCB characteristic; an additional, less direct 853 influence, is the maximum bandwidth afforded by the PHY modulation/ 854 demodulation methods and channel access specified by 802.11-OCB. The 855 maximum bandwidth theoretically possible in 802.11-OCB is 54 Mbit/s 856 (when using, for example, the following parameters: 20 MHz channel; 857 modulation 64-QAM; coding rate R is 3/4); in practice of IP-over- 858 802.11-OCB a commonly observed figure is 12Mbit/s; this bandwidth 859 allows the operation of a wide range of protocols relying on IPv6. 861 o Operation Outside the Context of a BSS (OCB): the (earlier 862 802.11p) 802.11-OCB links are operated without a Basic Service Set 863 (BSS). This means that the frames IEEE 802.11 Beacon, Association 864 Request/Response, Authentication Request/Response, and similar, 865 are not used. The used identifier of BSS (BSSID) has a 866 hexadecimal value always 0xffffffffffff (48 '1' bits, represented 867 as MAC address ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' 868 BSSID), as opposed to an arbitrary BSSID value set by 869 administrator (e.g. 'My-Home-AccessPoint'). The OCB operation - 870 namely the lack of beacon-based scanning and lack of 871 authentication - should be taken into account when the Mobile IPv6 872 protocol [RFC6275] and the protocols for IP layer security 873 [RFC4301] are used. The way these protocols adapt to OCB is not 874 described in this document. 876 o Timing Advertisement: is a new message defined in 802.11-OCB, 877 which does not exist in 802.11a/b/g/n. This message is used by 878 stations to inform other stations about the value of time. It is 879 similar to the time as delivered by a GNSS system (Galileo, GPS, 880 ...) or by a cellular system. This message is optional for 881 implementation. 883 o Frequency range: this is a characteristic of the PHY layer, with 884 almost no impact on the interface between MAC and IP. However, it 885 is worth considering that the frequency range is regulated by a 886 regional authority (ARCEP, ECC/CEPT based on ENs from ETSI, FCC, 887 etc.); as part of the regulation process, specific applications 888 are associated with specific frequency ranges. In the case of 889 802.11-OCB, the regulator associates a set of frequency ranges, or 890 slots within a band, to the use of applications of vehicular 891 communications, in a band known as "5.9GHz". The 5.9GHz band is 892 different from the 2.4GHz and 5GHz bands used by Wireless LAN. 893 However, as with Wireless LAN, the operation of 802.11-OCB in 894 "5.9GHz" bands is exempt from owning a license in EU (in US the 895 5.9GHz is a licensed band of spectrum; for the fixed 896 infrastructure an explicit FCC authorization is required; for an 897 on-board device a 'licensed-by-rule' concept applies: rule 898 certification conformity is required.) Technical conditions are 899 different than those of the bands "2.4GHz" or "5GHz". The allowed 900 power levels, and implicitly the maximum allowed distance between 901 vehicles, is of 33dBm for 802.11-OCB (in Europe), compared to 20 902 dBm for Wireless LAN 802.11a/b/g/n; this leads to a maximum 903 distance of approximately 1km, compared to approximately 50m. 905 Additionally, specific conditions related to congestion avoidance, 906 jamming avoidance, and radar detection are imposed on the use of 907 DSRC (in US) and on the use of frequencies for Intelligent 908 Transportation Systems (in EU), compared to Wireless LAN 909 (802.11a/b/g/n). 911 o 'Half-rate' encoding: as the frequency range, this parameter is 912 related to PHY, and thus has not much impact on the interface 913 between the IP layer and the MAC layer. 915 o In vehicular communications using 802.11-OCB links, there are 916 strong privacy requirements with respect to addressing. While the 917 802.11-OCB standard does not specify anything in particular with 918 respect to MAC addresses, in these settings there exists a strong 919 need for dynamic change of these addresses (as opposed to the non- 920 vehicular settings - real wall protection - where fixed MAC 921 addresses do not currently pose some privacy risks). This is 922 further described in Section 5. A relevant function is described 923 in documents IEEE 1609.3-2016 [IEEE-1609.3] and IEEE 1609.4-2016 924 [IEEE-1609.4]. 926 Appendix C. Changes Needed on a software driver 802.11a to become a 927 802.11-OCB driver 929 The 802.11p amendment modifies both the 802.11 stack's physical and 930 MAC layers but all the induced modifications can be quite easily 931 obtained by modifying an existing 802.11a ad-hoc stack. 933 Conditions for a 802.11a hardware to be 802.11-OCB compliant: 935 o The PHY entity shall be an orthogonal frequency division 936 multiplexing (OFDM) system. It must support the frequency bands 937 on which the regulator recommends the use of ITS communications, 938 for example using IEEE 802.11-OCB layer, in France: 5875MHz to 939 5925MHz. 941 o The OFDM system must provide a "half-clocked" operation using 10 942 MHz channel spacings. 944 o The chip transmit spectrum mask must be compliant to the "Transmit 945 spectrum mask" from the IEEE 802.11p amendment (but experimental 946 environments tolerate otherwise). 948 o The chip should be able to transmit up to 44.8 dBm when used by 949 the US government in the United States, and up to 33 dBm in 950 Europe; other regional conditions apply. 952 Changes needed on the network stack in OCB mode: 954 o Physical layer: 956 * The chip must use the Orthogonal Frequency Multiple Access 957 (OFDM) encoding mode. 959 * The chip must be set in half-mode rate mode (the internal clock 960 frequency is divided by two). 962 * The chip must use dedicated channels and should allow the use 963 of higher emission powers. This may require modifications to 964 the local computer file that describes regulatory domains 965 rules, if used by the kernel to enforce local specific 966 restrictions. Such modifications to the local computer file 967 must respect the location-specific regulatory rules. 969 MAC layer: 971 * All management frames (beacons, join, leave, and others) 972 emission and reception must be disabled except for frames of 973 subtype Action and Timing Advertisement (defined below). 975 * No encryption key or method must be used. 977 * Packet emission and reception must be performed as in ad-hoc 978 mode, using the wildcard BSSID (ff:ff:ff:ff:ff:ff). 980 * The functions related to joining a BSS (Association Request/ 981 Response) and for authentication (Authentication Request/Reply, 982 Challenge) are not called. 984 * The beacon interval is always set to 0 (zero). 986 * Timing Advertisement frames, defined in the amendment, should 987 be supported. The upper layer should be able to trigger such 988 frames emission and to retrieve information contained in 989 received Timing Advertisements. 991 Appendix D. Protocol Layering 993 A more theoretical and detailed view of layer stacking, and 994 interfaces between the IP layer and 802.11-OCB layers, is illustrated 995 in Figure 2. The IP layer operates on top of the EtherType Protocol 996 Discrimination (EPD); this Discrimination layer is described in IEEE 997 Std 802.3-2012; the interface between IPv6 and EPD is the LLC_SAP 998 (Link Layer Control Service Access Point). 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | IPv6 | 1002 +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ 1003 { LLC_SAP } 802.11-OCB 1004 +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary 1005 | EPD | | | 1006 | | MLME | | 1007 +-+-+-{ MAC_SAP }+-+-+-| MLME_SAP | 1008 | MAC Sublayer | | | 802.11-OCB 1009 | and ch. coord. | | SME | Services 1010 +-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| | 1011 | | PLME | | 1012 | PHY Layer | PLME_SAP | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 Figure 2: EtherType Protocol Discrimination 1017 Appendix E. Design Considerations 1019 The networks defined by 802.11-OCB are in many ways similar to other 1020 networks of the 802.11 family. In theory, the transportation of IPv6 1021 over 802.11-OCB could be very similar to the operation of IPv6 over 1022 other networks of the 802.11 family. However, the high mobility, 1023 strong link asymmetry and very short connection makes the 802.11-OCB 1024 link significantly different from other 802.11 networks. Also, the 1025 automotive applications have specific requirements for reliability, 1026 security and privacy, which further add to the particularity of the 1027 802.11-OCB link. 1029 Appendix F. IEEE 802.11 Messages Transmitted in OCB mode 1031 For information, at the time of writing, this is the list of IEEE 1032 802.11 messages that may be transmitted in OCB mode, i.e. when 1033 dot11OCBActivated is true in a STA: 1035 o The STA may send management frames of subtype Action and, if the 1036 STA maintains a TSF Timer, subtype Timing Advertisement; 1038 o The STA may send control frames, except those of subtype PS-Poll, 1039 CF-End, and CF-End plus CFAck; 1041 o The STA MUST send data frames of subtype QoS Data. 1043 Appendix G. Examples of Packet Formats 1045 This section describes an example of an IPv6 Packet captured over a 1046 IEEE 802.11-OCB link. 1048 By way of example we show that there is no modification in the 1049 headers when transmitted over 802.11-OCB networks - they are 1050 transmitted like any other 802.11 and Ethernet packets. 1052 We describe an experiment of capturing an IPv6 packet on an 1053 802.11-OCB link. In topology depicted in Figure 3, the packet is an 1054 IPv6 Router Advertisement. This packet is emitted by a Router on its 1055 802.11-OCB interface. The packet is captured on the Host, using a 1056 network protocol analyzer (e.g. Wireshark); the capture is performed 1057 in two different modes: direct mode and 'monitor' mode. The topology 1058 used during the capture is depicted below. 1060 The packet is captured on the Host. The Host is an IP-OBU containing 1061 an 802.11 interface in format PCI express (an ITRI product). The 1062 kernel runs the ath5k software driver with modifications for OCB 1063 mode. The capture tool is Wireshark. The file format for save and 1064 analyze is 'pcap'. The packet is generated by the Router. The 1065 Router is an IP-RSU (ITRI product). 1067 +--------+ +-------+ 1068 | | 802.11-OCB Link | | 1069 ---| Router |--------------------------------| Host | 1070 | | | | 1071 +--------+ +-------+ 1073 Figure 3: Topology for capturing IP packets on 802.11-OCB 1075 During several capture operations running from a few moments to 1076 several hours, no message relevant to the BSSID contexts were 1077 captured (no Association Request/Response, Authentication Req/Resp, 1078 Beacon). This shows that the operation of 802.11-OCB is outside the 1079 context of a BSSID. 1081 Overall, the captured message is identical with a capture of an IPv6 1082 packet emitted on a 802.11b interface. The contents are precisely 1083 similar. 1085 G.1. Capture in Monitor Mode 1087 The IPv6 RA packet captured in monitor mode is illustrated below. 1088 The radio tap header provides more flexibility for reporting the 1089 characteristics of frames. The Radiotap Header is prepended by this 1090 particular stack and operating system on the Host machine to the RA 1091 packet received from the network (the Radiotap Header is not present 1092 on the air). The implementation-dependent Radiotap Header is useful 1093 for piggybacking PHY information from the chip's registers as data in 1094 a packet understandable by userland applications using Socket 1095 interfaces (the PHY interface can be, for example: power levels, data 1096 rate, ratio of signal to noise). 1098 The packet present on the air is formed by IEEE 802.11 Data Header, 1099 Logical Link Control Header, IPv6 Base Header and ICMPv6 Header. 1101 Radiotap Header v0 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 |Header Revision| Header Pad | Header length | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Present flags | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Data Rate | Pad | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 IEEE 802.11 Data Header 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | Type/Subtype and Frame Ctrl | Duration | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Receiver Address... 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 ... Receiver Address | Transmitter Address... 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 ... Transmitter Address | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | BSS Id... 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 ... BSS Id | Frag Number and Seq Number | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 Logical-Link Control Header 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | DSAP |I| SSAP |C| Control field | Org. code... 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 ... Organizational Code | Type | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 IPv6 Base Header 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 |Version| Traffic Class | Flow Label | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Payload Length | Next Header | Hop Limit | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | | 1138 + + 1139 | | 1140 + Source Address + 1141 | | 1142 + + 1143 | | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | | 1146 + + 1147 | | 1148 + Destination Address + 1149 | | 1150 + + 1151 | | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 Router Advertisement 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Type | Code | Checksum | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Reachable Time | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Retrans Timer | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Options ... 1165 +-+-+-+-+-+-+-+-+-+-+-+- 1167 The value of the Data Rate field in the Radiotap header is set to 6 1168 Mb/s. This indicates the rate at which this RA was received. 1170 The value of the Transmitter address in the IEEE 802.11 Data Header 1171 is set to a 48bit value. The value of the destination address is 1172 33:33:00:00:00:1 (all-nodes multicast address). The value of the BSS 1173 Id field is ff:ff:ff:ff:ff:ff, which is recognized by the network 1174 protocol analyzer as being "broadcast". The Fragment number and 1175 sequence number fields are together set to 0x90C6. 1177 The value of the Organization Code field in the Logical-Link Control 1178 Header is set to 0x0, recognized as "Encapsulated Ethernet". The 1179 value of the Type field is 0x86DD (hexadecimal 86DD, or otherwise 1180 #86DD), recognized as "IPv6". 1182 A Router Advertisement is periodically sent by the router to 1183 multicast group address ff02::1. It is an icmp packet type 134. The 1184 IPv6 Neighbor Discovery's Router Advertisement message contains an 1185 8-bit field reserved for single-bit flags, as described in [RFC4861]. 1187 The IPv6 header contains the link local address of the router 1188 (source) configured via EUI-64 algorithm, and destination address set 1189 to ff02::1. 1191 The Ethernet Type field in the logical-link control header is set to 1192 0x86dd which indicates that the frame transports an IPv6 packet. In 1193 the IEEE 802.11 data, the destination address is 33:33:00:00:00:01 1194 which is the corresponding multicast MAC address. The BSS id is a 1195 broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link 1196 duration between vehicles and the roadside infrastructure, there is 1197 no need in IEEE 802.11-OCB to wait for the completion of association 1198 and authentication procedures before exchanging data. IEEE 1199 802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s) 1200 and may start communicating as soon as they arrive on the 1201 communication channel. 1203 G.2. Capture in Normal Mode 1205 The same IPv6 Router Advertisement packet described above (monitor 1206 mode) is captured on the Host, in the Normal mode, and depicted 1207 below. 1209 Ethernet II Header 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 | Destination... 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 ...Destination | Source... 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 ...Source | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Type | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 IPv6 Base Header 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 |Version| Traffic Class | Flow Label | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Payload Length | Next Header | Hop Limit | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | | 1227 + + 1228 | | 1229 + Source Address + 1230 | | 1231 + + 1232 | | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | | 1235 + + 1236 | | 1237 + Destination Address + 1238 | | 1239 + + 1240 | | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 Router Advertisement 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | Type | Code | Checksum | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Reachable Time | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | Retrans Timer | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | Options ... 1254 +-+-+-+-+-+-+-+-+-+-+-+- 1256 One notices that the Radiotap Header, the IEEE 802.11 Data Header and 1257 the Logical-Link Control Headers are not present. On the other hand, 1258 a new header named Ethernet II Header is present. 1260 The Destination and Source addresses in the Ethernet II header 1261 contain the same values as the fields Receiver Address and 1262 Transmitter Address present in the IEEE 802.11 Data Header in the 1263 "monitor" mode capture. 1265 The value of the Type field in the Ethernet II header is 0x86DD 1266 (recognized as "IPv6"); this value is the same value as the value of 1267 the field Type in the Logical-Link Control Header in the "monitor" 1268 mode capture. 1270 The knowledgeable experimenter will no doubt notice the similarity of 1271 this Ethernet II Header with a capture in normal mode on a pure 1272 Ethernet cable interface. 1274 A frame translation is inserted on top of a pure IEEE 802.11 MAC 1275 layer, in order to adapt packets, before delivering the payload data 1276 to the applications. It adapts 802.11 LLC/MAC headers to Ethernet II 1277 headers. In further detail, this adaptation consists in the 1278 elimination of the Radiotap, 802.11 and LLC headers, and in the 1279 insertion of the Ethernet II header. In this way, IPv6 runs straight 1280 over LLC over the 802.11-OCB MAC layer; this is further confirmed by 1281 the use of the unique Type 0x86DD. 1283 Appendix H. Extra Terminology 1285 The following terms are defined outside the IETF. They are used to 1286 define the main terms in the main terminology Section 2. 1288 DSRC (Dedicated Short Range Communication): a term defined outside 1289 the IETF. The US Federal Communications Commission (FCC) Dedicated 1290 Short Range Communication (DSRC) is defined in the Code of Federal 1291 Regulations (CFR) 47, Parts 90 and 95. This Code is referred in the 1292 definitions below. At the time of the writing of this Internet 1293 Draft, the last update of this Code was dated October 1st, 2010. 1295 DSRCS (Dedicated Short-Range Communications Services): a term defined 1296 outside the IETF. The use of radio techniques to transfer data over 1297 short distances between roadside and mobile units, between mobile 1298 units, and between portable and mobile units to perform operations 1299 related to the improvement of traffic flow, traffic safety, and other 1300 intelligent transportation service applications in a variety of 1301 environments. DSRCS systems may also transmit status and 1302 instructional messages related to the units involve. [Ref. 47 CFR 1303 90.7 - Definitions] 1304 OBU (On-Board Unit): a term defined outside the IETF. An On-Board 1305 Unit is a DSRCS transceiver that is normally mounted in or on a 1306 vehicle, or which in some instances may be a portable unit. An OBU 1307 can be operational while a vehicle or person is either mobile or 1308 stationary. The OBUs receive and contend for time to transmit on one 1309 or more radio frequency (RF) channels. Except where specifically 1310 excluded, OBU operation is permitted wherever vehicle operation or 1311 human passage is permitted. The OBUs mounted in vehicles are 1312 licensed by rule under part 95 of the respective chapter and 1313 communicate with Roadside Units (RSUs) and other OBUs. Portable OBUs 1314 are also licensed by rule under part 95 of the respective chapter. 1315 OBU operations in the Unlicensed National Information Infrastructure 1316 (UNII) Bands follow the rules in those bands. - [CFR 90.7 - 1317 Definitions]. 1319 RSU (Road-Side Unit): a term defined outside of IETF. A Roadside 1320 Unit is a DSRC transceiver that is mounted along a road or pedestrian 1321 passageway. An RSU may also be mounted on a vehicle or is hand 1322 carried, but it may only operate when the vehicle or hand- carried 1323 unit is stationary. Furthermore, an RSU operating under the 1324 respectgive part is restricted to the location where it is licensed 1325 to operate. However, portable or hand-held RSUs are permitted to 1326 operate where they do not interfere with a site-licensed operation. 1327 A RSU broadcasts data to OBUs or exchanges data with OBUs in its 1328 communications zone. An RSU also provides channel assignments and 1329 operating instructions to OBUs in its communications zone, when 1330 required. - [CFR 90.7 - Definitions]. 1332 Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless Links 1334 IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] was designed for 1335 point-to-point and transit links such as Ethernet, with the 1336 expectation of a cheap and reliable support for multicast from the 1337 lower layer. Section 3.2 of RFC 4861 indicates that the operation on 1338 Shared Media and on non-broadcast multi-access (NBMA) networks 1339 require additional support, e.g., for Address Resolution (AR) and 1340 duplicate address detection (DAD), which depend on multicast. An 1341 infrastructureless radio network such as OCB shares properties with 1342 both Shared Media and NBMA networks, and then adds its own 1343 complexity, e.g., from movement and interference that allow only 1344 transient and non-transitive reachability between any set of peers. 1346 The uniqueness of an address within a scoped domain is a key pillar 1347 of IPv6 and the base for unicast IP communication. RFC 4861 details 1348 the DAD method to avoid that an address is duplicated. For a link 1349 local address, the scope is the link, whereas for a Globally 1350 Reachable address the scope is much larger. The underlying 1351 assumption for DAD to operate correctly is that the node that owns an 1352 IPv6 address can reach any other node within the scope at the time it 1353 claims its address, which is done by sending a NS multicast message, 1354 and can hear any future claim for that address by another party 1355 within the scope for the duration of the address ownership. 1357 In the case of OCB, there is a potentially a need to define a scope 1358 that is compatible with DAD, and that cannot be the set of nodes that 1359 a transmitter can reach at a particular time, because that set varies 1360 all the time and does not meet the DAD requirements for a link local 1361 address that could possibly be used anytime, anywhere. The generic 1362 expectation of a reliable multicast is not ensured, and the operation 1363 of DAD and AR (Address Resolution) as specified by RFC 4861 cannot be 1364 guaranteed. Moreover, multicast transmissions that rely on broadcast 1365 are not only unreliable but are also often detrimental to unicast 1366 traffic (see [draft-ietf-mboned-ieee802-mcast-problems]). 1368 Early experience indicates that it should be possible to exchange 1369 IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR 1370 (Address Resolution) in good conditions. In the absence of a correct 1371 DAD operation, a node that relies only on IPv6 ND for AR and DAD over 1372 OCB should ensure that the addresses that it uses are unique by means 1373 others than DAD. It must be noted that deriving an IPv6 address from 1374 a globally unique MAC address has this property but may yield privacy 1375 issues. 1377 RFC 8505 provides a more recent approach to IPv6 ND and in particular 1378 DAD. RFC 8505 is designed to fit wireless and otherwise constrained 1379 networks whereby multicast and/or continuous access to the medium may 1380 not be guaranteed. RFC 8505 Section 5.6 "Link-Local Addresses and 1381 Registration" indicates that the scope of uniqueness for a link local 1382 address is restricted to a pair of nodes that use it to communicate, 1383 and provides a method to assert the uniqueness and resolve the link- 1384 Layer address using a unicast exchange. 1386 RFC 8505 also enables a router (acting as a 6LR) to own a prefix and 1387 act as a registrar (acting as a 6LBR) for addresses within the 1388 associated subnet. A peer host (acting as a 6LN) registers an 1389 address derived from that prefix and can use it for the lifetime of 1390 the registration. The prefix is advertised as not onlink, which 1391 means that the 6LN uses the 6LR to relay its packets within the 1392 subnet, and participation to the subnet is constrained to the time of 1393 reachability to the 6LR. Note that RSU that provides internet 1394 connectivity MAY announce a default router preference [RFC4191], 1395 whereas a car that does not provide that connectivity MUST NOT do so. 1396 This operation presents similarities with that of an access point, 1397 but at Layer-3. This is why RFC 8505 well-suited for wireless in 1398 general. 1400 Support of RFC 8505 may be implemented on OCB. OCB nodes that 1401 support RFC 8505 SHOULD support the 6LN operation in order to act as 1402 a host, and may support the 6LR and 6LBR operations in order to act 1403 as a router and in particular own a prefix that can be used by RFC 1404 8505-compliant hosts for address autoconfiguration and registration. 1406 Authors' Addresses 1408 Nabil Benamar 1409 Moulay Ismail University of Meknes 1410 Morocco 1412 Phone: +212670832236 1413 Email: n.benamar@est.umi.ac.ma 1415 Jerome Haerri 1416 Eurecom 1417 Sophia-Antipolis 06904 1418 France 1420 Phone: +33493008134 1421 Email: Jerome.Haerri@eurecom.fr 1423 Jong-Hyouk Lee 1424 Sangmyung University 1425 31, Sangmyeongdae-gil, Dongnam-gu 1426 Cheonan 31066 1427 Republic of Korea 1429 Email: jonghyouk@smu.ac.kr 1431 Thierry Ernst 1432 YoGoKo 1433 France 1435 Email: thierry.ernst@yogoko.fr