idnits 2.17.1 draft-jeong-its-vehicular-neighbor-discovery-00.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 19, 2016) is 2835 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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: January 20, 2017 Sungkyunkwan University 6 J. Jeong 7 Samsung Electronics 8 J. Lee 9 Sangmyung University 10 July 19, 2016 12 IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular 13 Networks 14 draft-jeong-its-vehicular-neighbor-discovery-00 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. This document 22 defines new ND options to allows a vehicle to announce the network 23 prefixes and services inside its internal network to another vehicle 24 or RSU. 26 Status of This Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on January 20, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 5. ND Extension for Prefix and Service Discovery . . . . . . . . 6 71 5.1. Vehicular Prefix Information Option . . . . . . . . . . . 6 72 5.2. Vehicular Service Information Option . . . . . . . . . . . 7 73 5.3. Vehicular Neighbor Discovery . . . . . . . . . . . . . . . 8 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 Vehicular Ad Hoc Networks (VANET) have been researched for the 83 networking on intelligent services in road networks, such as driving 84 safety, efficient driving, and entertainment. To enable this VANET 85 in road networks, Dedicated Short-Range Communications (DSRC) 86 [DSRC-WAVE] has been standardized as IEEE 802.11p [IEEE-802.11p], 87 which is an extension of IEEE 802.11a [IEEE-802.11a], considering the 88 characteristics of vehicular networks, such as high-speed mobility 89 and network fragmentation. For Wireless Access in Vehicular 90 Environments (WAVE), the IEEE has standardized IEEE 1609 family 91 standards, such as IEEE 1609.3 and 1609.4 [DSRC-WAVE]. The IEEE 1609 92 standards specify IPv6 as the network-layer protocol. 94 With this trend, it is time to enable vehicular networking with IPv6 95 to let various Internet-based applications run on top of transport- 96 layer protocols, such as TCP, UDP, and SCTP. IPv6 [RFC2460] is 97 suitable for a network layer in vehicular networks in that the 98 protocol has abundant address space, autoconfiguration features, and 99 protocol extension ability through extension headers. 101 To support the interaction between vehicles or between a vehicle and 102 an RSU, this document specifies an extension of IPv6 ND [RFC4861] for 103 rapid network prefix and service discovery in vehicular networks with 104 new ND options. 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 3. Terminology 114 This document uses the terminology described in [RFC4861] and 115 [RFC4862]. In addition, four new terms are defined below: 117 o Road-Side Unit (RSU): A node that has a Dedicated Short-Range 118 Communications (DSRC) device for wireless communications with the 119 vehicles and is connected to the Internet. Every RSU is usually 120 deployed at an intersection so that it can provide vehicles with 121 the Internet connectivity. 123 o Vehicle: A node that has the DSRC device for wireless 124 communications with vehicles and RSUs. Every vehicle may also 125 have a GPS-navigation system for efficient driving. 127 o Traffic Control Center (TCC): A node that maintains road 128 infrastructure information (e.g., RSUs and traffic signals), 129 vehicular traffic statistics (e.g., average vehicle speed and 130 vehicle inter-arrival time per road segment), and vehicle 131 information (e.g., a vehicle's identifier, position, direction, 132 speed, and trajectory). TCC is included in a vehicular cloud for 133 vehicular networks. 135 4. Overview 137 This document specifies an IPv6 ND extension for vehicle-to-vehicle 138 (V2V) or vehicle-to-infrastructure (V2I) networking. 140 Figure 1 shows the V2V networking of two vehicles whose internal 141 networks are Moving Network1 and Moving Network2, respectively. 142 Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and 143 Host2), and the two routers (Router1 and Router2). Vehicle2 has the 144 DNS Server (RDNSS2), the two hosts (Host3 and Host4), and the two 145 routers (Router3 and Router4). 147 It is assumed that Host1 and Host3 are running a Cooperative Adaptive 148 Cruise Control (C-ACC) program for physical collision avoidance. 149 Also, it is assumed that Host2 and Host4 are running a Cooperative 150 Blackbox Camera Sharing (C-BCS) program for sharing road hazards or 151 obstacles to avoid road accidents. Vehicle1's Router1 and Vehicle2's 152 Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for 153 V2V networking for various vehicular services. The vehicular 154 applications, such as C-ACC and C-BCS, can be registered into the DNS 155 Server (i.e., RDNSS) through DNSNA protocol in [ID-DNSNA] along with 156 IPv6 ND DNS options in [RFC6106]. 158 Vehicle1's Router1 and Vehicle2's Router3 can know what vehicular 159 applications exist in their internal network by referring to their 160 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 161 what network prefixes exist in their internal network through an 162 intra-domain routing protocoli, such as OSFP. Each vehicle announces 163 its network prefixes and services through ND options defined in 164 Section 5. 166 (*)<..........>(*) 167 | | 2001:DB8:1:1::/64 168 .------------------------------. .------------------------------. 169 | | | | | | 170 | .-------. .------. .-------. | | .-------. .------. .-------. | 171 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 172 | ._______. .______. ._______. | | ._______. .______. ._______. | 173 | ^ ^ ^ | | ^ ^ ^ | 174 | | | | | | | | | | 175 | v v v | | v v v | 176 | ---------------------------- | | ---------------------------- | 177 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 178 | | | | | | 179 | v | | v | 180 | .-------. .-------. | | .-------. .-------. | 181 | | Host2 | |Router2| | | |Router4| | Host4 | | 182 | ._______. ._______. | | ._______. ._______. | 183 | ^ ^ | | ^ ^ | 184 | | | | | | | | 185 | v v | | v v | 186 | ---------------------------- | | ---------------------------- | 187 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 188 .______________________________. .______________________________. 189 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 191 <----> Wired Link <....> Wireless Link (*) Antenna 193 Figure 1: Internetworking between Vehicle Networks 195 Figure 2 shows the V2I networking of a vehicle and an RSU whose 196 internal networks are Moving Network1 and Fixed Network1, 197 respectively. Vehicle1 has the DNS Server (RDNSS1), the two hosts 198 (Host1 and Host2), and the two routers (Router1 and Router2). RSU1 199 has the DNS Server (RDNSS2), one host (Host3), the two routers 200 (Router3 and Router4). 202 It is assumed that RSU1 has a collection of servers (Server1 to 203 ServerN) for various services in the road networks, such as road 204 emergency notification and navigation services. Vehicle1's Router1 205 and RSU1's Router3 use 2001:DB8:1:1::/64 for an external link (e.g., 206 DSRC) for I2V networking for various vehicular services. The 207 vehicular applications, such as road emergency notification and 208 navigation services, can be registered into the DNS Server (i.e., 209 RDNSS) through DNSNA protocol in [ID-DNSNA] along with IPv6 ND DNS 210 options in [RFC6106]. 212 Vehicle1's Router1 and RSU1's Router3 can know what vehicular 213 applications exist in their internal network by referring to their 214 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 215 what network prefixes exist in their internal network through an 216 intra-domain routing protocoli, such as OSFP. Each vehicle and each 217 RSU announce their network prefixes and services through ND options 218 defined in Section 5. 220 (*)<..........>(*) 221 | | 2001:DB8:1:1::/64 222 .------------------------------. .---------------------------------. 223 | | | | | | 224 | .-------. .------. .-------. | | .-------. .------. .-------. | 225 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 226 | ._______. .______. ._______. | | ._______. .______. ._______. | 227 | ^ ^ ^ | | ^ ^ ^ | 228 | | | | | | | | | | 229 | v v v | | v v v | 230 | ---------------------------- | | ------------------------------- | 231 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 232 | | | | | | 233 | v | | v | 234 | .-------. .-------. | | .-------. .-------. .-------. | 235 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 236 | ._______. ._______. | | ._______. ._______. ._______. | 237 | ^ ^ | | ^ ^ ^ | 238 | | | | | | | | | 239 | v v | | v v v | 240 | ---------------------------- | | ------------------------------- | 241 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 242 .______________________________. ._________________________________. 243 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 245 <----> Wired Link <....> Wireless Link (*) Antenna 247 Figure 2: Internetworking between Vehicle Network and RSU Network 249 5. ND Extension for Prefix and Service Discovery 251 This section defines two new ND options for prefix and service 252 discovery: (i) the Vehicular Prefix Information (VPI) option and (ii) 253 the Vehicular Service Information (VSI) option. It also describes 254 the ND protocol for such prefix and service discovery. 256 5.1. Vehicular Prefix Information Option 258 The VPI option contains one IPv6 prefix in the internal network. 259 Figure 3 shows the format of the VPI option. 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length | Prefix Length | Distance | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Reserved | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 : Prefix : 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 3: Vehicular Prefix Information (VPI) Option Format 275 Fields: 276 Type 8-bit identifier of the VPI option type as assigned 277 by the IANA: TBD 279 Length 8-bit unsigned integer. The length of the option 280 (including the Type and Length fields) is in units of 281 8 octets. The value is 3. 283 Prefix Length 8-bit unsigned integer. The number of leading bits 284 in the Prefix that are valid. The value ranges 285 from 0 to 128. 287 Distance 8-bit unsigned integer. The distance between the 288 subnet announcing this prefix and the subnet 289 corresponding to this prefix in terms of the number 290 of hops. 292 Reserved This field is unused. It MUST be initialized to 293 zero by the sender and MUST be ignored by the 294 receiver. 296 Prefix An IP address or a prefix of an IP address. The 297 Prefix Length field contains the number of valid 298 leading bits in the prefix. The bits in the prefix 299 after the prefix length are reserved and MUST be 300 initialized to zero by the sender and ignored by 301 the receiver. 303 5.2. Vehicular Service Information Option 305 The VSI option contains one vehicular service in the internal 306 network. Figure 4 shows the format of the VSI option. 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type | Length | Reserved1 | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Protocol | Reserved2 | Port Number | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | | 316 : Service Address : 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 4: Vehicular Service Information (VSI) Option Format 322 Fields: 323 Type 8-bit identifier of the VSI option type as assigned 324 by the IANA: TBD 326 Length 8-bit unsigned integer. The length of the option 327 (including the Type and Length fields) is in units of 328 8 octets. The value is 3. 330 Reserved1 This field is unused. It MUST be initialized to 331 zero by the sender and MUST be ignored by the 332 receiver. 334 Protocol 8-bit unsigned integer to indicate the upper-layer 335 protocol, such as transport-layer protocol (e.g., 336 TCP, UDP, and SCTP). 338 Reserved2 This field is unused. It MUST be initialized to 339 zero by the sender and MUST be ignored by the 340 receiver. 342 Port Number 16-bit unsigned integer to indicate the port number 343 for the protocol. 345 Service Address 346 128-bit IPv6 address of a vehicular service. 348 5.3. Vehicular Neighbor Discovery 350 With VPI and VSI options, a node (e.g., vehicle or RSU) can announce 351 the network prefixes and services in its internal network via ND 352 messages, such as Neighbor Solicitation (NS) and Neighbor 353 Advertisement (NA) [RFC4861]. 355 A node periodically announces an NS message containing the VPI and 356 VSI options with its prefixes and services in all-nodes multicast 357 address to reach all neighboring nodes. When another neighboring 358 node receives this NS message, it responds to this NS message by 359 sending an NA message containing the VPI and VSI options with its 360 prefixes and services via unicast toward the NS-originating node. 362 Through this procedure, vehicles and RSUs can rapidly discover the 363 network prefixes and services of the other party without any 364 additional service discovery protocol. 366 6. Security Considerations 368 This document shares all the security issues of the neighbor 369 discovery protocol. This document can get benefits from secure 370 neighbor discovery (SEND) [RFC3971] in order to protect ND from 371 possible security attacks. 373 7. Acknowledgements 375 This work was supported by Institute for Information & communications 376 Technology Promotion (IITP) grant funded by the Korea government 377 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 378 Technology Development for the Customized Security Service 379 Provisioning). This work was supported in part by ICT R&D program of 380 MSIP/IITP (14-824-09-013, Resilient Cyber-Physical Systems Research) 381 and the DGIST Research and Development Program (CPS Global Center) 382 funded by the Ministry of Science, ICT & Future Planning. 384 8. References 386 8.1. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, 392 Version 6 (IPv6) Specification", RFC 2460, 393 December 1998. 395 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. 396 Soliman, "Neighbor Discovery for IP Version 6 397 (IPv6)", RFC 4861, September 2007. 399 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 400 Stateless Address Autoconfiguration", RFC 4862, 401 September 2007. 403 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 404 "IPv6 Router Advertisement Options for DNS 405 Configuration", RFC 6106, November 2010. 407 8.2. Informative References 409 [DSRC-WAVE] Morgan, Y., "Notes on DSRC & WAVE Standards Suite: 410 Its Architecture, Design, and Characteristics", 411 IEEE Communications Surveys & Tutorials, 12(4), 2012. 413 [IEEE-802.11p] IEEE Std 802.11p, "Part 11: Wireless LAN Medium 414 Access Control (MAC) and Physical Layer (PHY) 415 Specifications Amendment 6: Wireless Access in 416 Vehicular Environments", June 2010. 418 [IEEE-802.11a] IEEE Std 802.11a, "Part 11: Wireless LAN Medium 419 Access Control (MAC) and Physical Layer (PHY) 420 specifications: High-speed Physical Layer in the 5 421 GHZ Band", September 1999. 423 [ID-DNSNA] Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 424 Autoconfiguration for Internet of Things Devices", 425 draft-jeong-its-iot-dns-autoconf-01 (work in 426 progress), July 2016. 428 [RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", 429 RFC 3971, March 2005. 431 Authors' Addresses 433 Jaehoon Paul Jeong 434 Department of Software 435 Sungkyunkwan University 436 2066 Seobu-Ro, Jangan-Gu 437 Suwon, Gyeonggi-Do 16419 438 Republic of Korea 440 Phone: +82 31 299 4957 441 Fax: +82 31 290 7996 442 EMail: pauljeong@skku.edu 443 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 444 Yiwen Chris Shen 445 Department of Computer Science and Engineering 446 Sungkyunkwan University 447 2066 Seobu-Ro, Jangan-Gu 448 Suwon, Gyeonggi-Do 16419 449 Republic of Korea 451 Phone: +82 31 299 4106 452 Fax: +82 31 290 7996 453 EMail: chrisshen@skku.edu 455 Younghwa Jo 456 Department of Software Platform 457 Sungkyunkwan University 458 2066 Seobu-Ro, Jangan-Gu 459 Suwon, Gyeonggi-Do 16419 460 Republic of Korea 462 Phone: +82 31 299 4106 463 Fax: +82 31 290 7996 464 EMail: movie_jo@naver.com 466 Junsik Jeong 467 Software R&D Center 468 Samsung Electronics 469 Seoul R&D Campus D-Tower, 56, Seongchon-Gil, Seocho-Gu 470 Seoul 06765 471 Republic of Korea 473 EMail: jun.jeong@samsung.com 475 Jong-Hyouk Lee 476 Sangmyung University 477 Sangmyung University 478 31, Sangmyeongdae-gil, Dongnam-gu 479 Cheonan, NY 31066 480 Republic of Korea 482 EMail: jonghyouk@smu.ac.kr