|
|
|
|
|
ZeroconfZeroconf or Zero Configuration Networking is the name for a set of technologies to allow two or more computers to communicate with each other without any external configuration. A typical usage scenario would involve two laptops connected with a cross-over Ethernet cable or ad-hoc wireless network. The goal is thus to obtain a functioning IP networking, without dependence on infrastructure (DHCP server, DNS server, etc.) or expert knowledge (e.g. RFC 1918 addressing). Zeroconf was initially pioneered by now Apple-employee Stuart Cheshire as part of Apple's transition from AppleTalk to IP; it is now adopted by many makers of network devices. One good example is network printers. Many printers have no screen or keyboard for users to enter IP addresses and subnet masks, so they often have to set themselves up automatically if normal humans are to use them. Many network printers and network storage devices available today implement some form of Zeroconf-compatible networking. Components Zeroconf tackles four separate issues: - 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.
- Allocate IP Multicast addresses without a MADCAP server.
Dynamic allocation of IP addresses For IPv4, there is one standard to handle automatic allocation of link-local IPv4 addresses in the 169.254.0.0/16 range. The official Ipv4 Link-local draft was published as RFC 3927 in March 2005. IPv6 supports dynamic allocation of IP address by design. Name resolving without DNS server For name resolving, there are two competing solutions: mDNS is propagated by Apple Computer (Stuart Cheshire), and has working implementations. LLMNR is promoted by Microsoft (Bernard Aboba), and is still discussed within the IETF. However, LLMNR has no implementations yet. In general, mDNS has better software backup, but LLMNR has more standards track backup. Though the protocols are very similar, they are not compatible. On a technical level, both protocols work by specifying a specific IP multicast address, where all computers listen and respond to. Each hosts picks a hostname in the .local (dotlocal) domain, and announces this on the IP multicast address. A conflict resolution mechanism prevents collisions. Technically, mDNS and LLMNR do not depend on link-local IPv4 addresses, but they can be used in conjunction. The differences between mDNS and LLMNR are very minor, and handle for example the way the TTL (time to live) parameter of the IP packets are set. Service Discovery To make things even worse, there are at least as many as three competing, non-compatible solutions to tackle service discovery: Beside these three protocols, which are primarily focused on discovery of services in a link-local (or at least confined) network, there are also protocols which are designed for service discovery in other areas, like UDDI for Webservices and Jini for Java objects. Though it falls within the realm of Service Discovery, if falls outside the realm of Zeroconf networking. For comparison of these protocols, you should not just look at each of the specifications, but rather who is promoting or actually using them and in what circumstances and trying to assess the reasons (both technical and commercial) for that choice. In short, DNS-SD is implemented and promoted by Apple, and is a light-weight protocol. It is implemented by some vendors, including multiple printer vendors, as well. SSDP is the direct competitor of DNS-SD, and is promoted by the UPnP Forum and supported (among others) by Microsoft. Microsoft implemented UPnP in Windows XP. It is implemented by some vendors, including multiple vendors of network devices, as well. SLP is the only official standard (RFC 2608, created by the IETF srvloc working group), and there is an open source implementation available, called OpenSLP. However, the large vendors seem to move away from SLP. Apple used to support it up to Mac OS 10.1, but abandoned it in favour of DNS-SD. SSDP is considered to be more complex then DNS-SD, since SSDP uses HTTP messages and DNS-SD uses DNS message. 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. On a technical level, DNS-SD uses DNS SRV records (as described in RFC 2782) as well as DNS TXT and DNS PTR records to find out which services are running on which hosts, and to get specific details for those services. 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 Steering Committee, while DNS-SD uses a informal first-come-first-serve registration for DNS SRV Service Types. Allocate IP Multicast addresses There are no known standards or implementations which handle the automatic allocation of IP Multicast address in a Zeroconfig environment without a MADCAP server. Standardization The IETF Zeroconf working group was chartered to handle the first of these issues. http://www.ietf.org/html.charters/OLD/zeroconf-charter.html This effort, by Sun, Apple and Microsoft, was concluded in August 2004, and in March 2005 their work is expected to result in the publication of RFC 3927. However, currently it is only available as "Internet Draft zeroconf-ipv4-linklocal". http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-17.txt The IETF vision furthermore envisioned the use of Link-Local Multicast Name Resolution (LLMNR) for name resolving without DNS server. This work is carried out in the IETF DNS Extension (dnsext) working group http://www.ietf.org/html.charters/dnsext-charter.html Last, the concluded IETF Service Location (srcloc) working group defined the Service Location Protocol (SLP) to handle Service Discovery. http://www.ietf.org/html.charters/OLD/svrloc-charter.html Implementations Apple Rendezvous Despite the attempt at standardization, the most widely adopted Zeroconf solution is Rendezvous from Apple Computer, which does not follow the IETF standards, but uses a combination of IPv4 link-local IP address, Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD). Up till Mac OS 10.1, Apple supported SLP, but they abandoned that in favour of mDNS and DNS-SD starting with Mac OS 10.2. Link-Local IPv4 Addresses There are some implementations available: - Microsoft Windows and Mac OS have both supported link-local IPv4 addresses out of the box for a few years. Apple may have released this as Open Source using Darwin; the mDNSResponder open source package does not seem to handle this.
- zcip (Zero-Conf IP) implements it, but is no longer available from SourceForge.
- Simple IPv4LL, a very short implementation by Arthur van Hoff.
- http://www.dotlocal.org/
It is unclear to what extent these software implementations support all details of the specification, like the graceful transistion from a link-local address to a DHCP address as soon as a DHCP server is found on the network. Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD) mDNS and DNS-SD often seem to be implemented together. The most often used version by programmers of Applications seems to be Apple's mDNSResponder implementation, which is available on Mac OS X, Windows and Linux, and has interfaces for C and Java. http://developer.apple.com/darwin/projects/rendezvous/ http://www.macdevcenter.com/pub/a/mac/2004/08/31/osx_java.html Other implementations are: - JmDNS - Java implementation by Arthur van Hoff
- pyZeroConf - Python Multicast DNS Service Discovery
- mdnsd - embeddable Multicast DNS Daemon (no DNS-SD)
- Liaison
- Howl
References - http://ietf.org/html.charters/dnsext-charter.html -- Charter of the DNSEXT working group, which is co-ordinates the LLMNR standarization work.
- http://www.dotlocal.org/ explains more about .local addresses (which are not yet standardized by IANA, but actively used in mDNS implementations)
- LLMNR is described in http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-38.txt (Work in Progress, link may expire)
- http://www.upnp.org/ -- Industry consortium for UPnP
- http://developer.apple.com/darwin/projects/rendezvous/ - Implementation of DNS-SD by Apple Computer
- RFC 2608 - Service Location Protocol, Version 2
|
 |
| |
|
|