Zero-configuration networking
Zero-configuration networking (zeroconf) is a set of technologies that automatically creates a usable
Zeroconf is built on three core technologies: automatic 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.
Internet protocol suite |
---|
Application layer |
Transport layer |
Internet layer |
Link layer |
Background
Computer networks use numeric
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
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
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.[2]
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
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.[5]
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 modems 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.[5]
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.[5]
To address the need for automatic configuration, Microsoft implemented
In 2000, Bill Manning and
Use of either NetBIOS or LLMNR services on Windows is essentially automatic, since using standard DNS client APIs 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
Service discovery
Name services such as mDNS, LLMNR and others do not provide information about the type of device or its status. A user looking for a nearby printer, for instance, might be hindered if the printer was given the name "Bob".
NetBIOS Service Discovery
NetBIOS on Windows supports individual hosts on the network to advertise services, such as file shares and printers. It also supports, for example, a network printer to advertise itself as a host sharing a printer device and any related services it supports. Depending on how a device is attached (to the network directly, or to the host which shares it) and which protocols are supported. However, Windows clients connecting to it may prefer to use SSDP or WSD using NetBIOS. NetBIOS is one of the providers on Windows implementing the more general discovery process dubbed function discovery which includes built-in providers for PnP, Registry, NetBIOS, SSDP and WSD[15] of which the former two are local-only and the latter three support discovery of networked devices. None of these need any configuration for use on the local subnet. NetBIOS has traditionally been supported only in expensive printers for corporate use though some entry-level printers with Wi-Fi or Ethernet support it natively, allowing the printer to be used without configuration even on very old operating systems.
WS-Discovery
Web Services Dynamic Discovery (WS-Discovery) is a technical specification that defines a multicast discovery protocol to locate services on a local network. It operates over TCP and UDP port 3702 and uses IP multicast address 239.255.255.250. As the name suggests, the actual communication between nodes is done using web services standards, notably SOAP-over-UDP. Windows supports it in the form of Web Services for Devices and Devices Profile for Web Services. Many devices, such as HP and Brother printers, support it.
DNS-based service discovery
DNS-SD (DNS Service Discovery[16]) 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[17] and DNS TXT[18] record. A client discovers the list of available instances for a given service type by querying the DNS PTR[18] record of that service type's name; the server returns zero or more names of the form <Service>.<Domain>, 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,[16] but has since been merged into IANA's registry for DNS SRV records.[19]
History
In 1997
DNS-SD with multicast
mDNS uses packets similar to
) 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 224.0.0.251 for IPv4 and ff02::fb for IPv6 link-local addressing.DNS Service Discovery aka
Support
DNS-SD is used by Apple products, most network printers, many Linux distributions including
UPnP
SSDP
DLNA
Efforts toward an IETF standard protocol
SLP is supported by
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.
Standardization
LLMNR was submitted for official adoption in the IETF DNSEXT working group, however, failed to gain consensus and thus was published as informational
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]
In February 2013 mDNS and DNS-SD were published as Standards Track Proposals
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 attacks by any system within the same broadcast domain. 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.[30] Because of this, applications should still authenticate and encrypt traffic to remote hosts (e.g. via RSA, SSH, etc.) after discovering and resolving them through DNS-SD/mDNS. LLMNR suffers from similar vulnerabilities.[31]
Major implementations
Apple Bonjour
Apple's mDNSResponder has interfaces for C and Java[32] 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.[33]
Avahi
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
Systemd
Systemd implements both mDNS and LLMNR in systemd-resolved
.
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. Using 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 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).[1] 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)[35]
- BusyBox can embed a simple IPv4LL implementation.
- Stablebox,[36] a fork from Busybox, offers a slightly modified IPv4LL implementation named llad.
- Zeroconf[37] is a package based on Simple IPv4LL, a shorter implementation by Arthur van Hoff.[38]
The above implementations are all stand-alone daemons or plugins for
- Elvis Pfützenreuter has written a patch for the uDHCP client/server.[39]
- dhcpcdBSD that includes IPv4LL support. It is included as standard in NetBSD.
Neither of these implementations addresses kernel issues like broadcasting ARP replies[41] or closing existing network connections.
See also
References
Notes
- ^ . Proposed Standard.
- .
- ^ "Apipa", MS Developer Network, Microsoft, archived from the original on 2017-03-18, retrieved 2008-07-05
- ^ "How to use automatic TCP/IP addressing without a DHCP server", Knowledge base, Microsoft, 6 January 2021
- ^ a b c Marshall Brain and Stephanie Crawford, "How Domain Name Servers Work", howstuffworks
- ^ a b c "Description of the Microsoft Computer Browser Service". Microsoft Knowledge Base. Microsoft. Retrieved 1 November 2015.
- IETF
- ^ Microsoft TechNet Library Link-Local Multicast Name Resolution (webpage), Microsoft, 5 May 2010
- ^ Bonjour Licensing and Trademarks (webpage), Apple
- ^ Android 4.1 APIs (webpage)
- ^ Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard (electronic mail message), IETF, archived from the original on 2008-12-07, retrieved 2006-02-10
- ^ Re: Summary of the LLMNR Last Call (electronic mail message), IETF, archived from the original on 2008-12-07, retrieved 2006-02-10
- ^ Summary of the LLMNR Last Call (electronic mail message), IETF, archived from the original on 2008-12-07, retrieved 2005-11-11
- ^ More details on the differences (electronic mail message), IETF
- ^ "About Function Discovery". Windows Dev Center. Microsoft. Retrieved 1 November 2015.
- ^ a b DNS-SD
- RFC 2782
- ^ RFC 1035
- ^ Service types, DNS-SD
- ^ Cheshire, Stuart, Name Binding Protocol over IP (rant)[self-published source?]
- ^ Zero conf[self-published source?]
- .
- .
- .
- ^ "Ubuntu 15.10 desktop manifest". Ubuntu. Retrieved 23 October 2015.
- ^ "Windows.Networking.ServiceDiscovery.Dnssd namespace". Windows Dev Center. Microsoft. Retrieved 1 November 2015.
- ^ Service Location Protocol (svrloc) Charter, IETF
- ^ Zero Configuration Networking (zeroconf) Charter, IETF, archived from the original on 2004-11-01, retrieved 2004-10-28
- ^ DNS Extensions (dnsext) Charter, IETF, archived from the original on 2005-03-07, retrieved 2005-03-02
- ^ Name (MDNS) Poisoning Attacks Inside the LAN (World Wide Web log), GNU citizen, 23 January 2008
- ^ Lodge, David (22 September 2015). "How to get Windows to give you credentials through LLMNR". Pen Test Partners.
- ^ A Rendezvous with Java, Mac Dev Center, 2004-08-31
- ^ "Bonjour for MS Windows 1.0.4", Support, Apple
- ^ Lennart, nss-mdns 0.10, DE: 0 pointer
- ^ zcip, Source forge
- ^ "Stable box", Code
- ^ Zeroconf, AU: UTS, archived from the original on 2005-05-09, retrieved 2005-05-04
- ^ AVH IPv4LL (C source code), Zero conf
- ^ "Zeroconf in udhcpc", udhcpc (electronic mail message), Busy box, May 2005, archived from the original on 2006-02-06, retrieved 2006-03-15
- ^ Marples, Roy, dhcpcd (project), archived from the original (wiki) on 2010-07-12, retrieved 2011-01-07
- ^ "Link-Local ARP Measurements", AIR (wiki), NE: UVA
Sources
- Guttman, Erik (2001), "Autoconfiguration for IP Networking: Enabling Local Communication", IEEE Internet Computing, 5 (3): 81–86,
External links
- JmDNS, Source forge, a pure Java implementation of mDNS/DNS-SD.
- pyZeroConf, Source forge, 11 July 2015, a pure Python implementation of mDNS/DNS-SD.
- Mono.Zeroconf, Mono project, a cross platform (Linux, MS Windows, Apple Mac), unified Mono/.NET library for Zeroconf, supporting both Bonjour and Avahi.
- WxServDisc, Source forge, 13 June 2013, a cross-platform wxWidgets-based service discovery module without external dependencies.
- Cheshire, Stuart, Multicast DNS (draft).
- Cheshire, Stuart, DNS-Based Service Discovery Specification (draft), DNS-SD.
- Cheshire, Stuart, Zeroconf (tech talk), archived from the original (video) on 2008-03-02, retrieved 2006-03-08.
- Cheshire, Stuart, Zeroconf, including Internet drafts.
- DNS-SD, DNS based Service Discovery
- "Multicast DNS".
- Service Location Protocol, version 2. .
- Steinberg, Daniel; Cheshire, Stuart, Zero Configuration Networking: The Definitive Guide, O'Reilly.