Mobile VPN and V2V NEMO for Public Transportation

Download PDF
4 downloads 4836 Views 215KB Size Report
Comment
mostly entertainment services for passengers and urgent messaging and ... corporate network, while being able to change its point of attachment to the Internet ...
Mobile VPN and V2V NEMO for Public Transportation Alexandru Petrescu and Alexis Olivereau CEA LIST, Communicating Systems Laboratory Point Courrier 94 Gif-sur-Yvette, F-91191 France [email protected], [email protected] Abstract—In this paper we present an advanced method to offer differentiated Internet access to users of public transportation systems. On one hand, enterprise VPN access is offered to employees of the public transportation agency; on another hand, straight access to Internet is offered to passengers – both passengers and employees are part of same vehicular moving network. The double addressing scheme is equally enforced in the disconnected case, i.e. when direct Vehicle-to-Vehicle communications are used. Keywords — dual addressing scheme, mobile router to mobile router communications, vehicular communications, V2V, vehicleto-vehicle communications, public transportation, Mobile IPv6, network mobility, NEMO, Mobile VPN, MOBIKE.

I.

INTRODUCTION

T

HIS document presents novel technical approaches developed in the framework of a French collaborative project: SEAMLESS. This project generally aims at enabling continuous access to Internet services for the users of public transportation systems. Throughout the paper we assume that moving vehicles of the transportation agency (buses, tramways, subways) use IPv6 network mobility protocols, in particular NEMO [2], MOBIKE [3], Mobile VPN [4], [5] and related extensions to connect to the Internet. One traditional peculiarity of public transportation is the need to differentiate services according to user class. It is expected that different services will be allocated to different users, for example: mostly entertainment services for passengers and urgent messaging and professional database access for transportation company agents. This differentiation poses a number of problems to the most trivial IP deployments in moving vehicles. A passenger device should not be allowed visibility to traffic of a transportation agency employee device; yet, this happens naturally when the wireless network deployed in the vehicle is WiFi, and all devices are assigned IP addresses from the same Mobile Network Prefix. Moreover, whereas passenger devices in one vehicle should be able to communicate to same class devices in another vehicle, there should be no possibility for passenger devices in one vehicle to communicate to the transportation company agent devices in other vehicle, in order to avoid all attack possibility on the agency resources.

This work was supported in part by the French ANR (Agence Nationale de la Recherche).

In the following we first present a dual addressing scheme for secure IP mobility. The setting consists of a “Corporate” network, a DMZ and a moving network. We subsequently present the enforcement of the same dual addressing scheme to a disconnected situation, where vehicles are not connected to their Corporate/DMZ networks, but are able to connect directly to each other – a Vehicle-to-Vehicle communications situation II.

DOUBLE ADDRESSING SCHEME FOR SECURE MOBILITY

Two main solutions [4], [5] have been proposed to allow a roaming IPv4 host to remain securely connected to its corporate network, while being able to change its point of attachment to the Internet without disrupting its ongoing communications. These solutions combine: • An internal mobility mechanism (Mobile IPv4 as in [4] and [5], Proxy-Mobile IPv4 as in [6]), responsible for handling the mobility of the host within the corporate network, or between the corporate network and the Internet; • An external mobility mechanism (Mobile IPv4 as in [4], Mobike as in [5]), responsible for handling the mobility of the host between two points of attachment to the Internet. These two complementary mechanisms are required because an internal home agent ("internal" as per its respective position to the corporate VPN gateway) may not handle by itself the mobility of a node roaming between two external locations, outside the corporate network. The outgoing traffic of such node would indeed be routed back towards the VPN gateway first, then to the internal home agent. The care-of address seen by the internal home agent would then always be the (corporate) static IP address assigned by the VPN gateway to the roaming node and the internal home agent would therefore not be able to handle the external mobility of the node. Hence either an external (as per its respective location to the corporate VPN gateway) home agent is needed (as per [4]), or the VPN gateway is required to be mobility-capable (as per [5]) so as to handle external mobility. Alternatively, one may wonder whether the external home

agent of [4] (or mobility-capable VPN gateway of [5]) may be enough for entirely handling the node's mobility, without having to rely on an additional internal home agent. This is however not the case. The external home agent would not be sufficient to handle node's mobility within the corporate network, or between an external location and the corporate network. A node roaming back to the corporate network would indeed drop its VPN tunnel and directly start using its internal address to communicate with its peers. Mandating this node to instead establish a tunnel to an external entity for all of its communications would be both a waste of resources and a nonsense security policy. Hence an internal home agent is needed as well. Internal and external mobility systems rely on successive tunneling/de-tunneling operations. According to [4], each packet sent/received by a mobile node MN outside the corporate network is carried within (1) a tunnel between MN and the internal home agent; (2) a tunnel between MN and the VPN gateway; (3) a tunnel between MN and the external home agent. From the respective locations of both home agents and the VPN gateway, it is obvious that tunnel (1) is transported within tunnel (2), which is itself transported within tunnel (3). This scheme naturally translates from IPv4 to IPv6: the change of address family (and corresponding mobility protocol: Mobile IPv6 instead of Mobile IPv4) does not affect its operation. The same is true for [5], which may almost straightforwardly be applied to an IPv6 architecture. Things get more complex when the mobile device is no longer an IPv4 host but an IPv6 NEMO [2] mobile router. Then the internal home agent, which handles the network mobility of the whole moving network, has to be NEMOcapable whereas the external mobility mechanism, which is not in charge of an entire prefix but ensures mobility of the VPN tunnel only, remains based on vanilla Mobile IP (as per [4]) or Mobike (as per [5]) protocol. However, the public transportation scenario introduces additional requirements that may question this result, as explained in what follows. We assume that Internet connectivity in the public transportation vehicles will be offered to both company agents and passengers. Yet the NEMO translations of the "mobile VPN" solutions presented above assume that all traffic sent by the moving network is tunneled back to the corporate network, successively through the external home agent, VPN gateway and internal home agent. Whereas this routing policy makes sense for the company agents, it is clearly unacceptable for passengers, who should not be authorized to inject traffic directly within the corporate network. It is therefore necessary to introduce heterogeneity in the way IP routing is performed, so as to discriminate between these two classes of users. The NEMO protocol states that "all IPv6 traffic to and from the Mobile Network is sent through [the] bi-directional tunnel"; in the present context, said NEMO bi-directional tunnel is the tunnel established with the internal home agent. This mandates for a dual addressing scheme, where company agents must actually

belong to the moving network handled by the internal home agent whereas passengers must not belong to this moving network; that is, company agents must obtain an IP address based on the moving network prefix whereas passengers must obtain an IP address based on another prefix. Although not being authorized to access the corporate network, passengers should however be offered a mobility service by the public transportation company: the vehicle mobility should be transparent to the applications run on the passengers' devices. Therefore, we propose that the vehicle's mobile router performs a dual role, actually running two distinct logical mobile router components: one aimed at serving the company agents and a second one aimed at serving the vehicle's passengers. Instead of having these components handled independently one to the other, we leverage on the double tunneling mechanism described in [4] by adding NEMO capability to the external home agent and using it to provide mobility for the passengers. This results in the following situation: on one hand, the bi-directional tunnel between the mobile router and the internal home agent carries all traffic sent/received by the company agents; on the other hand, the bi-directional tunnel between the mobile router and the external home agent carries all traffic sent/received by the passengers and also carries all traffic sent/received by the mobile router itself, including the encrypted agent's traffic sent to the VPN gateway. Figure 1 gives an overview of the "double tunneling" (two NEMO bi-directional tunnels) mechanism. In order to make things clearer, the concept of "virtual location" has been introduced. A mobile router having established a bi-directional tunnel to a home agent is virtually under the same link as this home agent. Here, being served by two home agents simultaneously, the vehicular mobile router is simultaneously at two virtual locations (A and B), which it uses respectively for routing passengers' (identified by prefix A) and agents' (identified by prefix B) traffic. In addition to leveraging the external home agent, the present mechanism almost straightforwardly support the implementation of security policies / restriction rules for passengers' traffic, since this traffic is routed to a location (DMZ) that is entirely under the control of the public transportation company. Meanwhile, the agents' traffic cannot be altered by malicious passengers since it is transmitted under an encrypted form between the mobile router and the external home agent. Agents can therefore enjoy full connectivity to the corporate network, as if they had established multiple independent VPN tunnels. Instead, the agents have to establish a one-hop secured channel between themselves and the mobile router, which plays for them the role of a mobile VPN gateway.

DMZ

Figure 1. NEMO (shaded) and IPsec (gray) tunnels are used differently depending on the moving network node’s class. Whereas passenger devices’ data (light laptops) is tunneled back to a DMZ, agent devices (dark laptops) are granted full connectivity to the corporate network.

This raises the question of the overall security level of the present mechanism. It is essential that both authentication and access control enforcement be robust enough to respectively (1) allow for discrimination between passengers and agents and (2) prevent any attack where a passenger would masquerade as an agent. In addition, the secured channel between the agent's device and the mobile router has to rely on cryptographic algorithms at least as secure as the VPN tunnel between the mobile router and the fixed VPN gateway (preferably, more secure). Even then, one may not neglect the fact that the mobile router will always remain more vulnerable than a fixed corporate VPN gateway, because of its inferior level of physical security. An example of acceptable security components consists in EAP-based authentication as part of WPA2 security enforcement: at the end of a successful EAP authentication, the mobile router receives from the EAP authentication server (AS) an indication of the class to which the authenticated user belongs. For the AS, the identification is as simple as checking the realm part of the user's network access identifier (NAI). The mobile router allocates then an IP address for the corresponding device accordingly (prefix A for a passenger, prefix B for an agent). WPA2 security prevents MAC/IP address spoofing, while providing per-packet integrity protection and encryption. The careful reader will have noticed that the proposed architecture may only be based on the "mobile VPN" solution proposed in [4], as opposed to [5]. This is because the former introduces the concept of external home agent (which we extend to become a NEMO home agent so as to handle passengers' traffic) while the latter relies on Mobike (mobilitycapable VPN gateway, not able to handle network mobility) to achieve external mobility. If the public transportation company does not aim at providing a mobility service for its passengers, however, both the two-home-agent solution a la [4] and the Mobike solution a la [5] may be used. In fact, these solutions may even be used concurrently for load balancing purpose at the scale of the public transportation company: some vehicular mobile routers relying on [4], some others on

[5] to achieve external mobility, while using a single internal home agent to achieve internal mobility. Even more, a mobile router using a certain scheme for external mobility may seamlessly transition to the other. Transitioning from a MIPVPN scheme to a Mobike one would require that the mobile router drop the external bi-directional tunnel and use Mobike to register its IP address (former care-of address of NEMO external tunnel) with the Mobike VPN gateway. On the other hand, transitioning from a Mobike scheme to a MIP-VPN one would require both the establishment of a bi-directional tunnel to the external home agent and the registration of the corresponding home address with the Mobike-capable VPN gateway. The mobility mechanism that best fits resource availability on both external HA and VPN gateway can therefore be dynamically chosen. III.

APPLICATION FOR V2V COMMUNICATIONS

The dual addressing scheme presented in the previous section is an effective method to offer differentiated secure access for users of moving networks in the public transportation system. In this section we will detail the application of this addressing scheme when the “Corporate” network and the DMZ are not reachable, the vehicles being disconnected from the Internet. This is typically a case of V2V (vehicle-to-vehicle) communication; let us remind that the goal is for one passenger to communicate with another passenger in another (or same) vehicle and, similarly, one agent with another agent, while prohibiting passenger-to-agent communications and potential security threats. The protection should be offered both in-vehicle and between vehicles. A. Assumptions We make the following assumptions for the application to V2V communications: (1) one vehicle contains one moving network controlled by a Mobile Router (MR) (2) secure connections have already been established between each LFN (Local Fixed Node) and the MR in that vehicle, (3) within a vehicle two distinct IP subnets are deployed on the same wireless link-layer (e.g. 802.11n technique) and (4) every vehicle is disconnected from the Internet – only vehicle-tovehicle communications are possible. Let us further detail these assumptions. A public transportation vehicle carries principally one Mobile Router. This device is a small-format PC permanently installed in the vehicle and powered by the vehicular electricity plugs. It has at least two wireless interfaces: ingress and egress. The ingress interface of the MR plays the role of an Access Point offering connectivity to the mobile devices coming in and out of the bus. For the purpose of simplifying the description of the V2V method we consider these devices to be actually fixed in the vehicle at one instant: Local Fixed Nodes. An example of an LFN is a Personal Digital Assistant carried by a passenger, and having a wireless interface of the same type of the ingress interface of the MR (typically WiFi).

WiFi Ad-hoc mode, essid “adhoc”

fe80::FFFE_MAC4 egress interface

Vehicle

MR WiFi ingress AP mode 2001:db8:4:1::/64 2001:db8:4:2::/64

LFN, Agent

LFN Passenger

Figure 2. Moving Network deployed in a Vehicle

The ingress interface provides two Service Set Identifiers (SSIDs): one for Agents and one for Passengers. The two are completely independent and use different link-layer security keys, thus acting as two independent links (this constitutes the third assumption). We avoid naming these SSIDs throughout the paper. On each of the two links, a separate IPv6 prefix (Mobile Network Prefix, MNP) is pre-configured: 2001:db8:4:1::/64 for the Agents’ link and 2001:db8:4:2::/64 for the Passengers’ link. The Agents and Passengers devices will auto-configure addresses within these ranges, respectively. For example, an Agent will auto-configure the address 2001:db8:4:1:8200:60ff:fe0f:e800, and a default route towards the link-local address of the ingress interface of MR, by using the standard protocol Stateless Address AutoConfiguration [7]. The MNPs assigned on each vehicle’s ingress links are unique, throughout the transportation company. For example, vehicle 1 uses MNP1 and MNP2 whereas vehicle 2 uses MNP3 and MNP4, all four being different. The egress interface works in Ad-Hoc mode, has the linklocal address fe80::FFFE_MAC4 and is pre-configured with a stable SSID, named “adhoc” in this paper. It can be also preconfigured with a shared unique WEP key, known by all vehicles of the transportation agency, or with a similar WPA passphrase and method WPA-NONE. There is no IPv6 prefix pre-configured on any of the egress interface on any vehicle. Further, during the V2V communications, there will still be no prefix assigned on the link formed by the communicating egress interfaces1. We assume that if all vehicles of the transportation agency are configured in this way they will automatically set up their egress link-layer to properly communicate when they are in close proximity. As mentioned previously, the second assumption is that each LFN has already performed an authentication phase when attaching to the ingress interface of the Mobile Router, prior to starting the V2V operation. This phase can include but is not limited to EAP, or EAP-TTLS; once this link-layer security phase has set up, the LFNs need to communicate at IP 1 Obviously though, the fe80::/10 prefix will be self-assigned on these egress interfaces, the prefix of the link-local addresses. However, this prefix and the corresponding link-local addresses of the egress interfaces cannot be used for communication other than on that same link.

layer. The link-layer protection allows for secure traffic on each of the two links on the ingress interface, without need of using IPsec: Agent LFNs are protected against eventual attacks from Passenger LFNs active in the same vehicle. Finally, the last assumption is that each vehicle is disconnected from the Internet. In the application of V2V communications for public transportation described in this paper we do not rely on the use of the NEMO (Network Mobility) protocol. The combination of V2V operation together with vehicles connected to the Internet infrastructure (and using NEMO) will be considered as part of future work. In that we will investigate whether the presence of dual prefixes (one for agents, one for passengers) in the moving network necessarily involves the use of dual separate Home Agents active on the same home link. B. V2V Topology, Addressing and Protocol There are several cases of Vehicle-to-Vehicle communications in a public transportation setting. Typical examples are: (1) two buses at the end of the line, exchanging road status information, (2) wagon-to-wagon communications, part of the same train or metro, (3) convoy communication between buses moving together along the same route and towards the same destination, etc. Some more specific cases in public transportation include the communication between a towing truck and the towed bus, and more. From an IP networking standpoint, the V2V communication situation appears when we consider two or more moving networks deployed in vehicles (similar to the vehicle described in the first assumption in the previous section). The vehicles approach and establish contact at linklayer, in ad-hoc mode on their egress interface. We consider a topology formed by four vehicles shown in Figure 3 below. After the topology description we will detail the protocol of messages exchanged directly between vehicles and the contents of the routing tables after that exchange. LFN, Agent

LFN Passenger

2001:db8:1:1::/64

2001:db8:1:2::/64

WiFi ingress AP mode

Vehicle1

LFN, Agent

LFN Passenger

2001:db8:2:1::/64

2001:db8:2:2::/64

WiFi ingress AP mode

MR1

Vehicle2

egress interface fe80::FFFE_MAC1

MR2

fe80::FFFE_MAC2 egress interface

WiFi Ad-hoc mode, essid “adhoc” egress interface fe80::FFFE_MAC3

Vehicle3

fe80::FFFE_MAC4 egress interface

Vehicle4

MR3

MR4

WiFi ingress AP mode 2001:db8:3:1::/64 2001:db8:3:2::/64

WiFi ingress AP mode 2001:db8:4:1::/64 2001:db8:4:2::/64

LFN, Agent

LFN Passenger

LFN, Agent

LFN Passenger

Figure 3. Application of the dual addressing scheme for 4 vehicles, configured as vehicle-to-vehicle topology, using a WiFi ad-hoc mode connection. Within each vehicle there are two IPv6 prefixes, each being dedicated to a different class of users (one for passengers and one for agents).

In the topology depicted above, four vehicles (Vehicle1…4) are in close proximity and have established link-layer connectivity in ad-hoc mode between their egress interfaces. As described previously in the first assumption, within each vehicle there are two IPv6 prefixes, one for the “Agent” LFNs (the device carried by an Agent) and one for the “Passenger” LFNs. There is no IPv6 prefix on the ad-hoc link of the egress interfaces. There is a need to establish communications between Agents and between Passengers of different vehicles. Obviously, the Agents and Passenger devices in Vehicle1 have no knowledge about the routes towards the addresses of the Agents and Passengers in the other vehicles. They will send packets by using their default route, towards their respective MR. For a given MR to forward the received packets towards the right other MR (vehicle) it needs to have routing information about the prefix and next-hop gateway of it, otherwise it will drop these incoming packets. To obtain this routing information on an MR, we propose a protocol to exchange data by using ICMPv6 Router Advertisements. The protocol is based on an earlier publication [1] which describes packet formats to contain prefix/next-hop pairs. That document also describes the message exchanges; (we briefly overview it below for completeness). The method of [1] is further augmented with policy-based routing based on the source address. MR1

MR2

MR3

happen relatively at the same time, and are sent to every other node on the link. It is not always necessary to send this message, as some implementations set up local filters indicating willingness to always receive the messages addressed to the “all-node” multicast address. Once every egress interface is able to receive messages addressed to the “all-nodes” multicast group, each MR can send a “Special” Router Advertisement on its egress interface. This message is extended from a classical RA (defined in [8]) to contain two Mobile Network Prefixes: the RA sent by MR3 contains MNP31 (MNP used on the ingress interface of MR3 for configuring Agent LFN addresses) and the MNP32 (used for Passengers). In addition, the link-local address of the egress interface (noted LL3) is present in the source address of the base header (see RFC2460 for the structure of the IPv6 base header) of this RA too. The special RA sent by MR3 is received by both MR1 and MR2. We next picture the two routing tables of MR1 after reception of RAs (tables of MR2 and MR3 are similar): Table for RATP agents src

Dst prefix

Gateway

2001:db8:1:1::/64 2001:db8:2:1::/64 fe80::FFFE_MAC2 2001:db8:1:1::/64 2001:db8:3:1::/64 fe80::FFFE_MAC3 2001:db8:1:1::/64 2001:db8:4:1::/64 fe80::FFFE_MAC4

Table for Passengers src

Dst prefix

Gateway

2001:db8:1:2::/64 2001:db8:2:2::/64 fe80::FFFE_MAC2 2001:db8:1:2::/64 2001:db8:3:2::/64 fe80::FFFE_MAC3 2001:db8:1:2::/64 2001:db8:4:2::/64 fe80::FFFE_MAC4

Figure 5. Routing Tables in MR1 after reception of RA from MR2, MR3 and MR4

Simultaneous “JOIN”

“Special”Router Advertisement “Special” RA: MNP31, MNP32, LL3 “Special” RA: MNP21, MNP22, LL2

Figure 4. Exchanging Routing Information for V2V Communications

The protocol behavior is relatively simple and symmetric: each MR acts similarly on its egress interface: send and receive multicast “JOIN” and Router Advertisements – after the last received Routing Advertisements modify the routing tables. Each MR maintains two separate routing tables: one for Agents and one for Passengers. For conciseness we consider only three Mobile Routers (four Mobile Routers in the topology of Figure 3 will function similarly). The message exchange is pictured in the Figure 4 above. Once the link-layer connectivity is established (phase not pictured) each MR sends a message on its egress interface to declare its willingness to receive messages addressed to the “all-node” multicast group (the group to which Router Advertisement messages are sent). All three “JOIN” messages

In detail, once MR1 receives the special RA from MR2, MR3 and MR4 it will extract the data (MNPs and LLs) and fill up its two routing tables as pictured above. The numbers correspond to the addresses and prefixes pictured in the topology illustration. In each table, the src column indicates the prefixes of the addresses from which packets are accepted for checking in this routing table (the two MNPs deployed on the ingress interface of MR1); the Dst prefix and Gateway field are the classical fields of a routing table. When each MR has filled its routing tables, it starts using the normal search in the routing tables (longest-prefix match) and the policy-based routing based on the source address; thus it becomes possible for Agents and Passengers to communicate securely: Agents to Agents and Passengers to Passengers, from whichever vehicle to whichever other vehicle. IV.

SCALABILITY

The scalability analysis of this method is relatively straightforward. For memory needs, it is obvious that for n routers, each router maintains (n-1)*2 routing table entries. At the same time, for communication needs, there are n messages

exchanged (except the initial link establishment and multicast “JOIN” phases). Thus, it can be stated that in terms of memory and communication needs, this V2V method scales linearly with the number of Mobile Routers (i.e. vehicles) added in the V2V topology. The method can be further refined easily with several classes of users (e.g. Class1 Passengers, Class2 Passengers, and so on), and yet the method will still be linearly scaling in terms of memory and communication. However, beyond the scalability of this network-layer V2V method, it is important to note a barrier aspect of the link-layer communications: when ad-hoc modes are used, there is a certain threshold in the number of stations connected on that link, threshold above which the radio level noise can become so high to a point of interrupting communications between certain stations. This factor (the number of stations supported by the link-layer technology in ad-hoc mode) may easily become the limiting factor of this V2V method, more than the scalability of the protocol of exchanging routing information. Still, with actual deployments of public transportation vehicles, most scenarios require only a few vehicles to be connected together in a V2V way (a train has only a few wagons, at the end of line only a few buses are stationary, a convoy has only a few number of vehicles following each other, etc.) V.

VALIDATION

For validation, we are currently performing software prototyping for the Mobile VPN and V2V method of communication, as part of the SEAMLESS project. We use four Mobile Routers running linux kernels 2.6.30, several types of WiFi 802.11 network interfaces, we extend the radvd 1.4 daemon software and re-use FreeRADIUS 2.1.6 software. First results are encouraging and further reports will be delivered in the project deliverables. We perform both addition and deletion of routing table entries. VI.

SIMILAR METHODS FOR V2V COMMUNICATIONS

At the beginning of section 3 we have presented a set of assumptions for performing V2V communications between vehicles in a public transportation setting. We have introduced the need of separate communications between Agents and Passengers and exposed the necessity of exchanging Mobile Network Prefixes between Mobile Routers, on their egress interfaces. We have subsequently presented a method to achieve this effect by using “special” ICMPv6 Router Advertisement messages, enhanced to contain the MNPs; the method is also using src-based policy routing to match entries in the routing tables. It is however possible to achieve the same effect by using dynamic routing protocols such as OSPF version 3 [10] and/or RIPng [11]. For example, two MRs connected on their egress interfaces would also run RIPng and exchange their routing tables as a set of “RTE”s (Routing Table Entries in RIPng parlance). These two protocols are mentioned as an

example only – more exist, especially in the domain of MANET ad-hoc routing protocols. There exist also widespread implementations of these protocols; however, they offer many features which are not necessary in simple V2V settings such as the ones described in this paper. For example, the maximum path length in the V2V topologies described here does not exceed 3 (from one LFN in one vehicle to another LFN in another vehicle) whereas the dynamic routing protocols are made to easily support topologies with diameters larger than 5. Another inconvenient of some dynamic IP routing protocols is a lack of immediate reaction upon change in link-layer status. For example, typical RIPng will exchange routes every 30 seconds, but has no means to perform the same exchange upon request (except maybe “Triggered RIP”, another RFC). In comparison, our method offers the possibility to send “special” Router Advertisements in response to a specified Router Solicitation which could be issued automatically when the ad-hoc link between egress interfaces is set up. We currently consider it “heavy” to use dynamic IP routing protocols in the simple V2V communications cases, such as the ones presented in this paper. ACKNOWLEDGMENT This work is performed during the SEAMLESS project. Lasting between April 2008 and September 2010, it is contributed by the following institutional partners: NEOTILUS, Telecom SudParis, RATP and CEA LIST. The authors of this paper sincerely acknowledge the fruitful discussions within the project meetings which helped shape some of the ideas in this document. Special thanks are gratefully extended to Maxence Dalmais, the student of INSA Lyon currently performing an internship at CEA LIST on the topic of this paper. REFERENCES [1]

A. Petrescu and C. Janneteau, “The NANO Draft (Scene Scenario for Mobile Routers and MNP in RA)”, Internet Draft, draft-petrescumanemo-nano-00.txt, Work in Progress, February 26th, 2007. [2] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol”, Request for Comments, RFC 3963, Internet Engineering Task Force, January 2005. [3] P. Eronen, “IKEv2 Mobility and Multihoming Protocol (MOBIKE)”, IETF RFC 4555, June 2006. [4] S. Vaarala, E. Klovning, “Mobile IPv4 Traversal across IPsec-Based VPN Gateways”, IETF RFC 5265, June 2008. [5] V. Devarapalli, P. Eronen, “Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)”, IETF RFC 5266, June 2008. [6] A. Stephane, “Mobility using Proxy MIP and Mobike”, draft-antoinemip4-proxymobike-01.txt, IETF work in progress, February 2008. [7] S. Thomson, T. Narten and T. Jinmei, “IPv6 Stateless Address Autoconfiguration”, IETF RFC 4862, September 2007. [8] T. Narten, E. Nordmark, W. Simpson and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6)”, IETF RFC 4861, September 2007. [9] S. Deering and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, IETF RFC 2460, December 1998. [10] J. T. Moy, “OSPF: Anatomy of an Internet Routing Protocol”, AddisonWesley, 1998. [11] Q. Li, J. Tatuya and K. Shima, “IPv6 Advanced Protocols Implementation”, The Morgan Kaufmann Series in Networking, 2007.