idnits 2.17.1 draft-yan-ipwave-nd-04.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 (October 11, 2019) is 1652 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 249, 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-03 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Yan 3 Internet-Draft CNNIC 4 Intended status: Standards Track J. Lee 5 Expires: April 13, 2020 Sangmyung University 6 J. Jeong 7 Sungkyunkwan University 8 October 11, 2019 10 Service and Neighbor Discovery in ITS 11 draft-yan-ipwave-nd-04.txt 13 Abstract 15 For C-ACC, platooning and other typical use cases in ITS, direct IP 16 communication between neighbor vehicles poses the following two 17 issues: 1) how to discover the neighbor vehicle and the demanded 18 service; and 2) how to discover the link-layer address of the 19 neighbor vehicle and selected server. This draft presents a solution 20 to these problems based on DNS-SD/mDNS [RFC6762][RFC6763]. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119. 28 Status of This Memo 30 This Internet-Draft is submitted 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). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 13, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Prefix management . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Name configuration . . . . . . . . . . . . . . . . . . . . . 3 65 4. Address configuration . . . . . . . . . . . . . . . . . . . . 4 66 5. Neighbor vehicle and service discovery . . . . . . . . . . . 4 67 6. Mobility support . . . . . . . . . . . . . . . . . . . . . . 5 68 7. Signaling messages . . . . . . . . . . . . . . . . . . . . . 5 69 8. Security considerations . . . . . . . . . . . . . . . . . . . 6 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 9.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 As illustrated in [DNS-Autoconf], a naming scheme is needed for the 78 vehicle devices to support the unique name auto-configuration. This 79 can support the location based communicaton and scalable information 80 organization in ITS. Based on the naming scheme like this and the 81 widely-used DNS-SD/mDNS protocol, this draft illustrates how to 82 discover the neighbor vehicle or services with DNS resolution logic. 83 Before this, we make the following assumptions: 85 o Name: vehicle SHOULD have a temporary name which is related to its 86 geo-location. 88 o Address: vehicle SHOULD have a global IP address which is 89 routeable for the IP communications. 91 In this way, a standardized, efficient and scalable scheme can be 92 used to retrieve the necessary information of the corresponding node 93 (domain name, IP address, goe-location, link-local address and so on) 94 for the further communications based on the DNS-SD/mDNS function. In 95 addition, the extended NDP messages (e.g., RA and RS messages) can 96 also be used to exchange some required information (e.g., mobile 97 network prefixes, link-local address) in ITS in combination with DNS- 98 SD/mDNS [MNPP]. 100 2. Prefix management 102 The network architecture which illustrates the prefix management of 103 name and address is shown in Figure 1. 105 +------------+ +**********+ +------------+ 106 | Router1 |--------* Internet *--------| Router2 | 107 |[IP-Prefix1]| +**********+ |[IP-Prefix2]| 108 +------------+ +------------+ 109 | | 110 | | 111 ----------- ----------- 112 | | | | 113 | | | | 114 +-------+ +-------+ +-------+ +-------+ 115 | RSU1 | | RSU2 | | RSU3 | | RSU4 | 116 |[Name1]| |[Name2]| |[Name3]| |[Name4]| 117 +-------+ +-------+ +-------+ +-------+ 119 +-------+ 120 |Vehicle|--------moving----------> 121 +-------+ 123 Figure 1: Name and address management architecture 125 As shown in Figure 1, Router1 and Router2 are two routers which can 126 connect to the Internet and they hold different IP prefixes. RSU1 127 and RSU2 are two RSUs under Router1 but hold different name prefixes, 128 while RSU3 and RSU4 are two RSUs under Router2 but hold different 129 name prefixes. 131 3. Name configuration 133 The RSU acts as an access router for the static and moving vehicles 134 which want to be connected. Based on [RFC3640], [RFC6106] or 135 extended WSA message, the RSU can announce its location based name 136 prefix to the vehicles covered by the RSU. This location based 137 prefix may contain information such as country, city, street and so 138 on, which will act as the "domain_name" of the vehicle device name as 139 spefified in [DNS-Autoconf]. 141 4. Address configuration 143 The RSU may advertise the IP prefix to support the SLAAC operation of 144 vehicle devices and movement detection (in the IP layer). If the 145 DHCP is used for the address configuration, RSU also acts as 146 functional entity of the DHCP infrastructure . 148 5. Neighbor vehicle and service discovery 150 (1) RSU based 152 Vehicles may have direct connection with the serving RSU and join the 153 same link with the serving RSU. Then the RSU can maintain the 154 registered vehicle or service in its serving domain. Otherwise, the 155 RSU acts as a relay node for discovering in a proxy manner. 157 When a vehicle wants to locate the potential nearby neighbor and 158 further establish the communication, the vehicle will trigger the 159 direct unicast query to port 5353 or legacy unicast DNS query to the 160 RSU. RSU may respond directly if it has the related information, 161 otherwise, the RSU multicasts the DNS query to multicast group to 162 retrieve the related information. Unicast response is the first 163 recommendation here because it can suppress the flooding, but of 164 course, the DNS response message can also be multicasted as an active 165 announcement of the verhicle or service existence. 167 (2) Ad-hoc based 169 Vehicles may communicate with each other or sense the front and rear 170 neighbors with DSRC, WiFi, blue-tooth or other short-distance 171 communication technologies, connecting each other in the Ad-hoc 172 manner. Then the discovery can be executed in an infrastructure-less 173 manner with the following phases, as specified in mDNS. 175 o Probing: When a vehicle starts up, wakes up from stalls or the 176 VANET topology changes (after configuration of the name and 177 address), it should probe the availability of the service it 178 announced. Then the vehicle periodically announces the service 179 and its existence with unsolicited multicast DNS response 180 containing, in the Answer Section, all of its service,name,address 181 and other information. The vehicle also updates the related 182 information actively if there is any change. 184 o Discovering: To support the service and neighbor vehicle discovery 185 in the dynamic and fragmentation-possible environment in VANET, 186 different query modes of mDNS can be used for different scenarios: 187 1) One-Short Multicast DNS Query can be used to locate a specific 188 vehicle (for example). 2) Continuous Multicast DNS Query can be 189 used to locate the nearby vehicles which are moving (for example). 191 o Refreshing: After the neighbor discovery illustrated above, the 192 vehicles should continually exchange their name, IP address, geo- 193 location and other information in order to refresh the established 194 communications. For example, the Multiple Questions Multicast 195 Responses can be used to update the caches of receivers 196 efficiently and Multiple Questions Unicast Responses can be used 197 to support the fast bootstrapping when new vehicle joins. 199 o Goodbye: When the vehicle arrives at its destination, stalls 200 temporarily or shuts down its communication or sensing devices, it 201 will announce the service suspending and its inexistence with 202 unsolicited multicast DNS response packet, giving the same RRs 203 (for example containing its name and address), but TTL of zero. 205 6. Mobility support 207 During the movement of the vehicle, it may cross different RUSes. 208 When attaching into a new RSU, the new domain prefix and new IP 209 prefix may be learned. Generally, there are two main cases for the 210 mobility: 212 o Name prefix changes and IP prefix remains, as shown in Figure 1, 213 the vehicle hands over from RSU1 to RSU2. The vehicle will 214 configure a new name from RSU2 and may update the new name in the 215 local database (e.g., RSU). But the vehicle should keep its 216 previous name for a period until that all the communicating 217 neighbors have learned its new name. During this period, the 218 vehicle will contain both previous and new names in the DNS 219 response message. 221 o Both name and IP prefixes change, as shown in Figure 1, the 222 vehicle hands over from RSU2 to RSU3. The vehicle will configure 223 both new name and new IP address from RSU3 and update them in the 224 local database. Then the above scheme can also be used or with 225 IP-layer mobility management protocols. 227 7. Signaling messages 229 To facilitate the further communication, the link-layer address and 230 geo-information may be included in the DNS message in a piggyback 231 manner. Otherwise, these information may be obtained through the 232 following NDP or other procedures. 234 8. 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 9. References 247 9.1. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., 255 and P. Gentric, "RTP Payload Format for Transport of 256 MPEG-4 Elementary Streams", RFC 3640, 257 DOI 10.17487/RFC3640, November 2003, 258 . 260 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 261 "IPv6 Router Advertisement Options for DNS Configuration", 262 RFC 6106, DOI 10.17487/RFC6106, November 2010, 263 . 265 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 266 DOI 10.17487/RFC6762, February 2013, 267 . 269 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 270 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 271 . 273 9.2. Informative References 275 [DNS-Autoconf] 276 Jeong, J., Lee, S., and J. Park, "DNS Name 277 Autoconfiguration for Internet of Things Devices", draft- 278 jeong-ipwave-iot-dns-autoconf-03, July 2018. 280 [MNPP] Lee, J., Tsukada, M., and T. Ernst, "Mobile Network Prefix 281 Provisioning", draft-jhlee-mext-mnpp-00, October 2009. 283 Authors' Addresses 285 Zhiwei Yan 286 CNNIC 287 No.4 South 4th Street, Zhongguancun 288 Beijing 100190 289 China 291 EMail: yan@cnnic.cn 293 Jong-Hyouk Lee 294 Sangmyung University 295 31, Sangmyeongdae-gil, Dongnam-gu 296 Cheonan 297 Republic of Korea 299 EMail: jonghyouk@smu.ac.kr 301 Jaehoon Paul Jeong 302 Department of Computer Science and Engineering 303 Sungkyunkwan University 304 2066 Seobu-Ro, Jangan-Gu 305 Suwon, Gyeonggi-Do 306 Republic of Korea 308 EMail: pauljeong@skku.edu