idnits 2.17.1 draft-yan-ipwave-nd-08.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 (May 10, 2021) is 1053 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 248, 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: November 11, 2021 G. Geng 6 Jinan University 7 J. Lee 8 Sejong University 9 J. Jeong 10 Sungkyunkwan University 11 May 10, 2021 13 Service and Neighbor Vehicle Discovery in IPv6-Based Vehicular Networks 14 draft-yan-ipwave-nd-08.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 November 11, 2021. 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 7.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 As illustrated in [DNS-Autoconf], a naming scheme is needed for the 81 vehicle devices to support the unique name auto-configuration. This 82 can support the location based communication and scalable information 83 organization in Intelligent Transportation Systems (ITS). Based on 84 the naming scheme like this and the widely-used DNS-SD/mDNS protocol, 85 this document illustrates how to discover a neighbor vehicle or the 86 required services with DNS resolution logic. Before this, we make 87 the following assumptions: 89 o Name: A vehicle SHOULD have at least one temporary name which may 90 be related with its geo-location or provided services. This name 91 is related with the service or identifier of the particular 92 vehicle. 94 o Address: A vehicle SHOULD have at least one global IP address 95 which is routable for the IPv6 communications. This address acts 96 as the Home Address (HoA) of vehicle to facilitate its mobility. 98 In this way, a standardized, efficient and scalable scheme should be 99 used to retrieve the necessary information of the corresponding node 100 (domain name, IP address, geo-location, link-layer address, key and 101 so on) for the further communications based on the DNS-SD/mDNS 102 functions. In addition, the IPv6 Neighbor Discovery (ND)'s messages 103 (e.g., RA and RS messages) can also be used to exchange some required 104 information (e.g., mobile network prefixes) in ITS in combination 105 with DNS-SD/mDNS [MNPP]. 107 2. Name and address configurations 109 Typically, the Road-Side Unit (RSU) acts as an Access Router (AR) to 110 serve for the static and moving vehicles which want to be connected 111 into the networks locally or publically. 113 Based on [RFC3646], [RFC6106] or extended WAVE Service Announcement 114 (WSA) message, the RSU can announce its location based name prefix to 115 the vehicles covered by the RSU. This location based prefix may 116 contain information such as country, city, street and so on, which 117 will act as the "domain_name" of the vehicle device name as specified 118 in [DNS-Autoconf]. 120 The RSU may also advertise the IPv6 prefix to support the IPv6 121 Stateless Address Auto-configuration (SLAAC) operation of vehicle 122 devices and movement detection (in the IP layer). If the DHCPv6 is 123 used for the address configuration, RSU also acts as functional 124 entity such as a DHCP proxy and DHCP server. 126 3. Service and neighbor vehicle discovery 128 Vehicular network is a dynamic environment, then the following two 129 modes should be supported based on different connection conditions of 130 the vehicle. 132 (1) RSU based 134 Vehicles may have direct connection with the serving RSU and join the 135 same link with the serving RSU. Then the RSU can maintain the 136 registered vehicles and services in its serving domain. Otherwise, 137 the RSU acts as a proxy node for discovering in a proxy manner 138 [DNSSD-Hybrid]. 140 When a vehicle wants to locate the potential service or the nearby 141 neighbor and further establish the communication, the vehicle will 142 trigger the direct unicast query to port 5353 or legacy unicast DNS 143 query to the RSU. RSU may respond directly if it has the related 144 information, otherwise, the RSU multicasts the DNS query to the 145 multicast group to retrieve the related information. A unicast 146 response is the first recommendation here because it can suppress the 147 flooding, but of course, the DNS response message can also be 148 multicasted as an active announcement of the vehicle or service 149 existence. 151 (2) Ad-hoc based 153 Vehicles may communicate with each other or sense the front and rear 154 neighbor vehicles with DSRC, WiFi, Bluetooth or other short-distance 155 communication technologies, connecting each other in the Ad-hoc 156 manner. Then the discovery can also be executed in an 157 infrastructure-less manner with the following phases, as specified in 158 the plain mDNS. 160 o Probing: When a vehicle starts up, wakes up from sleeping mode or 161 the Vehicular Ad Hoc Networks (VANET) topology changes (after 162 configuration of the name and address), it should probe the 163 availability of the service with which it can provide other 164 vehicles. Then the vehicle periodically announces the service and 165 its existence with unsolicited multicast DNS response containing, 166 in the Answer Section, all of its service name, DNS name, IP 167 address and other information. The vehicle also updates the 168 related information actively if there is any change. 170 o Discovering: To support the service and neighbor vehicle discovery 171 in the dynamic and fragmentation-possible environment in VANET, 172 different query modes of mDNS can be used for different scenarios: 173 1) One-Short Multicast DNS Query can be used to locate a specific 174 vehicle. 2) Continuous Multicast DNS Query can be used to locate 175 the nearby vehicles which are moving. 177 o Refreshing: After the neighbor discovery as illustrated above, the 178 vehicles should continually exchange their DNS name, IP address, 179 geo-location and other information in order to refresh the 180 established communications. For example, the Multiple Questions 181 Multicast Responses can be used to update the caches of receivers 182 efficiently and Multiple Questions Unicast Responses can be used 183 to support the fast bootstrapping when a new vehicle joins. 185 o Goodbye: When the vehicle arrives at its destination, stops 186 temporarily or shuts down its communication or sensing devices, it 187 will announce the service suspending and its inexistence with an 188 unsolicited multicast DNS response packet, giving the same 189 Resource Records (RRs) (containing its DNS name and IP address), 190 but with zero Time-To-Live (TTL). 192 4. Mobility support 194 During the movement of the vehicle, it may cross different RSUs. 195 When a vehicle enters the coverage of a new RSU, the new domain 196 prefix and new IPv6 prefix may be learned. Generally, there are the 197 following three main cases for the mobility: 199 o The domain name changes and the IP prefix remains. The vehicle 200 will configure a new DNS name from the new RSU. Then the vehicle 201 should update the new DNS name in the local database (e.g., RSU) 202 with DNS Update [RFC2136], DNS Push Notifications [DNSSD-Push], 203 Service Registration Protocol (SRP) [DNSSD-SRP] or just actively 204 announce its new name information with plain mDNS notification 205 scheme. If the service is registered in the RSU, then the stale 206 service should be withdrawn in order to reduce the management load 207 [DNSSD-Lease]. 209 o The domain name remains and the IP prefix changes. The vehicle 210 will configure a new IPv6 temporary address (e.g., CoA) form the 211 new RSU. Then the IP-layer mobility management protocols should 212 be used to update the binding entry of the vehicle (e.g., Mobile 213 IPv6 [RFC6275]). 215 o Both the domain name and IP prefix change, the name information 216 should be updated as in the first case and then the IP-layer 217 mobility management protocols (e.g., Mobile IPv6 [RFC6275] and 218 Proxy Mobile IPv6 [RFC5213]) as in the second case should also be 219 triggered. 221 5. Signaling messages 223 To facilitate the further communication, the link-layer address, 224 public Key, geo-information and other metadata may be included in the 225 DNS message in a piggyback manner. Specially, the TXT RR in DNS-SD 226 can be used to include these information with multiple key: value 227 pairs. 229 Besides, this kind of information may be obtained through the 230 following IPv6 Neighbor Discovery Protocol (NDP) or other procedures 231 (e.g., DHCP and WSA). 233 6. Security considerations 235 In order to reduce the DNS traffic on the wireless link and avoid the 236 unnecessary flooding, the related schemes in mDNS can be used, such 237 as: Known-Answer Suppression, Multipacket Known-Answer Suppression, 238 Duplicate Question Suppression and Duplicate Answer Suppression. 240 In order to guarantee the origination of the DNS message and avoid 241 the DNS message tampering, the security consideration in mDNS should 242 also be adopted. 244 7. References 246 7.1. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, 250 DOI 10.17487/RFC2119, March 1997, 251 . 253 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 254 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 255 RFC 2136, DOI 10.17487/RFC2136, April 1997, 256 . 258 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 259 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 260 DOI 10.17487/RFC3646, December 2003, 261 . 263 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 264 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 265 RFC 5213, DOI 10.17487/RFC5213, August 2008, 266 . 268 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 269 "IPv6 Router Advertisement Options for DNS Configuration", 270 RFC 6106, DOI 10.17487/RFC6106, November 2010, 271 . 273 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 274 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 275 2011, . 277 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 278 DOI 10.17487/RFC6762, February 2013, 279 . 281 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 282 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 283 . 285 7.2. Informative References 287 [DNS-Autoconf] 288 Jeong, J., Lee, S., and J. Park, "DNS Name 289 Autoconfiguration for Internet-of-Things Devices in IP- 290 Based Vehicular Networks", draft-jeong-ipwave-iot-dns- 291 autoconf-07, November 2019. 293 [DNSSD-Hybrid] 294 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 295 Service Discovery", draft-ietf-dnssd-hybrid-10, March 296 2019. 298 [DNSSD-Lease] 299 Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", 300 draft-sekar-dns-ul-02, August 2018. 302 [DNSSD-Push] 303 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 304 draft-ietf-dnssd-push-25, October 2019. 306 [DNSSD-SRP] 307 Cheshire, S. and T. Lemon, "Service Registration Protocol 308 for DNS-Based Service Discovery", draft-ietf-dnssd-srp- 309 02, July 2019. 311 [MNPP] Lee, J., Tsukada, M., and T. Ernst, "Mobile Network Prefix 312 Provisioning", draft-jhlee-mext-mnpp-00, October 2009. 314 Authors' Addresses 316 Zhiwei Yan 317 CNNIC 318 No.4 South 4th Street, Zhongguancun 319 Beijing 100190 320 China 322 EMail: yan@cnnic.cn 324 Jian Weng 325 Jinan University 326 No.601, West Huangpu Avenue 327 Guangzhou 510632 328 China 330 EMail: cryptjweng@gmail.com 331 Guanggang Geng 332 Jinan University 333 No.601, West Huangpu Avenue 334 Guangzhou 510632 335 China 337 EMail: gggeng@jnu.edu.cn 339 Jong-Hyouk Lee 340 Sejong University 341 209, Neungdong-ro, Gwangjin-gu 342 Seoul 05006 343 Republic of Korea 345 EMail: jonghyouk@sejong.ac.kr 347 Jaehoon Paul Jeong 348 Department of Computer Science and Engineering 349 Sungkyunkwan University 350 2066 Seobu-Ro, Jangan-Gu 351 Suwon, Gyeonggi-Do 352 Republic of Korea 354 EMail: pauljeong@skku.edu