Zero-configuration networking

From Wikipedia, the free encyclopedia
  (Redirected from Zero configuration networking)
Jump to: navigation, search

Zero-configuration networking (zeroconf) is a methodology and a set of special technologies that automatically creates a usable computer network based on the Internet Protocol Suite (TCP/IP) when computers or network peripherals are interconnected. It does not require manual operator intervention or special configuration servers.

Zeroconf is built on three core technologies: assignment of numeric network addresses for networked devices, automatic distribution and resolution of computer hostnames, and automatic location of network services, such as printing devices. Without zeroconf, a network administrator must set up services, such as Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS), or configure each computer's network settings manually.

Background[edit]

Basic concepts[edit]

Computer networks use numerical addresses to identify communications endpoints in a network of network-enabled devices. In modern networking protocols, every "packet" contains the source and destination addresses, allowing equipment on the network to examine and forward the data packet in the proper direction. These numbers are not intended to be human-readable, and may be reassigned as the network configuration changes.

This presents a problem of identifying devices to the end user. For one, it requires the device to display its address, which may not be easy for small devices with limited interfaces, like printers. For some time it was common to see addresses written on tape on the front of the devices. Even if the user can determine the address, while it is possible for the user to type in short addresses, like 100 or even the longer 10.165.43.27 style used for most internet addresses based on IPv4, this fails for systems like IPv6 where the addresses are very long and the chance of correctly typing in the full address without errors is low.

To address this problem, many networking systems include some sort of directory service, a database that allows human-readable names to be assigned to the numeric addresses. Computer software asking the user to identify a device instead asks them to type in a name, and then the software asks the database to translate that to an address. The software then uses the provided address for further communications with the other network devices. Data from the database is automatically collected and distributed so it is always up-to-date and reflects changes in addresses.

LAN vs. WAN[edit]

For much of the early history of computing, network protocols tended to fall into two rough groups - those intended to connect together local devices into a local area network (LAN), and those intended primarily for long-distance communications, or wide area networking (WAN). WAN systems tended to have centralized setup, where an "authority" of some sort would assign addresses and names, often using entirely manual means. This was not out of keeping with the telecommunications networks they were generally built on, which generally required considerable work to set up even a conventional telephone line.

LAN systems tended to automate these tasks to one degree or another, so that new equipment could be added to a LAN with a minimum of operator intervention. The canonical example of a zero-configuration LAN system is AppleTalk, a protocol introduced by Apple Inc. for the early Macintosh computers in the 1980s. Macs, as well as other devices supporting the protocol like the Apple IIGS and a variety of printers and file servers, could be added to the network simply by plugging them in - all further configuration was completely automated. Network addresses were automatically selected by each device using a protocol known as AARP, while each machine built its own local directory service using a protocol known as NBP. NBP included not only a name, but the type of device and any additional user-provided information like its physical location or device status. Users could look up any device on the network using an application known as Chooser, which filtered names based on the device type.

Since the late 1990s, Internet Protocol (IP), originally a long-distance solution, increasingly and then almost universally took over all roles. Having been designed for the WAN, IP generally lacked the auto-configuring systems of LAN protocols like AppleTalk or Novell NetWare. This has led to the introduction of a number of new protocols providing these services using IP data.

Address selection[edit]

Internet protocols assign objects in the network one or more unique IP addresses that identify them to other devices on the same network. These addresses operate in a fashion similar to telephone numbers, allowing devices to connect to each other by identifying the remote device by its address in the same way that a telephone call is connected by dialling in a telephone number.

Unlike the phone system, an IP network does not necessarily include some sort of central authority that assigns these addresses as new devices are added. Mechanisms were introduced to handle this task, and both IPv4 and IPv6 now include systems for address autoconfiguration, which allows a device to determine a safe address to use through simple mechanisms. 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::/10. More commonly, in modern networks addresses are assigned by a DHCP server, often built-in to common networking hardware like computer hosts or routers.

Most IPv4 hosts use link-local addressing (IPv4LL) 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.

IPv6 hosts are required to support multiple addresses per interface; moreover, every IPv6 host is required to configure a link-local address even when global addresses are available. IPv6 hosts may additionally self-configure one or more global addresses on receipt of one or more router advertisement messages, thus eliminating the need for a DHCP6 server; see RFC 4862.[1]

Both IPv4 and IPv6 hosts may randomly generate the host-specific part of an autoconfigured address. IPv6 hosts generally combine a prefix of up to 64 bits with a 64-bit EUI-64 derived from the factory-assigned 48-bit IEEE MAC address. The MAC address has the advantage of being globally unique, a property inherited by the EUI-64. The host is normally required to ensure, through multicast 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.[2] However, Microsoft refers to this as Automatic Private IP Addressing (APIPA)[3] or Internet Protocol Automatic Configuration (IPAC) (supported since at least Windows 98[4]).

Name resolution[edit]

Internet protocols use IP addresses for communications, but these are not really human-readable; IPv6 in particular uses very long strings of digits that are not easily entered manually. To address this issue, the internet has long used the Domain Name Service (DNS), which allows human-readable names to be associated with IP addresses, and includes code for looking up these names from a hierarchical automatically-configured database system. Users type in common names, like wikipedia.org, which the computer's DNS software looks up in the remote DNS databases, translates to the proper IP address, and then hands off that address to the networking software for further communications.[5]

Looking up a DNS address requires the IP address of the DNS server to be known. This has normally been accomplished by typing in the address of a known server into a field in one of the devices on the network. In early systems this was normally required on every device, but this has been pushed up one layer in the hierarchy to the DHCP servers or wide-area network devices like cable modems that receive this information from their IP provider. This has reduced the user-side administration load and provides a key element of zero-configuration access.[5]

DNS was intended to provide names to entire groups of devices, like wikipedia.org, provided by a naming service. Traditional DNS servers were not intended to be easily modified or self-configured. Assigning an address to a local device, say thirdfloorprinter.wikipedia.org, normally requires administrator access to the DNS server and is accomplished manually. Additionally, traditional DNS servers are not expected to automatically correct for changes in configuration. For instance, if a printer is moved from one floor to another it might be assigned a new IP address by the local DHCP server, something traditional DNS servers cannot correct for.[5]

To address this need, in 2000, Bill Manning and Bill Woodcock described the Multicast Domain Name Service[6] which spawned the implementations by Apple and Microsoft. Both implementations are very similar. Apple's Multicast DNS (mDNS) is published as the standards track proposal RFC 6762, 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 DNS namespace and announce it using a special multicast IP address. This introduces special semantics for the local domain,[7] which is considered a problem by some members of the IETF.[8] 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.[9] mDNS is compatible with DNS-SD as described in the next section, while LLMNR is not.[10]

Service discovery [edit]

mDNS provides the ability to provide and find DNS names for local devices, however, it does not provide information about the type of device or its status. A user looking for a nearby printer, for instance, might be stymied if the printer was given the name "Bob".

This is the purpose of the service discovery protocols (SDP), which provide the concept of "discoverability". SDP systems have sometimes been combined with naming services, as in Apple's NBP, while many systems lacked this concept, like VINES. SPD is a relatively new addition to IP.

DNS-based service discovery[edit]

DNS-SD is described in RFC 6763. This standard allows clients to discover a named list of services by type in a specified domain using standard DNS queries. The service instance can be described using a DNS SRV (RFC 2782) and DNS TXT (RFC 1035) record. This specification is compatible with both Multicast DNS and with existing unicast DNS server and client software. A client discovers the list of available instances of a given service type using a query for a DNS PTR [RFC1035] record with a name of the form "<Service>.<Domain>", which returns a set of zero or more names, which are the names of the aforementioned DNS SRV/TXT record pairs.

Apple's multicast DNS/DNS-SD[edit]

In 1997 Stuart Cheshire proposed[11][self-published source?] adapting Apple Computer's Name Binding Protocol for IP networks. Cheshire subsequently joined Apple and authored IETF draft proposals for Multicast DNS and DNS-based Service Discovery, supporting the transition from AppleTalk to IP networking. In 2002,[12] Apple announced an implementation of both protocols under the name Rendezvous (later renamed Bonjour), included in Mac OS X 10.2 and replacing the Service Location Protocol used in 10.1.[citation needed] In 2013, the proposals were ratified as RFC 6762[13] and RFC 6763.[14]

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 computer given its name, mDNS client sends a request to a well-known multicast address; the computer 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; see RFC 6763.[15] 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 exists,[16] maintained and published by DNS-SD.org.[17]

Many Apple Mac OS X networking clients, such as the Safari browser and the iChat instant messaging software, use DNS-SD to locate nearby servers. On MS Windows, some instant messaging and VoIP clients support DNS-SD. Some Unix, BSD, and Linux distributions also include DNS-SD functionality.

Microsoft's UPnP SSDP[edit]

Simple Service Discovery Protocol (SSDP) is a UPnP protocol, used in MS 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.

Efforts toward an IETF standard protocol[edit]

Service Location Protocol (SLP) is supported by Hewlett-Packard's network printers, Novell, and Sun Microsystems. SLP is described in RFC 2608 and RFC 3224 and implementations are available for both Solaris and Linux.

Standardization[edit]

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.[18]

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.[19]

Following the failure of LLMNR to become an Internet standard, Apple was asked by the IETF to submit the mDNS/DNS-SD specs for publication as informational RFC as well, given that mDNS/DNS-SD is used much more widely than LLMNR. In February 2013 mDNS and DNS-SD were published as Standards Track Proposals RFC 6762 and RFC 6763.

RFC 2608, the SLP standard for figuring out where to get services, was published by the SVRLOC IETF working group.[20]

Security issues[edit]

Because mDNS operates under a different trust model than unicast DNS—trusting the entire network rather than a designated DNS server, it is vulnerable to spoofing attacks by any system within the multicast IP range. Like SNMP and many other network management protocols, it can also be used by attackers to quickly gain detailed knowledge of the network and its machines.[21]

Major implementations[edit]

Apple Bonjour[edit]

Bonjour (formerly known as Rendezvous) from Apple Inc., 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[22] and is available on BSD, Apple Mac OS X, Linux, other POSIX based operating systems and MS Windows. The Windows downloads are available from Apple's website.[23]

Avahi[edit]

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.[24]

Avahi also implements binary compatibility libraries that emulate Bonjour and the historical mDNS implementation Howl, so software made to use those implementations can also utilize Avahi through the emulation interfaces.

MS Windows CE 5.0[edit]

Microsoft Windows CE 5.0 includes Microsoft's own implementation of LLMNR.

Link-local IPv4 addresses[edit]

There are some link-local IPv4 address implementations available:

  • Apple Mac OS and MS Windows have 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.
  • Zero-Conf IP (zcip).[25]
  • BusyBox can embed a simple IPv4LL implementation.
  • Stablebox,[26] a fork from Busybox, offers a slightly modified IPv4LL implementation named llad.
  • Zeroconf,[27] a package based on Simple IPv4LL, a shorter implementation by Arthur van Hoff.[28]

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.[29]
  • dhcpcd[30] 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 broadcasting ARP replies[31] or closing existing network connections.

See also[edit]

References[edit]

Notes

  1. ^ RFC 4862, IETF 
  2. ^ RFC 3927, IETF 
  3. ^ "Apipa", MS Developer Network, Microsoft 
  4. ^ "How to use automatic TCP/IP addressing without a DHCP server", Knowledge base, Microsoft 
  5. ^ a b c Marshall Brain and Stephanie Crawford, "How Domain Name Servers Work", howstuffworks
  6. ^ Manning, Multicast Domain Name Service (draft), Water springs 
  7. ^ Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard (electronic mail message), IETF 
  8. ^ Re: Summary of the LLMNR Last Call (electronic mail message), IETF 
  9. ^ Summary of the LLMNR Last Call (electronic mail message), IETF 
  10. ^ More details on the differences (electronic mail message), IETF 
  11. ^ Cheshire, Stuart, Name Binding Protocol over IP (rant) 
  12. ^ Zero conf 
  13. ^ "RFC 6762 Document History". IETF. 
  14. ^ "RFC 6763 Document History". IETF. 
  15. ^ RFC 6763, IETF 
  16. ^ Service types, DNS-SD 
  17. ^ DNS-SD 
  18. ^ Zero Configuration Networking (zeroconf) Charter, IETF 
  19. ^ DNS Extensions (dnsext) Charter, IETF 
  20. ^ Service Location Protocol (svrloc) Charter, IETF 
  21. ^ Name (MDNS) Poisoning Attacks Inside the LAN (World Wide Web log), GNU citizen 
  22. ^ A Rendezvous with Java, Mac Dev Center, 2004-08-31 
  23. ^ "Bonjour for MS Windows 1.0.4", Support, Apple 
  24. ^ Lennart, nss-mdns 0.10, DE: 0 pointer 
  25. ^ zcip, Source forge 
  26. ^ "Stable box", Code, Google 
  27. ^ Zeroconf, AU: UTS 
  28. ^ AVH IPv4LL (C source code), Zero conf 
  29. ^ "Zeroconf in udhcpc", udhcpc (electronic mail message), Busy box, May 2005 
  30. ^ Marples, Roy, dhcpcd (wiki) (project) 
  31. ^ "Link-Local ARP Measurements", AIR (wiki), NE: UVA 
  32. ^ "Mac OS X v10.6: About Wake on Demand (Apple Article HT3774)" (in several languages). Apple. 2009-08-27. Retrieved 2009-09-15. "Setting up Wake on Demand", "Setting up a Bonjour Sleep Proxy" 

Sources

  • Guttman, Erik (2001), Autoconfiguration for IP Networking: Enabling Local Communication, IEEE Internet Computing 5 (3): 81–86, doi:10.1109/4236.935181 

External links[edit]