The default MTU for IP packets on 802.11-OCB is inherited from [RFC 2464
] and, as such, is 1500 octets. As noted in [RFC 8200
], every link on the Internet must have a minimum MTU of 1280 octets and must follow the other recommendations, especially with regard to fragmentation.
IP packets MUST
be transmitted over 802.11-OCB media as QoS data frames whose format is specified in an IEEE 802.11 spec [IEEE-802.11-2016
The IPv6 packet transmitted on 802.11-OCB is immediately preceded by a Logical Link Control (LLC) header and an 802.11 header. In the LLC header and in accordance with EtherType Protocol Discrimination (EPD; see Appendix D
), the value of the Type field MUST
be set to 0x86DD (IPv6). 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, including the ones listed in [ETSI-sec-archi
To simplify the Application Programming Interface (API) between the operating system and the 802.11-OCB media, device drivers MAY
implement IPv6 over Ethernet as per [RFC 2464
] and then a frame translation from 802.3 to 802.11 in order to minimize the code changes.
There are several types of IPv6 addresses [RFC 4291
] [RFC 4193
] that may be assigned to an 802.11-OCB interface. Among these types of addresses, only the IPv6 link-local addresses can be formed using an EUI-64 identifier, particularly during transition time (the period of time before an interface starts using an address different from the LL one).
If the IPv6 link-local address is formed using an EUI-64 identifier, then the mechanism for forming that address is the same mechanism as that used to form an IPv6 link-local address on Ethernet links. Moreover, regardless of whether the interface identifier is derived from the EUI-64 identifier, its length is 64 bits, as is the case for the Ethernet [RFC 2464
The steps a host takes in deciding how to autoconfigure its interfaces in IPv6 are described in [RFC 4862
]. This section describes the formation of Interface Identifiers for 'Global' or 'Unique Local' IPv6 addresses. Interface Identifiers for 'link-local' IPv6 addresses are discussed in Section 4.3
method for forming stable Interface Identifiers (IIDs) is described in [RFC 8064
]. The method of forming IIDs described in Section 4
of RFC 2464 MAY
be used during transition time, particularly for IPv6 link-local addresses. Regardless of the method used to form the IID, its length is 64 bits, similarly to IPv6 over Ethernet [RFC 2464
The bits in the IID have no specific 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, which is an IEEE link-layer address, are significant. The details of this significance are described in [RFC 7136
Semantically opaque IIDs, instead of meaningful IIDs derived from a valid and meaningful MAC address (RFC 2464
, Section 4
), help avoid certain privacy risks (see the risks mentioned in Section 5.1.1
). If semantically opaque IIDs are needed, they may be generated using the method for generating semantically opaque IIDs with IPv6 Stateless Address Autoconfiguration given in [RFC 7217
]. Typically, an opaque IID is formed starting from identifiers different from the MAC addresses and from cryptographically strong material. Thus, privacy-sensitive information is absent from Interface IDs because it is impossible to calculate back the initial value from which the Interface ID was first generated.
Some applications that use IPv6 packets on 802.11-OCB links (among other link types) may benefit from IPv6 addresses whose IIDs don't change too often. 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. A possible source for the Net_Iface parameter is a virtual interface name or logical interface name that is decided by a local administrator.
Unicast and multicast address mapping MUST
follow the procedures specified for Ethernet interfaces described in Sections 6
of [RFC 2464
This document is scoped for Address Resolution (AR) and Duplicate Address Detection (DAD) per [RFC 4862
The multicast address mapping is performed according to the method specified in Section 7
of RFC 2464
. The meaning of the value "33-33" mentioned there is defined in Section 2.3.1
of RFC 7042
Transmitting IPv6 packets to multicast destinations over 802.11 links proved to have some performance issues [IEEE802-MCAST
]. These issues may be exacerbated in OCB mode. Future improvement to this specification should consider solutions for these problems.
When vehicles are in close range, a subnet may be formed over 802.11-OCB interfaces (not by their in-vehicle interfaces). A Prefix List conceptual data structure (RFC 4861
, Section 5.1
) is maintained for each 802.11-OCB interface.
The IPv6 Neighbor Discovery protocol (ND) requires reflexive properties (bidirectional connectivity), which is generally, though not always, the case for P2P OCB links. IPv6 ND also requires transitive properties for DAD and AR, so an IPv6 subnet can be mapped on an OCB network only if all nodes in the network share a single physical broadcast domain. The extension to IPv6 ND operating on a subnet that covers multiple OCB links and does not fully overlap (i.e., non-broadcast multi-access (NBMA)) is not in scope of this document. Finally, IPv6 ND requires permanent connectivity of all nodes in the subnet to defend their addresses -- in other words, very stable network conditions.
The structure of this subnet is ephemeral in that it is strongly influenced by the mobility of vehicles: the hidden terminal effects appear, and the 802.11 networks in OCB mode may be considered ad hoc networks with an addressing model, as described in [RFC 5889
]. On the other hand, the structure of the internal subnets in each vehicle is relatively stable.
As recommended in [RFC 5889
], 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 (i.e., a default route is absent), and the addressing peers are equally qualified (that is, it is impossible to determine whether some vehicle owns and distributes addresses to others), the use of link-local addresses is RECOMMENDED
The baseline ND protocol [RFC 4861
be supported over 802.11-OCB links. Transmitting ND packets may prove to have some performance issues, as mentioned in Section 4.5.2
and Appendix I
. These issues may be exacerbated in OCB mode. Solutions for these problems should consider the OCB mode of operation. Future solutions to OCB should consider solutions for avoiding broadcast. The best of current knowledge indicates the kinds of issues that may arise with ND in OCB mode; they are described in Appendix I
Protocols like Mobile IPv6 [RFC 6275
] [RFC 3963
] and DNAv6 [RFC 6059
], which depend on timely movement detection, might need additional tuning work to handle the lack of link-layer notifications during handover. This topic is left for further study.