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