idnits 2.17.1 draft-jeong-ipwave-iot-dns-autoconf-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.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 246 has weird spacing: '...ntifier devic...' == Line 442 has weird spacing: '...ntifier devic...' -- The document date (May 7, 2020) is 1450 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) == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-14 ** Downref: Normative reference to an Informational draft: draft-ietf-ipwave-vehicular-networking (ref. 'ID-IPWAVE-PS') ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) Summary: 4 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 J. Jeong 3 Internet-Draft Sungkyunkwan University 4 Intended status: Standards Track S. Lee 5 Expires: November 8, 2020 Ericsson-LG 6 J. Park 7 ETRI 8 May 7, 2020 10 DNS Name Autoconfiguration for Internet-of-Things Devices in IP-Based 11 Vehicular Networks 12 draft-jeong-ipwave-iot-dns-autoconf-08 14 Abstract 16 This document specifies an autoconfiguration scheme for device 17 discovery and service discovery in IP-based vehicular networks. 18 Through the device discovery, this document supports the global (or 19 local) DNS naming of Internet-of-Things (IoT) devices, such as 20 sensors, actuators, and in-vehicle units. By this scheme, the DNS 21 name of an IoT device can be autoconfigured with the device's model 22 information in wired and wireless target networks (e.g., vehicle, 23 road network, home, office, shopping mall, and smart grid). Through 24 the service discovery, IoT users (e.g., drivers, passengers, home 25 residents, and customers) in the Internet (or local network) can 26 easily identify each device for monitoring and remote-controlling it 27 in a target network. 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 November 8, 2020. 46 Copyright Notice 48 Copyright (c) 2020 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 1.1. Applicability Statements . . . . . . . . . . . . . . . . 4 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. DNS Name Autoconfiguration . . . . . . . . . . . . . . . . . 5 69 5.1. DNS Name Format with Object Identifier . . . . . . . . . 5 70 5.2. Procedure of DNS Name Autoconfiguration . . . . . . . . . 6 71 5.2.1. DNS Name Generation . . . . . . . . . . . . . . . . . 6 72 5.2.2. DNS Name Registration . . . . . . . . . . . . . . . . 7 73 5.2.3. DNS Name Retrieval . . . . . . . . . . . . . . . . . 9 74 6. Location-Aware DNS Name Configuration . . . . . . . . . . . . 9 75 7. Macro-Location-Aware DNS Name . . . . . . . . . . . . . . . . 11 76 8. Micro-Location-Aware DNS Name . . . . . . . . . . . . . . . . 11 77 9. DNS Name Management for Mobile IoT Devices . . . . . . . . . 11 78 10. Device Discovery for IoT Devices . . . . . . . . . . . . . . 12 79 11. Service Discovery for IoT Devices . . . . . . . . . . . . . . 12 80 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 82 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 83 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 15.1. Normative References . . . . . . . . . . . . . . . . . . 13 85 15.2. Informative References . . . . . . . . . . . . . . . . . 14 86 Appendix A. Changes from draft-jeong-ipwave-iot-dns-autoconf-07 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 Many Internet-of-Things (IoT) devices (e.g., sensors, actuators, and 92 in-vehicle units) have begun to have wireless communication 93 capability (e.g., WiFi, Bluetooth, and ZigBee) for monitoring and 94 remote-controlling in a local network or the Internet. According to 95 the capacity, such IoT devices can be categorized into high-capacity 96 devices and low-capacity devices. High-capacity devices have a high- 97 power processor and a large storage, such as vehicles, road 98 infrastructure devices (e.g., road-side unit, traffic light, and 99 loop-detector), appliances (e.g., television, refrigerator, air 100 conditioner, and washing machine), and smart devices (smartphone and 101 tablet). They are placed in environments (e.g., vehicle, road 102 network, home, office, shopping mall, and smart grid) for the direct 103 use for human users, and they require the interaction with human 104 users. Low-capacity devices have a low-power processor and a small 105 storage, such as sensors (e.g., in-vehicle units, light sensor, 106 meter, and fire detector) and actuators (e.g., vehicle engine, signal 107 light, street light, and room temperature controller). They are 108 installed for the easy management of environments (e.g., vehicle, 109 road network, home, office, store, and factory), and they do not 110 require the interaction with human users. 112 For the Internet connectivity of IoT devices, a variety of parameters 113 (e.g., address prefixes, default routers, and DNS servers) can be 114 automatically configured by Neighbor Discovery (ND) for IP Version 6, 115 IPv6 Stateless Address Autoconfiguration, and IPv6 Router 116 Advertisement (RA) Options for DNS Configuration [RFC4861][RFC4862] 117 [RFC8106]. 119 For these IoT devices, the manual configuration of DNS names will be 120 cumbersome and time-consuming as the number of them increases rapidly 121 in a network. It will be good for such DNS names to be automatically 122 configured such that they are readable to human users. 124 Multicast DNS (mDNS) in [RFC6762] can provide DNS service for 125 networked devices on a local link (e.g., home network and office 126 network) without any conventional recursive DNS server. mDNS also 127 supports the autoconfiguration of a device's DNS name without the 128 intervention of the user. mDNS aims at the DNS naming service for 129 the local DNS names of the networked devices on the local link rather 130 than the DNS naming service for the global DNS names of such devices 131 in the Internet. However, for IoT devices accessible from the 132 Internet, mDNS cannot be used. Thus, a new autoconfiguration scheme 133 becomes required for the global DNS names of IoT devices. 135 This document proposes an autoconfiguration scheme for the global (or 136 local) DNS names of IoT devices in IP-based vehicular networks. 137 Since an autoconfigured DNS name contains the model identifier (ID) 138 of a device, IoT users in the Internet (or local network) can easily 139 identify such a device. The autoconfigured DNS names and the 140 corresponding IP addresses of the IoT devices are registered with 141 local or remote authoritative DNS servers that manage the DNS 142 suffixes of the DNS domain names. With these DNS names, they will be 143 able to monitor and remote-control their IoT devices with their smart 144 devices (e.g., smartphone and tablet PC) by resolving their DNS names 145 into the corresponding IP addresses. 147 For cloud-based DNS naming services of IoT devices, a cloud server 148 can collect DNS zone files having the global DNS names and IP 149 addresses of the IoT devices from multiple DNS servers and provide 150 IoT users with such global DNS names of IoT devices relevant to the 151 IoT users. These IoT users can monitor and remote-control their IoT 152 devices in the Internet with the global DNS names and IP addresses, 153 using their smart devices. 155 1.1. Applicability Statements 157 It is assumed that IoT devices have networking capability through 158 wired or wireless communication media, such as Ethernet [IEEE-802.3], 159 WiFi [IEEE-802.11][IEEE-802.11a][IEEE-802.11b][IEEE-802.11g] 160 [IEEE-802.11n], Dedicated Short-Range Communications (DSRC) 161 [DSRC-WAVE][IEEE-802.11p], Bluetooth [IEEE-802.15.1], and ZigBee 162 [IEEE-802.15.4] in a local area network (LAN) or personal area 163 network (PAN). Note that IEEE 802.11p was renamed IEEE 802.11 164 Outside the Context of a Basic Service Set [IEEE-802.11-OCB] in 2012. 165 IPv6 packet delivery over an IEEE 802.11-OCB link is defined in 166 [RFC8691]. 168 Also, it is assumed that each IoT device has a factory configuration 169 (called device configuration) having device model information by 170 manufacturer ID and model ID (e.g., vehicle, road-side unit, smart 171 TV, smartphone, tablet, and refrigerator). This device configuration 172 can be read by the device for DNS name autoconfiguration. 174 2. Requirements Language 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119 [RFC2119]. 180 3. Terminology 182 This document uses the terminology described in [RFC4861] and 183 [RFC4862]. In addition, four new terms are defined below: 185 o Device Configuration: A factory configuration that has device 186 model information by manufacturer ID and model ID (e.g., vehicle, 187 road-side unit, smart TV, smartphone, tablet, and refrigerator). 189 o DNS Search List (DNSSL): The list of DNS suffix domain names used 190 by IPv6 hosts when they perform DNS query searches for short, 191 unqualified domain names [RFC8106]. 193 o DNSSL Option: IPv6 RA option to deliver the DNSSL information to 194 IPv6 hosts [RFC8106]. 196 4. Overview 198 This document specifies an autoconfiguration scheme for an IoT device 199 using device configuration and DNS search list. Device configuration 200 has device model information (e.g., device's manufacturer and model). 201 DNS search list has DNS suffix domain names that represent the DNS 202 domains of a network having the IoT device [RFC8106]. 204 As an IPv6 host, the IoT device can obtain DNS search list through 205 IPv6 Router Advertisement (RA) with DNS Search List (DNSSL) Option 206 [RFC4861][RFC8106] or DHCPv6 with Domain Search List Option 207 [RFC3315][RFC3736][RFC3646]. 209 The IoT device can construct its DNS name with the concatenation of 210 manufacturer ID, model ID, and domain name. Since there exist more 211 than one device with the same model, the DNS name should have a 212 unique identification (e.g., unique ID or serial ID) to differentiate 213 multiple devices with the same model. 215 Since both RA and DHCPv6 can be simultaneously used for the parameter 216 configuration for IPv6 hosts, this document considers the DNS name 217 autoconfiguration in the coexistence of RA and DHCP. 219 5. DNS Name Autoconfiguration 221 The DNS name autoconfiguration for an IoT device needs the 222 acquisition of DNS search list through either RA [RFC8106] or DHCPv6 223 [RFC3646]. Once the DNS search list is obtained, the IoT device 224 autonomously constructs its DNS name(s) with the DNS search list and 225 its device information. 227 5.1. DNS Name Format with Object Identifier 229 A DNS name for an IoT device can have the following format with 230 object identifier (OID), which is defined in [oneM2M-OID], as in 231 Figure 1: 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | unique_id.object_identifier.OID.domain_name | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 1: IoT Device DNS Name Format with OID 239 Fields: 241 unique_id unique identifier to guarantee the uniqueness 242 of the DNS name in ASCII characters. The 243 identifier MAY be alphanumeric with readability, 244 e.g., product name plus a sequence number. 246 object_identifier device's object identifier that consists of a 247 higher arc, that is, M2M node indication ID 248 (i.e., the concatenation of the managing 249 organization, administration, data country 250 code, and M2M node) and a sequence of four 251 arcs (i.e., manufacturer ID, model ID, serial 252 ID, and expanded ID) as defined in 253 [oneM2M-OID]. The fields are seperated by an 254 underscore '_'. 256 OID subdomain for the keyword of OID to indicate 257 that object_identifier is used. 259 domain_name domain name that represents a DNS domain for 260 the network having the IoT devices. 262 Note each subdomain (i.e., unique_id, object_identifier, OID, and 263 domain_name) in the domain name format in Figure 1 is expressed using 264 the name syntax described in [RFC1035]. 266 5.2. Procedure of DNS Name Autoconfiguration 268 The procedure of DNS name autoconfiguration is performed through a 269 DNSSL option delivered by either RA [RFC8106] or DHCPv6 [RFC3646]. 271 5.2.1. DNS Name Generation 273 When as an IPv6 host a device receives a DNSSL option through either 274 RA or DHCPv6, it checks the validity of the DNSSL option. If the 275 option is valid, the IPv6 host performs the DNS name 276 autoconfiguration with each DNS suffix domain name in the DNSSL 277 option as follows: 279 1. The host constructs its DNS name with the DNS suffix domain name 280 along with device configuration (i.e., manufacturer ID, model ID, 281 and serial ID) and a selected identifier (as unique_id) that is 282 considered unique, which is human-friendly, as shown in Figure 1. 284 2. The host constructs an IPv6 unicast address as a tentative 285 address with a 64-bit network prefix and the last 64 bits of the 286 MD5 hashed value of the above DNS name. 288 3. The host constructs the solicited-node multicast address in 289 [RFC4861] corresponding to the tentative IPv6 address. 291 4. The host performs Duplicate Address Detection (DAD) for the IPv6 292 address with the solicited-node multicast address [RFC4861] 293 [RFC4862]. 295 5. If there is no response from the DAD, the host sets the IPv6 296 tentative address as its IPv6 unicast address and regards the 297 constructed DNS name as unique on the local link. Otherwise, 298 since the DAD fails because of DNS name conflict, go to Step 1 299 for a new DNS name generation with another identifier for 300 unique_id. 302 6. Since the DNS name is proven to be unique, it is used as the 303 device's DNS name and the DNS autoconfiguration is done for the 304 given DNS suffix domain name. Also, the host joins the 305 solicited-node multicast address for the verified DNS name in 306 order to prevent other hosts from using this DNS name. 308 When the DNS search list has more than one DNS suffix domain name, 309 the IPv6 host repeats the above procedure until all of the DNS 310 suffixes are used for the DNS name autoconfiguration along with the 311 IPv6 unicast autoconfiguration corresponding to the DNS name. 313 5.2.2. DNS Name Registration 315 Once as IPv6 hosts the devices have autoconfigured their DNS names, 316 as a collector, any IPv6 node (i.e., router or host) in the same 317 subnet can collect the device DNS names using IPv6 Node Information 318 (NI) protocol [RFC4620]. 320 For a collector to collect the device DNS names without any prior 321 node information, a new NI query needs to be defined. That is, a new 322 ICMPv6 Code (e.g., 3) SHOULD be defined for the collection of the 323 IPv6 host DNS names. The Data field is not included in the ICMPv6 324 header since the NI query is for all the IPv6 hosts in the same 325 subnet. The Qtype field for NI type is set to 2 for Node Name. 327 The query SHOULD be transmitted by the collector to a link-local 328 multicast address for this NI query. Assume that a link-local scope 329 multicast address (e.g., all-nodes multicast address, FF02::1) SHOULD 330 be defined for device DNS name collection such that all the IPv6 331 hosts join this link-local multicast address for the device DNS name 332 collection service. 334 When an IPv6 host receives this query sent by the collector in 335 multicast, it transmits its Reply with its DNS name with a random 336 interval between zero and Query Response Interval, as defined by 337 Multicast Listener Discovery Version 2 [RFC3810]. This randomly 338 delayed Reply allows the collector to collect the device DNS names 339 with less frame collision probability by spreading out the Reply time 340 instants. 342 After the collector collects the device DNS names, it resolves the 343 DNS names into the corresponding IPv6 addresses by NI protocol 344 [RFC4620] with the ICMPv6 Code 1 of NI Query. This code indicates 345 that the Data field of the NI Query has the DNS name of an IoT 346 device. The IoT device that receives this NI query sends the 347 collector an NI Reply with its IPv6 address in the Data field. 349 For DNS name resolution service, the collector can register the 350 pair(s) of DNS name and IPv6 address for each IPv6 host with an 351 appropriate designated DNS server for the DNS domain suffix of the 352 DNS name. It is assumed that the collector is configured to register 353 DNS names with the designated DNS server in a secure way based on 354 DNSSEC [RFC4033][RFC6840]. This registration of the DNS name and 355 IPv6 address can be performed by DNS dynamic update [RFC2136]. 356 Before registering the DNS name with the designated DNS server, the 357 collector SHOULD verify the uniqueness of the DNS name in the 358 intended DNS domain by sending a DNS query for the resolution of the 359 DNS name. If there is no corresponding IPv6 address for the queried 360 DNS name, the collector registers the DNS name and the corresponding 361 IPv6 address for each IPv6 host with the designated DNS server. On 362 the other hand, if there is such a corresponding IPv6 address, the 363 DNS name is regarded as duplicate (i.e., not unique), and so the 364 corresponder notifies the corresponding IoT device with the duplicate 365 DNS name of an error message of DNS name duplication using NI 366 protocol. When an IoT device receives such a DNS name duplication 367 error, it needs to construct a new DNS name and repeats the procedure 368 of device DNS name generation along with the uniqueness test of the 369 device DNS name in its subnet. 371 The two separate procedures of the DNS name collection and IPv6 372 address resolution in the above NI protocol can be consolidated into 373 a single collection for the pairs of DNS names and the corresponding 374 IPv6 addresses. For such an optimization, a new ICMPv6 Code (e.g., 375 4) is defined for the NI Query to query the pair of a DNS name and 376 the corresponding IPv6 address. With this code, the collector can 377 collect the pairs of each IoT device's DNS name and IPv6 address in 378 one NI query message rather than two NI query messages. 380 For DNS name registration of IoT devices as IPv6 hosts, DHCPv6 381 [RFC3315] can be used instead of the NI protocol. For this purpose, 382 a new DHCP option (called DNSNA option) needs to be defined to 383 collect the pair of a DNS name and the corresponding IPv6 address of 384 an IoT device. As a DNS information collector, a DHCPv6 server (or a 385 router running a DHCPv6 server) sends a request message for the DHCP 386 DNSNA option to IoT devices as its DHCPv6 clients under its address 387 pool. The clients respond to this request message by sending the 388 DHCPv6 server a reply message with their DNS information. Thus, the 389 DHCPv6 server can collect the pairs of DNS names and the 390 corresponding IPv6 addresses of the IoT devices. Then, as a 391 collector, the DHCPv6 server can register the DNS names and the 392 corresponding IPv6 addresses of IoT devices with the designated DNS 393 server. 395 To allow only a legitimate IoT device to register its DNS name and 396 IPv6 address with the designated DNS server via a router (or DHCPv6 397 server), the IoT device can sign its registration message with its 398 private key through a digital signature, and the router (or DHCPv6 399 server) can verify the message with the IoT device's public key. For 400 the detailed authentication based on a digital signature, refer to 401 [DNSNA-FGCS]. 403 5.2.3. DNS Name Retrieval 405 For device discovery, a smart device (e.g., smartphone) can retrieve 406 the DNS names of IoT devices by contacting a global (or local) DNS 407 server having the IoT device DNS names. If the smart device can 408 retrieve the zone file with the DNS names, it can display the 409 information of IoT devices in a target network, such as a vehicle's 410 internal network, home network, and office network. With this 411 information, the user can monitor and control the IoT devices in the 412 Internet (or local network). To monitor or remote-control IoT 413 devices, Constrained Application Protocol (CoAP) can be used 414 [RFC7252]. 416 6. Location-Aware DNS Name Configuration 418 If the DNS name of an IoT device includes location information, it 419 allows users to easily identify the physical location of each device. 420 This document proposes the representation of a location in a DNS 421 name. In this document, the location in a DNS name consists of two 422 levels for a detailed location specification, such as macro-location 423 for a large area and micro-location for a small area. 425 To denote both macro-location (i.e., mac_loc) and micro-location 426 (i.e., mic_loc) into a DNS name, the following format is described as 427 in Figure 2: 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | unique_id.object_identifier.OID.mic_loc.mac_loc.LOC.domain_name | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 2: Location-Aware Device DNS Name Format 435 Fields: 437 unique_id unique identifier to guarantee the uniqueness 438 of the DNS name in ASCII characters. The 439 identifier MAY be alphanumeric with readability, 440 such as product name plus a sequence number. 442 object_identifier device's object identifier that consists of a 443 higher arc, that is, M2M node indication ID 444 (i.e., the concatenation of the managing 445 organization, administration, data country 446 code, and M2M node) and a sequence of four 447 arcs (i.e., manufacturer ID, model ID, serial 448 ID, and expanded ID) as defined in 449 [oneM2M-OID]. The fields are seperated by an 450 underscore '_'. 452 OID subdomain for the keyword of OID to indicate 453 that object_identifier is used. 455 mic_loc device's micro-location, such as an offset in a 456 road segment and coordinates in 2-dimensional 457 (or 3-dimensional) space. 459 mac_loc device's macro-location, such as a road 460 segment and 2-dimensional (or 3-dimensional) 461 space. 463 LOC subdomain for the keyword of LOC to indicate 464 that mac_loc and mic_loc are used. 466 domain_name domain name that represents a DNS domain for 467 the network having the IoT devices. 469 Note each subdomain (e.g., mic_loc and mac_loc) in the domain name 470 format in Figure 2 is expressed using the name syntax described in 471 [RFC1035]. 473 7. Macro-Location-Aware DNS Name 475 If location information (such as cross area, intersection, and road 476 segment in a road network) is available to an IoT device, a keyword, 477 coordinate, or location ID for the location information can be used 478 to construct a DNS name as subdomain name. This location information 479 lets users track the position of mobile devices (such as vehicle, 480 smartphone, and tablet). The physical location of the device is 481 defined as macro-location for DNS naming. 483 A subdomain name for macro-location (denoted as mac_loc) MAY be 484 placed between micro-location (denoted as mic_loc) and the keyword 485 LOC of the DNS name format in Figure 2. For the localization of 486 macro-location, a localization scheme for indoor or outdoor can be 487 used [SALA]. 489 8. Micro-Location-Aware DNS Name 491 An IoT device can be located in the center or edge in a place that is 492 specified by macro-location. For example, assume that a loop- 493 detector is located in the start or end position of a road segment. 494 If the DNS name for the loop-detector contains the start or end 495 position of the road segment, a road network administrator can find 496 it easily. In this document, for this DNS naming, the detailed 497 location for an IoT device can be specified as a micro-location 498 subdomain name. 500 A subdomain name for micro-location (denoted as mic_loc) MAY be 501 placed between the keyword OID and macro-location (denoted as 502 mac_loc) of the DNS name format in Figure 2. For the localization of 503 micro-location, a localization scheme for indoor or outdoor can be 504 used [SALA]. 506 9. DNS Name Management for Mobile IoT Devices 508 Some IoT devices can have mobility, such as vehicle, smartphone, 509 tablet, laptop computer, and cleaning robot. This mobility allows 510 the IoT devices to move from a subnet to another subnet where subnets 511 can have different domain suffixes, such as 512 coordinate.road_segment.road, coordinate.intersection.road, 513 living_room.home and garage.home. The DNS name change (or addition) 514 due to the mobility should be considered. 516 To deal with DNS name management in mobile environments, whenever an 517 IoT device enters a new subnet and receives DNS suffix domain names, 518 it generates its new DNS names and registers them with a designated 519 DNS server, specified by RDNSS option. 521 When the IoT device recognizes the movement to another subnet, it can 522 delete its previous DNS name(s) from the DNS server having the DNS 523 name(s), using DNS dynamic update [RFC2136]. For at least one DNS 524 name to remain in a DNS server for the location management in Mobile 525 IPv6 [RFC6275], the IoT device does not delete its default DNS name 526 in its home network in Mobile IPv6. 528 10. Device Discovery for IoT Devices 530 DNSNA can facilitate the device discovery of a user for IoT devices 531 using a global (or local) DNS server having the IoT device DNS 532 information, as discussed in Section 5.2.3. This device discovery 533 based on unicast outperforms mDNS [RFC6762] using multicast in terms 534 of the discovery speed and the network bandwidth usage for discovery. 536 For example, a vehicle can have its own internal network having in- 537 vehicle devices (e.g., Electronic Control Units (ECUs) such as engine 538 control module, powertrain control module, transmission control 539 module, and brake control module). When the vehicle's internal 540 network is constructed by the Ethernet, those ECUs can autoconfigure 541 their DNS names with the DNSNA and register them with the vehicle's 542 local DNS server [ID-IPWAVE-PS]. The local DNS server can register 543 them with a global DNS server accessible by the automotive service 544 center to monitor and make on-line diagnosis on them. 546 11. Service Discovery for IoT Devices 548 DNS SRV resource record (RR) can be used to support the service 549 discovery of the services provided by IoT devices [RFC2782]. This 550 SRV RR specifies a service name, a transport layer protocol, the 551 corresponding port number, and an IP address of a process running in 552 an IP host as a server to provide a service. An instance for a 553 service can be specified in this SRV RR in DNS-based service 554 discovery [RFC6763]. After the DNS name registration in Section 5.2, 555 IoT devices can register their services with the DNS server via a 556 router with DNS SRV RRs for their services. 558 After the service registration, an IoT user can retrieve services 559 available in his/her target network through service discovery, which 560 can fetch the SRV RRs from the DNS server in the target network. 561 Once (s)he retrieves the list of the SRV RRs, (s)he can monitor or 562 remote-control the devices or their services by using the known 563 protocols and domain information of the devices or their services. 564 For this monitoring or remote-controlling of IoT devices, Constrained 565 Application Protocol (CoAP) can be used [RFC7252]. 567 12. Security Considerations 569 This document shares all the security issues of the NI protocol that 570 are specified in the "Security Considerations" section of [RFC4620]. 572 To prevent the disclosure of location information for privacy 573 concern, the subdomains related to location can be encrypted by a 574 shared key or public-and-private keys. For example, a DNS name of 575 vehicle1.oid1.OID.coordinate1.road_segment_id1.LOC.road can be 576 represented as vehicle1.oid1.OID.xxx.yyy.LOC.road where vehicle1 is 577 unique ID, oid1 is object ID, xxx is a string of the encrypted 578 representation of the coordinate (denoted as coordinate1) in a road 579 segment, and yyy is a string of the encrypted representation of the 580 road segment ID (denoted as road_segment_id1). Thus, the location of 581 the vehicle1 can be protected from unwanted users by encryption. 583 13. Acknowledgments 585 This work was supported by Basic Science Research Program through the 586 National Research Foundation of Korea (NRF) funded by the Ministry of 587 Education (2017R1D1A1B03035885). 589 This work was supported by the MSIT (Ministry of Science and ICT), 590 Korea, under the ITRC (Information Technology Research Center) 591 support program (IITP-2019-2017-0-01633) supervised by the IITP 592 (Institute for Information & communications Technology Promotion). 594 14. Contributors 596 This document is the group work of IPWAVE working group. This 597 document has the following contributing authors considered co- 598 authors: 600 o Keuntae Lee (Sungkyunkwan University) 602 o Seokhwa Kim (Sungkyunkwan University) 604 15. References 606 15.1. Normative References 608 [ID-IPWAVE-PS] 609 Jeong, J., Ed., "IPv6 Wireless Access in Vehicular 610 Environments (IPWAVE): Problem Statement and Use Cases", 611 draft-ietf-ipwave-vehicular-networking-14 (work in 612 progress), March 2020. 614 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 615 Specification", RFC 1035, November 1987. 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, March 1997. 620 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 621 C., and M. Carney, "Dynamic Host Configuration Protocol 622 for IPv6 (DHCPv6)", RFC 3315, July 2003. 624 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 625 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 626 December 2003. 628 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 629 (DHCP) Service for IPv6", RFC 3736, April 2004. 631 [RFC4033] Arends, R., Ed., Austein, R., Larson, M., Massey, D., and 632 S. Rose, "DNS Security Introduction and Requirements", 633 RFC 4033, March 2005. 635 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 636 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 637 September 2007. 639 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 640 Address Autoconfiguration", RFC 4862, September 2007. 642 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 643 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 644 February 2013. 646 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 647 "IPv6 Router Advertisement Options for DNS Configuration", 648 RFC 8106, March 2017. 650 [RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic 651 Support for IPv6 Networks Operating Outside the Context of 652 a Basic Service Set over IEEE Std 802.11", RFC 8691, 653 December 2019. 655 15.2. Informative References 657 [DNSNA-FGCS] 658 Lee, K., Kim, S., Jeong, J., Lee, S., Kim, H., and J. 659 Park, "A Framework for DNS Naming Services for Internet- 660 of-Things Devices", Elsevier Future Generation Computer 661 Systems, Vol. 92, March 2019. 663 [DSRC-WAVE] 664 Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its 665 Architecture, Design, and Characteristics", 666 IEEE Communications Surveys & Tutorials, 12(4), 2012. 668 [IEEE-802.11] 669 "Part 11: Wireless LAN Medium Access Control (MAC) and 670 Physical Layer (PHY) Specifications", March 2012. 672 [IEEE-802.11-OCB] 673 "Part 11: Wireless LAN Medium Access Control (MAC) and 674 Physical Layer (PHY) Specifications", IEEE Std 675 802.11-2016, December 2016. 677 [IEEE-802.11a] 678 "Part 11: Wireless LAN Medium Access Control (MAC) and 679 Physical Layer (PHY) specifications - High-speed Physical 680 Layer in the 5 GHZ Band", September 1999. 682 [IEEE-802.11b] 683 "Part 11: Wireless LAN Medium Access Control (MAC) and 684 Physical Layer (PHY) specifications - Higher-Speed 685 Physical Layer Extension in the 2.4 GHz Band", September 686 1999. 688 [IEEE-802.11g] 689 "Part 11: Wireless LAN Medium Access Control (MAC) and 690 Physical Layer (PHY) specifications - Further Higher Data 691 Rate Extension in the 2.4 GHz Band", April 2003. 693 [IEEE-802.11n] 694 "Part 11: Wireless LAN Medium Access Control (MAC) and 695 Physical Layer (PHY) specifications - Amendment 5: 696 Enhancements for Higher Throughput", March 2009. 698 [IEEE-802.11p] 699 "Part 11: Wireless LAN Medium Access Control (MAC) and 700 Physical Layer (PHY) Specifications - Amendment 6: 701 Wireless Access in Vehicular Environments", July 2010. 703 [IEEE-802.15.1] 704 "Part 15.1: Wireless Medium Access Control (MAC) and 705 Physical Layer (PHY) specifications for Wireless Personal 706 Area Networks (WPANs)", June 2005. 708 [IEEE-802.15.4] 709 "Part 15.4: Low-Rate Wireless Personal Area Networks (LR- 710 WPANs)", September 2011. 712 [IEEE-802.3] 713 "IEEE Standard for Ethernet", December 2012. 715 [oneM2M-OID] 716 "Object Identifier based M2M Device Identification 717 Scheme", February 2014. 719 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 720 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 721 RFC 2136, April 1997. 723 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 724 specifying the location of services (DNS SRV)", RFC 2782, 725 February 2000. 727 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 728 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 730 [RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information 731 Queries", RFC 4620, August 2006. 733 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 734 Support in IPv6", RFC 6275, July 2011. 736 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 737 February 2013. 739 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 740 Discovery", RFC 6763, February 2013. 742 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 743 Application Protocol (CoAP)", RFC 7252, June 2014. 745 [SALA] Jeong, J., Yeon, S., Kim, T., Lee, H., Kim, S., and S. 746 Kim, "SALA: Smartphone-Assisted Localization Algorithm for 747 Positioning Indoor IoT Devices", Springer Wireless 748 Networks, Vol. 24, No. 1, January 2018. 750 Appendix A. Changes from draft-jeong-ipwave-iot-dns-autoconf-07 752 The following changes are made from draft-jeong-ipwave-iot-dns- 753 autoconf-07: 755 o This version has a submission date update to maintain the active 756 status of the draft. 758 o This version updates the version numbers of the referenced drafts. 760 Authors' Addresses 762 Jaehoon Paul Jeong 763 Department of Computer Science and Engineering 764 Sungkyunkwan University 765 2066 Seobu-Ro, Jangan-Gu 766 Suwon, Gyeonggi-Do 16419 767 Republic of Korea 769 Phone: +82 31 299 4957 770 Fax: +82 31 290 7996 771 EMail: pauljeong@skku.edu 772 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 774 Sejun Lee 775 Ericsson-LG 776 77, Heungan-Daero 81 Beon-Gil, Dongan-Gu 777 Anyang-Si, Gyeonggi-Do 14117 778 Republic of Korea 780 Phone: +82 31 450 4099 781 EMail: prosejun14@gmail.com 783 Jung-Soo Park 784 Electronics and Telecommunications Research Institute 785 218 Gajeong-Ro, Yuseong-Gu 786 Daejeon 34129 787 Republic of Korea 789 Phone: +82 42 860 6514 790 EMail: pjs@etri.re.kr