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