Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11
Extracted elements (26)
High vehicle mobility, strong link asymmetry, very short connection durations, and strict automotive reliability and privacy requirements make the 802.11-OCB link significantly different from other 802.11 networks, justifying this separate specification rather than reusing existing 802.11 IPv6 documents without modification.
IPv6 over 802.11-OCB is derived from IPv6 over Ethernet (RFC 2464) with minimal stack changes, because the 802.11-OCB MAC layer presents practically the same interface to IP as 802.11a/b/g/n and 802.3. Device drivers MAY implement Ethernet framing internally and perform 802.3-to-802.11 frame translation to minimize code changes.
Semantically opaque IIDs (rather than EUI-64-derived IIDs) are preferred because privacy-sensitive information is absent from Interface IDs when it is impossible to calculate back the initial MAC address value from which the IID was generated.
IPv6 Neighbor Discovery requires reflexive (bidirectional) and transitive properties for DAD and AR; an IPv6 subnet can be mapped on an OCB network only if all nodes share a single physical broadcast domain. Extension to NBMA multi-OCB-link subnets is out of scope.
Multicast transmissions over 802.11-OCB links have known performance issues (per IEEE802-MCAST) that may be exacerbated in OCB mode; DAD and AR operations as specified in RFC 4861 cannot be guaranteed, and broadcast-based multicast is often detrimental to unicast traffic.
Protocols like Mobile IPv6 (RFC 6275) and DNAv6 (RFC 6059) that depend on timely movement detection may need additional tuning because 802.11-OCB lacks link-layer notifications during handover.
An RSU that provides internet connectivity MAY announce a default router preference (RFC 4191), whereas a car that does not provide that connectivity MUST NOT do so.
At 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.
Because pseudonymization means layer-2 or layer-3 addresses cannot be relied upon for trust, upper-layer protocols and applications SHOULD NOT rely on layer-2 or layer-3 addresses to assume that the other participant can be trusted.
In the LLC header, the value of the Type field MUST be set to 0x86DD (IPv6) in accordance with EtherType Protocol Discrimination (EPD).
IP packets MUST be transmitted over 802.11-OCB media as QoS data frames whose format is specified in IEEE 802.11-2016.
It is RECOMMENDED to use the mechanisms described in RFC 7217 to permit the use of stable IIDs that do not change within one subnet prefix, supporting semantically opaque identifiers that prevent back-calculation to the MAC address.
OCB nodes that support RFC 8505 SHOULD support the 6LN operation in order to act as a host, and may support 6LR and 6LBR operations to act as a router and own a prefix for address autoconfiguration and registration.
The baseline ND protocol (RFC 4861) MUST be supported over 802.11-OCB links.
The mapping to the 802.11 data service SHOULD use a 'priority' value of 1 (QoS with a 'Background' user priority), reserving higher priority values for safety-critical and time-sensitive traffic.
The RECOMMENDED method for forming stable Interface Identifiers (IIDs) for Global or Unique Local IPv6 addresses is described in RFC 8064. Regardless of the method, the IID length is 64 bits.
Unicast and multicast address mapping MUST follow the procedures specified for Ethernet interfaces described in Sections 6 and 7 of RFC 2464.
When timing requirements are very strict (e.g., fast-drive-through IP-RSU coverage), the exclusive use of IPv6 link-local addresses is RECOMMENDED and no on-link subnet prefix should be configured on an 802.11-OCB interface.
Embedding a MAC address in an IPv6 Interface Identifier exposes company ID information encoded in OUI bits; attackers can capture Router Advertisements and correlate source addresses with physical observations (e.g., car color) to build persistent profiles of vehicles.
Vehicles using 802.11-OCB expose their MAC addresses and IPv6 addresses to passive sniffers along public roads, enabling location tracking. The use of dynamically changing MAC addresses, semantically opaque IIDs, and stable IIDs (per RFC 7217) is strongly recommended to mitigate tracking risks.
A randomized MAC address for 802.11-OCB has the 'Local/Global' bit set to 'locally administered', the 'Unicast/Multicast' bit set to 'Unicast', and the remaining 46 bits set to a random value using a generator meeting RFC 4086 requirements.
In 802.11-OCB mode, all nodes use a wildcard BSSID (ff:ff:ff:ff:ff:ff), no beacon frames are transmitted, no authentication or association is required, no encryption is provided, and the flag dot11OCBActivated is set to 'true'.
The default MTU for IP packets on 802.11-OCB is 1500 octets, inherited from RFC 2464. Every link must have a minimum MTU of 1280 octets per RFC 8200.
802.11-OCB provides no cryptographic protection; an attacker within radio range can sniff or inject traffic, and a directional antenna allows attacks without close physical proximity. The link is less protected than wired or BSS-mode 802.11 links.
Any node can join an 802.11-OCB subnet and directly communicate with or impersonate any other node, enabling threats outlined in RFC 6959. SEND (RFC 3971/3972) is identified as a solution to spoof-based attack vectors, though not widely deployed. IPsec (RFC 4301) may provide data security protection at the network layer.
An IPv6 packet on the air over 802.11-OCB is structured as: Radiotap header (monitor mode only) | IEEE 802.11 Data header (Type/Subtype, Duration, Receiver/Transmitter Address, BSS ID ff:ff:ff:ff:ff:ff, Frag/Seq Number) | LLC header (DSAP, SSAP, Control, Org Code, Type=0x86DD) | IPv6 Base header | payload.