idnits 2.17.1 draft-balakrichenan-lpwan-dns-usage-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 31, 2018) is 1943 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan S. Balakrichenan, Ed. 3 Internet-Draft AFNIC 4 Intended status: Experimental December 31, 2018 5 Expires: July 4, 2019 7 DNS usage in LPWAN 8 draft-balakrichenan-lpwan-dns-usage-00 10 Abstract 12 DNS protocol and the database are used extensively in the Internet. 13 Usage of DNS in the constrained devices or network is still nascent. 14 This document describes how DNS could be used in a constrained 15 scenario such as the LPWAN. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 4, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Names as Identifiers . . . . . . . . . . . . . . . . . . . . 2 53 3. Retrieving the context information via DNS . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 3 56 6. Operational Considerations . . . . . . . . . . . . . . . . . 4 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 9.2. Informative References . . . . . . . . . . . . . . . . . 4 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1. Introduction 66 [RFC8376] ] states that the goal of the LPWAN WG is to, where 67 necessary, adapt IETF-defined protocols, addressing schemes, and 68 naming conventions to LPWAN. 70 Domain names (i.e. the Internet naming convention) in association 71 with the DNS (i.e. the Internet naming authority and Server) are 72 introduced in the Internet not only because that humans remember 73 names better than numbers but also for operational facilities. 75 This is a preliminary document elaborating on how DNS could be used 76 in constrained scenarios such as LPWAN. The initial ideas that have 77 been presented will be elaborated. 79 2. Names as Identifiers 81 Like in all networks, LPWAN has two identifier types - i.e. the 82 unique identifier representing the source and the unique identifier 83 representing the destination, within the scope of that network. 85 For example, In LoRaWAN, the source is represented by the DevEUI 86 (i.e. the device address) and the destination corresponding to the 87 source is represented by the JoinEUI (i.e. the Join Server address) 88 and the AppEUI (i.e. the Application server address). Naturally, the 89 source and the destination information are sent as part of the packet 90 header. These different addresses are constructed using the IEEE- 91 EUI-64 format. 93 As in the Internet, there are multiple advantages in using domain 94 names instead of IEEE defined 64 bit identifiers for representing 95 either the source or the destination or both. As per the LoRa 96 specifications, the JoinEUI is converted to a domain name to identify 97 the Join Server IP address in the case of OTAA (Over the Air 98 Activation) or roaming. 100 This section describes how identifiers in the LPWAN could be 101 configurable to a domain name. The device sends the source and 102 destination information, represented as domain name in the packet 103 header and it is up to the gateway to resolve the IP address 104 corresponding to the domain name and cache this information. Caching 105 will enable that the future connections need to re-do the DNS look up 106 until the cache is expired. 108 3. Retrieving the context information via DNS 110 Draft [ietf-lpwan-ipv6-static-context-hc-18] defines a compression 111 technique for LPWAN based on a static context that is known by both 112 the device as well as the Network Gateway. The Compression/ 113 Decompression (C/D) process is as follows: The device compresses the 114 packet header using SCHC C/D. The resulting SCHC packet is sent to a 115 LPWAN Radio Gateway, which forwards it to a Network Gateway. At the 116 Network Gateway end, the packet is decompressed using SCHC C/D. 117 After decompression, the packet is sent over the Internet to one or 118 several LPWAN application servers. 120 The SCHC C/D must be present on both sides i.e. at the device and as 121 well as at the Network Gateway. At both ends the same set of rules 122 (which is termed as "Context") is shared. The Context is not 123 transmitted over the air. Only the Rule ID (an identifier which 124 identifies a rule that is already stored at both ends) is sent over 125 the air. 127 The manner the contexts are obtained both at the device and as well 128 as the Network Gateway is not normalized. There are different 129 suggestion such as either the contexts could be pre-provisioned, 130 learned by a provisioning protocol or by an out of band mechanism. 132 The context could be defined by a data model 133 [I-D.toutain-lpwan-yang-static-context-hc]. This section presents 134 how to securely retrieve "Context" at both ends using DNS. 136 4. Security Considerations 138 TBD 140 5. Privacy Considerations 142 TBD 144 6. Operational Considerations 146 TBD 148 7. IANA Considerations 150 TBD 152 8. Acknowledgements 154 9. References 156 9.1. Normative References 158 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 159 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 160 . 162 9.2. Informative References 164 [I-D.toutain-lpwan-yang-static-context-hc] 165 Minaburo, A. and L. Toutain, "YANG module for LPWAN Static 166 Context Header Compression (SCHC)", draft-toutain-lpwan- 167 yang-static-context-hc-00 (work in progress), July 2016. 169 Author's Address 171 Sandoche Balakrichenan (editor) 172 AFNIC 173 1 Rue Stephenson 174 Montigny le Bretonneux 78180 175 FR 177 Email: sandoche.balakrichenan@afnic.fr