Feature #3465
open
Extend client auto-configuration stages to include mDNS/DNS-SD
0%
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.
Updated by Junxiao Shi about 8 years ago
- Description updated (diff)
Will autoconfig use NDN Interest/Data over mDNS, or will it use non-NDN packets?
Updated by Junxiao Shi almost 8 years ago
Alex reveals at 20160526 call that a UCLA student is designing an alternate to this approach.
Updated by Junxiao Shi over 6 years 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.
Updated by Junxiao Shi about 6 years ago
- 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.
Updated by Davide Pesavento over 3 years ago
- Related to Feature #3840: mDNS discovery of other NFD nodes on WiFi network added