Ray, I agree with the intent of RFC6281 aka Apple BTMM, although not with many of the details of the implementation.
I agree that syncing mDNS and DNS might be difficult and I propose we avoid using mDNS. A compromise is if a FQDN exists in DNS, both DNS and mDNS return a CNAME to the FQDN for local or sitelocal queries. A bad assumption is that anything on the same subnet deserves some level of trust just as a matter of having been connected to that subnet. The BTMM builds on this bad assumption by providing a means to make it appear as if remote hosts are on the same subnet or at least site by effectively using ULA as a host ID and tunneling the ULA of the remote machine. A much better way of doing things would be to use a GLA if available, particularly for IPv6 where no NAT should ever be needed. For security, on the same LAN segment or not, exchange some credential, such as a private key. This could be done at home the way most *ix people do it (put on USB stick and copy, exchange some insecure way with fingerprint verification, respect key signing by a trusted entity, etc), or for the more typical homenet customer with an insecure transfer encrypted with a shared secret (same password typed in two places, where one place could be the web page used to configure the consumer oriented junk such as printer). Delegating a sub-domain is a necessary part of any good solution that involves remote access to the homenet. sitelocal is different everywhere. <ula>.ula-based-sitelocal is unique but available only at the site. We (both in the IETF and in consumer product worlds) sometimes stand on our heads trying to work around horribly insecure home and office devices and practices that are hidden behind firewalls. Using firewalls has been proven time and again to be ineffective. In the office, one compromised PC can compromise an entire enterprise or at least the subnet it is on if weak security is in use behind the firewall. Same at home if "Mom" shows up with her old windows98 PC and an equally old PCMCIA 802.11a/b card. How may of us have been in an office where an email from IT explained that the current local network slowness is due to very high virus activity (behind the firewall!) and fear not because IT is on it? If there is a way to discover the ULA being used at a local site, then printer3.<ula>.ula-based-sitelocal is functionally equivalent to printer3.sitelocal - either way it is the printer that is found if you ask for printer3 and you (or cups) don't specificy a FQDN that you learned earlier. If the first printer3.sitelocal was a CNAME for a FQDN, then an application could cache the mapping of printer3 to that FQDN or at least inform the user of the FQDN or inform the userwhen specifying printer3 results in a different FQDN than previously. Curtis In message <[email protected]> Ray Hunter writes: I disagree. The context of my message is that there should be some identifier that can disambiguate the namespace per Homenet. I'm talking about using the ULA to generate a HomenetID for use in the namespace. See RFC6281. The HomenetID and DNS subomain (or as you put it "<somethingveryobscure>") may be generated by one unique host (e.g. each Homenet border router) based on a ULA. But that does not mean it cannot be discovered by all hosts and routers in the Homenet (via some bunch of discovery mechanisms such as automatic prefix distribution for router-router and DHCPv6 for router - fridge). The HomenetID will remain constant as long as the ULA of the border router remains constant. If it appears to vary (because the border router changes) then highly mobile nodes will get some indication that they may not be connected to their own Homenet, and ask for user input to accept an update. Static nodes would only know their local HomenetID, and if it changed they could be set to always accept the update without user input. Eventually you would probably end up with a search list linked to the number of border routers the end node has ever encountered, but end nodes can automatically age out old entries. We might also want to be able to manually override the auto-generated HomenetID to cover the case where border router hardware is replaced by the user, but that's no different to MAC address cloning on CPE's in the past (where ISPs used the MAC address of the CPE as an identifier in management systems). Sure there's a downside in complexity of the namespace. The potential upside of this approach is that the same <somethingveryobscure>.sitelocal. zone file could also be mounted as a secondary on <somethingveryobscure> .<ISP DNS root> or <somethingveryobscure> .<employer's DNS root> if the ISP or enterprise wished to provide this service for global name resolution. Highly mobile nodes would only need two items in their DNS search list, the search list can be pretty much auto-generated, and they can use the same name resolution technology (DNS) wherever they are located. It also completely avoids trying to synch mDNS with DNS, which I think you'll agree is likely to be very difficult. > Curtis Villamizar <mailto:[email protected]> > 4 August 2012 22:06 > With all due respect, any suggestion to use the ULA in a domain name > produces either a domain that is unique to one host or a domain that > is every bit as global as sitelocal, depending on whether by stating > "ULA prefix" you mean the local ULA or the well-known global ULA > prefix. > > In rfc4193: > > Local IPv6 unicast addresses have the following characteristics: > > - Globally unique prefix (with high probability of uniqueness). > > - Well-known prefix to allow for easy filtering at site > boundaries. > > [...] > > If you mean the first (the local ULA prefix), then the domain is > unique to one host. My computer could never find my fridge using the > hostname "fridge" unless it knew every ULA on the local network and > created an entry in the dns search path. Very long entries in the dns > search path are a very bad thing (tm). > > If you means the second (the assigned prefix under which all ULA fall) > then the domain is common to all hosts in the universe that generate a > ULA address. The only difference is it is > <host>.<somethingveryobscure>.sitelocal. > > Curtis > > > In message <[email protected]> > ------------------------------------------------------------------------ _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
