Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Ted,
The solution in RFC 6762 (Multicast DNS) section 9 is viable for regular
computers,
such as laptop, desktop, and smartphone that can afford to run mDNS
responder.
For IoT devices, such as light bulb and fire detecting sensor, that have
limited memory and storage,
mDNS seems not viable for the DNS naming for them.

For IoT devices, IETF is working for 6lo for the light interface with IPv6
layer.
In this context, my proposal is based on IPv6 neighbor discovery, so it
will be a viable option for
the DNS name service of IoT devices.

For the regeneration and verification of a unique DNS name under DNS name
conflict,
the solution in RFC 6762 recommends to use an incremental digit (such as 2,
3, 4, etc.) by trial and error.
In an IoT scenario where there will be many IoT devices of the same type,
such as light bulb in home or hotel here,
this incremental numbering approach will be costly and slow to let each IoT
device have a unique DNS name,
especially in a multi-subset network.

My proposal (not included in my current draft yet) is that the router will
join the "multicast addresses for IoT devices" as
a proxy for DNS name conflict detector in the home network whose DNS names
are registered in a DNS server
in the home network.

Thanks for your good feedback.

Paul



===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /
Department of Computer Engineering
Sungkyunkwan University
Office: [phone]
Mobile: [phone]
Fax: [phone]
Email: [e-mail], [e-mail]
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php

On Fri, Nov 14, 2014 at 9:39 AM, Ted Lemon <[e-mail]> wrote:

> On Nov 13, 2014, at 11:49 PM, Mr. Jaehoon Paul Jeong <
> [e-mail]> wrote:
> > My problem is how to make IoT devices have their unique DNS names
> > without the intervention or with a minimal intervention of home network
> users.
>
> RFC 6762 section 9 explains how to do this without operator intervention.
>  I presume that you do not find the solution given in 6762 good enough for
> your specific use case.   Can you explain why it isn't good enough--why
> something better is needed?
>
>
>