In message <[email protected]> Michael Richardson writes: > while reading drafts on the airplane, I have come to think that picking > any specific name a la ".local" for the homenet name service is fraught > with RFC1918-like confusion. For the actual printer and refridgerator > (which does not move, but needs to talk to the TV) it's not a big deal, > but for mobile devices, I think it's gonna lead to confusion. > > When I'm at your house, and I visit "fridge.local", do I get your > fridge, or mine? Assuming I want mine, if I've discovered it when I was > at home, how would I bookmark and remember it, assuming it had a GUA? > > I therefore propose adding a level of indirection (because that solves > every problem....), which (mobile) hosts will ideally become aware of. > > I think of this as a layer above the current LLMNR/mDNS/Bonjour++ layer.
If you have your own domain, whether by default you get your fridge or the one at the site that you are at depends on whther your domain is ahead or or after sitelocal in your DNS search path. This affect only how a short name like fridge gets expanded into a FQDN. You can still access either fridge. Printer might be a good example. Use the one at home or have a copy printed where you are now. I've printed things from remotely a few times for my wife to pick up at home and sign. And I've also wanted a local copy at times. > My idea is that the .homenet/.local discovery protocol would, in > addition to the AAAA ULA or GUA record, would provide a reference a > unique name which might not be globally resolvable from the DNS root, > but can be resolved by arrangement. This would be not unlike > split-horizon DNS, but given IPv6 reachability, no VPN necessary. If I'm at your house I don't want to have to configure your router so I can talk to my printer. Also, not local can mean on a mobile device including a mobile phone or at a WiFi hotspot. I don't think the barista is going to allow you to configure their router to share with you local DNS. > For sites where mglt-name-delegation works, great, use that! > For those where this doesn't work, we need a new well known name. > Perhaps it can find a "logical" place in arpa. Let's say it's based > upon the ULA, and the home with prefix A:B:C:D gets > D.C.B.A.homenet.arpa. (add this to DNS search path...) > > When an application resolves fridge.local, if the fridge has a GUA > which it has provided to the CPE's DNS server, then it also returns a > pointer to the "long-term name" (probably in a new RR) like > "fridge.D.C.B.A.homenet.arpa". Any bookmarks and the like would contain > that address (HTTP/HTML has existing mechanisms to deal with this), > other applications might see this as the canonical name. (getaddrinfo(3) > already has a canonname) > > My idea is that given IPv6 reachability for the HOME's CPE(s), that a > mobile recursive (secure) DNS resolver can learn to make queries for > D.C.B.A.homenet.arpa. directly to the home CPE, even when the mobile > device is not "at home". > > The mobile device needs to be "pair"ed with the CPE such that it agrees > to do this side-ways lookup. It's pretty much identical to a windows > desktop joining an AD (but I can't speak to the "home edition" being > able to do that... don't do windows). > > This process is, I admit, a form of walled garden DNS, something I've > argued against as being unnecessary. I'd rather that the ISPs provided > a name, but I feel that ISPs won't be very fast to offer this, and for > the home user with no native IPv6 (using a managed tunnel, for > instance), that a protocol such as I am suggesting, would provide a > clear value (something people would brag about to their friends...) > without requiring people to "wait" for their ISP. > > This does not replace "fridge.local" referring to the fridge on the > network that you are on, but it does provide a way to easily discover > and then bookmark "my fridge". > > (written offline using xemacs on android) > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
