Zero configuration networking

http://en.wikipedia.org/wiki/Zero_configuration_networking

 

Zero configuration networking
From Wikipedia, the free encyclopedia
Jump to:navigation, search
Zero configuration networking (zeroconf), is a set of techniques that automatically creates a usable Internet Protocol (IP) network without manual operator intervention or special configuration servers.
Zero configuration networking allows inexpert users to connect computers, networked printers, and other network devices and expect a functioning network to be established automatically. Without zeroconf, a user must either set up special services, like Dynamic Host Configuration Protocol (DHCP) and Domain Name System services (DNS), or set up each computer's network settings manually, which may be difficult or impossible for non-technical or novice users.
Zeroconf is built on three core technologies:
Assignment of numeric network addresses for networked devices (link-local address autoconfiguration)
Automatic resolution and distribution of computer hostnames (multicast DNS)
Automatic location of network services, such as printing devices through DNS service discovery. The Internet Protocol Suite
Application Layer
BGP · DHCP · DNS · FTP · GTP · HTTP · IMAP · IRC · LDAP · Megaco · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · RTSP · SDP · SIP · SMTP · SNMP · SOAP · SSH · Telnet · TLS/SSL · XMPP · (more)
Transport Layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
Internet Layer
IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec · (more)
Link Layer
ARP/InARP · NDP · OSPF · Tunnels (L2TP) · PPP · Media Access Control (Ethernet, DSL, ISDN, FDDI) · (more)
This box: view • talk • edit
Contents
[hide]
1 Address selection
2 Name resolution
3 Service discovery
3.1 Apple's protocol: Multicast DNS/DNS-SD
3.2 Microsoft's protocol: UPnP SSDP
3.3 Efforts toward an IETF standard protocol
4 Standardization
5 Major implementations
5.1 Apple Bonjour
5.2 Avahi
5.3 Windows CE 5.0
5.4 Link-local IPv4 addresses
6 See also
7 References
8 External links

[edit] Address selection
Both IPv4 and IPv6 have standard methods for address autoconfiguration. For link-local addressing IPv4 uses the special block 169.254.0.0/16 as described in RFC 3927 while IPv6 hosts use the prefix fe80::/16.
Most IPv4 hosts use link-local addressing only as a last resort when a DHCP server is unavailable. An IPv4 host otherwise uses its DHCP-assigned address for all communications, global or link-local. One reason is that IPv4 hosts are not required to support multiple addresses per interface, although many do. Another is that not every IPv4 host implements distributed name resolution (e.g., multicast DNS), so discovering the autoconfigured link-local address of another host on the network can be difficult. However, discovering the DHCP-assigned address of another host also requires either distributed name resolution or a unicast DNS server with this information, and some networks feature DNS servers that are automatically updated with DHCP-assigned host and address information.
Because IPv6 hosts are required to support multiple addresses per interface, nearly every IPv6 host configures a link-local address even when global addresses are available. IPv6 hosts may additionally self-configure one or more global address(es) on receipt of one or more router advertisement message(s), thus eliminating the need for a DHCP6 server; see RFC 4862.
Both IPv4 and IPv6 hosts may randomly generate the host-specific part of an autoconfigured address. IPv6 hosts can use a factory-assigned 48-bit IEEE MAC address, which has the advantage of being globally unique. In every case, every host is required to ensure, through broadcast queries, that the addresses it generates are not in use by any other host on the local network.
The technique is called Link-Local address assignment in RFC 3927. However, Microsoft refers to this as Automatic Private IP Addressing (APIPA) or Internet Protocol Automatic Configuration (IPAC) (supported since at least Windows 98 [1]).
[edit] Name resolution
In 2000, Bill Manning and Bill Woodcock described the Multicast Domain Name Service[2] which spawned the implementations by Apple and Microsoft. Both implementations are very similar. Apple's Multicast DNS (mDNS) is an open specification, while Microsoft's Link-local Multicast Name Resolution (LLMNR) is little used and the specification is not an IETF standards track publication. The latter was published as informational RFC 4795.
The two protocols have minor differences in their approach to name resolution. mDNS allows a network device to choose a domain name in the local namespace and announce it using a special multicast IP address. This introduces special semantics for the local domain,[3] which is considered a problem by some members of the IETF.[4] The current LLMNR draft allows a network device to choose any domain name, which is considered a security risk by some members of the IETF.[5] mDNS is compatible with DNS-SD as described in the next section, while LLMNR is not.[6]
[edit] Service discovery
[edit] Apple's protocol: Multicast DNS/DNS-SD
Multicast DNS (mDNS) is a protocol that uses APIs similar to unicast Domain Name System but implemented over a multicast protocol. Each computer on the LAN stores its own list of DNS resource records (e.g., A, MX, SRV) and joins the mDNS multicast group. When an mDNS client wants to know the IP address of a PC given its name, mDNS client sends a request to a well-known multicast address; the PC with the corresponding A record replies with its IP address. The mDNS multicast address is 224.0.0.251 for IPv4 and ff02::fb for IPv6 link-local addressing.
DNS based Service Discovery (DNS-SD) is the other half of Apple's solution, built on top of the Domain Name System. It is used in Apple products, many network printers and a number of third party products and applications on various operating systems. The Apple solution uses DNS messages, in contrast to Microsoft's competing technology, SSDP, which uses HTTP messages. It uses DNS SRV, TXT, and PTR records to advertise Service Instance Names. The hosts offering services publish details of available services: instance, service type, domain name and optional configuration parameters. Service types are given informally on a first-come basis. A service type registry is maintained and published by DNS-SD.org.
Many Mac OS X networking clients, such as the Safari browser and the iChat instant messaging software, use DNS-SD to locate nearby servers. On Windows, some instant messaging and VoIP clients, for example Gizmo5, support DNS-SD. Some Linux distributions also include DNS-SD functionality.
mDNS/DNS-SD was developed by Apple Computer employee Stuart Cheshire in the company's move from AppleTalk to IP.
[edit] Microsoft's protocol: UPnP SSDP
Simple Service Discovery Protocol (SSDP) is a UPnP protocol, used in Windows XP and several brands of network equipment. SSDP uses HTTP notification announcements that give a service-type URI and a Unique Service Name (USN). Service types are regulated by the Universal Plug and Play Steering Committee.
SSDP is supported in many SOHO firewall appliances, where host computers behind it may pierce holes for applications. It is also used in media center systems, where media exchange between host computers and the media center is facilitated using SSDP.
[edit] Efforts toward an IETF standard protocol
Service Location Protocol (SLP), the only protocol for service discovery to have reached the IETF Proposed Standard status, is supported by Hewlett-Packard's network printers, Novell, and Sun Microsystems, but ignored by some other large vendors. SLP is described in RFC 2608 and RFC 3224 and implementations are available for both Solaris and Linux.
[edit] Standardization
RFC 3927, a standard for choosing addresses for networked items, was published in March 2005 by the Zeroconf IETF working group, which included individuals from Apple, Sun, and Microsoft.[7]
LLMNR was submitted for official adoption in the DNSEXT IETF working group, however failed to gain consensus and thus has been published as informational RFC only: RFC 4795.[8] Following the failure of LLMNR to become an Internet standard Apple was asked by the IETF to submit the mDNS/DNS-SD specs for publishing as informational RFC as well, given that mDNS/DNS-SD is used much more widely than LLMNR. They are currently published as an Internet Draft[9].
RFC 2608, the SLP standard for figuring out where to get services, was published by the SVRLOC IETF working group.[10]
As of December 2009, the IETF is actively planning to publish the Apple Multicast DNS specification (draft-cheshire-multicastdns-08.txt) as an RFC. That document has been placed into Last Call by the IESG, which is the IETF's management committee. IETF approval of the mDNS document is likely to happen by end of December 2009. It is not yet clear whether this will be an Informational RFC or a standards-track RFC.
[edit] Major implementations
[edit] Apple Bonjour
A widely adopted zeroconf solution is Bonjour (formerly known as Rendezvous) from Apple Inc., which uses multicast DNS and DNS Service Discovery. Apple changed its preferred zeroconf technology from SLP to mDNS and DNS-SD between Mac OS X 10.1 and 10.2, though SLP continues to be supported by Mac OS X.
Apple's mDNSResponder has interfaces for C and Java[11] and is available on BSD, Mac OS X, Linux, other POSIX based operating systems and Windows. The Windows downloads are available from Apple's website.[12]
[edit] Avahi
Avahi is a Zeroconf implementation for Linux and BSDs. It implements IPv4LL, mDNS and DNS-SD. It is part of most Linux distributions, and is installed by default on some. If run in conjunction with nss-mdns it also offers host name resolution.[13]
Avahi also implements binary compatibility libraries that emulate Bonjour and the historic mDNS implementation Howl, so software made to use those implementations can also utilize Avahi through the emulation interfaces.
[edit] Windows CE 5.0
Windows CE 5.0 includes Microsoft's own implementation of LLMNR, which is not Bonjour compatible.
[edit] Link-local IPv4 addresses
There are some implementations available:
Windows and Mac OS have both supported link-local addresses since 1998. Apple released its open-source implementation in the Darwin bootp package.
Avahi contains an implementation of IPv4LL in the avahi-autoipd tool.
zcip (Zero-Conf IP)
BusyBox can embed a simple IPv4LL implementation
Stablebox, a fork from Busybox, offers a slightly modified IPv4LL implementation named llad.
zeroconf, a package based on Simple IPv4LL, a shorter implementation by Arthur van Hoff.[14]
The above implementations are all stand-alone daemons or plugins for DHCP clients that only deal with link-local IP addresses. Another approach is to include support in new or existing DHCP clients:
Elvis Pfützenreuter has written a patch for the uDHCP client/server.[15]
dhcpcd is an opensource DHCP client for Linux and BSD that includes IPv4LL support. It is included as standard in NetBSD.
Neither of these implementations addresses kernel issues like the broadcasting of ARP replies[16] or closing of existing network connections.
[edit] See also
Avahi (software)
Sleep Proxy Service, also known as Bonjour Sleep Proxy[17]
Universal Plug and Play
Wireless Zero Configuration
[edit] References
Erik Guttman (2001). "Autoconfiguration for IP Networking: Enabling Local Communication". IEEE Internet Computing 5 (3): 81–86. doi:10.1109/4236.935181. 
1. ^ How to use automatic TCP/IP addressing without a DHCP server
2. ^ Multicast Domain Name Service
3. ^ Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
4. ^ Re: Summary of the LLMNR Last Call
5. ^ Summary of the LLMNR Last Call
6. ^ More details on the differences
7. ^ Zero Configuration Networking (zeroconf) Charter
8. ^ DNS Extensions (dnsext) Charter
9. ^ Multicast DNS I-D
10. ^ Service Location Protocol (svrloc) Charter
11. ^ MacDevCenter.com - A Rendezvous with Java
12. ^ Apple - Support - Downloads - Bonjour for Windows 1.0.4
13. ^ nss-mdns 0.10
14. ^ http://www.zeroconf.org/AVH-IPv4LL.c
15. ^ [udhcp] Fwd: Zeroconf in udhcpc
16. ^ AIR Wiki: Link-Local ARP Measurements
17. ^ "Mac OS X v10.6: About Wake on Demand (Apple Article HT3774)" (in several languages). Apple. 2009-08-27. http://support.apple.com/kb/HT3774. Retrieved 2009-09-15. "Setting up Wake on Demand", "Setting up a Bonjour Sleep Proxy" 
[edit] External links
JmDNS, a pure Java implementation of mDNS/DNS-SD
pyZeroConf, a pure Python implementation of mDNS/DNS-SD
Mono.Zeroconf, a cross platform (Linux, Windows, Mac), unified Mono/.NET library for Zeroconf, supporting both Bonjour and Avahi
Multicast DNS Specification
DNS-Based Service Discovery Specification
Zeroconf.org - Stuart Cheshire's page, including internet drafts.
dns-sd.org DNS based Service