On Sat, Mar 10, 2012 at 7:51 PM, Randy Turner <[email protected]> wrote: > > Just seems like the IETF has tried to address one of our requirements (zero > configuration) in the past -- if the IETF has already published proposed > standards for zero configuration, why wouldn't we look at this first? Or at > least "cherry pick" what we like from this effort. > > R. >
This seems like a good place to briefly describe the mDNS extensions we proposed in https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/ LLNs are a primary target. Since an LLN's definition of "link-local" means first-hop neighbors, the first change is to use the site-local multicast address FF05::FB to make sure the whole mesh is covered. Next, since the behavior of name resolution for .local names is completely defined by the mDNS draft (and tens of millions of extant resolvers) we decided to define another special TLD .site. As there are currently no legacy implementations, we have some latitude to modify the way certain fields like hop limit are used. When it comes to routing behavior, there are three possibilities: a router *always* forwards xmDNS out the other "in scope" ports (e.g. this is the defined behavior of interior mesh nodes), a router *never* forwards xmDNS (e.g. across the HAN/ISP border), or it *may* forward xmDNS. This last one is tricky one. The xmDNS draft does not take a position (yet, anyway) on how to define a site boundary. It may be that there are several in a single homenet. We probably don't want LLNs to be over- whelmed by discovery packets from an adjacent ethernet link and might choose to put a proxy there instead; one that selectively forwards requests or at least shapes the traffic at that border. I note that the current arch draft is virtually silent on the matter of multi- cast forwarding. It seems to me that we really must ultimately declare multicast forwarding to in or out of scope. I favor the former, since we should anticipate applications like multi-player online games or media distribution inside the home. One possible candidate is MLD Proxy (RFC 4605) but then we'd have to come up with a way to form a tree. -K- _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
