Zero configuration Technologies
Zeroconfig networking consists of three technologies: ~- automatic configuration of IP addresses ~- name lookup of hosts ~- discovery of services
It should be noted that Zero Configuration is specifically aimed at doing these tasks without central infrastructures, so the components are actually: ~- Allocate dynamic IP addresses without a DHCP server. ~- Translate between names and IP addresses without a DNS server. ~- Find services, like printers, without a directory server.
I'm leaving out the fourth item, Allocate IP Multicast addresses without a MADCAP server, since that never got standardized in any way.
More information can be found at the [charter of the IETF zeroconf workgroup]. Be aware that the workgroup was concluded, while only standardizing the first target (allocation of IP address), since there was no concensus on the other items. www.zerconf.org, which is advertised as an //Additional Zeroconf web page// also only deals with this first item.
Automatic configuration of IP addresses
The specification is different for IPv4 and IPv6: ~- For IPv4 in RFC:3927 RFC3927. Basically, computers pick at random an address in the 169.254/16 range, and send out an ARP request to check if another host is using it. If so, they pick another IP address. Microsoft calls this Automatic Private IP Addressing (APIPA), most of the civilized world calls it (Link-Local) Self-Assigned IP addresses. ~- For IPv6 in RFC2462 (the technology) and RFC3513 (the IP ranges, section 2.5.6). Self-Assigned IP addresses fall in the range FE80::/10 (link-local) or FEC0::/10 (site-local). Since the IP range is so large, there are generally no conflicts, and even though RFC2462 defines conflict detection, it's far less sophisticated for IPv6 then for IPv4. Note that RFC 4193 also specifies how to randomly pick local IP addresses, but this is more like the usage of private IP ranges, like 192.168/16 for IPv4.
Beside the RFC itself, more information about IPv4 Link-Local Addressing can be found at [www.zeroconf.org].
Microsoft Windows and Mac OS have both supported link-local IPv4 addresses out of the box since 1998. The idea of picking random IP addresses was first used in AppleTalk, and [patented by Apple] in 1985. Microsoft first came up with the idea of doing the same thing with IPv4 addresses (though it was already done with IPv6!), and [patented] that in 1998. According to most sources, these patents are no limitation to apply this technology in free software since Apple's patents are expired by now, and //Microsoft will grant a royalty-free license//, according to their [statement to the IETF].
Name lookup of hosts
Both protocols are simular; LLMNR is hardly used but has gone further along the standardization track, and is scheduled to become IETF Proposed Standard track document, though it is not clear when that should happen, given the many rewrites. The protocol are incompatible, even though they draw from the same concept (sending DNS-like queries to a multicast address on the local subnet). Amonst others, they differ in the approach how they handle domain names (mDNS uses the .local namespace; LLMNR allows network devices to pick any name, which is [considered a security risk by the IETF community]). In addition, mDNS works seamlessly with DNS-SD, while LLMNR is incompatible with it.
The basic idea of multicast DNS is pretty simple. Normally, if a host want to find the name of another host, it consults a central DNS server. Instead, since there are no central servers, a host sends its DNS request to a IP multicast address, where most or all hosts on the local subnet are listening to as well. Whoever knows the answers to a specific question will reply to it. For mDNS, hosts will pick a hostname in the [.local] DNS name space, and announce that name. For LLMNR, a host can pick any hostname, and announce it (it is valid as long as it does not exist as a FQDN).
mDNS daeoms listen to multicast addresses 22.214.171.124 and FF0*::FB (in practive only FF02::FB is used), port 5353 LLMNR daeoms listen to multicast addresses 126.96.36.199 and FF0*::1:3 (in practive only FF02:0:0:0:0:0:1:3), port 5355 (One may wonder why IANA not just use the same IP multicast address, since they already have a different port number)
More information about mDNS can be found at [www.multicastdns.org], and more information about LLMNR can be found at [drizzle.com/~aboba]. Multicast DNS and link-local addressing are often used in conjunction, though they are not dependant on each other.
Discovery of services
Discovery of services has been standardized in many, many forms, including: ~- [DNS Service Discovery] (DNS-SD) ~- [Simple Service Discovery Protocol] (SSDP) (part of UPnP) ~- [Service Location Protocol] (SLP)
The following protocols are also designed for service discovery, but fall outside the scope of Zero configuration networks, mostly because they are high level (application or technology specific) protocols: ~- [UDDI] for webservices. Not widely used yet (URLs are often hardcoded in WSDL descriptions, since there are very little broker services) ~- Jini for Java objects: Is application (Java language) specific. ~- Salutation: relies on a central servers, the Salutation Manager (SLM). ~- Service Discovery Protocol (SDP) for Bluetooth, which is based on Salutation.
SSDP, SLP and Jini can operate with or without special directory server (often called lookup server). DNS-SD supports both multicast DNS (no directory server) as well as regular DNS (a dedicated directory). UDDI, SDP and Salutation all seem to rely on a central directory server, and are therefor no Zero configuration protocols.
http://cswl.com/whiteppr/tech/upnp.html gives an overview of the higher level service discovery protocols. Keep in mind that it refers to the suite of IPv4 self-assigned addresses, LLMNR and SSDP as "UPnP", as if they are inseperatable, while in fact they are independant of each other. Salutation seems to have died a slow dead, along with SLP, the only "officially" IETF standard.
DNS-SD works particularly well with mDNS, since it also uses DNS records. It is very much based on the use of SRV records, as described in RFC2782, but uses another level of indirection (PTR records pointing to SRV and TXT records). It can advertise services through both multicast DNS as well as regular DNS ("Wide Area Bonjour" as Apple calls it). DNS-SD is considered a lightweight protocol, and [service type registration] (e.g. _http._tcp) happens on a informal first-come-first-serve basis. More information about DNS-SD van be found at [dns-sd.org]
SSDP, on the other hand, is considered to be more complex then DNS-SD. Services in DNS-SD are specified using their Service Instance Name (SIN), which is a combination of Instance, Service Type, and Domain name. SSDP uses HTTP notification announcements to discover services as identified by a unique combination of a service type URI and a Unique Service Name (USN). The Device Control Protocols (DCP) as used by SSDP are supervised by the Universal Plug and Play (UPnP) Steering Committee. A major difference between UPnP and DNS-SD is that UPnP is more formalized, which may be an advantage or a disadvantage depending on your point of view.
Finally, a good read for a comparison between DNS-SD and SSDP is "[Understanding Zeroconf and Multicast DNS]" by Heath Johns. Despite that the article is from 20 Dec 2002.
For Software implementations of RFC3927, mDNS and DNS-SD, see ZeroconfSoftware.
More information on this wiki about ZeroConf experiments can be found at CategoryZeroconf.