Zero configure network ( zeroconf ) is a set of technologies that automatically create computer networks that can be used based on Internet Protocol Suite (TCP/IP) when the computer or network peripherals are interconnected. This does not require manual operator intervention or a dedicated configuration server. Without zeroconf, network administrators need to set up network services, such as Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS), or configure network settings for each computer manually.
Zeroconf is built on three core technologies: automatic assignment of numerical network addresses for networked devices, automatic distribution and host name resolution of computers, and automatic location of network services, such as printing devices.
Video Zero-configuration networking
​​â € <â €
Computer networks use a numerical network address to identify the communication endpoints within the participating network of devices. This is similar to a telephone network that provides a series of numbers to identify each phone. In modern network protocols, the information to be transmitted is divided into a series of network packets. Each packet contains the source and destination address for the transmission. The network router checks this address to determine the best network path in forwarding packets of data at every step toward its destination.
Similarly for phones that are labeled with their phone numbers, it is a common practice on the initial network to attach an address label to a network device. The dynamic nature of modern networks, especially residential networks where devices are raised only when needed, want a dynamic address assignment mechanism that does not require user engagement for initialization and management. The system automatically assigns common names chosen by either the equipment manufacturer, such as brand and model number, or selected by the user to identify their equipment. The name and address are then automatically entered into the directory service.
Early computer networks were built on telecommunication network technology and thus the protocol tended to fall into two groups: those meant to connect local devices into local area networks (LANs), and those aimed primarily for remote communications. The wide area network (WAN) system tends to have centralized settings, where the network administrator manually assigns addresses and names. LAN systems tend to provide more automation of these tasks, so new equipment can be added to the LAN with minimal operator and administrator intervention.
An early example of an unconfigured LAN system is AppleTalk, a protocol introduced by Apple Inc. for early Macintosh computers in the 1980s. Mac, as well as other devices that support the protocol, can be added to the network by simply plugging it in; all further configuration is automatic. The network address is automatically selected by each device using a protocol known as AppleTalk Address Resolution Protocol (AARP), while each machine builds its own local directory service using a protocol known as Name Binding Protocol (NBP). NBP not only names, but any type of device and any additional information that the user provides such as physical location or availability. Users can search any device on the network with the Chooser app, which filters the name by device type.
On the Internet Protocol network, the Domain Name System database for the network was initially managed manually by the network administrator. Attempts to automate the maintenance of this database, led to the introduction of a number of new protocols that provide automated services, such as Dynamic Host Configuration Protocol (DHCP).
Maps Zero-configuration networking
Address options
Hosts on the network must be assigned an IP address that uniquely identifies them to other devices on the same network. On some networks there is a central authority that sets this address as a new device is added. Mechanisms are introduced to handle this task automatically, and both IPv4 and IPv6 now include systems for automatic configuration of addresses, allowing devices to specify secure addresses for use via simple mechanisms. For local-link addressing, IPv4 uses special blocks 169.254.0.0 / 16 as described in RFC 3927 while the IPv6 host uses the fe80 :: span> 10 Most IPv4 hosts use link-local addresses only as a last resort when the DHCP server is unavailable. The IPv4 host instead uses its DHCP address set for all communications, global or local link. 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 (for example, multicast DNS), so finding an automatically-linked local linked address from another host on the network can be difficult. However, finding DHCP-host addresses from other hosts also requires distributed name resolution or unicast DNS servers with this information, and some DNS server feature networks are automatically updated with hosts and addresses DHCP-assigned information. An IPv6 host is required to support multiple addresses per interface; Additionally, each IPv6 host is required to configure a local link-address even when a global address is available. The IPv6 host can also configure their own additional address on the receipt of a router ad message, thus eliminating the need for a DHCP server. Both IPv4 and IPv6 hosts can randomly generate host-specific sections of automatically configured addresses. IPv6 hosts generally combine the prefix with up to 64 bits with 64-bit EUI-64 originating from factory-specified IEEE 48-bit MAC addresses. The MAC address has the advantage of being globally unique, a property inherited by the EUI-64. IPv6 protocol stack includes duplicate address detection to avoid conflict with other hosts. In IPv4, this method is called automatic configuration of local link-address . However, Microsoft refers to this as Automatic Private IP Address (APIPA) or Internet Protocol Automatic Configuration (IPAC) (supported at least since Windows 98).
Name service discovery
Internet protocols use IP addresses for communication, but these are not really human readable; IPv6 specifically uses very long digits of digits that are not easily entered manually. To solve this problem, the Internet has long used Domain Name System (DNS), which allows human readable names to be associated with IP addresses, and includes code to search for these names from hierarchical database systems. Users typed in a domain name, such as example.org , which the computer's DNS software looks up in the DNS database to retrieve the IP address, and then submits the address to the network software for further communication.
Finding the DNS address requires the IP address of the DNS server to be known. This is usually done by typing the address of a known server into a field on one of the devices on the network. In this initial system is usually required on each device, but this has pushed one layer in the hierarchy to a DHCP server or a wide network device such as cable modems that receive this information from their IP provider. This has reduced the user-side administration burden and provides a key element of the zero-configuration access.
DNS is intended to provide uniform names for groups of devices within the same administrative region, such as example.org , provided by name services. Assigning an address to a local device, e.g., thirdfloorprinter.example.org , usually requires administrator access to the DNS server and is often resolved manually. In addition, traditional DNS servers are not expected to automatically correct configuration changes. For example, if a printer is moved from one floor to another it may be assigned a new IP address by the local DHCP server.
To overcome the need for automatic configuration, Microsoft implemented the NetBIOS Name Services section which is an existing Computer Browser Service in Microsoft Windows for Workgroups 3.11 as early as 1992. NetBIOS Name Service is a zero-configuration on the network with one subnet and can be used in conjunction with the server WINS or DNS (Microsoft) servers that support (secure) automatic address registrations to have small but non-zero management overheads even on very large (enterprise) networks. The NetBIOS-enabling protocol is part of the open SMB protocol suite implemented on Linux and iOS, although Windows typically supports multiple negotiated dialects between (Windows) clients that support it. For example, a Computer Browser Service running on the server operating system or a newer version of Windows is selected as the so-called main browser above those not running the server operating system or running an older version of Windows.
In 2000, Bill Manning and Bill Woodcock described the Multicast Domain Name Service which gave birth to implementations by Apple and Microsoft. Both implementations are very similar. Apple's Multicast DNS (mDNS) is published as a standard track proposal (RFC 6762), while Microsoft Link-local Multicast Name Resolution (LLMNR) is published as RFC 4795 information. LLMNR is included in every Windows version of Windows Vista and beyond and acts as an alternate adjoining Microsoft's NetBIOS Name Service via IPv4 and in place of IPv6, since NetBIOS is not available through IPv6. The Apple implementation is available as a Bonjour Service, formerly Rendezvous, since 2002 on Mac OS X v10.2. The Bonjour Implementation (mDNSResponder) is available under the Open Source License Apache 2 and is included in Android 4.1 "Jelly Bean" and then under the same license.
The use of NetBIOS or LLMNR services on Windows is essentially automated, since using standard DNS client APIs will result in the use of NetBIOS or LLMNR depending on what name is being resolved (whether the name is localized or not), the network configuration is valid (eg DNS suffix is ​​applicable) and (within the corporate network) policies in force (whether LLMNR or NetBIOS is disabled), although developers may choose to skip this service for individual address searches.
The mDNS and LLMNR protocols have little difference in their approach to name resolution. mDNS allows network devices to select a domain name in the local DNS namespace and announce it using a special multicast IP address. This introduces a special semantic for the local domain , which is considered a problem by some IETF members. The current LLMNR design allows network devices to select any domain name, which is considered a security risk by some IETF members. mDNS is compatible with DNS-SD as described in the next section, while LLMNR does not.
Service discovery
Name services such as mDNS, LLMNR, and others do not provide information about the device type or its status. A user looking for the nearest printer, for example, may be blocked if the printer is named "Bob". Service discovery provides additional information about the device. Service discovery is sometimes combined with name services, such as in the Apple Binding Protocol Name and Microsoft NetBIOS (including SMB as supported on non-Microsoft operating systems).
NetBIOS Service Discovery
NetBIOS on Windows and siblings SMB on other operating systems, supporting individual hosts on the network to advertise services, such as file and printer sharing. It also supports for example a network printer to advertise itself as a host that shares printer devices and related services that it supports. Depending on how the device is attached (to the network directly, or to the host that shared it) and which protocols are supported however, the Windows clients that connect to it may prefer to use SSDP or WSD instead of using NetBIOS. NetBIOS is one of the providers in Windows that implements a more common discovery process dubbed the 'Discovery Function' which includes built-in providers for PnP, Registry, NetBIOS, SSDP and WSD which were the only two local and third-generation latest network support devices. None of this requires configuration to be used on a local subnet. NetBIOS has traditionally been supported only on expensive printers for use in companies and the cheapest devices of some brands currently still do not have support for it, but home users and SOHO will connect the printer to the above computer saying the parallel port or USB and sharing it from the computer. However, even beginner-level printers with Wi-Fi or Ethernet support from multiple brands support them by default, allowing the printer to be used without configuration even on very long operating systems (combined with generic PostScript drivers, for example).
WS-Discovery
The Dynamic Discovery (WS-Discovery) Web service is a technical specification that defines multicast discovery protocols for locating services on a local network. It operates via 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 service standards, especially SOAP over UDP. Windows supports it in the form of WSD and WPDS and many devices and tool manufacturers support it, such as HP and Brother printers.
DNS-based services search
DNS-SD allows clients to find a list of named service instances, given the type of service, and to complete the service to the hostname using standard DNS requests. This specification is compatible with existing DNS servers and client unicast software, but works well with Multicast DNS in an unconfigured environment. Each service instance is described using SRV DNS records (RFC 27 2782) and DNS TXT (RFC 10 1035). The client finds a list of examples available for a particular type of service by asking for DNS records of PTR (RFCÃ, 1035) of the service type's name; server returns zero or more form names "& lt; Service & gt ;. & lt; Domain & gt;" respectively according to the SRV/TXT recording partner. The SRV record changes to a domain name that provides instances, whereas TXT can contain service-specific configuration parameters. The client can then complete the A/AAAA record for the domain name and connect to the service.
History
In 1997 Stuart Cheshire proposed to adapt the mature Name Binding Protocol from Apple to the IP network to address the lack of service discovery capabilities. Cheshire then joined Apple and wrote an IETF draft proposal for DNS-based Multicast DNS and Service Discovery, supporting the transition from AppleTalk to the IP network. In 2002, Apple announced the adoption 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. In 2013, the proposal was ratified as RFC 6762 and RFC 6763.
DNS-SD with multicast
Multicast DNS (mDNS) is a protocol that uses packets similar to DNS unicast except to send over multicast links to resolve hostnames. Each host listens on the mDNS port, 5353, and completes the request for the DNS records from the .local hostname (eg A, AAAA, CNAME) to its IP address. When the mDNS client needs to resolve the local hostname to the IP address, the client sends a DNS request for that name to a famous multicast address; computer with A/AAAA related records replying with its IP address. The mDNS multicast address is 224.0.0.251 for IPv4 and ff02 :: fb for the IPv6 link-local addressing.
DNS service (DNS-SD) discovery requests can also be sent via multicast links, and it can be combined with mDNS to generate DNS-SD with zero configuration. It still uses DNS PTR, SRV, TXT records to advertise instance of service type, domain name for the instance, and optional configuration parameters to connect to the instance. But SRV records can now resolve to multicastable .local domain names, which mDNS can resolve to local IP addresses.
Support
DNS-SD is used by Apple products, mostly network printers, many Linux distributions including Debian and Ubuntu, and a number of third-party products for various operating systems. For example, many OS X network applications written by Apple, including Safari, iChat, and Messaging, can use DNS-SD to search for nearby servers and peer-to-peer clients. On Windows, the operating system includes support for DNS-SD at least in Windows 10 for applications written using JavaScript and other languages ​​may be supported immediately. Individual applications may include their own support in older operating system versions, as most instant messaging and VoIP clients in Windows support DNS-SD. Some distributions of Unix, BSD, and Linux also include DNS-SD. For example, Ubuntu sends Avahi, mDNS/DNS-SD implementation, in its basic distribution.
Type of service is provided on the basis of the first service. This type of registry service was originally managed by DNS-SD.org, but has since been merged into the IANA registry for DNS SRV records.
UPnP
UPnP has several variants of the protocol for the purpose of service discovery.
SSDP
The Simple Service Discovery Protocol (SSDP) is the UPnP protocol, used in Windows XP and later. SSDP uses HTTP notification notifications that provide service type URIs and Unique Service Names (USN). The service type is governed by the Universal Plug and Play Steering Committee. SSDP is supported by many printers, NAS manufacturers and tools such as Brother, certain network equipment brands, and many SOHO firewall tools, where the host computer behind it can pierce holes for applications. It is also used in PC home theater systems, where media exchange between host computers and media centers is facilitated using SSDP.
DLNA
DLNA is another standard set that uses UPnP for network device discovery, which has a long list of manufacturers that produce devices that support it, like TVs from most, if not all major brands, NAS devices, and so on. As such, it is also supported by all major operating systems.
Attempt to IETF standard protocol
Service Location Protocol (SLP) is supported by network printers, Novell, and Sun Microsystems Hewlett-Packard. The SLP is described in RFC 2608 and RFC 3224 and implementation is available for Solaris and Linux.
AllJoyn
AllJoyn is open source software for various devices, from the smallest IOT device to the largest computer, for discovery and control of devices on the network (Wifi, Ethernet) and other links (Bluetooth, ZigBee, etc.). It uses (among other things) mDNS and HTTP via UDP.
Standardization
RFC 3927, a standard for selecting addresses for network items, was published in March 2005 by the IETF Zeroconf working group, which included individuals from Apple, Sun, and Microsoft.
LLMNR submitted for official adoption in the IETF DNSEXT working group, but failed to reach consensus and therefore has been published only as RFC information: RFC 4795.
Following LLMNR's failure to become an Internet standard, Apple was asked by the IETF to submit the mDNS/DNS-SD specification for publication as RFC information as well, given that mDNS/DNS-SD is used much more broadly than LLMNR.. In February 2013, mDNS and DNS -SD is published as RFC 6762 Standard Path Proposal and RFC 6763.
RFCÃ, 2608, SLP standards to find out where to obtain services, published by the IETF SVRLOC working group.
Security issues
Since mDNS operates under a different trust model than DNS unicast - trusting the entire network rather than a designated DNS server, it is vulnerable to spoof 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 about the network and its machines. Therefore, the app must still authenticate and encrypt the traffic to the remote host (eg via RSA, SSH, etc.) After finding and resolving it through DNS-SD/mDNS.
Implementation of the main
Apple Bonjour
Bonjour (formerly known as Rendezvous) from Apple Inc., using mDNS and DNS Service Discovery. Apple changed the preferred zeroconf technology from SLP to mDNS and DNS-SD between Mac OS X 10.1 and 10.2, although SLP continues to be supported by Mac OS X.
MDNSResponder Apple has an interface for C and Java and is available on BSD, Apple Mac OS X, Linux, other POSIX-based operating systems and MS Windows. Windows downloads are available from the Apple website.
Avahi
Avahi is a Zeroconf implementation for Linux and BSD. It implements IPv4LL, mDNS and DNS-SD. It is part of most Linux distributions, and is installed by default on some. If it is run in conjunction with nss-mdns, it also offers host name resolution.
Avahi also implements binary compatibility libraries that mimic Bonjour and historical implementation of HowD mDNS, so the software created to deploy the implementation can also utilize Avahi through the emulation interface.
MS Windows CE 5.0
Microsoft Windows CE 5.0 includes Microsoft's own LLMNR implementation.
Local IPv4 addresses
There are several implementation of available link-local IPv4 addresses:
- Apple Mac OS and MS Windows have supported link-local addresses since 1998. Apple released open-source implementations in the Darwin boot package.
- Avahi contains an IPv4LL implementation in the avahi-autoipd tool.
- IP Zero-Conf (zcip).
- BusyBox can embed a simple IPv4LL implementation.
- Stablebox, a fork of Busybox, offers a slightly modified IPv4LL implementation called llad.
- Zeroconf, a package based on Simple IPv4LL, a shorter implementation by Arthur van Hoff.
The above implementation is all stand-alone daemons or plugins for DHCP clients that handle only local IP addresses. Another approach would be to include support in new or existing DHCP clients:
- Elvis PfÃÆ'¼tzenreuter has written a patch for uDHCP client/server.
- dhcpcd is an opensource DHCP client for Linux and BSD that includes IPv4LL support. This is included as standard on NetBSD.
None of these implementations addresses kernel issues such as sending ARP replies or closing an existing network connection.
See also
- Bonjour Sleep Proxy
- Wireless Zero Configuration
- Peer Name Resolution Protocol (PNRP)
![PDF] Zero Configuration Networking: The Definitive Guide Full ...](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_uQh-z1HhvlRwx_FNlzTW3PhXUm7hXGbKBXxvUI33Y8WMCDQ6S-oonMj8B8UdVW8T4e71VGqVhRBojoucjzr4H7uecKqBSN7nWZWpQxzTpTnczFC1vwstl8bJ1h3gL667yrUHyPv4cJ=s0-d "PDF] Zero Configuration Networking: The Definitive Guide Full ...")
References
Note
Source of the article : Wikipedia
0 Comments