ETSI GR IP6 030 V1.1.1 (2020-10)

IPv6-based Vehicular Networking (V2X)

DGR/IP6-0030

General Information

• Status: Not Published
• Technical Committee: IP6 - IPv6 integration
• Current Stage: 12 - Completion
• Due Date: 27-Oct-2020
• Completion Date: 16-Oct-2020

Standards Content (Sample)

GROUP REPORT
IPv6-based Vehicular Networking (V2X)
Disclaimer
The present document has been produced and approved by the IPv6 Integration (IP6) ETSI Industry Specification Group (ISG)
and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR IP6 030 V1.1.1 (2020-10)

Reference
DGR/IP6-0030
Keywords
IPv6, V2X
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GR IP6 030 V1.1.1 (2020-10)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 IPv6-based Vehicular Networking (V2X) . 12
4.1 Introduction . 12
4.2 IPv6 Transition Strategies . 12
4.3 World Wide V2X Standardisation Initiatives . 13
4.3.1 Applying IPv6 to Extra-Vehicular Communication . 13
4.3.2 Modelling IPv6 Links and Subnets over a Wireless LAN . 14
4.3.3 Applying IPv6 ND to Wireless Links . 15
4.3.4 Deeper dive on IPv6 Wireless ND . 16 ®
4.3.5 Connecting to the infrastructure with IPv6 Over Wi-Fi . 17
4.3.6 Connecting to the infrastructure with IPv6 Over OCB . 17
4.3.7 Enabling network mobility . 19
4.3.8 Vehicle-to-Vehicle connectivity with MANET Technologies . 20
4.3.9 Security . 21
rd
4.3.10 3 Generation Partnership Project (3GPP) . 22
4.3.11 International Organization for Standardization (ISO) . 23
4.3.11.1 IPv6 in ITS Station Architecture . 23
4.3.11.2 IPv6 GeoNetworking in ITS Station Architecture . 23
4.3.12 ETSI ITS-G5 versus 3GPP C-V2X (AIOTI) . 25
4.3.12.1 ITS-G5 . 25
4.3.12.2 C-V2X . 25
4.3.13 IETF activity on vehicular communications . 25
4.3.14 5G Automotive Association (5G-AA) . 26
4.4 Best Cases on IPv6 Transition Strategies for Vehicular Networks . 27
4.4.1 Introduction. 27
4.4.2 The AUTOPILOT project . 28
4.4.3 Use Case in USA: Example of Web Performance Improvement in Vehicular Networks using IPv6 . 30
4.4.4 Use Case in Europe: 5G-MOBIX Project . 32
4.4.5 Use Case in Europe: 5G-DRIVE Project . 33
4.4.6 Use Case in China: Example 1. 34
4.4.7 Use Case in China: 5G Large-scale Trial Project . 35
4.4.8 5G and Internet of Things (IoT). 36
5 Lessons Learned . 37
6 Conclusions . 37
History . 38

ETSI
4 ETSI GR IP6 030 V1.1.1 (2020-10)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) IPv6 Integration (IP6).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
5 ETSI GR IP6 030 V1.1.1 (2020-10)
1 Scope
The present document outlines the motivation for the deployment of IPv6-based 5G Mobile Internet, the objectives, the
technology guidelines, the step-by-step process, the benefits, the risks, the challenges and the milestones.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document, but they assist the
user with regard to a particular subject area.
[i.1] ETSI GR IP6 011 (V1.1.1): "IPv6-Based 5G Mobile Wireless Internet; Deployment of IPv6-Based
5G Mobile Wireless Internet".
[i.2] Alcatel-Lucent Strategic White Paper (April 2015): "464XLAT in mobile networks IPv6 migration
strategies for mobile networks".
[i.3] IETF RFC 6342 (December 2011): "Mobile Networks Considerations for IPv6 Deployment".
[i.4] ETSI GR IP6 006: "Generic migration steps from IPv4 to IPv6".
NOTE: Available at http://www.itu.int/en/ITU-T/focusgroups/imt-2020/Documents/T13-SG13-151130-TD-
PLEN-0208%21%21MSW-E.docx.
[i.5] R, Chandler and ARIN staff: "The introduction of IPv6 to the 3GPP Standards and Mobile
Networks", ARIN wiki, last modified on 20 June 2015.
NOTE: Available at https://getipv6.info/display/IPv6/3GPP+Mobile+Networks.
[i.6] IETF RFC 3633 (December 2003): "IPv6 Prefix Options for Dynamic Host Configuration Protocol
(DHCP) version 6".
[i.7] IETF RFC 3769 (June 2004): "Requirements for IPv6 Prefix Delegation".
[i.8] IETF RFC 7755 (February 2016): "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center
Environments".
NOTE: Available at http://www.lightreading.com/ethernet-ip/ip-protocols-software/facebook-ipv6-is-a-real-
world-big-deal/a/d-id/718395.
[i.9] ACM MobiCom'16, October 03-07 2016, New York City, USA: "A case for faster mobile web in
cellular IPv6 networks", U. Goel, M. Steiner, MP. Wittie, M. Flack, S. Ludin.
NOTE: Available at https://origin-www.moritzsteiner.de/papers/Mobicom_IPv6.pdf.
[i.10] ETSI GR IP6 008: "IPv6-based Internet of Things Deployment of IPv6-based Internet of Things".
ETSI
6 ETSI GR IP6 030 V1.1.1 (2020-10)
[i.11] 5G Automotive Association (5GAA): "MNO Network Expansion Mechanisms to Fulfil Connected
Vehicle Requirements", White Paper, 23 June 2020.
[i.12] ISO 21217:2014 "Intelligent transport systems -- Communications access for land mobiles
(CALM) - Architecture", April 2014.
[i.13] ETSI EN 302 665 (V1.1.1): "Intelligent Transport Systems (ITS); Communications Architecture".
[i.14] ISO 21210:2012: "Intelligent transport systems -- Communications access for land mobiles
(CALM) -- IPv6 Networking", June 2012.
[i.15] ISO 29281-1:2018: "Intelligent transport systems -- Localized communications -- Part 1: Fast
networking & transport layer protocol (FNTP)", June 2018.
[i.16] IETF RFC 3963 (January 2005): "Network Mobility (NEMO) Basic Support Protocol".
[i.17] ETSI EN 302 636-5-1 (V2.1.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
GeoNetworking; Part 5: Transport Protocols; Sub-part 1: Basic Transport Protocol".
[i.18] ETSI EN 302 636-6-1 (V1.2.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over
GeoNetworking Protocols".
[i.19] IETF RFC 5648 (October 2009): "Multiple Care-of Addresses Registration".
[i.20] ETSI EN 302 636-4-1 (V1.2.1): "Intelligent Transport Systems (ITS); Vehicular Communications;
GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-
multipoint communications; Sub-part 1: Media-Independent Functionality".
[i.21] IETF RFC 8200 (July 2017): "Internet Protocol, Version 6 (IPv6) Specification".
[i.22] IETF RFC 2663 (August 1999): "IP Network Address Translation (NAT) Terminology and
Considerations".
[i.23] IETF RFC 4241 (December 2005): "A Model of IPv6/IPv4 Dual Stack Internet Access Service".
[i.24] IETF RFC 6275 (July 2011): "Mobility Support in IPv6".
[i.25] José Santa, Pedro J. Fernández, Fernando Pereñíguez, Fernando Bernal, Antonio Moragón,
Antonio F. Skarmeta, "IPv6 Communication Stack for Deploying Cooperative Vehicular
Services", International Journal of ITS Research, Vol. 12, May 2013.
NOTE: Available at
https://www.researchgate.net/publication/261718503_IPv6_Communication_Stack_for_Deploying_Coop
erative_Vehicular_Services.
[i.26] Pedro Javier Fernández Ruiz, Fernando Bernal Hidalgo, José Santa Lozano and Antonio F.
Skarmeta, "Deploying ITS Scenarios Providing Security and Mobility Services Based on IEEE
802.11p™ Technology". (Published: February 13th, 2013).
NOTE: Available at https://www.intechopen.com/books/vehicular-technologies-deployment-and-
applications/deploying-its-scenarios-providing-security-and-mobility-services-based-on-ieee-802-11p-
technology.
[i.27] IETF RFC 4301 (December 2005): "Security Architecture for the Internet Protocol".
[i.28] Pedro J. Fernandez, José Santa, Fernando Bernal and Antonio F. Skarmeta,"Securing Vehicular
IPv6 Communications" (2015).
[i.29] Donenfeld, J.A.: "WireGuard®: Next generation kernel network tunnel", In: 24th Annual Network
and Distributed System Security Symposium, NDSS 2017.
[i.30] Perrin, T.: "The Noise protocol framework" (2018).
NOTE: Available at https://noiseprotocol.org/noise.html.
ETSI
7 ETSI GR IP6 030 V1.1.1 (2020-10)
[i.31] Jacob Appelbaum, Chloe Martindale, Peter Wu, "Tiny WireGuard Tweak". Department of
Mathematics and Computer Science Eindhoven University of Technology, Eindhoven,
Netherlands.
[i.32] 5G Automotive Association (5GAA): "5GAA Efficient Security Provisioning System", White
Paper, 18 May 2020.
NOTE: Available at https://eprint.iacr.org/2019/482.pdf.
[i.33] IETF RFC 4861 (September 2007): "Neighbor Discovery for IP version 6 (IPv6)".
[i.34] IETF RFC 4862 (September 2007): "IPv6 Stateless Address Autoconfiguration".
[i.35] IETF RFC 6550 (March 2012): "RPL: IPv6 Routing Protocol for Low-Power and Lossy
Networks".
[i.36] IETF RFC 4291 (February 2006): "IP Version 6 Addressing Architecture".
[i.37] IETF RFC 8273 (December 2017): "Unique IPv6 Prefix per Host".
[i.38] IETF RFC 8505 (November 2018): "Registration Extensions for IPv6 over Low-Power Wireless
Personal Area Network (6LoWPAN) Neighbor Discovery".
[i.39] IETF RFC 6775 (November 2012): "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)".
[i.40] IETF draft draft-ietf-6lo-backbone-router: "IPv6 Backbone Router".
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/.
[i.41] IETF draft draft-ietf-6lo-ap-nd: "Address Protected Neighbor Discovery for Low-power and Lossy
Networks".
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/.
[i.42] IETF RFC 4191 (November 2005): "Default Router Preferences and More-Specific Routes".
[i.43] IETF RFC 8691 (December 2019): "Basic Support for IPv6 Networks Operating Outside the
Context of a Basic Service Set over IEEE Std 802.11™".
[i.44] IETF Distributed Mobility Management WG.
NOTE: Available at https://datatracker.ietf.org/wg/dmm/about/.
[i.45] ETSI EN 302 663 (V1.3.1): "Intelligent Transport Systems (ITS); ITS-G5 Access layer
specification for Intelligent Transport Systems operating in the 5 GHz frequency band".
[i.46] ETSI TS 122 185 (V14.3.0): "Service requirements for V2X services (3GPP TS 22.185
Release 14)".
[i.47] AIOTI WG03 - loT Standardisation, "IoT Relation and Impact on 5G", April 2020.
NOTE: Available at https://aioti.eu/wp-content/uploads/2020/05/AIOTI-IoT-relation-and-impact-on-5G-R3-
Published.pdf.
[i.48] IETF Draft: "draft-thubert-roll-unaware-leaves".
[i.49] IETF Draft: "draft-thubert-6man-ipv6-over-wireless".
[i.50] IETF Draft: "draft-pthubert-raw-architecture".
[i.51] IEEE Std 802.11™: "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".
[i.52] IEEE Std. 802.3™: "IEEE Standard for Ethernet".
ETSI
8 ETSI GR IP6 030 V1.1.1 (2020-10)
[i.53] IEEE Std. 802.1™: "IEEE Standard for Local and Metropolitan Area Networks--Port-Based
Network Access Control".
[i.54] ETSI TS 123 501: "5G; System architecture for the 5G System (5GS) (3GPP TS 23.501)".
[i.55] IETF RFC 4903 (June 2007): "Multi-Link Subnet Issues".
[i.56] IETF RFC 7668 (October 2015): "IPv6 over BLUETOOTH(R) Low Energy".
[i.57] IETF RFC 6830 (January 2013): "The Locator/ID Separation Protocol (LISP)".
[i.58] IETF RFC 7401 (April 2015): "Host Identity Protocol Version 2 (HIPv2)".
[i.59] IETF RFC 7181 (April 2014): "The Optimized Link State Routing Protocol Version 2".
[i.60] IETF RFC 3561 (July 2003): "Ad hoc On-Demand Distance Vector (AODV) Routing".
[i.61] ETSI TS 123 285: "Universal Mobile Telecommunications System (UMTS); LTE; Architecture
enhancements for V2X services (3GPP TS 23.285)".
[i.62] IETF RFC 5614 (August 2009): "Mobile Ad Hoc Network (MANET) Extension of OSPF Using
Connected Dominating Set (CDS) Flooding".
[i.63] IETF RFC 5820 (March 2010): "Extensions to OSPF to Support Mobile Ad Hoc Networking".
[i.64] IETF RFC 7137 (February 2014): "Use of the OSPF-MANET Interface in Single-Hop Broadcast
Networks".
[i.65] IETF RFC 3775 (June 2004): "Mobility Support in IPv6".
[i.66] IETF RFC 4889 (July 2007): "Network Mobility Route Optimization Solution Space Analysis".
[i.67] IETF RFC 8655 (October 2019): "Deterministic Networking Architecture".
[i.68] AUTOPILOT EU LSP Project.
NOTE 1: Available at https://autopilot-project.eu/.
NOTE 2: Versailles Project available at https://autopilot-project.eu/wp-
content/uploads/sites/16/2018/09/Versailles.pdf.
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP Third Generation Partnership Project
th
5G 5 Generation
5G NR 5G New Radio
5G-DRIVE 5G HarmoniseD Research and TrIals for serVice Evolution
AD Autonomous Driving
ADAS Advanced Driver Assistance System
ETSI
9 ETSI GR IP6 030 V1.1.1 (2020-10)
AEAD Authentication Encryption with Additional Data
AF Application Function
AH Authentication Header
AI Artifical Intelligence
AIOTI Alliance for Internet of Things Innovation
AMF Access and Mobility Function
AODV Ad hoc On-Demand Distance Vector routing
AP Access Point
APN Access Point Names
APNIC Asia Pacific Network Information Centre
AR Address Resolution
AR/VR Augmented Reality/Virtual Reality
ASL Adaptation Sub-Layer
ATM Asynchronous Transfer Mode
BA Binding Acknowledge
BID Binding Identification Number
BLE Bluetooth Low Energy
BS Base Station
BSM Basic Safety Message
BSS Basic Service Set
BTP Basic Transport Protocol
BU Binding Update
C-ADAS Cooperative Advanced Driving Assistance Systems
CAM Cooperative Awareness Message
CCAM Cooperative, Connected and Automated Mobility
CCSA China Communication Standards Association
CDN Content Delivery Network
CGN Carrier Grade NAT
CG-NAT Carrier-Grade NAT
CLAT Customer-side transLATor
CN Correspondent Node
CoA Care of Address
CORE Core Network
CPM Collective Perception Message
CSAE China Society of Automotive Engineers
CSFB Circuit Switched FallBack
DAD Duplicate Address Detection
DHCP Dynamic Host Configuation Protocol
DHCPv6 Dynamic Host Configuration Protocol version 6
DMM Distributed Mobility Management
DNS Domain Name System
DS Dual-Stack
DSRC Dedicated Short Range Communication
EARO Extended Address Registration Option
EDCA Enhanced Distributed Channel Access
EDM Edge Dynamic Map
EIID Extended Interface Identifier
EPS Evolved Packet System
ESP Encapsulation Security Payload
ES-PT Spain-Portugal
ESS Extended Service Set
EUI End-system Unique Identifier
FN Foreign Network
FOT Field Operational Tests
GLOSA Green Light Optimal Speed Advisory
GN Geo Networking
GPRS General Packet Radio Service
GR Group Report
GR-TR Greece-Turkey
GUA Global Unique Address
GVL Geographical Virtual Link
HA Home Agent
ETSI
10 ETSI GR IP6 030 V1.1.1 (2020-10)
HD High Definition
HIP Host Identity Protocol
HMI Human Machine Interface
HN Home Network
HoA Home of Address
HR Home Router
HSS Home Subscriber server
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IAB Internet Architecture Board
ICT Information and Communications Technology
IDC Internet Data Centre
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IID Interface Identifier
IKEv2 Internet Key Exchange version 2
IMS IP Multimedia Subsystem
IMT International Mobile Telecommunications
IoT Internet of Things
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IPWAVE IP Wireless Access in Vehicular Environments
ISP Internet Service Provider
ITS Intelligent Transport System
ITS-G 5,9 GHz Cooperative ITS system
ITU-R International Telecommunication Union - Radiocommunication Sector
ITU-T International Telecommunication Union - Telecommunication Standardization Sector
LAN Local Area Network
LISP Locator/ID Separation Protocol
LLA Link Local Address
MAC MAC Medium Access Control layer
MANET Mobile Ad-hoc NETworks
MCoA Mobile Care of Address
MIIT Ministry of Industry and Information Technology (China)
MIPv6 Mobile IPv6
MLSN Multi-Link Subnet
MME Mobile Management Entity
MN Mobile Node
MNN Mobile Network Node
MNO Mobile Networks Operator
MNP Mobile Network Prefix
MR Mobile Router
NA/RA Neighbor Advertisement/ Router Advertisement
NAT Network Address Translation
NBMA Non-Broadcast Multi-Access
NCC Network Control Center
ND Neighbour Discovery
NDP Neighbour Discovery Protocol
NEMO BS NEtwork MObility Basic Support
NEMO Network Mobility
NGMN Next Generation Mobile Network
NR 5G New Radio interface
NS Neighbor Solicitation
NS/NA Neighbour Solicitation/Neighbour Advertisement
OCB Outside the Context of a BSS
OFDM Orthogonal Frequency Division Multiple Access
OLSR Optimised Link State Routing
OS Operating System
OSI Open Systems Interconnection
PDN Packet Data Network
PDP Packet Data Protocol
ETSI
11 ETSI GR IP6 030 V1.1.1 (2020-10)
PGW Packet data network GateWay
PHY Physical Layer (protocol layer)
PIO Prefix Information Option
PLMN Public Landline Mobile Network
PLT Page Load Time
PS Pilot Site
RA Router Advertisement
RAT Radio Access Technologies
RAW Reliable and Available Wireless
RFC Request For Comments
RIPE Reseaux IP Europeens
RPL Routing Protocol for Low-Power and Lossy Networks
RS Router Solicitation
RSU Road Side Unit
RTT Round Trip Time
RUM Real User Monitoring
SA Security Association
SAD Security Association Database
SC-FDMA Single Carrier-Frequency Division Multiple Access
SCMS Security Credential Management Systems
SLLAO Source Link-Layer Address Option
SMF Session Management Function
SNMA Solicited-Node Multicast Address
SPD Security Policy Database
SSH Secure Shell
SSL Secure Socket Layer
STA Station
STD STandarD
TC (ETSI) Technical Committee
TCP Transmission Control Protocol
TD Temporary Document
TLS Transport Layer Security
UDM Unified Data Management
UDP User Datagram Protocol
UE User Equipment
ULA Unique Local Address
UMTS Universal Mobil Telecommunications System
UP User Plane
V2X Vehicle to everything
VoIP Voice over IP
VoLTE Voice over Long Term Evolution
VRU Vulnerable Road User
WI Work Item
WiMAX™ Worldwide interoperability for Microwave Access
WLAN Wireless Local Area Network
WPAN Wireless Personal Area Network
ETSI
12 ETSI GR IP6 030 V1.1.1 (2020-10)
4 IPv6-based Vehicular Networking (V2X)
4.1 Introduction
Internet protocol version 6 (IPv6) is a new version of the Internet protocol (IP) defined in IETF RFC 8200 [i.21] and
designed to replace Internet protocol version 4 (IPv4). IPv6 provides several advantages that cover important needs in
cooperative vehicular communication, such as the large space of addressing due to the exhaustion of IPv4 address
space, which impacts the growing of internet continuity. In fact, most mobile terminals will not be able to connect to
IPv4 Internet without the intermediate technology called Network Address Translation (NAT) [i.22], which allows one
or more public addresses to serve many private IP addresses in order to conserve addresses, hence the importance of
using IPv6 which goes from 32-bit addressing to 128-bit addressing. Dual stack [i.23] is considered as one of the most
used mechanisms that applies migration from IPv4 to IPv6. It allows the implementation of IPv4 and IPv6 in terminals
in order to use IPv4 access services that have not yet been migrated to IPv6.
In addition to all the advantages already mentioned, IPv6 protocol also brought other numerous benefits such as the
improvement of mobility and security services and mainly the addition of node auto-configuration mechanisms to
facilitate the configuration of connected equipment. In fact, one of the main functions of an IPv6 node based on its
ability to be configured automatically when its connected to a network using router discovery message ICMPv6
(Internet Control Message Protocol version 6). During this mechanism, an address named (Link-Local) is created by
IPv6 node in order to search for the routers present on its network segment using the Neighbour Discovery Protocol
(NDP) [i.33] and connect to other nodes connected to the same communication channel.
In order to obtain an IPv6 global address, the IPv6 node sends a router solicitation message using as destination the
multicast address (FF01 :: 2). After receiving this message, the routers respond with a Router advertisement (RA)
message, which is often transmitted periodically by routers and contain IPv6 prefix to all nodes located on their
network. When receiving the RA messages, the node creates its IPv6 address by adding its network identifier extracted
from its Mac address, to the received IPv6 prefix. Finally, to avoid double assignment of IPv6 addresses, the IPv6 node
performs Duplicate Address Detection (DAD) for the newly generated IPv6 address.
This mechanism of auto-configuration is called stateless, because nodes can be configured without using manual
configuration or a help of a server such as DHCPv6 (Dynamic Host Configuration Protocol version 6), and it is very
important in the vehicular network, because it offers fast connectivity with other ITS station and reduce latency.
4.2 IPv6 Transition Strategies
Currently several IPv6 transition strategies can be identified. The main IPv6 transition strategies that are being
discussed by Mobile Network Operators (MNOs), see e.g. [i.1] and [i.2], are listed below. More details on mobile
networks considerations for IPv6 deployment are described in [i.3].
• IPv4 only: delays the introduction of IPv6 to a later date and remain an all-IPv4 network. Over the long term,
it is expected that this transition strategy will lead to problems and increased costs for the MNO. Due to the
increase in traffic, see 5G requirements, there will be an increased demand for IP addresses and on using NAT
in the carriers' network, denoted as Carrier Grade Network Address Translation (CG-NAT). In particular, all
traffic to and from the Internet will have to pass CG-NAT. Furthermore, growth in bandwidth demand can
only be handled with increased CG-NAT capacity, which has a higher cost. It means that the MNO is unable
to benefit from the increasing ratio of IPv6-to-IPv4 Internet traffic. This mechanism works only for
DNS-based applications and IPv4-only.
• Coexistence of IPv4 and IPv6: requires the use of a dual stack, introducing IPv6 in the network next to IPv4.
For an MNO, this approach is a less desirable option because dual-stack networks are more complex to deploy,
operate, and manage. Furthermore, this option also requires an address management solution for both IPv4 and
IPv6 addresses.
ETSI
13 ETSI GR IP6 030 V1.1.1 (2020-10)
• IPv6 only: introduces IPv6 in the network and remove IPv4 completely. This approach can provide benefits
for an MNO, because IPv6-only networks are simpler to deploy, operate, and manage. Moreover, an address
management solution is required only for IPv6 addresses. Therefore, this option has no impact on scale,
charging, and roaming because only a single bearer with a single stack is required. However, the problem with
this approach is that many UE (User Equipment) devices, websites, and applications still only work on IPv4.
When moving to an IPv6-only network may lead to inferior service for MNO customers, resulting in customer
dissatisfaction.
• Enhanced IPv6 only + NAT64: in addition to offering IPv6 only, also IPv4 is offered as a service over IPv6
for DNS-based applications. For the MNO, benefits from the advantages of the IPv6 only strategy and at the
same time, there is no impact on scale, charging, and roaming as only a single bearer with a single stack is
required. DNS64 (Domain Name System 64) also embeds IPv4 Internet destinations in IPv6 addresses.
However, non-DNS applications are not supported and will be broken, which could result in a lower quality
service for the operator's customers.
• Enhanced IPv6 only + 464XLAT: this strategy benefits from the advantages provided by the IPv6 only +
NAT64 solution and at the same time it solves the drawback associated with the support of non-DNS
applications. In particular, For IPv4-only, non-DNS applications, IPv4 packets are translated to IPv6 packets
by the UE and subsequently are translated back to IPv4 packets by a central CG-NAT64, which is deployed
behind the PGW (PDN Gateway).
More details on the IPv4 to IPv6 transition are provided in ETSI GR IP6 006 [i.4].
4.3 World Wide V2X Standardisation Initiatives
4.3.1 Applying IPv6 to Extra-Vehicular Communication ®
The emergence of automotive Ethernet for in-vehicle communications and variations of Wi-Fi designed to operate
outside of the context of a BSS (IEEE Std 802.11™ [i.51] OCB and new work from TG 802.11bd) naturally brings in
the need for IP communications. IP enables to leverage:
i) ICT technologies such as Internet access;
ii) AI and big data for applications such as video, LiDAR, and traffic-sign recognition inside the car;
iii) Connectivity-based services such as remote diagnostics, location based services, autonomous vehicles and
Cooperative-Advanced Driving Assistance Systems (C-ADAS).
While it seems simple to design a model for IP subnets inside the vehicle that connects and isolates functions and ECUs
as required, the connectivity to the outside appears a lot more problematic:
• IP addresses are normally assigned to fixed locations around an abstract link where a subnet resides. Subnets
are then aggregated by routers in larger and larger aggregations that are finally advertised in the Internet
default-free zone. This is what routable addresses mean. But the vehicle and the prefixes within are mobile,
and a technology such as Network Mobility (NEMO) is required to maintain IP connectivity and session
continuity from the inside to the outside of the vehicle at all times.
• Cars may be moving together and may need to maintain connectivity within the platoon whether connectivity
to the larger internet is available or not. Depending of the type of swarming (relative movement inside the
platoon) and the size of the platoon (average number of relays), one of the possible Mobile Ad-hoc Network
(MANET) technologies may be more appropriate than another.
th
• IPv4 addresses are running out; RIPE NCC ran out on November 25 , 2019. With millions of cars produced
each year and several subnets inside each car, it makes sense to leverage IPv6 and IPv6-specific types of
addresses such as unique-local addresses (ULA) to design the networks inside the cars and define their
interconnectivity at Layer-3. While it is possible to tunnel the traffic to the outside in IPv4 tunnels or to apply
NAT64 techniques, vehicle communication will hugely benefit from a pervasive native IPv6 access.
ETSI
14 ETSI GR IP6 030 V1.1.1 (2020-10)
• As the vehicle moves, it may be connected to the Internet, other vehicles or the infrastructure with one or more ®
of 3GPP networks (LTE, 5G), Wi-Fi hotspot (e.g. with openroaming), and specialized V2X communication
such as OCB. Each of these communication methods has its own challenges in terms of geographical
availability and bandwidth. Selecting a technology or a set of technologies at every point of time and deciding
whether to leverage redundant transmissions is now being discussed in the context of Reliable and Available
Wireless (RAW) networking.
• Wireless LANs in particular present unique challenges for IP communications, that are not fully resolved at
the IETF. As unrelated cars move in and out an access location, which ones are members of a local subnet and
for how long? When should a vehicle form an address and for how long should it retain that state? Should that
address be preserved for that vehicle and for how long? Indeed, what is the Link model for IPv6 in that case?
4.3.2 Modelling IPv6 Links and Subnets over a Wireless LAN
At the physical (PHY) Layer, a broadcast domain is the set of nodes that may receive a datagram that one sends over an
interface, i.e. the set of nodes in range of radio transmission. On WLAN and WPAN radios, the physical broadcast
domain is defined by a particular transmitter, as the set of nodes that can receive what this transmitter is sending.
Literally every datagram defines its own broadcast domain since the chances of reception of a given datagram are
statistical. In average and in stable conditions, the broadcast domain of a particular node can still be seen as mostly
constant and can be used to define a closure of nodes on which an upper-layer abstraction can be built.
A PHY-layer communication can be established between 2 nodes if their physical broadcast domains overlap. On
WLAN and WPAN radios, this property is usually symmetrical, meaning that if B can receive a datagram from A, then
A can receive a datagram from B. But there can be asymmetries due to power levels, interferers near one of the
receivers, or differences in the quality of the hardware (e.g. crystals, Power Amps and antennas) that may affect the
balance to the point that the connectivity becomes mostly uni-directional, e.g. A to B but practically not B to A.
It takes a particular effort to place a set of devices in a fashion that all their physical broadcast domains fully overlap,
and it cannot be assumed in the general case. In other words, the property of radio connectivity is generally not
transitive, meaning that A may be in range with B and B may be in range with C does not necessarily imply that A is in
range with C.
With IEEE Std 802.11™ OCB, the broadcast domain that is usable at the MAC layer is the same as the physical ®
broadcast domain. This contrasts with the MAC-layer Broadcast Emulation schemes that Wi-Fi provides with the
IEEE Std 802.11™ [i.51] Infrastructure Basic Service Set (BSS).
A BSS provides a closure of nodes as defined by the broadcast domain of a central Access Point (AP). The AP relays
both unicast and broadcast packets and ensures a symmetrical and transitive emulation of the shared wire between the
associated nodes, with the capability to signal link-up/link-down to the upper layer. Within an Infrastructure BSS, the
physical broadcast domain of the AP serves as emulated broadcast domain for all the nodes that are associated to the
AP. Broadcast packets are relayed by the AP and are not acknowledged. To ensure that all nodes in the BSS receive the
broadcast transmission, AP transmits at the slowest PHY speed. This translates into maximum co-channel interferences
for others and longest occupancy of the medium, for a duration that can be 100 times that of a unicast. For that reason, ®
upper layer protocols should avoid the use of broadcast when operating over Wi-Fi .
IPv6 defines the (physical) concept of an IP Link, a Link Scope and Link-Local Addresses (LLA), an LLA being unique
and usable only within the Scope of a Link. On wired media, the Link is often confused with the physical broadcast
domain because both are determined by the serial cable or the Ethernet shared wire. Ethernet Bridging reinforces that
illusion by providing a MAC-Layer broadcast domain that emulates a physical broadcast domain over the mesh of
wires. But the difference shows on legacy Non-Broadcast Multi-Access (NBMA) such as ATM and Frame-Relay, on
shared links and on newer types of NBMA networks such as radio and composite radio-wires networks. It also shows
when private VLANs or Layer-2 cryptography restrict the capability to read a frame to a subset of the connected nodes.
In Infrastructure BSS, the IP Link extends beyond the physical broadcast domain to the emulated MAC-Layer broadcast
domain. But with OCB radios, IP Links between peers come and go as the individual physical broadcast domains of the
transmitters meet and overlap. The nodes may need to form new LLAs to talk to one another and the scope where LLA
uniqueness can be dynamically checked is that pair of nodes. As long as there is no conflict a node may use the same
LLA with multiple peers, but it has to recheck for address duplication with every new peer node. In practice, each pair
of nodes defines a temporary P2P link, which can be modelled as a sub-interface of the radio interface.
ETSI
15 ETSI GR IP6 030 V1.1.1 (2020-10)
IPv6 also defines the (logical) concept of Subnet for Global and Unique Local Addresses. Addresses in the same Subnet
share the same prefix and, by extension, a node belongs to a Subnet if it has an interface with an address on that Subnet.
A Subnet prefix is Globally Unique, so it is sufficient to validate that an address that is formed from a Subnet prefix is
unique within that Subnet to guarantee that it is globally unique. IPv6 aggregation relies on the property that a packet
from the outside of a Subnet can be routed to any router that belongs to the Subnet, and that this router will be able to
either resolve the destination MAC address and deliver the packet, or route the packet to the destination within the
Subnet. If the Subnet is known as on-link, then any node may also resolve the destination MAC address and deliver the
packet directly, but if the Subnet is not on-link, then a host will need to pass the packet to a router for forwarding.
On IEEE Std. 802.3™ [i.52], a Subnet is often congruent with an IP Link because both are determined by the physical
attachment to an Ethernet shared wire or an IEEE Std. 802.1™ [i.53] bridged broadcast domain. In that case, the
connectivity over the Link is transitive, the Subnet can appear as on-link, and any node can resolve a destination
MAC address of any other node directly using the IPv6 Neighbour Discovery (IETF RFC 4861 [i.33] and
IETF RFC 4862 [i.34]) Protocol (IPv6 ND).
But an IP Link and an IP Subnet are not always congruent. In a shared Link situation, a Subnet may encompass only a
subset of the nodes connected to the Link. In Route-Over Multi-Link Subnets (MLSN) (see IETF RFC 4903 [i.55]),
routers federate the Links between nodes that belong to the Subnet, the Subnet is not on-link and it extends beyond any
of the federated Links. The routing service can be a simple reflexion in a Hub-and-Spoke Subnet that emulates an IEEE
Std 802.11™ [i.51] Infrastructure BSS at Layer-3. It can also be a full-fledge routing protocol such as RPL
(IETF RFC 6550 [i.35]). RPL was designed to adapt to various LLNs such as WLAN and WPAN radio MLSNs.
Finally, the routing service can also be an ND proxy function that emulates an IEEE Std 802.11™ [i.51] Infrastructure
ESS at Layer 3.
The basic procedures of IPv6 ND expect that a node in a Subnet is reachable within the broadcast domain of any other
node in the Subnet when that other node attempts to form an
...