IPWAVE Working Group of IETF, an updated status report Alexandre PETRESCU, CEA March 2021 Contents What is IPWAVE Working Group Main WG item: IPv6 over 802.11 OCB Additional WG item: Problem Statement and Use Cases Perspectives IPWAVE
"IPWAVE Working Group of IETF, an updated status" is the property of its rightful owner. Permission is granted to
download and print the materials on this website for personal, non-commercial use only, and to display it
on your personal computer provided you do not modify the materials and that you retain all copyright
notices contained in the materials. By downloading content from our website, you accept the terms of this
agreement.
Presentation Transcript
01
IPWAVE Working Group of IETF,an updated status report Alexandre PETRESCU, CEA
March 2021<br>
02
Contents What is IPWAVE Working Group
Main WG item: IPv6 over 802.11 OCB
Additional WG item: Problem Statement and Use Cases
Perspectives<br>
03
IPWAVE Working Group IP Wireless Access in Vehicular Environments (IPWAVE) is a Working Group at the Internet Engineering Task Force (IETF).
Works on “V2V and V2I use-cases where IP is well-suited as a networking technology”.
Liaisons with ISO TC 204, SAE, ETSI ITS, IEEE, ITU CITS, ITU-R WP 5A.
Group formed in year 2016, after successful Birds-of-a-Feather (BoF) www.ietfjournal.org/intelligent-transportation-systems-and-the-ietf/
Email list, roughly 340 subscribers www.ietf.org/mailman/listinfo/its<br>
04
Main Work Item: IPv6 over 802.11-OCB IEEE 802.11p is a MAC and PHY layer for vehicular wireless networks:
Operates Outside the Context of a BSSID (802.11-OCB).
Works at 5.9GHz bands channels with a short 10MHz width.
Requires the use of 802.11 “QoS Data” headers.
Higher power levels are allowed (33 dBm, 40 dBm, country-specific).
Future evolutions: 802.11bd.
Running an IP layer on 802.11-OCB requires the definition of a few parameters:
EtherType is 0x86DD
Default MTU is 1500 bytes, minimum MTU size is 1280 bytes
Priority (TID) is 1, i.e. ‘Background’, also known as ‘AC_BK’
Interface Identifiers are:
based on EUI-64, or are ‘Stable’ or ‘Opaque’ IIDs;
of length 64 bit.
Use IPv6-over-Ethernet [RFC2464], and a simple “frame translation from 802.3 to 802.11 in order to minimize the code changes.”
Subnet structure: recommendations on the use of Neighbor Discovery and Mobile IPv6 protocols in vehicular settings.
Security considerations, privacy.<br>
05
Status RFC 8691 “Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11”
issued in December 2019
Implementation of RFC 8691 is straightforward:
Available as a patch to linux kernels (some parts fully integrated in mainline)
See an OCB patch for 16mbit/s and less, at e.g. https://github.com/jfpastrana/ath9k_ocb_linux_4.2.8
Not yet available on BSD systems
Advancements towards the use of IPv6 with ath10k drivers
For a higher bandwidth OCB (more than 16mbit/s for vehicle networks, e.g. 1Gbit/s)
See the OCB patch at:
https://gitlab.com/hpi-potsdam/osm/g5-on-linux/11p-on-linux/-/tree/ath10k
(important note: contrary to github, one can browse that gitlab URL on IPv6 as well, without a need of having IPv4 on the computer)<br>
06
Topologies for using IPv6 for Vehicle Networks Vehicle-to-Vehicle IP network topology:
Vehicle-to-Internet IP network topology:
Other variations Vehicle Vehicle Vehicle IPv6
over OCB
at 5.9GHz
subnet1 IPv6
over OCB
at 5.9GHz
subnet2 IPv6
over OCB
at 5.9GHz
subnetn Disconnected from the Internet
Scales well very large (more than what ITS-G5 can do on 5 channels)
Demonstrated in camera-less and driver-less convoy (platoon) Vehicle RSU IPv6
over OCB
at 5.9GHz
subnet Internet Connected to the Internet
Offers access to Internet without going to cellular network
Works simultaneously with non-IP CAMs or BSMs, on same channels<br>
07
Additional WG item: Problem Statement and Use Cases draft-ietf-ipwave-vehicular-networking-20 publicly accessible
Exercise in identifying gaps and open areas, prioritize for potential upcoming work;
Analyse address autoconfiguration, routing, mobility management, DNS, service discovery, security and privacy – for IP networking in vehicular environments;
Describes general problems;
Describes IP-related problems;
Mentions also the use of IP in cellular networks for vehicular environments.
Further improvements following the review from Area Director<br>
08
Status WG item “IPWAVE Problem Statement” is back from IESG, and comments are addressed.
The Working Group IPWAVE will probably not meet during the typical IETF online meetings (the July meeting of year 2021, initially planned in San Francisco, is highly likely to happen online exclusively; maybe new ‘hybrid meeting’ formulas might be plannned for November 2021).<br>
09
Which channel for IPv6 on 802.11-OCB? FCC plan to re-allocate channels in the 5.9GHz band
https://docs.fcc.gov/public/attachments/DOC-361339A1.pdf
Response from some members of the IPWAVE WG:
https://www.fcc.gov/ecfs/filing/10115292918548
On which channel is one allowed to run IPv6 over 802.11-OCB?
FCC re-allocation at 5.9GHz gives half of that space to WiFi (any WiFi) and half to C-V2X
Requires to move away from DSRC at 5.9GHz in one year time (until end of year 2021)
Allows for exceptions at DSRC deployments, but requests to be informed
Risks:
C-V2X might not work simultaneously with the IEEE MAC and PHY in the same channel from 5895MHz to 5M925MHz only C-V2X is ‘legitimate’ (but still ‘unlicensed’)
Up to 5895MHz the WiFi 7 will eat all the channels nothing left for OCB mode (but still in an ‘unlicensed’ area).
So, again, on which channel can IPv6 run legitimately on 802.11-OCB?
maybe there is no solution.<br>
10
Towards IPv6 on C-V2X, some leads See the list of C-V2X devices on market,
https://5gaa.org/wp-content/uploads/2020/11/5GAA_List-of-C-V2X-Devices.pdf
(but beware: not visible if you are on an IPv6-only computer)
Identify a miniPCI interface that supports ‘mode4’, and see whether there is a linux driver for it
Put IPv6 on it
There are risks that are similar to those in OCB mode:
There are two kinds of 802.11 WiFi cards that support OCB mode in the market:
Those who don’t use QoS Headers – cheap.
Those who use QoS Headers – expensive.
RFC8691 IPv6-over-OCB requires those who do QoS Headers; mixtures of cards with and without QoS support work ok, so the RFC works ok too.
There are many kinds of C-V2X cards that support multiple ‘Modes’
They seem(?) to be all expensive, independent of the ‘Mode’.
They seem to not be compatible with the use of OCB modes of IEEE.
THE COST! The cost of hardware and the cost of software, open source or not.<br>