idnits 2.17.1 draft-yan-ipwave-nd-05.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.) ** The abstract seems to contain references ([RFC6762], [RFC6763]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2019) is 1620 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) == Unused Reference: 'RFC2119' is defined on line 257, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-07 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group Z. Yan 3 Internet-Draft CNNIC 4 Intended status: Standards Track J. Lee 5 Expires: May 20, 2020 Sangmyung University 6 J. Jeong 7 Sungkyunkwan University 8 November 17, 2019 10 Neighbor Vehicle Discovery and Service in IP-Based Vehicular Networks 11 draft-yan-ipwave-nd-05.txt 13 Abstract 15 For Cooperative Adaptive Cruise Control (C-ACC), platooning and other 16 typical use cases in ITS, direct IP communication between neighbor 17 vehicles poses the following two issues: 1) how to discover a 18 neighbor vehicle and the demanded service; and 2) how to discover the 19 link-layer address of the neighbor vehicle and selected server. This 20 document presents a solution to these problems based on DNS-SD/mDNS 21 [RFC6762][RFC6763]. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 20, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Prefix management . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Name configuration . . . . . . . . . . . . . . . . . . . . . 3 66 4. Address configuration . . . . . . . . . . . . . . . . . . . . 4 67 5. Neighbor vehicle and service discovery . . . . . . . . . . . 4 68 6. Mobility support . . . . . . . . . . . . . . . . . . . . . . 5 69 7. Signaling messages . . . . . . . . . . . . . . . . . . . . . 6 70 8. Security considerations . . . . . . . . . . . . . . . . . . . 6 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 9.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 As illustrated in [DNS-Autoconf], a naming scheme is needed for the 79 vehicle devices to support the unique name auto-configuration. This 80 can support the location based communicaton and scalable information 81 organization in Intelligent Transportation Systems (ITS). Based on 82 the naming scheme like this and the widely-used DNS-SD/mDNS protocol, 83 this document illustrates how to discover a neighbor vehicle or the 84 required services with DNS resolution logic. Before this, we make 85 the following assumptions: 87 o Name: A vehicle SHOULD have a temporary name which is related to 88 its geo-location. 90 o Address: A vehicle SHOULD have a global IP address which is 91 routeable for the IP communications. 93 In this way, a standardized, efficient and scalable scheme can be 94 used to retrieve the necessary information of the corresponding node 95 (domain name, IP address, goe-location, link-local address and so on) 96 for the further communications based on the DNS-SD/mDNS function. In 97 addition, the IPv6 Neighbor Discovery (ND)'s messages (e.g., RA and 98 RS messages) can also be used to exchange some required information 99 (e.g., mobile network prefixes and link-local address) in ITS in 100 combination with DNS-SD/mDNS [MNPP]. 102 2. Prefix management 104 The network architecture which illustrates the prefix management of 105 name and address is shown in Figure 1. 107 +------------+ +**********+ +------------+ 108 | Router1 |--------* Internet *--------| Router2 | 109 |[IP-Prefix1]| +**********+ |[IP-Prefix2]| 110 +------------+ +------------+ 111 | | 112 | | 113 ----------- ----------- 114 | | | | 115 | | | | 116 +-------+ +-------+ +-------+ +-------+ 117 | RSU1 | | RSU2 | | RSU3 | | RSU4 | 118 |[Name1]| |[Name2]| |[Name3]| |[Name4]| 119 +-------+ +-------+ +-------+ +-------+ 121 +-------+ 122 |Vehicle|--------moving----------> 123 +-------+ 125 Figure 1: Name and address management architecture 127 As shown in Figure 1, Router1 and Router2 are two routers which can 128 connect to the Internet and they hold different IP prefixes. RSU1 129 and RSU2 are two Road-Side Units (RSUs) under Router1 but hold 130 different name prefixes, while RSU3 and RSU4 are two RSUs under 131 Router2 but hold different name prefixes. 133 3. Name configuration 135 The RSU acts as an access router for the static and moving vehicles 136 which want to be connected with the Internet. Based on [RFC3646], 137 [RFC6106] or extended WAVE Service Announcement (WSA) message, the 138 RSU can announce its location based name prefix to the vehicles 139 covered by the RSU. This location based prefix may contain 140 information such as country, city, street and so on, which will act 141 as the "domain_name" of the vehicle device name as spefified in [DNS- 142 Autoconf]. 144 4. Address configuration 146 The RSU may advertise the IP prefix to support the IPv6 Stateless 147 Address Autoconfiguration (SLAAC) operation of vehicle devices and 148 movement detection (in the IP layer). If the DHCP is used for the 149 address configuration, RSU also acts as functional entity such as a 150 DHCP proxy and DHCP server. 152 5. Neighbor vehicle and service discovery 154 (1) RSU based 156 Vehicles may have direct connection with the serving RSU and join the 157 same link with the serving RSU. Then the RSU can maintain the 158 registered vehicle or service in its serving domain. Otherwise, the 159 RSU acts as a relay node for discovering in a proxy manner. 161 When a vehicle wants to locate the potential nearby neighbor and 162 further establish the communication, the vehicle will trigger the 163 direct unicast query to port 5353 or legacy unicast DNS query to the 164 RSU. RSU may respond directly if it has the related information, 165 otherwise, the RSU multicasts the DNS query to the multicast group to 166 retrieve the related information. A unicast response is the first 167 recommendation here because it can suppress the flooding, but of 168 course, the DNS response message can also be multicasted as an active 169 announcement of the verhicle or service existence. 171 (2) Ad-hoc based 173 Vehicles may communicate with each other or sense the front and rear 174 neighbor vehicles with DSRC, WiFi, Bluetooth or other short-distance 175 communication technologies, connecting each other in the Ad-hoc 176 manner. Then the discovery can be executed in an infrastructure-less 177 manner with the following phases, as specified in mDNS. 179 o Probing: When a vehicle starts up, wakes up from sleeping mode or 180 the Vehicular Ad Hoc Networks (VANET) topology changes (after 181 configuration of the name and address), it should probe the 182 availability of the service with which it can provide other 183 vehicles. Then the vehicle periodically announces the service and 184 its existence with unsolicited multicast DNS response containing, 185 in the Answer Section, all of its service name, DNS name, IP 186 address and other information. The vehicle also updates the 187 related information actively if there is any change. 189 o Discovering: To support the service and neighbor vehicle discovery 190 in the dynamic and fragmentation-possible environment in VANET, 191 different query modes of mDNS can be used for different scenarios: 192 1) One-Short Multicast DNS Query can be used to locate a specific 193 vehicle. 2) Continuous Multicast DNS Query can be used to locate 194 the nearby vehicles which are moving. 196 o Refreshing: After the neighbor discovery as illustrated above, the 197 vehicles should continually exchange their DNS name, IP address, 198 geo-location and other information in order to refresh the 199 established communications. For example, the Multiple Questions 200 Multicast Responses can be used to update the caches of receivers 201 efficiently and Multiple Questions Unicast Responses can be used 202 to support the fast bootstrapping when a new vehicle joins. 204 o Goodbye: When the vehicle arrives at its destination, stops 205 temporarily or shuts down its communication or sensing devices, it 206 will announce the service suspending and its inexistence with an 207 unsolicited multicast DNS response packet, giving the same 208 Resource Records (RRs) (containing its DNS name and IP address), 209 but with zero Time-To-Live (TTL). 211 6. Mobility support 213 During the movement of the vehicle, it may cross different RSUs. 214 When a vehicle enters the communication coverage of a new RSU, the 215 new domain prefix and new IP prefix may be learned. Generally, there 216 are two main cases for the mobility: 218 o The domain name changes and the IP prefix remains, as shown in 219 Figure 1, the vehicle moves from the coverage of RSU1 to the 220 coverage of RSU2. The vehicle will configure a new DNS name from 221 RSU2 and may update the new DNS name in the local database (e.g., 222 RSU). But the vehicle should keep its previous DNS name for a 223 while until that all the communicating neighbors have learned its 224 new DNS name. During this duration, the vehicle will contain both 225 the previous and new DNS names in the DNS response message. 227 o Both the domain name and IP prefix change, as shown in Figure 1, 228 the vehicle performs a handover from RSU2 to RSU3. The vehicle 229 will configure both its new DNS name and new IP address from RSU3 230 and update them in the local database. Then the above scheme can 231 also be used or with IP-layer mobility management protocols (e.g., 232 Mobile IPv6 [RFC6275] and Proxy Mobile IPv6 [RFC5213]). 234 7. Signaling messages 236 To facilitate the further communication, the link-layer address and 237 geo-information may be included in the DNS message in a piggyback 238 manner. Otherwise, this information may be obtained through the 239 following IPv6 Neighbor Discovery Protocol (NDP) or other procedures 240 (e.g., DHCP and WSA). 242 8. Security considerations 244 In order to reduce the DNS traffic on the wireless link and avoid the 245 unnecessary flooding, the related schemes in mDNS can be used, such 246 as: Known-Answer Suppression, Multipacket Known-Answer Suppression, 247 Duplicate Question Suppression and Duplicate Answer Suppression. 249 In order to guarantee the origination of the DNS message and avoid 250 the DNS message tampering, the security consideration in mDNS should 251 also be adopted. 253 9. References 255 9.1. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, 259 DOI 10.17487/RFC2119, March 1997, 260 . 262 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 263 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 264 DOI 10.17487/RFC3646, December 2003, 265 . 267 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 268 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 269 RFC 5213, DOI 10.17487/RFC5213, August 2008, 270 . 272 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 273 "IPv6 Router Advertisement Options for DNS Configuration", 274 RFC 6106, DOI 10.17487/RFC6106, November 2010, 275 . 277 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 278 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 279 2011, . 281 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 282 DOI 10.17487/RFC6762, February 2013, 283 . 285 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 286 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 287 . 289 9.2. Informative References 291 [DNS-Autoconf] 292 Jeong, J., Lee, S., and J. Park, "DNS Name 293 Autoconfiguration for Internet-of-Things Devices in IP- 294 Based Vehicular Networks", draft-jeong-ipwave-iot-dns- 295 autoconf-07, November 2019. 297 [MNPP] Lee, J., Tsukada, M., and T. Ernst, "Mobile Network Prefix 298 Provisioning", draft-jhlee-mext-mnpp-00, October 2009. 300 Authors' Addresses 302 Zhiwei Yan 303 CNNIC 304 No.4 South 4th Street, Zhongguancun 305 Beijing 100190 306 China 308 EMail: yan@cnnic.cn 310 Jong-Hyouk Lee 311 Sangmyung University 312 31, Sangmyeongdae-gil, Dongnam-gu 313 Cheonan 314 Republic of Korea 316 EMail: jonghyouk@smu.ac.kr 318 Jaehoon Paul Jeong 319 Department of Computer Science and Engineering 320 Sungkyunkwan University 321 2066 Seobu-Ro, Jangan-Gu 322 Suwon, Gyeonggi-Do 323 Republic of Korea 325 EMail: pauljeong@skku.edu