Zero-configuration networking: Difference between revisions

Revision as of 04:34, 21 September 2021

Latest revision as of 04:31, 11 August 2025

(48 intermediate revisions by 32 users not shown)

Line 1:

{{short description|Technologies for automatic network connection configuration}}

{{cleanup|date=January 2021|reason=The Story Gets Lost Midway. Great tech story up to para 16 "In 2000,". I followed it as history and development of ZCN, but after para 16 the author changed and it turned into a feast of abbreviations, but never mentioned how they achieved the zero config solutions sch as Bonjoir etc.|nocat=true}}

'''Zero-configuration networking''' ('''zeroconf''') is a set of 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. Without zeroconf, a network administrator must set up [[network service]]s, such as [[Dynamic Host Configuration Protocol]] (DHCP) and [[Domain Name System]] (DNS), or configure each computer's network settings manually.

Line 13 ⟶ 12:

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 computer]] computerss 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}} as described in ,{{IETFRef 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.

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 additional addresses on receipt of router advertisement messages, thus eliminating the need for a DHCP server.<ref>{{Cite IETFRef RFC| publisher = IETF | rfc = 4862}}</ref>

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 basic property of the EUI-64. The IPv6 protocol stack also includes duplicate address detection to avoid conflicts with other hosts. In IPv4, the method is called ''link-local address autoconfiguration''.<ref>{{Cite IETF | publisher name="rfc3927" IETF | rfc = 3927}}</ref> However, [[Microsoft]] refers to this as ''[[Automatic Private IP Addressing]]'' ([[APIPA]])<ref>{{Citation | url = http://msdn.microsoft.com/en-us/library/aa505918.aspx | publisher = Microsoft | title = MS Developer Network | contribution = Apipa | access-date = 2008-07-05 | archive-url = https://web.archive.org/web/20170318001826/https://msdn.microsoft.com/en-us/library/aa505918.aspx | archive-date = 2017-03-18 | url-status = dead }}</ref> or '''''Internet Protocol Automatic Configuration''''' ('''IPAC'''). The feature is supported in Windows since at least [[Windows 98]].<ref>{{Citation | url = http://support.microsoft.com/kb/220874 | title = Knowledge base | date = 6 January 2021 | contribution = How to use automatic TCP/IP addressing without a DHCP server | publisher = Microsoft}}</ref>

==Name service discovery==

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 37 ⟶ 36:

To address the need for automatic configuration, Microsoft implemented [[NetBIOS Name Service]], part of which is the [[Computer Browser Service]] already in Microsoft Windows for Workgroups 3.11<ref name="ComputerBrowserService">{{cite web|title=Description of the Microsoft Computer Browser Service|url=https://support.microsoft.com/en-us/kb/188001|website=Microsoft Knowledge Base|publisher=Microsoft|access-date=1 November 2015}}</ref> as early as 1992. NetBIOS Name Service is zero-configuration on networks with a single subnet and may be used in conjunction with a [[Windows Internet Name Service|WINS]] server or a Microsoft DNS server that supports secure automatic registration of addresses. This system has small, but not zero, management overhead even on very large enterprise networks. The protocols NetBIOS can use are part of the [[Server Message Block]] (SMB) suite of open protocols<ref name=ComputerBrowserService /> which are also available on Linux and iOS, although Windows typically supports a wider range of so-called dialects which can be negotiated between Windows clients that support it. For example, Computer Browser Services running on server operating systems or later versions of Windows are elected as so-called ''master browser'' over those that are not running a server operating system or running older versions of Windows.<ref name=ComputerBrowserService />

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 | newspaper = Ietf Datatracker |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 | date = 5 May 2010 }}</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 [[top-level ___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>

==Service discovery==

Line 53 ⟶ 52:

===DNS-based service discovery===

'''{{vanchor|DNS-SD}}''' (DNS Service Discovery<ref name="dotorg">{{Citation | url = http://www.dns-sd.org/ | title = DNS-SD}}</ref>) allows clients to discover a named list of service instances and to resolve those services to hostnames using standard DNS queries. The specification is compatible with existing unicast DNS server and client software, but works equally well with mDNS in a zero-configuration environment. Each service instance is described using a DNS SRV<ref>{{IETF RFC|2782}}</ref> and DNS TXT<ref name="IETF RFC|1035">{{IETF RFC|1035}}</ref> record. A client discovers the list of available instances for a given service type by querying the DNS PTR<ref>{{ name="IETF RFC|1035}}<"/ref> record of that service type's name; the server returns zero or more names of the form &lt;Service&gt;.&lt;Domain&gt;, each corresponding to a SRV/TXT record pair. The [[SRV record]] resolves to the ___domain name providing the instance, while the TXT can contain service-specific configuration parameters. A client can then resolve the A/AAAA record for the ___domain name and connect to the service.

Service types are given on a first-come-first-serve basis. A service type registry was originally maintained by DNS-SD.org,<ref>{{Citation | url = http://www.dns-sd.org/ | title name="dotorg" DNS-SD}}</ref> but has since been merged into IANA's registry for DNS SRV records.<ref>{{Citation | url = http://www.dns-sd.org/ServiceTypes.html | publisher = DNS-SD | title = Service types}}</ref>

====History====

Line 61 ⟶ 60:

====DNS-SD with multicast====

mDNS uses packets similar to [[Domain Name System#DNS message format|unicast DNS]] to resolve hostnames except they are sent over a multicast link. Each host listens on the mDNS port, 5353, transmitted to a well-known multicast address and resolves requests for the [[resource record|DNS record]] of its ''.local'' hostname (e.g. the [[List of DNS record types#A|A]], [[List of DNS record types#AAAA|AAAA]], [[CNAME record|CNAME]]) to its IP address. When an mDNS client needs to resolve a local hostname to an IP address, it sends a DNS request for that name to the well-known multicast address; the computer with the corresponding A/AAAA record replies with its IP address. The mDNS multicast address is <tt>{{IPaddr|224.0.0.251</tt>}} for IPv4 and <tt>{{IPaddr|ff02::fb</tt>}} for IPv6 link-local addressing.

DNS Service Discovery (aka [[DNS-SD)]] requests can also be sent using mDNS to yield zero-configuration DNS-SD.<ref>{{Cite IETFRef RFC| publisher = IETF | rfc = 6763 |title=DNS-Based Service Discovery}}</ref> This uses DNS [[PTR record|PTR]], SRV, [[TXT record|TXT]] records to advertise instances of service types, ___domain names for those instances, and optional configuration parameters for connecting to those instances. But SRV records can now resolve to ''.local'' ___domain names, which mDNS can resolve to local IP addresses.

====Support====

DNS-SD is used by Apple products, most network printers, many Linux distributions including [[Debian]] and [[Ubuntu (operating system)|Ubuntu]],<ref>{{cite web|title=Ubuntu 15.10 desktop manifest|url=http://releases.ubuntu.com/wily/ubuntu-15.10-desktop-amd64.manifest|publisher=Ubuntu|access-date=23 October 2015}}</ref> and a number of third-party products for various operating systems. For example, many [[OS X]] network applications written by Apple, including [[Safari (web browser)|Safari]], [[iChat]], and [[Messages (Apple)|Messages]], can use DNS-SD to locate nearby servers and peer-to-peer clients. Windows 10 includes support for DNS-SD for applications written using JavaScript.<ref name="WindowsDnssdNamespace">{{cite web|title=Windows.Networking.ServiceDiscovery.Dnssd namespace|url=https://msdn.microsoft.com/en-us/library/windows/desktop/bb870632(v=vs.85).aspx|website=Windows Dev Center|publisher=Microsoft|access-date=1 November 2015}}</ref> Individual applications may include their own support in older versions of the operating system, such that most instant messaging and [[VoIP]] clients on Windows support DNS-SD. Some [[Unix]], [[BSD]], and Linux distributions also include DNS-SD. For example, Ubuntu ships [[Avahi (software)|Avahi]], an mDNS/DNS-SD implementation, in its base distribution.

===UPnP===

Line 72 ⟶ 71:

====SSDP====

[[Simple Service Discovery Protocol]] (SSDP) is a UPnP protocol, used in [[Windows XP]] and later. SSDP uses HTTP notification announcements that give a service-type [[Uniform Resource Identifier|URI]] and a Unique Service Name (USN). Service types are regulated by the Universal Plug and Play Steering Committee. SSDP is supported by many printer, NAS and appliance manufacturers such as Brother. It is supported by certain brands of network equipment, and in many [[SOHO network|SOHO]] firewall appliances, where host computers behind it may pierce holes for applications. It is also used in [[home theater PC]] systems to facilitate media exchange between host computers and the media center.

====DLNA====

Line 81 ⟶ 80:

===AllJoyn===

[[AllJoyn]] is an open-source software stack for a myriad of devices, ranging from IoT devices to full-size computers, for discovery and control of devices on networks (Wifi, Ethernet) and other links (Bluetooth, ZigBee, etc.). It uses mDNS and [[HTTP]] over UDP and other protocols. The project has however not been active since 2016, and is not recommended to use for new projects.<ref>{{ Citation | title = Error compiling with modern gcc | url = https://github.com/alljoyn/core-alljoyn/issues/1 | access-date = 2025-01-31 }}</ref>

==Standardization==

Line 88 ⟶ 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}}

Line 95 ⟶ 94:

==Security issues==

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 attack]]s by any system within the same [[broadcast ___domain]]. Like [[Simple Network Management Protocol|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.<ref>{{Citation | url = http://www.gnucitizen.org/blog/name-mdns-poisoning-attacks-inside-the-lan/ | title = Name (MDNS) Poisoning Attacks Inside the LAN | publisher = GNU citizen | type = World Wide Web log | date = 23 January 2008}}</ref> Because of this, applications should still authenticate and encrypt traffic to remote hosts (e.g. via [[RSA (cryptosystem)|RSA]], [[Secure Shell|SSH]], etc.) after discovering and resolving them through DNS-SD/mDNS. LLMNR suffers from similar vulnerabilities.<ref>{{cite web |url=https://www.pentestpartners.com/security-blog/how-to-get-windows-to-give-you-credentials-through-llmnr/ |title=How to get Windows to give you credentials through LLMNR |first=David |last=Lodge |date=22 September 2015 |website=Pen Test Partners}}</ref>

==Major implementations==

Line 102 ⟶ 101:

[[Bonjour (software)|Bonjour]] from Apple, uses mDNS and DNS Service Discovery. Apple changed its preferred zeroconf technology from SLP to mDNS and DNS-SD between [[Mac OS X 10.1]] and [[Mac OS X 10.2|10.2]], though SLP continues to be supported by Mac OS X.

Apple's mDNSResponder has interfaces for [[C (programming language)|C]] and [[Java (programming language)|Java]]<ref>{{Citation | url = http://www.macdevcenter.com/pub/a/mac/2004/08/31/osx_java.html | publisher = Mac Dev Center | title = A Rendezvous with Java | date = 2004-08-31}}</ref> 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.<ref>{{Citation | url = https://support.apple.com/downloads/bonjour_for_windows | publisher = Apple | title = Support | contribution = Bonjour for MS Windows 1.0.4}}</ref><!--[[User:Kvng/RTH]]-->

===Avahi===

[[Avahi (software)|Avahi]] is a Zeroconf implementation for [[Linux]] and [[Berkeley Software Distribution|BSD]]s. 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.<ref>{{Citation | url = http://0pointer.de/lennart/projects/nss-mdns | title = nss-mdns 0.10 | last = Lennart | publisher = 0 pointer | place = [[Germany|DE]]}}</ref>

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===

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

===Systemd===

[[Systemd]] implements both mDNS and LLMNR in <code>systemd-resolved</code>.

===Link-local IPv4 addresses===

Where no DHCP server is available to assign a host an IP address, the host can select its own [[link-local address]]. ThusUsing a link-local address, hosts can communicate over this link but only locally; Access to other networks and the Internet is not possible. There are some [[Link-local address|link-local IPv4 address]] implementations available:

* Apple Mac OS and MS Windows have supported link-local addresses since [[Windows 98]] and [[Mac OS 8.5]] (both released in 1998).{{citation<ref needed|datename=May"rfc3927" 2015}}/> Apple released its open-source implementation in the [[Darwin (operating system)|Darwin]] bootp package.

* [[Avahi (software)|Avahi]] contains an implementation of [[IPv4LL]] in the avahi-autoipd tool.

* Zero-Conf IP (zcip).<ref>{{Citation | url = httphttps://zeroconf.sourceforge.net/ | title = zcip | publisher = Source forge}}</ref>

* [[BusyBox]] can embed a simple IPv4LL implementation.

* Stablebox,<ref>{{Citation | url = http://code.google.com/p/stablebox/ | title = Code | contribution = Stable box}}</ref> a fork from Busybox, offers a slightly modified IPv4LL implementation named llad.

* Zeroconf,<ref>{{Citation | url = http://www.progsoc.uts.edu.au/~wildfire/zeroconf/ | title = Zeroconf | publisher = UTS | place = [[Australia|AU]] | access-date = 2005-05-04 | archive-url = https://web.archive.org/web/20050509093846/http://www.progsoc.uts.edu.au/~wildfire/zeroconf/ | archive-date = 2005-05-09 | url-status = dead }}</ref> is a package based on Simple IPv4LL, a shorter implementation by [[Arthur van Hoff]].<ref>{{Citation | url = http://www.zeroconf.org/AVH-IPv4LL.c | publisher = Zero conf | title = AVH IPv4LL | type = C source code}}</ref>

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.<ref>{{Citation | url = http://udhcp.busybox.net/lists/udhcp/2005-May/000124.html | publisher = Busy box | title = udhcpc | contribution = Zeroconf in udhcpc | type = electronic mail message | date = May 2005 | access-date = 2006-03-15 | archive-url = https://web.archive.org/web/20060206072249/http://udhcp.busybox.net/lists/udhcp/2005-May/000124.html | archive-date = 2006-02-06 | url-status = dead }}</ref>

* dhcpcd<ref>{{Citation | url = http://roy.marples.name/projects/dhcpcd/wiki | title = dhcpcd | first = Roy | last = Marples | type = project | format = wiki | access-date = 2011-01-07 | archive-url = https://web.archive.org/web/20100712131058/http://roy.marples.name/projects/dhcpcd/wiki | archive-date = 2010-07-12 | url-status = dead }}</ref> is an [[opensourceOpen-source software|open source]] [[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 [[Address Resolution Protocol|ARP]] replies<ref>{{Citation | url = http://www.science.uva.nl/research/air/wiki/LinkLocalARPMeasurements | title = AIR | type = wiki | contribution = Link-Local ARP Measurements | publisher = UVA | place = [[Netherlands|NE]]}}</ref> or closing existing network connections.

Line 137 ⟶ 136:

==References==

'''Notes'''

{{reflist | 33em}}

'''Sources'''

{{refbegin}}

Line 144 ⟶ 143:

==External links==

* {{Citation | url = httphttps://jmdns.sourceforge.net/ | publisher = Source forge | title = JmDNS}}, a pure Java implementation of mDNS/DNS-SD.

* {{Citation | url = httphttps://sourceforge.net/projects/pyzeroconf/ | publisher = Source forge | title = pyZeroConf| date = 11 July 2015 }}, a pure [[Python (programming language)|Python]] implementation of mDNS/DNS-SD.

* {{Citation | url = http://mono-project.com/Mono.Zeroconf | title = Mono.Zeroconf | publisher = Mono project}}, a cross platform (Linux, MS Windows, Apple Mac), unified Mono/.NET library for Zeroconf, supporting both Bonjour and Avahi.

* {{Citation | url = httphttps://sourceforge.net/projects/wxservdisc/ | publisher = Source forge | title = WxServDisc| date = 13 June 2013 }}, a cross-platform wxWidgets-based service discovery module without external dependencies.

* {{Citation | url = http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt | publishertitle = Multicast DNS | title = Specification | last = Cheshire | first = Stuart | type = draft}}.

* {{Citation | url = http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt | publisher = DNS‐SDDNS-SD | title = DNS-Based Service Discovery Specification | last = Cheshire | first = Stuart | author-mask = 3 | type = draft}}.

* {{Citation | url = http://video.google.com/videoplay?docid=-7398680103951126462&q=Google+techtalks | title = Zeroconf | type = tech talk | first = Stuart | last = Cheshire | author-mask = 3 | format = video | access-date = 2006-03-08 | archive-url = https://web.archive.org/web/20080302221751/http://video.google.com/videoplay?docid=-7398680103951126462&q=Google+techtalks | archive-date = 2008-03-02 | url-status = dead }}.

* {{Citation | url = http://www.zeroconf.org/ | title = Zeroconf | first = Stuart | last = Cheshire | author-mask = 3}}, including Internet drafts.

* {{Citation | url = http://dns-sd.org/ | title = DNS-SD}}, DNS based Service Discovery

* {{CitationCite web | url = http://multicastdns.org/ | title = Multicast DNS}}.

* {{Citation | url = http://www.oreillynet.com/pub/a/wireless/2002/12/20/zeroconf.html | title = Understanding Zeroconf and Multicast DNS | first = Heath | last = Johns |date=December 2002 | type = article | publisher = O'Reilly}}, slightly outdated.

* {{Citation | url = http://www.science.uva.nl/research/air/wiki/ZeroconfTechnologies | title = AIR | type = wiki | contribution = Zeroconf Technologies | publisher = UVA | place = NL}}.

* {{Citation | url = http://ietf.org/html.charters/dnsext-charter.html | type = charter | title = DNSEXT working group | publisher = [[Internet Engineering Task Force|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 }}, which coordinates LLMNR standardization.

* {{Cite IETF |rfc= 2608 |title=Service Location Protocol, version 2}}

* {{Citation | url = http://www.oreilly.com/catalog/bonjour/ | title = Zero Configuration Networking: The Definitive Guide | first1 = Daniel | last1 = Steinberg | first2 = Stuart | last2 = Cheshire | publisher = O'Reilly}}.

Line 164 ⟶ 160:

[[Category:Computer configuration]]

[[Category:Domain Name System]]

[[Category:Network protocols]]

[[Category:Windows communication and services]]

[[Category:NetworkDiscovery protocols]]