idnits 2.17.1 draft-jeong-ipwave-vehicular-neighbor-discovery-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 7, 2020) is 1448 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VMI' is mentioned on line 569, but not defined == Missing Reference: 'ARO' is mentioned on line 671, but not defined == Unused Reference: 'RFC8106' is defined on line 944, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-14 ** Downref: Normative reference to an Informational draft: draft-ietf-ipwave-vehicular-networking (ref. 'ID-IPWAVE-PS') ** Downref: Normative reference to an Informational RFC: RFC 5889 == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-08 == Outdated reference: A later version (-11) exists of draft-jeong-ipwave-vehicular-mobility-management-03 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group J. Jeong 3 Internet-Draft Y. Shen 4 Intended status: Standards Track Z. Xiang 5 Expires: November 8, 2020 Sungkyunkwan University 6 S. Cespedes 7 NIC Chile Research Labs 8 May 7, 2020 10 Vehicular Neighbor Discovery for IP-Based Vehicular Networks 11 draft-jeong-ipwave-vehicular-neighbor-discovery-09 13 Abstract 15 This document specifies a Vehicular Neighbor Discovery (VND) as an 16 extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular 17 networks. An optimized Address Registration and a multihop Duplicate 18 Address Detection (DAD) mechanism are performed for having operation 19 efficiency and also saving both wireless bandwidth and vehicle 20 energy. Also, three new ND options for prefix discovery, service 21 discovery, and mobility information report are defined to announce 22 the network prefixes and services inside a vehicle (i.e., a vehicle's 23 internal network). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 8, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. ND Optimization . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Vehicular Network Architecture . . . . . . . . . . . . . . . 7 67 6. ND Extension for Prefix and Service Discovery . . . . . . . . 8 68 6.1. Vehicular Prefix Information Option . . . . . . . . . . . 8 69 6.2. Vehicular Service Information Option . . . . . . . . . . 9 70 6.3. Vehicular Mobility Information Option . . . . . . . . . . 10 71 6.4. Vehicular Neighbor Discovery . . . . . . . . . . . . . . 11 72 6.5. Message Exchange Procedure for V2I Networking . . . . . . 12 73 7. Address Registration and Duplicate Address Detection . . . . 13 74 7.1. Address Autoconfiguration . . . . . . . . . . . . . . . . 14 75 7.2. Address Registration . . . . . . . . . . . . . . . . . . 14 76 7.3. Multihop Duplicate Address Detection . . . . . . . . . . 15 77 7.3.1. DAD without Intermediate Vehicle . . . . . . . . . . 15 78 7.3.2. DAD with one Intermediate Vehicle . . . . . . . . . . 17 79 7.3.3. DAD with multiple Intermediate Vehicles . . . . . . . 18 80 7.4. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 19 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 85 10.2. Informative References . . . . . . . . . . . . . . . . . 21 86 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 87 discovery-08 . . . . . . . . . . . . . . . . . . . . 23 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 Vehicular Ad Hoc Networks (VANET) have been researched for 93 Intelligent Transportation System (ITS) such as driving safety, 94 efficient driving and entertainment. Considering the high-speed 95 mobility of vehicular network based on Dedicated Short-Range 96 Communications (DSRC), IEEE has standardized IEEE 802.11p 98 [IEEE-802.11p] as a MAC protocol for vehicles in Wireless Access in 99 Vehicular Environments (WAVE). IEEE 802.11p was renamed IEEE 802.11 100 Outside the Context of a Basic Service Set (OCB) [IEEE-802.11-OCB] in 101 2012. IEEE has standardized a family standard suite of WAVE 102 [DSRC-WAVE] as IEEE 1609. This IEEE 1609 is considered as a key 103 component in ITS. IEEE 1609 standards include IEEE 1609.0 104 [WAVE-1609.0], 1609.2 [WAVE-1609.2], 1609.3 [WAVE-1609.3], and 1609.4 105 [WAVE-1609.4] to provide a low-latency and alternative network for 106 vehicular communications. What is more, IP-based vehicular networks 107 specialized as IP Wireless Access in Vehicular Environments (IPWAVE) 108 [ID-IPWAVE-PS] can enable many use cases over vehicle-to-vehicle 109 (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything 110 (V2X) communications. IETF has standardized an IPv6 packet delivery 111 protocol over IEEE 802.11-OCB [RFC8691]. 113 VANET features high mobility dynamics, asymmetric and lossy 114 connections, and moderate power constraint (e.g., electric cars and 115 unmanned aerial vehicles). Links among hosts and routers in VANET 116 can be considered as undetermined connectivities with constantly 117 changing neighbors described in [RFC5889]. IPv6 [RFC8200] is 118 selected as the network-layer protocol for Internet applications by 119 IEEE 1609.0 and 1609.3. However, the relatively long-time Neighbor 120 Discovery (ND) process in IPv6 [RFC4861] is not suitable in VANET 121 scenarios. 123 To support the interaction between vehicles or between vehicles and 124 Rode-Side Units (RSUs), this document specifies a Vehicular Neighbor 125 Discovery (VND) as an extension of IPv6 ND for IP-based vehicular 126 networks. VND provides vehicles with an optimized Address 127 Registration and a multihop Duplicate Address Detection (DAD) 128 mechanism. In addition, an efficient mobility management scheme is 129 specified to support efficient V2V, V2I, and V2X communications. 130 Detailed statements of the mobility management are addressed in 131 [ID-IPWAVE-VMM] . 133 2. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 3. Terminology 141 This document uses the terminology described in [RFC4861], [RFC4862], 142 and [RFC6775]. In addition, the following new terms are defined as 143 below: 145 o WAVE: Acronym for "Wireless Access in Vehicular Environments" 146 [WAVE-1609.0]. 148 o Road-Side Unit (RSU): A node that has physical communication 149 devices (e.g., DSRC, Visible Light Communication, 802.15.4, LTE- 150 V2X, etc.) for wireless communications with vehicles and is also 151 connected to the Internet as a router or switch for packet 152 forwarding. An RSU is typically deployed on the road 153 infrastructure, either at an intersection or in a road segment, 154 but may also be located in car parking areas. 156 o On-Board Unit (OBU): A node that has a DSRC device for wireless 157 communications with other OBUs and RSUs, and may be connected to 158 in-vehicle devices or networks. An OBU is mounted on a vehicle. 159 It is assumed that a radio navigation receiver (e.g., Global 160 Positioning System (GPS)) is included in a vehicle with an OBU for 161 efficient navigation. 163 o Mobility Anchor (MA): A node that maintains IP addresses and 164 mobility information of vehicles in a road network to support the 165 address autoconfiguration and mobility management of them. It has 166 end-to-end connections with RSUs under its control. It maintains 167 a DAD Table recording the IP addresses of vehicles moving within 168 the communication coverage of its RSUs. 170 o Vehicular Cloud: A cloud infrastructure for vehicular networks, 171 including compute nodes, storage nodes, and network nodes. 173 o Traffic Control Center (TCC): A node that maintains road 174 infrastructure information (e.g., RSUs, traffic signals, and loop 175 detectors), vehicular traffic statistics (e.g., average vehicle 176 speed and vehicle inter-arrival time per road segment), and 177 vehicle information (e.g., a vehicle's identifier, position, 178 direction, speed, and trajectory as a navigation path). TCC is 179 included in a vehicular cloud for vehicular networks and has MAs 180 under its management. 182 4. Overview 184 This document proposes an optimized ND with a more adaptive structure 185 for vehicular networks compared to [RFC4861] considering fast vehicle 186 mobility and wireless control traffic overhead. Furthermore, prefix 187 and service discovery can be implemented as part of the ND's process 188 along with an efficient Address Registration procedure and DAD 189 mechanism for moving vehicles. This document specifies a set of 190 behaviors between vehicles and RSUs to accomplish these goals. 192 4.1. Link Model 194 There is a relationship between a link and a network prefix along 195 with reachability scopes, such as link-local and global scopes. The 196 legacy IPv6 ND protocol [RFC4861] has the following link model. All 197 IPv6 nodes in the same on-link subnet, which use the same subnet 198 prefix with the on-link bit set, are reachable with each other by 199 one-hop links. The symmetry of the connectivity among the nodes is 200 assumed, that is, bidirectional connectivity between two on-link 201 nodes. However, a link model in vehicular networks (called vehicular 202 link model) should consider the asymmetry of the connectivity that 203 unidirectional links can exist due to interference in wireless 204 channels and the different levels of transmission power employed by 205 wireless network interfaces. 207 The on-link subnet can be constructed by one link (as a basic service 208 set) or multiple links (as an extended service set) called a multi- 209 link subnet [RFC6775]. In this multi-link subnet, an all-node- 210 multicasted packet is copied and related to other links by an ND 211 proxy. On the other hand, in vehicular networks having fast moving 212 vehicles, multiple links can share the same subnet prefix for 213 operation efficiency. For example, if two wireless links under two 214 adjacent RSUs are in the same subnet, a vehicle as an IPv6 host does 215 not need to reconfigure its IPv6 address during handover between 216 those RSUs. However, the packet relay by an RSU as an ND proxy is 217 not required because such a relay can cause a broadcast storm in the 218 extended subnet. Thus, in the multi-link subnet, all-node- 219 multicasting needs to be well-calibrated to either being confined to 220 multicasting in the current link or being disseminated to other links 221 in the same subnet. 223 In a connected multihop VANET, for efficient communication, vehicles 224 in the same link of an RSU can communicate directly with each other, 225 not through the serving RSU. This direct wireless communication is 226 similar to the direct wired communication in an on-link subnet using 227 Ethernet as a wired network. The vehicular link model needs to 228 accommodate both the ad-hoc communication between vehicles and 229 infrastructure communication between a vehicle and an RSU in an 230 efficient and flexible way. Therefore, the IPv6 ND should be 231 extended to accommodate the concept of a new IPv6 link model in 232 vehicular networks. 234 To support multi-link subnet, this specification employs the Shared- 235 Prefix model for prefix assignments. A Shared-Prefix model refers to 236 an addressing model where the prefix(es) are shared by more than one 237 node. In this document, we assume that in a specified subnet, all 238 interfaces of RSUs responding for prefix assignments to vehicles hold 239 the same prefix, which ensure vehicles obtain and maintain the same 240 prefix in this subnet scope. 242 4.2. ND Optimization 244 This document takes advantage of the optimized ND for Low-Power 245 Wireless Personal Area Network (6LoWPAN) [RFC6775] because vehicular 246 environments have common parts with 6LoWPAN, such as the reduction of 247 unnecessary wireless traffic by multicasting and the energy saving in 248 battery. Note that vehicles tend to be electric vehicles whose 249 energy source is from their battery. 251 In the optimized IPv6 ND for 6LoWPAN, the connections among nodes are 252 assumed to be asymmetric and unidirectional because of changing radio 253 environment and loss signal. The authors proposed an optimized IPv6 254 ND which greatly eliminates link-scope multicast to save energy by 255 constructing new options and a new scheme for address configurations. 256 Similarly, this document proposes an improved IPv6 ND by eliminating 257 many link-scope-multicast-based ND operations, such as DAD for IPv6 258 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. Thus, this 259 document suggests an extension of IPv6 ND as vehicular ND tailored 260 for vehicular networks along with new ND options (e.g., prefix 261 discovery, service discovery, and mobility information options). 263 4.3. Design Goals 265 The vehicular ND in this document has the following design goals: 267 o To perform prefix and service discovery through ND procedure; 269 o To implement host-initiated refresh of Router Advertisement (RA) 270 and remove the necessity for routers to use periodic or 271 unsolicited multicast RA to find hosts; 273 o To replace Neighbor Unreachable Detection(NUD), create Neighbor 274 Cache Entries (NCE) for all registered vehicles in RSUs and MA by 275 appending Address Registration Option (ARO) in Neighbor 276 Solicitation (NS), Neighbor Advertisement (NA) messages; 278 o To support a multihop DAD by conveying ND messages received from 279 vehicles to MA to eliminate multicast storms and save energy; and 281 o To support multi-hop communication for vehicles outside the 282 coverage of RSUs to communicate with the serving RSU via a relay 283 neighbor. 285 5. Vehicular Network Architecture 287 A vehicular network architecture for V2I and V2V is illustrated in 288 Figure 1. Three RSUs are deployed along roadsides and are connected 289 to an MA through wired links. There are two subnets such as Subnet1 290 and Subnet2. The wireless links of RSU1 and RSU2 belong to the same 291 subnet named Subnet1, but the wireless link of RSU3 belongs to 292 another subnet named Subnet2. Vehicle2 is wirelessly connected to 293 RSU1 while Vehicle3 and Vehicle4 are connected to RSU2 and RSU3, 294 respectively. Vehicles can directly communicate with each other 295 through V2V connection (e.g., Vehicle1 and Vehicle2) to share driving 296 information. In addition, vehicles not in the range of any RSU may 297 connect with RSU in multi-hop connection via relay vehicle (e.g., 298 Vehicle1 can contact RSU1 via Vehicle2). Vehicles are assumed to 299 start the connection to an RSU when they entered the coverage of the 300 RSU. 302 The document recommends a multi-link subnet involving multiple RSUs 303 as shown in Figure 1. This recommendation aims at the reduction of 304 the frequency with which vehicles have to change their IP address 305 during handover between two adjacent RSUs. To construct this multi- 306 link subnet, a Shared-Prefix model is proposed. That is, for RSUs in 307 the same subnet, the interfaces responsible for prefix assignment for 308 vehicles should hold the same prefix in their global address. This 309 also promises vehicles achieve the same prefix in this scope. When 310 they pass through RSUs in the same subnet, vehicles do not need to 311 perform the Address Registration and DAD again because they can use 312 their current IP address in the wireless coverage of the next RSU. 313 Moreover, this proposal accords with the assumption that nodes 314 belonging to the same IP prefix domain are able to communicate with 315 each other directly without the intervention of RSUs if they are 316 within the wireless communication range of each other. On the other 317 hand, if vehicles enter the wireless coverage of an RSU belonging to 318 another subnet with a different prefix, they repeat the Address 319 Registration and DAD procedure to update their IP address with the 320 new prefix. 322 In Figure 1, RSU1 and RSU2 are deployed in a multi-link subnet with 323 the same prefix address in their interfaces responding for connection 324 with vehicles. When vehicle2 leaves the coverage of RSU1 and enters 325 RSU2, it maintains its address configuration and ignores Address 326 Registration and DAD steps. If vehicle2 moves into the coverage of 327 RSU3, since RSU3 belongs to another subnet and holds a different 328 prefix from RSU1 and RSU2, so vehicle2 must do Address Registration 329 and DAD just as connecting to a new RSU. Note that vehicles and RSUs 330 have their internal networks including in-vehicle devices and 331 servers, respectively. The structures of the internal networks are 332 described in [ID-IPWAVE-PS]. 334 Traffic Control Center in Vehicular Cloud 335 *-----------------------------------------* 336 * * 337 * +----------------+ * 338 * | Mobility Anchor| * 339 * +----------------+ * 340 * ^ * 341 * | * 342 *------------------v----------------------* 343 ^ ^ ^ 344 | | | 345 | | | 346 v v v 347 +--------+ Ethernet +--------+ +--------+ 348 | RSU1 |<-------->| RSU2 |<---------->| RSU3 | 349 +--------+ +--------+ +--------+ 350 ^ ^ ^ 351 : : : 352 +-------------------------------------+ +-----------------+ 353 | : V2I V2I : | | V2I : | 354 | v v | | v | 355 +--------+ | +--------+ +--------+ | | +--------+ | 356 |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>| 357 | |<...>| |<........>| | | | | | | 358 +--------+ V2V +--------+ V2V +--------+ | | +--------+ | 359 | | | | 360 +-------------------------------------+ +-----------------+ 361 Subnet1 Subnet2 363 <----> Wired Link <....> Wireless Link ===> Moving Direction 365 Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 367 6. ND Extension for Prefix and Service Discovery 369 This section specifies an IPv6 ND extension for vehicle-to-vehicle 370 (V2V) or vehicle-to-infrastructure (V2I) networking. This section 371 also defines three new ND options for prefix discovery, service 372 discovery, and mobility information report: (i) Vehicular Prefix 373 Information (VPI) option, (ii) Vehicular Service Information (VSI) 374 option, and (iii) Vehicular Mobility Information (VMI) option. It 375 also describes the procedure of the ND protocol with those options. 377 6.1. Vehicular Prefix Information Option 379 The VPI option contains IPv6 prefix informations in the internal 380 network. Figure 2 shows the format of the VPI option. 382 0 1 2 3 383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Type | Length | Prefix Length | Distance | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Reserved | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | | 390 : Prefix : 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 2: Vehicular Prefix Information (VPI) Option Format 396 Fields: 397 Type 8-bit identifier of the VPI option type as assigned 398 by the IANA: TBD 400 Length 8-bit unsigned integer. The length of the option 401 (including the Type and Length fields) is in units of 402 8 octets. The value is 3. 404 Prefix Length 8-bit unsigned integer. The number of leading bits 405 in the Prefix that are valid. The value ranges 406 from 0 to 128. 408 Distance 8-bit unsigned integer. The distance between the 409 subnet announcing this prefix and the subnet 410 corresponding to this prefix in terms of the number 411 of hops. 413 Reserved This field is unused. It MUST be initialized to 414 zero by the sender and MUST be ignored by the 415 receiver. 417 Prefix An IP address or a prefix of an IP address. The 418 Prefix Length field contains the number of valid 419 leading bits in the prefix. The bits in the prefix 420 after the prefix length are reserved and MUST be 421 initialized to zero by the sender and ignored by 422 the receiver. 424 6.2. Vehicular Service Information Option 426 The VSI option contains vehicular service information in the internal 427 network. Figure 3 shows the format of the VSI option. 429 0 1 2 3 430 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Type | Length | Reserved1 | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Protocol | Reserved2 | Port Number | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 : Node Address : 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Figure 3: Vehicular Service Information (VSI) Option Format 443 Fields: 444 Type 8-bit identifier of the VSI option type as assigned 445 by the IANA: TBD 447 Length 8-bit unsigned integer. The length of the option 448 (including the Type and Length fields) is in units of 449 8 octets. The value is 3. 451 Reserved1 This field is unused. It MUST be initialized to 452 zero by the sender and MUST be ignored by the 453 receiver. 455 Protocol 8-bit unsigned integer to indicate the upper-layer 456 protocol, such as transport-layer protocol (e.g., 457 TCP, UDP, and SCTP). 459 Reserved2 This field is unused. It MUST be initialized to 460 zero by the sender and MUST be ignored by the 461 receiver. 463 Port Number 16-bit unsigned integer to indicate the port number 464 for this protocol. 466 Service Address 467 128-bit IPv6 address of a node providing this vehicular 468 service. 470 6.3. Vehicular Mobility Information Option 472 The VMI option contains one vehicular mobility information of a 473 vehicle or an RSU. Figure 4 shows the format of the VMI option. 475 0 1 2 3 476 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type | Length | Reserved1 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Reserved2 | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | 483 : Mobility Information : 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Figure 4: Vehicular Mobility Information (VMI) Option Format 489 Fields: 490 Type 8-bit identifier of the VMI option type as assigned 491 by the IANA: TBD 493 Length 8-bit unsigned integer. The length of the option 494 (including the Type and Length fields) is in units of 495 8 octets. The value is 3. 497 Reserved1 This field is unused. It MUST be initialized to 498 zero by the sender and MUST be ignored by the 499 receiver. 501 Reserved2 This field is unused. It MUST be initialized to 502 zero by the sender and MUST be ignored by the 503 receiver. 505 Mobility Information 506 128-bit mobility information, such as position, 507 speed, acceleration/deceleration, and direction. 509 6.4. Vehicular Neighbor Discovery 511 Prefix discovery enables hosts (e.g., vehicles and in-vehicle 512 devices) to distinguish destinations on the same link from those only 513 reachable via RSUs. A vehicle (or its in-vehicle devices) can 514 directly communicate with on-link vehicles (or their in-vehicle 515 devices) without the relay of an RSU, but through V2V communications 516 along with VPI ND option. This VPI option contains IPv6 prefixes in 517 a vehicle's internal network. 519 Vehicles announce services in their internal networks to other 520 vehicles through an VSI ND option. The VSI option contains a list of 521 vehicular services in a vehicle's or an RSU's internal network. 523 A vehicle periodically announces an NS message containing VPI and VSI 524 options with its prefixes and services in all-nodes multicast address 525 to reach all neighboring nodes. When it receives this NS message, 526 another neighboring node responds to this NS message by sending an NA 527 message containing the VPI and VSI options with its prefixes and 528 services via unicast towards the NS-originating node. 530 Therefore, prefix and service discovery can be achieved via ND 531 messages (e.g., NS and NA) by vehicular ND with VPI and VSI options. 532 This VND-based discovery eliminates an additional prefix and service 533 discovery scheme, such as DNS-based Service Discovery [RFC6763] 534 (e.g., Multicast DNS (mDNS) [RFC6762] and DNSNA [ID-DNSNA]), other 535 than ND. That is, vehicles and RSUs can rapidly discover the network 536 prefixes and services of the other party without any additional 537 service discovery protocol. 539 6.5. Message Exchange Procedure for V2I Networking 541 This subsection explains a message exchange procedure for VND in V2I 542 networking, where a vehicle communicates with its corresponding node 543 in the Internet via an RSU. 545 Figure 5 shows an example of message exchange procedure in V2I 546 networking. Detailed steps of the procedure are explained in 547 Section 7. The mobility management part is described in 548 [ID-IPWAVE-VMM]. 550 Note that a vehicle could also perform the prefix and service 551 discovery simultaneously along with Address Registration procedure, 552 as shown in Figure 7. 554 This document specified that RSUs as routers do not transmit 555 periodical and unsolicited multicast RA messages including a prefix 556 for energy saving in vehicular networks. Vehicles as hosts 557 periodically initiate an RS message according to a time interval 558 (considering its position and an RSU's coverage). Since they have a 559 digital road map with the information of RSUs (e.g., position and 560 communication coverage), vehicles can know when they will go out of 561 the communication range of an RSU along with the signal strength 562 (e.g., Received Channel Power Indicator (RCPI) [VIP-WAVE]) from the 563 RSU. RSUs replies with a solicited RA in unicast only when they 564 receive an RS message. 566 Vehicle RSU MA 567 | | | 568 |-RS with Mobility Info->| | 569 | [VMI] | | 570 | | | 571 | |-----------PBU--------->| 572 | | | 573 | | | 574 | |<----------PBA----------| 575 | | | 576 | | | 577 | |======Bi-Dir Tunnel=====| 578 | | | 579 | | | 580 |<----RA with prefix-----| | 581 | | | 582 | | | 583 | | | 584 |--NS with Address Reg-->| | 585 | [ARO+VPI+VSI] | | 586 | | | 587 | |---Forward NS for DAD-->| 588 | | | 589 | | | 590 | |<--NA with DAD result---| 591 | | [ARO+VPI+VSI] | 592 |<------Forward NA-------| | 593 | | | 595 Figure 5: Message Interaction for Vehicular Neighbor Discovery 597 7. Address Registration and Duplicate Address Detection 599 This section explains address configuration, consisting of IP Address 600 Autoconfiguration, Address Registration, and multihop DAD via V2I or 601 V2V. 603 This document recommends a new Address Registration and DAD scheme in 604 order to avoid multicast flooding and decrease link-scope multicast 605 for energy and wireless channel conservation on a large-scale 606 vehicular network. Host-initiated refresh of RA removes the 607 necessity for routers to use frequent and unsolicited multicast RAs 608 to accommodate hosts. This also enables the same IPv6 address 609 prefix(es) to be used across a subnet. 611 There are three scenarios feasible in Address Registration scheme: 613 1. Vehicle enters the subnet for the first time or the current RSU 614 belongs to another subnet: Vehicles need to perform the Address 615 Registration and multihop DAD as described in the following 616 subsections. 618 2. Vehicle has already configured its IP addresses with prefix 619 obtained from the previous RSU, and the current RSU located in 620 the same subnet: This means RSUs have the same prefix and the 621 vehicle has no need to repeat the Address Registration and 622 multihop DAD. 624 3. Vehicle is not in the coverage of RSU but has a neighbor 625 registered in RSU: This document proposes a new V2V scenario for 626 vehicles which are currently not in the range of the RSU. If a 627 user vehicle failed to find an on-link RSU, it starts to look for 628 adjacent vehicle neighbors which can work as a relay neighbor to 629 share the prefix obtained from RSU and undertake DAD of the user 630 vehicle by forwarding DAD messages to RSU. 632 7.1. Address Autoconfiguration 634 A vehicle as an IPv6 host creates its link-local IPv6 address and 635 global IPv6 address as follows [RFC4862]. When they receive RS 636 messages from vehicles, RSUs send back RA messages containing prefix 637 information. The vehicle makes its global IPv6 addresses by 638 combining the prefix for its current link and its link-layer address. 640 The address autoconfiguration does not perform the legacy DAD as 641 defined in [RFC4862]. Instead, a new multihop DAD is performed in 642 Section 7.3. 644 7.2. Address Registration 646 After its IP tentative address autoconfiguration with the known 647 prefix from an RSU and its link-layer address, a vehicle starts to 648 register its IP address to the serving RSU along with multihop DAD. 649 Address Register Option (ARO) is used in this step and its format is 650 defined in [RFC6775]. 652 ARO is always host-initiated by vehicles. Information such as 653 registration time and registration status contained in ARO are 654 applied to indicate the registration duration and result. ARO will 655 also be forwarded to MA together with NS by RSUs. 657 An example message exchange procedure of Address Registration is 658 presented in Figure 6. Since Address Registration is performed 659 simultaneously with the multihop DAD, the specific procedure is 660 together described with the DAD mechanism in Section 7.3. 662 Vehicle RSU 663 | | 664 | | 665 1. |----NS with Address Reg--->| 666 | [ARO] | 667 | | 668 | | 669 | | 670 2. |<---NA with Address Reg----| 671 | [ARO] | 673 Figure 6: Neighbor Discovery Address Registration 675 7.3. Multihop Duplicate Address Detection 677 Before it can exchange data, a node should determine whether its IP 678 address is already used by another node or not. In the legacy IPv6 679 ND, hosts multicast NS messages to all nodes in the same on-link 680 subnet for DAD. Instead of this, an optimized multihop DAD is 681 designed to eliminate multicast messages for energy-saving purpose. 682 For this multihop DAD, Neighbor Cache and DAD Table are maintained by 683 each RSU and an MA, respectively, for the duplicate address 684 inspection during the multihop DAD process. That is, each RSU makes 685 Neighbor Cache Entries (NCE) of all the on-link hosts in its Neighbor 686 Cache. Similarly, the MA stores all the NCEs reported by the RSUs in 687 its DAD Table. 689 With the multihop DAD, a vehicle can skip the multicast-based DAD in 690 its current wireless link whenever it enters the coverage of another 691 RSU in the same subset, leading to the reduction of traffic overhead 692 in vehicular wireless links. 694 For the multihop DAD, we take advantage of the procedure of [RFC6775] 695 but simplified the message flows by canceling the two new ICMPv6 696 message types such as Duplicate Address Request (DAR) and the 697 Duplicate Address Confirmation (DAC). Instead, NS and NA containing 698 ARO are directly forwarded between RSU and MA. This idea is raised 699 because DAR and DAC 701 7.3.1. DAD without Intermediate Vehicle 703 Figure 7 presents the procedure of Address Registration and multihop 704 DAD. The detailed steps are explained as follows. 706 Vehicle RSU MA 707 | | | 708 | | | 709 1. |--NS with Address Reg-->| | 710 | [ARO+VPI+VSI] | | 711 | | | 712 2. | |----Forward NS--->| 713 | | | 714 | | | 715 3. | |<---Forward NA----| 716 | | | 717 | | | 718 4. |<--NA with Address Reg--| | 719 | [ARO+VPI+VSI] | | 721 Figure 7: Neighbor Discovery Address Registration with Multihop DAD 723 1. A vehicle sends an NS message to the current RSU in unicast, 724 containing the ARO to register its address. 726 2. The RSU receives the NS message, and then inspects its Neighbor 727 Cache to check whether it is duplicate or not. If there is no 728 duplicate NCE, a tentative NCE is created for this address, and 729 then the RSU forward the NS message containing the ARO to the MA 730 for the multihop DAD. 732 3. When the MA receives NS from an RSU, it checks whether the 733 register-requested address exists in its DAD Table or not. If an 734 entry with the same address exists in the DAD Table, which means 735 that the address is considered "Duplicate Address", then MA 736 returns a NA message containing the registration status in ARO to 737 notify the RSU of the address duplication. If no entry with the 738 same address exists in the DAD Table, which means that an entry 739 for the address is created, then MA replies a NA message to the 740 RSU to confirm the uniqueness of the register-requested address 741 to the RSU. 743 4. If the address duplication is notified by the MA, the RSU deletes 744 the tentative NCE, and forward NA with to the address- 745 registration vehicle to notify the registration failure. 746 Otherwise, the RSU changes the tentative NCE into a registered 747 NCE in its Neighbor Cache, and then forward NA to the vehicle to 748 notify the registration success. 750 Thus, the multihop DAD is processed simultaneously with the Address 751 Registration. Note that the tentative address is not considered 752 assigned to the vehicle until the MA confirms the uniqueness of the 753 register-requested address in the multihop DAD. 755 7.3.2. DAD with one Intermediate Vehicle 757 If a vehicle failed to register a default router, it triggers 758 neighbor discovery to look for vehicle neighbors which can provide 759 relay service using multi-hop communication. In this specification, 760 we assumed vehicles would not emulate V2V communication and trigger 761 relay scenario only if Router Discovery(RD) failed. 763 User Vehicle Relay Vehicle RSU MA 764 | | | | 765 |------------------------| | | 766 | RD failed | | | 767 |------------------------| | | 768 | | | | 769 | | | | 770 |-----------NS---------->| | | 771 | | | | 772 |<--NA with Prefix Info--| | | 773 | | | | 774 | | | | 775 |--NS with Address Reg-->| | | 776 | [ARO+VPI+VSI] | | | 777 | |----- Forward NS ----->| | 778 | | | | 779 | | |-----------------| 780 | | | Same as Figure 9| 781 | | |-----------------| 782 | | | | 783 | |<--NA with Address Reg-| | 784 | | [ARO+VPI+VSI] | | 785 |<------ Forward NA -----| | | 786 | | | | 788 Figure 8: Address Registration and Multihop DAD via V2V Relay 790 Since vehicles have a digital road map with the information of RSUs 791 (e.g., position and communication coverage), they can determine if 792 they are available to serve as a relay vehicle. Only vehicles with 793 the ability to serve as temporary relays will take action when they 794 receive relay service requests. The user vehicle can process global 795 address configuration, Address Registration and DAD through its relay 796 vehicle before it enters the coverage of RSUs. See Figure 8. 798 When a user vehicle failed to directly register to an RSU, it 799 initiates neighbor discovery to detect vehicle neighbors through V2V 800 communication. Vehicle sends NS messages to connect with neighbors 801 in range. If neighbor can provide relay service, it creates a NCE 802 for user vehicle, setting its own address as relay address, and sends 803 back NA with prefix information received from RSU. 805 To guarantee vehicles could find the nearest neighbor from multiple 806 neighbors which can act as relay vehicles, a new time-out mechanism 807 is presented to select the nearest neighbor by hop distance parameter 808 carried in Prefix Information Option. That is, a user vehicle 809 multicast NS messages to look for relay vehicles after RD failed and 810 wait for 1.5 seconds to receive all NA replies from neighbors. Each 811 NA carries its own global prefix(es) and the hop distance(s) in 812 Prefix Information Option. The user vehicle preserves every NA reply 813 in a temporary router list and select the one with least hop counts 814 as its relay vehicle after time out. 816 With receipt of NA, user vehicle configures its global address with 817 prefix information as mentioned in Section 7.1. After this, user 818 vehicle takes up to initiate the Address Registration along with DAD 819 process via relay vehicle. NS message is configured as specified in 820 Section 7.2 but indicate the relay vehicle's address as next-hop to 821 reach the RSU. In such a case, when relay vehicle receives relay 822 request message, it will forward NS message to RSU. The procedure 823 sets up on the rails except MA will include the relay vehicle's 824 address as relay address in NCE to indicate that at this moment, it 825 is not a directly attached vehicle, and sets the relay address as 826 next-hop address. Relay vehicle forwards DAD result information 827 message to user vehicle as soon as it received. 829 7.3.3. DAD with multiple Intermediate Vehicles 831 This document supports multihop communications (e.g., multihop DAD 832 and UDP/TCP transmission) for remote vehicles through multiple relay 833 vehicles. Vehicles which have already finished DAD process can serve 834 as temporary routers and forward packets for remote vehicles. 836 A new routing mechanism is specified to accomplish route selections 837 among user vehicles and serving RSUs when multiple vehicles act as 838 relay vehicles. Taking advantage of the Destination-Sequenced 839 Distance-Vector routing protocol (DSDV) [DSDV], this new routing 840 approach supposes that each vehicle holds a Neighbor Routing 841 Table which integrates the neighbor information in Neighbor Cache and 842 forwarding records for remote vehicles. Each vehicle which acts as a 843 relay vehicle for this remote vehicle will make records in its 844 Neighbor Routing Table. 846 Figure 9 specifies an example of parameters in Neighbor Routing 847 Table when more than one vehicle work as intermediate relay vehicles. 849 In Figure 9, Vehicle3 connects RSU1 indirectly via Vehicle2 and 850 Vehicle1. When Vehicle1 and Vehicle2 forward messages for Vehicle3, 851 they make records in its Neighbor Routing Table including the next- 852 hop node to indicate the route to Vehicle3. This can ensure that the 853 packets from a source vehicle can be successfully transmitted to an 854 RSU as well as the reverse packet path exists from the RSU to the 855 source vehicle. 857 +--------+ +--------+ +--------+ +--------+ 858 |Vehicle3|<......>|Vehicle2|<........>|Vehicle1|<.......> | RSU1 | 859 | (V3) | V2V | (V2) | V2V | (V1) | V2I | | 860 +--------+ +--------+ +--------+ +--------+ 862 +------------+ +------------+ +------------+ +------------+ 863 |Node|NextHop| |Node|NextHop| |Node|NextHop| |Node|NextHop| 864 +------------+ +------------+ +------------+ +------------+ 865 | V2 | V2 | | V1 | V1 | |RSU1| RSU1 | | V1 | V1 | 866 +------------+ | V3 | V3 | | V2 | V2 | | V2 | V1 | 867 +------------+ | V3 | V2 | | V3 | V1 | 868 +------------+ +------------+ 870 Figure 9: An Example of Neighbor Routing Table when multiple Vehicles 871 act as Relay Vehicles 873 7.4. Pseudonym Handling 875 Considering the privacy protection of a vehicle, a pseudonym 876 mechanism for its link-layer address is requested. This mechanism 877 periodically modifies the link-layer address, leading to the update 878 of the corresponding IP address. A random MAC Address Generation 879 mechanism is proposed in Appendix F.4 of [IEEE-802.11-OCB] by 880 generating the 46 remaining bits of MAC address using a random number 881 generator. When it changes its MAC address, a vehicle should ask the 882 serving RSU to update its own NCE, and to register its IP address 883 into the MA again. 885 8. Security Considerations 887 This document shares all the security issues of the neighbor 888 discovery protocol and 6LoWPAN protocol. This document can get 889 benefits from secure neighbor discovery (SEND) [RFC3971] in order to 890 protect ND from possible security attacks. 892 9. Acknowledgments 894 This work was supported by Basic Science Research Program through the 895 National Research Foundation of Korea (NRF) funded by the Ministry of 896 Education (2017R1D1A1B03035885). 898 This work was supported in part by Institute of Information & 899 Communications Technology Planning & Evaluation (IITP) grant funded 900 by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, 901 Cloud based Security Intelligence Technology Development for the 902 Customized Security Service Provisioning). 904 This work was supported in part by the MSIT under the ITRC 905 (Information Technology Research Center) support program (IITP- 906 2019-2017-0-01633) supervised by the IITP. 908 10. References 910 10.1. Normative References 912 [ID-IPWAVE-PS] 913 Jeong, J., Ed., "IPv6 Wireless Access in Vehicular 914 Environments (IPWAVE): Problem Statement and Use Cases", 915 draft-ietf-ipwave-vehicular-networking-14 (work in 916 progress), March 2020. 918 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 919 Requirement Levels", BCP 14, RFC 2119, March 1997. 921 [RFC3971] Arkko, J., "SEcure Neighbor Discovery (SEND)", RFC 3971, 922 March 2005. 924 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 925 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 926 September 2007. 928 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 929 Address Autoconfiguration", RFC 4862, September 2007. 931 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 932 Hoc Networks", RFC 5889, September 2010. 934 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 935 February 2013. 937 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 938 Discovery", RFC 6763, February 2013. 940 [RFC6775] Shelby, Z., Ed., "Neighbor Discovery Optimization for IPv6 941 over Low-Power Wireless Personal Area Networks 942 (6LoWPANs)", RFC 6775, November 2012. 944 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 945 "IPv6 Router Advertisement Options for DNS Configuration", 946 RFC 8106, March 2017. 948 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 949 (IPv6) Specification", RFC 8200, July 2017. 951 [RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic 952 Support for IPv6 Networks Operating Outside the Context of 953 a Basic Service Set over IEEE Std 802.11", RFC 8691, 954 December 2019. 956 10.2. Informative References 958 [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 959 Sequenced Distance-Vector Routing (DSDV) for Mobile 960 Computers", ACM SIGCOMM, August 1994. 962 [DSRC-WAVE] 963 Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its 964 Architecture, Design, and Characteristics", 965 IEEE Communications Surveys & Tutorials, 12(4), 2012. 967 [ID-DNSNA] 968 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 969 Autoconfiguration for Internet-of-Things Devices in IP- 970 Based Vehicular Networks", draft-jeong-ipwave-iot-dns- 971 autoconf-08 (work in progress), May 2020. 973 [ID-IPWAVE-VMM] 974 Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular 975 Mobility Management for IP-Based Vehicular Networks", 976 draft-jeong-ipwave-vehicular-mobility-management-03 (work 977 in progress), May 2020. 979 [IEEE-802.11-OCB] 980 "Part 11: Wireless LAN Medium Access Control (MAC) and 981 Physical Layer (PHY) Specifications", IEEE Std 982 802.11-2016, December 2016. 984 [IEEE-802.11p] 985 "Part 11: Wireless LAN Medium Access Control (MAC) and 986 Physical Layer (PHY) Specifications Amendment 6: Wireless 987 Access in Vehicular Environments", June 2010. 989 [VIP-WAVE] 990 Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the 991 Feasibility of IP Communications in 802.11p Vehicular 992 Networks", IEEE Transactions on Intelligent Transportation 993 Systems, vol. 14, no. 1, March 2013. 995 [WAVE-1609.0] 996 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 997 in Vehicular Environments (WAVE) - Architecture", IEEE Std 998 1609.0-2013, March 2014. 1000 [WAVE-1609.2] 1001 IEEE 1609 Working Group, "IEEE Standard for Wireless 1002 Access in Vehicular Environments - Security Services for 1003 Applications and Management Messages", IEEE Std 1004 1609.2-2016, March 2016. 1006 [WAVE-1609.3] 1007 IEEE 1609 Working Group, "IEEE Standard for Wireless 1008 Access in Vehicular Environments (WAVE) - Networking 1009 Services", IEEE Std 1609.3-2016, April 2016. 1011 [WAVE-1609.4] 1012 IEEE 1609 Working Group, "IEEE Standard for Wireless 1013 Access in Vehicular Environments (WAVE) - Multi-Channel 1014 Operation", IEEE Std 1609.4-2016, March 2016. 1016 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 1017 discovery-08 1019 The following changes are made from draft-jeong-ipwave-vehicular- 1020 neighbor-discovery-08: 1022 o This version has a submission date update to maintain the active 1023 status of the draft. 1025 o This version updates the version numbers of the referenced drafts. 1027 Authors' Addresses 1029 Jaehoon Paul Jeong 1030 Department of Computer Science and Engineering 1031 Sungkyunkwan University 1032 2066 Seobu-Ro, Jangan-Gu 1033 Suwon, Gyeonggi-Do 16419 1034 Republic of Korea 1036 Phone: +82 31 299 4957 1037 Fax: +82 31 290 7996 1038 EMail: pauljeong@skku.edu 1039 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1041 Yiwen Chris Shen 1042 Department of Electrical and Computer Engineering 1043 Sungkyunkwan University 1044 2066 Seobu-Ro, Jangan-Gu 1045 Suwon, Gyeonggi-Do 16419 1046 Republic of Korea 1048 Phone: +82 31 299 4106 1049 Fax: +82 31 290 7996 1050 EMail: chrisshen@skku.edu 1052 Zhong Xiang 1053 Department of Electrical and Computer Engineering 1054 Sungkyunkwan University 1055 2066 Seobu-Ro, Jangan-Gu 1056 Suwon, Gyeonggi-Do 16419 1057 Republic of Korea 1059 Phone: +82 10 9895 1211 1060 Fax: +82 31 290 7996 1061 EMail: xz618@skku.edu 1062 Sandra Cespedes 1063 NIC Chile Research Labs 1064 Universidad de Chile 1065 Av. Blanco Encalada 1975 1066 Santiago 1067 Chile 1069 Phone: +56 2 29784093 1070 EMail: scespede@niclabs.cl