Zeroconf

from Wikipedia, the free encyclopedia

Zeroconf or Zero Configuration Networking is a project for the independent configuration of computer networks without human intervention.

background

The corresponding working group of the Internet Engineering Task Force concluded without a result due to a lack of consensus . She worked from 1999 to 2004. Her goals were:

The working group relativized Zero ( zero ) to the effect that little configuration better than no security is.

In 2005, RFC 3927 was subsequently published on the automatic configuration of IPv4 in local area networks without the Dynamic Host Configuration Protocol . This text was written by employees of Apple , Microsoft and Sun Microsystems and also documents related previous implementations of AutoIP or Automatic Private IP Addressing (APIPA). Connections to networks other than the Internet are excluded in all of this. The IPv6 Stateless Address Autoconfiguration according to RFC 4862 is more flexible in this regard.

The simplest scenario is to connect two computers with a crossover cable . Each device then automatically looks for a free IP address and can then be addressed at this address using the Internet Protocol (IP). This task is not new and has been largely solved with AppleTalk under Mac OS and NetBIOS under Microsoft Windows . To use it, however, you have to know the IP address of the remote station, which is why Zeroconf continues to aim.

Automatic IP assignment

This is a mechanism based on the Address Resolution Protocol (ARP) to automatically select a free IP address for a network interface . The IANA provides the address range 169.254.0.0/16 for this purpose , with the first and last 256 addresses in this range being reserved for future applications.

If a computer wants to configure a link-local IP address, it selects a random IP address between 169.254.1.0 and 169.254.254.255. When generating the IP address, computer-specific information should be included, such as the MAC address of the network interface, so that the same IP address is generated every time if possible (it is only selected pseudo randomly ).

After selecting its IP address, the computer must claim it for itself and test whether it is already being used by another computer. This test must be performed before the IP address is used as the sender address in IP or ARP packets, and exactly when a network interface is activated. This can be switching on or rebooting the computer, waking up from sleep mode , plugging in an Ethernet cable or automatically connecting a computer to a WLAN . It is explicitly forbidden to carry out this check periodically, since this would represent a waste of network resources and the actual test for address conflicts already provides a possibility to passively recognize and react to possible conflicts.

Addresses are checked for conflicts with the help of ARP probes. An ARP probe is an ARP packet in which the sender IP address is set to 0.0.0.0 and the address to be checked is used as the recipient IP address.

As soon as the computer is ready to start checking the conflict, it waits for a randomly long time between 1 and 2 seconds and then sends out three ARP probes with a random interval of 1 to 2 seconds. If the computer receives an ARP packet between the start of the test and 2 seconds after the last ARP probe has been sent, in which the sender IP address corresponds to the IP address to be checked, a conflict has been found. The computer must then repeat this procedure with a different generated IP address.

If another ARP probe is received during this period that contains the IP address to be tested as the recipient IP address and whose sender MAC address does not correspond to any of the MAC addresses of the network interface of the computer, the computer must also send a new IP address can be generated and checked. This can happen, for example, if two or more computers try to configure the same link-local address at the same time.

In order to avoid ARP storms and thus overloading the local network if there are several conflicts in quick succession, each computer must reduce the speed at which it selects and checks new addresses to a maximum of one check per minute after ten unsuccessful attempts.

If the computer could not find a conflict, it has successfully claimed the generated IP address for itself. He then has to make this known by sending two ARP announcements with an interval of 2 seconds. An ARP announcement differs from an ARP probe only in that the newly selected link-local IP address is used as the sender and recipient IP address.

The detection of conflicts must take place permanently even after a usable IP address has been selected. If the computer receives an ARP packet that was sent from another computer and contains its own IP address as the sender IP address, there is an address conflict.

The computer now has two options, namely to select a new IP address or to defend its IP address. The latter is preferable if the computer still has TCP connections open. If no colliding ARP packets have yet been received, the address is defended by the computer by sending out an ARP announcement. However, if the computer was able to detect an address conflict in the last few seconds, it must select a new IP address in order to avoid an endless loop if two computers with the same IP address try to defend it against the other.

Multicast DNS

Multicast DNS in the TCP / IP protocol stack
application Multicast DNS
transport UDP
network IP (IPv6, IPv4)
Network access Ethernet Token
ring 		FDDI ...

The problems of translating names and IP addresses without a DNS server and of having a mechanism available for the automatic publication and finding of network services were conveniently summarized by the Zeroconf Working Group and in the form of the two fundamentally independent, but mutually complementary, multicast protocols DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) put on paper.

mDNS is nothing more than a description of how clients have to proceed when they send DNS requests to multicast addresses and how a group of computers deals with them so that the request is answered correctly and without increased load on the network. DNS-SD, on the other hand, specifies a convention for the use of existing DNS record types that allow browsing and publishing of network services with DNS.

mDNS specifies that the DNS top-level domain ".local." is link-local. Queries and responses that have to do with “.local.”, Similar to IP addresses from the 169.254.0.0/16 or fe80 :: / 10 range, only make sense in the local network. All DNS queries for names ending in “.local.” Must be sent to the mDNS multicast address (IPv4: 224.0.0.251, IPv6: ff02 :: fb, UDP port 5353) using UDP and IP multicast . If no other DNS server is available, requests that do not end in ".local." Can also be sent to this address.

By the way, every computer is free to choose its own computer name from the ".local." Domain. In contrast to other, public top-level domains, there are no formalities whatsoever, except that computer names that have already been assigned should no longer be used. Of course, conflicts can arise in practice, but the inventors of mDNA considered this to be very unlikely. A conflict resolution is even deliberately not discussed, since there can be useful applications in the event that several computers have the same name - for example for load sharing or high availability solutions.

If the host name for a link-local IP address is to be determined via a reverse mapping DNS query , this must also be sent to the mDNS multicast address (see above).

Avoidance of redundant network traffic

In order to keep the network traffic as low as possible, the inventors of mDNS came up with a few rules of conduct to prevent double or even multiple mDNS queries and responses.

Known Answer Suppression

One possibility for suppressing already known answers is that the client sending an mDNS query appends already known answers that can still be found in its cache as answer records to its query. If another client that could answer the query sees its suggested answer in the list of answers already given and the TTL (time to live) is still more than half of the usual TTL, it no longer has to send it. If the TTL is too low, the other client must send a response in order to update the TTL stored in the cache of the first client.

Duplicate Question Suppression

If several clients were to send the same query at about the same time, there would be redundant network traffic. If a client plans to send a request and sees a request from another client with the same content, it should regard the foreign request as its own and use the response instead of sending its own request.

Duplicate Answer Suppression

If a server, while preparing to send a response, sees a response from another server with the same content and the TTL (time to live) of the foreign response is not less than that of its own planned, then it should consider its response as sent (i.e. do not send your own answer).

Implementations

The first implementation of Zeroconf was done by Apple and is called Bonjour (formerly Rendezvous ). It has been integrated into Mac OS X since version 10.2 (“Jaguar,” 2002) , and Apple delivers most programs with Bonjour functionalities as far as it makes sense.

One component of Bonjour is the mDNSResponder project, which was published by Apple in source code under the Apache license. mDNSResponder implements mDNS and DNS-SD. It was designed and implemented by Apple to be portable, so that the source text can be translated not only under Mac OS X 10.2 or higher, but also under Linux , FreeBSD , NetBSD , OpenBSD , Solaris , VxWorks , Mac OS 9 and Microsoft Windows without modifications.

A known error in the mDNS implementation by Apple often leads to the problem under Windows 7 that a default gateway of 0.0.0.0 is entered, which is used before the gateway obtained via DHCP and thus the Internet connection of the computer is effective paralyzes. A simple solution here is to deactivate the Bonjour service via the service manager.

With Avahi there is still a free ( LGPL ) and portable implementation of mDNS / DNS-SD, which is now standard in all Linux distributions.

In order for the name resolution for the top-level domain .local to be processed as usual via the DNS server (e.g. BIND ) under Linux, an entry mDNS offin the file is /etc/host.confrequired for older implementations .

Microsoft APIPA

Microsoft's APIPA is supposed to enable home users to operate a TCP / IP network without having to deal with IP addressing and its IP parameters. The operating system tries to reach a DHCP server first. If such an address cannot be reached, a random address from the 169.254.xx area is automatically assigned.

In Microsoft Windows, the automatic IP address assignment APIPA has been implemented since Windows 98 . However, it does not fully comply with the IETF RFC . Microsoft calls this procedure Automatic Private IP Addressing or APIPA for short.

Norms and standards

  • RFC 3927 - Dynamic Configuration of IPv4 Link-Local Addresses
  • RFC 6762 - Multicast DNS
  • RFC 6763 - DNS-Based Service Discovery

Web links

Individual evidence

  1. ↑ a b Zero Configuration Networking (zeroconf) . Internet Engineering Task Force. Retrieved April 29, 2012.
  2. ↑ RFC 6763 - DNS-Based Service Discovery
  3. ↑ Windows 7 network system tray icon displays "Internet access" when there is none. Retrieved October 13, 2019 (American English).
  4. ↑ Microsoft Knowledge Base: The Default Gateway may have been set to 0.0.0.0 on a Windows Vista-based or later OS running Apple's Bonjour service
  5. ↑ Support | Name Resolution Problems with ".local" Domains. Retrieved April 14, 2017 .
  6. ↑ APIPA - Computer Lexicon - technical terms clearly explained | PC, EDP glossary. Retrieved June 12, 2020 .
  7. ↑ APIPA. (No longer available online.) Archived from the original on November 20, 2010 ; accessed on October 25, 2010 (English).
  8. ↑ Automatic TCP / IP addressing without a DHCP server. Retrieved October 25, 2010 .