idnits 2.17.1 draft-jeong-homenet-device-name-autoconf-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 4 instances 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 224 has weird spacing: '...ategory dev...' == Line 414 has weird spacing: '...ategory dev...' -- The document date (October 9, 2015) is 3121 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 6106 (Obsoleted by RFC 8106) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong 3 Internet-Draft S. Lee 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: April 11, 2016 J. Park 6 ETRI 7 October 9, 2015 9 DNS Name Autoconfiguration for Internet of Things Devices 10 draft-jeong-homenet-device-name-autoconf-04 12 Abstract 14 This document specifies an autoconfiguration scheme for the global 15 (or local) DNS names of Internet of Things (IoT) devices, such as 16 appliances and sensors. By this scheme, the DNS name of an IoT 17 device can be autoconfigured with the device's category and model in 18 wired and wireless target networks (e.g., home, office, shopping 19 mall, smart grid, and road network). This DNS name lets IoT users 20 (e.g., home residents and customers) in the Internet (or local 21 network) easily identify each device for monitoring and remote- 22 controlling it in the target network. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on April 11, 2016. 47 Copyright Notice 48 Copyright (c) 2015 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Applicability Statements . . . . . . . . . . . . . . . . . 4 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. DNS Name Autoconfiguration . . . . . . . . . . . . . . . . . . 5 69 5.1. DNS Name Format . . . . . . . . . . . . . . . . . . . . . 5 70 5.2. Procedure of DNS Name Autoconfiguration . . . . . . . . . 6 71 5.2.1. DNS Name Generation . . . . . . . . . . . . . . . . . 6 72 5.2.2. DNS Name Collection . . . . . . . . . . . . . . . . . 7 73 5.2.3. DNS Name Retrieval . . . . . . . . . . . . . . . . . . 8 74 6. Location-Aware DNS Name Configuration . . . . . . . . . . . . 8 75 6.1. Macro-Location-Aware DNS Name . . . . . . . . . . . . . . 8 76 6.2. Micro-Location-Aware DNS Name . . . . . . . . . . . . . . 9 77 7. DNS Name Management for Mobile IoT Devices . . . . . . . . . . 10 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 Many Internet of Things (IoT) devices (e.g., appliances and sensors) 87 have begun to have wireless communication capability (e.g., WiFi, 88 Bluetooth, and ZigBee) for monitoring and remote-controlling in a 89 local network or the Internet. According to the capacity, such IoT 90 devices can be categorized into high-capacity devices and low- 91 capacity devices. High-capacity devices have a high-power processor 92 and a large storage, such as appliances (e.g., television, 93 refrigerator, air conditioner, and washing machine) and smart devices 94 (smartphone and tablet). They are placed in environments (e.g., 95 home, office, shopping mall, smart grid, and road network) for the 96 direct use for human users, and they require the interaction with 97 human users. Low-capacity devices have a low-power processor and a 98 small storage, such as sensors (e.g., light, meter, room temperature 99 controller, and sensors). They are installed for the easy management 100 of environments (e.g., home, office, store, and factory), and they do 101 not require the interaction with human users. 103 For the Internet connectivity of IoT devices, a variety of parameters 104 (e.g., address prefixes, default routers, and DNS servers) can be 105 automatically configured by Neighbor Discovery (ND) for IP Version 6, 106 IPv6 Stateless Address Autoconfiguration, and IPv6 Router 107 Advertisement (RA) Options for DNS Configuration [RFC4861][RFC4862] 108 [RFC6106]. 110 For these IoT devices, the manual configuration of DNS names will be 111 cumbersome and time-consuming as the number of them increases rapidly 112 in a network. It will be good for such DNS names to be automatically 113 configured such that they are readable to human users. 115 Multicast DNS (mDNS) in [RFC6762] can provide DNS service for 116 networked devices on a local link (e.g., home network and office 117 network) without any conventional recursive DNS server. mDNS also 118 supports the autoconfiguration of a device's DNS name without the 119 intervention of the user. mDNS aims at the DNS naming service for the 120 local DNS names of the networked devices on the local link rather 121 than the DNS naming service for the global DNS names of such devices 122 in the Internet. However, for IoT devices accessible from the 123 Internet, mDNS cannot be used. Thus, a new autoconfiguration scheme 124 becomes required for the global DNS names of IoT devices. 126 This document proposes an autoconfiguration scheme for the global (or 127 local) DNS names of IoT devices. Since an autoconfigured DNS name 128 contains the device category and model of a device, IoT users in the 129 Internet (or local network) can easily identify the device. With 130 this device category and model, they will be able to monitor and 131 remote-control each device with mobile smart devices (e.g., 132 smartphone and tablet) by resolving its DNS name into the 133 corresponding IPv6 address. 135 1.1. Applicability Statements 137 It is assumed that IoT devices have networking capability through 138 wired or wireless communication media, such as Ethernet [IEEE-802.3], 139 WiFi [IEEE-802.11] [IEEE-802.11a] [IEEE-802.11b][IEEE-802.11g] 140 [IEEE-802.11n], Bluetooth [IEEE-802.15.1], and ZigBee [IEEE-802.15.4] 141 in a local area network (LAN) or personal area network (PAN). 143 Also, it is assumed that each IoT device has a factory configuration 144 (called device configuration) having device category (e.g., smart TV, 145 smartphone, tablet, and refrigerator) and model (i.e., a specific 146 model name of the device). This device configuration can be read by 147 the device for DNS name autoconfiguration. 149 2. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 3. Terminology 157 This document uses the terminology described in [RFC4861] and 158 [RFC4862]. In addition, four new terms are defined below: 160 o Device Configuration: A factory configuration that has device 161 category (e.g., smart TV, smartphone, tablet, and refrigerator) 162 and model (i.e., a specific model name of the device). 164 o DNS Search List (DNSSL): The list of DNS suffix domain names used 165 by IPv6 hosts when they perform DNS query searches for short, 166 unqualified domain names [RFC6106]. 168 o DNSSL Option: IPv6 RA option to deliver the DNSSL information to 169 IPv6 hosts [RFC6106]. 171 4. Overview 173 This document specifies an autoconfiguration scheme for an IoT device 174 using device configuration and DNS search list. Device configuration 175 has device category and device model. DNS search list has DNS suffix 176 domain names that represent the DNS domains of a network having the 177 IoT device [RFC6106]. 179 As an IPv6 host, the IoT device can obtain DNS search list through 180 IPv6 Router Advertisement (RA) with DNS Search List (DNSSL) Option 181 [RFC4861][RFC6106] or DHCPv6 with Domain Search List Option 182 [RFC3315][RFC3736][RFC3646]. 184 The IoT device can construct its DNS name with the concatenation of 185 device category, device model, and domain name. Since there exist 186 more than one device with the same model, the DNS name should have a 187 unique identification to differentiate multiple devices with the same 188 model. 190 Since both RA and DHCPv6 can be simultaneously used for the parameter 191 configuration for IPv6 hosts, this document considers the DNS name 192 autoconfiguration in the coexistence of RA and DHCP. 194 5. DNS Name Autoconfiguration 196 The DNS name autoconfiguration for an IoT device needs the 197 acquisition of DNS search list through either RA [RFC6106] or DHCPv6 198 [RFC3646]. Once the DNS search list is obtained, the IoT device 199 autonomously constructs its DNS name(s) with the DNS search list and 200 its device information. 202 5.1. DNS Name Format 204 A DNS name for an IoT device has the following format as in Figure 1: 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | unique_id.device_model.device_category.domain_name | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 1: IoT Device DNS Name Format 212 Fields: 214 unique_id unique identifier to guarantee the uniqueness 215 of the DNS name in ASCII characters. The 216 identifier MAY be a sequence number or 217 alphanumeric with readability, such as product 218 name. 220 device_model device's model name in ASCII characters. It 221 is a product model name provided by the 222 manufacturer. 224 device_category device's category name in ASCII characters, 225 such as TV, refrigerator, air conditioner, 226 smartphone, tablet, light, and meter. 228 domain_name DNS domain name that is encoded according to 229 the specification of "Representation and use 230 of domain name" of RFC 3315. 232 5.2. Procedure of DNS Name Autoconfiguration 234 The procedure of DNS name autoconfiguration is performed through a 235 DNSSL option delivered by either RA [RFC6106] or DHCPv6 [RFC3646]. 237 5.2.1. DNS Name Generation 239 When as an IPv6 host a device receives a DNSSL option through either 240 RA or DHCPv6, it checks the validity of the DNSSL option. If the 241 option is valid, the IPv6 host performs the DNS name 242 autoconfiguration with each DNS suffix domain name in the DNSSL 243 option as follows: 245 1. The host constructs its DNS name with the DNS suffix domain name 246 along with device configuration (i.e., device category and device 247 model) and a selected identifier (as unique_id) that is 248 considered unique, as shown in Figure 1. 250 2. The host constructs an IPv6 unicast address as a tentative 251 address with a 64-bit network prefix and the last 64 bits of the 252 MD5 hashed value of the above DNS name. 254 3. The host constructs the solicited-node multicast address in 255 [RFC4861] corresponding to the tentative IPv6 address. 257 4. The host performs Duplicate Address Detection (DAD) for the IPv6 258 address with the solicited-node multicast address [RFC4861] 259 [RFC4862]. 261 5. If there is no response from the DAD, the host sets the IPv6 262 tentative address as its IPv6 unicast address and regards the 263 constructed DNS name as unique on the local link. Otherwise, 264 since the DAD fails because of DNS name conflict, go to Step 1 265 for a new DNS name generation with another identifier for 266 unique_id. 268 6. Since the DNS name is proven to be unique, it is used as the 269 device's DNS name and the DNS autoconfiguration is done for the 270 given DNS suffix domain name. Also, the host joins the 271 solicited-node multicast address for the verified DNS name in 272 order to prevent other hosts from using this DNS name. 274 When the DNS search list has more than one DNS suffix domain name, 275 the IPv6 host repeats the above procedure until all of the DNS 276 suffixes are used for the DNS name autoconfiguration along with the 277 IPv6 unicast autoconfiguration corresponding to the DNS name. 279 5.2.2. DNS Name Collection 281 Once as IPv6 hosts the devices have autoconfigured their DNS names, 282 as a collector, any IPv6 node (i.e., router or host) in the same 283 subnet can collect the device DNS names using IPv6 Node Information 284 (NI) protocol [RFC4620]. 286 For a collector to collect the device DNS names without any prior 287 node information, a new NI query needs to be defined. That is, a new 288 ICMPv6 Code (e.g., 3) SHOULD be defined for the collection of the 289 IPv6 host DNS names. The Data field is not included in the ICMPv6 290 header since the NI query is for all the IPv6 hosts in the same 291 subnet. The Qtype field for NI type is set to 2 for Node Name. 293 The query SHOULD be transmitted by the collector to a link-local 294 multicast address for this NI query. Assume that a link-local scope 295 multicast address (e.g., all-nodes multicast address, FF02::1) SHOULD 296 be defined for device DNS name collection such that all the IPv6 297 hosts join this link-local multicast address for the device DNS name 298 collection service. 300 When an IPv6 host receives this query sent by the collector in 301 multicast, it transmits its Reply with its DNS name with a random 302 interval between zero and Query Response Interval, as defined by 303 Multicast Listener Discovery Version 2 [RFC3810]. This randomly 304 delayed Reply allows the collector to collect the device DNS names 305 with less frame collision probability by spreading out the Reply time 306 instants. 308 After the collector collects the device DNS names, it resolves the 309 DNS names into the corresponding IPv6 addresses by NI protocol 310 [RFC4620] with the ICMPv6 Code 1 of NI Query. This code indicates 311 that the Data field of the NI Query has the DNS name of an IoT 312 device. The IoT device that receives this NI query sends the 313 collector an NI Reply with its IPv6 address in the Data field. 315 For DNS name resolution service, the collector can register the 316 pair(s) of DNS name and IPv6 address for each IPv6 host into an 317 appropriate designated DNS server for the DNS domain suffix of the 318 DNS name. It is assumed that the collector is configured to register 319 DNS names into the designated DNS server in a secure way based on 320 DNSSEC [RFC4033][RFC6840]. This registration of the DNS name and 321 IPv6 address can be performed by DNS dynamic update [RFC2136]. 322 Before registering the DNS name into the designated DNS server, the 323 collector SHOULD verify the uniqueness of the DNS name in the 324 intended DNS domain by sending a DNS query for the resolution of the 325 DNS name. If there is no corresponding IPv6 address for the queried 326 DNS name, the collector registers the DNS name and the corresponding 327 IPv6 address into the designated DNS server. On the other hand, if 328 there is such a corresponding IPv6 address, the DNS name is regarded 329 as duplicate (i.e., not unique), and so the corresponder notifies the 330 corresponding IoT device with the duplicate DNS name of an error 331 message of DNS name duplication using NI protocol. When an IoT 332 device receives such a DNS name duplication error, it needs to 333 construct a new DNS name and repeats the procedure of device DNS name 334 generation along with the uniqueness test of the device DNS name in 335 its subnet. 337 The two separate procedures of the DNS name collection and IPv6 338 address resolution in the above NI protocol can be consolidated into 339 a single collection for the pairs of DNS names and the corresponding 340 IPv6 addresses. For such an optimization, a new ICMPv6 Code (e.g., 341 4) is defined for the NI Query to query the pair of a DNS name and 342 the corresponding IPv6 address. With this code, the collector can 343 collect the pairs of each IoT device's DNS name and IPv6 address in 344 one NI query message rather than two NI query messages. 346 5.2.3. DNS Name Retrieval 348 A smart device like smartphone can retrieve the DNS names of IoT 349 devices by contacting a global (or local) DNS server having the IoT 350 device DNS names. If the smart device can retrieve the zone file 351 with the DNS names, it can display the information of IoT devices in 352 a target network, such as home network and office network. With this 353 information, the user can monitor and control the IoT devices in the 354 Internet (or local network). 356 6. Location-Aware DNS Name Configuration 358 If the DNS name of an IoT device includes location information, it 359 allows users to easily identify the physical location of each device. 360 This document proposes the representation of location in a DNS name. 362 6.1. Macro-Location-Aware DNS Name 364 If location information (such as living room, kitchen, and bedroom in 365 an apartment) is available to an IoT device, a keyword for the 366 location can be used to construct a DNS name as subdomain name. This 367 location information lets users track the position of mobile devices 368 (such as smartphone, tablet, and vacuum cleaning robot). The 369 physical location of the device is defined as macro-location for DNS 370 naming. 372 A subdomain name for macro-location (denoted as mac_loc) MAY be 373 placed between device_category and domain_name of the DNS name format 374 in Figure 2. A localization scheme for device location is beyond the 375 scope of this document. 377 6.2. Micro-Location-Aware DNS Name 379 An IoT device can be located in the center, wall, or corner in a room 380 that is specified by macro-location. For example, assume that a 381 cleaning robot is located in the right-upper corner of a living room. 382 If the DNS name for the cleaning robot contains the right-upper 383 corner of the living room, a home resident can find it easily. In 384 this document, for this DNS naming, the detailed location for an IoT 385 device can be specified as a micro-location subdomain name. 387 A subdomain name for micro-location (denoted as mic_loc) MAY be 388 placed between device_category and domain_name of the DNS name format 389 in Figure 2. A localization scheme for micro-location is beyond the 390 scope of this document. 392 To denote both macro-location (i.e., mac_loc) and micro-location 393 (i.e., mic_loc) into a DNS name, the following format is described as 394 in Figure 2: 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | unique_id.device_model.device_category.mic_loc.mac_loc.domain_name| 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 2: Location-Aware Device DNS Name Format 402 Fields: 404 unique_id unique identifier to guarantee the uniqueness 405 of the DNS name in ASCII characters. The 406 identifier MAY be a sequence number or 407 alphanumeric with readability, such as product 408 name. 410 device_model device's model name in ASCII characters. It 411 is a product model name provided by the 412 manufacturer. 414 device_category device's category name in ASCII characters, 415 such as TV, refrigerator, air conditioner, 416 smartphone, tablet, light, and meter. 418 mic_loc device's micro-location, such as center, 419 wall, and corner. 421 mac_loc device's macro-location, such as living room. 423 domain_name DNS domain name that is encoded according to 424 the specification of "Representation and use 425 of domain name" of RFC 3315. 427 7. DNS Name Management for Mobile IoT Devices 429 Some IoT devices can have mobility, such as smartphone, tablet, 430 laptop computer, and cleaning robot. This mobility allows the IoT 431 devices to move from a subnet to another subnet where subnets can 432 have different domain suffixes, such as living_room.home and 433 garage.home. The DNS name change (or addition) due to the mobility 434 should be considered. 436 To deal with DNS name management in mobile environments, whenever an 437 IoT device enters a new subnet and receives DNS suffix domain names, 438 it generates its new DNS names and registers them into a designated 439 DNS server, specified by RDNSS option. 441 When the IoT device recognizes the movement to another subnet, it can 442 delete its previous DNS name(s) from the DNS server having the DNS 443 name(s), using DNS dynamic update [RFC2136]. For at least one DNS 444 name to remain in a DNS server for the location management in Mobile 445 IPv6 [RFC6275], the IoT device does not delete its default DNS name 446 in its home network in Mobile IPv6. 448 8. Security Considerations 450 This document shares all the security issues of the NI protocol that 451 are specified in the "Security Considerations" section of [RFC4620]. 453 To prevent the disclosure of location information for privacy 454 concern, the subdomains related to location can be encrypted by a 455 shared key or public-and-private keys. For example, a DNS name of 456 smartphone1.living_room.home can be represented as 457 smartphone1.xxx.home where xxx is a string of the encrypted 458 representation of the subdomain living_room. 460 9. Acknowledgements 462 This work was partly supported by the ICT R&D program of MSIP/IITP 463 [10041244, SmartTV 2.0 Software Platform] and ETRI. 465 10. References 466 10.1. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. 472 Soliman, "Neighbor Discovery for IP Version 6 473 (IPv6)", RFC 4861, September 2007. 475 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 476 Stateless Address Autoconfiguration", RFC 4862, 477 September 2007. 479 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. 480 Madanapalli, "IPv6 Router Advertisement Options for 481 DNS Configuration", RFC 6106, November 2010. 483 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., 484 Perkins, C., and M. Carney, "Dynamic Host 485 Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, 486 July 2003. 488 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration 489 Protocol (DHCP) Service for IPv6", RFC 3736, 490 April 2004. 492 [RFC3646] Droms, R., Ed., "DNS Configuration options for 493 Dynamic Host Configuration Protocol for IPv6 494 (DHCPv6)", RFC 3646, December 2003. 496 [RFC4033] Arends, R., Ed., Austein, R., Larson, M., Massey, 497 D., and S. Rose, "DNS Security Introduction and 498 Requirements", RFC 4033, March 2005. 500 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications 501 and Implementation Notes for DNS Security (DNSSEC)", 502 RFC 6840, February 2013. 504 10.2. Informative References 506 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", 507 RFC 6762, February 2013. 509 [RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node 510 Information Queries", RFC 4620, August 2006. 512 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 513 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 515 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. 516 Bound, "Dynamic Updates in the Domain Name System 517 (DNS UPDATE)", RFC 2136, April 1997. 519 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, 520 "Mobility Support in IPv6", RFC 6275, July 2011. 522 [IEEE-802.3] IEEE Std 802.3, "IEEE Standard for Ethernet", 523 December 2012. 525 [IEEE-802.11] IEEE Std 802.11, "Part 11: Wireless LAN Medium 526 Access Control (MAC) and Physical Layer (PHY) 527 Specifications", March 2012. 529 [IEEE-802.11a] IEEE Std 802.11a, "Part 11: Wireless LAN Medium 530 Access Control (MAC) and Physical Layer (PHY) 531 specifications: High-speed Physical Layer in the 5 532 GHZ Band", September 1999. 534 [IEEE-802.11b] IEEE Std 802.11b, "Part 11: Wireless LAN Medium 535 Access Control (MAC) and Physical Layer (PHY) 536 specifications: Higher-Speed Physical Layer 537 Extension in the 2.4 GHz Band", September 1999. 539 [IEEE-802.11g] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium 540 Access Control (MAC) and Physical Layer (PHY) 541 specifications: Further Higher Data Rate Extension 542 in the 2.4 GHz Band", April 2003. 544 [IEEE-802.11n] IEEE P802.11n/D9.0, "Part 11: Wireless LAN Medium 545 Access Control (MAC) and Physical Layer (PHY) 546 specifications Amendment 5: Enhancements for Higher 547 Throughput", March 2009. 549 [IEEE-802.15.1] IEEE Std 802.15.1, "Part 15.1: Wireless Medium 550 Access Control (MAC) and Physical Layer (PHY) 551 specifications for Wireless Personal Area Networks 552 (WPANs)", June 2005. 554 [IEEE-802.15.4] IEEE Std 802.15.4, "Part 15.4: Low-Rate Wireless 555 Personal Area Networks (LR-WPANs)", September 2011. 557 Authors' Addresses 559 Jaehoon Paul Jeong 560 Department of Software 561 Sungkyunkwan University 562 2066 Seobu-Ro, Jangan-Gu 563 Suwon, Gyeonggi-Do 440-746 564 Republic of Korea 566 Phone: +82 31 299 4957 567 Fax: +82 31 290 7996 568 EMail: pauljeong@skku.edu 569 URI: http://cpslab.skku.edu/people-jaehoon-jeong.php 571 Sejun Lee 572 Department of Computer Science and Engineering 573 Sungkyunkwan University 574 2066 Seobu-Ro, Jangan-Gu 575 Suwon, Gyeonggi-Do 440-746 576 Republic of Korea 578 Phone: +82 31 299 4106 579 Fax: +82 31 290 7996 580 EMail: sejunlee@skku.edu 582 Jung-Soo Park 583 Electronics and Telecommunications Research Institute 584 218 Gajeong-Ro, Yuseong-Gu 585 Daejeon, 305-700 586 Republic of Korea 588 Phone: +82 42 860 6514 589 EMail: pjs@etri.re.kr