idnits 2.17.1 draft-jeong-ipwave-vehicular-neighbor-discovery-01.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 (October 30, 2017) is 2370 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-01 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong 3 Internet-Draft Y. Shen 4 Intended status: Standards Track Y. Jo 5 Expires: May 3, 2018 Sungkyunkwan University 6 J. Jeong 7 Samsung Electronics 8 J. Lee 9 Sangmyung University 10 October 30, 2017 12 IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular 13 Networks 14 draft-jeong-ipwave-vehicular-neighbor-discovery-01 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 to IETF 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), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 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 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on May 3, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 5. ND Extension for Prefix and Service Discovery . . . . . . . . 6 73 5.1. Vehicular Prefix Information Option . . . . . . . . . . . 6 74 5.2. Vehicular Service Information Option . . . . . . . . . . . 7 75 5.3. Vehicular Neighbor Discovery . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 81 Appendix A. Changes from 82 draft-jeong-ipwave-vehicular-neighbor-discovery-00 . 10 84 1. Introduction 86 Vehicular Ad Hoc Networks (VANET) have been researched for the 87 networking on intelligent services in road networks, such as driving 88 safety, efficient driving, and entertainment. To enable this VANET 89 in road networks, Dedicated Short-Range Communications (DSRC) 90 [DSRC-WAVE] has been standardized as IEEE 802.11p [IEEE-802.11p], 91 which is an extension of IEEE 802.11a [IEEE-802.11a], considering the 92 characteristics of vehicular networks, such as high-speed mobility 93 and network fragmentation. For Wireless Access in Vehicular 94 Environments (WAVE), the IEEE has standardized IEEE 1609 family 95 standards, such as IEEE 1609.3 and 1609.4 [DSRC-WAVE]. The IEEE 1609 96 standards specify IPv6 as the network-layer protocol. 98 Many automobile vendors are replacing Controller Area Networks (CANs) 99 with Ethernet for high-speed interconnectivity among Electronic 100 Control Units (ECUs) in a vehicle. The sensing information of the 101 ECUs can be delivered to the service centers of those automobile 102 ventors for remote diagnosis for driving safety using DSRC between 103 vehicles and Road-Side Units (RSUs) having the Internet connectivity 104 toward the service centers in a vehicular cloud. 106 With this trend, it is time to enable vehicular networking with IPv6 107 to let various Internet-based applications (e.g., remote vehicle 108 diagnosis) run on top of transport-layer protocols, such as TCP, UDP, 109 and SCTP. IPv6 [RFC2460] is suitable for a network layer in 110 vehicular networks in that the protocol has abundant address space, 111 autoconfiguration features, and protocol extension ability through 112 extension headers. 114 To support the interaction between vehicles or between a vehicle and 115 an RSU, this document specifies an extension of IPv6 ND [RFC4861] for 116 rapid network prefix and service discovery in vehicular networks with 117 new ND options. That is, the extended IPv6 ND in this document, 118 which is called vehicular ND, can support not only vehicle-to- 119 infrastructure (V2I) communications but also vehicle-to-vehicle (V2V) 120 communications. 122 2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 3. Terminology 130 This document uses the terminology described in [RFC4861] and 131 [RFC4862]. In addition, four new terms are defined below: 133 o Road-Side Unit (RSU): A node that has a Dedicated Short-Range 134 Communications (DSRC) device for wireless communications with the 135 vehicles and is connected to the Internet. Every RSU is usually 136 deployed at an intersection so that it can provide vehicles with 137 the Internet connectivity. 139 o Vehicle: A node that has the DSRC device for wireless 140 communications with vehicles and RSUs. Every vehicle may also 141 have a GPS-navigation system for efficient driving. 143 o Traffic Control Center (TCC): A node that maintains road 144 infrastructure information (e.g., RSUs and traffic signals), 145 vehicular traffic statistics (e.g., average vehicle speed and 146 vehicle inter-arrival time per road segment), and vehicle 147 information (e.g., a vehicle's identifier, position, direction, 148 speed, and trajectory). TCC is included in a vehicular cloud for 149 vehicular networks. 151 4. Overview 153 This document specifies an IPv6 ND extension for vehicle-to-vehicle 154 (V2V) or vehicle-to-infrastructure (V2I) networking. 156 Figure 1 shows the V2V networking of two vehicles whose internal 157 networks are Moving Network1 and Moving Network2, respectively. 158 Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and 159 Host2), and the two routers (Router1 and Router2). Vehicle2 has the 160 DNS Server (RDNSS2), the two hosts (Host3 and Host4), and the two 161 routers (Router3 and Router4). 163 It is assumed that Host1 and Host3 are running a Cooperative Adaptive 164 Cruise Control (C-ACC) program for physical collision avoidance. 165 Also, it is assumed that Host2 and Host4 are running a Cooperative 166 On-board Camera Sharing (C-OCS) program for sharing road hazards or 167 obstacles to avoid road accidents. Vehicle1's Router1 and Vehicle2's 168 Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for 169 V2V networking for various vehicular services. The vehicular 170 applications, such as C-ACC and C-BCS, can be registered into the DNS 171 Server (i.e., RDNSS) through DNSNA protocol in [ID-DNSNA] along with 172 IPv6 ND DNS options in [RFC6106]. 174 Vehicle1's Router1 and Vehicle2's Router3 can know what vehicular 175 applications exist in their internal network by referring to their 176 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 177 what network prefixes exist in their internal network through an 178 intra-domain routing protocoli, such as OSFP. Each vehicle announces 179 its network prefixes and services through ND options defined in 180 Section 5. 182 (*)<..........>(*) 183 | | 2001:DB8:1:1::/64 184 .------------------------------. .------------------------------. 185 | | | | | | 186 | .-------. .------. .-------. | | .-------. .------. .-------. | 187 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 188 | ._______. .______. ._______. | | ._______. .______. ._______. | 189 | ^ ^ ^ | | ^ ^ ^ | 190 | | | | | | | | | | 191 | v v v | | v v v | 192 | ---------------------------- | | ---------------------------- | 193 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 194 | | | | | | 195 | v | | v | 196 | .-------. .-------. | | .-------. .-------. | 197 | | Host2 | |Router2| | | |Router4| | Host4 | | 198 | ._______. ._______. | | ._______. ._______. | 199 | ^ ^ | | ^ ^ | 200 | | | | | | | | 201 | v v | | v v | 202 | ---------------------------- | | ---------------------------- | 203 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 204 .______________________________. .______________________________. 205 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 207 <----> Wired Link <....> Wireless Link (*) Antenna 209 Figure 1: Internetworking between Vehicle Networks 211 Figure 2 shows the V2I networking of a vehicle and an RSU whose 212 internal networks are Moving Network1 and Fixed Network1, 213 respectively. Vehicle1 has the DNS Server (RDNSS1), the two hosts 214 (Host1 and Host2), and the two routers (Router1 and Router2). RSU1 215 has the DNS Server (RDNSS2), one host (Host3), the two routers 216 (Router3 and Router4). 218 It is assumed that RSU1 has a collection of servers (Server1 to 219 ServerN) for various services in the road networks, such as road 220 emergency notification and navigation services. Vehicle1's Router1 221 and RSU1's Router3 use 2001:DB8:1:1::/64 for an external link (e.g., 222 DSRC) for I2V networking for various vehicular services. The 223 vehicular applications, such as road emergency notification and 224 navigation services, can be registered into the DNS Server (i.e., 225 RDNSS) through DNSNA protocol in [ID-DNSNA] along with IPv6 ND DNS 226 options in [RFC6106]. 228 Vehicle1's Router1 and RSU1's Router3 can know what vehicular 229 applications exist in their internal network by referring to their 230 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 231 what network prefixes exist in their internal network through an 232 intra-domain routing protocoli, such as OSFP. Each vehicle and each 233 RSU announce their network prefixes and services through ND options 234 defined in Section 5. 236 (*)<..........>(*) 237 | | 2001:DB8:1:1::/64 238 .------------------------------. .---------------------------------. 239 | | | | | | 240 | .-------. .------. .-------. | | .-------. .------. .-------. | 241 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 242 | ._______. .______. ._______. | | ._______. .______. ._______. | 243 | ^ ^ ^ | | ^ ^ ^ | 244 | | | | | | | | | | 245 | v v v | | v v v | 246 | ---------------------------- | | ------------------------------- | 247 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 248 | | | | | | 249 | v | | v | 250 | .-------. .-------. | | .-------. .-------. .-------. | 251 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 252 | ._______. ._______. | | ._______. ._______. ._______. | 253 | ^ ^ | | ^ ^ ^ | 254 | | | | | | | | | 255 | v v | | v v v | 256 | ---------------------------- | | ------------------------------- | 257 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 258 .______________________________. ._________________________________. 259 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 261 <----> Wired Link <....> Wireless Link (*) Antenna 263 Figure 2: Internetworking between Vehicle Network and RSU Network 265 5. ND Extension for Prefix and Service Discovery 267 This section defines two new ND options for prefix and service 268 discovery: (i) the Vehicular Prefix Information (VPI) option and (ii) 269 the Vehicular Service Information (VSI) option. It also describes 270 the ND protocol for such prefix and service discovery. 272 5.1. Vehicular Prefix Information Option 274 The VPI option contains one IPv6 prefix in the internal network. 275 Figure 3 shows the format of the VPI option. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type | Length | Prefix Length | Distance | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Reserved | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 : Prefix : 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 3: Vehicular Prefix Information (VPI) Option Format 291 Fields: 292 Type 8-bit identifier of the VPI option type as assigned 293 by the IANA: TBD 295 Length 8-bit unsigned integer. The length of the option 296 (including the Type and Length fields) is in units of 297 8 octets. The value is 3. 299 Prefix Length 8-bit unsigned integer. The number of leading bits 300 in the Prefix that are valid. The value ranges 301 from 0 to 128. 303 Distance 8-bit unsigned integer. The distance between the 304 subnet announcing this prefix and the subnet 305 corresponding to this prefix in terms of the number 306 of hops. 308 Reserved This field is unused. It MUST be initialized to 309 zero by the sender and MUST be ignored by the 310 receiver. 312 Prefix An IP address or a prefix of an IP address. The 313 Prefix Length field contains the number of valid 314 leading bits in the prefix. The bits in the prefix 315 after the prefix length are reserved and MUST be 316 initialized to zero by the sender and ignored by 317 the receiver. 319 5.2. Vehicular Service Information Option 321 The VSI option contains one vehicular service in the internal 322 network. Figure 4 shows the format of the VSI option. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Length | Reserved1 | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Protocol | Reserved2 | Port Number | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | 332 : Node Address : 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 4: Vehicular Service Information (VSI) Option Format 338 Fields: 339 Type 8-bit identifier of the VSI option type as assigned 340 by the IANA: TBD 342 Length 8-bit unsigned integer. The length of the option 343 (including the Type and Length fields) is in units of 344 8 octets. The value is 3. 346 Reserved1 This field is unused. It MUST be initialized to 347 zero by the sender and MUST be ignored by the 348 receiver. 350 Protocol 8-bit unsigned integer to indicate the upper-layer 351 protocol, such as transport-layer protocol (e.g., 352 TCP, UDP, and SCTP). 354 Reserved2 This field is unused. It MUST be initialized to 355 zero by the sender and MUST be ignored by the 356 receiver. 358 Port Number 16-bit unsigned integer to indicate the port number 359 for the protocol. 361 Service Address 362 128-bit IPv6 address of a node proving this vehicular 363 service. 365 5.3. Vehicular Neighbor Discovery 367 With VPI and VSI options, a node (e.g., vehicle or RSU) can announce 368 the network prefixes and services in its internal network via ND 369 messages, such as Neighbor Solicitation (NS) and Neighbor 370 Advertisement (NA) [RFC4861]. 372 A node periodically announces an NS message containing the VPI and 373 VSI options with its prefixes and services in all-nodes multicast 374 address to reach all neighboring nodes. When another neighboring 375 node receives this NS message, it responds to this NS message by 376 sending an NA message containing the VPI and VSI options with its 377 prefixes and services via unicast toward the NS-originating node. 379 Through this procedure, vehicles and RSUs can rapidly discover the 380 network prefixes and services of the other party without any 381 additional service discovery protocol. 383 6. Security Considerations 385 This document shares all the security issues of the neighbor 386 discovery protocol. This document can get benefits from secure 387 neighbor discovery (SEND) [RFC3971] in order to protect ND from 388 possible security attacks. 390 7. Acknowledgements 392 This work was supported by Basic Science Research Program through the 393 National Research Foundation of Korea (NRF) funded by the Ministry of 394 Education (2017R1D1A1B03035885). This work was supported in part by 395 the Global Research Laboratory Program (2013K1A1A2A02078326) through 396 NRF and the DGIST Research and Development Program (CPS Global 397 Center) funded by the Ministry of Science and ICT. 399 8. References 401 8.1. Normative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, 407 Version 6 (IPv6) Specification", RFC 2460, 408 December 1998. 410 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. 411 Soliman, "Neighbor Discovery for IP Version 6 412 (IPv6)", RFC 4861, September 2007. 414 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 415 Stateless Address Autoconfiguration", RFC 4862, 416 September 2007. 418 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 419 "IPv6 Router Advertisement Options for DNS 420 Configuration", RFC 6106, November 2010. 422 8.2. Informative References 424 [DSRC-WAVE] Morgan, Y., "Notes on DSRC & WAVE Standards Suite: 425 Its Architecture, Design, and Characteristics", 426 IEEE Communications Surveys & Tutorials, 12(4), 2012. 428 [IEEE-802.11p] IEEE Std 802.11p, "Part 11: Wireless LAN Medium 429 Access Control (MAC) and Physical Layer (PHY) 430 Specifications Amendment 6: Wireless Access in 431 Vehicular Environments", June 2010. 433 [IEEE-802.11a] IEEE Std 802.11a, "Part 11: Wireless LAN Medium 434 Access Control (MAC) and Physical Layer (PHY) 435 specifications: High-speed Physical Layer in the 5 436 GHZ Band", September 1999. 438 [ID-DNSNA] Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 439 Autoconfiguration for Internet of Things Devices", 440 draft-jeong-ipwave-iot-dns-autoconf-01 (work in 441 progress), October 2017. 443 [RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", 444 RFC 3971, March 2005. 446 Appendix A. Changes from 447 draft-jeong-ipwave-vehicular-neighbor-discovery-00 449 The following changes are made from 450 draft-jeong-ipwave-vehicular-neighbor-discovery-00: 452 o In Section 1, the trend of Ethernet installation in a vehicle for 453 remote diagnosis is introduced. 455 Authors' Addresses 457 Jaehoon Paul Jeong 458 Department of Software 459 Sungkyunkwan University 460 2066 Seobu-Ro, Jangan-Gu 461 Suwon, Gyeonggi-Do 16419 462 Republic of Korea 464 Phone: +82 31 299 4957 465 Fax: +82 31 290 7996 466 EMail: pauljeong@skku.edu 467 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 469 Yiwen Chris Shen 470 Department of Computer Science and Engineering 471 Sungkyunkwan University 472 2066 Seobu-Ro, Jangan-Gu 473 Suwon, Gyeonggi-Do 16419 474 Republic of Korea 476 Phone: +82 31 299 4106 477 Fax: +82 31 290 7996 478 EMail: chrisshen@skku.edu 480 Younghwa Jo 481 Department of Software Platform 482 Sungkyunkwan University 483 2066 Seobu-Ro, Jangan-Gu 484 Suwon, Gyeonggi-Do 16419 485 Republic of Korea 487 Phone: +82 31 299 4106 488 Fax: +82 31 290 7996 489 EMail: movie_jo@naver.com 491 Junsik Jeong 492 Software R&D Center 493 Samsung Electronics 494 Seoul R&D Campus D-Tower, 56, Seongchon-Gil, Seocho-Gu 495 Seoul 06765 496 Republic of Korea 498 EMail: jun.jeong@samsung.com 499 Jong-Hyouk Lee 500 Sangmyung University 501 Sangmyung University 502 31, Sangmyeongdae-gil, Dongnam-gu 503 Cheonan, NY 31066 504 Republic of Korea 506 EMail: jonghyouk@smu.ac.kr