idnits 2.17.1 draft-petrescu-ipv6-over-80211p-06.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 (November 30, 2016) is 2697 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 1379, but not defined == Unused Reference: 'RFC6775' is defined on line 1121, but no explicit reference was found in the text == Unused Reference: 'I-D.baccelli-multi-hop-wireless-communication' is defined on line 1171, 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 3, 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 November 30, 2016 18 Transmission of IPv6 Packets over IEEE 802.11 Outside the Context of a 19 Basic Service Set (OCB) 20 draft-petrescu-ipv6-over-80211p-06.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 3, 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 . . . . . . . . . . . . . . . . . . . . . 29 102 Appendix B. Explicit Prohibition of IPv6 on Channels 103 Related to ITS Scenarios using 802.11p Networks 104 - an Analysis . . . . . . . . . . . . . . . . . . . 31 105 B.1. Interpretation of FCC and ETSI documents with 106 respect to running IP on particular channels . . . . . . 31 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 . . . . . . . . . . . . . . . . . . . . . . . 34 112 D.2. Non IP Communications . . . . . . . . . . . . . . . . . . 35 113 D.3. Reliability Requirements . . . . . . . . . . . . . . . . 36 114 D.4. Privacy requirements . . . . . . . . . . . . . . . . . . 36 115 D.5. Authentication requirements . . . . . . . . . . . . . . . 37 116 D.6. Multiple interfaces . . . . . . . . . . . . . . . . . . . 38 117 D.7. MAC Address Generation . . . . . . . . . . . . . . . . . 38 118 D.8. Security Certificate Generation . . . . . . . . . . . . . 39 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 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 11. Acknowledgements 1047 The authors would like to thank Witold Klaudel, Ryuji Wakikawa, 1048 Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan 1049 Romascanu, Konstantin Khait, Ralph Droms, Richard Roy, Ray Hunter, 1050 Tom Kurihara, Michelle Wetterwald, Michal Sojka, Jan de Jongh, Suresh 1051 Krishnan, Dino Farinacci, Vincent Park, Jaehoon Paul Jeong and Gloria 1052 Gwynne. Their valuable comments clarified certain issues and 1053 generally helped to improve the document. 1055 Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB 1056 drivers for linux and described how. 1058 For the multicast discussion, the authors would like to thank Owen 1059 DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and 1060 participants to discussions in network working groups. 1062 The authours would like to thank participants to the Birds-of- 1063 a-Feather "Intelligent Transportation Systems" meetings held at IETF 1064 in 2016. 1066 12. References 1068 12.1. Normative References 1070 [I-D.ietf-6man-default-iids] 1071 Gont, F., Cooper, A., Thaler, D., and S. LIU, 1072 "Recommendation on Stable IPv6 Interface Identifiers", 1073 draft-ietf-6man-default-iids-16 (work in progress), 1074 September 2016. 1076 [I-D.ietf-6man-ug] 1077 Carpenter, B. and S. Jiang, "Significance of IPv6 1078 Interface Identifiers", draft-ietf-6man-ug-06 (work in 1079 progress), December 2013. 1081 [I-D.ietf-tsvwg-ieee-802-11] 1082 Szigeti, T. and F. Baker, "DiffServ to IEEE 802.11 1083 Mapping", draft-ietf-tsvwg-ieee-802-11-01 (work in 1084 progress), November 2016. 1086 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1087 Requirement Levels", BCP 14, RFC 2119, 1088 DOI 10.17487/RFC2119, March 1997, 1089 . 1091 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1092 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1093 December 1998, . 1095 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1096 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1097 . 1099 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1100 "Randomness Requirements for Security", BCP 106, RFC 4086, 1101 DOI 10.17487/RFC4086, June 2005, 1102 . 1104 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1105 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 1106 . 1108 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1109 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1110 DOI 10.17487/RFC4861, September 2007, 1111 . 1113 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 1114 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 1115 September 2010, . 1117 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1118 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1119 2011, . 1121 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1122 Bormann, "Neighbor Discovery Optimization for IPv6 over 1123 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1124 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1125 . 1127 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1128 Considerations for IPv6 Address Generation Mechanisms", 1129 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1130 . 1132 12.2. Informative References 1134 [etsi-302663-v1.2.1p-2013] 1135 "Intelligent Transport Systems (ITS); Access layer 1136 specification for Intelligent Transport Systems operating 1137 in the 5 GHz frequency band, 2013-07, document 1138 en_302663v010201p.pdf, document freely available at URL 1139 http://www.etsi.org/deliver/etsi_en/302600_302699/302663/ 1140 01.02.01_60/en_302663v010201p.pdf downloaded on October 1141 17th, 2013.". 1143 [etsi-draft-102492-2-v1.1.1-2006] 1144 "Electromagnetic compatibility and Radio spectrum Matters 1145 (ERM); Intelligent Transport Systems (ITS); Part 2: 1146 Technical characteristics for pan European harmonized 1147 communications equipment operating in the 5 GHz frequency 1148 range intended for road safety and traffic management, and 1149 for non-safety related ITS applications; System Reference 1150 Document, Draft ETSI TR 102 492-2 V1.1.1, 2006-07, 1151 document tr_10249202v010101p.pdf freely available at URL 1152 http://www.etsi.org/deliver/etsi_tr/102400_102499/ 1153 10249202/01.01.01_60/tr_10249202v010101p.pdf downloaded on 1154 October 18th, 2013.". 1156 [fcc-cc] "'Report and Order, Before the Federal Communications 1157 Commission Washington, D.C. 20554', FCC 03-324, Released 1158 on February 10, 2004, document FCC-03-324A1.pdf, document 1159 freely available at URL 1160 http://www.its.dot.gov/exit/fcc_edocs.htm downloaded on 1161 October 17th, 2013.". 1163 [fcc-cc-172-184] 1164 "'Memorandum Opinion and Order, Before the Federal 1165 Communications Commission Washington, D.C. 20554', FCC 1166 06-10, Released on July 26, 2006, document FCC- 1167 06-110A1.pdf, document freely available at URL 1168 http://hraunfoss.fcc.gov/edocs_public/attachmatch/ 1169 FCC-06-110A1.pdf downloaded on June 5th, 2014.". 1171 [I-D.baccelli-multi-hop-wireless-communication] 1172 Baccelli, E. and C. Perkins, "Multi-hop Ad Hoc Wireless 1173 Communication", draft-baccelli-multi-hop-wireless- 1174 communication-06 (work in progress), July 2011. 1176 [I-D.perkins-intarea-multicast-ieee802] 1177 Perkins, C., Stanley, D., Kumari, W., and J. Zuniga, 1178 "Multicast Considerations over IEEE 802 Wireless Media", 1179 draft-perkins-intarea-multicast-ieee802-01 (work in 1180 progress), September 2016. 1182 [I-D.petrescu-its-scenarios-reqs] 1183 Petrescu, A., Janneteau, C., Boc, M., and W. Klaudel, 1184 "Scenarios and Requirements for IP in Intelligent 1185 Transportation Systems", draft-petrescu-its-scenarios- 1186 reqs-03 (work in progress), October 2013. 1188 [ieee16094] 1189 "1609.2-2016 - IEEE Standard for Wireless Access in 1190 Vehicular Environments--Security Services for Applications 1191 and Management Messages; document freely available at URL 1192 https://standards.ieee.org/findstds/ 1193 standard/1609.2-2016.html retrieved on July 08th, 2016.". 1195 [ieee802.11-2012] 1196 "802.11-2012 - IEEE Standard for Information technology-- 1197 Telecommunications and information exchange between 1198 systems Local and metropolitan area networks--Specific 1199 requirements Part 11: Wireless LAN Medium Access Control 1200 (MAC) and Physical Layer (PHY) Specifications. Downloaded 1201 on October 17th, 2013, from IEEE Standards, document 1202 freely available at URL 1203 http://standards.ieee.org/findstds/ 1204 standard/802.11-2012.html retrieved on October 17th, 1205 2013.". 1207 [ieee802.11p-2010] 1208 "IEEE Std 802.11p(TM)-2010, IEEE Standard for Information 1209 Technology - Telecommunications and information exchange 1210 between systems - Local and metropolitan area networks - 1211 Specific requirements, Part 11: Wireless LAN Medium Access 1212 Control (MAC) and Physical Layer (PHY) Specifications, 1213 Amendment 6: Wireless Access in Vehicular Environments; 1214 document freely available at URL 1215 http://standards.ieee.org/getieee802/ 1216 download/802.11p-2010.pdf retrieved on September 20th, 1217 2013.". 1219 [ieeep1609.0-D2] 1220 "IEEE P1609.0/D2 Draft Guide for Wireless Access in 1221 Vehicular Environments (WAVE) Architecture. pdf, length 1222 879 Kb. Restrictions apply.". 1224 [ieeep1609.2-D17] 1225 "IEEE P1609.2(tm)/D17 Draft Standard for Wireless Access 1226 in Vehicular Environments - Security Services for 1227 Applications and Management Messages. pdf, length 2558 1228 Kb. Restrictions apply.". 1230 [ieeep1609.3-D9-2010] 1231 "IEEE P1609.3(tm)/D9, Draft Standard for Wireless Access 1232 in Vehicular Environments (WAVE) - Networking Services, 1233 August 2010. Authorized licensed use limited to: CEA. 1234 Downloaded on June 19, 2013 at 07:32:34 UTC from IEEE 1235 Xplore. Restrictions apply, document at persistent link 1236 http://ieeexplore.ieee.org/servlet/opac?punumber=5562705". 1238 [ieeep1609.4-D9-2010] 1239 "IEEE P1609.4(tm)/D9 Draft Standard for Wireless Access in 1240 Vehicular Environments (WAVE) - Multi-channel Operation. 1241 Authorized licensed use limited to: CEA. Downloaded on 1242 June 19, 2013 at 07:34:48 UTC from IEEE Xplore. 1243 Restrictions apply. Document at persistent link 1244 http://ieeexplore.ieee.org/servlet/opac?punumber=5551097". 1246 [ipv6-80211p-its] 1247 Shagdar, O., Tsukada, M., Kakiuchi, M., Toukabri, T., and 1248 T. Ernst, "Experimentation Towards IPv6 over IEEE 802.11p 1249 with ITS Station Architecture", International Workshop on 1250 IPv6-based Vehicular Networks, (colocated with IEEE 1251 Intelligent Vehicles Symposium), URL: 1252 http://hal.inria.fr/hal-00702923/en, Downloaded on: 24 1253 October 2013, Availability: free at some sites, paying at 1254 others, May 2012. 1256 [ipv6-wave] 1257 Clausen, T., Baccelli, E., and R. Wakikawa, "IPv6 1258 Operation for WAVE - Wireless Access in Vehicular 1259 Environments", Rapport de Recherche INRIA, number 7383, 1260 URL: http://hal.inria.fr/inria-00517909/, Downloaded on: 1261 24 October 2013, Availability: free at some sites, 1262 September 2010. 1264 [TS103097] 1265 "Intelligent Transport Systems (ITS); Security; Security 1266 header and certificate formats; document freely available 1267 at URL http://www.etsi.org/deliver/ 1268 etsi_ts/103000_103099/103097/01.01.01_60/ 1269 ts_103097v010101p.pdf retrieved on July 08th, 2016.". 1271 [vip-wave] 1272 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 1273 Feasibility of IP Communications in 802.11p Vehicular 1274 Networks", IEEE Transactions on Intelligent Transportation 1275 Systems, Volume 14, Issue 1, URL and Digital Object 1276 Identifier: http://dx.doi.org/10.1109/TITS.2012.2206387, 1277 Downloaded on: 24 October 2013, Availability: free at 1278 some sites, paying at others, March 2013. 1280 Appendix A. ChangeLog 1282 The changes are listed in reverse chronological order, most recent 1283 changes appearing at the top of the list. 1285 From draft-petrescu-ipv6-over-80211p-05.txt to draft-petrescu-ipv6- 1286 over-80211p-06.txt: 1288 o Removed IPv4 text. 1290 o Added text about isues with multicast over 802.11 and OCB mode. 1292 o Shortened the subnet structure section, by referring to an 1293 existing RFC. 1295 o Removed the appendix about distribution of certificates. 1297 o Added text about tradeoff of too frequent RAs, handover 1298 performance and risks of packet loss. 1300 o Removed discussion about other MTU possibilities, kept only the 1301 1500 bytes MTU. 1303 o Keep both header "802.11 Data" and header "802.11 QoS Data". 1305 o Referred to default-iids recommendation of generating stable IIDs. 1307 o Moved the Design Considerations sections to an appendix. 1309 From draft-petrescu-ipv6-over-80211p-02.txt to draft-petrescu-ipv6- 1310 over-80211p-03.txt: 1312 o Added clarification about the "OCBActivated" qualifier in the the 1313 new IEEE 802.11-2012 document; this IEEE document integrates now 1314 all earlier 802.11p features; this also signifies the 1315 dissapearance of an IEEE IEEE 802.11p document altogether. 1317 o Added explanation about FCC not prohibiting IP on channels, and 1318 comments about engineering advice and reliability of IP messages. 1320 o Added possibility to use 6lowpan adaptation layer when in OCB 1321 mode. 1323 o Added appendix about the distribution of certificates to vehicles 1324 by using IPv6-over-802.11p single-hop communications. 1326 o Refined the explanation of 'half-rate' mode. 1328 o Added the privacy concerns and necessity of and potential effects 1329 of dynamically changing MAC addresses. 1331 From draft-petrescu-ipv6-over-80211p-01.txt to draft-petrescu-ipv6- 1332 over-80211p-02.txt: 1334 o updated authorship. 1336 o added explanation about FCC not prohibiting IP on channels, and 1337 comments about engineering advice and reliability of IP messages. 1339 o added possibility to use 6lowpan adaptation layer when in OCB 1340 mode. 1342 o added appendix about the distribution of certificates to vehicles 1343 by using IPv6-over-802.11p single-hop communications. 1345 o refined the explanation of 'half-rate' mode. 1347 o added the privacy concerns and necessity of and potential effects 1348 of dynamically changing MAC addresses. 1350 From draft-petrescu-ipv6-over-80211p-00.txt to draft-petrescu-ipv6- 1351 over-80211p-01.txt: 1353 o updated one author's affiliation detail. 1355 o added 2 more references to published literature about IPv6 over 1356 802.11p. 1358 From draft-petrescu-ipv6-over-80211p-00.txt to draft-petrescu-ipv6- 1359 over-80211p-00.txt: 1361 o first version. 1363 Appendix B. Explicit Prohibition of IPv6 on Channels Related to ITS 1364 Scenarios using 802.11p Networks - an Analysis 1366 B.1. Interpretation of FCC and ETSI documents with respect to running 1367 IP on particular channels 1369 o The FCC created the term "Control Channel" [fcc-cc]. For it, it 1370 defines the channel number to be 178 decimal, and positions it 1371 with a 10MHz width from 5885MHz to 5895MHz. The FCC rules point 1372 to standards document ASTM-E2213 (not freely available at the time 1373 of writing of this draft); in an interpretation of a reviewer of 1374 this document, this means not making any restrictions to the use 1375 of IP on the control channel. 1377 o The FCC created two more terms for particular channels 1378 [fcc-cc-172-184], among others. The channel 172 (5855MHz to 1379 5865MHz)) is designated "exclusively for [V2V] safety 1380 communications for accident avoidance and mitigation, and safety 1381 of life and property applications", and the channel 184 (5915MHz 1382 to 5925MHz) is designated "exclusively for high-power, longer- 1383 distance communications to be used for public-safety applications 1384 involving safety of life and property, including road-intersection 1385 collision mitigation". However, they are not named "control" 1386 channels, and the document does not mention any particular 1387 restriction on the use of IP on either of these channels. 1389 o On another hand, at IEEE, IPv6 is explicitely prohibited on 1390 channel number 178 decimal - the FCC's 'Control Channel'. The 1391 document [ieeep1609.4-D9-2010] prohibits upfront the use of IPv6 1392 traffic on the Control Channel: 'data frames containing IP 1393 datagrams are only allowed on service channels'. Other 'Service 1394 Channels' are allowed to use IP, but the Control Channel is not. 1396 o In Europe, basically ETSI considers FCC's "Control Channel" to be 1397 a "Service Channel", and defines a "Control Channel" to be in a 1398 slot considered by FCC as a "Service Channel". In detail, FCC's 1399 "Control Channel" number 178 decimal with 10MHz width (5885MHz to 1400 5895MHz) is defined by ETSI to be a "Service Channel", and is 1401 named 'G5-SCH2' [etsi-302663-v1.2.1p-2013]. This channel is 1402 dedicated to 'ITS Road Safety' by ETSI. Other channels are 1403 dedicated to 'ITS road traffic efficiency' by ETSI. The ETSI's 1404 "Control Channel" - the "G5-CCH" - number 180 decimal (not 178) is 1405 reserved as a 10MHz-width centered on 5900MHz (5895MHz to 5905MHz) 1406 (the 5895MHz-5905MHz channel is a Service Channel for FCC). 1407 Compared to IEEE, ETSI makes no upfront statement with respect to 1408 IP and particular channels; yet it relates the 'In car Internet' 1409 applications ('When nearby a stationary public internet access 1410 point (hotspot), application can use standard IP services for 1411 applications.') to the 'Non-safety-related ITS application' 1412 [etsi-draft-102492-2-v1.1.1-2006]. Under an interpretation of an 1413 author of this Internet Draft, this may mean ETSI may forbid IP on 1414 the 'ITS Road Safety' channels, but may allow IP on 'ITS road 1415 traffic efficiency' channels, or on other 5GHz channels re-used 1416 from BRAN (also dedicated to Broadband Radio Access Networks). 1418 o At EU level in ETSI (but not some countries in EU with varying 1419 adoption levels) the highest power of transmission of 33 dBm is 1420 allowed, but only on two separate 10Mhz-width channels centered on 1421 5900MHz and 5880MHz respectively. It may be that IPv6 is not 1422 allowed on these channels (in the other 'ITS' channels where IP 1423 may be allowed, the levels vary between 20dBm, 23 dBm and 30 dBm; 1424 in some of these channels IP is allowed). A high-power of 1425 transmission means that vehicles may be distanced more 1426 (intuitively, for 33 dBm approximately 2km is possible, and for 20 1427 dBm approximately 50meter). 1429 B.2. Interpretations of Latencies of IP datagrams 1431 IPv6 may be "allowed" on any channel. Certain interpretations 1432 consider that communicating IP datagrams may involve longer latencies 1433 than non-IP datagrams; this may make them little adapted for safety 1434 applications which require fast reaction. Certain other views 1435 disagree with this, arguing that IP datagrams are transmitted at the 1436 same speed as any other non-IP datagram and may thus offer same level 1437 of reactivity for safety applications. 1439 Appendix C. Changes Needed on a software driver 802.11a to become a 1440 802.11-OCB driver 1442 The 802.11p amendment modifies both the 802.11 stack's physical and 1443 MAC layers but all the induced modifications can be quite easily 1444 obtained by modifying an existing 802.11a ad-hoc stack. 1446 Conditions for a 802.11a hardware to be 802.11p compliant: 1448 o The chip must support the frequency bands on which the regulator 1449 recommends the use of ITS communications, for example using IEEE 1450 802.11p layer, in France: 5875MHz to 5925MHz. 1452 o The chip must support the half-rate mode (the internal clock 1453 should be able to be divided by two). 1455 o The chip transmit spectrum mask must be compliant to the "Transmit 1456 spectrum mask" from the IEEE 802.11p amendment (but experimental 1457 environments tolerate otherwise). 1459 o The chip should be able to transmit up to 44.8 dBm when used by 1460 the US government in the United States, and up to 33 dBm in 1461 Europe; other regional conditions apply. 1463 Changes needed on the network stack in OCB mode: 1465 o Physical layer: 1467 * The chip must use the Orthogonal Frequency Multiple Access 1468 (OFDM) encoding mode. 1470 * The chip must be set in half-mode rate mode (the internal clock 1471 frequency is divided by two). 1473 * The chip must use dedicated channels and should allow the use 1474 of higher emission powers. This may require modifications to 1475 the regulatory domains rules, if used by the kernel to enforce 1476 local specific restrictions. Such modifications must respect 1477 the location-specific laws. 1479 MAC layer: 1481 * All management frames (beacons, join, leave, and others) 1482 emission and reception must be disabled except for frames of 1483 subtype Action and Timing Advertisement (defined below). 1485 * No encryption key or method must be used. 1487 * Packet emission and reception must be performed as in ad-hoc 1488 mode, using the wildcard BSSID (ff:ff:ff:ff:ff:ff). 1490 * The functions related to joining a BSS (Association Request/ 1491 Response) and for authentication (Authentication Request/Reply, 1492 Challenge) are not called. 1494 * The beacon interval is always set to 0 (zero). 1496 * Timing Advertisement frames, defined in the amendment, should 1497 be supported. The upper layer should be able to trigger such 1498 frames emission and to retrieve information contained in 1499 received Timing Advertisements. 1501 Appendix D. Design Considerations 1503 The networks defined by 802.11-OCB are in many ways similar to other 1504 networks of the 802.11 family. In theory, the encapsulation of IPv6 1505 over 802.11-OCB could be very similar to the operation of IPv6 over 1506 other networks of the 802.11 family. However, the high mobility, 1507 strong link asymetry and very short connection makes the 802.11-OCB 1508 link significantly different from other 802.11 networks. Also, the 1509 automotive applications have specific requirements for reliability, 1510 security and privacy, which further add to the particularity of the 1511 802.11-OCB link. 1513 This section does not address safety-related applications, which are 1514 done on non-IP communications. However, this section will consider 1515 the transmission of such non IP communication in the design 1516 specification of IPv6 over IEEE 802.11-OCB. 1518 D.1. Vehicle ID 1520 Automotive networks require the unique representation of each of 1521 their node. Accordingly, a vehicle must be identified by at least 1522 one unique ID. The current specification at ETSI and at IEEE 1609 1523 identifies a vehicle by its MAC address uniquely obtained from the 1524 802.11-OCB NIC. 1526 A MAC address uniquely obtained from a IEEE 802.11-OCB NIC 1527 implicitely generates multiple vehicle IDs in case of multiple 1528 802.11-OCB NICs. A mechanims to uniquely identify a vehicle 1529 irrespectively to the different NICs and/or technologies is required. 1531 D.2. Non IP Communications 1533 In IEEE 1609 and ETSI ITS, safety-related communications CANNOT be 1534 used with IP datagrams. For example, Basic Safety Message (BSM, an 1535 IEEE 1609 datagram) and Cooperative Awareness Message (CAM, an ETSI 1536 ITS-G5 datagram), are each transmitted as a payload that is preceded 1537 by link-layer headers, without an IP header. 1539 Each vehicle taking part of traffic (i.e. having its engine turned on 1540 and being located on a road) MUST use Non IP communication to 1541 periodically broadcast its status information (ID, GPS position, 1542 speed,..) in its immediate neighborhood. Using these mechanisms, 1543 vehicles become 'aware' of the presence of other vehicles in their 1544 immediate vicinity. Therefore, IP communication being transmitted by 1545 vehicles taking part of traffic MUST co-exist with Non IP 1546 communication and SHOULD NOT break any Non IP mechanism, including 1547 'harmful' interference on the channel. 1549 The ID of the vehicle transmitting Non IP communication is 1550 transmitted in the src MAC address of the IEEE 1609 / ETSI-ITS-G5 1551 datagrams. Accordingly, non-IP communications expose the ID of each 1552 vehicle, which may be considered as a privacy breach. 1554 IEEE 802.11-OCB bypasses the authentication mechanisms of IEEE 802.11 1555 networks, in order to transmit non IP communications to without any 1556 delay. This may be considered as a security breach. 1558 IEEE 1609 and ETSI ITS provided strong security and privacy 1559 mechanisms for Non IP Communications. Security (authentication, 1560 encryption) is done by asymetric cryptography, where each vehicle 1561 attaches its public key and its certificate to all of its non IP 1562 messages. Privacy is enforced through the use of Pseudonymes. Each 1563 vehicle will be pre-loaded with a large number (>1000s) of 1564 pseudonymes generated by a PKI, which will uniquely assign a 1565 pseudonyme to a certificate (and thus to a public/private key pair). 1567 Non IP Communication being developped for safety-critical 1568 applications, complex mechanisms have been provided for their 1569 support. These mechanisms are OPTIONAL for IP Communication, but 1570 SHOULD be used whenever possible. 1572 D.3. Reliability Requirements 1574 The dynamically changing topology, short connectivity, mobile 1575 transmitter and receivers, different antenna heights, and many-to- 1576 many communication types, make IEEE 802.11-OCB links significantly 1577 different from other IEEE 802.11 links. Any IPv6 mechanism operating 1578 on IEEE 802.11-OCB link MUST support strong link asymetry, spatio- 1579 temporal link quality, fast address resolution and transmission. 1581 IEEE 802.11-OCB strongly differs from other 802.11 systems to operate 1582 outside of the context of a Basic Service Set. This means in 1583 practice that IEEE 802.11-OCB does not rely on a Base Station for all 1584 Basic Service Set management. In particular, IEEE 802.11-OCB SHALL 1585 NOT use beacons. Any IPv6 mechanism requiring L2 services from IEEE 1586 802.11 beacons MUST support an alternative service. 1588 Channel scanning being disabled, IPv6 over IEEE 802.11-OCB MUST 1589 implement a mechanism for transmitter and receiver to converge to a 1590 common channel. 1592 Authentication not being possible, IPv6 over IEEE 802.11-OCB MUST 1593 implement an distributed mechanism to authenticate transmitters and 1594 receivers without the support of a DHCP server. 1596 Time synchronization not being available, IPv6 over IEEE 802.11-OCB 1597 MUST implement a higher layer mechanism for time synchronization 1598 between transmitters and receivers without the support of a NTP 1599 server. 1601 The IEEE 802.11-OCB link being asymetic, IPv6 over IEEE 802.11-OCB 1602 MUST disable management mechanisms requesting acknowledgements or 1603 replies. 1605 The IEEE 802.11-OCB link having a short duration time, IPv6 over IEEE 1606 802.11-OCB MUST implement fast IPv6 mobility management mechanisms. 1608 D.4. Privacy requirements 1610 Vehicles will move. As each vehicle moves, it needs to regularly 1611 announce its network interface and reconfigure its local and global 1612 view of its network. L2 mechanisms of IEEE 802.11-OCB MAY be 1613 employed to assist IPv6 in discovering new network interfaces. L3 1614 mechanisms over IEEE 802.11-OCB SHOULD be used to assist IPv6 in 1615 discovering new network interfaces. 1617 The headers of the L2 mechanisms of IEEE 802.11-OCB and L3 management 1618 mechanisms of IPv6 are not encrypted, and as such expose at least the 1619 src MAC address of the sender. In the absence of mitigations, 1620 adversaries could monitor the L2 or L3 management headers, track the 1621 MAC Addresses, and through that track the position of vehicles over 1622 time; in some cases, it is possible to deduce the vehicle 1623 manufacturer name from the OUI of the MAC address of the interface 1624 (with help of additional databases). It is important that sniffers 1625 along roads not be able to easily identify private information of 1626 automobiles passing by. 1628 Similary to Non IP safety-critical communications, the obvious 1629 mitigation is to use some form of MAC Address Randomization. We can 1630 assume that there will be "renumbering events" causing the MAC 1631 Addresses to change. Clearly, a change of MAC Address should induce 1632 a simultaneous change of IPv6 Addresses, to prevent linkage of the 1633 old and new MAC Addresses through continuous use of the same IP 1634 Addresses. 1636 The change of an IPv6 address also implies the change of the network 1637 prefix. Prefix delegation mechanisms should be available to vehicles 1638 to obtain new prefixes during "renumbering events". 1640 Changing MAC and IPv6 addresses will disrupt communications, which 1641 goes against the reliability requirements expressed in [TS103097]. 1642 We will assume that the renumbering events happen only during "safe" 1643 periods, e.g. when the vehicle has come to a full stop. The 1644 determination of such safe periods is the responsibility of 1645 implementors. In automobile settings it is common to decide that 1646 certain operations (e.g. software update, or map update) must happen 1647 only during safe periods. 1649 MAC Address randomization will not prevent tracking if the addresses 1650 stay constant for long intervals. Suppose for example that a vehicle 1651 only renumbers the addresses of its interface when leaving the 1652 vehicle owner's garage in the morning. It would be trivial to 1653 observe the "number of the day" at the known garage location, and to 1654 associate that with the vehicle's identity. There is clearly a 1655 tension there. If renumbering events are too infrequent, they will 1656 not protect privacy, but if their are too frequent they will affect 1657 reliability. We expect that implementors will eventually find the 1658 right balance. 1660 D.5. Authentication requirements 1662 IEEE 802.11-OCB does not have L2 authentication mechanisms. 1663 Accordingly, a vehicle receiving a IPv6 over IEEE 802.11-OCB packet 1664 cannot check or be sure the legitimacy of the src MAC (and associated 1665 ID). This is a significant breach of security. 1667 Similarly to Non IP safety-critical communications, IPv6 over 1668 802.11-OCB packets must contain a certificate, including at least the 1669 public key of the sender, that will allow the receiver to 1670 authenticate the packet, and guarantee its legitimacy. 1672 To satisfy the privacy requiremrents of Appendix D.4, the certificate 1673 SHALL be changed at each 'renumbering event'. 1675 D.6. Multiple interfaces 1677 There are considerations for 2 or more IEEE 802.11-OCB interface 1678 cards per vehicle. For each vehicle taking part in road traffic, one 1679 IEEE 802.11-OCB interface card MUST be fully allocated for Non IP 1680 safety-critical communication. Any other IEEE 802.11-OCB may be used 1681 for other type of traffic. 1683 The mode of operation of these other wireless interfaces is not 1684 clearly defined yet. One possibility is to consider each card as an 1685 independent network interface, with a specific MAC Address and a set 1686 of IPv6 addresses. Another possibility is to consider the set of 1687 these wireless interfaces as a single network interface (not 1688 including the IEEE 802.11-OCB interface used by Non IP safety 1689 critical communications). This will require specific logic to 1690 ensure, for example, that packets meant for a vehicle in front are 1691 actually sent by the radio in the front, or that multiple copies of 1692 the same packet received by multiple interfaces are treated as a 1693 single packet. Treating each wireless interface as a separate 1694 network interface pushes such issues to the application layer. 1696 The privacy requirements of Appendix D.4 imply that if these multiple 1697 interfaces are represented by many network interface, a single 1698 renumbering event SHALL cause renumbering of all these interfaces. 1699 If one MAC changed and another stayed constant, external observers 1700 would be able to correlate old and new values, and the privacy 1701 benefits of randomization would be lost. 1703 The privacy requirements of Non IP safety-critical communications 1704 imply that if a change of pseudonyme occurs, renumbering of all other 1705 interfaces SHALL also occur. 1707 D.7. MAC Address Generation 1709 When designing the IPv6 over 802.11-OCB address mapping, we will 1710 assume that the MAC Addresses will change during well defined 1711 "renumbering events". The 48 bits randomized MAC addresses will have 1712 the following characteristics: 1714 o Bit "Local/Global" set to "locally admninistered". 1716 o Bit "Unicast/Multicast" set to "Unicast". 1718 o 46 remaining bits set to a random value, using a random number 1719 generator that meets the requirements of [RFC4086]. 1721 The way to meet the randomization requirements is to retain 46 bits 1722 from the output of a strong hash function, such as SHA256, taking as 1723 input a 256 bit local secret, the "nominal" MAC Address of the 1724 interface, and a representation of the date and time of the 1725 renumbering event. 1727 D.8. Security Certificate Generation 1729 When designing the IPv6 over 802.11-OCB address mapping, we will 1730 assume that the MAC Addresses will change during well defined 1731 "renumbering events". So MUST also the Security Certificates. 1732 Unless unavailable, the Security Certificate Generation mechanisms 1733 SHOULD follow the specification in IEEE 1609.2 [ieee16094] or ETSI TS 1734 103 097 [TS103097]. These security mechanisms have the following 1735 characteristics: 1737 o Authentication - Elliptic Curve Digital Signature Algorithm 1738 (ECDSA) - A Secured Hash Function (SHA-256) will sign the message 1739 with the public key of the sender. 1741 o Encryption - Elliptic Curve Integrated Encryption Scheme (ECIES) - 1742 A Key Derivation Function (KDF) between the sender's public key 1743 and the receiver's private key will generate a symetric key used 1744 to encrypt a packet. 1746 If the mechanisms described in IEEE 1609.2 [ieee16094] or ETSI TS 103 1747 097 [TS103097] are either not supported or not capable of running on 1748 the hardware, an alternative approach based on Pretty-Good-Privacy 1749 (PGP) MAY be used as an alternative. 1751 Authors' Addresses 1753 Alexandre Petrescu 1754 CEA, LIST 1755 CEA Saclay 1756 Gif-sur-Yvette , Ile-de-France 91190 1757 France 1759 Phone: +33169089223 1760 Email: Alexandre.Petrescu@cea.fr 1761 Nabil Benamar 1762 Moulay Ismail University 1763 Morocco 1765 Phone: +212670832236 1766 Email: benamar73@gmail.com 1768 Jerome Haerri 1769 Eurecom 1770 Sophia-Antipolis 06904 1771 France 1773 Phone: +33493008134 1774 Email: Jerome.Haerri@eurecom.fr 1776 Christian Huitema 1777 Friday Harbor, WA 98250 1778 U.S.A. 1780 Email: huitema@huitema.net 1782 Jong-Hyouk Lee 1783 Sangmyung University 1784 31, Sangmyeongdae-gil, Dongnam-gu 1785 Cheonan 31066 1786 Republic of Korea 1788 Email: jonghyouk@smu.ac.kr 1790 Thierry Ernst 1791 YoGoKo 1792 France 1794 Email: thierry.ernst@yogoko.fr 1796 Tony Li 1797 Peloton Technology 1798 1060 La Avenida St. 1799 Mountain View, California 94043 1800 United States 1802 Phone: +16503957356 1803 Email: tony.li@tony.li