DNS usage in LPWAN
draft-balakrichenan-lpwan-dns-usage-00

Abstract

DNS protocol and the database are used extensively in the Internet. Usage of DNS in the constrained devices or network is still nascent. This document describes how DNS could be used in a constrained scenario such as the LPWAN.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 4, 2019.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Names as Identifiers
• 3. Retrieving the context information via DNS
• 4. Security Considerations
• 5. Privacy Considerations
• 6. Operational Considerations
• 7. IANA Considerations
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Author's Address

1. Introduction

[RFC8376] ] states that the goal of the LPWAN WG is to, where necessary, adapt IETF-defined protocols, addressing schemes, and naming conventions to LPWAN.

Domain names (i.e. the Internet naming convention) in association with the DNS (i.e. the Internet naming authority and Server) are introduced in the Internet not only because that humans remember names better than numbers but also for operational facilities.

This is a preliminary document elaborating on how DNS could be used in constrained scenarios such as LPWAN. The initial ideas that have been presented will be elaborated.

2. Names as Identifiers

Like in all networks, LPWAN has two identifier types – i.e. the unique identifier representing the source and the unique identifier representing the destination, within the scope of that network.

For example, In LoRaWAN, the source is represented by the DevEUI (i.e. the device address) and the destination corresponding to the source is represented by the JoinEUI (i.e. the Join Server address) and the AppEUI (i.e. the Application server address). Naturally, the source and the destination information are sent as part of the packet header. These different addresses are constructed using the IEEE-EUI-64 format.

As in the Internet, there are multiple advantages in using domain names instead of IEEE defined 64 bit identifiers for representing either the source or the destination or both. As per the LoRa specifications, the JoinEUI is converted to a domain name to identify the Join Server IP address in the case of OTAA (Over the Air Activation) or roaming.

This section describes how identifiers in the LPWAN could be configurable to a domain name. The device sends the source and destination information, represented as domain name in the packet header and it is up to the gateway to resolve the IP address corresponding to the domain name and cache this information. Caching will enable that the future connections need to re-do the DNS look up until the cache is expired.

3. Retrieving the context information via DNS

Draft [ietf-lpwan-ipv6-static-context-hc-18] defines a compression technique for LPWAN based on a static context that is known by both the device as well as the Network Gateway. The Compression/Decompression (C/D) process is as follows: The device compresses the packet header using SCHC C/D. The resulting SCHC packet is sent to a LPWAN Radio Gateway, which forwards it to a Network Gateway. At the Network Gateway end, the packet is decompressed using SCHC C/D. After decompression, the packet is sent over the Internet to one or several LPWAN application servers.

The SCHC C/D must be present on both sides i.e. at the device and as well as at the Network Gateway. At both ends the same set of rules (which is termed as “Context”) is shared. The Context is not transmitted over the air. Only the Rule ID (an identifier which identifies a rule that is already stored at both ends) is sent over the air.

The manner the contexts are obtained both at the device and as well as the Network Gateway is not normalized. There are different suggestion such as either the contexts could be pre-provisioned, learned by a provisioning protocol or by an out of band mechanism.

The context could be defined by a data model [I-D.toutain-lpwan-yang-static-context-hc]. This section presents how to securely retrieve “Context” at both ends using DNS.

4. Security Considerations

TBD

5. Privacy Considerations

TBD

6. Operational Considerations

TBD

7. IANA Considerations

TBD

8. Acknowledgements

9. References

9.1. Normative References

9.2. Informative References

Author's Address