Requirements for Homenet Naming Architecture
draft-lemon-homenet-dns-requirements-00

Abstract

This document describes options for how naming could be done in a homenet, and lists requirements for each solution.

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 http://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 May 19, 2017.

Copyright Notice

Copyright (c) 2016 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 (http://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. Security Considerations
• 3. Acknowledgments
• 4. Informative References
• Author's Address

1. Introduction

The homenet working group is trying to develop a suite of specifications that, when implemented together, will produce home routers that are capable of supporting fully-featured end-to-end routed internet service. Of course, fully-featured could mean a lot of things, and at present the homenet naming architecture is stalled over the question of what it means.

There are a few things it could mean. At the most basic level, it could mean simply that devices that publish services using mDNS are reachable from anywhere on the home network using dnssd hybrid proxy, that caching name service [RFC1035] or DNS Proxy service is provided for off-network queries, and that no other naming is available on the homenet. This is fairly easy to implement, and likely would address all use cases addressed by existing home routers, but would support service discovery across routers, which current home routers do not support. We'll call this option 1.

A second option would be to provide fully-featured name service, using DNS updates with mDNS as a backup. This differs from option 1 in that there would have to be one or more stateful DNS authoritative servers on the homenet. It would require additional bookkeeping work on the part of the infrastructure to delete stale names. It would require some form of quorum detection and election for cases where the end user decommissions devices without telling the network, and adds devices without telling the network. In order to actually add value, this option requires that it be possible for the homenet to acquire a global DNS delegation somehow.

A third option would be to provide the second option with DNSSEC, including a secure delegation from the root.

In order to make anything other than option 1 work, some interaction with the end user would be required. In order to support DNSSEC, some sort of secure pairing process would be necessary. Supporting either of these options requires either that we pass the buck on how to do this to router vendors and hope for the best, or that we specify some sort of management API that allows for these functions to be done in a standards-compliant way, so apps can be written for smart devices that will support any homenet router that an end user purchases.

2. Security Considerations

3. Acknowledgments

4. Informative References

Author's Address