idnits 2.17.1 draft-yan-ipwave-nd-09.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 7, 2021) is 901 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 254, 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 == Outdated reference: A later version (-03) exists of draft-sekar-dns-ul-02 == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-srp-02 Summary: 3 errors (**), 0 flaws (~~), 5 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. Weng 5 Expires: May 11, 2022 G. Geng 6 Jinan University 7 J. Lee 8 Sejong University 9 J. Jeong 10 Sungkyunkwan University 11 November 7, 2021 13 Service and Neighbor Vehicle Discovery in IPv6-Based Vehicular Networks 14 draft-yan-ipwave-nd-09.txt 16 Abstract 18 For Cooperative Adaptive Cruise Control (C-ACC), platooning and other 19 typical use cases in Intelligent Transportation System (ITS), IPv6 20 communication between neighbor vehicles and between vehicle and 21 server pose the following two issues: 1) how to discover a neighbor 22 vehicle and the demanded service; and 2) how to discover the link- 23 layer address and other metadata of the neighbor vehicle and selected 24 server. This document presents a solution to these problems based on 25 DNS-SD/mDNS [RFC6762][RFC6763]. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 11, 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Name and address configurations . . . . . . . . . . . . . . . 3 69 3. Service and neighbor vehicle discovery . . . . . . . . . . . 3 70 4. Mobility support . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Signaling messages . . . . . . . . . . . . . . . . . . . . . 5 72 6. Security considerations . . . . . . . . . . . . . . . . . . . 5 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 8.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 As illustrated in [DNS-Autoconf], a naming scheme is needed for the 82 vehicle devices to support the unique name auto-configuration. This 83 can support the location based communication and scalable information 84 organization in Intelligent Transportation Systems (ITS). Based on 85 the naming scheme like this and the widely-used DNS-SD/mDNS protocol, 86 this document illustrates how to discover a neighbor vehicle or the 87 required services with DNS resolution logic. Before this, we make 88 the following assumptions: 90 o Name: A vehicle SHOULD have at least one temporary name which may 91 be related with its geo-location or provided services. This name 92 is related with the service or identifier of the particular 93 vehicle. 95 o Address: A vehicle SHOULD have at least one global IP address 96 which is routable for the IPv6 communications. This address acts 97 as the Home Address (HoA) of vehicle to facilitate its mobility. 99 In this way, a standardized, efficient and scalable scheme should be 100 used to retrieve the necessary information of the corresponding node 101 (domain name, IP address, geo-location, link-layer address, key and 102 so on) for the further communications based on the DNS-SD/mDNS 103 functions. In addition, the IPv6 Neighbor Discovery (ND)'s messages 104 (e.g., RA and RS messages) can also be used to exchange some required 105 information (e.g., mobile network prefixes) in ITS in combination 106 with DNS-SD/mDNS [MNPP]. 108 2. Name and address configurations 110 Typically, the Road-Side Unit (RSU) acts as an Access Router (AR) to 111 serve for the static and moving vehicles which want to be connected 112 into the networks locally or publically. 114 Based on [RFC3646], [RFC6106] or extended WAVE Service Announcement 115 (WSA) message, the RSU can announce its location based name prefix to 116 the vehicles covered by the RSU. This location based prefix may 117 contain information such as country, city, street and so on, which 118 will act as the "domain_name" of the vehicle device name as specified 119 in [DNS-Autoconf]. 121 The RSU may also advertise the IPv6 prefix to support the IPv6 122 Stateless Address Auto-configuration (SLAAC) operation of vehicle 123 devices and movement detection (in the IP layer). If the DHCPv6 is 124 used for the address configuration, RSU also acts as functional 125 entity such as a DHCP proxy and DHCP server. 127 3. Service and neighbor vehicle discovery 129 Vehicular network is a dynamic environment, then the following two 130 modes should be supported based on different connection conditions of 131 the vehicle. 133 (1) RSU based 135 Vehicles may have direct connection with the serving RSU and join the 136 same link with the serving RSU. Then the RSU can maintain the 137 registered vehicles and services in its serving domain. Otherwise, 138 the RSU acts as a proxy node for discovering in a proxy manner 139 [DNSSD-Hybrid]. 141 When a vehicle wants to locate the potential service or the nearby 142 neighbor and further establish the communication, the vehicle will 143 trigger the direct unicast query to port 5353 or legacy unicast DNS 144 query to the RSU. RSU may respond directly if it has the related 145 information, otherwise, the RSU multicasts the DNS query to the 146 multicast group to retrieve the related information. A unicast 147 response is the first recommendation here because it can suppress the 148 flooding, but of course, the DNS response message can also be 149 multicasted as an active announcement of the vehicle or service 150 existence. 152 (2) Ad-hoc based 154 Vehicles may communicate with each other or sense the front and rear 155 neighbor vehicles with DSRC, WiFi, Bluetooth or other short-distance 156 communication technologies, connecting each other in the Ad-hoc 157 manner. Then the discovery can also be executed in an 158 infrastructure-less manner with the following phases, as specified in 159 the plain mDNS. 161 o Probing: When a vehicle starts up, wakes up from sleeping mode or 162 the Vehicular Ad Hoc Networks (VANET) topology changes (after 163 configuration of the name and address), it should probe the 164 availability of the service with which it can provide other 165 vehicles. Then the vehicle periodically announces the service and 166 its existence with unsolicited multicast DNS response containing, 167 in the Answer Section, all of its service name, DNS name, IP 168 address and other information. The vehicle also updates the 169 related information actively if there is any change. 171 o Discovering: To support the service and neighbor vehicle discovery 172 in the dynamic and fragmentation-possible environment in VANET, 173 different query modes of mDNS can be used for different scenarios: 174 1) One-Short Multicast DNS Query can be used to locate a specific 175 vehicle. 2) Continuous Multicast DNS Query can be used to locate 176 the nearby vehicles which are moving. 178 o Refreshing: After the neighbor discovery as illustrated above, the 179 vehicles should continually exchange their DNS name, IP address, 180 geo-location and other information in order to refresh the 181 established communications. For example, the Multiple Questions 182 Multicast Responses can be used to update the caches of receivers 183 efficiently and Multiple Questions Unicast Responses can be used 184 to support the fast bootstrapping when a new vehicle joins. 186 o Goodbye: When the vehicle arrives at its destination, stops 187 temporarily or shuts down its communication or sensing devices, it 188 will announce the service suspending and its inexistence with an 189 unsolicited multicast DNS response packet, giving the same 190 Resource Records (RRs) (containing its DNS name and IP address), 191 but with zero Time-To-Live (TTL). 193 4. Mobility support 195 During the movement of the vehicle, it may cross different RSUs. 196 When a vehicle enters the coverage of a new RSU, the new domain 197 prefix and new IPv6 prefix may be learned. Generally, there are the 198 following three main cases for the mobility: 200 o The domain name changes and the IP prefix remains. The vehicle 201 will configure a new DNS name from the new RSU. Then the vehicle 202 should update the new DNS name in the local database (e.g., RSU) 203 with DNS Update [RFC2136], DNS Push Notifications [DNSSD-Push], 204 Service Registration Protocol (SRP) [DNSSD-SRP] or just actively 205 announce its new name information with plain mDNS notification 206 scheme. If the service is registered in the RSU, then the stale 207 service should be withdrawn in order to reduce the management load 208 [DNSSD-Lease]. 210 o The domain name remains and the IP prefix changes. The vehicle 211 will configure a new IPv6 temporary address (e.g., CoA) form the 212 new RSU. Then the IP-layer mobility management protocols should 213 be used to update the binding entry of the vehicle (e.g., Mobile 214 IPv6 [RFC6275]). 216 o Both the domain name and IP prefix change, the name information 217 should be updated as in the first case and then the IP-layer 218 mobility management protocols (e.g., Mobile IPv6 [RFC6275] and 219 Proxy Mobile IPv6 [RFC5213]) as in the second case should also be 220 triggered. 222 5. Signaling messages 224 To facilitate the further communication, the link-layer address, 225 public Key, geo-information and other metadata may be included in the 226 DNS message in a piggyback manner. Specially, the TXT RR in DNS-SD 227 can be used to include these information with multiple key: value 228 pairs. 230 Besides, this kind of information may be obtained through the 231 following IPv6 Neighbor Discovery Protocol (NDP) or other procedures 232 (e.g., DHCP and WSA). 234 6. Security considerations 236 In order to reduce the DNS traffic on the wireless link and avoid the 237 unnecessary flooding, the related schemes in mDNS can be used, such 238 as: Known-Answer Suppression, Multipacket Known-Answer Suppression, 239 Duplicate Question Suppression and Duplicate Answer Suppression. 241 In order to guarantee the origination of the DNS message and avoid 242 the DNS message tampering, the security consideration in mDNS should 243 also be adopted. 245 7. Acknowledgements 247 This work was supported by the Beijing Nova Program of Science and 248 Technology under grant Z191100001119113. 250 8. References 252 8.1. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, 256 DOI 10.17487/RFC2119, March 1997, 257 . 259 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 260 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 261 RFC 2136, DOI 10.17487/RFC2136, April 1997, 262 . 264 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 265 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 266 DOI 10.17487/RFC3646, December 2003, 267 . 269 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 270 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 271 RFC 5213, DOI 10.17487/RFC5213, August 2008, 272 . 274 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 275 "IPv6 Router Advertisement Options for DNS Configuration", 276 RFC 6106, DOI 10.17487/RFC6106, November 2010, 277 . 279 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 280 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 281 2011, . 283 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 284 DOI 10.17487/RFC6762, February 2013, 285 . 287 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 288 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 289 . 291 8.2. Informative References 293 [DNS-Autoconf] 294 Jeong, J., Lee, S., and J. Park, "DNS Name 295 Autoconfiguration for Internet-of-Things Devices in IP- 296 Based Vehicular Networks", draft-jeong-ipwave-iot-dns- 297 autoconf-07, November 2019. 299 [DNSSD-Hybrid] 300 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 301 Service Discovery", draft-ietf-dnssd-hybrid-10, March 302 2019. 304 [DNSSD-Lease] 305 Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", 306 draft-sekar-dns-ul-02, August 2018. 308 [DNSSD-Push] 309 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 310 draft-ietf-dnssd-push-25, October 2019. 312 [DNSSD-SRP] 313 Cheshire, S. and T. Lemon, "Service Registration Protocol 314 for DNS-Based Service Discovery", draft-ietf-dnssd-srp- 315 02, July 2019. 317 [MNPP] Lee, J., Tsukada, M., and T. Ernst, "Mobile Network Prefix 318 Provisioning", draft-jhlee-mext-mnpp-00, October 2009. 320 Authors' Addresses 322 Zhiwei Yan 323 CNNIC 324 No.4 South 4th Street, Zhongguancun 325 Beijing 100190 326 China 328 EMail: yan@cnnic.cn 329 Jian Weng 330 Jinan University 331 No.601, West Huangpu Avenue 332 Guangzhou 510632 333 China 335 EMail: cryptjweng@gmail.com 337 Guanggang Geng 338 Jinan University 339 No.601, West Huangpu Avenue 340 Guangzhou 510632 341 China 343 EMail: gggeng@jnu.edu.cn 345 Jong-Hyouk Lee 346 Sejong University 347 209, Neungdong-ro, Gwangjin-gu 348 Seoul 05006 349 Republic of Korea 351 EMail: jonghyouk@sejong.ac.kr 353 Jaehoon Paul Jeong 354 Department of Computer Science and Engineering 355 Sungkyunkwan University 356 2066 Seobu-Ro, Jangan-Gu 357 Suwon, Gyeonggi-Do 358 Republic of Korea 360 EMail: pauljeong@skku.edu