On 14/03/13 05:21, Stuart Cheshire wrote:
There's been some discussion about service discovery. Anyone who prints
wirelessly from their iPhone or iPad without typing in an IP address is
using service discovery. Anyone who’s watched video on a web page on
their iPad, and then tapped the screen to transfer the video playback to
their television, without typing in its IP address, is using service
discovery. Anyone who’s streamed music from their iPhone to their
wireless AirPlay speakers, or controlled their TiVo from its iPad app,
or shown a slide show from their phone on a friend's television screen,
or given a university lecture by beaming their presentation wirelessly
from their laptop to the video projector, all without typing in any
names or IP addresses, has been using service discovery.
This is all commonly done today, but generally only on the local link.
We'd like similar ease of use in larger networks too. I recently
submitted this draft:
<http://www.ietf.org/id/draft-cheshire-mdnsext-hybrid-01.txt>
<snip very illuminating details>
Here at IETF, the records are added to the DNS manually by our capable
network volunteers. The idea of the Hybrid Proxy is to populate the DNS
namespace automatically, making Wide Area DNS-Based Service Discovery
available to a broader community of users.
I'm concerned that that basis of this whole discovery mechanism is the
"domain name" DHCP option.
The service discovery mechanism has now migrated to the DNS, so all
services are potentially discoverable from anywhere; that's good. But
the concept of what's "local" is now hung exclusively on the value of
DHCP option 15. DHCP option 15 most be one of the most overloaded and
least well characterised of any DHCP options. Lots of homenet-type
installations will have it set to ".lan" or something similar. Some will
set it to ".local" only to discover that the .local TLD has been
usurped. It's used frequently as substitute for the "domain name search
list" option but concatentating more than one domain with spaces, for
clients which don't support the later option. It's somewhat succeeded by
the FQDN option, and therefore not supplied. DHCPv6 doesn't have, AFAIR
an equivalent, only the FQDN option.
Now, we want to overload with yet another meaning. Is that wise?
Wouldn't defining a new option be better?
Simon.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
