idnits 2.17.1 draft-yan-ipwave-nd-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.) ** 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 (April 20, 2017) is 2556 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 246, 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-00 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: October 22, 2017 Sangmyung University 6 April 20, 2017 8 Neighbor discovery in ITS 9 draft-yan-ipwave-nd-00.txt 11 Abstract 13 For C-ACC, platooning and other typical use cases in ITS, a direct IP 14 communication between neighbor vehicles is required that poses the 15 following two issues: 1) how to discover the neighbor vehicle and the 16 required service; and 2) how to discover the link-layer address of 17 the neighbor vehicle and server. This draft presents a solution to 18 these problems based on DNS-SD/mDNS [RFC6762][RFC6763]. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119. 26 Status of This Memo 28 This Internet-Draft is submitted 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). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on October 22, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Prefix management . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Name configuration . . . . . . . . . . . . . . . . . . . . . 3 63 4. Address configuration . . . . . . . . . . . . . . . . . . . . 3 64 5. Neighbor vehicle and service discovery . . . . . . . . . . . 4 65 6. Mobility support . . . . . . . . . . . . . . . . . . . . . . 5 66 7. Signaling messages . . . . . . . . . . . . . . . . . . . . . 5 67 8. Security considerations . . . . . . . . . . . . . . . . . . . 5 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 9.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 As illustrated in [DNS-Autoconf], a naming scheme is needed for the 76 vehicle devices to support the unique name auto-configuration. This 77 can support the location based communicaton and scalable information 78 organization in ITS. Based on the naming scheme like this and the 79 mature DNS-SD/mDNS protocol, this draft illustrates how to discover 80 the vehicle or services with DNS resolution. Before this, we have 81 the following assumptions: 83 o Name: vehicle SHOULD have a temporary name which is related to its 84 geo-location. 86 o Address: vehicle SHOULD have a global IP address which is 87 routeable for the IP communications. 89 In this way, a standardized, efficient and scalable scheme can be 90 used to retrieve the necessary information of the corresponding node 91 (domain name, IP address, goe-location and so on) for the further 92 communications based on the DNS-SD/mDNS function. In addition, the 93 extended NDP messages (e.g., RA and RS messages) can also be used to 94 exchange some required information (e.g., mobile network prefixes, 95 link-local address) in ITS in combination with DNS-SD/mDNS [MNPP]. 97 2. Prefix management 99 The network architecture which illustrates the prefix management of 100 name and address is shown in Figure 1. 102 +------------+ +**********+ +------------+ 103 | Router1 |--------* Internet *--------| Router2 | 104 |[IP-Prefix1]| +**********+ |[IP-Prefix2]| 105 +------------+ +------------+ 106 | | 107 | | 108 ----------- ----------- 109 | | | | 110 | | | | 111 +-------+ +-------+ +-------+ +-------+ 112 | RSU1 | | RSU2 | | RSU3 | | RSU4 | 113 |[Name1]| |[Name2]| |[Name3]| |[Name4]| 114 +-------+ +-------+ +-------+ +-------+ 116 +-------+ 117 |Vehicle|--------road----------> 118 +-------+ 120 Figure 1: Name and address management architecture 122 As shown in Figure 1, Router1 and Router2 are two routers which can 123 connect to the Internet and hold different IP prefixes. RSU1 and 124 RSU2 are two RSUs under Router1 but hold different name prefixes, 125 while RSU3 and RSU4 are two RSUs under Router2 but hold different 126 name prefixes. 128 3. Name configuration 130 The RSU acts as an access router for the static and moving vehicles 131 which want to be connected. Based on [RFC3640], [RFC6106] or 132 extended WSA message, the RSU can announce its location based name 133 prefix to the vehicles covered by the RSU. This location based 134 prefix may contain information such as country, city, street and so 135 on, which will act as the "domain_name" of the vehicle device name as 136 spefified in [DNS-Autoconf]. 138 4. Address configuration 140 The RSU may advertise the IP prefix to support the SLAAC operation of 141 vehicle devices and movement detection (in the IP layer). If the 142 DHCP is used for the address configuration, RSU also acts as the DHCP 143 infrastructure. 145 5. Neighbor vehicle and service discovery 147 (1) RSU based 149 Vehicles may have direct connection with the serving RSU and join the 150 same link with the serving RSU. Then the RSU can maintain the 151 registered vehicle or service in its serving domain. Otherwise, the 152 RSU acts as a relay node for discovering in a proxy manner. 154 When a vehicle wants to locate the potential nearby neighbor and 155 further establish the communication, the vehicle will trigger the 156 direct unicast query to port 5353 or legacy unicast DNS query to the 157 RSU. RSU may response directly if it has the related information, 158 otherwise, the RSU multicasts the DNS query to multicast group to 159 retrieve the related information. Unicast response is the first 160 recommendation here because it can suppress the flooding, but of 161 course, the DNS response message can also be multicasted as an active 162 announcement of the verhicle or service existence. 164 (2) Ad-hoc based 166 Vehicles may communicate with each other or sense the front and rear 167 neighbors with DSRC, WiFi, blue-tooth or other short-distance 168 communication technologies, connecting each other in the Ad-hoc 169 manner. Then the discovery can be executed in an infrastructure-less 170 manner with the following phases, as specified in mDNS. 172 o Probing: When a vehicle starts up, wakes up from stalls or 173 topology changes (after configuration of the name and address), it 174 should probe the availability of the service it announced. Then 175 the vehicle periodically announces the service and its existence 176 with unsolicited multicast DNS response containing, in the Answer 177 Section, all of its service and name and address. The vehicle 178 also updates the related information actively if there is any 179 change. 181 o Discovering: To support the service and neighbor vehicle discovery 182 in the dynamic and fragmentation-possible environment in VANET, 183 different query modes of mDNS can be used for different scenarios: 184 1) One-Short Multicast DNS Query can be used to locate a specific 185 service (for example). 2) Continuous Multicast DNS Query can be 186 used to locate the nearby vehicles which are moving (for example). 188 o Refreshing: After the neighbor discovery illustrated above, the 189 vehicles should continually exchange their name, IP address and 190 geo-location information in order to refresh the established 191 communications. For example, the Multiple Questions Multicast 192 Responses can be used to update the caches of receivers 193 efficiently and Multiple Questions Unicast Responses can be used 194 to support the fast bootstrapping when new vehicle joins. 196 o Goodbye: When the vehicle arrives at its destination, stalls 197 temporarily or shuts down its communication or sensing devices, it 198 will announce the service suspending and its inexistence with 199 unsolicited multicast DNS response packet, giving the same RRs 200 (containing its name and address), but TTL of zero. 202 6. Mobility support 204 During the movement of the vehicle, it may cross different RUSes. 205 When attaching into a new RSU, the new domain prefix and new IP 206 prefix may be learned. Generally, there are two main cases for the 207 mobility: 209 o Name prefix changes and IP prefix remains, as shown in Figure 1, 210 the vehicle hands over from RSU1 to RSU2. The vehicle will 211 configure new name from RSU2 and update the new name in the local 212 database (e.g., RSU). But the vehicle should keep its previous 213 name for a period until that all the communicating neighbors learn 214 its new name. During this period, the vehicle will contain both 215 previous and new domain names in the DNS response message. 217 o Both name and IP prefixes change, as shown in Figure 1, the 218 vehicle hands over from RSU2 to RSU3. The vehicle will configure 219 new name and new IP address from RSU3 and update the IP address 220 (and the name) in the local database, in addition, IP-layer 221 mobility management protocols may be used to maintain the IP 222 connectivity in this case. 224 7. Signaling messages 226 To facilitate the further communication, the link-layer address and 227 geo-information may be included in the DNS message in a piggyback 228 manner. Otherwise, these information may be obtained through the 229 following NDP or other procedures. 231 8. Security considerations 233 In order to reduce the DNS traffic on the wireless link and avoid the 234 unnecessary flooding, the related schemes in mDNS can be used, such 235 as: Known-Answer Suppression, Multipacket Known-Answer Suppression, 236 Duplicate Question Suppression and Duplicate Answer Suppression. 238 In order to guarantee the origination of the DNS message and avoid 239 the DNS message tampering, the security consideration in mDNS should 240 also be adopted. 242 9. References 244 9.1. Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., 252 and P. Gentric, "RTP Payload Format for Transport of 253 MPEG-4 Elementary Streams", RFC 3640, 254 DOI 10.17487/RFC3640, November 2003, 255 . 257 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 258 "IPv6 Router Advertisement Options for DNS Configuration", 259 RFC 6106, DOI 10.17487/RFC6106, November 2010, 260 . 262 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 263 DOI 10.17487/RFC6762, February 2013, 264 . 266 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 267 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 268 . 270 9.2. Informative References 272 [DNS-Autoconf] 273 Jeong, J., Lee, S., and J. Park, "DNS Name 274 Autoconfiguration for Internet of Things Devices", draft- 275 jeong-ipwave-iot-dns-autoconf-00, March 2017. 277 [MNPP] Lee, J., Tsukada, M., and T. Ernst, "Mobile Network Prefix 278 Provisioning", draft-jhlee-mext-mnpp-00, October 2009. 280 Authors' Addresses 282 Zhiwei Yan 283 CNNIC 284 No.4 South 4th Street, Zhongguancun 285 Beijing 100190 286 China 288 EMail: yan@cnnic.cn 289 Jong-Hyouk Lee 290 Sangmyung University 291 31, Sangmyeongdae-gil, Dongnam-gu 292 Cheonan 293 Republic of Korea 295 EMail: jonghyouk@smu.ac.kr