idnits 2.17.1 draft-baldessari-c2ccc-nemo-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 935. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 941. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 582: '... available, it MAY also be used as R...' RFC 2119 keyword, line 589: '... A C2C-CC OBU MUST be capable of bot...' RFC 2119 keyword, line 675: '...establishment procedure, MUST have the...' RFC 2119 keyword, line 688: '... A RO technique SHOULD allow MNNs con...' RFC 2119 keyword, line 699: '... A RO technique MUST prevent maliciou...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A RO technique MUST not require that the MNP is revealed to all nodes in the visited network. Instead, a RO technique MUST allow for revealing the MNP only to selected nodes in the visited network. Furthermore, a RO technique SHOULD allow that MNP and HoA are not exchanged as clear text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 05, 2007) is 6139 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3041 (ref. '4') (Obsoleted by RFC 4941) == Outdated reference: A later version (-02) exists of draft-eddy-nemo-aero-reqs-00 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO R. Baldessari 3 Internet-Draft NEC Europe 4 Intended status: Informational A. Festag 5 Expires: January 6, 2008 NEC Germany 6 M. Lenardi 7 Hitachi Europe 8 July 05, 2007 10 C2C-C Consortium Requirements for NEMO Route Optimization 11 draft-baldessari-c2ccc-nemo-req-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 6, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 Vehicular ad hoc Networks (VANETs), self-organized networks based on 45 short-range wireless technologies, aim at improving road safety and 46 providing comfort and entertainment applications. The Car2Car 47 Communication Consortium is defining a European standard for inter- 48 vehicle communication that adopts VANETs principles. This document 49 specifies requirements for Route Optimization techniques for usage of 50 Network Mobility (NEMO) in VANETs as identified by the Consortium. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. C2C Communication Architecture . . . . . . . . . . . . . . . . 6 57 3.1. System Architecture . . . . . . . . . . . . . . . . . . . 6 58 3.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 8 59 3.3. IPv6 Deployment . . . . . . . . . . . . . . . . . . . . . 9 60 4. Intended NEMO Deployment . . . . . . . . . . . . . . . . . . . 11 61 4.1. Scope of NEMO . . . . . . . . . . . . . . . . . . . . . . 11 62 4.2. Example Use Cases . . . . . . . . . . . . . . . . . . . . 11 63 4.2.1. Notification Services . . . . . . . . . . . . . . . . 12 64 4.2.2. Peer-to-peer Applications . . . . . . . . . . . . . . 12 65 4.2.3. Upload and Download Services . . . . . . . . . . . . . 12 66 5. NEMO Route Optimization Scenarios . . . . . . . . . . . . . . 13 67 6. NEMO Route Optimization Requirements . . . . . . . . . . . . . 15 68 6.1. Req 1 - Separability . . . . . . . . . . . . . . . . . . . 15 69 6.2. Req 2 - MNN IPsec . . . . . . . . . . . . . . . . . . . . 15 70 6.3. Req 3 - RO Security . . . . . . . . . . . . . . . . . . . 16 71 6.4. Req 4 - Privacy Protection . . . . . . . . . . . . . . . . 16 72 6.5. Req 5 - Multihoming . . . . . . . . . . . . . . . . . . . 17 73 6.6. Req 6 - Coexistence with Sub-IPv6 RO . . . . . . . . . . . 17 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 81 Intellectual Property and Copyright Statements . . . . . . . . . . 21 83 1. Introduction 85 In Vehicular ad hoc Networks (VANETs), cars are equipped with short- 86 range wireless communication devices that operate at frequencies 87 dedicated to safety and non-safety vehicular applications. When 88 entering the proximity of each other, vehicles form a self-organized 89 network by means of a specialized routing protocol that allows for 90 packet exchange through broadcast and unicast communications. 91 Further, fixed communication devices are installed along roadsides 92 and can either distribute local warnings or offer connectivity with a 93 network infrastructure. Due to its safety-oriented nature and 94 extremely dynamic operational environment, this type of communication 95 has lead research to consider specialized protocols and algorithms, 96 especially concerning information dissemination, geographic 97 distribution of packets and privacy/security issues. 99 The Car2Car Communication Consortium [10] is an industry consortium 100 of car manufacturers and electronics suppliers that focuses on the 101 definition of an European standard for vehicular communication 102 protocols. The Consortium gathers results from research projects and 103 aims at harmonizing their efforts. The first technical document 104 [11], to be released in the following months, gives an overview of 105 the system and protocol architecture, as well as of the applications 106 on which the Consortium has agreed so far. In essence, this document 107 defines a C2C-C protocol stack that offers specialized 108 functionalities and interfaces to (primarily) safety-oriented 109 applications and relies as a communication technology on a modified 110 version of IEEE 802.11p [12]. This protocol stack is placed beside a 111 traditional TCP/IP stack, based on IP version 6, which is used mainly 112 for non-safety applications or potentially by any application that is 113 not subject to strict delivery requirements, including Internet-based 114 applications. The interaction between these stacks is currently 115 discussed and briefly overviewed in this document. 117 As vehicles connecting to the Internet via dedicated access points 118 (also termed Road Side Units, see Section 2 for terminology) change 119 their attachment point while driving, the Consortium considers IP 120 Mobility support as enhancing the system with session continuity and 121 global reachability. When considering that passenger devices can be 122 plugged into car communication equipment, therefore turning a vehicle 123 into an entire moving network, Network Mobility (NEMO) principles 124 have clear benefits in the discussed scenario (i.e. passenger devices 125 shielded from mobility, centralized mobility management). 127 In NEMO Basic Support protocol [1] all data packets go through the 128 IPv6-in-IPv6 tunnel established between the Mobile Router (MR) and 129 the Home Agent (HA). As already pointed out in various documents 130 ([7], [6] and [9]) this can have severe consequences on the 131 communication performances, as it causes data packets to follow a 132 path that can be very far from optimal and requires a double IPv6 133 header for every packet exchanged with a Correspondent Node (CN) in 134 the Internet. Compared with a communication that uses the ideal 135 packet routing and the normal IPv6 header size, these factors results 136 in an increased delay and a reduced throughput, plus indirect 137 consequences like increased packet fragmentation and overall less 138 efficient usage of resources. Even if, as described later, the C2C-C 139 Consortium intends to adopt NEMO only for non-safety applications, a 140 Route Optimization (RO) mechanism that alleviates or even eliminates 141 this inefficiency is highly desirable. Moreover, the actual 142 deployment of NEMO as default IP mobility support in C2C-C 143 communication systems strongly depends on the availability of RO 144 techniques. 146 The document is organized as follows: Section 2 defines terminology. 147 Section 3 describes the technical approach of C2C-C Consortium that 148 allows for usage of NEMO. Section 4 describes the deployment of NEMO 149 in vehicular applications as intended by the C2C-C Consortium. 150 Section 5 introduces the RO scenario and finally Section 6 lists the 151 requirements for NEMO RO. 153 2. Terminology 155 The following terms used in this document are defined in the Mobile 156 IPv6 protocol specification [2]: 158 o Home Agent (HA) 160 o Home Address (HoA) 162 The following terms used in this document are defined in the Mobile 163 Network terminology document [8]: 165 o Network Mobility (NEMO) 167 o Mobile Network 169 o Mobile Router (MR) 171 o Mobile Network Prefix (MNP) 173 o Mobile Network Node (MNN) 175 The following terms used in this document are defined in the NEMO 176 Route Optimization Space Analysis document [6]: 178 o Correspondent Router (CR) 180 o Correspondent Entity (CE) 182 The following new terms are used in this document: 184 o On Board Unit (OBU): a device installed in vehicles, implementing 185 the communication protocols and algorithm and equipped with at 186 least 1) a short-range wireless network interface operating at 187 dedicated frequencies and 2) a wireless or wired network interface 188 where Application Units (AU) can be attached to. With respect to 189 the NEMO terminology, the OBU is the physical machine acting as 190 MR, 1) is used as egress interface and 2) as ingress. 192 o Application Unit (AU): a portable or built-in device connected 193 temporarily or permanently to the vehicle OBU. It is assumed that 194 AUs support a standard TCP/IPv6 protocol stack, optionally 195 enhanced with IP Mobility support. With respect to the NEMO 196 terminology, an AU is a generic MNN. 198 o Road Side Unit (RSU): a device installed along roadsides 199 implementing the C2C-C communication protocols and algorithms. 200 RSUs can either be isolated or connected to a network 201 infrastructure. In the latter case, RSUs are attachment points 202 either acting themselves as IPv6 access routers or as network 203 bridges directly connected to an access router. 205 o In-vehicle network: the wireless or wired network placed in a 206 vehicle and composed by (potentially) several AUs and one OBU. 208 o Vehicle-to-Vehicle (V2V) Communication Mode: a generic 209 communication mode in which data packets are exchanged between two 210 vehicles, either directly or by means of multi-hop routing, 211 without involving any node in the infrastructure. 213 o Vehicle-to-Infrastructure (V2I) Communication Mode: a generic 214 communication mode in which data packets sent or received by a 215 vehicle traverse a network infrastructure. 217 o Vehicle-to-Infrastructure-to-Vehicle (V2I2V) Communication Mode: a 218 generic communication mode in which data packets are exchanged 219 between two vehicles, by means of multi-hop routing involving a 220 RSU not connected to a network infrastructure. 222 3. C2C Communication Architecture 224 3.1. System Architecture 226 The current draft reference architecture of the C2C communication 227 system is shown in Figure 1. 229 | Internet | 230 | | 231 +---+-----------------+-+ 232 | | 233 Access +--+-+ +--+-+ Access 234 Router | AR | | AR | Router 235 +--+-+ +--+-+ 236 | | 237 --+---+--- --+---+-- 238 | | 239 Road Side +--+--+ +--+--+ Public 240 Unit | RSU | | PHS | Hot Spot 241 +---+-+ +---+-+ 242 | | 243 /\ /\ 245 \_ \_ 246 \_ \_ 247 \ \ 249 Mandatory \/ 250 Mod IEEE 802.11p | __ \/ Optional IEEE 251 Interface +---+--+ \__ \/ | 802.11a/b/g 252 | OBU1 | | | Interface 253 +--+---+ +-+-----+---+ 254 Vehicle1 | | OBU2 | On-Board 255 -+---+-+- +--+--------+ Unit 256 | | | Vehicle2 257 Application +--+-+ +-+--+ --+--+-- 258 Units | AU | | AU | | 259 +----+ +----+ +-+--+ 260 | AU | 261 +----+ 263 Figure 1: C2C-CC Reference Architecture 265 Vehicles are equipped with networks logically composed of an OBU and 266 potentially multiple AUs. An AU is typically a dedicated device that 267 executes a single or a set of applications and utilizes the OBU 268 communication capabilities. An AU can be an integrated part of a 269 vehicle and be permanently connected to an OBU. It can also be a 270 portable device such as laptop, PDA or game pad that can dynamically 271 attach to (and detach from) an OBU. AU and OBU are usually connected 272 with wired connection, but the connection can also be wireless, such 273 as Bluetooth. The distinction between AU and OBU is logical, they 274 can also reside in a single physical unit. 276 Vehicles' OBUs and stationary units along the road, termed road-side 277 units (RSUs), form an ad hoc network. An OBU is at least equipped 278 with a (short range) wireless communication device based on draft 279 standard IEEE 802.11p [12] (adapted to European conditions and with 280 specific C2C-C extensions) primarily dedicated for road safety, and 281 potentially with other optional communication devices. OBUs directly 282 communicate if wireless connectivity exist among them. In case of no 283 direct connectivity, multi-hop communication is used, where data is 284 forwarded from one OBU to another, until it reaches its destination. 285 For example in Figure 1, RSU and OBU1 have direct connectivity, 286 whereas OBU2 is out of RSU radio coverage but can communicate with it 287 through multi-hop routing. 289 The primary role of an RSU is improvement of road safety. RSUs have 290 two possible configuration modes: as isolated nodes, they execute 291 applications and/or extend the coverage of the ad hoc network 292 implementing routing functionalities. As attachment point connected 293 to an infrastructure network, RSUs distribute information originated 294 in the infrastructure and offer connectivity to the vehicles. As 295 result, for example, the latter configuration allows AUs registered 296 with an OBU to communicate with any host located in the Internet, 297 when at least one RSU connected to a network infrastructure is 298 available. 300 An OBU may also be equipped with alternative wireless technologies 301 for both, safety and non-safety. For example, an OBU may also 302 communicate with Internet nodes or servers via public wireless LAN 303 hot spots (PHS) operated individually or by wireless Internet service 304 providers. While RSUs for Internet access are typically set up with 305 a controlled process by a C2C-C key stake holder, such as road 306 administrators or other public authorities, public hot spots are 307 usually set up in a less controlled environment. These two types of 308 infrastructure access, RSU and PHS, also correspond to different 309 applications types. Other communication technology, such as wide 310 coverage/cellular networks (e.g. UMTS, GPRS) may also be optionally 311 installed in OBUs, but their usage is currently considered out of 312 scope of the C2C-CC Consortium. 314 The C2C-CC commonly refers to two main communication modes: 316 o in Vehicle-to-Vehicle (V2V) mode, data packets are exchanged 317 directly between OBUs, either via multi-hop or not, without 318 involving any RSU; 320 o in Vehicle-to-Infrastructure mode (V2I), an OBU exchanges data 321 packets through a RSU with an arbitrary node connected to the 322 infrastructure (potentially another vehicle not attached to the 323 same RSU). 325 3.2. Protocol Architecture 327 The protocol stack currently considered by C2C-CC for OBUs is 328 depicted in Figure 2. 330 +--------------------+------------------+ 331 | | | 332 | C2C-CC | IP-based | 333 | Applications | Applications | 334 | | | 335 +--------------------+------------------+ 336 | | TCP/UDP/... | 337 | C2C-CC Transport +------------------+ 338 | | | 339 +--------------------+-----+ IPv6 | 340 | | | 341 | C2C-CC Network | | 342 | | | 343 +--------------------+-----+------------+ 344 | Modified | Standard WLAN | 345 | IEEE 802.11p | IEEE 802.11a/b/g | 346 +--------------------+------------------+ 348 Figure 2: OBU Protocol Stack 350 Protocol blocks are explained in the following list: 352 o Modified IEEE 802.11p: this block represents MAC and PHY layers of 353 a wireless technology based upon current draft standard IEEE 354 802.11p [12] but modified for usage in Europe. In Europe, 355 allocation of dedicated frequencies around 5.9 GHz for safety and 356 non-safety applications is in progress. Expected communication 357 range in line of sight is around 500m. This network interface is 358 mandatory. 360 o IEEE 802.11a/b/g: this block represents MAC and PHY layers 361 provided by one ore more IEEE 802.11a/b/g network interfaces. 362 This network interface is optional but C2C-C Consortium encourages 363 its installation. 365 o C2C-CC Network: this block represents the network layer protocol 366 currently defined by C2C-CC. The protocol provides secure ad hoc 367 routing and forwarding, as well as addressing, error handling, 368 packet sequencing, congestion control and efficient information 369 dissemination. The specification of this protocol is currently 370 under discussion. Only the C2C-CC Network protocol can access the 371 Modified IEEE 802.11p network interface. The C2C-CC Network 372 protocol can also access the IEEE 802.11a/b/g interface. The 373 C2C-CC Network protocol offers an interface to the IPv6 protocol. 374 This interface allows IPv6 headers and payload to be encapsulated 375 into C2C-CC Network datagrams and sent over the Modified IEEE 376 802.11p or IEEE 802.11a/b/g network interface. The specification 377 of this interface is currently under discussion. A primary goal 378 of the C2C-CC Network layer is to provide geographic routing and 379 addressing functionalities for cooperative safety applications. 380 Through the mentioned interface to the IPv6 protocol, these 381 functionalities are also available for IP-based applications. 383 o C2C-CC Transport: this block represents the transport layer 384 protocol currently defined by C2C-CC. This protocol provides a 385 selected set of traditional transport layer functionalities (e.g. 386 application data multiplexing/demultiplexing, connection 387 establishment, reliability etc.). The specification of this 388 protocol is currently under discussion. 390 o C2C-CC Applications: this block represents the application layer 391 protocol currently defined by C2C-CC and concerns Active Safety 392 and Traffic Efficiency Applications. 394 3.3. IPv6 Deployment 396 As described in Section 3.2, the C2C-CC includes IPv6 as mandatory 397 part of its specified protocol architecture. Currently, three 398 methods are discussed for transmission of IPv6 headers and their 399 payload: 401 o On the Modified IEEE 802.11p interface via the C2C-CC Network 402 layer: in this method, IPv6 headers are encapsulated into C2C-CC 403 Network headers and sent using dedicated frequencies for inter- 404 vehicle communications. As the C2C-CC Network layer transparently 405 provides ad hoc routing, from the IPv6 layer perspective other 406 nodes (OBUs and RSU) are attached to the same link. The real 407 broadcast domain, where IPv6 multicast headers are distributed to, 408 is chosen by the C2C-CC Network layer according to the packet 409 type. In particular, C2C-CC Network layer provides efficient 410 flooding and geographically scoped broadcast mechanisms. With 411 respect to a currently adopted terminology, introduced in [13], 412 the C2C-C Consortium approach for usage of NEMO on the Modified 413 IEEE 802.11p is fully MANET-Centric, in the sense that the sub- 414 IPv6 protocol layer provides routing and forwarding in the ad hoc 415 network. This results in the ad hoc nature of VANETs being hidden 416 from IPv6 layer. A comparison of approaches for VANETs can be 417 found in [14]. The deployability of this method strongly depends 418 on the future availability of dedicated frequencies for non-safety 419 purposes in inter-vehicle communications. If frequencies for this 420 purpose will not be allocated, only the left part of the protocol 421 stack of Figure 2 can access the Modified IEEE 802.11p interface. 423 o On the IEEE 802.11a/b/g interface via the C2C-CC Network layer: in 424 this method, IPv6 headers are encapsulated into C2C-CC Network 425 headers and sent using license-free ISM frequency bands (wireless 426 LAN). Except the network interface, this method is equivalent to 427 the previous one. 429 o On the IEEE 802.11a/b/g interface directly: in this method, IPv6 430 headers are sent directly to the wireless LAN interface as 431 specified by [5]. 433 The following informational list briefly summarizes currently 434 discussed design concepts: 436 o vehicles use only IPv6 addresses with as host part an EUI-64 437 identifier derived from the MAC address. Privacy issues described 438 in [4] are strongly alleviated through the use of temporary, 439 changing MAC addresses, which are assigned in a set to every 440 vehicle (as part of their assigned "pseudonyms"); 442 o when a RSU connected to a network infrastructure is available, an 443 OBU configures a globally routable Care-of Address using stateless 444 address configuration; 446 o when infrastructure access is not available, OBUs use addresses 447 with as prefix part a predefined IPv6 prefix (either reserved for 448 C2C-C communications or a general purpose one); 450 o RSU can either act as IPv6 Access Routers or as network bridges 451 connected to external IPv6 Access Routers. Different Access 452 Routers are responsible for announcing different network prefixes 453 with global validity. As a consequence, when roaming between 454 different Access Routers, vehicles experience layer 3 handovers. 456 In all the methods for use of IPv6 in C2C-CC systems as described 457 above, the IPv6 layer is meant to be enhanced with Mobility Support. 458 As a vehicle includes a set of attached devices (AUs), Network 459 Mobility seems the most appropriate solution, allowing for a 460 centralized management of mobility to be executed in OBUs. 462 4. Intended NEMO Deployment 464 4.1. Scope of NEMO 466 In VANETs based on IEEE 802.11 family, a limited amount of bandwidth 467 is shared among a potentially high number of vehicles. Additionally 468 applications for safety purposes have strict requirements in terms of 469 delay, information dissemination and aggregation and secure ad hoc 470 routing. This conflicting conditions have led research activities to 471 consider different approaches compared with traditional, packet- 472 centric network engineering. In particular, only through a more 473 information-centric approach it seems possible to achieve 474 functionalities like geographic distribution, information 475 dissemination according to relevance, information aggregation using 476 cross-layer analysis, plausibility checks at different protocol 477 layers. 479 Taking these aspects into consideration, the C2C-C Consortium is 480 defining a protocol stack mainly dedicated for vehicular safety 481 communications. Applications that are not subject to these 482 particular requirements must use the right part of the protocol stack 483 of Figure 2. This implies that the usage of NEMO in vehicular 484 communications does not target safety-of-life applications but rather 485 less restrictive, non-safety applications. 487 Another important aspect for deployability is related to costs. A 488 primary goal of the C2C-C Consortium is to achieve a spread diffusion 489 in terms of vehicles equipped with communication devices and 490 protocols. This implies that vehicles of different brands and 491 classes should be equipped by default with a basic communication 492 system, whereas differentiation of products can be achieved by 493 offering additional services. NEMO, like any other solution based on 494 IP Mobility support, relies on a service provider that guarantees 495 global reachability at the Home Network Prefix by maintaining an Home 496 Agent. As it does not seem realistic that every car owner will also 497 subscribe for such a service, a set of limited applications based on 498 IPv6 should be available even without Mobility Support. Therefore, 499 NEMO modularity and interoperability with non-NEMO equipped vehicles 500 has to be guaranteed. 502 4.2. Example Use Cases 504 In this section, the main use cases are listed that have been 505 identified by the C2C-CC for usage of NEMO in inter-vehicle 506 communications: notification services, peer-to-peer applications and 507 upload/download services. 509 4.2.1. Notification Services 511 A generic notification service delivers information to subscribers by 512 means of the Internet. After subscribing the service with a 513 provider, a user is notified when updates are available. Example 514 services are weather, traffic or news reports, as well as commercial 515 and technical information from the car producer or other companies. 517 As the network address of a vehicle changes while the vehicle moves 518 among different points of attachment, without NEMO each application 519 should register the new address in order to receive information at 520 the correct location. Service providers would need to update 521 continuously the subscription data and would be able to track the 522 users. Adopting NEMO, which provides global reachability at a 523 reasonably constant identifier (e.g. Mobile Network Prefix), 524 efficiency and location privacy improve considerably. 526 4.2.2. Peer-to-peer Applications 528 A generic peer-to-peer application exchanges data directly between 529 vehicles, without contacting any application server. Data traffic 530 goes through a network infrastructure (V2I or V2I2V) or directly 531 between cars when the infrastructure is not available (V2V). Example 532 applications are vehicle-to-vehicle instant messaging (chat) and off- 533 line messaging (peer-to-peer email), vehicle-to-vehicle voice over IP 534 and file exchange. 536 In this set of use cases, the same applications should be able to run 537 in V2V and V2I mode. As applications should not be aware of routing 538 nor addressing issues, they should use the same identifier for 539 sessions and users (e.g. cars/drivers/passengers) independently of 540 the communications mode. Possible approaches are either to adopt 541 resolution mechanisms or actually maintain the same network 542 identifier in both V2V and V2I modes. This could be achieved for 543 example generalizing the concept of Mobile Network Prefix (MNP) and 544 allowing a Mobile Router (OBU) to use it for V2V communications in 545 absence of attachment points. By means of enforcing limited lifetime 546 for IPv6 prefixes and due to the isolation of VANET clusters from the 547 infrastructure (in V2V), this use of MNP should not introduce routing 548 inconsistencies. 550 4.2.3. Upload and Download Services 552 A generic upload/download service via the Internet consists in simple 553 file exchange procedures with servers located in the Internet. 555 As in vehicular scenarios the connectivity to the infrastructure is 556 highly intermittent, network address' changes cause applications to 557 re-establish sessions in order to resume the exchange, which implies 558 considerable overhead. Session re-establishment can be avoided 559 adopting NEMO. 561 5. NEMO Route Optimization Scenarios 563 In this section, operational characteristics of the intended NEMO 564 deployment are described that are relevant for the design of Route 565 Optimization techniques. In particular a restriction of the general 566 solution space for RO and motivations for RO requirements described 567 in Section 6 are provided. 569 In most NEMO deployment scenarios, MRs have permanent connectivity to 570 the infrastructure and Route Optimization techniques are mainly 571 intended as extensions of MIPv6 RO, where communication assumes to 572 take place always through a point of attachment (infrastructure-based 573 RO). In VANETs based on wireless LAN technologies, the connectivity 574 of moving vehicles to the infrastructure is intermittent due to 575 limited coverage of access points. Nevertheless, direct 576 communication among vehicles should be supported even when 577 infrastructure access is not available. Because this case is 578 strictly a peculiarity of the considered scenario, a technique to 579 allow direct communication (single- and multi-hop) by exposing the 580 MNP associated to vehicles will be studied by the C2C-CC as part of 581 the sub-IPv6 C2C-CC Network layer. Once such a mechanism is 582 available, it MAY also be used as RO technique between MRs located in 583 their vicinity (infrastructure-less RO). The sub-IPv6 layer is 584 responsible for making sure that this mechanism is scalable, 585 reasonably secure (i.e. compared with current Internet level of 586 security) and protects users' privacy. More details about 587 infrastructure-less RO are out of the scope of this document. 589 A C2C-CC OBU MUST be capable of both infrastructure-based and 590 infrastructure-less NEMO RO. When both techniques are simultaneously 591 possible (e.g. two MRs that are reachable both via the infrastructure 592 and directly in the ad hoc domain) the OBU should apply appropriate 593 policies to choose one. The definition of such policies is out of 594 scope of this document. Furthermore, the scope of this document is 595 restricted to the specification of requirements for infrastructure- 596 based NEMO RO techniques. 598 With respect to the classification of NEMO Route Optimization 599 scenarios described in [6], the non-nested NEMO RO case (Section 3.1) 600 is considered as the most important for the C2C-CC deployment. In 601 fact, MIPv6-enabled AUs (i.e. VMNs) and nested Network Mobility are 602 not considered in the C2C-CC use cases. 604 The requirements defined in this document refer to RO between MR and 605 CR (Correspondent Router). According to C2C-CC use cases, the CR can 606 be: 608 o a NEMO MR. For example the MR running on another vehicle or 609 another mobile device connected to the Internet; 611 o a RO-enabled router, i.e. a router static or mobile that does not 612 act as NEMO MR but is capable of establishing RO sessions with 613 NEMO MRs. For example the access router serving a CN in the 614 infrastructure that offers services to vehicles, or the access 615 router serving RSUs installed along the road; 617 o a RO-enabled router collapsed into the CN, i.e. performing 618 internal routing. For example RSUs installed along the road. 620 As consequence of the fact that connectivity to the infrastructure 621 strongly depends on vehicles' mobility, two opposite situations are 622 here considered as RO scenarios: vehicles passing by points of 623 attachment while driving and vehicles connecting to the 624 infrastructure while stopped or parked. 626 In the first case, the connectivity to the infrastructure is 627 available only for short time intervals. Vehicles' applications 628 exchange data packets with nodes in the infrastructure in form of 629 short bursts, containing for example traffic updates or information 630 about local points of interests. In this situation, providing prompt 631 and reliable communication is more important than achieving optimal 632 routing or highest available throughput. In particular, the 633 additional delay for RO establishment with every CRs can have a 634 considerable negative impact. Furthermore, in some situations the 635 path through MR-HA tunnel might be considered more reliable and 636 trustworthy than a direct one to the CR. In particular, the tunnel 637 allows the MR to hide its CoA from the CR which results in a location 638 privacy protection. Therefore: 640 o vehicles should be able to decide whether or not to switch to RO 641 according to various criteria (e.g. speed, density and geographic 642 location of attachment points, trustworthiness of CR etc.); 644 o a lightweight RO scheme providing some degree of optimization 645 (e.g. direct MR-CR routing but with the same packet overhead due 646 to tunneling) and requiring short establishment times is more 647 likely to be selected. 649 Another aspect of the vehicular dynamic scenario is that 650 communication involving the infrastructure takes place mostly with 651 nodes dedicated for vehicular communications, like control centers, 652 notification points, infotainment service providers. In all of these 653 cases, the Correspondent Router is a newly deployed device. 654 Consequently, RO techniques for this scenario are not strictly 655 required to be compatible with CNs implementing legacy MIPv6 RO. 657 In the case of low mobile or static vehicles, the characteristics of 658 the connectivity allow for classical internet-based applications, 659 involving multiple nodes in the infrastructure. This scenario 660 presents less peculiarities than the dynamic one when compared with 661 other NEMO deployments (considering that the sub-IPv6 C2C-CC layer 662 presents a flat topology to NEMO). 664 Other requirements for RO pointed out in Section 6 like multihoming, 665 security and privacy, are fundamental and not related to the dynamics 666 of the scenario. 668 6. NEMO Route Optimization Requirements 670 The C2C-C Consortium has identified the following requirements for 671 NEMO RO techniques. 673 6.1. Req 1 - Separability 675 A RO technique, including its establishment procedure, MUST have the 676 ability to be bypassed by applications that desire to use 677 bidirectional tunnels through the HA. 679 As explained in Section 5, in some scenarios due to the intermittent 680 connectivity, it might not be beneficial to activate RO. Therefore, 681 applications or other management instances in the OBU should be able 682 to trigger the switching to RO according to appropriate criteria. 684 This requirement is also specified in [9]. 686 6.2. Req 2 - MNN IPsec 688 A RO technique SHOULD allow MNNs connected to the MR to use IPsec as 689 if they were connected to a regular access router. 691 This requirement comes from the fact that no assumption can be made 692 on pre-existing trust relationships between passenger devices and the 693 OBU. Therefore, passenger devices (assumed to run IPv6 without 694 Mobility Support) should be able to use full IPsec functionalities 695 when connecting to the infrastructure via a MR. 697 6.3. Req 3 - RO Security 699 A RO technique MUST prevent malicious nodes to claim false MNP 700 ownership. In order to achieve this, a RO technique MAY make use of 701 security features provided by the sub-IPv6 C2C-CC Network layer (e.g. 702 cryptographic protection), but it MUST NOT introduce new security 703 leaks for the C2C-CC applications or render their security measures 704 ineffective. 706 It is required that the security level of a RO scheme is comparable 707 with today's Internet, which is the same goal of MIPv6 Return 708 Routability procedure. In addition to that, as data security is 709 mandatory for safety applications targeted by the C2C-C Consortium 710 and implemented in the left part of the protocol stack depicted in 711 Figure 2, security features will be already implemented in a C2C-CC 712 compliant OBU. The presence of this features might facilitate the 713 design of a lightweight, yet secure, RO technique. 715 C2C-CC security mechanisms are currently discussed and further 716 details are out of scope of this document. As informational 717 references, see [16], [17] and [18]. 719 6.4. Req 4 - Privacy Protection 721 A RO technique MUST not require that the MNP is revealed to all nodes 722 in the visited network. Instead, a RO technique MUST allow for 723 revealing the MNP only to selected nodes in the visited network. 724 Furthermore, a RO technique SHOULD allow that MNP and HoA are not 725 exchanged as clear text. 727 Privacy of drivers and passengers is mandatory for safety 728 applications targeted by the C2C-C Consortium. Mechanisms to 729 implement privacy in the left part of the protocol stack depicted in 730 Figure 2 are currently discussed (e.g. "revocable pseudonimity", 731 where pre-assigned, quasi-random and changing pseudonyms are used as 732 MAC and sub-IPv6 layer identifiers). 734 When using the right part of the stack depicted in Figure 2 to access 735 the Internet using IPv6, users will be aware that the level of 736 privacy protection is decreased. Nevertheless, clear text 737 information that could allow for linking changed pseudonyms by 738 sending constant identifiers should be minimized or even prohibited. 739 In particular, encryption of Home Address and Mobile Network Prefix 740 in NEMO signaling should be considered (e.g. specified as optional 741 mechanism in [3]). 743 C2C-CC privacy protection mechanisms are currently discussed and 744 further details are out of scope of this document. As informational 745 reference, see [15]. 747 6.5. Req 5 - Multihoming 749 A RO technique MUST allow a MR to be simultaneously connected to 750 multiple access networks, having multiple prefixes and Care-Of 751 Addresses in a MONAMI6 context. 753 In other words, it is required that a RO technique can be used on 754 multiple communication technologies. Assuming that mechanisms for 755 registering and handling multiple CoAs are provided from the MONAMI6 756 work, NEMO RO should be usable for every available CoA. 758 This requirement is also specified in [9]. 760 6.6. Req 6 - Coexistence with Sub-IPv6 RO 762 A RO technique MUST allow for coexistence in the same OBU with a RO 763 technique offered by the sub-IPv6 C2C-CC Network layer. The OBU MUST 764 be able to choose which technique to use when both are simultaneously 765 available. 767 The here mentioned sub-IPv6 RO technique is supposed to inject routes 768 into the IPv6 routing table as result of a sub-IPv6 signaling between 769 cars, without involving the infrastructure. A NEMO RO technique 770 should not be disturbed by the sub-IPv6 RO technique. 772 7. IANA Considerations 774 This document does not require any IANA action. 776 8. Security Considerations 778 This document does not specify any protocol therefore does not create 779 any security threat. However, it specifies requirements for a 780 protocol that include security and privacy issues in VANETs as 781 currently discussed in the C2C-C Consortium. 783 9. Acknowledgments 785 The authors would like to thank the members of the work groups PHY/ 786 MAC/NET and APP of the C2C-C Consortium and in particular Tim 787 Leinmueller, Bernd Bochow, Andras Kovacs and Matthias Roeckl. 789 10. References 791 10.1. Normative References 793 [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 794 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 795 January 2005. 797 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 798 IPv6", RFC 3775, June 2004. 800 [3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 801 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 802 Agents", RFC 3776, June 2004. 804 [4] Narten, T. and R. Draves, "Privacy Extensions for Stateless 805 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 807 [5] Crawford, M., "Transmission of IPv6 Packets over Ethernet 808 Networks", RFC 2464, December 1998. 810 [6] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 811 Route Optimization Solution Space Analysis", 812 draft-ietf-nemo-ro-space-analysis (work in progress), 813 September 2006. 815 [7] Ng, C., "Network Mobility Route Optimization Problem 816 Statement", draft-ietf-nemo-ro-problem-statement-03 (work in 817 progress), September 2006. 819 10.2. Informative References 821 [8] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 822 draft-ietf-nemo-terminology-06 (work in progress), 823 November 2006. 825 [9] Eddy, W., Ivancic, W., and T. Davis, "NEMO Route Optimization 826 Requirements for Operational Use in Aeronautics and Space 827 Exploration Mobile Networks", draft-eddy-nemo-aero-reqs-00 828 (work in progress), April 2007. 830 [10] "Car2Car Communication Consortium Official Website", 831 http://www.car-2-car.org/ . 833 [11] "Car2Car Communication Consortium Manifesto", 834 http://www.car-2-car.org/index.php?id=570 , May 2007. 836 [12] "Draft Amendment to Standard for Information Technology . 838 Telecommunications and information exchange between systems . 839 Local and Metropolitan networks . Specific requirements - Part 840 11: Wireless LAN Medium Access Control (MAC) and Physical Layer 841 (PHY) specifications: Amendment 3: Wireless Access in Vehicular 842 Environments (WAVE)", IEEE P802.11p/D1.0, February 2006. 844 [13] McCarthy, B., Edwards, C., Dunmore, M., and R. Aguiar, "The 845 Integration of Ad-hoc (MANET) and Mobile Networking (NEMO): 846 Principles to Support Rescue Team Communication", Proc. of 847 International Conference on Mobile Computing and 848 Ubiquitous Networking (ICMU 2006), October 2006. 850 [14] Baldessari, R., Festag, A., and J. Abeille, "NEMO meets VANET: 851 A Deployability Analysis of Network Mobility in Vehicular 852 Communication", Proc.of 7th International Conference on ITS 853 Telecommunications (ITST2007), June 2007. 855 [15] Fonseca, E., Festag, A., Baldessari, R., and R. Aguiar, 856 "Support of Anonymity in VANETs - Putting Pseudonymity into 857 Practice", Proc.of IEEE Wireless Communication and Networking 858 Conference (WCNC2007), March 2007. 860 [16] Raya, M. and J. Hubaux, "The Security of Vehicular Ad Hoc 861 Networks", Proc.of Workshop on Security of Ad Hoc and 862 Sensor Networks (SASN2005), November 2005. 864 [17] Aijaz, A., Bochow, B., Doetzer, F., Festag, A., Gerlach, M., 865 Leinmueller, T., and R. Kroh, "Attacks on Inter Vehicle 866 Communication Systems - an Analysis", Proc.of International 867 Workshop on Intelligent Transportation (WIT2006), 868 March 2006. 870 [18] Fonseca, E. and A. Festag, "A Survey of Existing Approaches for 871 Secure Ad Hoc Routing and Their Applicability to VANETS", NEC 872 Technical Report NLE-PR-2006-19, March 2006. 874 Authors' Addresses 876 Roberto Baldessari 877 NEC Europe Network Laboratories 878 Kurfuersten-anlage 36 879 Heidelberg 69115 880 Germany 882 Phone: +49 6221 4342167 883 Email: roberto.baldessari@netlab.nec.de 884 Andreas Festag 885 NEC Deutschland GmbH 886 Kurfuersten-anlage 36 887 Heidelberg 69115 888 Germany 890 Phone: +49 6221 4342147 891 Email: andreas.festag@netlab.nec.de 893 Massimiliano Lenardi 894 Hitachi Europe SAS Sophia Antipolis Laboratory 895 Immeuble Le Theleme 896 1503 Route des Dolines 897 Valbonne F-06560 898 France 900 Phone: +33 489 874168 901 Email: massimiliano.lenardi@hitachi-eu.com 903 Full Copyright Statement 905 Copyright (C) The IETF Trust (2007). 907 This document is subject to the rights, licenses and restrictions 908 contained in BCP 78, and except as set forth therein, the authors 909 retain all their rights. 911 This document and the information contained herein are provided on an 912 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 913 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 914 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 915 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 916 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 917 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 919 Intellectual Property 921 The IETF takes no position regarding the validity or scope of any 922 Intellectual Property Rights or other rights that might be claimed to 923 pertain to the implementation or use of the technology described in 924 this document or the extent to which any license under such rights 925 might or might not be available; nor does it represent that it has 926 made any independent effort to identify any such rights. Information 927 on the procedures with respect to rights in RFC documents can be 928 found in BCP 78 and BCP 79. 930 Copies of IPR disclosures made to the IETF Secretariat and any 931 assurances of licenses to be made available, or the result of an 932 attempt made to obtain a general license or permission for the use of 933 such proprietary rights by implementers or users of this 934 specification can be obtained from the IETF on-line IPR repository at 935 http://www.ietf.org/ipr. 937 The IETF invites any interested party to bring to its attention any 938 copyrights, patents or patent applications, or other proprietary 939 rights that may cover technology that may be required to implement 940 this standard. Please address the information to the IETF at 941 ietf-ipr@ietf.org. 943 Acknowledgment 945 Funding for the RFC Editor function is provided by the IETF 946 Administrative Support Activity (IASA).