Feature #3465
open
Extend client auto-configuration stages to include mDNS/DNS-SD
Added by Alex Afanasyev almost 9 years ago.
Updated about 4 years ago.
Description
Currently, the autoconfig stages include:
- discovery of hub within Ethernet or IP multicast domains
- discovery using DNS with domain suffixes obtained from DHCP
- 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.
Related issues
1 (1 open — 0 closed)
- Description updated (diff)
Will autoconfig use NDN Interest/Data over mDNS, or will it use non-NDN packets?
Alex reveals at 20160526 call that a UCLA student is designing an alternate to this approach.
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.
- Description updated (diff)
- Target version deleted (
v0.5)
According to recent tests, although mDNS is widely available, many commercial APs are blocking unicast traffic. Even if mDNS helps finding the router, it isn't useful when unicast is blocked. Thus, 20180110 call decides to go with server-based solutions first.
- Related to Feature #3840: mDNS discovery of other NFD nodes on WiFi network added
- Tags set to needs-discussion
Also available in: Atom
PDF
Updated by 
Updated by