idnits 2.17.1 draft-jeong-ipwave-iot-dns-autoconf-12.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 248 has weird spacing: '...ntifier devic...' == Line 444 has weird spacing: '...ntifier devic...' -- The document date (21 February 2022) is 793 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-26 ** Downref: Normative reference to an Informational draft: draft-ietf-ipwave-vehicular-networking (ref. 'ID-IPWAVE-PS') 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, Ed. 3 Internet-Draft J. Ahn 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: 25 August 2022 S. Lee 6 Ericsson-LG 7 J. Park 8 ETRI 9 21 February 2022 11 DNS Name Autoconfiguration for Internet-of-Things Devices in IP-Based 12 Vehicular Networks 13 draft-jeong-ipwave-iot-dns-autoconf-12 15 Abstract 17 This document specifies an autoconfiguration scheme for device 18 discovery and service discovery in IP-based vehicular networks. 19 Through the device discovery, this document supports the global (or 20 local) DNS naming of Internet-of-Things (IoT) devices, such as 21 sensors, actuators, and in-vehicle units. By this scheme, the DNS 22 name of an IoT device can be autoconfigured with the device's model 23 information in wired and wireless target networks (e.g., vehicle, 24 road network, home, office, shopping mall, and smart grid). Through 25 the service discovery, IoT users (e.g., drivers, passengers, home 26 residents, and customers) in the Internet (or local network) can 27 easily identify each device for monitoring and remote-controlling it 28 in a target network. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 25 August 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Applicability Statements . . . . . . . . . . . . . . . . 4 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. DNS Name Autoconfiguration . . . . . . . . . . . . . . . . . 5 69 5.1. DNS Name Format with Object Identifier . . . . . . . . . 6 70 5.2. Procedure of DNS Name Autoconfiguration . . . . . . . . . 6 71 5.2.1. DNS Name Generation . . . . . . . . . . . . . . . . . 7 72 5.2.2. DNS Name Registration . . . . . . . . . . . . . . . . 7 73 5.2.3. DNS Name Retrieval . . . . . . . . . . . . . . . . . 10 74 6. Location-Aware DNS Name Configuration . . . . . . . . . . . . 10 75 7. Macro-Location-Aware DNS Name . . . . . . . . . . . . . . . . 11 76 8. Micro-Location-Aware DNS Name . . . . . . . . . . . . . . . . 12 77 9. DNS Name Management for Mobile IoT Devices . . . . . . . . . 12 78 10. Device Discovery for IoT Devices . . . . . . . . . . . . . . 13 79 11. Service Discovery for IoT Devices . . . . . . . . . . . . . . 13 80 12. IoT Cloud for IoT Device Management . . . . . . . . . . . . . 13 81 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 83 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 84 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 16.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 16.2. Informative References . . . . . . . . . . . . . . . . . 16 87 Appendix A. Changes from 88 draft-jeong-ipwave-iot-dns-autoconf-11 . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 Many Internet-of-Things (IoT) devices (e.g., sensors, actuators, and 94 in-vehicle units) have begun to have wireless communication 95 capability (e.g., WiFi, Bluetooth, and ZigBee) for monitoring and 96 remote-controlling in a local network or the Internet. According to 97 the capacity, such IoT devices can be categorized into high-capacity 98 devices and low-capacity devices. High-capacity devices have a high- 99 power processor and a large storage, such as vehicles, road 100 infrastructure devices (e.g., road-side unit, traffic light, and 101 loop-detector), appliances (e.g., television, refrigerator, air 102 conditioner, and washing machine), and smart devices (smartphone and 103 tablet). They are placed in environments (e.g., vehicle, road 104 network, home, office, shopping mall, and smart grid) for the direct 105 use for human users, and they require the interaction with human 106 users. Low-capacity devices have a low-power processor and a small 107 storage, such as sensors (e.g., in-vehicle units, light sensor, 108 meter, and fire detector) and actuators (e.g., vehicle engine, signal 109 light, street light, and room temperature controller). They are 110 installed for the easy management of environments (e.g., vehicle, 111 road network, home, office, store, and factory), and they do not 112 require the interaction with human users. 114 For the Internet connectivity of IoT devices, a variety of parameters 115 (e.g., address prefixes, default routers, and DNS servers) can be 116 automatically configured by Neighbor Discovery (ND) for IP Version 6, 117 IPv6 Stateless Address Autoconfiguration, and IPv6 Router 118 Advertisement (RA) Options for DNS Configuration [RFC4861][RFC4862] 119 [RFC8106]. 121 For these IoT devices, the manual configuration of DNS names will be 122 cumbersome and time-consuming as the number of them increases rapidly 123 in a network. It will be good for such DNS names to be automatically 124 configured such that they are readable to human users. 126 Multicast DNS (mDNS) in [RFC6762] can provide DNS service for 127 networked devices on a local link (e.g., home network and office 128 network) without any conventional recursive DNS server. mDNS also 129 supports the autoconfiguration of a device's DNS name without the 130 intervention of the user. mDNS aims at the DNS naming service for 131 the local DNS names of the networked devices on the local link rather 132 than the DNS naming service for the global DNS names of such devices 133 in the Internet. However, for IoT devices accessible from the 134 Internet, mDNS cannot be used. Thus, a new autoconfiguration scheme 135 becomes required for the global DNS names of IoT devices. 137 This document proposes a DNS Name Autoconfiguration (DNSNA) for the 138 global (or local) DNS names of IoT devices in IP-based vehicular 139 networks. Since an autoconfigured DNS name contains the model 140 identifier (ID) of a device, IoT users in the Internet (or local 141 network) can easily identify such a device. The autoconfigured DNS 142 names and the corresponding IP addresses of the IoT devices are 143 registered with local or remote authoritative DNS servers that manage 144 the DNS suffixes of the DNS domain names. With these DNS names, they 145 will be able to monitor and remote-control their IoT devices with 146 their smart devices (e.g., smartphone and tablet PC) by resolving 147 their DNS names into the corresponding IP addresses. 149 For cloud-based DNS naming services of IoT devices, a cloud server 150 can collect DNS zone files having the global DNS names and IP 151 addresses of the IoT devices from multiple DNS servers and provide 152 IoT users with such global DNS names of IoT devices relevant to the 153 IoT users. These IoT users can monitor and remote-control their IoT 154 devices in the Internet with the global DNS names and IP addresses, 155 using their smart devices. 157 1.1. Applicability Statements 159 It is assumed that IoT devices have networking capability through 160 wired or wireless communication media, such as Ethernet [IEEE-802.3], 161 WiFi [IEEE-802.11][IEEE-802.11a][IEEE-802.11b][IEEE-802.11g] 162 [IEEE-802.11n], Dedicated Short-Range Communications (DSRC) 163 [DSRC-WAVE][IEEE-802.11p], Bluetooth [IEEE-802.15.1], and ZigBee 164 [IEEE-802.15.4] in a local area network (LAN) or personal area 165 network (PAN). Note that IEEE 802.11p was renamed IEEE 802.11 166 Outside the Context of a Basic Service Set [IEEE-802.11-OCB] in 2012. 167 IPv6 packet delivery over an IEEE 802.11-OCB link is defined in 168 [RFC8691]. 170 Also, it is assumed that each IoT device has a factory configuration 171 (called device configuration) having device model information by 172 manufacturer ID and model ID (e.g., vehicle, road-side unit, smart 173 TV, smartphone, tablet, and refrigerator). This device configuration 174 can be read by the device for DNS name autoconfiguration. 176 2. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC 2119 [RFC2119]. 182 3. Terminology 184 This document uses the terminology described in [RFC4861] and 185 [RFC4862]. In addition, four new terms are defined below: 187 * Device Configuration: A factory configuration that has device 188 model information by manufacturer ID and model ID (e.g., vehicle, 189 road-side unit, smart TV, smartphone, tablet, and refrigerator). 191 * DNS Search List (DNSSL): The list of DNS suffix domain names used 192 by IPv6 hosts when they perform DNS query searches for short, 193 unqualified domain names [RFC8106]. 195 * DNSSL Option: IPv6 RA option to deliver the DNSSL information to 196 IPv6 hosts [RFC8106]. 198 4. Overview 200 This document specifies an autoconfiguration scheme for an IoT device 201 using device configuration and DNS search list. Device configuration 202 has device model information (e.g., device's manufacturer and model). 203 DNS search list has DNS suffix domain names that represent the DNS 204 domains of a network having the IoT device [RFC8106]. 206 As an IPv6 host, the IoT device can obtain DNS search list through 207 IPv6 Router Advertisement (RA) with DNS Search List (DNSSL) Option 208 [RFC4861][RFC8106] or DHCPv6 with Domain Search List Option 209 [RFC3315][RFC3736][RFC3646]. 211 The IoT device can construct its DNS name with the concatenation of 212 manufacturer ID, model ID, and domain name. Since there exist more 213 than one device with the same model, the DNS name should have a 214 unique identification (e.g., unique ID or serial ID) to differentiate 215 multiple devices with the same model. 217 Since both RA and DHCPv6 can be simultaneously used for the parameter 218 configuration for IPv6 hosts, this document considers the DNS name 219 autoconfiguration in the coexistence of RA and DHCP. 221 5. DNS Name Autoconfiguration 223 The DNS name autoconfiguration for an IoT device needs the 224 acquisition of DNS search list through either RA [RFC8106] or DHCPv6 225 [RFC3646]. Once the DNS search list is obtained, the IoT device 226 autonomously constructs its DNS name(s) with the DNS search list and 227 its device information. 229 5.1. DNS Name Format with Object Identifier 231 A DNS name for an IoT device can have the following format with 232 object identifier (OID), which is defined in [oneM2M-OID], as in 233 Figure 1: 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | unique_id.object_identifier.OID.domain_name | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 1: IoT Device DNS Name Format with OID 241 Fields: 243 unique_id unique identifier to guarantee the uniqueness 244 of the DNS name in ASCII characters. The 245 identifier MAY be alphanumeric with readability, 246 e.g., product name plus a sequence number. 248 object_identifier device's object identifier that consists of a 249 higher arc, that is, M2M node indication ID 250 (i.e., the concatenation of the managing 251 organization, administration, data country 252 code, and M2M node) and a sequence of four 253 arcs (i.e., manufacturer ID, model ID, serial 254 ID, and expanded ID) as defined in 255 [oneM2M-OID]. The fields are separated by an 256 underscore '_'. 258 OID subdomain for the keyword of OID to indicate 259 that object_identifier is used. 261 domain_name domain name that represents a DNS domain for 262 the network having the IoT devices. 264 Note each subdomain (i.e., unique_id, object_identifier, OID, and 265 domain_name) in the domain name format in Figure 1 is expressed using 266 the name syntax described in [RFC1035]. 268 5.2. Procedure of DNS Name Autoconfiguration 270 The procedure of DNS name autoconfiguration is performed through a 271 DNSSL option delivered by either RA [RFC8106] or DHCPv6 [RFC3646]. 273 5.2.1. DNS Name Generation 275 When as an IPv6 host a device receives a DNSSL option through either 276 RA or DHCPv6, it checks the validity of the DNSSL option. If the 277 option is valid, the IPv6 host performs the DNS name 278 autoconfiguration with each DNS suffix domain name in the DNSSL 279 option as follows: 281 1. The host constructs its DNS name with the DNS suffix domain name 282 along with device configuration (i.e., manufacturer ID, model ID, 283 and serial ID) and a selected identifier (as unique_id) that is 284 considered unique, which is human-friendly, as shown in Figure 1. 286 2. The host constructs an IPv6 unicast address as a tentative 287 address with a 64-bit network prefix and the last 64 bits of the 288 MD5 hashed value of the above DNS name. 290 3. The host constructs the solicited-node multicast address in 291 [RFC4861] corresponding to the tentative IPv6 address. 293 4. The host performs Duplicate Address Detection (DAD) for the IPv6 294 address with the solicited-node multicast address [RFC4861] 295 [RFC4862]. 297 5. If there is no response from the DAD, the host sets the IPv6 298 tentative address as its IPv6 unicast address and regards the 299 constructed DNS name as unique on the local link. Otherwise, 300 since the DAD fails because of DNS name conflict, go to Step 1 301 for a new DNS name generation with another identifier for 302 unique_id. 304 6. Since the DNS name is proven to be unique, it is used as the 305 device's DNS name and the DNS autoconfiguration is done for the 306 given DNS suffix domain name. Also, the host joins the 307 solicited-node multicast address for the verified DNS name in 308 order to prevent other hosts from using this DNS name. 310 When the DNS search list has more than one DNS suffix domain name, 311 the IPv6 host repeats the above procedure until all of the DNS 312 suffixes are used for the DNS name autoconfiguration along with the 313 IPv6 unicast autoconfiguration corresponding to the DNS name. 315 5.2.2. DNS Name Registration 317 Once as IPv6 hosts the devices have autoconfigured their DNS names, 318 as a collector, any IPv6 node (i.e., router or host) in the same 319 subnet can collect the device DNS names using IPv6 Node Information 320 (NI) protocol [RFC4620]. 322 For a collector to collect the device DNS names without any prior 323 node information, a new NI query needs to be defined. That is, a new 324 ICMPv6 Code (e.g., 3) SHOULD be defined for the collection of the 325 IPv6 host DNS names. The Data field is not included in the ICMPv6 326 header since the NI query is for all the IPv6 hosts in the same 327 subnet. The Qtype field for NI type is set to 2 for Node Name. 329 The query SHOULD be transmitted by the collector to a link-local 330 multicast address for this NI query. Assume that a link-local scope 331 multicast address (e.g., all-nodes multicast address, FF02::1) SHOULD 332 be defined for device DNS name collection such that all the IPv6 333 hosts join this link-local multicast address for the device DNS name 334 collection service. 336 When an IPv6 host receives this query sent by the collector in 337 multicast, it transmits its Reply with its DNS name with a random 338 interval between zero and Query Response Interval, as defined by 339 Multicast Listener Discovery Version 2 [RFC3810]. This randomly 340 delayed Reply allows the collector to collect the device DNS names 341 with less frame collision probability by spreading out the Reply time 342 instants. 344 After the collector collects the device DNS names, it resolves the 345 DNS names into the corresponding IPv6 addresses by NI protocol 346 [RFC4620] with the ICMPv6 Code 1 of NI Query. This code indicates 347 that the Data field of the NI Query has the DNS name of an IoT 348 device. The IoT device that receives this NI query sends the 349 collector an NI Reply with its IPv6 address in the Data field. 351 For DNS name resolution service, the collector can register the 352 pair(s) of DNS name and IPv6 address for each IPv6 host with an 353 appropriate designated DNS server for the DNS domain suffix of the 354 DNS name. It is assumed that the collector is configured to register 355 DNS names with the designated DNS server in a secure way based on 356 DNSSEC [RFC4033][RFC6840]. This registration of the DNS name and 357 IPv6 address can be performed by DNS dynamic update [RFC2136]. 358 Before registering the DNS name with the designated DNS server, the 359 collector SHOULD verify the uniqueness of the DNS name in the 360 intended DNS domain by sending a DNS query for the resolution of the 361 DNS name. If there is no corresponding IPv6 address for the queried 362 DNS name, the collector registers the DNS name and the corresponding 363 IPv6 address for each IPv6 host with the designated DNS server. On 364 the other hand, if there is such a corresponding IPv6 address, the 365 DNS name is regarded as duplicate (i.e., not unique), and so the 366 collector notifies the corresponding IoT device with the duplicate 367 DNS name of an error message of DNS name duplication using NI 368 protocol. When an IoT device receives such a DNS name duplication 369 error, it needs to construct a new DNS name and repeats the procedure 370 of device DNS name generation along with the uniqueness test of the 371 device DNS name in its subnet. 373 The two separate procedures of the DNS name collection and IPv6 374 address resolution in the above NI protocol can be consolidated into 375 a single collection for the pairs of DNS names and the corresponding 376 IPv6 addresses. For such an optimization, a new ICMPv6 Code (e.g., 377 4) is defined for the NI Query to query the pair of a DNS name and 378 the corresponding IPv6 address. With this code, the collector can 379 collect the pairs of each IoT device's DNS name and IPv6 address in 380 one NI query message rather than two NI query messages. 382 For DNS name registration of IoT devices as IPv6 hosts, DHCPv6 383 [RFC3315] can be used instead of the NI protocol. For this purpose, 384 a new DHCP option (called DNSNA option) needs to be defined to 385 collect the pair of a DNS name and the corresponding IPv6 address of 386 an IoT device. As a DNS information collector, a DHCPv6 server (or a 387 router running a DHCPv6 server) sends a request message for the DHCP 388 DNSNA option to IoT devices as its DHCPv6 clients under its address 389 pool. The clients respond to this request message by sending the 390 DHCPv6 server a reply message with their DNS information. Thus, the 391 DHCPv6 server can collect the pairs of DNS names and the 392 corresponding IPv6 addresses of the IoT devices. Then, as a 393 collector, the DHCPv6 server can register the DNS names and the 394 corresponding IPv6 addresses of IoT devices with the designated DNS 395 server. 397 To allow only a legitimate IoT device to register its DNS name and 398 IPv6 address with the designated DNS server via a router (or DHCPv6 399 server), the IoT device can sign its registration message with its 400 private key through a digital signature, and the router (or DHCPv6 401 server) can verify the message with the IoT device's public key. For 402 the detailed authentication based on a digital signature, refer to 403 [DNSNA-FGCS]. 405 5.2.3. DNS Name Retrieval 407 For device discovery, a smart device (e.g., smartphone) can retrieve 408 the DNS names of IoT devices by contacting a global (or local) DNS 409 server having the IoT device DNS names. If the smart device can 410 retrieve the zone file with the DNS names, it can display the 411 information of IoT devices in a target network, such as a vehicle's 412 internal network, home network, and office network. With this 413 information, the user can monitor and control the IoT devices in the 414 Internet (or local network). To monitor or remote-control IoT 415 devices, Constrained Application Protocol (CoAP) can be used 416 [RFC7252]. 418 6. Location-Aware DNS Name Configuration 420 If the DNS name of an IoT device includes location information, it 421 allows users to easily identify the physical location of each device. 422 This document proposes the representation of a location in a DNS 423 name. In this document, the location in a DNS name consists of two 424 levels for a detailed location specification, such as macro-location 425 for a large area and micro-location for a small area. 427 To denote both macro-location (i.e., mac_loc) and micro-location 428 (i.e., mic_loc) into a DNS name, the following format is described as 429 in Figure 2: 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | unique_id.object_identifier.OID.mic_loc.mac_loc.LOC.domain_name | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 Figure 2: Location-Aware Device DNS Name Format 437 Fields: 439 unique_id unique identifier to guarantee the uniqueness 440 of the DNS name in ASCII characters. The 441 identifier MAY be alphanumeric with readability, 442 such as product name plus a sequence number. 444 object_identifier device's object identifier that consists of a 445 higher arc, that is, M2M node indication ID 446 (i.e., the concatenation of the managing 447 organization, administration, data country 448 code, and M2M node) and a sequence of four 449 arcs (i.e., manufacturer ID, model ID, serial 450 ID, and expanded ID) as defined in 451 [oneM2M-OID]. The fields are seperated by an 452 underscore '_'. 454 OID subdomain for the keyword of OID to indicate 455 that object_identifier is used. 457 mic_loc device's micro-location, such as an offset in a 458 road segment and coordinates in 2-dimensional 459 (or 3-dimensional) space. 461 mac_loc device's macro-location, such as a road 462 segment and 2-dimensional (or 3-dimensional) 463 space. 465 LOC subdomain for the keyword of LOC to indicate 466 that mac_loc and mic_loc are used. 468 domain_name domain name that represents a DNS domain for 469 the network having the IoT devices. 471 Note each subdomain (e.g., mic_loc and mac_loc) in the domain name 472 format in Figure 2 is expressed using the name syntax described in 473 [RFC1035]. 475 7. Macro-Location-Aware DNS Name 477 If location information (such as cross area, intersection, and road 478 segment in a road network) is available to an IoT device, a keyword, 479 coordinate, or location ID for the location information can be used 480 to construct a DNS name as subdomain name. This location information 481 lets users track the position of mobile devices (such as vehicle, 482 smartphone, and tablet). The physical location of the device is 483 defined as macro-location for DNS naming. 485 A subdomain name for macro-location (denoted as mac_loc) MAY be 486 placed between micro-location (denoted as mic_loc) and the keyword 487 LOC of the DNS name format in Figure 2. For the localization of 488 macro-location, a localization scheme for indoor or outdoor can be 489 used [SALA]. 491 8. Micro-Location-Aware DNS Name 493 An IoT device can be located in the center or edge in a place that is 494 specified by macro-location. For example, assume that a loop- 495 detector is located in the start or end position of a road segment. 496 If the DNS name for the loop-detector contains the start or end 497 position of the road segment, a road network administrator can find 498 it easily. In this document, for this DNS naming, the detailed 499 location for an IoT device can be specified as a micro-location 500 subdomain name. 502 A subdomain name for micro-location (denoted as mic_loc) MAY be 503 placed between the keyword OID and macro-location (denoted as 504 mac_loc) of the DNS name format in Figure 2. For the localization of 505 micro-location, a localization scheme for indoor or outdoor can be 506 used [SALA]. 508 9. DNS Name Management for Mobile IoT Devices 510 Some IoT devices can have mobility, such as vehicle, smartphone, 511 tablet, laptop computer, and cleaning robot. This mobility allows 512 the IoT devices to move from a subnet to another subnet where subnets 513 can have different domain suffixes, such as 514 coordinate.road_segment.road, coordinate.intersection.road, 515 living_room.home and garage.home. The DNS name change (or addition) 516 due to the mobility should be considered. 518 To deal with DNS name management in mobile environments, whenever an 519 IoT device enters a new subnet and receives DNS suffix domain names, 520 it generates its new DNS names and registers them with a designated 521 DNS server, specified by RDNSS option. 523 When the IoT device recognizes the movement to another subnet, it can 524 delete its previous DNS name(s) from the DNS server having the DNS 525 name(s), using DNS dynamic update [RFC2136]. For at least one DNS 526 name to remain in a DNS server for the location management in Mobile 527 IPv6 [RFC6275], the IoT device does not delete its default DNS name 528 in its home network in Mobile IPv6. 530 10. Device Discovery for IoT Devices 532 DNSNA can facilitate the device discovery of a user for IoT devices 533 using a global (or local) DNS server having the IoT device DNS 534 information, as discussed in Section 5.2.3. This device discovery 535 based on unicast outperforms mDNS [RFC6762] using multicast in terms 536 of the discovery speed and the network bandwidth usage for discovery. 538 For example, a vehicle can have its own internal network having in- 539 vehicle devices (e.g., Electronic Control Units (ECUs) such as engine 540 control module, powertrain control module, transmission control 541 module, and brake control module). When the vehicle's internal 542 network is constructed by the Ethernet, those ECUs can autoconfigure 543 their DNS names with the DNSNA and register them with the vehicle's 544 local DNS server [ID-IPWAVE-PS]. The local DNS server can register 545 them with a global DNS server accessible by the automotive service 546 center to monitor and make on-line diagnosis on them. 548 11. Service Discovery for IoT Devices 550 DNS SRV resource record (RR) can be used to support the service 551 discovery of the services provided by IoT devices [RFC2782]. This 552 SRV RR specifies a service name, a transport layer protocol, the 553 corresponding port number, and an IP address of a process running in 554 an IP host as a server to provide a service. An instance for a 555 service can be specified in this SRV RR in DNS-based service 556 discovery [RFC6763]. After the DNS name registration in Section 5.2, 557 IoT devices can register their services with the DNS server via a 558 router with DNS SRV RRs for their services. 560 After the service registration, an IoT user can retrieve services 561 available in his/her target network through service discovery, which 562 can fetch the SRV RRs from the DNS server in the target network. 563 Once (s)he retrieves the list of the SRV RRs, (s)he can monitor or 564 remote-control the devices or their services by using the known 565 protocols and domain information of the devices or their services. 566 For this monitoring or remote-controlling of IoT devices, Constrained 567 Application Protocol (CoAP) can be used [RFC7252]. 569 12. IoT Cloud for IoT Device Management 571 IoT Cloud is a cloud system to monitor and remote-control IoT devices 572 when a user exists either indoors or outdoors. If IoT devices are 573 installed into smart spaces (e.g., smart home and smart building) 574 connected to the IoT Cloud, the indoor location and movement of each 575 IoT device can be tracked and displayed by the user's smartphone App. 576 To enable location-based services for IoT devices, the IoT Cloud can 577 be facilitated by various IoT services including DNS Name 578 Autoconfiguration (DNSNA) in this document. 580 DNSNA is used to generate the DNS name and IPv6 address of each IoT 581 devices. It can construct the DNS name of an IoT device with the 582 physical location (as shown in Section 6) with Indoor Positioning 583 Systems (IPS) such as Smartphone-Assisted Localization Algorithm 584 (SALA) [SALA] and Particle Filtering-Based IPS [PF-IPS]. 586 As explained in [SALA], DNSNA can register the IoT device's DNS 587 naming information with a DNS server via its local router. The IoT 588 Cloud can interact with the DNS server to get the information of IoT 589 devices. A smartphone user can contact the IoT Cloud to retrieve the 590 list of IoT devices belonging to his physical location(s) and display 591 the IoT devices on his smartphone App with the layout of the 592 location(s). Since the IPv6 addresses of the IoT devices are known 593 to him, the user can remote-control them through Constrained 594 Application Protocol (CoAP) [RFC7252] 596 13. Security Considerations 598 This document shares all the security issues of the NI protocol that 599 are specified in the "Security Considerations" section of [RFC4620]. 601 To prevent the disclosure of location information for privacy 602 concern, the subdomains related to location can be encrypted by a 603 shared key or public-and-private keys. For example, a DNS name of 604 vehicle1.oid1.OID.coordinate1.road_segment_id1.LOC.road can be 605 represented as vehicle1.oid1.OID.xxx.yyy.LOC.road where vehicle1 is 606 unique ID, oid1 is object ID, xxx is a string of the encrypted 607 representation of the coordinate (denoted as coordinate1) in a road 608 segment, and yyy is a string of the encrypted representation of the 609 road segment ID (denoted as road_segment_id1). Thus, the location of 610 the vehicle1 can be protected from unwanted users by encryption. 612 14. Acknowledgments 614 This work was supported by the National Research Foundation of Korea 615 (NRF) grant funded by the Korea government, Ministry of Science and 616 ICT (MSIT) (No. 2020R1F1A1048263). 618 This work was supported by the MSIT (Ministry of Science and ICT), 619 Korea, under the ITRC (Information Technology Research Center) 620 support program (IITP-2021-2017-0-01633) supervised by the IITP 621 (Institute for Information & communications Technology Promotion). 623 15. Contributors 625 This document is the group work of IPWAVE working group. This 626 document has the following contributing authors considered co- 627 authors: 629 * Keuntae Lee (Sungkyunkwan University) 631 * Seokhwa Kim (Sungkyunkwan University) 633 16. References 635 16.1. Normative References 637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 638 Requirement Levels", BCP 14, RFC 2119, March 1997, 639 . 641 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 642 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 643 September 2007, . 645 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 646 Address Autoconfiguration", RFC 4862, September 2007, 647 . 649 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 650 "IPv6 Router Advertisement Options for DNS Configuration", 651 RFC 8106, March 2017, 652 . 654 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 655 C., and M. Carney, "Dynamic Host Configuration Protocol 656 for IPv6 (DHCPv6)", RFC 3315, July 2003, 657 . 659 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 660 (DHCP) Service for IPv6", RFC 3736, April 2004, 661 . 663 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 664 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 665 December 2003, . 667 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 668 Specification", RFC 1035, November 1987, 669 . 671 [RFC4033] Arends, R., Ed., Austein, R., Larson, M., Massey, D., and 672 S. Rose, "DNS Security Introduction and Requirements", 673 RFC 4033, March 2005, 674 . 676 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 677 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 678 February 2013, . 680 [RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic 681 Support for IPv6 Networks Operating Outside the Context of 682 a Basic Service Set over IEEE Std 802.11", RFC 8691, 683 December 2019, . 685 [ID-IPWAVE-PS] 686 Jeong, J., Ed., "IPv6 Wireless Access in Vehicular 687 Environments (IPWAVE): Problem Statement and Use Cases", 688 Work in Progress, Internet-Draft, draft-ietf-ipwave- 689 vehicular-networking-26, February 2022, 690 . 693 16.2. Informative References 695 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 696 February 2013, . 698 [RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information 699 Queries", RFC 4620, August 2006, 700 . 702 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 703 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, 704 . 706 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 707 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 708 RFC 2136, April 1997, 709 . 711 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 712 Support in IPv6", RFC 6275, July 2011, 713 . 715 [IEEE-802.3] 716 "IEEE Standard for Ethernet", December 2012. 718 [IEEE-802.11] 719 "Part 11: Wireless LAN Medium Access Control (MAC) and 720 Physical Layer (PHY) Specifications", March 2012. 722 [IEEE-802.11a] 723 "Part 11: Wireless LAN Medium Access Control (MAC) and 724 Physical Layer (PHY) specifications - High-speed Physical 725 Layer in the 5 GHZ Band", September 1999. 727 [IEEE-802.11b] 728 "Part 11: Wireless LAN Medium Access Control (MAC) and 729 Physical Layer (PHY) specifications - Higher-Speed 730 Physical Layer Extension in the 2.4 GHz Band", September 731 1999. 733 [IEEE-802.11g] 734 "Part 11: Wireless LAN Medium Access Control (MAC) and 735 Physical Layer (PHY) specifications - Further Higher Data 736 Rate Extension in the 2.4 GHz Band", April 2003. 738 [IEEE-802.11n] 739 "Part 11: Wireless LAN Medium Access Control (MAC) and 740 Physical Layer (PHY) specifications - Amendment 5: 741 Enhancements for Higher Throughput", March 2009. 743 [DSRC-WAVE] 744 Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its 745 Architecture, Design, and Characteristics", 746 IEEE Communications Surveys & Tutorials, 12(4), 2012. 748 [IEEE-802.11p] 749 "Part 11: Wireless LAN Medium Access Control (MAC) and 750 Physical Layer (PHY) Specifications - Amendment 6: 751 Wireless Access in Vehicular Environments", July 2010. 753 [IEEE-802.11-OCB] 754 "Part 11: Wireless LAN Medium Access Control (MAC) and 755 Physical Layer (PHY) Specifications", IEEE Std 756 802.11-2016, December 2016. 758 [IEEE-802.15.1] 759 "Part 15.1: Wireless Medium Access Control (MAC) and 760 Physical Layer (PHY) specifications for Wireless Personal 761 Area Networks (WPANs)", June 2005. 763 [IEEE-802.15.4] 764 "Part 15.4: Low-Rate Wireless Personal Area Networks (LR- 765 WPANs)", September 2011. 767 [oneM2M-OID] 768 "Object Identifier based M2M Device Identification 769 Scheme", February 2014. 771 [DNSNA-FGCS] 772 Lee, K., Kim, S., Jeong, J., Lee, S., Kim, H., and J. 773 Park, "A Framework for DNS Naming Services for Internet- 774 of-Things Devices", Elsevier Future Generation Computer 775 Systems, Vol. 92, March 2019. 777 [SALA] Jeong, J., Yeon, S., Kim, T., Lee, H., Kim, S., and S. 778 Kim, "SALA: Smartphone-Assisted Localization Algorithm for 779 Positioning Indoor IoT Devices", Springer Wireless 780 Networks, Vol. 24, No. 1, January 2018. 782 [PF-IPS] Shen, Y., Hwang, B., and J. Jeong, "Particle Filtering- 783 Based Indoor Positioning System for Beacon Tag Tracking", 784 IEEE Access, Vol. 8, December 2020. 786 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 787 specifying the location of services (DNS SRV)", RFC 2782, 788 February 2000, . 790 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 791 Discovery", RFC 6763, February 2013, 792 . 794 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 795 Application Protocol (CoAP)", RFC 7252, June 2014, 796 . 798 Appendix A. Changes from draft-jeong-ipwave-iot-dns-autoconf-11 800 The following changes are made from draft-jeong-ipwave-iot-dns- 801 autoconf-11: 803 * This version has a new section (Section 12) of IoT Cloud for IoT 804 device management. 806 Authors' Addresses 807 Jaehoon (Paul) Jeong (editor) 808 Department of Computer Science and Engineering 809 Sungkyunkwan University 810 2066 Seobu-Ro, Jangan-Gu 811 Suwon 812 Gyeonggi-Do 813 16419 814 Republic of Korea 815 Phone: +82 31 299 4957 816 Email: pauljeong@skku.edu 817 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 819 Yoseop Ahn 820 Department of Computer Science and Engineering 821 Sungkyunkwan University 822 2066 Seobu-Ro, Jangan-Gu 823 Suwon 824 Gyeonggi-Do 825 16419 826 Republic of Korea 827 Phone: +82 31 299 4106 828 Email: ahnjs124@skku.edu 829 URI: http://iotlab.skku.edu/people-Ahn-Yoseop.php 831 Sejun Lee 832 Ericsson-LG 833 77, Heungan-Daero 81 Beon-Gil, Dongan-Gu 834 Anyang-Si 835 Gyeonggi-Do 836 14117 837 Republic of Korea 838 Phone: +82 31 450 4099 839 Email: prosejun14@gmail.com 841 Jung-Soo Park 842 Electronics and Telecommunications Research Institute 843 218 Gajeong-Ro, Yuseong-Gu 844 Daejeon 845 34129 846 Republic of Korea 847 Phone: +82 42 860 6514 848 Email: pjs@etri.re.kr