idnits 2.17.1 draft-ietf-ipwave-ipv6-over-80211ocb-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 17, 2017) is 2415 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) -- Looks like a reference, but probably isn't: '1' on line 660 -- Looks like a reference, but probably isn't: '16' on line 670 -- Looks like a reference, but probably isn't: '13' on line 668 -- Looks like a reference, but probably isn't: '14' on line 668 -- Looks like a reference, but probably isn't: '15' on line 670 == Unused Reference: 'RFC3963' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: 'RFC4429' is defined on line 1084, but no explicit reference was found in the text == Unused Reference: 'RFC6775' is defined on line 1101, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-ieee-802-11-06 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 5889 ** Downref: Normative reference to an Informational RFC: RFC 7721 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: February 18, 2018 Moulay Ismail University 6 J. Haerri 7 Eurecom 8 C. Huitema 10 J. Lee 11 Sangmyung University 12 T. Ernst 13 YoGoKo 14 T. Li 15 Peloton Technology 16 August 17, 2017 18 Transmission of IPv6 Packets over IEEE 802.11 Networks in mode Outside 19 the Context of a Basic Service Set (IPv6-over-80211ocb) 20 draft-ietf-ipwave-ipv6-over-80211ocb-04.txt 22 Abstract 24 In order to transmit IPv6 packets on IEEE 802.11 networks run outside 25 the context of a basic service set (OCB, earlier "802.11p") there is 26 a need to define a few parameters such as the recommended Maximum 27 Transmission Unit size, the header format preceding the IPv6 header, 28 the Type value within it, and others. This document describes these 29 parameters for IPv6 and IEEE 802.11 OCB networks; it portrays the 30 layering of IPv6 on 802.11 OCB similarly to other known 802.11 and 31 Ethernet layers - by using an Ethernet Adaptation Layer. 33 In addition, the document attempts to list what is different in 34 802.11 OCB (802.11p) compared to more 'traditional' 802.11a/b/g/n 35 layers, layers over which IPv6 protocols operates without issues. 36 Most notably, the operation outside the context of a BSS (OCB) has 37 impact on IPv6 handover behaviour and on IPv6 security. 39 An example of an IPv6 packet captured while transmitted over an IEEE 40 802.11 OCB link (802.11p) is given. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on February 18, 2018. 59 Copyright Notice 61 Copyright (c) 2017 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Communication Scenarios where IEEE 802.11 OCB Links are Used 6 79 4. Aspects introduced by the OCB mode to 802.11 . . . . . . . . 6 80 5. Layering of IPv6 over 802.11-OCB as over Ethernet . . . . . . 10 81 5.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 10 82 5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 11 83 5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 12 84 5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 13 85 5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 14 86 5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 14 87 5.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 14 88 5.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 15 89 5.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 16 90 6. Example IPv6 Packet captured over a IEEE 802.11-OCB link . . 16 91 6.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 17 92 6.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 19 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 95 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 99 11.2. Informative References . . . . . . . . . . . . . . . . . 24 100 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 26 101 Appendix B. Changes Needed on a software driver 802.11a to 102 become a 802.11-OCB driver . . . 28 103 Appendix C. Design Considerations . . . . . . . . . . . . . . . 30 104 C.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 30 105 C.2. Reliability Requirements . . . . . . . . . . . . . . . . 30 106 C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 31 107 C.4. MAC Address Generation . . . . . . . . . . . . . . . . . 32 108 Appendix D. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 111 1. Introduction 113 This document describes the transmission of IPv6 packets on IEEE Std 114 802.11 OCB networks (earlier known as 802.11p). This involves the 115 layering of IPv6 networking on top of the IEEE 802.11 MAC layer (with 116 an LLC layer). Compared to running IPv6 over the Ethernet MAC layer, 117 there is no modification required to the standards: IPv6 works fine 118 directly over 802.11 OCB too (with an LLC layer). 120 The term "802.11p" is an earlier definition. As of year 2012, the 121 behaviour of "802.11p" networks has been rolled in the document IEEE 122 Std 802.11-2012. In this document the term 802.11p disappears. 123 Instead, each 802.11p feature is conditioned by a flag in the 124 Management Information Base. That flag is named "OCBActivated". 125 Whenever OCBActivated is set to true the feature it relates to 126 represents an earlier 802.11p feature. For example, an 802.11 127 STAtion operating outside the context of a basic service set has the 128 OCBActivated flag set. Such a station, when it has the flag set, it 129 uses a BSS identifier equal to ff:ff:ff:ff:ff:ff. 131 In the following text we use the term "802.11p" to mean 802.11-2012 132 OCB. 134 The IPv6 network layer operates on 802.11 OCB in the same manner as 135 it operates on 802.11 WiFi, with a few particular exceptions. The 136 IPv6 network layer operates on WiFi by involving an Ethernet 137 Adaptation Layer; this Ethernet Adaptation Layer maps 802.11 headers 138 to Ethernet II headers. The operation of IP on Ethernet is described 139 in [RFC1042] and [RFC2464]. The situation of IPv6 networking layer 140 on Ethernet Adaptation Layer is illustrated below: 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | IPv6 | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Ethernet Adaptation Layer | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | 802.11 WiFi MAC | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | 802.11 WiFi PHY | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 (in the above figure, a WiFi profile is represented; this is used 153 also for OCB profile.) 155 A more theoretical and detailed view of layer stacking, and 156 interfaces between the IP layer and 802.11 OCB layers, is illustrated 157 below. The IP layer operates on top of the EtherType Protocol 158 Discrimination (EPD); this Discrimination layer is described in IEEE 159 Std 802.3-2012; the interface between IPv6 and EPD is the LLC_SAP 160 (Link Layer Control Service Accesss Point). 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | IPv6 | 164 +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ 165 { LLC_SAP } 802.11 OCB 166 +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary 167 | EPD | | | 168 | | MLME | | 169 +-+-+-{ MAC_SAP }+-+-+-| MLME_SAP | 170 | MAC Sublayer | | | 802.11 OCB 171 | and ch. coord. | | SME | Services 172 +-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| | 173 | | PLME | | 174 | PHY Layer | PLME_SAP | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 In addition to the description of interface between IP and MAC using 178 "Ethernet Adaptation Layer" and "Ethernet Protocol Discrimination 179 (EPD)" it is worth mentioning that SNAP [RFC1042] is used to carry 180 the IPv6 Ethertype. 182 However, there may be some deployment considerations helping optimize 183 the performances of running IPv6 over 802.11-OCB (e.g. in the case of 184 handovers between 802.11 OCB-enabled access routers, or the 185 consideration of using the IP security layer [RFC4301]). 187 There are currently no specifications for handover between OCB links 188 since these are currently specified as LLC-1 links (i.e. 189 connectionless). Any handovers must be performed above the Data Link 190 Layer. Also, while there is no encryption applied below the network 191 layer using 802.11p, 1609.2 [ieee1609.2] does provide security 192 services for applications to use so that there can easily be data 193 security over the air without invoking IPsec. 195 We briefly introduce the vehicular communication scenarios where IEEE 196 802.11-OCB links are used. This is followed by a description of 197 differences in specification terms, between 802.11 OCB and 198 802.11a/b/g/n (and the same differences expressed in terms of 199 requirements to software implementation are listed in Appendix B.) 201 The document then concentrates on the parameters of layering IP over 202 802.11 OCB as over Ethernet: value of MTU, the contents of Frame 203 Format, the rules for forming Interface Identifiers, the mechanism 204 for Address Mapping and for State-less Address Auto-configuration. 205 These are precisely the same as IPv6 over Ethernet [RFC2464]. 207 As an example, these characteristics of layering IPv6 straight over 208 LLC over 802.11 OCB MAC are illustrated by dissecting an IPv6 packet 209 captured over a 802.11 OCB link; this is described in the section 210 Section 6. 212 A couple of points can be considered as different, although they are 213 not required in order to have a working implementation of IPv6-over- 214 802.11-OCB. These points are consequences of the OCB operation which 215 is particular to 802.11 OCB (Outside the Context of a BSS). First, 216 the handovers between OCB links need specific behaviour for IP Router 217 Advertisements, or otherwise 802.11 OCB's Time Advertisement, or of 218 higher layer messages such as the 'Basic Safety Message' (in the US) 219 or the 'Cooperative Awareness Message' (in the EU) or the 'WAVE 220 Routing Advertisement'; second, the IP security mechanisms are 221 necessary, since OCB means that 802.11 is stripped of all 802.11 222 link-layer security; a small additional security aspect which is 223 shared between 802.11 OCB and other 802.11 links is the privacy 224 concerns related to the address formation mechanisms. 226 In the published literature, many documents describe aspects related 227 to running IPv6 over 802.11 OCB: 228 [I-D.jeong-ipwave-vehicular-networking-survey]. 230 2. Terminology 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 234 document are to be interpreted as described in RFC 2119 [RFC2119]. 236 RSU: Road Side Unit. A computer equipped with at least one IEEE 237 802.11 interface operated in OCB mode. This definition applies to 238 this document. An RSU may be connected to the Internet, and may be 239 equipped with additional wired or wireless network interfaces running 240 IP. An RSU MAY be an IP Router. 242 OCB: outside the context of a basic service set (BSS): A mode of 243 operation in which a STA is not a member of a BSS and does not 244 utilize IEEE Std 802.11 authentication, association, or data 245 confidentiality. 247 802.11-OCB, or 802.11 OCB: text in document IEEE 802.11-2012 that is 248 flagged by "dot11OCBActivated". This means: IEEE 802.11e for quality 249 of service; 802.11j-2004 for half-clocked operations; and (what was 250 known earlier as) 802.11p for operation in the 5.9 GHz band and in 251 mode OCB. 253 3. Communication Scenarios where IEEE 802.11 OCB Links are Used 255 The IEEE 802.11 OCB Networks are used for vehicular communications, 256 as 'Wireless Access in Vehicular Environments'. The IP communication 257 scenarios for these environments have been described in several 258 documents, among which we refer the reader to one recently updated 259 [I-D.petrescu-its-scenarios-reqs], about scenarios and requirements 260 for IP in Intelligent Transportation Systems. 262 4. Aspects introduced by the OCB mode to 802.11 264 In the IEEE 802.11 OCB mode, all nodes in the wireless range can 265 directly communicate with each other without authentication/ 266 association procedures. Briefly, the IEEE 802.11 OCB mode has the 267 following properties: 269 o The use by each node of a 'wildcard' BSSID (i.e., each bit of the 270 BSSID is set to 1) 272 o No IEEE 802.11 Beacon frames transmitted 274 o No authentication required 276 o No association needed 278 o No encryption provided 280 o Flag dot11OCBActivated set to true 282 The following message exchange diagram illustrates a comparison 283 between traditional 802.11 and 802.11 in OCB mode. The 'Data' 284 messages can be IP messages such as the messages used in Stateless or 285 Stateful Address Auto-Configuration, or other IP messages. Other 286 802.11 management and control frames (non IP) may be transmitted, as 287 specified in the 802.11 standard. For information, the names of 288 these messages as currently specified by the 802.11 standard are 289 listed in Appendix D. 291 STA AP STA1 STA2 292 | | | | 293 |<------ Beacon -------| |<------ Data -------->| 294 | | | | 295 |---- Probe Req. ----->| |<------ Data -------->| 296 |<--- Probe Res. ------| | | 297 | | |<------ Data -------->| 298 |---- Auth Req. ------>| | | 299 |<--- Auth Res. -------| |<------ Data -------->| 300 | | | | 301 |---- Asso Req. ------>| |<------ Data -------->| 302 |<--- Asso Res. -------| | | 303 | | |<------ Data -------->| 304 |<------ Data -------->| | | 305 |<------ Data -------->| |<------ Data -------->| 307 (a) 802.11 Infrastructure mode (b) 802.11 OCB mode 309 The link 802.11 OCB was specified in IEEE Std 802.11p (TM) -2010 310 [ieee802.11p-2010] as an amendment to IEEE Std 802.11 (TM) -2007, 311 titled "Amendment 6: Wireless Access in Vehicular Environments". 312 Since then, this amendment has been included in IEEE 802.11(TM)-2012 313 [ieee802.11-2012], titled "IEEE Standard for Information technology-- 314 Telecommunications and information exchange between systems Local and 315 metropolitan area networks--Specific requirements Part 11: Wireless 316 LAN Medium Access Control (MAC) and Physical Layer (PHY) 317 Specifications"; the modifications are diffused throughout various 318 sections (e.g. the Time Advertisement message described in the 319 earlier 802.11 (TM) p amendment is now described in section 'Frame 320 formats', and the operation outside the context of a BSS described in 321 section 'MLME'). 323 In document 802.11-2012, specifically anything referring 324 "OCBActivated", or "outside the context of a basic service set" is 325 actually referring to the 802.11p aspects introduced to 802.11. Note 326 that in earlier 802.11p documents the term "OCBEnabled" was used 327 instead of te current "OCBActivated". 329 In order to delineate the aspects introduced by 802.11 OCB to 802.11, 330 we refer to the earlier [ieee802.11p-2010]. The amendment is 331 concerned with vehicular communications, where the wireless link is 332 similar to that of Wireless LAN (using a PHY layer specified by 333 802.11a/b/g/n), but which needs to cope with the high mobility factor 334 inherent in scenarios of communications between moving vehicles, and 335 between vehicles and fixed infrastructure deployed along roads. 336 While 'p' is a letter just like 'a, b, g' and 'n' are, 'p' is 337 concerned more with MAC modifications, and a little with PHY 338 modifications; the others are mainly about PHY modifications. It is 339 possible in practice to combine a 'p' MAC with an 'a' PHY by 340 operating outside the context of a BSS with OFDM at 5.4GHz. 342 The 802.11 OCB links are specified to be compatible as much as 343 possible with the behaviour of 802.11a/b/g/n and future generation 344 IEEE WLAN links. From the IP perspective, an 802.11 OCB MAC layer 345 offers practically the same interface to IP as the WiFi and Ethernet 346 layers do (802.11a/b/g/n and 802.3). 348 To support this similarity statement (IPv6 is layered on top of LLC 349 on top of 802.11 OCB similarly as on top of LLC on top of 350 802.11a/b/g/n, and as on top of LLC on top of 802.3) it is useful to 351 analyze the differences between 802.11 OCB and 802.11 specifications. 352 Whereas the 802.11p amendment specifies relatively complex and 353 numerous changes to the MAC layer (and very little to the PHY layer), 354 we note there are only a few characteristics which may be important 355 for an implementation transmitting IPv6 packets on 802.11 OCB links. 357 In the list below, the only 802.11 OCB fundamental points which 358 influence IPv6 are the OCB operation and the 12Mbit/s maximum which 359 may be afforded by the IPv6 applications. 361 o Operation Outside the Context of a BSS (OCB): the (earlier 362 802.11p) 802.11-OCB links are operated without a Basic Service Set 363 (BSS). This means that the frames IEEE 802.11 Beacon, Association 364 Request/Response, Authentication Request/Response, and similar, 365 are not used. The used identifier of BSS (BSSID) has a 366 hexadecimal value always 0xffffffffffff (48 '1' bits, represented 367 as MAC address ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' 368 BSSID), as opposed to an arbitrary BSSID value set by 369 administrator (e.g. 'My-Home-AccessPoint'). The OCB operation - 370 namely the lack of beacon-based scanning and lack of 371 authentication - has a potentially strong impact on the use of the 372 Mobile IPv6 protocol [RFC6275] and on the protocols for IP layer 373 security [RFC4301]. 375 o Timing Advertisement: is a new message defined in 802.11-OCB, 376 which does not exist in 802.11a/b/g/n. This message is used by 377 stations to inform other stations about the value of time. It is 378 similar to the time as delivered by a GNSS system (Galileo, GPS, 379 ...) or by a cellular system. This message is optional for 380 implementation. At the date of writing, an experienced reviewer 381 considers that currently no field testing has used this message. 382 Another implementor considers this feature implemented in an 383 initial manner. In the future, it is speculated that this message 384 may be useful for very simple devices which may not have their own 385 hardware source of time (Galileo, GPS, cellular network), or by 386 vehicular devices situated in areas not covered by such network 387 (in tunnels, underground, outdoors but shaded by foliage or 388 buildings, in remote areas, etc.) 390 o Frequency range: this is a characteristic of the PHY layer, with 391 almost no impact to the interface between MAC and IP. However, it 392 is worth considering that the frequency range is regulated by a 393 regional authority (ARCEP, ETSI, FCC, etc.); as part of the 394 regulation process, specific applications are associated with 395 specific frequency ranges. In the case of 802.11-OCB, the 396 regulator associates a set of frequency ranges, or slots within a 397 band, to the use of applications of vehicular communications, in a 398 band known as "5.9GHz". This band is "5.9GHz" which is different 399 from the bands "2.4GHz" or "5GHz" used by Wireless LAN. However, 400 as with Wireless LAN, the operation of 802.11-OCB in "5.9GHz" 401 bands is exempt from owning a license in EU (in US the 5.9GHz is a 402 licensed band of spectrum; for the the fixed infrastructure an 403 explicit FCC autorization is required; for an onboard device a 404 'licensed-by-rule' concept applies: rule certification conformity 405 is required); however technical conditions are different than 406 those of the bands "2.4GHz" or "5GHz". On one hand, the allowed 407 power levels, and implicitly the maximum allowed distance between 408 vehicles, is of 33dBm for 802.11-OCB (in Europe), compared to 20 409 dBm for Wireless LAN 802.11a/b/g/n; this leads to a maximum 410 distance of approximately 1km, compared to approximately 50m. On 411 the other hand, specific conditions related to congestion 412 avoidance, jamming avoidance, and radar detection are imposed on 413 the use of DSRC (in US) and on the use of frequencies for 414 Intelligent Transportation Systems (in EU), compared to Wireless 415 LAN (802.11a/b/g/n). 417 o Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, 418 as opposed to IPv6 not being prohibited on any channel on which 419 802.11a/b/g/n runs: 421 * Some channels are reserved for safety communications; the IPv6 422 packets should not be sent on these channels. 424 * At the time of writing, the prohibition is explicit at higher 425 layer protocols providing services to the application; these 426 higher layer protocols are specified in IEEE 1609 documents. 428 * National or regional specifications and regulations specify the 429 use of different channels; these regulations must be followed. 431 o 'Half-rate' encoding: as the frequency range, this parameter is 432 related to PHY, and thus has not much impact on the interface 433 between the IP layer and the MAC layer. 435 o In vehicular communications using 802.11-OCB links, there are 436 strong privacy requirements with respect to addressing. While the 437 802.11-OCB standard does not specify anything in particular with 438 respect to MAC addresses, in these settings there exists a strong 439 need for dynamic change of these addresses (as opposed to the non- 440 vehicular settings - real wall protection - where fixed MAC 441 addresses do not currently pose some privacy risks). This is 442 further described in section Section 7. A relevant function is 443 described in IEEE 1609.3-2016 [ieee1609.3], clause 5.5.1 and IEEE 444 1609.4-2016 [ieee1609.4], clause 6.7. 446 Other aspects particular to 802.11-OCB which are also particular to 447 802.11 (e.g. the 'hidden node' operation) may have an influence on 448 the use of transmission of IPv6 packets on 802.11-OCB networks. The 449 subnet structure which may be assumed in 802.11-OCB networks is 450 strongly influenced by the mobility of vehicles. 452 5. Layering of IPv6 over 802.11-OCB as over Ethernet 454 5.1. Maximum Transmission Unit (MTU) 456 The default MTU for IP packets on 802.11-OCB is 1500 octets. It is 457 the same value as IPv6 packets on Ethernet links, as specified in 458 [RFC2464]. This value of the MTU respects the recommendation that 459 every link in the Internet must have a minimum MTU of 1280 octets 460 (stated in [RFC2460], and the recommendations therein, especially 461 with respect to fragmentation). If IPv6 packets of size larger than 462 1500 bytes are sent on an 802.11-OCB interface card then the IP stack 463 will fragment. In case there are IP fragments, the field "Sequence 464 number" of the 802.11 Data header containing the IP fragment field is 465 increased. 467 Non-IP packets such as WAVE Short Message Protocol (WSMP) can be 468 delivered on 802.11-OCB links. Specifications of these packets are 469 out of scope of this document, and do not impose any limit on the MTU 470 size, allowing an arbitrary number of 'containers'. Non-IP packets 471 such as ETSI 'geonet' packets have an MTU of 1492 bytes. 473 The Equivalent Transmit Time on Channel is a concept that may be used 474 as an alternative to the MTU concept. A rate of transmission may be 475 specified as well. The ETTC, rate and MTU may be in direct 476 relationship. 478 5.2. Frame Format 480 IP packets are transmitted over 802.11-OCB as standard Ethernet 481 packets. As with all 802.11 frames, an Ethernet adaptation layer is 482 used with 802.11-OCB as well. This Ethernet Adaptation Layer 483 performing 802.11-to-Ethernet is described in Section 5.2.1. The 484 Ethernet Type code (EtherType) for IPv6 is 0x86DD (hexadecimal 86DD, 485 or otherwise #86DD). 487 The Frame format for transmitting IPv6 on 802.11-OCB networks is the 488 same as transmitting IPv6 on Ethernet networks, and is described in 489 section 3 of [RFC2464]. The frame format for transmitting IPv6 490 packets over Ethernet is illustrated below: 492 0 1 493 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Destination | 496 +- -+ 497 | Ethernet | 498 +- -+ 499 | Address | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Source | 502 +- -+ 503 | Ethernet | 504 +- -+ 505 | Address | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 |1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1| 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | IPv6 | 510 +- -+ 511 | header | 512 +- -+ 513 | and | 514 +- -+ 515 / payload ... / 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 (Each tic mark represents one bit.) 519 Ethernet II Fields: 521 Destination Ethernet Address 522 the MAC destination address. 524 Source Ethernet Address 525 the MAC source address. 527 1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1 528 binary representation of the EtherType value 0x86DD. 530 IPv6 header and payload 531 the IPv6 packet containing IPv6 header and payload. 533 5.2.1. Ethernet Adaptation Layer 535 In general, an 'adaptation' layer is inserted between a MAC layer and 536 the Networking layer. This is used to transform some parameters 537 between their form expected by the IP stack and the form provided by 538 the MAC layer. For example, an 802.15.4 adaptation layer may perform 539 fragmentation and reassembly operations on a MAC whose maximum Packet 540 Data Unit size is smaller than the minimum MTU recognized by the IPv6 541 Networking layer. Other examples involve link-layer address 542 transformation, packet header insertion/removal, and so on. 544 An Ethernet Adaptation Layer makes an 802.11 MAC look to IP 545 Networking layer as a more traditional Ethernet layer. At reception, 546 this layer takes as input the IEEE 802.11 Data Header and the 547 Logical-Link Layer Control Header and produces an Ethernet II Header. 548 At sending, the reverse operation is performed. 550 +--------------------+------------+-------------+---------+-----------+ 551 | 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer| 552 +--------------------+------------+-------------+---------+-----------+ 553 \ / \ / 554 ----------------------------- -------- 555 ^---------------------------------------------/ 556 | 557 802.11-to-Ethernet Adaptation Layer 558 | 559 v 560 +---------------------+-------------+---------+ 561 | Ethernet II Header | IPv6 Header | Payload | 562 +---------------------+-------------+---------+ 563 The Receiver and Transmitter Address fields in the 802.11 Data Header 564 contain the same values as the Destination and the Source Address 565 fields in the Ethernet II Header, respectively. The value of the 566 Type field in the LLC Header is the same as the value of the Type 567 field in the Ethernet II Header. 569 The ".11 Trailer" contains solely a 4-byte Frame Check Sequence. 571 The Ethernet Adaptation Layer performs operations in relation to IP 572 fragmentation and MTU. One of these operations is briefly described 573 in section Section 5.1. 575 In OCB mode, IPv6 packets can be transmitted either as "IEEE 802.11 576 Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in 577 the following figure: 579 +--------------------+-------------+-------------+---------+-----------+ 580 | 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer| 581 +--------------------+-------------+-------------+---------+-----------+ 583 or 585 +--------------------+-------------+-------------+---------+-----------+ 586 | 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |.11 Trailer| 587 +--------------------+-------------+-------------+---------+-----------+ 589 The distinction between the two formats is given by the value of the 590 field "Type/Subtype". The value of the field "Type/Subtype" in the 591 802.11 Data header is 0x0020. The value of the field "Type/Subtype" 592 in the 802.11 QoS header is 0x0028. 594 The mapping between qos-related fields in the IPv6 header (e.g. 595 "Traffic Class", "Flow label") and fields in the "802.11 QoS Data 596 Header" (e.g. "QoS Control") are not specified in this document. 597 Guidance for a potential mapping is provided in 598 [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB 599 mode. 601 5.3. Link-Local Addresses 603 The link-local address of an 802.11-OCB interface is formed in the 604 same manner as on an Ethernet interface. This manner is described in 605 section 5 of [RFC2464]. 607 5.4. Address Mapping 609 For unicast as for multicast, there is no change from the unicast and 610 multicast address mapping format of Ethernet interfaces, as defined 611 by sections 6 and 7 of [RFC2464]. 613 5.4.1. Address Mapping -- Unicast 615 The procedure for mapping IPv6 unicast addresses into Ethernet link- 616 layer addresses is described in [RFC4861]. The Source/Target Link- 617 layer Address option has the following form when the link-layer is 618 Ethernet. 620 0 1 621 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type | Length | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | | 626 +- Ethernet -+ 627 | | 628 +- Address -+ 629 | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Option fields: 634 Type 635 1 for Source Link-layer address. 636 2 for Target Link-layer address. 638 Length 639 1 (in units of 8 octets). 641 Ethernet Address 642 The 48 bit Ethernet IEEE 802 address, in canonical bit order. 644 5.4.2. Address Mapping -- Multicast 646 IPv6 protocols often make use of IPv6 multicast addresses in the 647 destination field of IPv6 headers. For example, an ICMPv6 link- 648 scoped Neighbor Advertisement is sent to the IPv6 address ff02::1 649 denoted "all-nodes" address. When transmitting these packets on 650 802.11-OCB links it is necessary to map the IPv6 address to a MAC 651 address. 653 The same mapping requirement applies to the link-scoped multicast 654 addresses of other IPv6 protocols as well. In DHCPv6, the 655 "All_DHCP_Servers" IPv6 multicast address ff02::1:2, and in OSPF the 656 "All_SPF_Routers" IPv6 multicast address ff02::5, need to be mapped 657 on a multicast MAC address. 659 An IPv6 packet with a multicast destination address DST, consisting 660 of the sixteen octets DST[1] through DST[16], is transmitted to the 661 IEEE 802.11-OCB MAC multicast address whose first two octets are the 662 value 0x3333 and whose last four octets are the last four octets of 663 DST. 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | DST[13] | DST[14] | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | DST[15] | DST[16] | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 A Group ID TBD of length 112bits may be requested from IANA; this 674 Group ID signifies "All 80211OCB Interfaces Address". Only the least 675 32 significant bits of this "All 80211OCB Interfaces Address" will be 676 mapped to and from a MAC multicast address. 678 Transmitting IPv6 packets to multicast destinations over 802.11 links 679 proved to have some performance issues 680 [I-D.perkins-intarea-multicast-ieee802]. These issues may be 681 exacerbated in OCB mode. Solutions for these problems should 682 consider the OCB mode of operation. 684 5.5. Stateless Autoconfiguration 686 The Interface Identifier for an 802.11-OCB interface is formed using 687 the same rules as the Interface Identifier for an Ethernet interface; 688 this is described in section 4 of [RFC2464]. No changes are needed, 689 but some care must be taken when considering the use of the SLAAC 690 procedure. 692 The bits in the the interface identifier have no generic meaning and 693 the identifier should be treated as an opaque value. The bits 694 'Universal' and 'Group' in the identifier of an 802.11-OCB interface 695 are significant, as this is an IEEE link-layer address. The details 696 of this significance are described in [I-D.ietf-6man-ug]. 698 As with all Ethernet and 802.11 interface identifiers ([RFC7721]), 699 the identifier of an 802.11-OCB interface may involve privacy risks. 700 A vehicle embarking an On-Board Unit whose egress interface is 701 802.11-OCB may expose itself to eavesdropping and subsequent 702 correlation of data; this may reveal data considered private by the 703 vehicle owner; there is a risk of being tracked; see the privacy 704 considerations described in Appendix C. 706 If stable Interface Identifiers are needed in order to form IPv6 707 addresses on 802.11-OCB links, it is recommended to follow the 708 recommendation in [I-D.ietf-6man-default-iids]. 710 5.6. Subnet Structure 712 The 802.11 networks in OCB mode may be considered as 'ad-hoc' 713 networks. The addressing model for such networks is described in 714 [RFC5889]. 716 6. Example IPv6 Packet captured over a IEEE 802.11-OCB link 718 We remind that a main goal of this document is to make the case that 719 IPv6 works fine over 802.11-OCB networks. Consequently, this section 720 is an illustration of this concept and thus can help the implementer 721 when it comes to running IPv6 over IEEE 802.11-OCB. By way of 722 example we show that there is no modification in the headers when 723 transmitted over 802.11-OCB networks - they are transmitted like any 724 other 802.11 and Ethernet packets. 726 We describe an experiment of capturing an IPv6 packet on an 727 802.11-OCB link. In this experiment, the packet is an IPv6 Router 728 Advertisement. This packet is emitted by a Router on its 802.11-OCB 729 interface. The packet is captured on the Host, using a network 730 protocol analyzer (e.g. Wireshark); the capture is performed in two 731 different modes: direct mode and 'monitor' mode. The topology used 732 during the capture is depicted below. 734 +--------+ +-------+ 735 | | 802.11-OCB Link | | 736 ---| Router |--------------------------------| Host | 737 | | | | 738 +--------+ +-------+ 740 During several capture operations running from a few moments to 741 several hours, no message relevant to the BSSID contexts were 742 captured (no Association Request/Response, Authentication Req/Resp, 743 Beacon). This shows that the operation of 802.11-OCB is outside the 744 context of a BSSID. 746 Overall, the captured message is identical with a capture of an IPv6 747 packet emitted on a 802.11b interface. The contents are precisely 748 similar. 750 6.1. Capture in Monitor Mode 752 The IPv6 RA packet captured in monitor mode is illustrated below. 753 The radio tap header provides more flexibility for reporting the 754 characteristics of frames. The Radiotap Header is prepended by this 755 particular stack and operating system on the Host machine to the RA 756 packet received from the network (the Radiotap Header is not present 757 on the air). The implementation-dependent Radiotap Header is useful 758 for piggybacking PHY information from the chip's registers as data in 759 a packet understandable by userland applications using Socket 760 interfaces (the PHY interface can be, for example: power levels, data 761 rate, ratio of signal to noise). 763 The packet present on the air is formed by IEEE 802.11 Data Header, 764 Logical Link Control Header, IPv6 Base Header and ICMPv6 Header. 766 Radiotap Header v0 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 |Header Revision| Header Pad | Header length | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Present flags | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Data Rate | Pad | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 IEEE 802.11 Data Header 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Type/Subtype and Frame Ctrl | Duration | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Receiver Address... 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 ... Receiver Address | Transmitter Address... 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 ... Transmitter Address | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | BSS Id... 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 ... BSS Id | Frag Number and Seq Number | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Logical-Link Control Header 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | DSAP |I| SSAP |C| Control field | Org. code... 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 ... Organizational Code | Type | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 IPv6 Base Header 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 |Version| Traffic Class | Flow Label | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Payload Length | Next Header | Hop Limit | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | | 803 + + 804 | | 805 + Source Address + 806 | | 807 + + 808 | | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | | 811 + + 812 | | 813 + Destination Address + 814 | | 815 + + 816 | | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 Router Advertisement 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Type | Code | Checksum | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Reachable Time | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Retrans Timer | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Options ... 830 +-+-+-+-+-+-+-+-+-+-+-+- 832 The value of the Data Rate field in the Radiotap header is set to 6 833 Mb/s. This indicates the rate at which this RA was received. 835 The value of the Transmitter address in the IEEE 802.11 Data Header 836 is set to a 48bit value. The value of the destination address is 837 33:33:00:00:00:1 (all-nodes multicast address). The value of the BSS 838 Id field is ff:ff:ff:ff:ff:ff, which is recognized by the network 839 protocol analyzer as being "broadcast". The Fragment number and 840 sequence number fields are together set to 0x90C6. 842 The value of the Organization Code field in the Logical-Link Control 843 Header is set to 0x0, recognized as "Encapsulated Ethernet". The 844 value of the Type field is 0x86DD (hexadecimal 86DD, or otherwise 845 #86DD), recognized as "IPv6". 847 A Router Advertisement is periodically sent by the router to 848 multicast group address ff02::1. It is an icmp packet type 134. The 849 IPv6 Neighbor Discovery's Router Advertisement message contains an 850 8-bit field reserved for single-bit flags, as described in [RFC4861]. 852 The IPv6 header contains the link local address of the router 853 (source) configured via EUI-64 algorithm, and destination address set 854 to ff02::1. Recent versions of network protocol analyzers (e.g. 855 Wireshark) provide additional informations for an IP address, if a 856 geolocalization database is present. In this example, the 857 geolocalization database is absent, and the "GeoIP" information is 858 set to unknown for both source and destination addresses (although 859 the IPv6 source and destination addresses are set to useful values). 860 This "GeoIP" can be a useful information to look up the city, 861 country, AS number, and other information for an IP address. 863 The Ethernet Type field in the logical-link control header is set to 864 0x86dd which indicates that the frame transports an IPv6 packet. In 865 the IEEE 802.11 data, the destination address is 33:33:00:00:00:01 866 which is he corresponding multicast MAC address. The BSS id is a 867 broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link 868 duration between vehicles and the roadside infrastructure, there is 869 no need in IEEE 802.11-OCB to wait for the completion of association 870 and authentication procedures before exchanging data. IEEE 871 802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s) 872 and may start communicating as soon as they arrive on the 873 communication channel. 875 6.2. Capture in Normal Mode 877 The same IPv6 Router Advertisement packet described above (monitor 878 mode) is captured on the Host, in the Normal mode, and depicted 879 below. 881 Ethernet II Header 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Destination... 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 ...Destination | Source... 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 ...Source | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Type | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 IPv6 Base Header 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 |Version| Traffic Class | Flow Label | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Payload Length | Next Header | Hop Limit | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | | 899 + + 900 | | 901 + Source Address + 902 | | 903 + + 904 | | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | | 907 + + 908 | | 909 + Destination Address + 910 | | 911 + + 912 | | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 Router Advertisement 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Type | Code | Checksum | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Reachable Time | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Retrans Timer | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Options ... 926 +-+-+-+-+-+-+-+-+-+-+-+- 928 One notices that the Radiotap Header is not prepended, and that the 929 IEEE 802.11 Data Header and the Logical-Link Control Headers are not 930 present. On another hand, a new header named Ethernet II Header is 931 present. 933 The Destination and Source addresses in the Ethernet II header 934 contain the same values as the fields Receiver Address and 935 Transmitter Address present in the IEEE 802.11 Data Header in the 936 "monitor" mode capture. 938 The value of the Type field in the Ethernet II header is 0x86DD 939 (recognized as "IPv6"); this value is the same value as the value of 940 the field Type in the Logical-Link Control Header in the "monitor" 941 mode capture. 943 The knowledgeable experimenter will no doubt notice the similarity of 944 this Ethernet II Header with a capture in normal mode on a pure 945 Ethernet cable interface. 947 It may be interpreted that an Adaptation layer is inserted in a pure 948 IEEE 802.11 MAC packets in the air, before delivering to the 949 applications. In detail, this adaptation layer may consist in 950 elimination of the Radiotap, 802.11 and LLC headers and insertion of 951 the Ethernet II header. In this way, it can be stated that IPv6 runs 952 naturally straight over LLC over the 802.11-OCB MAC layer, as shown 953 by the use of the Type 0x86DD, and assuming an adaptation layer 954 (adapting 802.11 LLC/MAC to Ethernet II header). 956 7. Security Considerations 958 Any security mechanism at the IP layer or above that may be carried 959 out for the general case of IPv6 may also be carried out for IPv6 960 operating over 802.11-OCB. 962 802.11-OCB does not provide any cryptographic protection, because it 963 operates outside the context of a BSS (no Association Request/ 964 Response, no Challenge messages). Any attacker can therefore just 965 sit in the near range of vehicles, sniff the network (just set the 966 interface card's frequency to the proper range) and perform attacks 967 without needing to physically break any wall. Such a link is way 968 less protected than commonly used links (wired link or protected 969 802.11). 971 At the IP layer, IPsec can be used to protect unicast communications, 972 and SeND can be used for multicast communications. If no protection 973 is used by the IP layer, upper layers should be protected. 974 Otherwise, the end-user or system should be warned about the risks 975 they run. 977 As with all Ethernet and 802.11 interface identifiers, there may 978 exist privacy risks in the use of 802.11-OCB interface identifiers. 979 Moreover, in outdoors vehicular settings, the privacy risks are more 980 important than in indoors settings. New risks are induced by the 981 possibility of attacker sniffers deployed along routes which listen 982 for IP packets of vehicles passing by. For this reason, in the 983 802.11-OCB deployments, there is a strong necessity to use protection 984 tools such as dynamically changing MAC addresses. This may help 985 mitigate privacy risks to a certain level. On another hand, it may 986 have an impact in the way typical IPv6 address auto-configuration is 987 performed for vehicles (SLAAC would rely on MAC addresses amd would 988 hence dynamically change the affected IP address), in the way the 989 IPv6 Privacy addresses were used, and other effects. 991 8. IANA Considerations 993 9. Contributors 995 Romain Kuntz contributed extensively about IPv6 handovers between 996 links running outside the context of a BSS (802.11-OCB links). 998 Tim Leinmueller contributed the idea of the use of IPv6 over 999 802.11-OCB for distribution of certificates. 1001 Marios Makassikis, Jose Santa Lozano, Albin Severinson and Alexey 1002 Voronov provided significant feedback on the experience of using IP 1003 messages over 802.11-OCB in initial trials. 1005 Michelle Wetterwald contributed extensively the MTU discussion, 1006 offered the ETSI ITS perspective, and reviewed other parts of the 1007 document. 1009 10. Acknowledgements 1011 The authors would like to thank Witold Klaudel, Ryuji Wakikawa, 1012 Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan 1013 Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray 1014 Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, 1015 Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, 1016 Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, 1017 Bob Moskowitz, Andrew (Dryden?), Georg Mayer, Dorothy Stanley and 1018 William Whyte. Their valuable comments clarified certain issues and 1019 generally helped to improve the document. 1021 Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB 1022 drivers for linux and described how. 1024 For the multicast discussion, the authors would like to thank Owen 1025 DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and 1026 participants to discussions in network working groups. 1028 The authours would like to thank participants to the Birds-of- 1029 a-Feather "Intelligent Transportation Systems" meetings held at IETF 1030 in 2016. 1032 11. References 1034 11.1. Normative References 1036 [I-D.ietf-6man-default-iids] 1037 Gont, F., Cooper, A., Thaler, D., and S. LIU, 1038 "Recommendation on Stable IPv6 Interface Identifiers", 1039 draft-ietf-6man-default-iids-16 (work in progress), 1040 September 2016. 1042 [I-D.ietf-6man-ug] 1043 Carpenter, B. and S. Jiang, "Significance of IPv6 1044 Interface Identifiers", draft-ietf-6man-ug-06 (work in 1045 progress), December 2013. 1047 [I-D.ietf-tsvwg-ieee-802-11] 1048 Szigeti, T., Henry, J., and F. Baker, "Diffserv to IEEE 1049 802.11 Mapping", draft-ietf-tsvwg-ieee-802-11-06 (work in 1050 progress), August 2017. 1052 [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission 1053 of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, 1054 DOI 10.17487/RFC1042, February 1988, . 1057 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1058 Requirement Levels", BCP 14, RFC 2119, 1059 DOI 10.17487/RFC2119, March 1997, . 1062 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1063 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1064 December 1998, . 1066 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1067 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1068 . 1070 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1071 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1072 RFC 3963, DOI 10.17487/RFC3963, January 2005, 1073 . 1075 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1076 "Randomness Requirements for Security", BCP 106, RFC 4086, 1077 DOI 10.17487/RFC4086, June 2005, . 1080 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1081 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1082 December 2005, . 1084 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1085 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 1086 . 1088 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1089 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1090 DOI 10.17487/RFC4861, September 2007, . 1093 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 1094 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 1095 September 2010, . 1097 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1098 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1099 2011, . 1101 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1102 Bormann, "Neighbor Discovery Optimization for IPv6 over 1103 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1104 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1105 . 1107 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1108 Considerations for IPv6 Address Generation Mechanisms", 1109 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1110 . 1112 11.2. Informative References 1114 [fcc-cc] "'Report and Order, Before the Federal Communications 1115 Commission Washington, D.C. 20554', FCC 03-324, Released 1116 on February 10, 2004, document FCC-03-324A1.pdf, document 1117 freely available at URL 1118 http://www.its.dot.gov/exit/fcc_edocs.htm downloaded on 1119 October 17th, 2013.". 1121 [fcc-cc-172-184] 1122 "'Memorandum Opinion and Order, Before the Federal 1123 Communications Commission Washington, D.C. 20554', FCC 1124 06-10, Released on July 26, 2006, document FCC- 1125 06-110A1.pdf, document freely available at URL 1126 http://hraunfoss.fcc.gov/edocs_public/attachmatch/ 1127 FCC-06-110A1.pdf downloaded on June 5th, 2014.". 1129 [I-D.jeong-ipwave-vehicular-networking-survey] 1130 Jeong, J., Cespedes, S., Benamar, N., Haerri, J., and M. 1131 Wetterwald, "Survey on IP-based Vehicular Networking for 1132 Intelligent Transportation Systems", draft-jeong-ipwave- 1133 vehicular-networking-survey-03 (work in progress), June 1134 2017. 1136 [I-D.perkins-intarea-multicast-ieee802] 1137 Perkins, C., Stanley, D., Kumari, W., and J. Zuniga, 1138 "Multicast Considerations over IEEE 802 Wireless Media", 1139 draft-perkins-intarea-multicast-ieee802-03 (work in 1140 progress), July 2017. 1142 [I-D.petrescu-its-scenarios-reqs] 1143 Petrescu, A., Janneteau, C., Boc, M., and W. Klaudel, 1144 "Scenarios and Requirements for IP in Intelligent 1145 Transportation Systems", draft-petrescu-its-scenarios- 1146 reqs-03 (work in progress), October 2013. 1148 [ieee1609.2] 1149 "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access 1150 in Vehicular Environments (WAVE) -- Security Services for 1151 Applications and Management Messages. Example URL 1152 http://ieeexplore.ieee.org/document/7426684/ accessed on 1153 August 17th, 2017.". 1155 [ieee1609.3] 1156 "IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access 1157 in Vehicular Environments (WAVE) -- Networking Services. 1158 Example URL http://ieeexplore.ieee.org/document/7458115/ 1159 accessed on August 17th, 2017.". 1161 [ieee1609.4] 1162 "IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access 1163 in Vehicular Environments (WAVE) -- Multi-Channel 1164 Operation. Example URL 1165 http://ieeexplore.ieee.org/document/7435228/ accessed on 1166 August 17th, 2017.". 1168 [ieee802.11-2012] 1169 "802.11-2012 - IEEE Standard for Information technology-- 1170 Telecommunications and information exchange between 1171 systems Local and metropolitan area networks--Specific 1172 requirements Part 11: Wireless LAN Medium Access Control 1173 (MAC) and Physical Layer (PHY) Specifications. Downloaded 1174 on October 17th, 2013, from IEEE Standards, document 1175 freely available at URL 1176 http://standards.ieee.org/findstds/ 1177 standard/802.11-2012.html retrieved on October 17th, 1178 2013.". 1180 [ieee802.11p-2010] 1181 "IEEE Std 802.11p (TM)-2010, IEEE Standard for Information 1182 Technology - Telecommunications and information exchange 1183 between systems - Local and metropolitan area networks - 1184 Specific requirements, Part 11: Wireless LAN Medium Access 1185 Control (MAC) and Physical Layer (PHY) Specifications, 1186 Amendment 6: Wireless Access in Vehicular Environments; 1187 document freely available at URL 1188 http://standards.ieee.org/getieee802/ 1189 download/802.11p-2010.pdf retrieved on September 20th, 1190 2013.". 1192 Appendix A. ChangeLog 1194 The changes are listed in reverse chronological order, most recent 1195 changes appearing at the top of the list. 1197 From draft-ietf-ipwave-ipv6-over-80211ocb-03 to draft-ietf-ipwave- 1198 ipv6-over-80211ocb-04 1200 o Removed a few informative references pointing to Dx draft IEEE 1201 1609 documents. 1203 o Removed outdated informative references to ETSI documents. 1205 o Added citations to IEEE 1609.2, .3 and .4-2016. 1207 o Minor textual issues. 1209 From draft-ietf-ipwave-ipv6-over-80211ocb-02 to draft-ietf-ipwave- 1210 ipv6-over-80211ocb-03 1212 o Keep the previous text on multiple addresses, so remove talk about 1213 MIP6, NEMOv6 and MCoA. 1215 o Clarified that a 'Beacon' is an IEEE 802.11 frame Beacon. 1217 o Clarified the figure showing Infrastructure mode and OCB mode side 1218 by side. 1220 o Added a reference to the IP Security Architecture RFC. 1222 o Detailed the IPv6-per-channel prohibition paragraph which reflects 1223 the discussion at the last IETF IPWAVE WG meeting. 1225 o Added section "Address Mapping -- Unicast". 1227 o Added the ".11 Trailer" to pictures of 802.11 frames. 1229 o Added text about SNAP carrying the Ethertype. 1231 o New RSU definition allowing for it be both a Router and not 1232 necessarily a Router some times. 1234 o Minor textual issues. 1236 From draft-ietf-ipwave-ipv6-over-80211ocb-01 to draft-ietf-ipwave- 1237 ipv6-over-80211ocb-02 1239 o Replaced almost all occurences of 802.11p with 802.11-OCB, leaving 1240 only when explanation of evolution was necessary. 1242 o Shortened by removing parameter details from a paragraph in the 1243 Introduction. 1245 o Moved a reference from Normative to Informative. 1247 o Added text in intro clarifying there is no handover spec at IEEE, 1248 and that 1609.2 does provide security services. 1250 o Named the contents the fields of the EthernetII header (including 1251 the Ethertype bitstring). 1253 o Improved relationship between two paragraphs describing the 1254 increase of the Sequence Number in 802.11 header upon IP 1255 fragmentation. 1257 o Added brief clarification of "tracking". 1259 From draft-ietf-ipwave-ipv6-over-80211ocb-00 to draft-ietf-ipwave- 1260 ipv6-over-80211ocb-01 1262 o Introduced message exchange diagram illustrating differences 1263 between 802.11 and 802.11 in OCB mode. 1265 o Introduced an appendix listing for information the set of 802.11 1266 messages that may be transmitted in OCB mode. 1268 o Removed appendix sections "Privacy Requirements", "Authentication 1269 Requirements" and "Security Certificate Generation". 1271 o Removed appendix section "Non IP Communications". 1273 o Introductory phrase in the Security Considerations section. 1275 o Improved the definition of "OCB". 1277 o Introduced theoretical stacked layers about IPv6 and IEEE layers 1278 including EPD. 1280 o Removed the appendix describing the details of prohibiting IPv6 on 1281 certain channels relevant to 802.11-OCB. 1283 o Added a brief reference in the privacy text about a precise clause 1284 in IEEE 1609.3 and .4. 1286 o Clarified the definition of a Road Side Unit. 1288 o Removed the discussion about security of WSA (because is non-IP). 1290 o Removed mentioning of the GeoNetworking discussion. 1292 o Moved references to scientific articles to a separate 'overview' 1293 draft, and referred to it. 1295 Appendix B. Changes Needed on a software driver 802.11a to become a 1296 802.11-OCB driver 1298 The 802.11p amendment modifies both the 802.11 stack's physical and 1299 MAC layers but all the induced modifications can be quite easily 1300 obtained by modifying an existing 802.11a ad-hoc stack. 1302 Conditions for a 802.11a hardware to be 802.11-OCB compliant: 1304 o The chip must support the frequency bands on which the regulator 1305 recommends the use of ITS communications, for example using IEEE 1306 802.11-OCB layer, in France: 5875MHz to 5925MHz. 1308 o The chip must support the half-rate mode (the internal clock 1309 should be able to be divided by two). 1311 o The chip transmit spectrum mask must be compliant to the "Transmit 1312 spectrum mask" from the IEEE 802.11p amendment (but experimental 1313 environments tolerate otherwise). 1315 o The chip should be able to transmit up to 44.8 dBm when used by 1316 the US government in the United States, and up to 33 dBm in 1317 Europe; other regional conditions apply. 1319 Changes needed on the network stack in OCB mode: 1321 o Physical layer: 1323 * The chip must use the Orthogonal Frequency Multiple Access 1324 (OFDM) encoding mode. 1326 * The chip must be set in half-mode rate mode (the internal clock 1327 frequency is divided by two). 1329 * The chip must use dedicated channels and should allow the use 1330 of higher emission powers. This may require modifications to 1331 the regulatory domains rules, if used by the kernel to enforce 1332 local specific restrictions. Such modifications must respect 1333 the location-specific laws. 1335 MAC layer: 1337 * All management frames (beacons, join, leave, and others) 1338 emission and reception must be disabled except for frames of 1339 subtype Action and Timing Advertisement (defined below). 1341 * No encryption key or method must be used. 1343 * Packet emission and reception must be performed as in ad-hoc 1344 mode, using the wildcard BSSID (ff:ff:ff:ff:ff:ff). 1346 * The functions related to joining a BSS (Association Request/ 1347 Response) and for authentication (Authentication Request/Reply, 1348 Challenge) are not called. 1350 * The beacon interval is always set to 0 (zero). 1352 * Timing Advertisement frames, defined in the amendment, should 1353 be supported. The upper layer should be able to trigger such 1354 frames emission and to retrieve information contained in 1355 received Timing Advertisements. 1357 Appendix C. Design Considerations 1359 The networks defined by 802.11-OCB are in many ways similar to other 1360 networks of the 802.11 family. In theory, the encapsulation of IPv6 1361 over 802.11-OCB could be very similar to the operation of IPv6 over 1362 other networks of the 802.11 family. However, the high mobility, 1363 strong link asymetry and very short connection makes the 802.11-OCB 1364 link significantly different from other 802.11 networks. Also, the 1365 automotive applications have specific requirements for reliability, 1366 security and privacy, which further add to the particularity of the 1367 802.11-OCB link. 1369 C.1. Vehicle ID 1371 Automotive networks require the unique representation of each of 1372 their node. Accordingly, a vehicle must be identified by at least 1373 one unique identifier. The current specification at ETSI and at IEEE 1374 1609 identifies a vehicle by its MAC address uniquely obtained from 1375 the 802.11-OCB NIC. 1377 A MAC address uniquely obtained from a IEEE 802.11-OCB NIC 1378 implicitely generates multiple vehicle IDs in case of multiple 1379 802.11-OCB NICs. A mechanims to uniquely identify a vehicle 1380 irrespectively to the different NICs and/or technologies is required. 1382 C.2. Reliability Requirements 1384 The dynamically changing topology, short connectivity, mobile 1385 transmitter and receivers, different antenna heights, and many-to- 1386 many communication types, make IEEE 802.11-OCB links significantly 1387 different from other IEEE 802.11 links. Any IPv6 mechanism operating 1388 on IEEE 802.11-OCB link MUST support strong link asymetry, spatio- 1389 temporal link quality, fast address resolution and transmission. 1391 IEEE 802.11-OCB strongly differs from other 802.11 systems to operate 1392 outside of the context of a Basic Service Set. This means in 1393 practice that IEEE 802.11-OCB does not rely on a Base Station for all 1394 Basic Service Set management. In particular, IEEE 802.11-OCB SHALL 1395 NOT use beacons. Any IPv6 mechanism requiring L2 services from IEEE 1396 802.11 beacons MUST support an alternative service. 1398 Channel scanning being disabled, IPv6 over IEEE 802.11-OCB MUST 1399 implement a mechanism for transmitter and receiver to converge to a 1400 common channel. 1402 Authentication not being possible, IPv6 over IEEE 802.11-OCB MUST 1403 implement an distributed mechanism to authenticate transmitters and 1404 receivers without the support of a DHCP server. 1406 Time synchronization not being available, IPv6 over IEEE 802.11-OCB 1407 MUST implement a higher layer mechanism for time synchronization 1408 between transmitters and receivers without the support of a NTP 1409 server. 1411 The IEEE 802.11-OCB link being asymetic, IPv6 over IEEE 802.11-OCB 1412 MUST disable management mechanisms requesting acknowledgements or 1413 replies. 1415 The IEEE 802.11-OCB link having a short duration time, IPv6 over IEEE 1416 802.11-OCB MUST implement fast IPv6 mobility management mechanisms. 1418 C.3. Multiple interfaces 1420 There are considerations for 2 or more IEEE 802.11-OCB interface 1421 cards per vehicle. For each vehicle taking part in road traffic, one 1422 IEEE 802.11-OCB interface card could be fully allocated for Non IP 1423 safety-critical communication. Any other IEEE 802.11-OCB may be used 1424 for other type of traffic. 1426 The mode of operation of these other wireless interfaces is not 1427 clearly defined yet. One possibility is to consider each card as an 1428 independent network interface, with a specific MAC Address and a set 1429 of IPv6 addresses. Another possibility is to consider the set of 1430 these wireless interfaces as a single network interface (not 1431 including the IEEE 802.11-OCB interface used by Non IP safety 1432 critical communications). This will require specific logic to 1433 ensure, for example, that packets meant for a vehicle in front are 1434 actually sent by the radio in the front, or that multiple copies of 1435 the same packet received by multiple interfaces are treated as a 1436 single packet. Treating each wireless interface as a separate 1437 network interface pushes such issues to the application layer. 1439 The privacy requirements of [] imply that if these multiple 1440 interfaces are represented by many network interface, a single 1441 renumbering event SHALL cause renumbering of all these interfaces. 1442 If one MAC changed and another stayed constant, external observers 1443 would be able to correlate old and new values, and the privacy 1444 benefits of randomization would be lost. 1446 The privacy requirements of Non IP safety-critical communications 1447 imply that if a change of pseudonyme occurs, renumbering of all other 1448 interfaces SHALL also occur. 1450 C.4. MAC Address Generation 1452 When designing the IPv6 over 802.11-OCB address mapping, we will 1453 assume that the MAC Addresses will change during well defined 1454 "renumbering events". The 48 bits randomized MAC addresses will have 1455 the following characteristics: 1457 o Bit "Local/Global" set to "locally admninistered". 1459 o Bit "Unicast/Multicast" set to "Unicast". 1461 o 46 remaining bits set to a random value, using a random number 1462 generator that meets the requirements of [RFC4086]. 1464 The way to meet the randomization requirements is to retain 46 bits 1465 from the output of a strong hash function, such as SHA256, taking as 1466 input a 256 bit local secret, the "nominal" MAC Address of the 1467 interface, and a representation of the date and time of the 1468 renumbering event. 1470 Appendix D. IEEE 802.11 Messages Transmitted in OCB mode 1472 For information, at the time of writing, this is the list of IEEE 1473 802.11 messages that may be transmitted in OCB mode, i.e. when 1474 dot11OCBActivated is true in a STA: 1476 o The STA may send management frames of subtype Action and, if the 1477 STA maintains a TSF Timer, subtype Timing Advertisement; 1479 o The STA may send control frames, except those of subtype PS-Poll, 1480 CF-End, and CF-End plus CFAck; 1482 o The STA may send data frames of subtype Data, Null, QoS Data, and 1483 QoS Null. 1485 Authors' Addresses 1486 Alexandre Petrescu 1487 CEA, LIST 1488 CEA Saclay 1489 Gif-sur-Yvette , Ile-de-France 91190 1490 France 1492 Phone: +33169089223 1493 Email: Alexandre.Petrescu@cea.fr 1495 Nabil Benamar 1496 Moulay Ismail University 1497 Morocco 1499 Phone: +212670832236 1500 Email: benamar73@gmail.com 1502 Jerome Haerri 1503 Eurecom 1504 Sophia-Antipolis 06904 1505 France 1507 Phone: +33493008134 1508 Email: Jerome.Haerri@eurecom.fr 1510 Christian Huitema 1511 Friday Harbor, WA 98250 1512 U.S.A. 1514 Email: huitema@huitema.net 1516 Jong-Hyouk Lee 1517 Sangmyung University 1518 31, Sangmyeongdae-gil, Dongnam-gu 1519 Cheonan 31066 1520 Republic of Korea 1522 Email: jonghyouk@smu.ac.kr 1524 Thierry Ernst 1525 YoGoKo 1526 France 1528 Email: thierry.ernst@yogoko.fr 1529 Tony Li 1530 Peloton Technology 1531 1060 La Avenida St. 1532 Mountain View, California 94043 1533 United States 1535 Phone: +16503957356 1536 Email: tony.li@tony.li