--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-27.txt 2018-09-19 08:13:13.681872959 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-28.txt 2018-09-19 08:13:13.757874766 -0700 @@ -1,26 +1,26 @@ IPWAVE Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: March 18, 2019 Moulay Ismail University +Expires: March 23, 2019 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - September 14, 2018 + September 19, 2018 Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) - draft-ietf-ipwave-ipv6-over-80211ocb-27 + draft-ietf-ipwave-ipv6-over-80211ocb-28 Abstract In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 18, 2019. + This Internet-Draft will expire on March 23, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -57,108 +57,110 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4 - 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4 - 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 - 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 - 4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 - 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 - 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 - 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 - 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 7 - 4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 - 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8 + 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 5 + 4.2. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 + 4.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 + 4.3.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 + 4.4. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 + 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 + 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 + 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 7 + 4.6. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 + 4.7. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 9 - 5.2. MAC Address Generation . . . . . . . . . . . . . . . . . 10 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10 + 5.2. MAC Address and Interface ID Generation . . . . . . . . . 10 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 14 - Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 15 - Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 24 - Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 24 + Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 16 + Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 25 + Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 25 Appendix D. Changes Needed on a software driver 802.11a to - become a 802.11-OCB driver . . . 28 - Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 29 - Appendix F. Design Considerations . . . . . . . . . . . . . . . 30 - F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 30 + become a 802.11-OCB driver . . . 29 + Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 30 + Appendix F. Design Considerations . . . . . . . . . . . . . . . 31 Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31 - Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 31 - H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 32 - H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 34 - Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 + Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 32 + H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33 + H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35 + Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction This document describes the transmission of IPv6 packets on IEEE Std 802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see Appendix B, Appendix C and Appendix D). This involves the layering of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC layer. Compared to running IPv6 over the Ethernet MAC layer, there is no modification expected to IEEE Std 802.11 MAC and Logical Link sublayers: IPv6 works fine directly over 802.11-OCB too, with an LLC layer. The IPv6 network layer operates on 802.11-OCB in the same manner as operating on Ethernet, but there are two kinds of exceptions: o Exceptions due to different operation of IPv6 network layer on 802.11 than on Ethernet. To satisfy these exceptions, this document describes an Ethernet Adaptation Layer between Ethernet headers and 802.11 headers. The Ethernet Adaptation Layer is - described Section 4.2.1. The operation of IP on Ethernet is + described Section 4.3.1. The operation of IP on Ethernet is described in [RFC1042], [RFC2464] and [I-D.hinden-6man-rfc2464bis]. o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11. This has impacts on security, privacy, subnet structure and handover behaviour. For security and privacy recommendations see - Section 5 and Section 4.5. The subnet structure is described in - Section 4.6. The handover behaviour on OCB links is not described + Section 5 and Section 4.6. The subnet structure is described in + Section 4.7. The handover behaviour on OCB links is not described in this document. + The Security Considerations section describes security and privacy + aspects of 802.11-OCB. + In the published literature, many documents describe aspects and problems related to running IPv6 over 802.11-OCB: [I-D.ietf-ipwave-vehicular-networking-survey]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer situated in a vehicle such as an automobile, bicycle, or similar. It has at least one IP interface that runs in mode OCB of 802.11, and that has an "OBU" transceiver. See the definition of the term "OBU" in section Appendix I. - IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. An - IP-RSU has at least two distinct IP-enabled interfaces. An IP-RSU is - similar to a Wireless Termination Point (WTP), as defined in - [RFC5415], or an Access Point (AP), as defined in IEEE documents, or - an Access Network Router (ANR) defined in [RFC3753], with one key - particularity: the wireless PHY/MAC layer of at least one of its IP- - enabled interfaces is configured to operate in 802.11-OCB mode. The - IP-RSU communicates with the IP-OBU in the vehicle over 802.11 - wireless link operating in OCB mode. + IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. It + has at least two distinct IP-enabled interfaces; the wireless PHY/MAC + layer of at least one of its IP-enabled interfaces is configured to + operate in 802.11-OCB mode. An IP-RSU communicates with the IP-OBU + in the vehicle over 802.11 wireless link operating in OCB mode. An + IP-RSU is similar to an Access Network Router (ANR) defined in + [RFC3753], and a Wireless Termination Point (WTP) defined in + [RFC5415]. OCB (outside the context of a basic service set - BSS): A mode of operation in which a STA is not a member of a BSS and does not utilize IEEE Std 802.11 authentication, association, or data confidentiality. 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribute dot11OCBActivited is true. Note: compliance with standards and regulations set in different countries when using the 5.9GHz frequency band is required. @@ -177,51 +179,56 @@ vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. While 802.11-OCB is clearly specified, and the use of IPv6 over such link is not radically new, the operating environment (vehicular networks) brings in new perspectives. The mechanisms for forming and terminating, discovering, peering and mobility management for 802.11-OCB links are not described in this document. 4. IPv6 over 802.11-OCB -4.1. Maximum Transmission Unit (MTU) + +4.1. Pseudonym Handling + + Pseudonym. + +4.2. Maximum Transmission Unit (MTU) The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. It is the same value as IPv6 packets on Ethernet links, as specified in [RFC2464]. This value of the MTU respects the recommendation that every link on the Internet must have a minimum MTU of 1280 octets (stated in [RFC8200], and the recommendations therein, especially with respect to fragmentation). -4.2. Frame Format +4.3. Frame Format IP packets MUST be transmitted over 802.11-OCB media as QoS Data frames whose format is specified in IEEE Std 802.11. The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded by a Logical Link Control (LLC) header and an 802.11 header. In the LLC header, and in accordance with the EtherType Protocol Discrimination (EPD), the value of the Type field MUST be set to 0x86DD (IPv6). In the 802.11 header, the value of the Subtype sub- field in the Frame Control field MUST be set to 8 (i.e. 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of the QoS Control field of the 802.11 header MUST be set to binary 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). To simplify the Application Programming Interface (API) between the operating system and the 802.11-OCB media, device drivers MAY implement an Ethernet Adaptation Layer that translates Ethernet II frames to the 802.11 format and vice versa. An Ethernet Adaptation - Layer is described in Section 4.2.1. + Layer is described in Section 4.3.1. -4.2.1. Ethernet Adaptation Layer +4.3.1. Ethernet Adaptation Layer An 'adaptation' layer is inserted between a MAC layer and the Networking layer. This is used to transform some parameters between their form expected by the IP stack and the form provided by the MAC layer. An Ethernet Adaptation Layer makes an 802.11 MAC look to IP Networking layer as a more traditional Ethernet layer. At reception, this layer takes as input the IEEE 802.11 header and the Logical-Link Layer Control Header and produces an Ethernet II Header. At sending, @@ -267,102 +274,113 @@ | 802.11 MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.11 PHY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Ethernet Adaptation Layer stacked with other layers (in the above figure, a 802.11 profile is represented; this is used also for 802.11-OCB profile.) -4.3. Link-Local Addresses +4.4. Link-Local Addresses There are several types of IPv6 addresses [RFC4291], [RFC4193], that MAY be assigned to an 802.11-OCB interface. Among these types of addresses only the IPv6 link-local addresses MAY be formed using an EUI-64 identifier. If the IPv6 link-local address is formed using an EUI-64 identifier, then the mechanism of forming that address is the same mechanism as used to form an IPv6 link-local address on Ethernet links. This mechanism is described in section 5 of [RFC2464]. -4.4. Address Mapping + For privacy, the link-local address MAY be formed according to the + mechanisms described in Section 5.2. + +4.5. Address Mapping Unicast and multicast address mapping MUST follow the procedures specified for Ethernet interfaces in sections 6 and 7 of [RFC2464]. -4.4.1. Address Mapping -- Unicast +4.5.1. Address Mapping -- Unicast The procedure for mapping IPv6 unicast addresses into Ethernet link- layer addresses is described in [RFC4861]. -4.4.2. Address Mapping -- Multicast +4.5.2. Address Mapping -- Multicast The multicast address mapping is performed according to the method specified in section 7 of [RFC2464]. The meaning of the value "3333" mentioned in that section 7 of [RFC2464] is defined in section 2.3.1 of [RFC7042]. Transmitting IPv6 packets to multicast destinations over 802.11 links proved to have some performance issues [I-D.perkins-intarea-multicast-ieee802]. These issues may be exacerbated in OCB mode. Solutions for these problems should consider the OCB mode of operation. -4.5. Stateless Autoconfiguration +4.6. Stateless Autoconfiguration There are several types of IPv6 addresses [RFC4291], [RFC4193], that MAY be assigned to an 802.11-OCB interface. This section describes the formation of Interface Identifiers for IPv6 addresses of type 'Global' or 'Unique Local'. For Interface Identifiers for IPv6 - address of type 'Link-Local' see Section 4.3. + address of type 'Link-Local' see Section 4.4. The Interface Identifier for an 802.11-OCB interface is formed using the same rules as the Interface Identifier for an Ethernet interface; the RECOMMENDED method for forming stable Interface Identifiers (IIDs) is described in [RFC8064]. The method of forming IIDs described in section 4 of [RFC2464] MAY be used during transition time. The bits in the Interface Identifier have no generic meaning and the identifier should be treated as an opaque value. The bits 'Universal' and 'Group' in the identifier of an 802.11-OCB interface are significant, as this is an IEEE link-layer address. The details of this significance are described in [RFC7136]. If semantically opaque Interface Identifiers are needed, a potential method for generating semantically opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration is given in [RFC7217]. The way Interface Identifiers are used MAY involve risks to privacy, as described in Section 5.1. -4.6. Subnet Structure +4.7. Subnet Structure A subnet is formed by the external 802.11-OCB interfaces of vehicles that are in close range (not by their in-vehicle interfaces). This subnet MUST use at least the link-local prefix fe80::/10 and the interfaces MUST be assigned IPv6 addresses of type link-local. This subnet MAY NOT have any other prefix than the link-local prefix. The structure of this subnet is ephemeral, in that it is strongly influenced by the mobility of vehicles: the 802.11 hidden node effects appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc' networks with an addressing model as described in [RFC5889]. On another hand, the structure of the internal subnets in each car is relatively stable. As recommended in [RFC5889], when the timing requirements are very strict (e.g. fast drive through IP-RSU coverage), no on-link subnet prefix should be configured on an 802.11-OCB interface. In such cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED. + Additionally, even if the timing requirements are not very strict + (e.g. the moving subnet formed by two following vehicles is stable, a + fixed IP-RSU is absent), the subnet is disconnected from the Internet + (a default route is absent), and the addressing peers are equally + qualified (impossible to determine that some vehicle owns and + distributes addresses to others) the use of link-local addresses is + RECOMMENDED. + The Neighbor Discovery protocol (ND) [RFC4861] is used over 802.11-OCB links. The operation of the Mobile IPv6 protocol over 802.11-OCB links is different than on other links. The Movement Detection operation (section 11.5.1 of [RFC6275]) can not rely on Neighbor Unreachability Detection operation of the Neighbor Discovery protocol, for the reason mentioned in the previous paragraph. Also, the 802.11-OCB link layer is not a lower layer that can provide an indication that a link layer handover has occured. The operation of the Mobile IPv6 @@ -413,24 +431,24 @@ eavesdropping and subsequent correlation of data; this may reveal data considered private by the vehicle owner; there is a risk of being tracked. In outdoors public environments, where vehicles typically circulate, the privacy risks are more important than in indoors settings. It is highly likely that attacker sniffers are deployed along routes which listen for IEEE frames, including IP packets, of vehicles passing by. For this reason, in the 802.11-OCB deployments, there is a strong necessity to use protection tools such as dynamically changing MAC addresses Section 5.2, semantically opaque Interface Identifiers and stable Interface Identifiers - Section 4.5. This may help mitigate privacy risks to a certain + Section 4.6. This may help mitigate privacy risks to a certain level. -5.2. MAC Address Generation +5.2. MAC Address and Interface ID Generation In 802.11-OCB networks, the MAC addresses MAY change during well defined renumbering events. In the moment the MAC address is changed on an 802.11-OCB interface all the Interface Identifiers of IPv6 addresses assigned to that interface MUST change. The policy dictating when the MAC address is changed on the 802.11-OCB interface is to-be-determined. For more information on the motivation of this policy please refer to the privacy discussion in Appendix C. @@ -439,24 +457,31 @@ o Bit "Local/Global" set to "locally admninistered". o Bit "Unicast/Multicast" set to "Unicast". o The 46 remaining bits are set to a random value, using a random number generator that meets the requirements of [RFC4086]. To meet the randomization requirements for the 46 remaining bits, a hash function may be used. For example, the SHA256 hash function may - be used with input a 256 bit local secret, the "nominal" MAC Address + be used with input a 256 bit local secret, the 'nominal' MAC Address of the interface, and a representation of the date and time of the renumbering event. + A randomized Interface ID has the same characteristics of a + randomized MAC address, except the length in bits. A MAC address + SHOULD be of length 48 decimal. An Interface ID SHOULD be of length + 64 decimal for all types of IPv6 addresses. In the particular case + of IPv6 link-local addresses, the length of the Interface ID MAY be + 118 decimal. + 6. IANA Considerations No request to IANA. 7. Contributors Christian Huitema, Tony Li. Romain Kuntz contributed extensively about IPv6 handovers between links running outside the context of a BSS (802.11-OCB links). @@ -492,20 +517,22 @@ drivers for linux and described how. For the multicast discussion, the authors would like to thank Owen DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and participants to discussions in network working groups. The authors would like to thank participants to the Birds-of- a-Feather "Intelligent Transportation Systems" meetings held at IETF in 2016. + Human Rights Protocol Considerations review by Amelia Andersdotter. + 9. References 9.1. Normative References [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, DOI 10.17487/RFC1042, February 1988, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -645,20 +672,33 @@ draft-perkins-intarea-multicast-ieee802-03 (work in progress), July 2017. [IEEE-1609.2] "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Security Services for Applications and Management Messages. Example URL http://ieeexplore.ieee.org/document/7426684/ accessed on August 17th, 2017.". + [IEEE-1609.3] + "IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access + in Vehicular Environments (WAVE) -- Networking Services. + Example URL http://ieeexplore.ieee.org/document/7458115/ + accessed on August 17th, 2017.". + + [IEEE-1609.4] + "IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access + in Vehicular Environments (WAVE) -- Multi-Channel + Operation. Example URL + http://ieeexplore.ieee.org/document/7435228/ accessed on + August 17th, 2017.". + [IEEE-802.11-2016] "IEEE Standard 802.11-2016 - IEEE Standard for Information Technology - Telecommunications and information exchange between systems Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. Status - Active Standard. Description retrieved freely on September 12th, 2017, at URL https://standards.ieee.org/findstds/ standard/802.11-2016.html". @@ -673,20 +713,33 @@ document freely available at URL http://standards.ieee.org/getieee802/ download/802.11p-2010.pdf retrieved on September 20th, 2013.". Appendix A. ChangeLog The changes are listed in reverse chronological order, most recent changes appearing at the top of the list. + -28: + + o Created a new section 'Pseudonym Handling'. + + o removed the 'Vehicle ID' appendix. + + o improved the address generation from random MAC address. + + o shortened Term IP-RSU definition. + + o removed refs to two detail Clauses in IEEE documents, kept just + these latter. + -27: part 1 of addressing Human Rights review from IRTF. Removed appendices F.2 and F.3. Shortened definition of IP-RSU. Removed reference to 1609.4. A few other small changes, see diff. -26: moved text from SLAAC section and from Design Considerations appendix about privacy into a new Privacy Condiderations subsection of the Security section; reformulated the SLAAC and IID sections to stress only LLs can use EUI-64; removed the "GeoIP" wireshark explanation; reformulated SLAAC and LL sections; added brief mention of need of use LLs; clarified text about MAC address changes; dropped @@ -1275,21 +1328,23 @@ related to PHY, and thus has not much impact on the interface between the IP layer and the MAC layer. o In vehicular communications using 802.11-OCB links, there are strong privacy requirements with respect to addressing. While the 802.11-OCB standard does not specify anything in particular with respect to MAC addresses, in these settings there exists a strong need for dynamic change of these addresses (as opposed to the non- vehicular settings - real wall protection - where fixed MAC addresses do not currently pose some privacy risks). This is - further described in Section 5. + further described in Section 5. A relevant function is described + in documents IEEE 1609.3-2016 [IEEE-1609.3] and IEEE 1609.4-2016 + [IEEE-1609.4]. Appendix D. Changes Needed on a software driver 802.11a to become a 802.11-OCB driver The 802.11p amendment modifies both the 802.11 stack's physical and MAC layers but all the induced modifications can be quite easily obtained by modifying an existing 802.11a ad-hoc stack. Conditions for a 802.11a hardware to be 802.11-OCB compliant: @@ -1380,38 +1435,20 @@ The networks defined by 802.11-OCB are in many ways similar to other networks of the 802.11 family. In theory, the encapsulation of IPv6 over 802.11-OCB could be very similar to the operation of IPv6 over other networks of the 802.11 family. However, the high mobility, strong link asymmetry and very short connection makes the 802.11-OCB link significantly different from other 802.11 networks. Also, the automotive applications have specific requirements for reliability, security and privacy, which further add to the particularity of the 802.11-OCB link. -F.1. Vehicle ID - - In automotive networks it is required that each node is represented - uniquely at a certain point in time. Accordingly, a vehicle must be - identified by at least one unique identifier. The current - specification at ETSI and at IEEE 1609 identifies a vehicle by its - MAC address, which is obtained from the 802.11-OCB Network Interface - Card (NIC). - - In case multiple 802.11-OCB NICs are present in one car, implicitely - multiple vehicle IDs will be generated. Additionally, some software - generates a random MAC address each time the computer boots; this - constitutes an additional difficulty. - - A mechanim to uniquely identify a vehicle irrespectively to the - multiplicity of NICs, or frequent MAC address generation, is - necessary. - Appendix G. IEEE 802.11 Messages Transmitted in OCB mode For information, at the time of writing, this is the list of IEEE 802.11 messages that may be transmitted in OCB mode, i.e. when dot11OCBActivated is true in a STA: o The STA may send management frames of subtype Action and, if the STA maintains a TSF Timer, subtype Timing Advertisement; o The STA may send control frames, except those of subtype PS-Poll,