Zero-configuration networking: Difference between revisions

Revision as of 00:43, 9 October 2022

Revision as of 16:58, 6 November 2022

Line 10:

Computer networks use numeric [[network address]]es to identify communications endpoints in a network of participating devices. This is similar to the [[Plain old telephone service|telephone network]] which assigns a string of digits to identify each telephone. In modern [[networking protocol]]s, information to be transmitted is divided into a series of [[network packet]]s. Every packet contains the source and destination addresses for the transmission. [[Network router]]s examine these addresses to determine the best network path in [[Packet forwarding|forwarding the data packet]] at each step toward its destination.

Similarly to telephones being labeled with their telephone number, it was a common practice in early networks to attach an address label to networked devices. The dynamic nature of modern networks, especially residential networks in which devices are powered up only when needed, desire dynamic address assignment mechanisms that do not require user involvement for initialization and management. These systems automatically give themselves common names chosen either by the equipment manufacturer, such as a brand and model number, or chosen by users for identifying their equipment. The names and addresses are then automatically entered into a [[directory service]].

Early computer networking was built upon technologies of the telecommunications networks and thus protocols tended to fall into two groups: those intended to connect local devices into a [[local area network]] (LAN), and those intended primarily for long-distance communications. The latter [[wide area network]] (WAN) systems tended to have centralized setup, where a [[network administrator]] would manually assign addresses and names. LAN systems tended to provide more automation of these tasks, so that new equipment could be added to a LAN with a minimum of operator and administrator intervention.

An early 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, could be added to the network by simply plugging them in; all further configuration was automated. Network addresses were automatically selected by each device using a protocol known as AppleTalk Address Resolution Protocol (AARP), while each machine built its own local directory service using a protocol known as Name Binding Protocol (NBP). NBP included not only a name, but the type of device and any additional user-provided information such as its physical ___location or availability. Users could look up any device on the network with the application [[Chooser (Mac OS)|Chooser]], which filtered names based on the device type.

On [[Internet Protocol]] (IP) networks, the [[Domain Name System]] database for a network was initially maintained manually by a network administrator. Efforts to automate maintenance of this database, led to the introduction of a number of new protocols providing automated services, such as the [[Dynamic Host Configuration Protocol]] (DHCP).

==Address selection==

Hosts on a network must be assigned [[IP address]]es that uniquely identify them to other devices on the same network. On some networks, there is a central authority that assigns these addresses as new devices are added. Mechanisms were introduced to handle this task automatically, 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 address]]ing, IPv4 uses the special block {{IPaddr|169.254.0.0|16}},{{Ref RFC|3927}} while IPv6 hosts use the prefix {{IPaddr|fe80::|10}}. More commonly addresses are assigned by a [[DHCP server]], often built into common networking hardware like computer hosts or routers.

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. Discovering the DHCP-assigned address of another host requires either distributed name resolution or a unicast DNS server with this information; Some networks feature DNS servers that are automatically updated with DHCP-assigned host and address information.

Line 30:

Internet protocols use IP addresses for communications, but these are not easy for humans to use; IPv6 in particular uses very long strings of digits that are not easily entered manually. To address this issue, the internet has long used DNS, which allows human-readable names to be associated with IP addresses, and includes code for looking up these names from a hierarchical database system. Users type in ___domain names, such as ''example.org'', which the computer's DNS software looks up in the DNS databases to retrieve an IP address, and then hands off that address to the [[protocol stack]] for further communications.<ref name="DNS">Marshall Brain and Stephanie Crawford, [http://computer.howstuffworks.com/dns.htm "How Domain Name Servers Work"], howstuffworks</ref>

Looking up an address using DNS 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 [[broadband]] devices like [[cable modem]]s that receive this information from their [[internet service provider]]. This has reduced the user-side administration requirements and provides a key element of zero-configuration access.<ref name=DNS/>

DNS was intended to provide uniform names to groups of devices within the same administration realm, such as ''example.org'', provided by a name service. Assigning an address to a local device, e.g., ''thirdfloorprinter.example.org'', normally requires administrator access to the DNS server and is often 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.<ref name=DNS/>

Line 38:

In 2000, Bill Manning and [[Bill Woodcock]] described the ''Multicast Domain Name Service''<ref>{{Citation | url = https://datatracker.ietf.org/doc/html/draft-manning-dnsext-mdns-00.txt | title = Multicast Domain Name Service |last1 = Manning |first1=Bill |last2= Woodcock |first2= Bill |publisher = [[IETF]] |date= August 2000}}</ref> which spawned the implementations by Apple and Microsoft. Both implementations are very similar. Apple's [[Multicast DNS]] (mDNS) is published as a standards track proposal {{IETF RFC|6762}}, while Microsoft's [[Link-local Multicast Name Resolution]] (LLMNR) is published as informational {{IETF RFC|4795}}. LLMNR is included in every Windows version from Windows Vista onwards<ref>{{Citation | publisher = Microsoft | type = webpage | url = https://technet.microsoft.com/library/bb878128 | title = Microsoft TechNet Library Link-Local Multicast Name Resolution }}</ref> and acts as a side-by-side alternative for Microsoft's NetBIOS Name Service over IPv4 and as a replacement over IPv6, since NetBIOS is not available over IPv6. Apple's implementation is available as the [[Bonjour (software)|Bonjour service]] since 2002 in Mac OS X v10.2. The Bonjour implementation (mDNSResponder) is available under the [[Apache License|Apache 2 Open Source License]]<ref>{{Citation | publisher = Apple | type = webpage | url = https://developer.apple.com/softwarelicensing/agreements/bonjour.php | title = Bonjour Licensing and Trademarks }}</ref> and is included in [[Android Jelly Bean]] and later<ref>{{Citation | type = webpage | url = http://developer.android.com/about/versions/android-4.1.html | title = Android 4.1 APIs }}</ref> under the same license.

Use of either NetBIOS or LLMNR services on Windows is essentially automatic, since using standard DNS client API'sAPIs will result in the use of either NetBIOS or LLMNR depending on what name is being resolved (whether the name is a local name or not), the network configuration in effect (e.g. DNS suffixes in effect) and (in corporate networks) the policies in effect (whether LLMNR or NetBIOS are disabled), although developers may opt into bypassing these services for individual address lookups.

The mDNS and LLMNR protocols have minor differences in their approach to name resolution. mDNS allows a network device to choose a ___domain name in the [[.local|local]] DNS [[namespace]] and announce it using a special multicast IP address. This introduces special semantics for the ___domain ''local'',<ref>{{Citation | publisher = IETF | type = electronic mail message | url = http://www1.ietf.org/mail-archive/web/ietf/current/msg37126.html | title = Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard | access-date = 2006-02-10 | archive-url = https://web.archive.org/web/20081207202354/http://www.ietf.org/mail-archive/web/ietf/current/msg37126.html | archive-date = 2008-12-07 | url-status = dead }}</ref> which is considered a problem by some members of the IETF.<ref>{{Citation | publisher = IETF | type = electronic mail message | url = http://www1.ietf.org/mail-archive/web/ietf/current/msg37773.html | title = Re: Summary of the LLMNR Last Call | access-date = 2006-02-10 | archive-url = https://web.archive.org/web/20081207202402/http://www.ietf.org/mail-archive/web/ietf/current/msg37773.html | archive-date = 2008-12-07 | url-status = dead }}</ref> 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.<ref>{{Citation | publisher = IETF | type = electronic mail message | url = http://www1.ietf.org/mail-archive/web/ietf/current/msg37740.html | title = Summary of the LLMNR Last Call | access-date = 2005-11-11 | archive-url = https://web.archive.org/web/20081207202357/http://www.ietf.org/mail-archive/web/ietf/current/msg37740.html | archive-date = 2008-12-07 | url-status = dead }}</ref> mDNS is compatible with DNS-SD as described in the next section, while LLMNR is not.<ref>{{Citation | publisher = IETF | type = electronic mail message | url = http://www.mhonarc.org/archive/html/ietf/2005-08/msg00494.html | title = More details on the differences}}</ref>

Line 87:

{{IETF RFC|3927}}, a standard for choosing addresses for networked items, was published in March 2005 by the IETF Zeroconf working group. The group included individuals from Apple, Sun, and Microsoft.<ref>{{Citation | publisher = IETF | url = http://www.ietf.org/html.charters/OLD/zeroconf-charter.html | title = Zero Configuration Networking (zeroconf) Charter | access-date = 2004-10-28 | archive-url = https://web.archive.org/web/20041101173627/http://www.ietf.org/html.charters/OLD/zeroconf-charter.html | archive-date = 2004-11-01 | url-status = dead }}</ref>

LLMNR was submitted for official adoption in the IETF DNSEXT working group, however, failed to gain consensus and thus was published as informational {{IETF RFC|4795}} in January 2007.<ref>{{Citation | url = http://www.ietf.org/html.charters/dnsext-charter.html | title = DNS Extensions (dnsext) Charter | publisher = IETF | access-date = 2005-03-02 | archive-url = https://web.archive.org/web/20050307044356/http://www.ietf.org/html.charters/dnsext-charter.html | archive-date = 2005-03-07 | url-status = dead }}</ref>

Following the failure of LLMNR to become an Internet standard and given that mDNS/DNS-SD is used much more widely than LLMNR, Apple was asked by the IETF to submit the mDNS/DNS-SD specs for publication as Informational RFC as well.{{citation needed|date=February 2016}}