idnits 2.17.1 draft-ietf-ipwave-ipv6-over-80211ocb-00.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 (December 1, 2016) is 2703 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 584 -- Looks like a reference, but probably isn't: '16' on line 594 -- Looks like a reference, but probably isn't: '13' on line 592 -- Looks like a reference, but probably isn't: '14' on line 592 -- Looks like a reference, but probably isn't: '15' on line 594 == Missing Reference: 'V2V' is mentioned on line 1383, but not defined == Unused Reference: 'RFC6775' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'I-D.baccelli-multi-hop-wireless-communication' is defined on line 1175, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-ieee-802-11-01 ** 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 == Outdated reference: A later version (-03) exists of draft-perkins-intarea-multicast-ieee802-01 Summary: 3 errors (**), 0 flaws (~~), 6 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: June 4, 2017 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 December 1, 2016 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-00.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 June 4, 2017. 59 Copyright Notice 61 Copyright (c) 2016 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.11p Links are Used . . 6 79 4. Aspects introduced by the OCB mode to 802.11 . . . . . . . . 6 80 5. Layering of IPv6 over 802.11p as over Ethernet . . . . . . . 9 81 5.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 9 82 5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 10 83 5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 11 84 5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 13 85 5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 13 86 5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 13 87 5.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 13 88 5.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 14 89 5.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 15 90 6. Handovers between OCB links . . . . . . . . . . . . . . . . . 15 91 7. Example IPv6 Packet captured over a IEEE 802.11p link . . . . 17 92 7.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 18 93 7.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 21 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 96 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 97 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 100 12.2. Informative References . . . . . . . . . . . . . . . . . 26 101 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 30 102 Appendix B. Explicit Prohibition of IPv6 on Channels 103 Related to ITS Scenarios using 802.11p Networks 104 - an Analysis . . . . . . . . . . . . . . . . . . . 32 105 B.1. Interpretation of FCC and ETSI documents with 106 respect to running IP on particular channels . . . . . . 32 107 B.2. Interpretations of Latencies of IP datagrams . . . . . . 33 108 Appendix C. Changes Needed on a software driver 802.11a to 109 become a 802.11-OCB driver . . 33 110 Appendix D. Design Considerations . . . . . . . . . . . . . . . 34 111 D.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 35 112 D.2. Non IP Communications . . . . . . . . . . . . . . . . . . 35 113 D.3. Reliability Requirements . . . . . . . . . . . . . . . . 36 114 D.4. Privacy requirements . . . . . . . . . . . . . . . . . . 37 115 D.5. Authentication requirements . . . . . . . . . . . . . . . 38 116 D.6. Multiple interfaces . . . . . . . . . . . . . . . . . . . 38 117 D.7. MAC Address Generation . . . . . . . . . . . . . . . . . 39 118 D.8. Security Certificate Generation . . . . . . . . . . . . . 39 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 121 1. Introduction 123 This document describes the transmission of IPv6 packets on IEEE Std 124 802.11 OCB networks (earlier known as 802.11p). This involves the 125 layering of IPv6 networking on top of the IEEE 802.11 MAC layer (with 126 an LLC layer). Compared to running IPv6 over the Ethernet MAC layer, 127 there is no modification required to the standards: IPv6 works fine 128 directly over 802.11 OCB too (with an LLC layer). 130 The term "802.11p" is an earlier definition. As of year 2012, the 131 behaviour of "802.11p" networks has been rolled in the document IEEE 132 Std 802.11-2012. In this document the term 802.11p disappears. 133 Instead, each 802.11p feature is conditioned by a flag in the 134 Management Information Base. That flag is named "OCBActivated". 135 Whenever OCBActivated is set to true the feature it relates to 136 represents an earlier 802.11p feature. For example, an 802.11 137 STAtion operating outside the context of a basic service set has the 138 OCBActivated flag set. Such a station, when it has the flag set, it 139 uses a BSS identifier equal to ff:ff:ff:ff:ff:ff. 141 In the following text we use the term "802.11p" to mean 802.11-2012 142 OCB, and vice-versa. 144 As an overview, we illustrate how an IPv6 stack runs over 802.11p by 145 layering different protocols on top of each other. The IPv6 146 Networking is layered on top of the IEEE 802.2 Logical-Link Control 147 (LLC) layer; this is itself layered on top of the 802.11p MAC; this 148 layering illustration is similar to that of running IPv6 over 802.2 149 LLC over the 802.11 MAC, or over Ethernet MAC. 151 +-----------------+ +-----------------+ 152 | ... | | ... | 153 +-----------------+ +-----------------+ 154 | IPv6 Networking | | IPv6 Networking | 155 +-----------------+ +-----------------+ 156 | 802.2 LLC | vs. | 802.2 LLC | 157 +-----------------+ +-----------------+ 158 | 802.11p MAC | | 802.11b MAC | 159 +-----------------+ +-----------------+ 160 | 802.11p PHY | | 802.11b PHY | 161 +-----------------+ +-----------------+ 163 However, there are several deployment considerations to optimize the 164 performances of running IPv6 over 802.11p (e.g. in the case of 165 handovers between 802.11p Access Points, or the consideration of 166 using the IP security layer). 168 We briefly introduce the vehicular communication scenarios where IEEE 169 802.11-OCB links are used. This is followed by a description of 170 differences in specification terms, between 802.11p and 802.11a/b/g/n 171 (and the same differences expressed in terms of requirements to 172 software implementation are listed in Appendix C.) 174 The document then concentrates on the parameters of layering IP over 175 802.11p as over Ethernet: MTU, Frame Format, Interface Identifier, 176 Address Mapping, State-less Address Auto-configuration. The values 177 of these parameters are precisely the same as IPv6 over Ethernet 178 [RFC2464]: the recommended value of MTU to be 1500 octets, the Frame 179 Format containing the Type 0x86DD, the rules for forming an Interface 180 Identifier, the Address Mapping mechanism and the Stateless Address 181 Auto-Configuration. 183 As an example, these characteristics of layering IPv6 straight over 184 LLC over 802.11p MAC are illustrated by dissecting an IPv6 packet 185 captured over a 802.11p link; this is described in the section titled 186 "Example of IPv6 Packet captured over an IEEE 802.11p link". 188 A couple of points can be considered as different, although they are 189 not required in order to have a working implementation of IPv6-over- 190 802.11p. These points are consequences of the OCB operation which is 191 particular to 802.11p (Outside the Context of a BSS). First, the 192 handovers between OCB links need specific behaviour for IP Router 193 Advertisements, or otherwise 802.11p's Time Advertisement, or of 194 higher layer messages such as the 'Basic Safety Message' (in the US) 195 or the 'Cooperative Awareness Message' (in the EU) or the 'WAVE 196 Routing Advertisement'; second, the IP security mechanisms are 197 necessary, since OCB means that 802.11p is stripped of all 802.11 198 link-layer security; a small additional security aspect which is 199 shared between 802.11p and other 802.11 links is the privacy concerns 200 related to the address formation mechanisms. The OCB handovers and 201 security are described each in section Section 6 and Section 8 202 respectively. 204 In standards, the operation of IPv6 as a 'data plane' over 802.11p is 205 specified at IEEE P1609 in [ieeep1609.3-D9-2010]. For example, it 206 mentions that "Networking services also specifies the use of the 207 Internet protocol IPv6, and supports transport protocols such as UDP 208 and TCP. [...] A Networking Services implementation shall support 209 either IPv6 or WSMP or both." and "IP traffic is sent and received 210 through the LLC sublayer as specified in [...]". The layered stacks 211 depicted in the "Architecture" document P1609.0 [ieeep1609.0-D2] 212 suggest that WSMP messages may not be transmitted as payload of IPv6 213 datagrams; WSMP and IPv6 are parallel (not stacked) layers. 215 Also, the operation of IPv6 over a GeoNetworking layer and over G5 is 216 described in [etsi-302663-v1.2.1p-2013]. 218 In the published literature, three documents describe aspects related 219 to running IPv6 over 802.11p: [vip-wave], [ipv6-80211p-its] and 220 [ipv6-wave]. 222 2. Terminology 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in RFC 2119 [RFC2119]. 228 RSU: Road Side Unit. 230 OCB: Outside the Context of a Basic Service Set identifier. 232 OCB - Outside the Context of a Basic-Service Set ID (BSSID). 234 802.11-OCB - IEEE 802.11-2012 text flagged by "dot11OCBActivated". 235 This means: IEEE 802.11e for quality of service; 802.11j-2004 for 236 half-clocked operations; and 802.11p for operation in the 5.9 GHz 237 band and in mode OCB. 239 3. Communication Scenarios where IEEE 802.11p Links are Used 241 The IEEE 802.11p Networks are used for vehicular communications, as 242 'Wireless Access in Vehicular Environments'. The IP communication 243 scenarios for these environments have been described in several 244 documents, among which we refer the reader to one recently updated 245 [I-D.petrescu-its-scenarios-reqs], about scenarios and requirements 246 for IP in Intelligent Transportation Systems. 248 4. Aspects introduced by the OCB mode to 802.11 250 In the IEEE 802.11 OCB mode, all nodes in the wireless range can 251 directly communicate with each other without authentication/ 252 association procedures. Briefly, the IEEE 802.11 OCB mode has the 253 following properties: 255 o Wildcard BSSID (i.e., all bits are set to 1) used by each node 257 o No beacons transmitted 259 o No authentication required 261 o No association needed 263 o No encryption provided 265 o dot11OCBActivated OID set to true 267 The link 802.11p is specified in IEEE Std 802.11p(TM)-2010 268 [ieee802.11p-2010] as an amendment to the 802.11 specifications, 269 titled "Amendment 6: Wireless Access in Vehicular Environments". 270 Since then, these 802.11p amendments have been included in IEEE 271 802.11(TM)-2012 [ieee802.11-2012], titled "IEEE Standard for 272 Information technology--Telecommunications and information exchange 273 between systems Local and metropolitan area networks--Specific 274 requirements Part 11: Wireless LAN Medium Access Control (MAC) and 275 Physical Layer (PHY) Specifications"; the modifications are diffused 276 throughout various sections (e.g. 802.11p's Time Advertisement 277 message is described in section 'Frame formats', and the operation 278 outside the context of a BSS described in section 'MLME'). 280 In document 802.11-2012, specifically anything referring 281 "OCBActivated", or "outside the context of a basic service set" is 282 actually referring to the 802.11p aspects introduced to 802.11. Note 283 in earlier 802.11p documents the term "OCBEnabled" was used instead. 285 In order to delineate the aspects introduced by 802.11p to 802.11, we 286 refer to the earlier [ieee802.11p-2010]. The amendment is concerned 287 with vehicular communications, where the wireless link is similar to 288 that of Wireless LAN (using a PHY layer specified by 802.11a/b/g/n), 289 but which needs to cope with the high mobility factor inherent in 290 scenarios of communications between moving vehicles, and between 291 vehicles and fixed infrastructure deployed along roads. While 'p' is 292 a letter just like 'a, b, g' and 'n' are, 'p' is concerned more with 293 MAC modifications, and a little with PHY modifications; the others 294 are mainly about PHY modifications. It is possible in practice to 295 combine a 'p' MAC with an 'a' PHY by operating outside the context of 296 a BSS with OFDM at 5.4GHz. 298 The 802.11p links are specified to be compatible as much as possible 299 with the behaviour of 802.11a/b/g/n and future generation IEEE WLAN 300 links. From the IP perspective, an 802.11p MAC layer offers 301 practically the same interface to IP as the WiFi and Ethernet layers 302 do (802.11a/b/g/n and 802.3). 304 To support this similarity statement (IPv6 is layered on top of LLC 305 on top of 802.11p similarly as on top of LLC on top of 802.11a/b/g/n, 306 and as on top of LLC on top of 802.3) it is useful to analyze the 307 differences between 802.11p and non-p 802.11 specifications. Whereas 308 the 802.11p amendment specifies relatively complex and numerous 309 changes to the MAC layer (and very little to the PHY layer), we note 310 there are only a few characteristics which may be important for an 311 implementation transmitting IPv6 packets on 802.11p links. 313 In the list below, the only 802.11p fundamental points which 314 influence IPv6 are the OCB operation and the 12Mbit/s maximum which 315 may be afforded by the IPv6 applications. 317 o Operation Outside the Context of a BSS (OCB): the 802.11p links 318 are operated without a Basic Service Set (BSS). This means that 319 the messages Beacon, Association Request/Response, Authentication 320 Request/Response, and similar, are not used. The used identifier 321 of BSS (BSSID) has a hexadecimal value always ff:ff:ff:ff:ff:ff 322 (48 '1' bits, or the 'wildcard' BSSID), as opposed to an arbitrary 323 BSSID value set by administrator (e.g. 'My-Home-AccessPoint'). 324 The OCB operation - namely the lack of beacon-based scanning and 325 lack of authentication - has a potentially strong impact on the 326 use of the Mobile IPv6 protocol and on the protocols for IP layer 327 security. 329 o Timing Advertisement: is a new message defined in 802.11p, which 330 does not exist in 802.11a/b/g/n. This message is used by stations 331 to inform other stations about the value of time. It is similar 332 to the time as delivered by a GNSS system (Galileo, GPS, ...) or 333 by a cellular system. This message is optional for 334 implementation. At the date of writing, an experienced reviewer 335 considers that currently no field testing has used this message. 336 Another implementor considers this feature implemented in an 337 initial manner. In the future, it is speculated that this message 338 may be useful for very simple devices which may not have their own 339 hardware source of time (Galileo, GPS, cellular network), or by 340 vehicular devices situated in areas not covered by such network 341 (in tunnels, underground, outdoors but shaded by foliage or 342 buildings, in remote areas, etc.) 344 o Frequency range: this is a characteristic of the PHY layer, with 345 almost no impact to the interface between MAC and IP. However, it 346 is worth considering that the frequency range is regulated by a 347 regional authority (ARCEP, ETSI, FCC, etc.); as part of the 348 regulation process, specific applications are associated with 349 specific frequency ranges. In the case of 802.11p, the regulator 350 associates a set of frequency ranges, or slots within a band, to 351 the use of applications of vehicular communications, in a band 352 known as "5.9GHz". This band is "5.9GHz" which is different from 353 the bands "2.4GHz" or "5GHz" used by Wireless LAN. However, as 354 with Wireless LAN, the operation of 802.11p in "5.9GHz" bands is 355 exempt from owning a license in EU (in US the 5.9GHz is a licensed 356 band of spectrum; for the the fixed infrastructure an explicit FCC 357 autorization is required; for an onboard device a 'licensed-by- 358 rule' concept applies: rule certification conformity is required); 359 however technical conditions are different than those of the bands 360 "2.4GHz" or "5GHz". On one hand, the allowed power levels, and 361 implicitly the maximum allowed distance between vehicles, is of 362 33dBm for 802.11p (in Europe), compared to 20 dBm for Wireless LAN 363 802.11a/b/g/n; this leads to a maximum distance of approximately 364 1km, compared to approximately 50m. On the hand, specific 365 conditions related to congestion avoidance, jamming avoidance, and 366 radar detection are imposed on the use of DSRC (in US) and on the 367 use of frequencies for Intelligent Transportation Systems (in EU), 368 compared to Wireless LAN (802.11a/b/g/n). 370 o Explicit prohibition of IPv6 on some channels relevant for the PHY 371 of IEEE 802.11p, as opposed to IPv6 not being prohibited on any 372 channel on which 802.11a/b/g/n runs; for example, IPv6 is 373 prohibited on the 'Control Channel' (number 178 at FCC/IEEE, and 374 180 at ETSI); for a detailed analysis of IEEE and ETSI prohibition 375 of IP in particular channels see Appendix B. 377 o 'Half-rate' encoding: as the frequency range, this parameter is 378 related to PHY, and thus has not much impact on the interface 379 between the IP layer and the MAC layer. The standard IEEE 802.11p 380 uses OFDM encoding at PHY, as other non-b 802.11 variants do. 381 This considers 20MHz encoding to be 'full-rate' encoding, as the 382 earlier 20MHz encoding which is used extensively by 802.11b. In 383 addition to the full-rate encoding, the OFDM rates also involve 384 5MHz and 10MHz. The 10MHz encoding is named 'half-rate'. The 385 encoding dictates the bandwidth and latency characteristics that 386 can be afforded by the higher-layer applications of IP 387 communications. The half-rate means that each symbol takes twice 388 the time to be transmitted; for this to work, all 802.11 software 389 timer values are doubled. With this, in certain channels of the 390 "5.9GHz" band, a maximum bandwidth of 12Mbit/s is possible, 391 whereas in other "5.9GHz" channels a minimal bandwidth of 1Mbit/s 392 may be used. It is worth mentioning the half-rate encoding is an 393 optional feature characteristic of OFDM PHY (compared to 802.11b's 394 full-rate 20MHz), used by 802.11a before 802.11p used it. In 395 addition to the half-rate (10MHz) used by 802.11p in some 396 channels, some other 802.11p channels may use full-rate (20MHz) or 397 quarter-rate(?) (5MHz) encoding instead. 399 o It is worth mentioning that more precise interpretations of the 400 'half-rate' term suggest that a maximum throughput be 27Mbit/s 401 (which is half of 802.11g's 54Mbit/s), whereas 6Mbit/s or 12Mbit/s 402 throughputs represent effects of further 802.11p-specific PHY 403 reductions in the throughput necessary to better accommodate 404 vehicle-class speeds and distance ranges. 406 o In vehicular communications using 802.11p links, there are strong 407 privacy concerns with respect to addressing. While the 802.11p 408 standard does not specify anything in particular with respect to 409 MAC addresses, in these settings there exists a strong need for 410 dynamic change of these addresses (as opposed to the non-vehicular 411 settings - real wall protection - where fixed MAC addresses do not 412 currently pose some privacy risks). This is further described in 413 section Section 8. 415 Other aspects particular to 802.11p which are also particular to 416 802.11 (e.g. the 'hidden node' operation) may have an influence on 417 the use of transmission of IPv6 packets on 802.11p networks. The 418 subnet structure which may be assumed in 802.11p networks is strongly 419 influenced by the mobility of vehicles. 421 5. Layering of IPv6 over 802.11p as over Ethernet 423 5.1. Maximum Transmission Unit (MTU) 425 The default MTU for IP packets on 802.11p is 1500 octets. It is the 426 same value as IPv6 packets on Ethernet links, as specified in 427 [RFC2464]. This value of the MTU respects the recommendation that 428 every link in the Internet must have a minimum MTU of 1280 octets 429 (stated in [RFC2460], and the recommendations therein, especially 430 with respect to fragmentation). If IPv6 packets of size larger than 431 1500 bytes are sent on an 802.11-OCB interface then the IP stack will 432 fragment. In case there are IP fragments, the field "Sequence 433 number" of the 802.11 Data header containing the IP fragment field is 434 increased. 436 Non-IP packets such as WAVE Short Message Protocol (WSMP) can be 437 delivered on 802.11-OCB links. Specifications of these packets are 438 out of scope of this document, and do not impose any limit on the MTU 439 size, allowing an arbitrary number of 'containers'. Non-IP packets 440 such as ETSI 'geonet' packets have an MTU of 1492 bytes. 442 The Equivalent Transmit Time on Channel is a concept that may be used 443 as an alternative to the MTU concept. A rate of transmission may be 444 specified as well. The ETTC, rate and MTU may be in direct 445 relationship. 447 5.2. Frame Format 449 IP packets are transmitted over 802.11p as standard Ethernet packets. 450 As with all 802.11 frames, an Ethernet adaptation layer is used with 451 802.11p as well. This Ethernet Adaptation Layer 802.11-to-Ethernet 452 is described in Section 5.2.1. The Ethernet Type code (EtherType) 453 for IPv6 is 0x86DD (hexadecimal 86DD, or otherwise #86DD). 455 The Frame format for transmitting IPv6 on 802.11p networks is the 456 same as transmitting IPv6 on Ethernet networks, and is described in 457 section 3 of [RFC2464]. The frame format for transmitting IPv6 458 packets over Ethernet is illustrated below: 460 0 1 461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Destination | 464 +- -+ 465 | Ethernet | 466 +- -+ 467 | Address | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Source | 470 +- -+ 471 | Ethernet | 472 +- -+ 473 | Address | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 |1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1| 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | IPv6 | 478 +- -+ 479 | header | 480 +- -+ 481 | and | 482 +- -+ 483 / payload ... / 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 (Each tic mark represents one bit.) 487 5.2.1. Ethernet Adaptation Layer 489 In general, an 'adaptation' layer is inserted between a MAC layer and 490 the Networking layer. This is used to transform some parameters 491 between their form expected by the IP stack and the form provided by 492 the MAC layer. For example, an 802.15.4 adaptation layer may perform 493 fragmentation and reassembly operations on a MAC whose maximum Packet 494 Data Unit size is smaller than the minimum MTU recognized by the IPv6 495 Networking layer. Other examples involve link-layer address 496 transformation, packet header insertion/removal, and so on. 498 An Ethernet Adaptation Layer makes an 802.11 MAC look to IP 499 Networking layer as a more traditional Ethernet layer. At reception, 500 this layer takes as input the IEEE 802.11 Data Header and the 501 Logical-Link Layer Control Header and produces an Ethernet II Header. 502 At sending, the reverse operation is performed. 504 +--------------------+-------------+-------------+---------+ 505 | 802.11 Data Header | LLC Header | IPv6 Header | Payload | 506 +--------------------+-------------+-------------+---------+ 507 ^ 508 | 509 802.11-to-Ethernet Adaptation Layer 510 | 511 v 513 +---------------------+-------------+---------+ 514 | Ethernet II Header | IPv6 Header | Payload | 515 +---------------------+-------------+---------+ 517 The Receiver and Transmitter Address fields in the 802.11 Data Header 518 contain the same values as the Destination and the Source Address 519 fields in the Ethernet II Header, respectively. The value of the 520 Type field in the LLC Header is the same as the value of the Type 521 field in the Ethernet II Header. 523 When the MTU value is smaller than the size of the IP packet to be 524 sent, the IP layer fragments the packet into multiple IP fragments. 525 During this operation, the "Sequence number" field of the 802.11 Data 526 Header is increased. 528 In OCB mode, IPv6 packets can be transmitted either as "IEEE 802.11 529 Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in 530 the following figure: 532 +--------------------+-------------+-------------+---------+ 533 | 802.11 Data Header | LLC Header | IPv6 Header | Payload | 534 +--------------------+-------------+-------------+---------+ 536 or 538 +--------------------+-------------+-------------+---------+ 539 | 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload | 540 +--------------------+-------------+-------------+---------+ 542 The distinction between the two formats is given by the value of the 543 field "Type/Subtype". The value of the field "Type/Subtype" in the 544 802.11 Data header is 0x0020. The value of the field "Type/Subtype" 545 in the 802.11 QoS header is 0x0028. 547 The mapping between qos-related fields in the IPv6 header (e.g. 548 "Traffic Class", "Flow label") and fields in the "802.11 QoS Data 549 Header" (e.g. "QoS Control") are not specified in this document. 550 Guidance for a potential mapping is provided in 551 [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB 552 mode. 554 5.3. Link-Local Addresses 556 The link-local address of an 802.11p interface is formed in the same 557 manner as on an Ethernet interface. This manner is described in 558 section 5 of [RFC2464]. 560 5.4. Address Mapping 562 For unicast as for multicast, there is no change from the unicast and 563 multicast address mapping format of Ethernet interfaces, as defined 564 by sections 6 and 7 of [RFC2464]. 566 5.4.1. Address Mapping -- Unicast 568 5.4.2. Address Mapping -- Multicast 570 IPv6 protocols often make use of IPv6 multicast addresses in the 571 destination field of IPv6 headers. For example, an ICMPv6 link- 572 scoped Neighbor Advertisement is sent to the IPv6 address ff02::1 573 denoted "all-nodes" address. When transmitting these packets on 574 802.11-OCB links it is necessary to map the IPv6 address to a MAC 575 address. 577 The same mapping requirement applies to the link-scoped multicast 578 addresses of other IPv6 protocols as well. In DHCPv6, the 579 "All_DHCP_Servers" IPv6 multicast address ff02::1:2, and in OSPF the 580 "All_SPF_Routers" IPv6 multicast address ff02::5, need to be mapped 581 on a multicast MAC address. 583 An IPv6 packet with a multicast destination address DST, consisting 584 of the sixteen octets DST[1] through DST[16], is transmitted to the 585 IEEE 802.11-OCB MAC multicast address whose first two octets are the 586 value 0x3333 and whose last four octets are the last four octets of 587 DST. 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | DST[13] | DST[14] | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | DST[15] | DST[16] | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 A Group ID TBD of length 112bits may be requested from IANA; this 598 Group ID signifies "All 80211OCB Interfaces Address". Only the least 599 32 significant bits of this "All 80211OCB Interfaces Address" will be 600 mapped to and from a MAC multicast address. 602 Transmitting IPv6 packets to multicast destinations over 802.11 links 603 proved to have some performance issues 604 [I-D.perkins-intarea-multicast-ieee802]. These issues may be 605 exacerbated in OCB mode. Solutions for these problems should 606 consider the OCB mode of operation. 608 5.5. Stateless Autoconfiguration 610 The Interface Identifier for an 802.11p interface is formed using the 611 same rules as the Interface Identifier for an Ethernet interface; 612 this is described in section 4 of [RFC2464]. No changes are needed, 613 but some care must be taken when considering the use of the SLAAC 614 procedure. 616 The bits in the the interface identifier have no generic meaning and 617 the identifier should be treated as an opaque value. The bits 618 'Universal' and 'Group' in the identifier of an 802.11p interface are 619 significant, as this is a IEEE link-layer address. The details of 620 this significance are described in [I-D.ietf-6man-ug]. 622 As with all Ethernet and 802.11 interface identifiers ([RFC7721]), 623 the identifier of an 802.11p interface may involve privacy risks. A 624 vehicle embarking an On-Board Unit whose egress interface is 802.11p 625 may expose itself to eavesdropping and subsequent correlation of 626 data; this may reveal data considered private by the vehicle owner. 628 If stable Interface Identifiers are needed in order to form IPv6 629 addresses on 802.11-OCB links, it is recommended to follow the 630 recommendation in [I-D.ietf-6man-default-iids]. 632 5.6. Subnet Structure 634 The 802.11 networks in OCB mode may be considered as 'ad-hoc' 635 networks. The addressing model for such networks is described in 636 [RFC5889]. 638 6. Handovers between OCB links 640 A station operating IEEE 802.11p in the 5.9 GHz band in US or EU is 641 required to send data frames outside the context of a BSS. In this 642 case, the station does not utilize the IEEE 802.11 authentication, 643 association, or data confidentiality services. This avoids the 644 latency associated with establishing a BSS and is particularly suited 645 to communications between mobile stations or between a mobile station 646 and a fixed one playing the role of the default router (e.g. a fixed 647 Road-Side Unit a.k.a RSU acting as an infrastructure router). 649 The process of movement detection is described in section 11.5.1 of 650 [RFC6275]. In the context of 802.11p deployments, detecting 651 movements between two adjacent RSUs becomes harder for the moving 652 stations: they cannot rely on Layer-2 triggers (such as L2 653 association/de-association phases) to detect when they leave the 654 vicinity of an RSU and move within coverage of another RSU. In such 655 case, the movement detection algorithms require other triggers. We 656 detail below the potential other indications that can be used by a 657 moving station in order to detect handovers between OCB ("Outside the 658 Context of a BSS") links. 660 A movement detection mechanism may take advantage of positioning data 661 (latitude and longitude). 663 Mobile IPv6 [RFC6275] specifies a new Router Advertisement option 664 called the "Advertisement Interval Option". It can be used by an RSU 665 to indicate the maximum interval between two consecutive unsolicited 666 Router Advertisement messages sent by this RSU. With this option, a 667 moving station can learn when it is supposed to receive the next RA 668 from the same RSU. This can help movement detection: if the 669 specified amount of time elapses without the moving station receiving 670 any RA from that RSU, this means that the RA has been lost. It is up 671 to the moving node to determine how many lost RAs from that RSU 672 constitutes a handover trigger. 674 In addition to the Mobile IPv6 "Advertisement Interval Option", the 675 Neighbor Unreachability Detection (NUD) [RFC4861] can be used to 676 determine whether the RSU is still reachable or not. In this 677 context, reachability confirmation would basically consist in 678 receiving a Neighbor Advertisement message from a RSU, in response to 679 a Neighbor Solicitation message sent by the moving station. The RSU 680 should also configure a low Reachable Time value in its RA in order 681 to ensure that a moving station does not assume an RSU to be 682 reachable for too long. 684 The Mobile IPv6 "Advertisement Interval Option" as well as the NUD 685 procedure only help knowing if the RSU is still reachable by the 686 moving station. It does not provide the moving station with 687 information about other potential RSUs that might be in range. For 688 this purpose, it is by increasing the RA frequency that the delay 689 could be reduced to discover the next RSU. The Neighbor Discovery 690 protocol [RFC4861] limits the unsolicited multicast RA interval to a 691 minimum of 3 seconds (the MinRtrAdvInterval variable). This value is 692 too high for dense deployments of Access Routers deployed along fast 693 roads. The protocol Mobile IPv6 [RFC6275] allows routers to send 694 such RA more frequently, with a minimum possible of 0.03 seconds (the 695 same MinRtrAdvInterval variable): this should be preferred to ensure 696 a faster detection of the potential RSUs in range. 698 However, frequent RAs (every 0.03 seconds) may occupy the channel 699 with too many packets leading to other significant packets being 700 lost. There is a tradeoff to be established: the more frequent the 701 RAs the better handover performance but the more risks of packet 702 loss. 704 If multiple RSUs are in the vicinity of a moving station at the same 705 time, the station may not be able to choose the "best" one (i.e. the 706 one that would afford the moving station spending the longest time in 707 its vicinity, in order to avoid too frequent handovers). In this 708 case, it would be helpful to base the decision on the signal quality 709 (e.g. the RSSI of the received RA provided by the radio driver). A 710 better signal would probably offer a longer coverage. If, in terms 711 of RA frequency, it is not possible to adopt the recommendations of 712 protocol Mobile IPv6 (but only the Neighbor Discovery specification 713 ones, for whatever reason), then another message than the RA could be 714 emitted periodically by the Access Router (provided its specification 715 allows to send it very often), in order to help the Host determine 716 the signal quality. One such message may be the 802.11p's Time 717 Advertisement, or higher layer messages such as the "Basic Safety 718 Message" (in the US) or the "Cooperative Awareness Message " (in the 719 EU), that are usually sent several times per second. Another 720 alternative replacement for the IPv6 Router Advertisement may be the 721 message 'WAVE Routing Advertisement' (WRA), which is part of the WAVE 722 Service Advertisement and which may contain optionally the 723 transmitter location; this message is described in section 8.2.5 of 724 [ieeep1609.3-D9-2010]. 726 Once the choice of the default router has been performed by the 727 moving node, it can be interesting to use Optimistic DAD [RFC4429] in 728 order to speed-up the address auto-configuration and ensure the 729 fastest possible Layer-3 handover. 731 To summarize, efficient handovers between OCB links can be performed 732 by using a combination of existing mechanisms. In order to improve 733 the default router unreachability detection, the RSU and moving 734 stations should use the Mobile IPv6 "Advertisement Interval Option" 735 as well as rely on the NUD mechanism. In order to allow the moving 736 station to detect potential default router faster, the RSU should 737 also be able to be configured with a smaller minimum RA interval such 738 as the one recommended by Mobile IPv6. When multiple RSUs are 739 available at the same time, the moving station should perform the 740 handover decision based on the signal quality. Finally, optimistic 741 DAD can be used to reduce the handover delay. 743 The Received Frame Power Level (RCPI) defined in IEEE Std 744 802.11-2012, conditioned by the dotOCBActived flag, is an information 745 element which contains a value expressing the power level at which 746 that frame was received. This value may be used in comparing power 747 levels when triggering IP handovers. 749 7. Example IPv6 Packet captured over a IEEE 802.11p link 751 We remind that a main goal of this document is to make the case that 752 IPv6 works fine over 802.11p networks. Consequently, this section is 753 an illustration of this concept and thus can help the implementer 754 when it comes to running IPv6 over IEEE 802.11p. By way of example 755 we show that there is no modification in the headers when transmitted 756 over 802.11p networks - they are transmitted like any other 802.11 757 and Ethernet packets. 759 We describe an experiment of capturing an IPv6 packet captured on an 760 802.11p link. In this experiment, the packet is an IPv6 Router 761 Advertisement. This packet is emitted by a Router on its 802.11p 762 interface. The packet is captured on the Host, using a network 763 protocol analyzer (e.g. Wireshark); the capture is performed in two 764 different modes: direct mode and 'monitor' mode. The topology used 765 during the capture is depicted below. 767 +--------+ +-------+ 768 | | 802.11-OCB Link | | 769 ---| Router |--------------------------------| Host | 770 | | | | 771 +--------+ +-------+ 773 During several capture operations running from a few moments to 774 several hours, no message relevant to the BSSID contexts were 775 captured (no Association Request/Response, Authentication Req/Resp, 776 Beacon). This shows that the operation of 802.11p is outside the 777 context of a BSSID. 779 Overall, the captured message is identical with a capture of an IPv6 780 packet emitted on a 802.11b interface. The contents are precisely 781 similar. 783 The popular wireshark network protocol analyzer is a free software 784 tool for Windows and Unix. It includes a dissector for 802.11p 785 features along with all other 802.11 features (i.e. it displays these 786 features in a human-readable format). 788 7.1. Capture in Monitor Mode 790 The IPv6 RA packet captured in monitor mode is illustrated below. 791 The radio tap header provides more flexibility for reporting the 792 characteristics of frames. The Radiotap Header is prepended by this 793 particular stack and operating system on the Host machine to the RA 794 packet received from the network (the Radiotap Header is not present 795 on the air). The implementation-dependent Radiotap Header is useful 796 for piggybacking PHY information from the chip's registers as data in 797 a packet understandable by userland applications using Socket 798 interfaces (the PHY interface can be, for example: power levels, data 799 rate, ratio of signal to noise). 801 The packet present on the air is formed by IEEE 802.11 Data Header, 802 Logical Link Control Header, IPv6 Base Header and ICMPv6 Header. 804 Radiotap Header v0 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 |Header Revision| Header Pad | Header length | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Present flags | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Data Rate | Pad | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 IEEE 802.11 Data Header 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Type/Subtype and Frame Ctrl | Duration | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Receiver Address... 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 ... Receiver Address | Transmitter Address... 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 ... Transmitter Address | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | BSS Id... 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 ... BSS Id | Frag Number and Seq Number | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 Logical-Link Control Header 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | DSAP |I| SSAP |C| Control field | Org. code... 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 ... Organizational Code | Type | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 IPv6 Base Header 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 |Version| Traffic Class | Flow Label | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Payload Length | Next Header | Hop Limit | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | | 842 + + 843 | | 844 + Source Address + 845 | | 846 + + 847 | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | | 850 + + 851 | | 852 + Destination Address + 853 | | 854 + + 855 | | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 Router Advertisement 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Type | Code | Checksum | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Reachable Time | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Retrans Timer | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Options ... 869 +-+-+-+-+-+-+-+-+-+-+-+- 871 The value of the Data Rate field in the Radiotap header is set to 6 872 Mb/s. This indicates the rate at which this RA was received. 874 The value of the Transmitter address in the IEEE 802.11 Data Header 875 is set to a 48bit value. The value of the destination address is 876 33:33:00:00:00:1 (all-nodes multicast address). The value of the BSS 877 Id field is ff:ff:ff:ff:ff:ff, which is recognized by the network 878 protocol analyzer as being "broadcast". The Fragment number and 879 sequence number fields are together set to 0x90C6. 881 The value of the Organization Code field in the Logical-Link Control 882 Header is set to 0x0, recognized as "Encapsulated Ethernet". The 883 value of the Type field is 0x86DD (hexadecimal 86DD, or otherwise 884 #86DD), recognized as "IPv6". 886 A Router Advertisement is periodically sent by the router to 887 multicast group address ff02::1. It is an icmp packet type 134. The 888 IPv6 Neighbor Discovery's Router Advertisement message contains an 889 8-bit field reserved for single-bit flags, as described in [RFC4861]. 891 The IPv6 header contains the link local address of the router 892 (source) configured via EUI-64 algorithm, and destination address set 893 to ff02::1. Recent versions of network protocol analyzers (e.g. 894 Wireshark) provide additional informations for an IP address, if a 895 geolocalization database is present. In this example, the 896 geolocalization database is absent, and the "GeoIP" information is 897 set to unknown for both source and destination addresses (although 898 the IPv6 source and destination addresses are set to useful values). 899 This "GeoIP" can be a useful information to look up the city, 900 country, AS number, and other information for an IP address. 902 The Ethernet Type field in the logical-link control header is set to 903 0x86dd which indicates that the frame transports an IPv6 packet. In 904 the IEEE 802.11 data, the destination address is 33:33:00:00:00:01 905 which is he corresponding multicast MAC address. The BSS id is a 906 broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link 907 duration between vehicles and the roadside infrastructure, there is 908 no need in IEEE 802.11p to wait for the completion of association and 909 authentication procedures before exchanging data. IEEE 802.11p 910 enabled nodes use the wildcard BSSID (a value of all 1s) and may 911 start communicating as soon as they arrive on the communication 912 channel. 914 7.2. Capture in Normal Mode 916 The same IPv6 Router Advertisement packet described above (monitor 917 mode) is captured on the Host, in the Normal mode, and depicted 918 below. 920 Ethernet II Header 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Destination... 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 ...Destination | Source... 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 ...Source | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Type | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 IPv6 Base Header 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 |Version| Traffic Class | Flow Label | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Payload Length | Next Header | Hop Limit | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | | 938 + + 939 | | 940 + Source Address + 941 | | 942 + + 943 | | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | | 946 + + 947 | | 948 + Destination Address + 949 | | 950 + + 951 | | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 Router Advertisement 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Type | Code | Checksum | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Reachable Time | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Retrans Timer | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Options ... 965 +-+-+-+-+-+-+-+-+-+-+-+- 967 One notices that the Radiotap Header is not prepended, and that the 968 IEEE 802.11 Data Header and the Logical-Link Control Headers are not 969 present. On another hand, a new header named Ethernet II Header is 970 present. 972 The Destination and Source addresses in the Ethernet II header 973 contain the same values as the fields Receiver Address and 974 Transmitter Address present in the IEEE 802.11 Data Header in the 975 "monitor" mode capture. 977 The value of the Type field in the Ethernet II header is 0x86DD 978 (recognized as "IPv6"); this value is the same value as the value of 979 the field Type in the Logical-Link Control Header in the "monitor" 980 mode capture. 982 The knowledgeable experimenter will no doubt notice the similarity of 983 this Ethernet II Header with a capture in normal mode on a pure 984 Ethernet cable interface. 986 It may be interpreted that an Adaptation layer is inserted in a pure 987 IEEE 802.11 MAC packets in the air, before delivering to the 988 applications. In detail, this adaptation layer may consist in 989 elimination of the Radiotap, 802.11 and LLC headers and insertion of 990 the Ethernet II header. In this way, it can be stated that IPv6 runs 991 naturally straight over LLC over the 802.11p MAC layer, as shown by 992 the use of the Type 0x86DD, and assuming an adaptation layer 993 (adapting 802.11 LLC/MAC to Ethernet II header). 995 8. Security Considerations 997 802.11p does not provide any cryptographic protection, because it 998 operates outside the context of a BSS (no Association Request/ 999 Response, no Challenge messages). Any attacker can therefore just 1000 sit in the near range of vehicles, sniff the network (just set the 1001 interface card's frequency to the proper range) and perform attacks 1002 without needing to physically break any wall. Such a link is way 1003 less protected than commonly used links (wired link or protected 1004 802.11). 1006 At the IP layer, IPsec can be used to protect unicast communications, 1007 and SeND can be used for multicast communications. If no protection 1008 is used by the IP layer, upper layers should be protected. 1009 Otherwise, the end-user or system should be warned about the risks 1010 they run. 1012 The WAVE protocol stack provides for strong security when using the 1013 WAVE Short Message Protocol and the WAVE Service Advertisement 1014 [ieeep1609.2-D17]. 1016 As with all Ethernet and 802.11 interface identifiers, there may 1017 exist privacy risks in the use of 802.11p interface identifiers. 1018 However, in outdoors vehicular settings, the privacy risks are more 1019 important than in indoors settings. New risks are induced by the 1020 possibility of attacker sniffers deployed along routes which listen 1021 for IP packets of vehicles passing by. For this reason, in the 1022 802.11p deployments, there is a strong necessity to use protection 1023 tools such as dynamically changing MAC addresses. This may help 1024 mitigate privacy risks to a certain level. On another hand, it may 1025 have an impact in the way typical IPv6 address auto-configuration is 1026 performed for vehicles (SLAAC would rely on MAC addresses amd would 1027 hence dynamically change the affected IP address), in the way the 1028 IPv6 Privacy addresses were used, and other effects. 1030 9. IANA Considerations 1032 10. Contributors 1034 Romain Kuntz contributed extensively the concepts described in 1035 Section 6 about IPv6 handovers between links running outside the 1036 context of a BSS (802.11p links). 1038 Tim Leinmueller contributed the idea of the use of IPv6 over 1039 802.11-OCB for distribution of certificates. 1041 Marios Makassikis, Jose Santa Lozano, Albin Severinson and Alexey 1042 Voronov provided significant feedback on the experience of using IP 1043 messages over 802.11-OCB in initial trials. 1045 Michelle Wetterwald contributed extensively the MTU discussion 1046 offering the ETSI ITS perspective, as well as other parts of the 1047 document. 1049 11. Acknowledgements 1051 The authors would like to thank Witold Klaudel, Ryuji Wakikawa, 1052 Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan 1053 Romascanu, Konstantin Khait, Ralph Droms, Richard Roy, Ray Hunter, 1054 Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, Dino 1055 Farinacci, Vincent Park, Jaehoon Paul Jeong and Gloria Gwynne. Their 1056 valuable comments clarified certain issues and generally helped to 1057 improve the document. 1059 Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB 1060 drivers for linux and described how. 1062 For the multicast discussion, the authors would like to thank Owen 1063 DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and 1064 participants to discussions in network working groups. 1066 The authours would like to thank participants to the Birds-of- 1067 a-Feather "Intelligent Transportation Systems" meetings held at IETF 1068 in 2016. 1070 12. References 1072 12.1. Normative References 1074 [I-D.ietf-6man-default-iids] 1075 Gont, F., Cooper, A., Thaler, D., and S. LIU, 1076 "Recommendation on Stable IPv6 Interface Identifiers", 1077 draft-ietf-6man-default-iids-16 (work in progress), 1078 September 2016. 1080 [I-D.ietf-6man-ug] 1081 Carpenter, B. and S. Jiang, "Significance of IPv6 1082 Interface Identifiers", draft-ietf-6man-ug-06 (work in 1083 progress), December 2013. 1085 [I-D.ietf-tsvwg-ieee-802-11] 1086 Szigeti, T. and F. Baker, "DiffServ to IEEE 802.11 1087 Mapping", draft-ietf-tsvwg-ieee-802-11-01 (work in 1088 progress), November 2016. 1090 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1091 Requirement Levels", BCP 14, RFC 2119, 1092 DOI 10.17487/RFC2119, March 1997, 1093 . 1095 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1096 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1097 December 1998, . 1099 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1100 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1101 . 1103 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1104 "Randomness Requirements for Security", BCP 106, RFC 4086, 1105 DOI 10.17487/RFC4086, June 2005, 1106 . 1108 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1109 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 1110 . 1112 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1113 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1114 DOI 10.17487/RFC4861, September 2007, 1115 . 1117 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 1118 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 1119 September 2010, . 1121 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1122 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1123 2011, . 1125 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1126 Bormann, "Neighbor Discovery Optimization for IPv6 over 1127 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1128 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1129 . 1131 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1132 Considerations for IPv6 Address Generation Mechanisms", 1133 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1134 . 1136 12.2. Informative References 1138 [etsi-302663-v1.2.1p-2013] 1139 "Intelligent Transport Systems (ITS); Access layer 1140 specification for Intelligent Transport Systems operating 1141 in the 5 GHz frequency band, 2013-07, document 1142 en_302663v010201p.pdf, document freely available at URL 1143 http://www.etsi.org/deliver/etsi_en/302600_302699/302663/ 1144 01.02.01_60/en_302663v010201p.pdf downloaded on October 1145 17th, 2013.". 1147 [etsi-draft-102492-2-v1.1.1-2006] 1148 "Electromagnetic compatibility and Radio spectrum Matters 1149 (ERM); Intelligent Transport Systems (ITS); Part 2: 1150 Technical characteristics for pan European harmonized 1151 communications equipment operating in the 5 GHz frequency 1152 range intended for road safety and traffic management, and 1153 for non-safety related ITS applications; System Reference 1154 Document, Draft ETSI TR 102 492-2 V1.1.1, 2006-07, 1155 document tr_10249202v010101p.pdf freely available at URL 1156 http://www.etsi.org/deliver/etsi_tr/102400_102499/ 1157 10249202/01.01.01_60/tr_10249202v010101p.pdf downloaded on 1158 October 18th, 2013.". 1160 [fcc-cc] "'Report and Order, Before the Federal Communications 1161 Commission Washington, D.C. 20554', FCC 03-324, Released 1162 on February 10, 2004, document FCC-03-324A1.pdf, document 1163 freely available at URL 1164 http://www.its.dot.gov/exit/fcc_edocs.htm downloaded on 1165 October 17th, 2013.". 1167 [fcc-cc-172-184] 1168 "'Memorandum Opinion and Order, Before the Federal 1169 Communications Commission Washington, D.C. 20554', FCC 1170 06-10, Released on July 26, 2006, document FCC- 1171 06-110A1.pdf, document freely available at URL 1172 http://hraunfoss.fcc.gov/edocs_public/attachmatch/ 1173 FCC-06-110A1.pdf downloaded on June 5th, 2014.". 1175 [I-D.baccelli-multi-hop-wireless-communication] 1176 Baccelli, E. and C. Perkins, "Multi-hop Ad Hoc Wireless 1177 Communication", draft-baccelli-multi-hop-wireless- 1178 communication-06 (work in progress), July 2011. 1180 [I-D.perkins-intarea-multicast-ieee802] 1181 Perkins, C., Stanley, D., Kumari, W., and J. Zuniga, 1182 "Multicast Considerations over IEEE 802 Wireless Media", 1183 draft-perkins-intarea-multicast-ieee802-01 (work in 1184 progress), September 2016. 1186 [I-D.petrescu-its-scenarios-reqs] 1187 Petrescu, A., Janneteau, C., Boc, M., and W. Klaudel, 1188 "Scenarios and Requirements for IP in Intelligent 1189 Transportation Systems", draft-petrescu-its-scenarios- 1190 reqs-03 (work in progress), October 2013. 1192 [ieee16094] 1193 "1609.2-2016 - IEEE Standard for Wireless Access in 1194 Vehicular Environments--Security Services for Applications 1195 and Management Messages; document freely available at URL 1196 https://standards.ieee.org/findstds/ 1197 standard/1609.2-2016.html retrieved on July 08th, 2016.". 1199 [ieee802.11-2012] 1200 "802.11-2012 - IEEE Standard for Information technology-- 1201 Telecommunications and information exchange between 1202 systems Local and metropolitan area networks--Specific 1203 requirements Part 11: Wireless LAN Medium Access Control 1204 (MAC) and Physical Layer (PHY) Specifications. Downloaded 1205 on October 17th, 2013, from IEEE Standards, document 1206 freely available at URL 1207 http://standards.ieee.org/findstds/ 1208 standard/802.11-2012.html retrieved on October 17th, 1209 2013.". 1211 [ieee802.11p-2010] 1212 "IEEE Std 802.11p(TM)-2010, IEEE Standard for Information 1213 Technology - Telecommunications and information exchange 1214 between systems - Local and metropolitan area networks - 1215 Specific requirements, Part 11: Wireless LAN Medium Access 1216 Control (MAC) and Physical Layer (PHY) Specifications, 1217 Amendment 6: Wireless Access in Vehicular Environments; 1218 document freely available at URL 1219 http://standards.ieee.org/getieee802/ 1220 download/802.11p-2010.pdf retrieved on September 20th, 1221 2013.". 1223 [ieeep1609.0-D2] 1224 "IEEE P1609.0/D2 Draft Guide for Wireless Access in 1225 Vehicular Environments (WAVE) Architecture. pdf, length 1226 879 Kb. Restrictions apply.". 1228 [ieeep1609.2-D17] 1229 "IEEE P1609.2(tm)/D17 Draft Standard for Wireless Access 1230 in Vehicular Environments - Security Services for 1231 Applications and Management Messages. pdf, length 2558 1232 Kb. Restrictions apply.". 1234 [ieeep1609.3-D9-2010] 1235 "IEEE P1609.3(tm)/D9, Draft Standard for Wireless Access 1236 in Vehicular Environments (WAVE) - Networking Services, 1237 August 2010. Authorized licensed use limited to: CEA. 1238 Downloaded on June 19, 2013 at 07:32:34 UTC from IEEE 1239 Xplore. Restrictions apply, document at persistent link 1240 http://ieeexplore.ieee.org/servlet/opac?punumber=5562705". 1242 [ieeep1609.4-D9-2010] 1243 "IEEE P1609.4(tm)/D9 Draft Standard for Wireless Access in 1244 Vehicular Environments (WAVE) - Multi-channel Operation. 1245 Authorized licensed use limited to: CEA. Downloaded on 1246 June 19, 2013 at 07:34:48 UTC from IEEE Xplore. 1247 Restrictions apply. Document at persistent link 1248 http://ieeexplore.ieee.org/servlet/opac?punumber=5551097". 1250 [ipv6-80211p-its] 1251 Shagdar, O., Tsukada, M., Kakiuchi, M., Toukabri, T., and 1252 T. Ernst, "Experimentation Towards IPv6 over IEEE 802.11p 1253 with ITS Station Architecture", International Workshop on 1254 IPv6-based Vehicular Networks, (colocated with IEEE 1255 Intelligent Vehicles Symposium), URL: 1256 http://hal.inria.fr/hal-00702923/en, Downloaded on: 24 1257 October 2013, Availability: free at some sites, paying at 1258 others, May 2012. 1260 [ipv6-wave] 1261 Clausen, T., Baccelli, E., and R. Wakikawa, "IPv6 1262 Operation for WAVE - Wireless Access in Vehicular 1263 Environments", Rapport de Recherche INRIA, number 7383, 1264 URL: http://hal.inria.fr/inria-00517909/, Downloaded on: 1265 24 October 2013, Availability: free at some sites, 1266 September 2010. 1268 [TS103097] 1269 "Intelligent Transport Systems (ITS); Security; Security 1270 header and certificate formats; document freely available 1271 at URL http://www.etsi.org/deliver/ 1272 etsi_ts/103000_103099/103097/01.01.01_60/ 1273 ts_103097v010101p.pdf retrieved on July 08th, 2016.". 1275 [vip-wave] 1276 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1277 Feasibility of IP Communications in 802.11p Vehicular 1278 Networks", IEEE Transactions on Intelligent Transportation 1279 Systems, Volume 14, Issue 1, URL and Digital Object 1280 Identifier: http://dx.doi.org/10.1109/TITS.2012.2206387, 1281 Downloaded on: 24 October 2013, Availability: free at 1282 some sites, paying at others, March 2013. 1284 Appendix A. ChangeLog 1286 The changes are listed in reverse chronological order, most recent 1287 changes appearing at the top of the list. 1289 From draft-petrescu-ipv6-over-80211p-05.txt to draft-petrescu-ipv6- 1290 over-80211p-06.txt: 1292 o Removed IPv4 text. 1294 o Added text about isues with multicast over 802.11 and OCB mode. 1296 o Shortened the subnet structure section, by referring to an 1297 existing RFC. 1299 o Removed the appendix about distribution of certificates. 1301 o Added text about tradeoff of too frequent RAs, handover 1302 performance and risks of packet loss. 1304 o Removed discussion about other MTU possibilities, kept only the 1305 1500 bytes MTU. 1307 o Keep both header "802.11 Data" and header "802.11 QoS Data". 1309 o Referred to default-iids recommendation of generating stable IIDs. 1311 o Moved the Design Considerations sections to an appendix. 1313 From draft-petrescu-ipv6-over-80211p-02.txt to draft-petrescu-ipv6- 1314 over-80211p-03.txt: 1316 o Added clarification about the "OCBActivated" qualifier in the the 1317 new IEEE 802.11-2012 document; this IEEE document integrates now 1318 all earlier 802.11p features; this also signifies the 1319 dissapearance of an IEEE IEEE 802.11p document altogether. 1321 o Added explanation about FCC not prohibiting IP on channels, and 1322 comments about engineering advice and reliability of IP messages. 1324 o Added possibility to use 6lowpan adaptation layer when in OCB 1325 mode. 1327 o Added appendix about the distribution of certificates to vehicles 1328 by using IPv6-over-802.11p single-hop communications. 1330 o Refined the explanation of 'half-rate' mode. 1332 o Added the privacy concerns and necessity of and potential effects 1333 of dynamically changing MAC addresses. 1335 From draft-petrescu-ipv6-over-80211p-01.txt to draft-petrescu-ipv6- 1336 over-80211p-02.txt: 1338 o updated authorship. 1340 o added explanation about FCC not prohibiting IP on channels, and 1341 comments about engineering advice and reliability of IP messages. 1343 o added possibility to use 6lowpan adaptation layer when in OCB 1344 mode. 1346 o added appendix about the distribution of certificates to vehicles 1347 by using IPv6-over-802.11p single-hop communications. 1349 o refined the explanation of 'half-rate' mode. 1351 o added the privacy concerns and necessity of and potential effects 1352 of dynamically changing MAC addresses. 1354 From draft-petrescu-ipv6-over-80211p-00.txt to draft-petrescu-ipv6- 1355 over-80211p-01.txt: 1357 o updated one author's affiliation detail. 1359 o added 2 more references to published literature about IPv6 over 1360 802.11p. 1362 From draft-petrescu-ipv6-over-80211p-00.txt to draft-petrescu-ipv6- 1363 over-80211p-00.txt: 1365 o first version. 1367 Appendix B. Explicit Prohibition of IPv6 on Channels Related to ITS 1368 Scenarios using 802.11p Networks - an Analysis 1370 B.1. Interpretation of FCC and ETSI documents with respect to running 1371 IP on particular channels 1373 o The FCC created the term "Control Channel" [fcc-cc]. For it, it 1374 defines the channel number to be 178 decimal, and positions it 1375 with a 10MHz width from 5885MHz to 5895MHz. The FCC rules point 1376 to standards document ASTM-E2213 (not freely available at the time 1377 of writing of this draft); in an interpretation of a reviewer of 1378 this document, this means not making any restrictions to the use 1379 of IP on the control channel. 1381 o The FCC created two more terms for particular channels 1382 [fcc-cc-172-184], among others. The channel 172 (5855MHz to 1383 5865MHz)) is designated "exclusively for [V2V] safety 1384 communications for accident avoidance and mitigation, and safety 1385 of life and property applications", and the channel 184 (5915MHz 1386 to 5925MHz) is designated "exclusively for high-power, longer- 1387 distance communications to be used for public-safety applications 1388 involving safety of life and property, including road-intersection 1389 collision mitigation". However, they are not named "control" 1390 channels, and the document does not mention any particular 1391 restriction on the use of IP on either of these channels. 1393 o On another hand, at IEEE, IPv6 is explicitely prohibited on 1394 channel number 178 decimal - the FCC's 'Control Channel'. The 1395 document [ieeep1609.4-D9-2010] prohibits upfront the use of IPv6 1396 traffic on the Control Channel: 'data frames containing IP 1397 datagrams are only allowed on service channels'. Other 'Service 1398 Channels' are allowed to use IP, but the Control Channel is not. 1400 o In Europe, basically ETSI considers FCC's "Control Channel" to be 1401 a "Service Channel", and defines a "Control Channel" to be in a 1402 slot considered by FCC as a "Service Channel". In detail, FCC's 1403 "Control Channel" number 178 decimal with 10MHz width (5885MHz to 1404 5895MHz) is defined by ETSI to be a "Service Channel", and is 1405 named 'G5-SCH2' [etsi-302663-v1.2.1p-2013]. This channel is 1406 dedicated to 'ITS Road Safety' by ETSI. Other channels are 1407 dedicated to 'ITS road traffic efficiency' by ETSI. The ETSI's 1408 "Control Channel" - the "G5-CCH" - number 180 decimal (not 178) is 1409 reserved as a 10MHz-width centered on 5900MHz (5895MHz to 5905MHz) 1410 (the 5895MHz-5905MHz channel is a Service Channel for FCC). 1411 Compared to IEEE, ETSI makes no upfront statement with respect to 1412 IP and particular channels; yet it relates the 'In car Internet' 1413 applications ('When nearby a stationary public internet access 1414 point (hotspot), application can use standard IP services for 1415 applications.') to the 'Non-safety-related ITS application' 1416 [etsi-draft-102492-2-v1.1.1-2006]. Under an interpretation of an 1417 author of this Internet Draft, this may mean ETSI may forbid IP on 1418 the 'ITS Road Safety' channels, but may allow IP on 'ITS road 1419 traffic efficiency' channels, or on other 5GHz channels re-used 1420 from BRAN (also dedicated to Broadband Radio Access Networks). 1422 o At EU level in ETSI (but not some countries in EU with varying 1423 adoption levels) the highest power of transmission of 33 dBm is 1424 allowed, but only on two separate 10Mhz-width channels centered on 1425 5900MHz and 5880MHz respectively. It may be that IPv6 is not 1426 allowed on these channels (in the other 'ITS' channels where IP 1427 may be allowed, the levels vary between 20dBm, 23 dBm and 30 dBm; 1428 in some of these channels IP is allowed). A high-power of 1429 transmission means that vehicles may be distanced more 1430 (intuitively, for 33 dBm approximately 2km is possible, and for 20 1431 dBm approximately 50meter). 1433 B.2. Interpretations of Latencies of IP datagrams 1435 IPv6 may be "allowed" on any channel. Certain interpretations 1436 consider that communicating IP datagrams may involve longer latencies 1437 than non-IP datagrams; this may make them little adapted for safety 1438 applications which require fast reaction. Certain other views 1439 disagree with this, arguing that IP datagrams are transmitted at the 1440 same speed as any other non-IP datagram and may thus offer same level 1441 of reactivity for safety applications. 1443 Appendix C. Changes Needed on a software driver 802.11a to become a 1444 802.11-OCB driver 1446 The 802.11p amendment modifies both the 802.11 stack's physical and 1447 MAC layers but all the induced modifications can be quite easily 1448 obtained by modifying an existing 802.11a ad-hoc stack. 1450 Conditions for a 802.11a hardware to be 802.11p compliant: 1452 o The chip must support the frequency bands on which the regulator 1453 recommends the use of ITS communications, for example using IEEE 1454 802.11p layer, in France: 5875MHz to 5925MHz. 1456 o The chip must support the half-rate mode (the internal clock 1457 should be able to be divided by two). 1459 o The chip transmit spectrum mask must be compliant to the "Transmit 1460 spectrum mask" from the IEEE 802.11p amendment (but experimental 1461 environments tolerate otherwise). 1463 o The chip should be able to transmit up to 44.8 dBm when used by 1464 the US government in the United States, and up to 33 dBm in 1465 Europe; other regional conditions apply. 1467 Changes needed on the network stack in OCB mode: 1469 o Physical layer: 1471 * The chip must use the Orthogonal Frequency Multiple Access 1472 (OFDM) encoding mode. 1474 * The chip must be set in half-mode rate mode (the internal clock 1475 frequency is divided by two). 1477 * The chip must use dedicated channels and should allow the use 1478 of higher emission powers. This may require modifications to 1479 the regulatory domains rules, if used by the kernel to enforce 1480 local specific restrictions. Such modifications must respect 1481 the location-specific laws. 1483 MAC layer: 1485 * All management frames (beacons, join, leave, and others) 1486 emission and reception must be disabled except for frames of 1487 subtype Action and Timing Advertisement (defined below). 1489 * No encryption key or method must be used. 1491 * Packet emission and reception must be performed as in ad-hoc 1492 mode, using the wildcard BSSID (ff:ff:ff:ff:ff:ff). 1494 * The functions related to joining a BSS (Association Request/ 1495 Response) and for authentication (Authentication Request/Reply, 1496 Challenge) are not called. 1498 * The beacon interval is always set to 0 (zero). 1500 * Timing Advertisement frames, defined in the amendment, should 1501 be supported. The upper layer should be able to trigger such 1502 frames emission and to retrieve information contained in 1503 received Timing Advertisements. 1505 Appendix D. Design Considerations 1507 The networks defined by 802.11-OCB are in many ways similar to other 1508 networks of the 802.11 family. In theory, the encapsulation of IPv6 1509 over 802.11-OCB could be very similar to the operation of IPv6 over 1510 other networks of the 802.11 family. However, the high mobility, 1511 strong link asymetry and very short connection makes the 802.11-OCB 1512 link significantly different from other 802.11 networks. Also, the 1513 automotive applications have specific requirements for reliability, 1514 security and privacy, which further add to the particularity of the 1515 802.11-OCB link. 1517 This section does not address safety-related applications, which are 1518 done on non-IP communications. However, this section will consider 1519 the transmission of such non IP communication in the design 1520 specification of IPv6 over IEEE 802.11-OCB. 1522 D.1. Vehicle ID 1524 Automotive networks require the unique representation of each of 1525 their node. Accordingly, a vehicle must be identified by at least 1526 one unique ID. The current specification at ETSI and at IEEE 1609 1527 identifies a vehicle by its MAC address uniquely obtained from the 1528 802.11-OCB NIC. 1530 A MAC address uniquely obtained from a IEEE 802.11-OCB NIC 1531 implicitely generates multiple vehicle IDs in case of multiple 1532 802.11-OCB NICs. A mechanims to uniquely identify a vehicle 1533 irrespectively to the different NICs and/or technologies is required. 1535 D.2. Non IP Communications 1537 In IEEE 1609 and ETSI ITS, safety-related communications CANNOT be 1538 used with IP datagrams. For example, Basic Safety Message (BSM, an 1539 IEEE 1609 datagram) and Cooperative Awareness Message (CAM, an ETSI 1540 ITS-G5 datagram), are each transmitted as a payload that is preceded 1541 by link-layer headers, without an IP header. 1543 Each vehicle taking part of traffic (i.e. having its engine turned on 1544 and being located on a road) MUST use Non IP communication to 1545 periodically broadcast its status information (ID, GPS position, 1546 speed,..) in its immediate neighborhood. Using these mechanisms, 1547 vehicles become 'aware' of the presence of other vehicles in their 1548 immediate vicinity. Therefore, IP communication being transmitted by 1549 vehicles taking part of traffic MUST co-exist with Non IP 1550 communication and SHOULD NOT break any Non IP mechanism, including 1551 'harmful' interference on the channel. 1553 The ID of the vehicle transmitting Non IP communication is 1554 transmitted in the src MAC address of the IEEE 1609 / ETSI-ITS-G5 1555 datagrams. Accordingly, non-IP communications expose the ID of each 1556 vehicle, which may be considered as a privacy breach. 1558 IEEE 802.11-OCB bypasses the authentication mechanisms of IEEE 802.11 1559 networks, in order to transmit non IP communications to without any 1560 delay. This may be considered as a security breach. 1562 IEEE 1609 and ETSI ITS provided strong security and privacy 1563 mechanisms for Non IP Communications. Security (authentication, 1564 encryption) is done by asymetric cryptography, where each vehicle 1565 attaches its public key and its certificate to all of its non IP 1566 messages. Privacy is enforced through the use of Pseudonymes. Each 1567 vehicle will be pre-loaded with a large number (>1000s) of 1568 pseudonymes generated by a PKI, which will uniquely assign a 1569 pseudonyme to a certificate (and thus to a public/private key pair). 1571 Non IP Communication being developped for safety-critical 1572 applications, complex mechanisms have been provided for their 1573 support. These mechanisms are OPTIONAL for IP Communication, but 1574 SHOULD be used whenever possible. 1576 D.3. Reliability Requirements 1578 The dynamically changing topology, short connectivity, mobile 1579 transmitter and receivers, different antenna heights, and many-to- 1580 many communication types, make IEEE 802.11-OCB links significantly 1581 different from other IEEE 802.11 links. Any IPv6 mechanism operating 1582 on IEEE 802.11-OCB link MUST support strong link asymetry, spatio- 1583 temporal link quality, fast address resolution and transmission. 1585 IEEE 802.11-OCB strongly differs from other 802.11 systems to operate 1586 outside of the context of a Basic Service Set. This means in 1587 practice that IEEE 802.11-OCB does not rely on a Base Station for all 1588 Basic Service Set management. In particular, IEEE 802.11-OCB SHALL 1589 NOT use beacons. Any IPv6 mechanism requiring L2 services from IEEE 1590 802.11 beacons MUST support an alternative service. 1592 Channel scanning being disabled, IPv6 over IEEE 802.11-OCB MUST 1593 implement a mechanism for transmitter and receiver to converge to a 1594 common channel. 1596 Authentication not being possible, IPv6 over IEEE 802.11-OCB MUST 1597 implement an distributed mechanism to authenticate transmitters and 1598 receivers without the support of a DHCP server. 1600 Time synchronization not being available, IPv6 over IEEE 802.11-OCB 1601 MUST implement a higher layer mechanism for time synchronization 1602 between transmitters and receivers without the support of a NTP 1603 server. 1605 The IEEE 802.11-OCB link being asymetic, IPv6 over IEEE 802.11-OCB 1606 MUST disable management mechanisms requesting acknowledgements or 1607 replies. 1609 The IEEE 802.11-OCB link having a short duration time, IPv6 over IEEE 1610 802.11-OCB MUST implement fast IPv6 mobility management mechanisms. 1612 D.4. Privacy requirements 1614 Vehicles will move. As each vehicle moves, it needs to regularly 1615 announce its network interface and reconfigure its local and global 1616 view of its network. L2 mechanisms of IEEE 802.11-OCB MAY be 1617 employed to assist IPv6 in discovering new network interfaces. L3 1618 mechanisms over IEEE 802.11-OCB SHOULD be used to assist IPv6 in 1619 discovering new network interfaces. 1621 The headers of the L2 mechanisms of IEEE 802.11-OCB and L3 management 1622 mechanisms of IPv6 are not encrypted, and as such expose at least the 1623 src MAC address of the sender. In the absence of mitigations, 1624 adversaries could monitor the L2 or L3 management headers, track the 1625 MAC Addresses, and through that track the position of vehicles over 1626 time; in some cases, it is possible to deduce the vehicle 1627 manufacturer name from the OUI of the MAC address of the interface 1628 (with help of additional databases). It is important that sniffers 1629 along roads not be able to easily identify private information of 1630 automobiles passing by. 1632 Similary to Non IP safety-critical communications, the obvious 1633 mitigation is to use some form of MAC Address Randomization. We can 1634 assume that there will be "renumbering events" causing the MAC 1635 Addresses to change. Clearly, a change of MAC Address should induce 1636 a simultaneous change of IPv6 Addresses, to prevent linkage of the 1637 old and new MAC Addresses through continuous use of the same IP 1638 Addresses. 1640 The change of an IPv6 address also implies the change of the network 1641 prefix. Prefix delegation mechanisms should be available to vehicles 1642 to obtain new prefixes during "renumbering events". 1644 Changing MAC and IPv6 addresses will disrupt communications, which 1645 goes against the reliability requirements expressed in [TS103097]. 1646 We will assume that the renumbering events happen only during "safe" 1647 periods, e.g. when the vehicle has come to a full stop. The 1648 determination of such safe periods is the responsibility of 1649 implementors. In automobile settings it is common to decide that 1650 certain operations (e.g. software update, or map update) must happen 1651 only during safe periods. 1653 MAC Address randomization will not prevent tracking if the addresses 1654 stay constant for long intervals. Suppose for example that a vehicle 1655 only renumbers the addresses of its interface when leaving the 1656 vehicle owner's garage in the morning. It would be trivial to 1657 observe the "number of the day" at the known garage location, and to 1658 associate that with the vehicle's identity. There is clearly a 1659 tension there. If renumbering events are too infrequent, they will 1660 not protect privacy, but if their are too frequent they will affect 1661 reliability. We expect that implementors will eventually find the 1662 right balance. 1664 D.5. Authentication requirements 1666 IEEE 802.11-OCB does not have L2 authentication mechanisms. 1667 Accordingly, a vehicle receiving a IPv6 over IEEE 802.11-OCB packet 1668 cannot check or be sure the legitimacy of the src MAC (and associated 1669 ID). This is a significant breach of security. 1671 Similarly to Non IP safety-critical communications, IPv6 over 1672 802.11-OCB packets must contain a certificate, including at least the 1673 public key of the sender, that will allow the receiver to 1674 authenticate the packet, and guarantee its legitimacy. 1676 To satisfy the privacy requiremrents of Appendix D.4, the certificate 1677 SHALL be changed at each 'renumbering event'. 1679 D.6. Multiple interfaces 1681 There are considerations for 2 or more IEEE 802.11-OCB interface 1682 cards per vehicle. For each vehicle taking part in road traffic, one 1683 IEEE 802.11-OCB interface card MUST be fully allocated for Non IP 1684 safety-critical communication. Any other IEEE 802.11-OCB may be used 1685 for other type of traffic. 1687 The mode of operation of these other wireless interfaces is not 1688 clearly defined yet. One possibility is to consider each card as an 1689 independent network interface, with a specific MAC Address and a set 1690 of IPv6 addresses. Another possibility is to consider the set of 1691 these wireless interfaces as a single network interface (not 1692 including the IEEE 802.11-OCB interface used by Non IP safety 1693 critical communications). This will require specific logic to 1694 ensure, for example, that packets meant for a vehicle in front are 1695 actually sent by the radio in the front, or that multiple copies of 1696 the same packet received by multiple interfaces are treated as a 1697 single packet. Treating each wireless interface as a separate 1698 network interface pushes such issues to the application layer. 1700 The privacy requirements of Appendix D.4 imply that if these multiple 1701 interfaces are represented by many network interface, a single 1702 renumbering event SHALL cause renumbering of all these interfaces. 1703 If one MAC changed and another stayed constant, external observers 1704 would be able to correlate old and new values, and the privacy 1705 benefits of randomization would be lost. 1707 The privacy requirements of Non IP safety-critical communications 1708 imply that if a change of pseudonyme occurs, renumbering of all other 1709 interfaces SHALL also occur. 1711 D.7. MAC Address Generation 1713 When designing the IPv6 over 802.11-OCB address mapping, we will 1714 assume that the MAC Addresses will change during well defined 1715 "renumbering events". The 48 bits randomized MAC addresses will have 1716 the following characteristics: 1718 o Bit "Local/Global" set to "locally admninistered". 1720 o Bit "Unicast/Multicast" set to "Unicast". 1722 o 46 remaining bits set to a random value, using a random number 1723 generator that meets the requirements of [RFC4086]. 1725 The way to meet the randomization requirements is to retain 46 bits 1726 from the output of a strong hash function, such as SHA256, taking as 1727 input a 256 bit local secret, the "nominal" MAC Address of the 1728 interface, and a representation of the date and time of the 1729 renumbering event. 1731 D.8. Security Certificate Generation 1733 When designing the IPv6 over 802.11-OCB address mapping, we will 1734 assume that the MAC Addresses will change during well defined 1735 "renumbering events". So MUST also the Security Certificates. 1736 Unless unavailable, the Security Certificate Generation mechanisms 1737 SHOULD follow the specification in IEEE 1609.2 [ieee16094] or ETSI TS 1738 103 097 [TS103097]. These security mechanisms have the following 1739 characteristics: 1741 o Authentication - Elliptic Curve Digital Signature Algorithm 1742 (ECDSA) - A Secured Hash Function (SHA-256) will sign the message 1743 with the public key of the sender. 1745 o Encryption - Elliptic Curve Integrated Encryption Scheme (ECIES) - 1746 A Key Derivation Function (KDF) between the sender's public key 1747 and the receiver's private key will generate a symetric key used 1748 to encrypt a packet. 1750 If the mechanisms described in IEEE 1609.2 [ieee16094] or ETSI TS 103 1751 097 [TS103097] are either not supported or not capable of running on 1752 the hardware, an alternative approach based on Pretty-Good-Privacy 1753 (PGP) MAY be used as an alternative. 1755 Authors' Addresses 1757 Alexandre Petrescu 1758 CEA, LIST 1759 CEA Saclay 1760 Gif-sur-Yvette , Ile-de-France 91190 1761 France 1763 Phone: +33169089223 1764 Email: Alexandre.Petrescu@cea.fr 1766 Nabil Benamar 1767 Moulay Ismail University 1768 Morocco 1770 Phone: +212670832236 1771 Email: benamar73@gmail.com 1773 Jerome Haerri 1774 Eurecom 1775 Sophia-Antipolis 06904 1776 France 1778 Phone: +33493008134 1779 Email: Jerome.Haerri@eurecom.fr 1781 Christian Huitema 1782 Friday Harbor, WA 98250 1783 U.S.A. 1785 Email: huitema@huitema.net 1786 Jong-Hyouk Lee 1787 Sangmyung University 1788 31, Sangmyeongdae-gil, Dongnam-gu 1789 Cheonan 31066 1790 Republic of Korea 1792 Email: jonghyouk@smu.ac.kr 1794 Thierry Ernst 1795 YoGoKo 1796 France 1798 Email: thierry.ernst@yogoko.fr 1800 Tony Li 1801 Peloton Technology 1802 1060 La Avenida St. 1803 Mountain View, California 94043 1804 United States 1806 Phone: +16503957356 1807 Email: tony.li@tony.li