idnits 2.17.1 draft-ietf-ipwave-ipv6-over-80211ocb-20.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 (March 2, 2018) is 2244 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) == Unused Reference: 'I-D.ietf-tsvwg-ieee-802-11' is defined on line 597, 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 ** Obsolete normative reference: RFC 7042 (Obsoleted by RFC 9542) ** Downref: Normative reference to an Informational RFC: RFC 7721 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Petrescu 3 Internet-Draft CEA, LIST 4 Intended status: Standards Track N. Benamar 5 Expires: September 3, 2018 Moulay Ismail University 6 J. Haerri 7 Eurecom 8 J. Lee 9 Sangmyung University 10 T. Ernst 11 YoGoKo 12 March 2, 2018 14 Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode 15 Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) 16 draft-ietf-ipwave-ipv6-over-80211ocb-20.txt 18 Abstract 20 In order to transmit IPv6 packets on IEEE 802.11 networks running 21 outside the context of a basic service set (OCB, earlier "802.11p") 22 there is a need to define a few parameters such as the supported 23 Maximum Transmission Unit size on the 802.11-OCB link, the header 24 format preceding the IPv6 header, the Type value within it, and 25 others. This document describes these parameters for IPv6 and IEEE 26 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB 27 similarly to other known 802.11 and Ethernet layers - by using an 28 Ethernet Adaptation Layer. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 3, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4 67 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 69 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 70 4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 71 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 72 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 73 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 74 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 7 75 4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 76 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 9.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 15 85 Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 23 86 Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 23 87 Appendix D. Changes Needed on a software driver 802.11a to 88 become a 802.11-OCB driver . . . 27 89 Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 28 90 Appendix F. Design Considerations . . . . . . . . . . . . . . . 29 91 F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29 92 F.2. Reliability Requirements . . . . . . . . . . . . . . . . 30 93 F.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30 94 F.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31 96 Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31 97 Appendix H. Implementation Status . . . . . . . . . . . . . . . 32 98 H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33 99 H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35 100 Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 37 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 103 1. Introduction 105 This document describes the transmission of IPv6 packets on IEEE Std 106 802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see 107 Appendix B). This involves the layering of IPv6 networking on top of 108 the IEEE 802.11 MAC layer, with an LLC layer. Compared to running 109 IPv6 over the Ethernet MAC layer, there is no modification expected 110 to IEEE Std 802.11 MAC and Logical Link sublayers: IPv6 works fine 111 directly over 802.11-OCB too, with an LLC layer. 113 The IPv6 network layer operates on 802.11-OCB in the same manner as 114 operating on Ethernet, but there are two kinds of exceptions: 116 o Exceptions due to different operation of IPv6 network layer on 117 802.11 than on Ethernet. To satisfy these exceptions, this 118 document describes an Ethernet Adaptation Layer between Ethernet 119 headers and 802.11 headers. The Ethernet Adaptation Layer is 120 described Section 4.2.1. The operation of IP on Ethernet is 121 described in [RFC1042], [RFC2464] and 122 [I-D.hinden-6man-rfc2464bis]. 124 o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11. 125 This has impacts on security, privacy, subnet structure and 126 handover behaviour. For security and privacy recommendations see 127 Section 5 and Section 4.5. The subnet structure is described in 128 Section 4.6. The handover behaviour on OCB links is not described 129 in this document. 131 In the published literature, many documents describe aspects and 132 problems related to running IPv6 over 802.11-OCB: 133 [I-D.ietf-ipwave-vehicular-networking-survey]. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer 142 situated in a vehicle such as an automobile, bicycle, or similar. It 143 has at least one IP interface that runs in mode OCB of 802.11, and 144 that has an "OBU" transceiver. See the definition of the term "OBU" 145 in section Appendix I. 147 IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. An 148 IP-RSU has at least two distinct IP-enabled interfaces; at least one 149 interface is operated in mode OCB of IEEE 802.11 and is IP-enabled. 150 An IP-RSU is similar to a Wireless Termination Point (WTP), as 151 defined in [RFC5415], or an Access Point (AP), as defined in IEEE 152 documents, or an Access Network Router (ANR) defined in [RFC3753], 153 with one key particularity: the wireless PHY/MAC layer of at least 154 one of its IP-enabled interfaces is configured to operate in 155 802.11-OCB mode. The IP-RSU communicates with the IP-OBU in the 156 vehicle over 802.11 wireless link operating in OCB mode. 158 OCB (outside the context of a basic service set - BSS): 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: mode specified in IEEE Std 802.11-2016 when the MIB 164 attribute dot11OCBActivited is true. Note: compliance with standards 165 and regulations set in different countries when using the 5.9GHz 166 frequency band is required. 168 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 170 The IEEE 802.11-OCB Networks are used for vehicular communications, 171 as 'Wireless Access in Vehicular Environments'. The IP communication 172 scenarios for these environments have been described in several 173 documents; in particular, we refer the reader to 174 [I-D.ietf-ipwave-vehicular-networking-survey], that lists some 175 scenarios and requirements for IP in Intelligent Transportation 176 Systems. 178 The link model is the following: STA --- 802.11-OCB --- STA. In 179 vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. While 180 802.11-OCB is clearly specified, and the use of IPv6 over such link 181 is not radically new, the operating environment (vehicular networks) 182 brings in new perspectives. 184 The mechanisms for forming and terminating, discovering, peering and 185 mobility management for 802.11-OCB links are not described in this 186 document. 188 4. IPv6 over 802.11-OCB 190 4.1. Maximum Transmission Unit (MTU) 192 The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. It 193 is the same value as IPv6 packets on Ethernet links, as specified in 194 [RFC2464]. This value of the MTU respects the recommendation that 195 every link on the Internet must have a minimum MTU of 1280 octets 196 (stated in [RFC8200], and the recommendations therein, especially 197 with respect to fragmentation). 199 4.2. Frame Format 201 IP packets are transmitted over 802.11-OCB as standard Ethernet 202 packets. As with all 802.11 frames, an Ethernet adaptation layer 203 MUST be used with 802.11-OCB as well. This Ethernet Adaptation Layer 204 performing 802.11-to-Ethernet is described in Section 4.2.1. The 205 Ethernet Type code (EtherType) for IPv6 MUST be 0x86DD (hexadecimal 206 86DD, or otherwise #86DD). 208 The Frame format for transmitting IPv6 on 802.11-OCB networks MUST be 209 the same as transmitting IPv6 on Ethernet networks, and is described 210 in section 3 of [RFC2464]. 212 4.2.1. Ethernet Adaptation Layer 214 An 'adaptation' layer is inserted between a MAC layer and the 215 Networking layer. This is used to transform some parameters between 216 their form expected by the IP stack and the form provided by the MAC 217 layer. 219 An Ethernet Adaptation Layer makes an 802.11 MAC look to IP 220 Networking layer as a more traditional Ethernet layer. At reception, 221 this layer takes as input the IEEE 802.11 header and the Logical-Link 222 Layer Control Header and produces an Ethernet II Header. At sending, 223 the reverse operation is performed. 225 The operation of the Ethernet Adaptation Layer is depicted by the 226 double arrow in Figure 1. 228 +--------------------+------------+-------------+---------+-----------+ 229 | 802.11 header | LLC Header | IPv6 Header | Payload |.11 Trailer| 230 +--------------------+------------+-------------+---------+-----------+ 231 \ / \ / 232 ----------------------------- -------- 233 \---------------------------------------------/ 234 ^ 235 | 236 802.11-to-Ethernet Adaptation Layer 237 | 238 v 239 +---------------------+-------------+---------+ 240 | Ethernet II Header | IPv6 Header | Payload | 241 +---------------------+-------------+---------+ 243 Figure 1: Operation of the Ethernet Adaptation Layer 245 The Receiver and Transmitter Address fields in the 802.11 header MUST 246 contain the same values as the Destination and the Source Address 247 fields in the Ethernet II Header, respectively. The value of the 248 Type field in the LLC Header MUST be the same as the value of the 249 Type field in the Ethernet II Header. 251 The ".11 Trailer" contains solely a 4-byte Frame Check Sequence. 253 The specification of which type or subtype of 802.11 headers are used 254 to transmit IP packets is left outside the scope of this document. 256 The placement of IPv6 networking layer on Ethernet Adaptation Layer 257 is illustrated in Figure 2. 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | IPv6 | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Ethernet Adaptation Layer | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | 802.11 MAC | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | 802.11 PHY | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 2: Ethernet Adaptation Layer stacked with other layers 271 (in the above figure, a 802.11 profile is represented; this is used 272 also for 802.11 OCB profile.) 273 Other alternative views of layering are EtherType Protocol 274 Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. 276 4.3. Link-Local Addresses 278 The link-local address of an 802.11-OCB interface is formed in the 279 same manner as on an Ethernet interface. This manner is described in 280 section 5 of [RFC2464]. Additionally, if stable identifiers are 281 needed, it is RECOMMENDED to follow the Recommendation on Stable IPv6 282 Interface Identifiers [RFC8064]. Additionally, if semantically 283 opaque Interface Identifiers are needed, a potential method for 284 generating semantically opaque Interface Identifiers with IPv6 285 Stateless Address Autoconfiguration is given in [RFC7217]. 287 4.4. Address Mapping 289 Unicast and multicast address mapping MUST follow the procedures 290 specified for Ethernet interfaces in sections 6 and 7 of [RFC2464]. 292 4.4.1. Address Mapping -- Unicast 294 The procedure for mapping IPv6 unicast addresses into Ethernet link- 295 layer addresses is described in [RFC4861]. 297 4.4.2. Address Mapping -- Multicast 299 The multicast address mapping is performed according to the method 300 specified in section 7 of [RFC2464]. The meaning of the value "3333" 301 mentioned in that section 7 of [RFC2464] is defined in section 2.3.1 302 of [RFC7042]. 304 Transmitting IPv6 packets to multicast destinations over 802.11 links 305 proved to have some performance issues 306 [I-D.perkins-intarea-multicast-ieee802]. These issues may be 307 exacerbated in OCB mode. Solutions for these problems should 308 consider the OCB mode of operation. 310 4.5. Stateless Autoconfiguration 312 The Interface Identifier for an 802.11-OCB interface is formed using 313 the same rules as the Interface Identifier for an Ethernet interface; 314 this is described in section 4 of [RFC2464]. No changes are needed, 315 but some care must be taken when considering the use of the Stateless 316 Address Auto-Configuration procedure. 318 The bits in the interface identifier have no generic meaning and the 319 identifier should be treated as an opaque value. The bits 320 'Universal' and 'Group' in the identifier of an 802.11-OCB interface 321 are significant, as this is an IEEE link-layer address. The details 322 of this significance are described in [RFC7136]. 324 As with all Ethernet and 802.11 interface identifiers ([RFC7721]), 325 the identifier of an 802.11-OCB interface may involve privacy, MAC 326 address spoofing and IP address hijacking risks. A vehicle embarking 327 an OBU or an IP-OBU whose egress interface is 802.11-OCB may expose 328 itself to eavesdropping and subsequent correlation of data; this may 329 reveal data considered private by the vehicle owner; there is a risk 330 of being tracked; see the privacy considerations described in 331 Appendix F. 333 If stable Interface Identifiers are needed in order to form IPv6 334 addresses on 802.11-OCB links, it is recommended to follow the 335 recommendation in [RFC8064]. Additionally, if semantically opaque 336 Interface Identifiers are needed, a potential method for generating 337 semantically opaque Interface Identifiers with IPv6 Stateless Address 338 Autoconfiguration is given in [RFC7217]. 340 4.6. Subnet Structure 342 A subnet is formed by the external 802.11-OCB interfaces of vehicles 343 that are in close range (not their on-board interfaces). This 344 ephemeral subnet structure is strongly influenced by the mobility of 345 vehicles: the 802.11 hidden node effects appear. On another hand, 346 the structure of the internal subnets in each car is relatively 347 stable. 349 The 802.11 networks in OCB mode may be considered as 'ad-hoc' 350 networks. The addressing model for such networks is described in 351 [RFC5889]. 353 The operation of the Neighbor Discovery protocol (ND) over 802.11 OCB 354 links is different than over 802.11 links. In OCB, the link layer 355 does not ensure that all associated members receive all messages, 356 because there is no association operation. The operation of ND over 357 802.11 OCB is not specified in this document. 359 The operation of the Mobile IPv6 protocol over 802.11 OCB links is 360 different than on other links. The Movement Detection operation 361 (section 11.5.1 of [RFC6275]) can not rely on Neighbor Unreachability 362 Detection operation of the Neighbor Discovery protocol, for the 363 reason mentioned in the previous paragraph. Also, the 802.11 OCB 364 link layer is not a lower layer that can provide an indication that a 365 link layer handover has occured. The operation of the Mobile IPv6 366 protocol over 802.11 OCB is not specified in this document. 368 5. Security Considerations 370 Any security mechanism at the IP layer or above that may be carried 371 out for the general case of IPv6 may also be carried out for IPv6 372 operating over 802.11-OCB. 374 The OCB operation is stripped off of all existing 802.11 link-layer 375 security mechanisms. There is no encryption applied below the 376 network layer running on 802.11-OCB. At application layer, the IEEE 377 1609.2 document [IEEE-1609.2] does provide security services for 378 certain applications to use; application-layer mechanisms are out-of- 379 scope of this document. On another hand, a security mechanism 380 provided at networking layer, such as IPsec [RFC4301], may provide 381 data security protection to a wider range of applications. 383 802.11-OCB does not provide any cryptographic protection, because it 384 operates outside the context of a BSS (no Association Request/ 385 Response, no Challenge messages). Any attacker can therefore just 386 sit in the near range of vehicles, sniff the network (just set the 387 interface card's frequency to the proper range) and perform attacks 388 without needing to physically break any wall. Such a link is less 389 protected than commonly used links (wired link or protected 802.11). 391 The potential attack vectors are: MAC address spoofing, IP address 392 and session hijacking and privacy violation. 394 Within the IPsec Security Architecture [RFC4301], the IPsec AH and 395 ESP headers [RFC4302] and [RFC4303] respectively, its multicast 396 extensions [RFC5374], HTTPS [RFC2818] and SeND [RFC3971] protocols 397 can be used to protect communications. Further, the assistance of 398 proper Public Key Infrastructure (PKI) protocols [RFC4210] is 399 necessary to establish credentials. More IETF protocols are 400 available in the toolbox of the IP security protocol designer. 401 Certain ETSI protocols related to security protocols in Intelligent 402 Transportation Systems are described in [ETSI-sec-archi]. 404 As with all Ethernet and 802.11 interface identifiers, there may 405 exist privacy risks in the use of 802.11-OCB interface identifiers. 406 Moreover, in outdoors vehicular settings, the privacy risks are more 407 important than in indoors settings. New risks are induced by the 408 possibility of attacker sniffers deployed along routes which listen 409 for IP packets of vehicles passing by. For this reason, in the 410 802.11-OCB deployments, there is a strong necessity to use protection 411 tools such as dynamically changing MAC addresses. This may help 412 mitigate privacy risks to a certain level. On another hand, it may 413 have an impact in the way typical IPv6 address auto-configuration is 414 performed for vehicles (SLAAC would rely on MAC addresses and would 415 hence dynamically change the affected IP address), in the way the 416 IPv6 Privacy addresses were used, and other effects. 418 6. IANA Considerations 420 No request to IANA. 422 7. Contributors 424 Christian Huitema, Tony Li. 426 Romain Kuntz contributed extensively about IPv6 handovers between 427 links running outside the context of a BSS (802.11-OCB links). 429 Tim Leinmueller contributed the idea of the use of IPv6 over 430 802.11-OCB for distribution of certificates. 432 Marios Makassikis, Jose Santa Lozano, Albin Severinson and Alexey 433 Voronov provided significant feedback on the experience of using IP 434 messages over 802.11-OCB in initial trials. 436 Michelle Wetterwald contributed extensively the MTU discussion, 437 offered the ETSI ITS perspective, and reviewed other parts of the 438 document. 440 8. Acknowledgements 442 The authors would like to thank Witold Klaudel, Ryuji Wakikawa, 443 Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan 444 Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray 445 Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, 446 Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, 447 Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, 448 Bob Moskowitz, Andrew (Dryden?), Georg Mayer, Dorothy Stanley, Sandra 449 Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun, 450 Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano and William 451 Whyte. Their valuable comments clarified particular issues and 452 generally helped to improve the document. 454 Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB 455 drivers for linux and described how. 457 For the multicast discussion, the authors would like to thank Owen 458 DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and 459 participants to discussions in network working groups. 461 The authors would like to thank participants to the Birds-of- 462 a-Feather "Intelligent Transportation Systems" meetings held at IETF 463 in 2016. 465 9. References 467 9.1. Normative References 469 [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission 470 of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, 471 DOI 10.17487/RFC1042, February 1988, 472 . 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, 476 DOI 10.17487/RFC2119, March 1997, 477 . 479 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 480 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 481 . 483 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 484 DOI 10.17487/RFC2818, May 2000, 485 . 487 [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related 488 Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, 489 . 491 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 492 "SEcure Neighbor Discovery (SEND)", RFC 3971, 493 DOI 10.17487/RFC3971, March 2005, 494 . 496 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 497 "Randomness Requirements for Security", BCP 106, RFC 4086, 498 DOI 10.17487/RFC4086, June 2005, 499 . 501 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 502 "Internet X.509 Public Key Infrastructure Certificate 503 Management Protocol (CMP)", RFC 4210, 504 DOI 10.17487/RFC4210, September 2005, 505 . 507 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 508 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 509 December 2005, . 511 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 512 DOI 10.17487/RFC4302, December 2005, 513 . 515 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 516 RFC 4303, DOI 10.17487/RFC4303, December 2005, 517 . 519 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 520 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 521 DOI 10.17487/RFC4861, September 2007, 522 . 524 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 525 Extensions to the Security Architecture for the Internet 526 Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, 527 . 529 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 530 Ed., "Control And Provisioning of Wireless Access Points 531 (CAPWAP) Protocol Specification", RFC 5415, 532 DOI 10.17487/RFC5415, March 2009, 533 . 535 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 536 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 537 September 2010, . 539 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 540 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 541 2011, . 543 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 544 IETF Protocol and Documentation Usage for IEEE 802 545 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 546 October 2013, . 548 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 549 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 550 February 2014, . 552 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 553 Interface Identifiers with IPv6 Stateless Address 554 Autoconfiguration (SLAAC)", RFC 7217, 555 DOI 10.17487/RFC7217, April 2014, 556 . 558 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 559 Considerations for IPv6 Address Generation Mechanisms", 560 RFC 7721, DOI 10.17487/RFC7721, March 2016, 561 . 563 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 564 "Recommendation on Stable IPv6 Interface Identifiers", 565 RFC 8064, DOI 10.17487/RFC8064, February 2017, 566 . 568 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 569 (IPv6) Specification", STD 86, RFC 8200, 570 DOI 10.17487/RFC8200, July 2017, 571 . 573 9.2. Informative References 575 [ETSI-sec-archi] 576 "ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical 577 Specification, Intelligent Transport Systems (ITS); 578 Security; ITS communications security architecture and 579 security management, November 2016. Downloaded on 580 September 9th, 2017, freely available from ETSI website at 581 URL http://www.etsi.org/deliver/ 582 etsi_ts/102900_102999/102940/01.02.01_60/ 583 ts_102940v010201p.pdf". 585 [I-D.hinden-6man-rfc2464bis] 586 Crawford, M. and R. Hinden, "Transmission of IPv6 Packets 587 over Ethernet Networks", draft-hinden-6man-rfc2464bis-02 588 (work in progress), March 2017. 590 [I-D.ietf-ipwave-vehicular-networking-survey] 591 Jeong, J., Cespedes, S., Benamar, N., Haerri, J., and M. 592 Wetterwald, "Survey on IP-based Vehicular Networking for 593 Intelligent Transportation Systems", draft-ietf-ipwave- 594 vehicular-networking-survey-00 (work in progress), July 595 2017. 597 [I-D.ietf-tsvwg-ieee-802-11] 598 Szigeti, T., Henry, J., and F. Baker, "Diffserv to IEEE 599 802.11 Mapping", draft-ietf-tsvwg-ieee-802-11-11 (work in 600 progress), December 2017. 602 [I-D.perkins-intarea-multicast-ieee802] 603 Perkins, C., Stanley, D., Kumari, W., and J. Zuniga, 604 "Multicast Considerations over IEEE 802 Wireless Media", 605 draft-perkins-intarea-multicast-ieee802-03 (work in 606 progress), July 2017. 608 [IEEE-1609.2] 609 "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access 610 in Vehicular Environments (WAVE) -- Security Services for 611 Applications and Management Messages. Example URL 612 http://ieeexplore.ieee.org/document/7426684/ accessed on 613 August 17th, 2017.". 615 [IEEE-1609.3] 616 "IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access 617 in Vehicular Environments (WAVE) -- Networking Services. 618 Example URL http://ieeexplore.ieee.org/document/7458115/ 619 accessed on August 17th, 2017.". 621 [IEEE-1609.4] 622 "IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access 623 in Vehicular Environments (WAVE) -- Multi-Channel 624 Operation. Example URL 625 http://ieeexplore.ieee.org/document/7435228/ accessed on 626 August 17th, 2017.". 628 [IEEE-802.11-2016] 629 "IEEE Standard 802.11-2016 - IEEE Standard for Information 630 Technology - Telecommunications and information exchange 631 between systems Local and metropolitan area networks - 632 Specific requirements - Part 11: Wireless LAN Medium 633 Access Control (MAC) and Physical Layer (PHY) 634 Specifications. Status - Active Standard. Description 635 retrieved freely on September 12th, 2017, at URL 636 https://standards.ieee.org/findstds/ 637 standard/802.11-2016.html". 639 [IEEE-802.11p-2010] 640 "IEEE Std 802.11p (TM)-2010, IEEE Standard for Information 641 Technology - Telecommunications and information exchange 642 between systems - Local and metropolitan area networks - 643 Specific requirements, Part 11: Wireless LAN Medium Access 644 Control (MAC) and Physical Layer (PHY) Specifications, 645 Amendment 6: Wireless Access in Vehicular Environments; 646 document freely available at URL 647 http://standards.ieee.org/getieee802/ 648 download/802.11p-2010.pdf retrieved on September 20th, 649 2013.". 651 Appendix A. ChangeLog 653 The changes are listed in reverse chronological order, most recent 654 changes appearing at the top of the list. 656 From draft-ietf-ipwave-ipv6-over-80211ocb-19 to draft-ietf-ipwave- 657 ipv6-over-80211ocb-20 659 o Reduced the definition of term "802.11-OCB". 661 o Left out of this specification which 802.11 header to use to 662 transmit IP packets in OCB mode (QoS Data header, Data header, or 663 any other). 665 o Added 'MUST' use an Ethernet Adaptation Layer, instead of 'is 666 using' an Ethernet Adaptation Layer. 668 From draft-ietf-ipwave-ipv6-over-80211ocb-18 to draft-ietf-ipwave- 669 ipv6-over-80211ocb-19 671 o Removed the text about fragmentation. 673 o Removed the mentioning of WSMP and GeoNetworking. 675 o Removed the explanation of the binary representation of the 676 EtherType. 678 o Rendered normative the paragraph about unicast and multicast 679 address mapping. 681 o Removed paragraph about addressing model, subnet structure and 682 easiness of using LLs. 684 o Clarified the Type/Subtype field in the 802.11 Header. 686 o Used RECOMMENDED instead of recommended, for the stable interface 687 identifiers. 689 From draft-ietf-ipwave-ipv6-over-80211ocb-17 to draft-ietf-ipwave- 690 ipv6-over-80211ocb-18 692 o Improved the MTU and fragmentation paragraph. 694 From draft-ietf-ipwave-ipv6-over-80211ocb-16 to draft-ietf-ipwave- 695 ipv6-over-80211ocb-17 697 o Susbtituted "MUST be increased" to "is increased" in the MTU 698 section, about fragmentation. 700 From draft-ietf-ipwave-ipv6-over-80211ocb-15 to draft-ietf-ipwave- 701 ipv6-over-80211ocb-16 703 o Removed the definition of the 'WiFi' term and its occurences. 704 Clarified a phrase that used it in Appendix C "Aspects introduced 705 by the OCB mode to 802.11". 707 o Added more normative words: MUST be 0x86DD, MUST fragment if size 708 larger than MTU, Sequence number in 802.11 Data header MUST be 709 increased. 711 From draft-ietf-ipwave-ipv6-over-80211ocb-14 to draft-ietf-ipwave- 712 ipv6-over-80211ocb-15 714 o Added normative term MUST in two places in section "Ethernet 715 Adaptation Layer". 717 From draft-ietf-ipwave-ipv6-over-80211ocb-13 to draft-ietf-ipwave- 718 ipv6-over-80211ocb-14 720 o Created a new Appendix titled "Extra Terminology" that contains 721 terms DSRC, DSRCS, OBU, RSU as defined outside IETF. Some of them 722 are used in the main Terminology section. 724 o Added two paragraphs explaining that ND and Mobile IPv6 have 725 problems working over 802.11 OCB, yet their adaptations is not 726 specified in this document. 728 From draft-ietf-ipwave-ipv6-over-80211ocb-12 to draft-ietf-ipwave- 729 ipv6-over-80211ocb-13 731 o Substituted "IP-OBU" for "OBRU", and "IP-RSU" for "RSRU" 732 throughout and improved OBU-related definitions in the Terminology 733 section. 735 From draft-ietf-ipwave-ipv6-over-80211ocb-11 to draft-ietf-ipwave- 736 ipv6-over-80211ocb-12 738 o Improved the appendix about "MAC Address Generation" by expressing 739 the technique to be an optional suggestion, not a mandatory 740 mechanism. 742 From draft-ietf-ipwave-ipv6-over-80211ocb-10 to draft-ietf-ipwave- 743 ipv6-over-80211ocb-11 745 o Shortened the paragraph on forming/terminating 802.11-OCB links. 747 o Moved the draft tsvwg-ieee-802-11 to Informative References. 749 From draft-ietf-ipwave-ipv6-over-80211ocb-09 to draft-ietf-ipwave- 750 ipv6-over-80211ocb-10 752 o Removed text requesting a new Group ID for multicast for OCB. 754 o Added a clarification of the meaning of value "3333" in the 755 section Address Mapping -- Multicast. 757 o Added note clarifying that in Europe the regional authority is not 758 ETSI, but "ECC/CEPT based on ENs from ETSI". 760 o Added note stating that the manner in which two STAtions set their 761 communication channel is not described in this document. 763 o Added a time qualifier to state that the "each node is represented 764 uniquely at a certain point in time." 766 o Removed text "This section may need to be moved" (the "Reliability 767 Requirements" section). This section stays there at this time. 769 o In the term definition "802.11-OCB" added a note stating that "any 770 implementation should comply with standards and regulations set in 771 the different countries for using that frequency band." 773 o In the RSU term definition, added a sentence explaining the 774 difference between RSU and RSRU: in terms of number of interfaces 775 and IP forwarding. 777 o Replaced "with at least two IP interfaces" with "with at least two 778 real or virtual IP interfaces". 780 o Added a term in the Terminology for "OBU". However the definition 781 is left empty, as this term is defined outside IETF. 783 o Added a clarification that it is an OBU or an OBRU in this phrase 784 "A vehicle embarking an OBU or an OBRU". 786 o Checked the entire document for a consistent use of terms OBU and 787 OBRU. 789 o Added note saying that "'p' is a letter identifying the 790 Ammendment". 792 o Substituted lower case for capitals SHALL or MUST in the 793 Appendices. 795 o Added reference to RFC7042, helpful in the 3333 explanation. 796 Removed reference to individual submission draft-petrescu-its- 797 scenario-reqs and added reference to draft-ietf-ipwave-vehicular- 798 networking-survey. 800 o Added figure captions, figure numbers, and references to figure 801 numbers instead of 'below'. Replaced "section Section" with 802 "section" throughout. 804 o Minor typographical errors. 806 From draft-ietf-ipwave-ipv6-over-80211ocb-08 to draft-ietf-ipwave- 807 ipv6-over-80211ocb-09 809 o Significantly shortened the Address Mapping sections, by text 810 copied from RFC2464, and rather referring to it. 812 o Moved the EPD description to an Appendix on its own. 814 o Shortened the Introduction and the Abstract. 816 o Moved the tutorial section of OCB mode introduced to .11, into an 817 appendix. 819 o Removed the statement that suggests that for routing purposes a 820 prefix exchange mechanism could be needed. 822 o Removed refs to RFC3963, RFC4429 and RFC6775; these are about ND, 823 MIP/NEMO and oDAD; they were referred in the handover discussion 824 section, which is out. 826 o Updated a reference from individual submission to now a WG item in 827 IPWAVE: the survey document. 829 o Added term definition for WiFi. 831 o Updated the authorship and expanded the Contributors section. 833 o Corrected typographical errors. 835 From draft-ietf-ipwave-ipv6-over-80211ocb-07 to draft-ietf-ipwave- 836 ipv6-over-80211ocb-08 838 o Removed the per-channel IPv6 prohibition text. 840 o Corrected typographical errors. 842 From draft-ietf-ipwave-ipv6-over-80211ocb-06 to draft-ietf-ipwave- 843 ipv6-over-80211ocb-07 845 o Added new terms: OBRU and RSRU ('R' for Router). Refined the 846 existing terms RSU and OBU, which are no longer used throughout 847 the document. 849 o Improved definition of term "802.11-OCB". 851 o Clarified that OCB does not "strip" security, but that the 852 operation in OCB mode is "stripped off of all .11 security". 854 o Clarified that theoretical OCB bandwidth speed is 54mbits, but 855 that a commonly observed bandwidth in IP-over-OCB is 12mbit/s. 857 o Corrected typographical errors, and improved some phrasing. 859 From draft-ietf-ipwave-ipv6-over-80211ocb-05 to draft-ietf-ipwave- 860 ipv6-over-80211ocb-06 862 o Updated references of 802.11-OCB document from -2012 to the IEEE 863 802.11-2016. 865 o In the LL address section, and in SLAAC section, added references 866 to 7217 opaque IIDs and 8064 stable IIDs. 868 From draft-ietf-ipwave-ipv6-over-80211ocb-04 to draft-ietf-ipwave- 869 ipv6-over-80211ocb-05 871 o Lengthened the title and cleanded the abstract. 873 o Added text suggesting LLs may be easy to use on OCB, rather than 874 GUAs based on received prefix. 876 o Added the risks of spoofing and hijacking. 878 o Removed the text speculation on adoption of the TSA message. 880 o Clarified that the ND protocol is used. 882 o Clarified what it means "No association needed". 884 o Added some text about how two STAs discover each other. 886 o Added mention of external (OCB) and internal network (stable), in 887 the subnet structure section. 889 o Added phrase explaining that both .11 Data and .11 QoS Data 890 headers are currently being used, and may be used in the future. 892 o Moved the packet capture example into an Appendix Implementation 893 Status. 895 o Suggested moving the reliability requirements appendix out into 896 another document. 898 o Added a IANA Consiserations section, with content, requesting for 899 a new multicast group "all OCB interfaces". 901 o Added new OBU term, improved the RSU term definition, removed the 902 ETTC term, replaced more occurences of 802.11p, 802.11 OCB with 903 802.11-OCB. 905 o References: 907 * Added an informational reference to ETSI's IPv6-over- 908 GeoNetworking. 910 * Added more references to IETF and ETSI security protocols. 912 * Updated some references from I-D to RFC, and from old RFC to 913 new RFC numbers. 915 * Added reference to multicast extensions to IPsec architecture 916 RFC. 918 * Added a reference to 2464-bis. 920 * Removed FCC informative references, because not used. 922 o Updated the affiliation of one author. 924 o Reformulation of some phrases for better readability, and 925 correction of typographical errors. 927 From draft-ietf-ipwave-ipv6-over-80211ocb-03 to draft-ietf-ipwave- 928 ipv6-over-80211ocb-04 930 o Removed a few informative references pointing to Dx draft IEEE 931 1609 documents. 933 o Removed outdated informative references to ETSI documents. 935 o Added citations to IEEE 1609.2, .3 and .4-2016. 937 o Minor textual issues. 939 From draft-ietf-ipwave-ipv6-over-80211ocb-02 to draft-ietf-ipwave- 940 ipv6-over-80211ocb-03 942 o Keep the previous text on multiple addresses, so remove talk about 943 MIP6, NEMOv6 and MCoA. 945 o Clarified that a 'Beacon' is an IEEE 802.11 frame Beacon. 947 o Clarified the figure showing Infrastructure mode and OCB mode side 948 by side. 950 o Added a reference to the IP Security Architecture RFC. 952 o Detailed the IPv6-per-channel prohibition paragraph which reflects 953 the discussion at the last IETF IPWAVE WG meeting. 955 o Added section "Address Mapping -- Unicast". 957 o Added the ".11 Trailer" to pictures of 802.11 frames. 959 o Added text about SNAP carrying the Ethertype. 961 o New RSU definition allowing for it be both a Router and not 962 necessarily a Router some times. 964 o Minor textual issues. 966 From draft-ietf-ipwave-ipv6-over-80211ocb-01 to draft-ietf-ipwave- 967 ipv6-over-80211ocb-02 969 o Replaced almost all occurences of 802.11p with 802.11-OCB, leaving 970 only when explanation of evolution was necessary. 972 o Shortened by removing parameter details from a paragraph in the 973 Introduction. 975 o Moved a reference from Normative to Informative. 977 o Added text in intro clarifying there is no handover spec at IEEE, 978 and that 1609.2 does provide security services. 980 o Named the contents the fields of the EthernetII header (including 981 the Ethertype bitstring). 983 o Improved relationship between two paragraphs describing the 984 increase of the Sequence Number in 802.11 header upon IP 985 fragmentation. 987 o Added brief clarification of "tracking". 989 From draft-ietf-ipwave-ipv6-over-80211ocb-00 to draft-ietf-ipwave- 990 ipv6-over-80211ocb-01 992 o Introduced message exchange diagram illustrating differences 993 between 802.11 and 802.11 in OCB mode. 995 o Introduced an appendix listing for information the set of 802.11 996 messages that may be transmitted in OCB mode. 998 o Removed appendix sections "Privacy Requirements", "Authentication 999 Requirements" and "Security Certificate Generation". 1001 o Removed appendix section "Non IP Communications". 1003 o Introductory phrase in the Security Considerations section. 1005 o Improved the definition of "OCB". 1007 o Introduced theoretical stacked layers about IPv6 and IEEE layers 1008 including EPD. 1010 o Removed the appendix describing the details of prohibiting IPv6 on 1011 certain channels relevant to 802.11-OCB. 1013 o Added a brief reference in the privacy text about a precise clause 1014 in IEEE 1609.3 and .4. 1016 o Clarified the definition of a Road Side Unit. 1018 o Removed the discussion about security of WSA (because is non-IP). 1020 o Removed mentioning of the GeoNetworking discussion. 1022 o Moved references to scientific articles to a separate 'overview' 1023 draft, and referred to it. 1025 Appendix B. 802.11p 1027 The term "802.11p" is an earlier definition. The behaviour of 1028 "802.11p" networks is rolled in the document IEEE Std 802.11-2016. 1029 In that document the term 802.11p disappears. Instead, each 802.11p 1030 feature is conditioned by the Management Information Base (MIB) 1031 attribute "OCBActivated". Whenever OCBActivated is set to true the 1032 IEEE Std 802.11 OCB state is activated. For example, an 802.11 1033 STAtion operating outside the context of a basic service set has the 1034 OCBActivated flag set. Such a station, when it has the flag set, 1035 uses a BSS identifier equal to ff:ff:ff:ff:ff:ff. 1037 Appendix C. Aspects introduced by the OCB mode to 802.11 1039 In the IEEE 802.11-OCB mode, all nodes in the wireless range can 1040 directly communicate with each other without involving authentication 1041 or association procedures. At link layer, it is necessary to set the 1042 same channel number (or frequency) on two stations that need to 1043 communicate with each other. The manner in which stations set their 1044 channel number is not specified in this document. Stations STA1 and 1045 STA2 can exchange IP packets if they are set on the same channel. At 1046 IP layer, they then discover each other by using the IPv6 Neighbor 1047 Discovery protocol. 1049 Briefly, the IEEE 802.11-OCB mode has the following properties: 1051 o The use by each node of a 'wildcard' BSSID (i.e., each bit of the 1052 BSSID is set to 1) 1054 o No IEEE 802.11 Beacon frames are transmitted 1056 o No authentication is required in order to be able to communicate 1058 o No association is needed in order to be able to communicate 1060 o No encryption is provided in order to be able to communicate 1062 o Flag dot11OCBActivated is set to true 1064 All the nodes in the radio communication range (IP-OBU and IP-RSU) 1065 receive all the messages transmitted (IP-OBU and IP-RSU) within the 1066 radio communications range. The eventual conflict(s) are resolved by 1067 the MAC CDMA function. 1069 The message exchange diagram in Figure 3 illustrates a comparison 1070 between traditional 802.11 and 802.11 in OCB mode. The 'Data' 1071 messages can be IP packets such as HTTP or others. Other 802.11 1072 management and control frames (non IP) may be transmitted, as 1073 specified in the 802.11 standard. For information, the names of 1074 these messages as currently specified by the 802.11 standard are 1075 listed in Appendix G. 1077 STA AP STA1 STA2 1078 | | | | 1079 |<------ Beacon -------| |<------ Data -------->| 1080 | | | | 1081 |---- Probe Req. ----->| |<------ Data -------->| 1082 |<--- Probe Res. ------| | | 1083 | | |<------ Data -------->| 1084 |---- Auth Req. ------>| | | 1085 |<--- Auth Res. -------| |<------ Data -------->| 1086 | | | | 1087 |---- Asso Req. ------>| |<------ Data -------->| 1088 |<--- Asso Res. -------| | | 1089 | | |<------ Data -------->| 1090 |<------ Data -------->| | | 1091 |<------ Data -------->| |<------ Data -------->| 1093 (i) 802.11 Infrastructure mode (ii) 802.11-OCB mode 1095 Figure 3: Difference between messages exchanged on 802.11 (left) and 1096 802.11-OCB (right) 1098 The interface 802.11-OCB was specified in IEEE Std 802.11p (TM) -2010 1099 [IEEE-802.11p-2010] as an amendment to IEEE Std 802.11 (TM) -2007, 1100 titled "Amendment 6: Wireless Access in Vehicular Environments". 1101 Since then, this amendment has been integrated in IEEE 802.11(TM) 1102 -2012 and -2016 [IEEE-802.11-2016]. 1104 In document 802.11-2016, anything qualified specifically as 1105 "OCBActivated", or "outside the context of a basic service" set to be 1106 true, then it is actually referring to OCB aspects introduced to 1107 802.11. 1109 In order to delineate the aspects introduced by 802.11-OCB to 802.11, 1110 we refer to the earlier [IEEE-802.11p-2010]. The amendment is 1111 concerned with vehicular communications, where the wireless link is 1112 similar to that of Wireless LAN (using a PHY layer specified by 1113 802.11a/b/g/n), but which needs to cope with the high mobility factor 1114 inherent in scenarios of communications between moving vehicles, and 1115 between vehicles and fixed infrastructure deployed along roads. 1116 While 'p' is a letter identifying the Ammendment, just like 'a, b, g' 1117 and 'n' are, 'p' is concerned more with MAC modifications, and a 1118 little with PHY modifications; the others are mainly about PHY 1119 modifications. It is possible in practice to combine a 'p' MAC with 1120 an 'a' PHY by operating outside the context of a BSS with OFDM at 1121 5.4GHz and 5.9GHz. 1123 The 802.11-OCB links are specified to be compatible as much as 1124 possible with the behaviour of 802.11a/b/g/n and future generation 1125 IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer 1126 offers practically the same interface to IP as the 802.11a/b/g/n and 1127 802.3. A packet sent by an IP-OBU may be received by one or multiple 1128 IP-RSUs. The link-layer resolution is performed by using the IPv6 1129 Neighbor Discovery protocol. 1131 To support this similarity statement (IPv6 is layered on top of LLC 1132 on top of 802.11-OCB, in the same way that IPv6 is layered on top of 1133 LLC on top of 802.11a/b/g/n (for WLAN) or layered on top of LLC on 1134 top of 802.3 (for Ethernet)) it is useful to analyze the differences 1135 between 802.11-OCB and 802.11 specifications. During this analysis, 1136 we note that whereas 802.11-OCB lists relatively complex and numerous 1137 changes to the MAC layer (and very little to the PHY layer), there 1138 are only a few characteristics which may be important for an 1139 implementation transmitting IPv6 packets on 802.11-OCB links. 1141 The most important 802.11-OCB point which influences the IPv6 1142 functioning is the OCB characteristic; an additional, less direct 1143 influence, is the maximum bandwidth afforded by the PHY modulation/ 1144 demodulation methods and channel access specified by 802.11-OCB. The 1145 maximum bandwidth theoretically possible in 802.11-OCB is 54 Mbit/s 1146 (when using, for example, the following parameters: 20 MHz channel; 1147 modulation 64-QAM; coding rate R is 3/4); in practice of IP-over- 1148 802.11-OCB a commonly observed figure is 12Mbit/s; this bandwidth 1149 allows the operation of a wide range of protocols relying on IPv6. 1151 o Operation Outside the Context of a BSS (OCB): the (earlier 1152 802.11p) 802.11-OCB links are operated without a Basic Service Set 1153 (BSS). This means that the frames IEEE 802.11 Beacon, Association 1154 Request/Response, Authentication Request/Response, and similar, 1155 are not used. The used identifier of BSS (BSSID) has a 1156 hexadecimal value always 0xffffffffffff (48 '1' bits, represented 1157 as MAC address ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' 1158 BSSID), as opposed to an arbitrary BSSID value set by 1159 administrator (e.g. 'My-Home-AccessPoint'). The OCB operation - 1160 namely the lack of beacon-based scanning and lack of 1161 authentication - should be taken into account when the Mobile IPv6 1162 protocol [RFC6275] and the protocols for IP layer security 1164 [RFC4301] are used. The way these protocols adapt to OCB is not 1165 described in this document. 1167 o Timing Advertisement: is a new message defined in 802.11-OCB, 1168 which does not exist in 802.11a/b/g/n. This message is used by 1169 stations to inform other stations about the value of time. It is 1170 similar to the time as delivered by a GNSS system (Galileo, GPS, 1171 ...) or by a cellular system. This message is optional for 1172 implementation. 1174 o Frequency range: this is a characteristic of the PHY layer, with 1175 almost no impact on the interface between MAC and IP. However, it 1176 is worth considering that the frequency range is regulated by a 1177 regional authority (ARCEP, ECC/CEPT based on ENs from ETSI, FCC, 1178 etc.); as part of the regulation process, specific applications 1179 are associated with specific frequency ranges. In the case of 1180 802.11-OCB, the regulator associates a set of frequency ranges, or 1181 slots within a band, to the use of applications of vehicular 1182 communications, in a band known as "5.9GHz". The 5.9GHz band is 1183 different from the 2.4GHz and 5GHz bands used by Wireless LAN. 1184 However, as with Wireless LAN, the operation of 802.11-OCB in 1185 "5.9GHz" bands is exempt from owning a license in EU (in US the 1186 5.9GHz is a licensed band of spectrum; for the fixed 1187 infrastructure an explicit FCC authorization is required; for an 1188 on-board device a 'licensed-by-rule' concept applies: rule 1189 certification conformity is required.) Technical conditions are 1190 different than those of the bands "2.4GHz" or "5GHz". The allowed 1191 power levels, and implicitly the maximum allowed distance between 1192 vehicles, is of 33dBm for 802.11-OCB (in Europe), compared to 20 1193 dBm for Wireless LAN 802.11a/b/g/n; this leads to a maximum 1194 distance of approximately 1km, compared to approximately 50m. 1195 Additionally, specific conditions related to congestion avoidance, 1196 jamming avoidance, and radar detection are imposed on the use of 1197 DSRC (in US) and on the use of frequencies for Intelligent 1198 Transportation Systems (in EU), compared to Wireless LAN 1199 (802.11a/b/g/n). 1201 o 'Half-rate' encoding: as the frequency range, this parameter is 1202 related to PHY, and thus has not much impact on the interface 1203 between the IP layer and the MAC layer. 1205 o In vehicular communications using 802.11-OCB links, there are 1206 strong privacy requirements with respect to addressing. While the 1207 802.11-OCB standard does not specify anything in particular with 1208 respect to MAC addresses, in these settings there exists a strong 1209 need for dynamic change of these addresses (as opposed to the non- 1210 vehicular settings - real wall protection - where fixed MAC 1211 addresses do not currently pose some privacy risks). This is 1212 further described in Section 5. A relevant function is described 1213 in IEEE 1609.3-2016 [IEEE-1609.3], clause 5.5.1 and IEEE 1214 1609.4-2016 [IEEE-1609.4], clause 6.7. 1216 Other aspects particular to 802.11-OCB, which are also particular to 1217 802.11 (e.g. the 'hidden node' operation), may have an influence on 1218 the use of transmission of IPv6 packets on 802.11-OCB networks. The 1219 OCB subnet structure is described in Section 4.6. 1221 Appendix D. Changes Needed on a software driver 802.11a to become a 1222 802.11-OCB driver 1224 The 802.11p amendment modifies both the 802.11 stack's physical and 1225 MAC layers but all the induced modifications can be quite easily 1226 obtained by modifying an existing 802.11a ad-hoc stack. 1228 Conditions for a 802.11a hardware to be 802.11-OCB compliant: 1230 o The PHY entity shall be an orthogonal frequency division 1231 multiplexing (OFDM) system. It must support the frequency bands 1232 on which the regulator recommends the use of ITS communications, 1233 for example using IEEE 802.11-OCB layer, in France: 5875MHz to 1234 5925MHz. 1236 o The OFDM system must provide a "half-clocked" operation using 10 1237 MHz channel spacings. 1239 o The chip transmit spectrum mask must be compliant to the "Transmit 1240 spectrum mask" from the IEEE 802.11p amendment (but experimental 1241 environments tolerate otherwise). 1243 o The chip should be able to transmit up to 44.8 dBm when used by 1244 the US government in the United States, and up to 33 dBm in 1245 Europe; other regional conditions apply. 1247 Changes needed on the network stack in OCB mode: 1249 o Physical layer: 1251 * The chip must use the Orthogonal Frequency Multiple Access 1252 (OFDM) encoding mode. 1254 * The chip must be set in half-mode rate mode (the internal clock 1255 frequency is divided by two). 1257 * The chip must use dedicated channels and should allow the use 1258 of higher emission powers. This may require modifications to 1259 the local computer file that describes regulatory domains 1260 rules, if used by the kernel to enforce local specific 1261 restrictions. Such modifications to the local computer file 1262 must respect the location-specific regulatory rules. 1264 MAC layer: 1266 * All management frames (beacons, join, leave, and others) 1267 emission and reception must be disabled except for frames of 1268 subtype Action and Timing Advertisement (defined below). 1270 * No encryption key or method must be used. 1272 * Packet emission and reception must be performed as in ad-hoc 1273 mode, using the wildcard BSSID (ff:ff:ff:ff:ff:ff). 1275 * The functions related to joining a BSS (Association Request/ 1276 Response) and for authentication (Authentication Request/Reply, 1277 Challenge) are not called. 1279 * The beacon interval is always set to 0 (zero). 1281 * Timing Advertisement frames, defined in the amendment, should 1282 be supported. The upper layer should be able to trigger such 1283 frames emission and to retrieve information contained in 1284 received Timing Advertisements. 1286 Appendix E. EtherType Protocol Discrimination (EPD) 1288 A more theoretical and detailed view of layer stacking, and 1289 interfaces between the IP layer and 802.11-OCB layers, is illustrated 1290 in Figure 4. The IP layer operates on top of the EtherType Protocol 1291 Discrimination (EPD); this Discrimination layer is described in IEEE 1292 Std 802.3-2012; the interface between IPv6 and EPD is the LLC_SAP 1293 (Link Layer Control Service Access Point). 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | IPv6 | 1297 +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ 1298 { LLC_SAP } 802.11-OCB 1299 +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary 1300 | EPD | | | 1301 | | MLME | | 1302 +-+-+-{ MAC_SAP }+-+-+-| MLME_SAP | 1303 | MAC Sublayer | | | 802.11-OCB 1304 | and ch. coord. | | SME | Services 1305 +-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| | 1306 | | PLME | | 1307 | PHY Layer | PLME_SAP | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 Figure 4: EtherType Protocol Discrimination 1312 Appendix F. Design Considerations 1314 The networks defined by 802.11-OCB are in many ways similar to other 1315 networks of the 802.11 family. In theory, the encapsulation of IPv6 1316 over 802.11-OCB could be very similar to the operation of IPv6 over 1317 other networks of the 802.11 family. However, the high mobility, 1318 strong link asymmetry and very short connection makes the 802.11-OCB 1319 link significantly different from other 802.11 networks. Also, the 1320 automotive applications have specific requirements for reliability, 1321 security and privacy, which further add to the particularity of the 1322 802.11-OCB link. 1324 F.1. Vehicle ID 1326 In automotive networks it is required that each node is represented 1327 uniquely at a certain point in time. Accordingly, a vehicle must be 1328 identified by at least one unique identifier. The current 1329 specification at ETSI and at IEEE 1609 identifies a vehicle by its 1330 MAC address, which is obtained from the 802.11-OCB Network Interface 1331 Card (NIC). 1333 In case multiple 802.11-OCB NICs are present in one car, implicitely 1334 multiple vehicle IDs will be generated. Additionally, some software 1335 generates a random MAC address each time the computer boots; this 1336 constitutes an additional difficulty. 1338 A mechanim to uniquely identify a vehicle irrespectively to the 1339 multiplicity of NICs, or frequent MAC address generation, is 1340 necessary. 1342 F.2. Reliability Requirements 1344 The dynamically changing topology, short connectivity, mobile 1345 transmitter and receivers, different antenna heights, and many-to- 1346 many communication types, make IEEE 802.11-OCB links significantly 1347 different from other IEEE 802.11 links. Any IPv6 mechanism operating 1348 on IEEE 802.11-OCB link must support strong link asymmetry, spatio- 1349 temporal link quality, fast address resolution and transmission. 1351 IEEE 802.11-OCB strongly differs from other 802.11 systems to operate 1352 outside of the context of a Basic Service Set. This means in 1353 practice that IEEE 802.11-OCB does not rely on a Base Station for all 1354 Basic Service Set management. In particular, IEEE 802.11-OCB shall 1355 not use beacons. Any IPv6 mechanism requiring L2 services from IEEE 1356 802.11 beacons must support an alternative service. 1358 Channel scanning being disabled, IPv6 over IEEE 802.11-OCB must 1359 implement a mechanism for transmitter and receiver to converge to a 1360 common channel. 1362 Authentication not being possible, IPv6 over IEEE 802.11-OCB must 1363 implement an distributed mechanism to authenticate transmitters and 1364 receivers without the support of a DHCP server. 1366 Time synchronization not being available, IPv6 over IEEE 802.11-OCB 1367 must implement a higher layer mechanism for time synchronization 1368 between transmitters and receivers without the support of a NTP 1369 server. 1371 The IEEE 802.11-OCB link being asymmetric, IPv6 over IEEE 802.11-OCB 1372 must disable management mechanisms requesting acknowledgements or 1373 replies. 1375 The IEEE 802.11-OCB link having a short duration time, IPv6 over IEEE 1376 802.11-OCB should implement fast IPv6 mobility management mechanisms. 1378 F.3. Multiple interfaces 1380 There are considerations for 2 or more IEEE 802.11-OCB interface 1381 cards per vehicle. For each vehicle taking part in road traffic, one 1382 IEEE 802.11-OCB interface card could be fully allocated for Non IP 1383 safety-critical communication. Any other IEEE 802.11-OCB may be used 1384 for other type of traffic. 1386 The mode of operation of these other wireless interfaces is not 1387 clearly defined yet. One possibility is to consider each card as an 1388 independent network interface, with a specific MAC Address and a set 1389 of IPv6 addresses. Another possibility is to consider the set of 1390 these wireless interfaces as a single network interface (not 1391 including the IEEE 802.11-OCB interface used by Non IP safety 1392 critical communications). This will require specific logic to 1393 ensure, for example, that packets meant for a vehicle in front are 1394 actually sent by the radio in the front, or that multiple copies of 1395 the same packet received by multiple interfaces are treated as a 1396 single packet. Treating each wireless interface as a separate 1397 network interface pushes such issues to the application layer. 1399 Certain privacy requirements imply that if these multiple interfaces 1400 are represented by many network interface, a single renumbering event 1401 shall cause renumbering of all these interfaces. If one MAC changed 1402 and another stayed constant, external observers would be able to 1403 correlate old and new values, and the privacy benefits of 1404 randomization would be lost. 1406 The privacy requirements of Non IP safety-critical communications 1407 imply that if a change of pseudonyme occurs, renumbering of all other 1408 interfaces shall also occur. 1410 F.4. MAC Address Generation 1412 In 802.11-OCB networks, the MAC addresses may change during well 1413 defined renumbering events. A 'randomized' MAC address has the 1414 following characteristics: 1416 o Bit "Local/Global" set to "locally admninistered". 1418 o Bit "Unicast/Multicast" set to "Unicast". 1420 o The 46 remaining bits are set to a random value, using a random 1421 number generator that meets the requirements of [RFC4086]. 1423 To meet the randomization requirements for the 46 remaining bits, a 1424 hash function may be used. For example, the SHA256 hash function may 1425 be used with input a 256 bit local secret, the "nominal" MAC Address 1426 of the interface, and a representation of the date and time of the 1427 renumbering event. 1429 Appendix G. IEEE 802.11 Messages Transmitted in OCB mode 1431 For information, at the time of writing, this is the list of IEEE 1432 802.11 messages that may be transmitted in OCB mode, i.e. when 1433 dot11OCBActivated is true in a STA: 1435 o The STA may send management frames of subtype Action and, if the 1436 STA maintains a TSF Timer, subtype Timing Advertisement; 1438 o The STA may send control frames, except those of subtype PS-Poll, 1439 CF-End, and CF-End plus CFAck; 1441 o The STA may send data frames of subtype Data, Null, QoS Data, and 1442 QoS Null. 1444 Appendix H. Implementation Status 1446 This section describes an example of an IPv6 Packet captured over a 1447 IEEE 802.11-OCB link. 1449 By way of example we show that there is no modification in the 1450 headers when transmitted over 802.11-OCB networks - they are 1451 transmitted like any other 802.11 and Ethernet packets. 1453 We describe an experiment of capturing an IPv6 packet on an 1454 802.11-OCB link. In topology depicted in Figure 5, the packet is an 1455 IPv6 Router Advertisement. This packet is emitted by a Router on its 1456 802.11-OCB interface. The packet is captured on the Host, using a 1457 network protocol analyzer (e.g. Wireshark); the capture is performed 1458 in two different modes: direct mode and 'monitor' mode. The topology 1459 used during the capture is depicted below. 1461 The packet is captured on the Host. The Host is an IP-OBU containing 1462 an 802.11 interface in format PCI express (an ITRI product). The 1463 kernel runs the ath5k software driver with modifications for OCB 1464 mode. The capture tool is Wireshark. The file format for save and 1465 analyze is 'pcap'. The packet is generated by the Router. The 1466 Router is an IP-RSU (ITRI product). 1468 +--------+ +-------+ 1469 | | 802.11-OCB Link | | 1470 ---| Router |--------------------------------| Host | 1471 | | | | 1472 +--------+ +-------+ 1474 Figure 5: Topology for capturing IP packets on 802.11-OCB 1476 During several capture operations running from a few moments to 1477 several hours, no message relevant to the BSSID contexts were 1478 captured (no Association Request/Response, Authentication Req/Resp, 1479 Beacon). This shows that the operation of 802.11-OCB is outside the 1480 context of a BSSID. 1482 Overall, the captured message is identical with a capture of an IPv6 1483 packet emitted on a 802.11b interface. The contents are precisely 1484 similar. 1486 H.1. Capture in Monitor Mode 1488 The IPv6 RA packet captured in monitor mode is illustrated below. 1489 The radio tap header provides more flexibility for reporting the 1490 characteristics of frames. The Radiotap Header is prepended by this 1491 particular stack and operating system on the Host machine to the RA 1492 packet received from the network (the Radiotap Header is not present 1493 on the air). The implementation-dependent Radiotap Header is useful 1494 for piggybacking PHY information from the chip's registers as data in 1495 a packet understandable by userland applications using Socket 1496 interfaces (the PHY interface can be, for example: power levels, data 1497 rate, ratio of signal to noise). 1499 The packet present on the air is formed by IEEE 802.11 Data Header, 1500 Logical Link Control Header, IPv6 Base Header and ICMPv6 Header. 1502 Radiotap Header v0 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 |Header Revision| Header Pad | Header length | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Present flags | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | Data Rate | Pad | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 IEEE 802.11 Data Header 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Type/Subtype and Frame Ctrl | Duration | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Receiver Address... 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 ... Receiver Address | Transmitter Address... 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 ... Transmitter Address | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | BSS Id... 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 ... BSS Id | Frag Number and Seq Number | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 Logical-Link Control Header 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | DSAP |I| SSAP |C| Control field | Org. code... 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 ... Organizational Code | Type | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 IPv6 Base Header 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 |Version| Traffic Class | Flow Label | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Payload Length | Next Header | Hop Limit | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | | 1540 + + 1541 | | 1542 + Source Address + 1543 | | 1544 + + 1545 | | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | | 1548 + + 1549 | | 1550 + Destination Address + 1551 | | 1552 + + 1553 | | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 Router Advertisement 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | Type | Code | Checksum | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Reachable Time | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | Retrans Timer | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | Options ... 1567 +-+-+-+-+-+-+-+-+-+-+-+- 1569 The value of the Data Rate field in the Radiotap header is set to 6 1570 Mb/s. This indicates the rate at which this RA was received. 1572 The value of the Transmitter address in the IEEE 802.11 Data Header 1573 is set to a 48bit value. The value of the destination address is 1574 33:33:00:00:00:1 (all-nodes multicast address). The value of the BSS 1575 Id field is ff:ff:ff:ff:ff:ff, which is recognized by the network 1576 protocol analyzer as being "broadcast". The Fragment number and 1577 sequence number fields are together set to 0x90C6. 1579 The value of the Organization Code field in the Logical-Link Control 1580 Header is set to 0x0, recognized as "Encapsulated Ethernet". The 1581 value of the Type field is 0x86DD (hexadecimal 86DD, or otherwise 1582 #86DD), recognized as "IPv6". 1584 A Router Advertisement is periodically sent by the router to 1585 multicast group address ff02::1. It is an icmp packet type 134. The 1586 IPv6 Neighbor Discovery's Router Advertisement message contains an 1587 8-bit field reserved for single-bit flags, as described in [RFC4861]. 1589 The IPv6 header contains the link local address of the router 1590 (source) configured via EUI-64 algorithm, and destination address set 1591 to ff02::1. Recent versions of network protocol analyzers (e.g. 1592 Wireshark) provide additional informations for an IP address, if a 1593 geolocalization database is present. In this example, the 1594 geolocalization database is absent, and the "GeoIP" information is 1595 set to unknown for both source and destination addresses (although 1596 the IPv6 source and destination addresses are set to useful values). 1597 This "GeoIP" can be a useful information to look up the city, 1598 country, AS number, and other information for an IP address. 1600 The Ethernet Type field in the logical-link control header is set to 1601 0x86dd which indicates that the frame transports an IPv6 packet. In 1602 the IEEE 802.11 data, the destination address is 33:33:00:00:00:01 1603 which is the corresponding multicast MAC address. The BSS id is a 1604 broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link 1605 duration between vehicles and the roadside infrastructure, there is 1606 no need in IEEE 802.11-OCB to wait for the completion of association 1607 and authentication procedures before exchanging data. IEEE 1608 802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s) 1609 and may start communicating as soon as they arrive on the 1610 communication channel. 1612 H.2. Capture in Normal Mode 1614 The same IPv6 Router Advertisement packet described above (monitor 1615 mode) is captured on the Host, in the Normal mode, and depicted 1616 below. 1618 Ethernet II Header 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | Destination... 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 ...Destination | Source... 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 ...Source | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | Type | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 IPv6 Base Header 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 |Version| Traffic Class | Flow Label | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Payload Length | Next Header | Hop Limit | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | | 1636 + + 1637 | | 1638 + Source Address + 1639 | | 1640 + + 1641 | | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | | 1644 + + 1645 | | 1646 + Destination Address + 1647 | | 1648 + + 1649 | | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 Router Advertisement 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Type | Code | Checksum | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | Reachable Time | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | Retrans Timer | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | Options ... 1663 +-+-+-+-+-+-+-+-+-+-+-+- 1665 One notices that the Radiotap Header, the IEEE 802.11 Data Header and 1666 the Logical-Link Control Headers are not present. On the other hand, 1667 a new header named Ethernet II Header is present. 1669 The Destination and Source addresses in the Ethernet II header 1670 contain the same values as the fields Receiver Address and 1671 Transmitter Address present in the IEEE 802.11 Data Header in the 1672 "monitor" mode capture. 1674 The value of the Type field in the Ethernet II header is 0x86DD 1675 (recognized as "IPv6"); this value is the same value as the value of 1676 the field Type in the Logical-Link Control Header in the "monitor" 1677 mode capture. 1679 The knowledgeable experimenter will no doubt notice the similarity of 1680 this Ethernet II Header with a capture in normal mode on a pure 1681 Ethernet cable interface. 1683 An Adaptation layer is inserted on top of a pure IEEE 802.11 MAC 1684 layer, in order to adapt packets, before delivering the payload data 1685 to the applications. It adapts 802.11 LLC/MAC headers to Ethernet II 1686 headers. In further detail, this adaptation consists in the 1687 elimination of the Radiotap, 802.11 and LLC headers, and in the 1688 insertion of the Ethernet II header. In this way, IPv6 runs straight 1689 over LLC over the 802.11-OCB MAC layer; this is further confirmed by 1690 the use of the unique Type 0x86DD. 1692 Appendix I. Extra Terminology 1694 The following terms are defined outside the IETF. They are used to 1695 define the main terms in the main terminology section Section 2. 1697 DSRC (Dedicated Short Range Communication): a term defined outside 1698 the IETF. The US Federal Communications Commission (FCC) Dedicated 1699 Short Range Communication (DSRC) is defined in the Code of Federal 1700 Regulations (CFR) 47, Parts 90 and 95. This Code is referred in the 1701 definitions below. At the time of the writing of this Internet 1702 Draft, the last update of this Code was dated October 1st, 2010. 1704 DSRCS (Dedicated Short-Range Communications Services): a term defined 1705 outside the IETF. The use of radio techniques to transfer data over 1706 short distances between roadside and mobile units, between mobile 1707 units, and between portable and mobile units to perform operations 1708 related to the improvement of traffic flow, traffic safety, and other 1709 intelligent transportation service applications in a variety of 1710 environments. DSRCS systems may also transmit status and 1711 instructional messages related to the units involve. [Ref. 47 CFR 1712 90.7 - Definitions] 1713 OBU (On-Board Unit): a term defined outside the IETF. An On-Board 1714 Unit is a DSRCS transceiver that is normally mounted in or on a 1715 vehicle, or which in some instances may be a portable unit. An OBU 1716 can be operational while a vehicle or person is either mobile or 1717 stationary. The OBUs receive and contend for time to transmit on one 1718 or more radio frequency (RF) channels. Except where specifically 1719 excluded, OBU operation is permitted wherever vehicle operation or 1720 human passage is permitted. The OBUs mounted in vehicles are 1721 licensed by rule under part 95 of the respective chapter and 1722 communicate with Roadside Units (RSUs) and other OBUs. Portable OBUs 1723 are also licensed by rule under part 95 of the respective chapter. 1724 OBU operations in the Unlicensed National Information Infrastructure 1725 (UNII) Bands follow the rules in those bands. - [CFR 90.7 - 1726 Definitions]. 1728 RSU (Road-Side Unit): a term defined outside of IETF. A Roadside 1729 Unit is a DSRC transceiver that is mounted along a road or pedestrian 1730 passageway. An RSU may also be mounted on a vehicle or is hand 1731 carried, but it may only operate when the vehicle or hand- carried 1732 unit is stationary. Furthermore, an RSU operating under the 1733 respectgive part is restricted to the location where it is licensed 1734 to operate. However, portable or hand-held RSUs are permitted to 1735 operate where they do not interfere with a site-licensed operation. 1736 A RSU broadcasts data to OBUs or exchanges data with OBUs in its 1737 communications zone. An RSU also provides channel assignments and 1738 operating instructions to OBUs in its communications zone, when 1739 required. - [CFR 90.7 - Definitions]. 1741 Authors' Addresses 1743 Alexandre Petrescu 1744 CEA, LIST 1745 CEA Saclay 1746 Gif-sur-Yvette , Ile-de-France 91190 1747 France 1749 Phone: +33169089223 1750 Email: Alexandre.Petrescu@cea.fr 1752 Nabil Benamar 1753 Moulay Ismail University 1754 Morocco 1756 Phone: +212670832236 1757 Email: n.benamar@est.umi.ac.ma 1758 Jerome Haerri 1759 Eurecom 1760 Sophia-Antipolis 06904 1761 France 1763 Phone: +33493008134 1764 Email: Jerome.Haerri@eurecom.fr 1766 Jong-Hyouk Lee 1767 Sangmyung University 1768 31, Sangmyeongdae-gil, Dongnam-gu 1769 Cheonan 31066 1770 Republic of Korea 1772 Email: jonghyouk@smu.ac.kr 1774 Thierry Ernst 1775 YoGoKo 1776 France 1778 Email: thierry.ernst@yogoko.fr