Subject: [homenet] Request for Comments on New Internet Draft for Homenet WG

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 9 Oct 2014 21:44:18 +0900

Hi all,

I submitted a new Internet Draft about "DNS name autoconfiguration for Home
network or IoT devices".

The DNS name autoconfiguration for home network devices will be useful
for the IPv6 stateless autoconfiguration of Home network (or IoT) devices
along with
RFC 6106 for "IPv6 Router Advertisement Options for DNS Configuration":
http://datatracker.ietf.org/doc/rfc6106/

The following is my draft information:
Title: DNS Name Autoconfiguration for Home Network Devices
       draft-jeong-homenet-device-name-autoconf-01

http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/

Abstract:
   This document specifies an autoconfiguration scheme for DNS names of
   home network devices.  By this scheme, the DNS name of a home network
   device can be autoconfigured with the device's category and model in
   a home network.  This DNS name lets home residents easily identify
   each device for monitoring and remote-controlling it in a home
   network.

I would like to ask you to take a look at my new draft and give me your
valuable feedback.

In this IETF 91 meeting, I hope to present my draft and discuss with you
whether my new proposal can be developed for a new working item in Homenet
WG.

Thanks.

Best Regards,
Paul
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /
Department of Computer Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: [email-masked], [email-masked]
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 9 Oct 2014 17:22:27 +0300

Heya,

it seems to be aiming to work only within link-local collision domain, and therefore it seems to be outside the work homenet WG is chartered to do. Perhaps dnssd is more appropriate for this work, although I am not sure about that either (they do more than just naming, as the focus is on service discovery).

Also, I am not sure why you are not just using mDNS (RFC6762) or SSDP (of UPnP) or something else; you get service discovery AND naming with them.

Finally, use of DNSSL option for this seems like a bad idea. For example, let’s assume my ISP gives me ’services.isp.com’ search path, and it gets propagated to my LAN. My devices start showing up under ..services.isp.com names (too) :-p

Cheers,

-Markus

P.S. Name construction scheme is interesting.

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 10 Oct 2014 17:14:22 +0900

Hi Markus,
First of all, thanks for your valuable feedback.

Let me answer your questions and comments.

First, as a basic domain, link-local collision domain is assumed,
but we can extend it into multiple links (or subnets) naturally
if a router can work as a proxy for IPv6 hosts.
That is, if a host tries to autoconfigure its DNS name in a subnet and
there exists another host with the same DNS name in an adjacent subnet,
a router interconnecting these two subnets can responds to the DAD
to tell the first host the duplication of the DNS name due to the second
host.

Second, our proposed scheme can be used along with mDNS or SSDP
for IoT devices (e.g., lamp, door lock, and light sensor) whose capacity
cannot afford to run mDNS by itself in terms of memory or processor
capacity.
It those tiny IoT devices with IPv6 stack and stateless autoconfiguration
functionality,
they will be able to support the DNS name services without the intervention
of a home network administrator.

At least, Device Name Generation (in Section 5.2.1) can be used to generate
a DNS name
for home network devices or IoT devices that run mDNS or SSDP.

Third, for DNSSL, DNS suffixes announced by a router within a home network
can be restricted
to a local domain, such as homenet. Since this can be decided by a local
policy within a home network,
we can eliminate the propagation of ISP DNS suffix into a home network.

Are there any other comments or questions?

Sincerely,
Paul

On Thu, Oct 9, 2014 at 11:22 PM, Markus Stenberg <[email-masked]>
wrote:

> Heya,
>
> it seems to be aiming to work only within link-local collision domain, and
> therefore it seems to be outside the work homenet WG is chartered to do.
> Perhaps dnssd is more appropriate for this work, although I am not sure
> about that either (they do more than just naming, as the focus is on
> service discovery).
>
> Also, I am not sure why you are not just using mDNS (RFC6762) or SSDP (of
> UPnP) or something else; you get service discovery AND naming with them.
>
> Finally, use of DNSSL option for this seems like a bad idea. For example,
> let’s assume my ISP gives me ’services.isp.com’ search path, and it gets
> propagated to my LAN. My devices start showing up under ..services.isp.com
> names (too) :-p
>
> Cheers,
>
> -Markus
>

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 10 Oct 2014 11:46:12 +0300

On 10.10.2014, at 11.14, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> to tell the first host the duplication of the DNS name due to the second host.

So let us assume my 4 home router topology I use for testing homenet stuff. Does this imply flooding of those ICMPs? Limited by TTL? Something else?

(And it starts to look like L2 bridge at some point.)

> cannot afford to run mDNS by itself in terms of memory or processor capacity. 
> It those tiny IoT devices with IPv6 stack and stateless autoconfiguration functionality,
> they will be able to support the DNS name services without the intervention of a home network administrator.

There are small mdns daemons, and if you do not want full functionality (just names), I am sure it could be even smaller.

To provide a service, you have to be discoverable anyway, and that implies mdns, ssdp, or something else that _will use IP address_ to contact your particular device anyway.

> At least, Device Name Generation (in Section 5.2.1) can be used to generate a DNS name 

Use of sub-domains in mDNS is not allowed I think, or at least implementations behave badly with them. SSDP I cannot remember.

(They are specified to be flatname.local.)

> Third, for DNSSL, DNS suffixes announced by a router within a home network can be restricted 
> to a local domain, such as homenet. Since this can be decided by a local policy within a home network,

This implies MUST just to support this, not ‘can’..

And if ISP provides home users with information such as ‘go http://coolservice', having it break suddenly sounds like a bad idea.

Cheers,

-Markus

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 10 Oct 2014 20:43:26 +0900

Markus,
Here are my answers.

On Fri, Oct 10, 2014 at 5:46 PM, Markus Stenberg <[email-masked]>
wrote:

> So let us assume my 4 home router topology I use for testing homenet
> stuff. Does this imply flooding of those ICMPs? Limited by TTL? Something
> else?
>
>      => Since a router collects DNS names of IoT devices in its subnets,
           it limits ICMP messages for Node Information Query to each
subnet.

> > they will be able to support the DNS name services without the
> intervention of a home network administrator.
>
> There are small mdns daemons, and if you do not want full functionality
> (just names), I am sure it could be even smaller.
>
     => Sure mDNS can be implemented lightly. However, my proposal scheme
can be implemented easily with small overhead
          for low-capacity IoT devices.

>
> To provide a service, you have to be discoverable anyway, and that implies
> mdns, ssdp, or something else that _will use IP address_ to contact your
> particular device anyway.
>
     => Once the DNS names of IoT devices are collected by a router, they
are self-explanatory for the service types
          through device category and device model in DNS names.

> Use of sub-domains in mDNS is not allowed I think, or at least
> implementations behave badly with them. SSDP I cannot remember.
>
    => It seems like you are right in mDNS because .local is the DNS
top-level domain for a link-local scope network.
         However, I believe that my proposed DNS name format (i.e.,
unique_id.device_model.device_category.domain_name)
         can make it easy to perform service discovery by the DNS name
itself without actual network operations.

> This implies MUST just to support this, not ‘can’..
     => If my proposal is accepted by IETF, MUST may be used. :-)

>
> And if ISP provides home users with information such as ‘go
> http://coolservice', having it break suddenly sounds like a bad idea.
>
> Cheers,
>
> -Markus

   Thanks for your constructive feedback.

   Regards,
   Paul