Project

General

Profile

Feature #3465

Extend client auto-configuration stages to include mDNS/DNS-SD

Added by Alex Afanasyev over 1 year ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Tools
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Currently, the autoconfig stages include:

  1. discovery of hub within Ethernet or IP multicast domains
  2. discovery using DNS with domain suffixes obtained from DHCP
  3. discovery using pre-configured security credentials

The first stage needs to get extended to include mDNS / DNS-SD queries to discover locally available hub. Anecdotally, mDNS queries have higher chance to work than other protocols, even though they utilize the same IP multicast. This is a result of optimizations some hardware vendors did to allow mDNS to work while limiting multicast capabilities.

History

#1 Updated by Junxiao Shi over 1 year ago

  • Description updated (diff)

Will autoconfig use NDN Interest/Data over mDNS, or will it use non-NDN packets?

#2 Updated by Junxiao Shi over 1 year ago

Alex reveals at 20160526 call that a UCLA student is designing an alternate to this approach.

#3 Updated by Junxiao Shi about 1 month ago

Anecdotally, mDNS queries have higher chance to work than other protocols, even though they utilize the same IP multicast. This is a result of optimizations some hardware vendors did to allow mDNS to work while limiting multicast capabilities.

Do we have access to such hardware? Without having the device, this is an imaginary problem.

Does the device perform deep packet inspection (DPI) and identify mDNS traffic, or only look at the port numbers? If there is no DPI, NFD can be configured to use mDNS's multicast address and port number.

Also available in: Atom PDF