<?xml version="1.0" encoding="iso-8859-1" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="trust200902"
    docName="draft-lemon-homenet-dns-requirements-00"
    category="info">

<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>

<front>

<title abbrev="Homenet DNS Reqs">Requirements for Homenet Naming Architecture</title>

<author initials="T" surname="Lemon" fullname="Ted Lemon">
<organization>Nominum, Inc.</organization>
<address>
<postal>
<street>800 Bridge Parkway</street>
<city>Redwood City</city>
<region>California</region>
<country>United States of America</country>
<code>94065</code>
</postal>
<phone>+1 650 381 6000</phone>
<email>ted.lemon@nominum.com</email>
</address>
</author>

<date month="November" year="2016" />

<keyword>Homenet</keyword>
<keyword>mDNS</keyword>
<keyword>DNSSD</keyword>

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

</front>
<middle>
    
    
<section anchor="intro" title="Introduction">
    <t>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.</t>

    <t>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 <xref target="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.</t>

    <t>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.</t>

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

    <t>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.</t>
</section>

<section title="Security Considerations">
</section>

<section title="Acknowledgments">
</section>

</middle>

<back>

<references title="Informative References">
  <?rfc include="reference.RFC.1035.xml"?>
</references>

</back>
</rfc>
