idnits 2.17.1 draft-jeong-ipwave-vehicular-neighbor-discovery-03.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 (July 2, 2018) is 2125 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) == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-03 Summary: 1 error (**), 0 flaws (~~), 2 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 Y. Jo 5 Expires: January 3, 2019 Sungkyunkwan University 6 J. Jeong 7 Samsung Electronics 8 J. Lee 9 Sangmyung University 10 July 2, 2018 12 IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular 13 Networks 14 draft-jeong-ipwave-vehicular-neighbor-discovery-03 16 Abstract 18 This document specifies an extension of IPv6 Neighbor Discovery (ND) 19 for rapid network prefix and service discovery in vehicular networks. 20 It is assumed that a vehicle or a Road-Side Unit (RSU) have an 21 external network interface and their internal network. The extended 22 IPv6 ND called vehicular ND can support vehicle-to-infrastructure 23 communications as well as vehicle-to-vehicle communications. This 24 document defines new ND options to allow a vehicle to announce the 25 network prefixes and services inside its internal network to another 26 vehicle or RSU. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 3, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 5. ND Extension for Prefix and Service Discovery . . . . . . . . 6 67 5.1. Vehicular Prefix Information Option . . . . . . . . . . . 6 68 5.2. Vehicular Service Information Option . . . . . . . . . . 7 69 5.3. Vehicular Neighbor Discovery . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 8.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Vehicular Ad Hoc Networks (VANET) have been researched for the 80 networking on intelligent services in road networks, such as driving 81 safety, efficient driving, and entertainment. To enable this VANET 82 in road networks, Dedicated Short-Range Communications (DSRC) 83 [DSRC-WAVE] has been standardized as IEEE 802.11p [IEEE-802.11p], 84 which is an extension of IEEE 802.11a [IEEE-802.11a], considering the 85 characteristics of vehicular networks, such as high-speed mobility 86 and network fragmentation. Note that IEEE 802.11p was renamed IEEE 87 802.11 Outside the Context of a Basic Service Set (OCB) 88 [IEEE-802.11-OCB] in 2012. For Wireless Access in Vehicular 89 Environments (WAVE) [DSRC-WAVE][WAVE-1609.0], the IEEE has 90 standardized IEEE 1609 family standards, such as IEEE 1609.2, 1609.3, 91 and 1609.4 [WAVE-1609.2][WAVE-1609.3][WAVE-1609.4]. The IEEE 1609 92 standards specify IPv6 as the network-layer protocol [WAVE-1609.3]. 94 Many automobile vendors are replacing Controller Area Networks (CANs) 95 with Ethernet for high-speed interconnectivity among Electronic 96 Control Units (ECUs) in a vehicle. The sensing information of the 97 ECUs can be delivered to the service centers of those automobile 98 ventors for remote diagnosis for driving safety using DSRC between 99 vehicles and Road-Side Units (RSUs) having the Internet connectivity 100 toward the service centers in a vehicular cloud. 102 With this trend, it is time to enable vehicular networking with IPv6 103 to let various Internet-based applications (e.g., remote vehicle 104 diagnosis) run on top of transport-layer protocols, such as TCP, UDP, 105 and SCTP. IPv6 [RFC8200] is suitable for a network layer in 106 vehicular networks in that the protocol has abundant address space, 107 autoconfiguration features, and protocol extension ability through 108 extension headers. 110 To support the interaction between vehicles or between a vehicle and 111 an RSU, this document specifies an extension of IPv6 ND [RFC4861] for 112 rapid network prefix and service discovery in vehicular networks with 113 new ND options. That is, the extended IPv6 ND in this document, 114 which is called vehicular ND, can support not only vehicle-to- 115 infrastructure (V2I) communications but also vehicle-to-vehicle (V2V) 116 communications. 118 2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 3. Terminology 126 This document uses the terminology described in [RFC4861] and 127 [RFC4862]. In addition, four new terms are defined below: 129 o Road-Side Unit (RSU): A node that has a Dedicated Short-Range 130 Communications (DSRC) device for wireless communications with the 131 vehicles and is connected to the Internet. Every RSU is usually 132 deployed at an intersection so that it can provide vehicles with 133 the Internet connectivity. 135 o Vehicle: A node that has the DSRC device for wireless 136 communications with vehicles and RSUs. Every vehicle may also 137 have a GPS-navigation system for efficient driving. 139 o Traffic Control Center (TCC): A node that maintains road 140 infrastructure information (e.g., RSUs and traffic signals), 141 vehicular traffic statistics (e.g., average vehicle speed and 142 vehicle inter-arrival time per road segment), and vehicle 143 information (e.g., a vehicle's identifier, position, direction, 144 speed, and trajectory). TCC is included in a vehicular cloud for 145 vehicular networks. 147 4. Overview 149 This document specifies an IPv6 ND extension for vehicle-to-vehicle 150 (V2V) or vehicle-to-infrastructure (V2I) networking. 152 Figure 1 shows the V2V networking of two vehicles whose internal 153 networks are Moving Network1 and Moving Network2, respectively. 154 Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and 155 Host2), and the two routers (Router1 and Router2). Vehicle2 has the 156 DNS Server (RDNSS2), the two hosts (Host3 and Host4), and the two 157 routers (Router3 and Router4). 159 It is assumed that Host1 and Host3 are running a Cooperative Adaptive 160 Cruise Control (C-ACC) program for physical collision avoidance. 161 Also, it is assumed that Host2 and Host4 are running a Cooperative 162 On-board Camera Sharing (C-OCS) program for sharing road hazards or 163 obstacles to avoid road accidents. Vehicle1's Router1 and Vehicle2's 164 Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for 165 V2V networking for various vehicular services. The vehicular 166 applications, such as C-ACC and C-BCS, can be registered into the DNS 167 Server (i.e., RDNSS) through DNSNA protocol in [ID-DNSNA] along with 168 IPv6 ND DNS options in [RFC8106]. 170 Vehicle1's Router1 and Vehicle2's Router3 can know what vehicular 171 applications exist in their internal network by referring to their 172 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 173 what network prefixes exist in their internal network through an 174 intra-domain routing protocoli, such as OSFP. Each vehicle announces 175 its network prefixes and services through ND options defined in 176 Section 5. 178 (*)<..........>(*) 179 | | 2001:DB8:1:1::/64 180 .------------------------------. .------------------------------. 181 | | | | | | 182 | .-------. .------. .-------. | | .-------. .------. .-------. | 183 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 184 | ._______. .______. ._______. | | ._______. .______. ._______. | 185 | ^ ^ ^ | | ^ ^ ^ | 186 | | | | | | | | | | 187 | v v v | | v v v | 188 | ---------------------------- | | ---------------------------- | 189 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 190 | | | | | | 191 | v | | v | 192 | .-------. .-------. | | .-------. .-------. | 193 | | Host2 | |Router2| | | |Router4| | Host4 | | 194 | ._______. ._______. | | ._______. ._______. | 195 | ^ ^ | | ^ ^ | 196 | | | | | | | | 197 | v v | | v v | 198 | ---------------------------- | | ---------------------------- | 199 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 200 .______________________________. .______________________________. 201 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 203 <----> Wired Link <....> Wireless Link (*) Antenna 205 Figure 1: Internetworking between Vehicle Networks 207 Figure 2 shows the V2I networking of a vehicle and an RSU whose 208 internal networks are Moving Network1 and Fixed Network1, 209 respectively. Vehicle1 has the DNS Server (RDNSS1), the two hosts 210 (Host1 and Host2), and the two routers (Router1 and Router2). RSU1 211 has the DNS Server (RDNSS2), one host (Host3), the two routers 212 (Router3 and Router4). 214 It is assumed that RSU1 has a collection of servers (Server1 to 215 ServerN) for various services in the road networks, such as road 216 emergency notification and navigation services. Vehicle1's Router1 217 and RSU1's Router3 use 2001:DB8:1:1::/64 for an external link (e.g., 218 DSRC) for I2V networking for various vehicular services. The 219 vehicular applications, such as road emergency notification and 220 navigation services, can be registered into the DNS Server (i.e., 221 RDNSS) through DNSNA protocol in [ID-DNSNA] along with IPv6 ND DNS 222 options in [RFC8106]. 224 Vehicle1's Router1 and RSU1's Router3 can know what vehicular 225 applications exist in their internal network by referring to their 226 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 227 what network prefixes exist in their internal network through an 228 intra-domain routing protocoli, such as OSFP. Each vehicle and each 229 RSU announce their network prefixes and services through ND options 230 defined in Section 5. 232 (*)<..........>(*) 233 | | 2001:DB8:1:1::/64 234 .------------------------------. .---------------------------------. 235 | | | | | | 236 | .-------. .------. .-------. | | .-------. .------. .-------. | 237 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 238 | ._______. .______. ._______. | | ._______. .______. ._______. | 239 | ^ ^ ^ | | ^ ^ ^ | 240 | | | | | | | | | | 241 | v v v | | v v v | 242 | ---------------------------- | | ------------------------------- | 243 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 244 | | | | | | 245 | v | | v | 246 | .-------. .-------. | | .-------. .-------. .-------. | 247 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 248 | ._______. ._______. | | ._______. ._______. ._______. | 249 | ^ ^ | | ^ ^ ^ | 250 | | | | | | | | | 251 | v v | | v v v | 252 | ---------------------------- | | ------------------------------- | 253 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 254 .______________________________. ._________________________________. 255 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 257 <----> Wired Link <....> Wireless Link (*) Antenna 259 Figure 2: Internetworking between Vehicle Network and RSU Network 261 5. ND Extension for Prefix and Service Discovery 263 This section defines two new ND options for prefix and service 264 discovery: (i) the Vehicular Prefix Information (VPI) option and (ii) 265 the Vehicular Service Information (VSI) option. It also describes 266 the ND protocol for such prefix and service discovery. 268 5.1. Vehicular Prefix Information Option 270 The VPI option contains one IPv6 prefix in the internal network. 271 Figure 3 shows the format of the VPI option. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Length | Prefix Length | Distance | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Reserved | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | | 281 : Prefix : 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 3: Vehicular Prefix Information (VPI) Option Format 287 Fields: 288 Type 8-bit identifier of the VPI option type as assigned 289 by the IANA: TBD 291 Length 8-bit unsigned integer. The length of the option 292 (including the Type and Length fields) is in units of 293 8 octets. The value is 3. 295 Prefix Length 8-bit unsigned integer. The number of leading bits 296 in the Prefix that are valid. The value ranges 297 from 0 to 128. 299 Distance 8-bit unsigned integer. The distance between the 300 subnet announcing this prefix and the subnet 301 corresponding to this prefix in terms of the number 302 of hops. 304 Reserved This field is unused. It MUST be initialized to 305 zero by the sender and MUST be ignored by the 306 receiver. 308 Prefix An IP address or a prefix of an IP address. The 309 Prefix Length field contains the number of valid 310 leading bits in the prefix. The bits in the prefix 311 after the prefix length are reserved and MUST be 312 initialized to zero by the sender and ignored by 313 the receiver. 315 5.2. Vehicular Service Information Option 317 The VSI option contains one vehicular service in the internal 318 network. Figure 4 shows the format of the VSI option. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | Reserved1 | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Protocol | Reserved2 | Port Number | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 : Node Address : 329 | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 4: Vehicular Service Information (VSI) Option Format 334 Fields: 335 Type 8-bit identifier of the VSI option type as assigned 336 by the IANA: TBD 338 Length 8-bit unsigned integer. The length of the option 339 (including the Type and Length fields) is in units of 340 8 octets. The value is 3. 342 Reserved1 This field is unused. It MUST be initialized to 343 zero by the sender and MUST be ignored by the 344 receiver. 346 Protocol 8-bit unsigned integer to indicate the upper-layer 347 protocol, such as transport-layer protocol (e.g., 348 TCP, UDP, and SCTP). 350 Reserved2 This field is unused. It MUST be initialized to 351 zero by the sender and MUST be ignored by the 352 receiver. 354 Port Number 16-bit unsigned integer to indicate the port number 355 for the protocol. 357 Service Address 358 128-bit IPv6 address of a node proving this vehicular 359 service. 361 5.3. Vehicular Neighbor Discovery 363 With VPI and VSI options, a node (e.g., vehicle or RSU) can announce 364 the network prefixes and services in its internal network via ND 365 messages, such as Neighbor Solicitation (NS) and Neighbor 366 Advertisement (NA) [RFC4861]. 368 A node periodically announces an NS message containing the VPI and 369 VSI options with its prefixes and services in all-nodes multicast 370 address to reach all neighboring nodes. When another neighboring 371 node receives this NS message, it responds to this NS message by 372 sending an NA message containing the VPI and VSI options with its 373 prefixes and services via unicast toward the NS-originating node. 375 Through this procedure, vehicles and RSUs can rapidly discover the 376 network prefixes and services of the other party without any 377 additional service discovery protocol. 379 6. Security Considerations 381 This document shares all the security issues of the neighbor 382 discovery protocol. This document can get benefits from secure 383 neighbor discovery (SEND) [RFC3971] in order to protect ND from 384 possible security attacks. 386 7. Acknowledgments 388 This work was supported by Basic Science Research Program through the 389 National Research Foundation of Korea (NRF) funded by the Ministry of 390 Education (2017R1D1A1B03035885). 392 This work was supported in part by Global Research Laboratory Program 393 through the NRF funded by the Ministry of Science and ICT (MSIT) 394 (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT 395 (18-EE-01). 397 8. References 399 8.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 405 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 406 September 2007. 408 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 409 Address Autoconfiguration", RFC 4862, September 2007. 411 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 412 "IPv6 Router Advertisement Options for DNS Configuration", 413 RFC 8106, March 2017. 415 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 416 (IPv6) Specification", RFC 8200, July 2017. 418 8.2. Informative References 420 [DSRC-WAVE] 421 Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its 422 Architecture, Design, and Characteristics", 423 IEEE Communications Surveys & Tutorials, 12(4), 2012. 425 [ID-DNSNA] 426 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 427 Autoconfiguration for Internet of Things Devices", draft- 428 jeong-ipwave-iot-dns-autoconf-03 (work in progress), July 429 2018. 431 [IEEE-802.11-OCB] 432 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 433 Access Control (MAC) and Physical Layer (PHY) 434 Specifications", IEEE Std 802.11-2012, February 2012. 436 [IEEE-802.11a] 437 IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access 438 Control (MAC) and Physical Layer (PHY) specifications: 439 High-speed Physical Layer in the 5 GHZ Band", September 440 1999. 442 [IEEE-802.11p] 443 IEEE Std 802.11p, "Part 11: Wireless LAN Medium Access 444 Control (MAC) and Physical Layer (PHY) Specifications 445 Amendment 6: Wireless Access in Vehicular Environments", 446 June 2010. 448 [RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", 449 RFC 3971, March 2005. 451 [WAVE-1609.0] 452 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 453 in Vehicular Environments (WAVE) - Architecture", IEEE Std 454 1609.0-2013, March 2014. 456 [WAVE-1609.2] 457 IEEE 1609 Working Group, "IEEE Standard for Wireless 458 Access in Vehicular Environments - Security Services for 459 Applications and Management Messages", IEEE Std 460 1609.2-2016, March 2016. 462 [WAVE-1609.3] 463 IEEE 1609 Working Group, "IEEE Standard for Wireless 464 Access in Vehicular Environments (WAVE) - Networking 465 Services", IEEE Std 1609.3-2016, April 2016. 467 [WAVE-1609.4] 468 IEEE 1609 Working Group, "IEEE Standard for Wireless 469 Access in Vehicular Environments (WAVE) - Multi-Channel 470 Operation", IEEE Std 1609.4-2016, March 2016. 472 Authors' Addresses 474 Jaehoon Paul Jeong 475 Department of Software 476 Sungkyunkwan University 477 2066 Seobu-Ro, Jangan-Gu 478 Suwon, Gyeonggi-Do 16419 479 Republic of Korea 481 Phone: +82 31 299 4957 482 Fax: +82 31 290 7996 483 EMail: pauljeong@skku.edu 484 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 486 Yiwen Chris Shen 487 Department of Computer Science and Engineering 488 Sungkyunkwan University 489 2066 Seobu-Ro, Jangan-Gu 490 Suwon, Gyeonggi-Do 16419 491 Republic of Korea 493 Phone: +82 31 299 4106 494 Fax: +82 31 290 7996 495 EMail: chrisshen@skku.edu 497 Younghwa Jo 498 Department of Software Platform 499 Sungkyunkwan University 500 2066 Seobu-Ro, Jangan-Gu 501 Suwon, Gyeonggi-Do 16419 502 Republic of Korea 504 Phone: +82 31 299 4106 505 Fax: +82 31 290 7996 506 EMail: movie_jo@naver.com 507 Junsik Jeong 508 Software R&D Center 509 Samsung Electronics 510 Seoul R&D Campus D-Tower, 56, Seongchon-Gil, Seocho-Gu 511 Seoul 06765 512 Republic of Korea 514 EMail: jun.jeong@samsung.com 516 Jong-Hyouk Lee 517 Sangmyung University 518 Sangmyung University 519 31, Sangmyeongdae-gil, Dongnam-gu 520 Cheonan, NY 31066 521 Republic of Korea 523 EMail: jonghyouk@smu.ac.kr