In message <20120911145928.gc20...@mx1.yitter.info> Andrew Sullivan writes: > On Tue, Sep 11, 2012 at 02:45:12PM +0100, Brian E Carpenter wrote: > > Thanks. Then it seems to me that a recommendation about the desirable > > behaviour > > of getnameinfo() and getaddrinfo() needs to be made, consistent with the > > final > > recommendation for mDNS vs DNS. At least we should describe a consistent > > deployment scenario. > > But you can't _make_ such a recommendation, because different > scenarios -- network-topologically indistinguishable from one another > -- require very different conclusions. > > This is exactly the same problem MIF faced with the DNS server > selection logic. You naturally want to use the DNS server that you > believe is going to provide you with the right answers. But when you > move networks (say, into the coffeeshop which is using Stupid DNS > Tricks to authenticate you as a customer first), you actually need the > _least good_ answer sometimes, in order to move you from your > expensive mobile radio onto your cheap wifi. > > The same problem crops up here. Inside your house, mDNS is perhaps > the right answer. But for bookmarking on your laptop that you carry > on the road but want to use with your home network then, it's exactly > the wrong answer. So this once again comes down to use cases, and > trading userland functionality against complications that make the > specification complex, and implementations tricky and therefore buggy. > > To moan just a little bit, this is why many of us think that the > mutliple namespace approaches (seen in mDNS, llmnr, before those > NetBIOS, and so on) are harmful. Inevitably, these systems get hooked > up to the wider Internet, and the inconsistencies thereby revealed > make people confused. (This isn't to say there is an obvious better > answer, given the facts of the world about DNS name registration and > resolution.) > > Best, > > A > > -- > Andrew Sullivan > a...@anvilwalrusden.com
Andrew, +1 I agree that multiple namespaces are harful, and multiple additional namespaces of mDNS, llmnr, NetBIOS even more harmful. So the question is what motivated these rather than use DNS. For mDNS and I think the others it was the absense of a need to provide and pick a DHCP/dynDNS server and just multicast the identities, plus simple service discovery (though admitedly confined to a single subnet). So lets solve this for DHCP/dynDNS. I'll start with the simplest cases and move to more involved. In the case where there is nothing but a computer and printer, either the computer needs to volunteer to be DHCP server and dynDNS nameserver or addresses and names don't exist. With IPv4 and mDNS and no DHCP server there are still no addresses (unless things default to 192.168.0.1 or similar). With IPv6 there are ULA that can be used and then its just a matter of naming. If DNS is used in the above scenario, then something has to come up as the DHCP/DNS server and do dynDNS, in this case just collecting the name/ULA mapping. If a router comes up and has a GUA prefix, there needs to be a way for the computer to transfer control to the router. With DHCP server preference set appropriately, with FORCERENEW and Forcerenew Nonce Authentication, this is acheivable and reasonably secure. A multicast "I'm a DHCP server and just came up" would trigger anything acting as a DHCP server to take notice. For IPv6 this could be sent to the All_DHCP_Relay_Agents_and_Servers multicast address. AFAIK DHCP relays and servers and configured and there is no mechanism available for servers to dynamically discover other DHCP servers and coordinate as peers. The above would require very little change to DHCP or DNS. Other than that it is just usage and therefore an Information RFC or BCP is all that is needed. The case where a router comes up but has no GUA prefix and sits on two subnets also has to be handled. In that case the router may have priority over computers offering DHCP/dynDNS and the same can occur, with the router providing names and routes to ULA on each subnet. Again, no change to DHCP or DNS, just usage. If more than one router comes up and none have a GUA prefix, then they must make names available. Collecting name/ULA mappings is the same there is no means to coordinate the DNS namespace so that Router-A can announce name/ULA mappings for devices connected only to Router-B. Here an extension is needed. One possibility is that each subnet becomes a DNS zone and exactly one router connected to that subnet is selected to do DHCP/dynDNS for that subnet. The other routers must discover each other and exchange names. Reasonable default names is also an issue. Two routers named "linksys" doesn't help, just as two printers named "printer1" doesn't help. I'm not sure how (or if) mDNS solves the latter problem. I suspect it doesn't. What might be needed is a means for a DHCP server to assign a host name based on what the client sent with a digit (or two if needed) appended to the conflicting name. A similar technique could be applied to routers coming up with the same name. In past postings I have suggested that a router without a GUA prefix snd a DHCP request as a client first and try to obtain a GUA prefix, and absent of that try to negociate with other DHCP servers over what address to use and how to divide up the sitelocal name space. Another case is where a router comes up and has a GUA prefix or has discovered one (service provider link came up, one got configured, etc). A lot of FORCERENEW exchanges would occur and hosts would get GUA addresses. Subdividing the GUA prefix would be based on number of hosts reported per subnet and margins for growth to avoid additional FORCERENEW as new hosts came up on an existing subnet. Another case for address allocation is more than one router coming up with different GUA prefixes. Each would subdivide, and hosts could now be offerred more than one address (if DHCP supported it) or a tie breaker is need (shortest route, plus other tie breaker) to pick a GUA. The former is better so a change in route costs does not require a FORCERENEW. The last case for address allocation is more than one router with the same GUA prefix. One has to be picked to subdivide the GUA prefix. Otherwise not much changes. A second dimension is the root of the namespace. If the initial root is .sitelocal and a router comes up with (or somehow discovers) a DNS domain for which it is authoritative (ie: primary), then FORCERENEW is needed to change the domain name and likely also the DNS nameserver list, though other routers could be granted secondary. The dynamic namespace can then be subdivided among subnets creating zones in the DNS namespace rooted at "." rather than at ".sitelocal". btw- Using DNSSEC with ".sitelocal" requires manual key exchange and may not be practical. If two (or more) routers come up with different namespaces rooted at ".", then the addresses space can be in both forward lookups. If there are also two (or more) GUA (highly likely) then the rDNS for the GUA provided by each router can point to the zone provided by that router if it is also authoritative for a GUA prefix. The only other motivation for mDNS and friends is service discovery. LL scope multicast work on a subnet. Site local multicast is now depricated but prior proposals for service discovery anycast have suggested gradually increasing TTL on a globally scoped multicast. The semantics here are different from mDNS and friends. In mDNS a LL multicast says "I am a <service>" where in anycast the host says "are there any <service> out there" and can therefore find services off subnet by increasing TTL until <service> is found. (ie: printer). Curtis _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
