One document matched: draft-baldessari-c2ccc-nemo-req-00.txt
NEMO R. Baldessari
Internet-Draft NEC Europe
Intended status: Informational A. Festag
Expires: August 27, 2007 NEC Germany
M. Lenardi
Hitachi Europe
February 23, 2007
C2C-C Consortium Requirements for Usage of NEMO in VANETs
draft-baldessari-c2ccc-nemo-req-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Vehicular ad hoc Networks (VANETs), self-organized networks based on
short-range wireless technologies, aim at improving road safety and
providing comfort and entertainment applications. The Car2Car
Communication Consortium is defining a European standard for inter-
vehicle communication that adopts VANETs principles. This document
Baldessari, et al. Expires August 27, 2007 [Page 1]
Internet-Draft Requirements for NEMO in VANETs February 2007
describes the scope, use cases and requirements for a solution based
on Network Mobility (NEMO) in VANETs as identified by the Consortium.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the Car-to-Car Communication Architecture . . . . 5
3.1. Current System Architecture . . . . . . . . . . . . . . . 6
3.2. Current Protocol Architecture . . . . . . . . . . . . . . 9
3.3. Interaction with IPv6 . . . . . . . . . . . . . . . . . . 10
4. Scope of NEMO . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Notification Services . . . . . . . . . . . . . . . . . . 12
5.2. Peer-to-peer Applications . . . . . . . . . . . . . . . . 13
5.3. Upload and Download Services . . . . . . . . . . . . . . . 13
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. V2V and V2I Communication Modes . . . . . . . . . . . . . 14
6.2. Same Identifiers for V2V and V2I . . . . . . . . . . . . . 14
6.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Baldessari, et al. Expires August 27, 2007 [Page 2]
Internet-Draft Requirements for NEMO in VANETs February 2007
1. Introduction
In Vehicular ad hoc Networks (VANETs), cars are equipped with short-
range wireless communication devices that operate at frequencies
dedicated to safety and non-safety vehicular applications. When
entering the proximity of each other, vehicles form a self-organized
network by means of a specialized routing protocol that allows for
packet exchange through broadcast and unicast communications.
Further, fixed communication devices are installed along roadsides
and can either distribute local warnings or offer connectivity with a
network infrastructure. Due to its safety-oriented nature and
extremely dynamic operational environment, this type of communication
has lead research to consider specialized protocols and algorithms,
especially concerning information dissemination, geographic
distribution of packets and privacy/security issues.
The Car2Car Communication Consortium is an industry consortium of car
manufacturers and electronics suppliers that focuses on the
definition of an European standard for vehicular communication
protocols. The Consortium gathers results from research projects and
aims at harmonizing their efforts. The first technical document [8],
to be released in the following months, gives an overview of the
system and protocol architecture, as well as of the applications on
which the Consortium has agreed so far. In essence, this document
defines a C2C-C protocol stack that offers specialized
functionalities and interfaces to (primarily) safety-oriented
applications and relies as a communication technology on a modified
version of [9]. This protocol stack is placed beside a traditional
TCP/IP stack, exclusively based on IPv6, which is used mainly for
non-safety applications or potentially by any application that is not
subject to strict delivery requirements, including Internet-based
applications. The interaction between these stacks is currently
discussed and briefly overviewed in this document.
As vehicles connecting to the Internet via dedicated access points
(also termed Road Side Units, see Section 2 for terminology) change
their attachment point while driving, the Consortium considers IP
Mobility support as enhancing the system with session continuity and
global reachability. When considering that passenger devices can be
plugged into car communication equipment, therefore turning a vehicle
into an entire moving network, Network Mobility (NEMO) principles
have clear benefits in the discussed scenario (i.e. passenger devices
shielded from mobility, centralized mobility management).
In VANETs, wireless multi-hop routing and forwarding are used to
extend the coverage area of attachment points, allowing vehicles that
are not in the proximity of a Road Side Unit to exchange packets with
the infrastructure. Furthermore, as the coverage of such access
Baldessari, et al. Expires August 27, 2007 [Page 3]
Internet-Draft Requirements for NEMO in VANETs February 2007
points is expected to be (at least short/mid term) very limited
compared with road extension, direct vehicle-to-vehicle packet
routing for both kinds of application (safety and non-safety) is
essential. These peculiar vehicular use cases require the
integration of NEMO Basic Support [1] with ad hoc routing in the
first case, an extension of NEMO to allow isolated vehicles to
communicate directly in the latter. Other specific use cases are
also described in this document.
This document intends to provide the IETF NEMO work group with an
overview of the C2C-C Consortium protocol architecture, selected use
cases and related requirements for the deployment of a vehicular-
specific solution based on Network Mobility principles. The document
is organized as follows: Section 2 defines terminology. Section 3
describes the C2C-C Consortium goals and technical approach.
Section 4 describes the intended scope of NEMO in vehicular
applications according to the C2C-C Consortium. Section 5 explains a
set of selected use cases. Finally Section 6 lists functional
requirements.
2. Terminology
The following terms used in this document are defined in the Mobile
IPv6 protocol specification [2]:
Home Agent (HA)
Home Address (HoA)
The following terms used in this document are defined in the Mobile
Network terminology document [6]:
Network Mobility (NEMO)
Mobile Network
Mobile Router (MR)
Mobile Network Prefix (MNP)
Mobile Network Node (MNN)
The following new terms are used in this document:
o On Board Unit (OBU): a device installed in vehicles, implementing
the communication protocols and algorithm and equipped with at
least 1) a short-range wireless network interface operating at
Baldessari, et al. Expires August 27, 2007 [Page 4]
Internet-Draft Requirements for NEMO in VANETs February 2007
dedicated frequencies and 2) a wireless or wired network interface
where Application Units (AU) can be attached to. With respect to
the NEMO terminology, the OBU is the physical machine acting as
MR.
o Application Unit (AU): a portable or built-in device connected
temporarily or permanently to the vehicle OBU. It is assumed that
AUs support a standard TCP/IPv6 protocol stack, optionally
enhanced with IP Mobility support. With respect to the NEMO
terminology, an AU is a generic MNN.
o Road Side Unit (RSU): a device installed along roadsides
implementing the same communication protocols and algorithms as an
OBU. RSUs can either be isolated or connected to a network
infrastructure. In the latter case, RSUs are attachment points
either acting themselves as IPv6 access routers or as network
bridges directly connected to an access router.
o In-vehicle network: the wireless or wired network placed in a
vehicle and composed by (potentially) several AUs and one OBU.
o Vehicle-to-Vehicle (V2V) Communication Mode: a generic
communication mode in which data packets are exchanged between two
vehicles, either directly or by means of multi-hop routing,
without involving any node in the infrastructure.
o Vehicle-to-Infrastructure (V2I) Communication Mode: a generic
communication mode in which data packets sent or received by a
vehicle traverse a network infrastructure.
o Vehicle-to-Infrastructure-to-Vehicle (V2I2V) Communication Mode: a
generic communication mode in which data packets are exchanged
between two vehicles, by means of multi-hop routing involving a
RSU not connected to a network infrastructure.
3. Overview of the Car-to-Car Communication Architecture
The Car2Car Communication Consortium [7] is a non-profit organization
initiated by European vehicle manufacturers that is open for
suppliers, research organizations and other partners. The Car2Car
Communication Consortium is dedicated to the objective of further
increasing road traffic safety and efficiency by means of inter-
vehicle communications.
The goals of the Car2Car Communication Consortium [8] are:
Baldessari, et al. Expires August 27, 2007 [Page 5]
Internet-Draft Requirements for NEMO in VANETs February 2007
o Create and establish an open European industry standard for inter-
vehicle communication systems based on wireless LAN components and
guarantee European-wide inter-vehicle operability.
o Enable the development of active safety applications by
specifying, prototyping and demonstrating the Car2Car
Communication system.
o Promote the allocation of a royalty free European wide exclusive
frequency band for Car2Car applications.
o Push the harmonization of Car2Car Communication standards
worldwide.
o Develop realistic deployment strategies and business models to
speed up the market penetration.
3.1. Current System Architecture
The draft reference architecture of the C2C communication system is
shown in Figure 1.
Baldessari, et al. Expires August 27, 2007 [Page 6]
Internet-Draft Requirements for NEMO in VANETs February 2007
| Internet |
| |
+---+-----------------+-+
| |
Access +--+-+ +--+-+ Access
Router | AR | | AR | Router
+--+-+ +--+-+
| |
--+---+--- --+---+--
| |
Road Side +--+--+ +--+--+ Public
Unit | RSU | | PHS | Hot Spot
+---+-+ +---+-+
| |
/\ /\
\_ \_
\_ \_
\ \
Mandatory \/
Mod IEEE 802.11p | __ \/ Optional IEEE
Interface +---+--+ \__ \/ | 802.11a/b/g
| OBU1 | | | Interface
+--+---+ +-+-----+---+
Vehicle1 | | OBU2 | On-Board
-+---+-+- +--+--------+ Unit
| | | Vehicle2
Application +--+-+ +-+--+ --+--+--
Units | AU | | AU | |
+----+ +----+ +-+--+
| AU |
+----+
Figure 1: C2C-CC Reference Architecture
Vehicles are equipped with networks logically composed of an OBU and
potentially multiple AUs. An AU is typically a dedicated device that
executes a single or a set of applications and utilizes the OBU
communication capabilities. An AU can be an integrated part of a
vehicle and be permanently connected to an OBU. It can also be a
portable device such as laptop, PDA or game pad that can dynamically
attach to (and detach from) an OBU. AU and OBU are usually connected
with wired connection, but the connection can also be wireless, such
as Bluetooth. The distinction between AU and OBU is logical, they
can also reside in a single physical unit.
Vehicles' OBUs and stationary units along the road, termed road-side
Baldessari, et al. Expires August 27, 2007 [Page 7]
Internet-Draft Requirements for NEMO in VANETs February 2007
units (RSUs), form an ad hoc network. An OBU is at least equipped
with a (short range) wireless communication device based on draft
standard IEEE 802.11p [9] (adapted to European conditions and with
specific C2C-C extensions) primarily dedicated for road safety, and
potentially with other optional communication devices. OBUs directly
communicate if wireless connectivity exist among them. In case of no
direct connectivity, multi-hop communication is used, where data is
forwarded from one OBU to another, until it reaches its destination.
For example in Figure 1, RSU and OBU1 have direct connectivity,
whereas OBU2 is out of RSU radio coverage but can communicate with it
through multi-hop routing.
The primary role of an RSU is improvement of road safety. RSUs have
two possible configuration modes: as isolated nodes, they execute
applications and/or extend the coverage of the ad hoc network
implementing routing functionalities. As attachment point connected
to an infrastructure network, RSUs distribute information originated
in the infrastructure and offer connectivity to the vehicles. As
result, for example, the latter configuration allows AUs registered
with an OBU to communicate with any host located in the Internet,
when at least one RSU connected to a network infrastructure is
available.
An OBU may also be equipped with alternative wireless technologies
for both, safety and non-safety. For example, an OBU may also
communicate with Internet nodes or servers via public WLAN hot spots
(PHS) operated individually or by wireless Internet service
providers. While RSUs for Internet access are typically set up with
a controlled process by a C2C-C key stake holder, such as road
administrators or other public authorities, public hot spots are
usually set up in a less controlled environment. These two types of
infrastructure access, RSU and PHS, also correspond to different
applications types. Other communication technology, such as wide
coverage/cellular networks (e.g. UMTS, GPRS) may also be optionally
installed in OBUs, but their usage is currently considered out of
scope of the C2C-CC Consortium.
The C2C-CC commonly refers to two main communication modes:
o in Vehicle-to-Vehicle (V2V) mode, data packets are exchanged
directly between OBUs, either via multi-hop or not, without
involving any RSU;
o in Vehicle-to-Infrastructure mode (V2I), an OBU exchanges data
packets through a RSU with an arbitrary node connected to the
infrastructure (potentially another vehicle not attached to the
same RSU).
Baldessari, et al. Expires August 27, 2007 [Page 8]
Internet-Draft Requirements for NEMO in VANETs February 2007
3.2. Current Protocol Architecture
The protocol stack currently considered by C2C-CC for OBUs is
depicted in Figure 2.
+--------------------+------------------+
| | |
| C2C-CC | IP-based |
| Applications | Applications |
| | |
+--------------------+------------------+
| | TCP/UDP/... |
| C2C-CC Transport +------------------+
| | |
+--------------------+-----+ IPv6 |
| | |
| C2C-CC Network | |
| | |
+--------------------+-----+------------+
| Modified | Standard WLAN |
| IEEE 802.11p | IEEE 802.11a/b/g |
+--------------------+------------------+
Figure 2: OBU Protocol Stack
Protocol blocks are explained in the following list:
o Modified IEEE 802.11p: this block represents MAC and PHY layers of
a wireless technology based upon current draft standard IEEE
802.11p [9] but modified for usage in Europe. In Europe,
allocation of dedicated frequencies around 5.9 GHz for safety and
non-safety applications is in progress. Expected communication
range in line of sight is around 500m. This network interface is
mandatory.
o IEEE 802.11a/b/g: this block represents MAC and PHY layers
provided by one ore more IEEE 802.11a/b/g network interfaces.
This network interface is optional but C2C-C Consortium encourages
its installation.
o C2C-CC Network: this block represents the network layer protocol
currently defined by C2C-CC. The protocol provides secure ad hoc
routing and forwarding, as well as addressing, error handling,
packet sequencing, congestion control and efficient information
dissemination. The specification of this protocol is currently
under discussion. Only the C2C-CC Network protocol can access the
Modified IEEE 802.11p network interface. The C2C-CC Network
protocol can also access the IEEE 802.11a/b/g interface. The
Baldessari, et al. Expires August 27, 2007 [Page 9]
Internet-Draft Requirements for NEMO in VANETs February 2007
C2C-CC Network protocol offers an interface to the IPv6 protocol.
This interface allows IPv6 headers and payload to be encapsulated
into C2C-CC Network datagrams and sent over the Modified IEEE
802.11p or IEEE 802.11a/b/g network interface. The specification
of this interface is currently under discussion. A primary goal
of the C2C-CC Network layer is to provide geographic routing and
addressing functionalities for cooperative safety applications.
Through the mentioned interface to the IPv6 protocol, these
functionalities are also available for IP-based applications.
o C2C-CC Transport: this block represents the transport layer
protocol currently defined by C2C-CC. This protocol provides a
selected set of traditional transport layer functionalities (e.g.
application data multiplexing/demultiplexing, connection
establishment, reliability etc.). The specification of this
protocol is currently under discussion.
o C2C-CC Applications: this block represents the application layer
protocol currently defined by C2C-CC and concerns Active Safety
and Traffic Efficiency Applications.
3.3. Interaction with IPv6
As described in Section 3.2, the C2C-CC includes IPv6 as mandatory
part of its specified protocol architecture. Currently, three
methods are discussed for transmission of IPv6 headers and their
payload:
o On the Modified IEEE 802.11p interface via the C2C-CC Network
layer: in this method, IPv6 headers are encapsulated into C2C-CC
Network headers and sent using dedicated frequencies for inter-
vehicle communications. As the C2C-CC Network layer transparently
provides ad hoc routing, from the IPv6 layer perspective other
nodes (OBUs and RSU) are attached to the same link. With respect
to a currently adopted terminology, introduced in [10], the C2C-C
Consortium approach for usage of NEMO on the Modified IEEE 802.11p
is fully MANET-Centric, in the sense that the protocol layer below
IPv6 provides routing and forwarding in the ad hoc network, with
the result that the ad hoc nature of VANETs is hidden from upper
layers. A comparison of approaches for VANETs can be found in
[11]. The deployability of this method strongly depends on the
future availability of dedicated frequencies for non-safety
purposes in inter-vehicle communications. If frequencies for this
purpose will not be allocated, only the left part of the protocol
stack of Figure 2 can access the Modified IEEE 802.11p interface.
o On the IEEE 802.11a/b/g interface via the C2C-CC Network layer: in
this method, IPv6 headers are encapsulated into C2C-CC Network
Baldessari, et al. Expires August 27, 2007 [Page 10]
Internet-Draft Requirements for NEMO in VANETs February 2007
headers and sent using license-free ISM frequency bands (wireless
LAN). Except the network interface, this method is equivalent to
the previous one.
o On the IEEE 802.11a/b/g interface directly: in this method, IPv6
headers are sent directly to the wireless LAN interface as
specified by [5].
The following informational list briefly summarizes currently
discussed design concepts:
o vehicles use only IPv6 addresses with as host part an EUI-64
identifier derived from the MAC address. Privacy issues described
in [4] are strongly alleviated through the use of temporary,
changing MAC addresses, which are assigned in a set to every
vehicle (as part of their assigned "pseudonyms");
o when a RSU connected to a network infrastructure is available, an
OBU configures a globally routable Care-of Address using stateless
address configuration;
o when infrastructure access is not available, OBUs use addresses
with as prefix part a predefined IPv6 prefix reserved for C2C-C
communications (TBD);
o RSU can either act as IPv6 Access Routers or as network bridges
connected to external IPv6 Access Routers. Different Access
Routers are responsible for announcing different network prefixes
with global validity. As a consequence, when roaming between
different Access Routers, vehicles experience layer 3 handovers.
In all the methods for use of IPv6 in C2C-C systems as described
above, the IPv6 layer is meant to be enhanced with Mobility Support.
As a vehicle includes a set of attached devices (AUs), Network
Mobility seems the most appropriate solution, allowing for a
centralized management of mobility to be executed in OBUs.
4. Scope of NEMO
In VANETs based on IEEE 802.11 family, a limited amount of bandwidth
is shared among a potentially high number of vehicles. Additionally
applications for safety purposes have strict requirements in terms of
delay, information dissemination and aggregation and secure ad hoc
routing. This conflicting conditions have led research activities to
consider different approaches compared with traditional, packet-
centric network engineering. In particular, only through a more
information-centric approach it seems possible to achieve
Baldessari, et al. Expires August 27, 2007 [Page 11]
Internet-Draft Requirements for NEMO in VANETs February 2007
functionalities like geographic distribution, information
dissemination according to relevance, information aggregation using
cross-layer analysis, plausibility checks at different protocol
layers.
Taking these aspects into consideration, the C2C-C Consortium is
defining a protocol stack mainly dedicated for vehicular safety
communications. Applications that are not subject to these
particular requirements must use the right part of the protocol stack
of Figure 2. This implies that the usage of NEMO in vehicular
communications does not target safety-of-life applications but rather
less restrictive, non-safety applications.
Another important aspect for deployability is related to costs. A
primary goal of the C2C-C Consortium is to achieve a spread diffusion
in terms of vehicles equipped with communication devices and
protocols. This implies that vehicles of different brands and
classes should be equipped by default with a basic communication
system, whereas differentiation of products can be achieved by
offering additional services. NEMO, like any other solution based on
IP Mobility support, relies on a service provider that guarantees
global reachability at the Home Network Prefix by maintaining an Home
Agent. As it does not seem realistic that every car owner will also
subscribe for such a service, a set of limited applications based on
IPv6 should be available even without Mobility Support. Therefore,
NEMO modularity and interoperability with non-NEMO equipped vehicles
has to be guaranteed.
5. Example Use Cases
In this section, the main use cases are listed that have been
identified by the C2C-CC for usage of NEMO in inter-vehicle
communications: notification services, peer-to-peer applications and
upload/download services.
5.1. Notification Services
A generic notification service delivers information to subscribers by
means of the Internet. After subscribing the service with a
provider, a user is notified when updates are available. Example
services are weather, traffic or news reports, as well as commercial
and technical information from the car producer or other companies.
As the network address of a vehicle changes while the vehicle moves
among different points of attachment, each application should
register the new address in order to receive information at the
correct location. Service providers need to update continuously the
Baldessari, et al. Expires August 27, 2007 [Page 12]
Internet-Draft Requirements for NEMO in VANETs February 2007
subscription data and are able to track the users. Adopting global
reachability at a reasonably constant identifier (e.g. Mobile
Network Prefix), efficiency and location privacy improve
considerably.
5.2. Peer-to-peer Applications
A generic peer-to-peer application exchanges data directly between
vehicles, without contacting any application server. Data traffic
goes through a network infrastructure (V2I) or directly between cars
when the infrastructure is not available (V2V). Example applications
are vehicle-to-vehicle instant messaging (chat) and off-line
messaging (peer-to-peer email), vehicle-to-vehicle voice over IP and
file exchange.
In this set of use cases, the same applications should be able to run
in V2V and V2I mode. As applications should not be aware of routing
nor addressing issues, they should use the same identifier for
sessions and users (e.g. cars/drivers/passengers) independently of
the communications mode. Possible approaches are either to adopt
resolution mechanisms or actually maintain the same network
identifier in both V2V and V2I modes. This could be achieved for
example generalizing the concept of Mobile Network Prefix (MNP) and
allowing a Mobile Router (OBU) to use it for V2V communications in
absence of attachment points. By means of enforcing limited lifetime
for IPv6 prefixes and due to the isolation of VANET clusters from the
infrastructure (in V2V), this use of MNP should not introduce routing
inconsistencies.
5.3. Upload and Download Services
A generic upload/download service via the Internet consists in simple
file exchange procedures with servers located in the Internet.
As in vehicular scenarios the connectivity to the infrastructure is
highly intermittent, network address' changes cause applications to
re-establish sessions in order to resume the exchange, which implies
considerable overhead. Session re-establishment can be avoided
adopting NEMO.
6. Requirements
The C2C-C Consortium has identified the following requirements for a
NEMO solution for vehicular communications, with respect to the
referred use cases.
Baldessari, et al. Expires August 27, 2007 [Page 13]
Internet-Draft Requirements for NEMO in VANETs February 2007
6.1. V2V and V2I Communication Modes
A vehicle equipped only with a Modified IEEE 802.11p interface can
use V2V and V2I communication modes for IP-based applications running
in an OBU or in attached AUs. In other words, an OBU and the AUs
attached to it are able to exchange IP packets with a node in the
Internet (when a RSU connected to a network infrastructure is
available), indirectly via a not connected RSU, or directly with
other OBUs and AUs, even if a RSU is not available.
6.2. Same Identifiers for V2V and V2I
Vehicles and in-vehicle networks attached to are reachable at
identifiers (e.g. Mobile Network Prefix) that do not change
frequently and can be used both when the infrastructure is available
(V2I, e.g. through an Home Agent) and to communicate directly when
infrastructure is not available (V2V).
6.3. Security
As data security is mandatory for safety applications targeted by the
C2C-C Consortium and implemented in the left part of the protocol
stack depicted in Figure 2, any IP-based application must not
introduce new security leaks for the C2C-CC applications or render
their security measures ineffective. Further details can not be
provided at this point of time because solutions for security in the
C2C-CC protocol stack are still under discussion. As informational
references, see [13], [14] and [15].
6.4. Privacy
Privacy of drivers and passengers is mandatory for safety
applications targeted by the C2C-C Consortium. Mechanisms to
implement privacy in the left part of the protocol stack depicted in
Figure 2 are currently discussed (e.g. "revocable pseudonimity",
where pre-assigned, quasi-random and changing pseudonyms are used as
layer 2 and 2.5 identifiers). Therefore any IP-based application
must not allow for linking changed pseudonyms by sending constant
identifiers as clear text. In particular, encryption of Home Address
and Mobile Network Prefix in NEMO signaling should be mandatory in
VANETs and not optional as described in [3]. Furthermore, direct V2V
communication mode without the infrastructure using a constant MNP
might introduce the possibility to track vehicles. Further details
can not be provided at this point of time because solutions for
privacy in the C2C-CC protocol stack are still under discussion. As
informational reference, see [12].
Baldessari, et al. Expires August 27, 2007 [Page 14]
Internet-Draft Requirements for NEMO in VANETs February 2007
7. IANA Considerations
This document does not require any IANA action.
8. Security Considerations
This document defines requirements and therefore does not create any
security threat. However, it mentions security and privacy issues in
VANETs as currently discussed in the C2C-C Consortium.
9. Acknowledgments
The authors would like to thank the members of the work groups PHY/
MAC/NET and APP of the C2C-C Consortium and in particular Andras
Kovacs, Bernd Bochow and Matthias Roeckl for supporting and
commenting this document.
10. References
10.1. Normative References
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[4] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[5] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[6] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-06 (work in progress),
November 2006.
Baldessari, et al. Expires August 27, 2007 [Page 15]
Internet-Draft Requirements for NEMO in VANETs February 2007
10.2. Informative References
[7] "Car2Car Communication Consortium Official Website",
http://www.car-2-car.org/ .
[8] "Car2Car Communication Consortium Handbook", work in progress,
February 2007.
[9] "Draft Amendment to Standard for Information Technology .
Telecommunications and information exchange between systems .
Local and Metropolitan networks . specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) specifications: Amendment 3: Wireless Access in Vehicular
Environments (WAVE)", IEEE P802.11p/D1.0, February 2006.
[10] McCarthy, B., Edwards, C., Dunmore, M., and R. Aguiar, "The
Integration of Ad-hoc (MANET) and Mobile Networking (NEMO):
Principles to Support Rescue Team Communication", Proc. of
International Conference on Mobile Computing and Ubiquitous
Networking (ICMU 2006), October 2006.
[11] Baldessari, R., Festag, A., and J. Abeille, "NEMO meets VANET:
A Deployability Analysis of Network Mobility in Vehicular
Communication", Under submission, February 2007.
[12] Fonseca, E., Festag, A., Baldessari, R., and R. Aguiar,
"Support of Anonymity in VANETs - Putting Pseudonymity into
Practice", To appear in Proc.of IEEE Wireless Communication and
Networking Conference (WCNC2007), March 2007.
[13] Raya, M. and J. Hubaux, "The Security of Vehicular Ad Hoc
Networks", Proc.of Workshop on Security of Ad Hoc and Sensor
Networks (SASN2005), November 2005.
[14] Aijaz, A., Bochow, B., Doetzer, F., Festag, A., Gerlach, M.,
Leinmueller, T., and R. Kroh, "Attacks on Inter Vehicle
Communication Systems - an Analysis", Proc.of International
Workshop on Intelligent Transportation (WIT2006), March 2006.
[15] Fonseca, E. and A. Festag, "A Survey of Existing Approaches for
Secure Ad Hoc Routing and Their Applicability to VANETS", NEC
Technical Report NLE-PR-2006-19, March 2006.
Baldessari, et al. Expires August 27, 2007 [Page 16]
Internet-Draft Requirements for NEMO in VANETs February 2007
Authors' Addresses
Roberto Baldessari
NEC Europe Network Laboratories
Kurfuersten-anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342167
Email: roberto.baldessari@netlab.nec.de
Andreas Festag
NEC Deutschland GmbH
Kurfuersten-anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342147
Email: andreas.festag@netlab.nec.de
Massimiliano Lenardi
Hitachi Europe SAS Sophia Antipolis Laboratory
Immeuble Le Theleme
1503 Route des Dolines
Valbonne F-06560
France
Phone: +33 489 874168
Email: massimiliano.lenardi@hitachi-eu.com
Baldessari, et al. Expires August 27, 2007 [Page 17]
Internet-Draft Requirements for NEMO in VANETs February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Baldessari, et al. Expires August 27, 2007 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 08:30:19 |