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

"Mr. Jaehoon Paul Jeong" <> Fri, 14 November 2014 21:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B833D1ACE3C for <>; Fri, 14 Nov 2014 13:34:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5SUqbgrhxTKl for <>; Fri, 14 Nov 2014 13:34:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA58B1ACE37 for <>; Fri, 14 Nov 2014 13:34:06 -0800 (PST)
Received: by with SMTP id r10so2241600igi.12 for <>; Fri, 14 Nov 2014 13:34:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mN6Ec7u+dK87HHhLUosUVq7UvsT+Qr4mOj01vlEEeGs=; b=Ypk2ZXLPEP5tDbF+skF6pkHIj9+OSETM20hqC27RrdjXVSjuP4zAmD8UOIoi2o+cXs XbirsgcD929fM/sU8UeGMUy9yoxMgIIiXDK3oTQ5rfErPLJRJ1KDVHkxa+qouGH0ONID xAHoPLPbOy3TygmQIRx71Ia3oipJgHy/gDUZNzX5XXKEGSJdkPfVAYXR3B3TfYITvBpT gVCKcodAE+WdD2pqB4EI5gIvBsabhrzk8XkBUvOac7PcJVatXVih3bPg8yRsLB+ncl1L UA/miKNQ1YcwGjG+JCT1FHDHXMJb0VMVmWlt+eoE0yE7kKU70lTpUI6aPvbU25msg+l6 sV9w==
MIME-Version: 1.0
X-Received: by with SMTP id f125mr13180747ioe.15.1416000845806; Fri, 14 Nov 2014 13:34:05 -0800 (PST)
Received: by with HTTP; Fri, 14 Nov 2014 13:34:05 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Fri, 14 Nov 2014 11:34:05 -1000
Message-ID: <>
From: "Mr. Jaehoon Paul Jeong" <>
To: Ted Lemon <>
Content-Type: multipart/alternative; boundary=001a1140c8d86a853f0507d8638d
Cc:, Jung-Soo Park <>, Brian Haberman <>, Myung-Ki Shin <>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Nov 2014 21:34:09 -0000

The solution in RFC 6762 (Multicast DNS) section 9 is viable for regular
such as laptop, desktop, and smartphone that can afford to run mDNS
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
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
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.


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
CPS Lab Website:
Personal Homepage:

On Fri, Nov 14, 2014 at 9:39 AM, Ted Lemon <>; wrote:

> On Nov 13, 2014, at 11:49 PM, Mr. Jaehoon Paul Jeong <
>>; 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?