Zero Configuration (ZeroConf)

Zero Configuration (ZeroConf)

As anyone who’s ever tried to hook their laptop to someone else’s to use TCP/IP to play video games, transfer files, or whatever, will tell you…it’s a pain. Even though computer manufacturer’s
and software programmers will tell you that networking is supposed to be simple, it really isn’t. You need to configure several parameters (IP address, DNS or host name, etc.) properly
or you won’t be able to communicate. These parameters are usually no problem for network technicians, but what about the average person? Configuring peer-to-peer or small network networking usually involves a game of “What should my IP address be?” between the people that want to network.
Enter the Internet Engineering Task Force (IETF) and the Zero Configuration (ZeroConf) initiative. The primary goal was to make networking via TCP/IP extremely easy and “hands off” for small networks. Ideally, two computers could be connected through Ethernet jacks with only a crossover cable and be able to communicate without any further configuration. In order
to accomplish this, the ZeroConf working group of the IETF had four main areas of focus:

1. Automatic Interface address configuration
2. Automatic Multicast address configuration
3. Translation of addresses to names and names to addresses
4. Service location

In order for the ZeroConf initiative to be successful, each of these components must be implemented in the ZeroConf protocol.

Note:

Apple Computer has been a large participant in the design of the ZeroConf protocol.
It has its own protocol, called Rendezvous, which itself is an open Zero-Conf protocol that has been submitted to the IETF for approval.

Automatic Local Interface Configuration
As you may already know, a computer must have a local IP address in order to communicate. Instead of relying on static addressing (too much work and too much to know) or dynamic addressing (other hardware required), ZeroConf allows for automatic configuration by the two communicating entities themselves. In the absence of a manually configured address or a DHCP server, the communicating entities will “figure out” their own local IP addresses (known as linklocal addresses) as follows: First, for each interface, each computer chooses a random TCP/IP address somewhere in the address space 169.254.1.0 to 169.254.254.255 (that is 169.254.0.0/ 16 with the top and bottom 256 addresses reserved for future use). Then, the computer configures its local interface with this address. Of course, it wouldn’t do any good if both computers chose the same address. So, two things happen to prevent that. First of all, the random number used to select the IP address is based on several computer-specific items (including the MAC address, real time clock, etc.) so that each computer is guaranteed a unique address. In addition, after the unique address is selected, it must be tested to ensure that no other device is using the same link-local address. To do this, the computer uses ARP to tell the other computers on the network segment connected to the interface being configured what IP address it intends to use. If no devices respond that they are already using that address, the interface is configured with the chosen address and communication
can take place.

Note:

 Windows has had this capability since Windows 98. Microsoft calls it Automatic
Private IP Addressing, or APIPA. The basics of this capability have been
incorporated into the ZeroConf proposed standard.

Multicast Address Selection
Another requirement of the ZeroConf initiative is that there is a mechanism for automatically choosing multicast addresses for the network. The IETF has defined the standard for the Zero- Conf Multicast Address Allocation Protocol (ZMAAP). This protocol is used to allocate multicast addresses among the various peers in small, peer-to-peer networks.
This protocol is the polar opposite of the multicast address assignment protocol known as MADCAP, which stands for Multicast Address Dynamic Client Allocation Protocol. Where
MADCAP is a client-server multicast address allocation scheme, ZMAAP is a peer-to-peer allocation scheme. Essentially, each node on a ZeroConf network is running its own little multicast 
allocation service (called a mini-MAAS in ZeroConf parlance). Any entity that needs a multicast address will make a request to its local mini-MAAS, which will then select an address and, before permanently allocating it, inform the other local mini-MAASs of its choice. If there are any objections, the originating mini-MAAS will rechoose the address. Otherwise, it will go ahead and allocate the address.

Name Resolution
You might think that there isn’t a way around name resolution, apart from constantly exchanging HOSTS files or some other silliness. In actuality, ZeroConf relies on standard TCP/IP protocols, including one known as Multicast DNS. Traditional DNS relies on centralized servers to answer DNS queries. But the addresses of these servers must be configured (and the goal is zero
configuration), so the designers of ZeroConf decided to use Multicast DNS. Multicast DNS was a little-used protocol until ZeroConf came along. 
       Traditional name resolution works much like asking the host at a party to introduce you to the people in the party you don’t know. Let’s say you wanted to know which person in the room was named John. With the traditional DNS model, you would ask the party host (the “DNS server” in our scenario). If you were to use Multicast DNS in the same scenario, you would simply
shout in the room, “Hey, is there a John in here?”
       Multicast DNS essentially puts out a multicast transmission that asks for the address of the network name being requested. This works great in small networks, but the amount of traffic required and the introduced delays make Multicast DNS impractical for larger networks, such as the Internet.

Service Location
The final aspect of ZeroConf is service location. It is important on networks to be able to locate services. AppleTalk is the master of finding services on a network without configuration. Apple
designed it so that whenever you plugged a printer into an AppleTalk network, it would advertise itself on the network and you could just choose it. This traditionally has been difficult on
TCP/IP networks. Furthermore, the chatty nature of such services would not be welcome on large networks.
       The IETF has designed a protocol specifically for locating services on a ZeroConf network.
That protocol is known as DNS Service Discovery, or DNS-SD. DNS-SD allows clients to use regular DNS queries, without the need for a new DNS message structure, to find a list of names

of particular types of services provided within a particular domain.