Zero Configuration: An Example

Zero-configuration IP networking holds a large amount of potential. Consider the everyday task of printing. Once a printer is configured on your computer or iOS device, it’s simply a matter of choosing an application’s Print command.

Take your laptop to a client’s company, or a neighbor’s house, and try to print something. If they have a printer that supports Bonjour protocols, printing is just as easy as it was on your local network. To print, connect your laptop to your client’s Wi-Fi access point and start up your laptop. Or start up your laptop and it instantly finds your neighbor’s home wireless network. Either way, your laptop automatically discovers any available printers. You open the document, choose the Print command, and every available printer appears in the Print dialog. You select a printer, click Print, and the document prints.

Or say you want to play a network game with a friend. You open the game, and your friend’s copy of the game instantly sees your copy over the network. Or if you have a music sharing application on two computers, the programs themselves can discover each other and instantly swap song lists. Similarly, if you have a shared folder or have personal Web sharing turned on, your shared files and Web pages are instantly available to others.

This scenario is illustrated in Figure 1-1. In step 1, you open up your laptop in your neighbor’s house, and the laptop either obtains an address from the DHCP server in the router or, in the absence of a DHCP server, assigns itself an available local address. In step 2, the network is queried for available printers so that when you open the Print dialog, your neighbor’s printer is listed. Finally, in step 3, you turn on music sharing on your computer, and your neighbor’s computer sees it and connects.

These are just a few of the existing applications that can benefit from zero-configuration IP networking. Zero-configuration IP networking has the potential to enhance mobile gaming, in-home networking, distributed computing, and many other network applications. Additionally, zero-configuration IP networking opens the door for a whole new class of IP-enabled digital devices.

Addressing

The addressing problem is solved by self-assigned link-local addressing. Link-local addressing uses a range of addresses reserved for the local network, typically a small LAN or a single LAN segment. To that end, the IPv6 specification includes self-assigned link-local addressing as part of the protocol. The main addressing challenge in zero-configuration networking was retrofitting this capability to IPv4.

In IPv4, self-assigned addressing works by picking a random IP address in the link-local range and testing it. If the address is not in use, it becomes your local address. If it is already in use, the computer or other device chooses another address at random and tries again.

Link-local addressing in IPv4 and IPv6 is supported on most major operating systems. Hardware manufacturers should implement link-local addressing on their devices to obtain the full benefit of Bonjour.

Any user or service on a computer or iOS device that supports link-local addressing benefits from this feature automatically. When your host computer encounters a local network, it finds an unused local address and adopts it. No action on your part is required.

Naming

The proposed solution for name-to-address translation on a local network uses Multicast DNS (mDNS), in which DNS-format queries are sent over the local network using IP multicast. Because these DNS queries are sent to a multicast address, no single DNS server with global knowledge is required to answer the queries. Each service or device can provide its own DNS capability—when it sees a query for its own name, it provides a DNS response with its own address.

Bonjour goes a bit further. It includes a responder that handles mDNS queries for any network service on the host computer or iOS device. This relieves your application of the need to interpret and respond to mDNS messages. By registering your service, the Bonjour mDNSResponder daemon automatically advertises the availability of your service so that any queries for your name are directed to the correct IP address and port number automatically.

Bonjour also provides built-in support for the NAT port mapping protocol (NAT-PMP). If the upstream router supports this protocol, OS X and iOS apps can create and destroy port mappings to allow hosts on the other side of the firewall to connect to the provided services. (NAT port mappings are described further in Firewalls and Network Address Translation in Networking Overview.)

For name-to-address translation to work properly, a unique name on the local network is necessary. Unlike conventional DNS host names, the local name only has significance on the local network or LAN segment. You can self-assign a local name the same way you self-assign a local address—choose one; if it’s not already in use, it’s yours:

• Hardware manufacturers determine whether their chosen name is already in use by having their device send an mDNS query for that name and looking for any response. If there is a response, the device should choose another name. Devices without a user interface append an incrementally larger number to a default name until the name is unique. For example, if a printer with the default name XYZ-LaserPrinter.local attaches to a local network with two other identical printers already installed, it tests for XYZ-LaserPrinter.local, then XYZ-LaserPrinter-2.local, then XYZ-LaserPrinter-3.local, which is unused and becomes its name.

• Software services provide a name when they register with Bonjour. If the provided name is already in use, Bonjour will automatically rename your service for you by default.

In OS X, users can set a host name for their computers via the Local Hostname setting in the Sharing pane of System Preferences. (In iOS, the host name is generated automatically and is not configurable.) This host name can be used anywhere a conventional DNS host name is used—Web browsers, command line tools, and so on. To indicate to the system that a name is a local host name, append a dot (.) and local. to the host name; Steve.local. is an example of a local host name.

For example, if a user types steve.local. into a Web browser, this tells the system to multicast the request for steve on the local network instead of sending it to the conventional DNS server. If a Bonjour-enabled computer named steve is on the local network, the user’s browser is sent the correct IP address for it. This allows users to access local hosts and services without a conventional DNS server.

For more information, see Domain Naming Conventions.

Service Discovery

The final element of Bonjour is service discovery. Service discovery allows applications to find all available instances of a particular type of service and to maintain a list of named services and port numbers. The application can then resolve the service hostname to a list of IPv4 and IPv6 addresses, as described in Naming.

The list of named services provides a layer of indirection between a service and its current DNS name and port number. Indirection allows applications keep a persistent list of available services and resolve an actual network address just prior to using a service. The list allows services to be relocated dynamically without generating a lot of network traffic announcing the change.

Service discovery in Bonjour is accomplished by “browsing.” An mDNS query is sent out for a given service type and domain, and any matching services reply with their names. The result is a list of available services to choose from.

This is very different from the traditional device-centric idea of network services. For someone who deals with servers, network devices, and network programming, it is easy to get in the habit of thinking about services in terms of physical hardware. In this device-centric view, the network consists of a number of devices or hosts, each with a set of services. For example, the network might consist of a server machine and several client machines. In a device-centric browsing scheme, a client queries the server for what services it is running, gets back a list (FTP, HTTP, and so on), and decides which service to use. The interface reflects the way the physical system is organized. But this is not necessarily what the user logically wants or needs.

Users typically want to accomplish a certain task, not query a list of devices to find out what services are running. It makes far more sense for a client to ask a single question: “What print services are available?” than to query each available device with the question, “What services are you running?” and sift through the results looking for printers. The device-centric approach is not only time-consuming, it generates a tremendous amount of network traffic, most of it useless. The service-centric approach sends a single query, generating only relevant replies.

Additionally, services are not tied to specific IP addresses or even host names. For example, a website may be hosted by multiple servers with different addresses. Within an organization, network administrators may need to move a service from one server to another to help balance the load. If clients store the host name (as in most cases they now do), they will not be able to connect if the service moves to a different host.

Bonjour takes the service-oriented view. Queries are made according to the type of service needed, not the hosts providing them. Applications store service instance names, not addresses, so if the IP address, port number, or even host name has changed, the application can still connect. By concentrating on services rather than devices, the user’s browsing experience is made more useful and trouble-free.

Caching

Bonjour uses a cache of Multicast DNS records to prevent hosts from requesting information that has already been requested. For example, when one host requests, say, a list of LPR print spoolers, the list of printers comes back via multicast, so all local hosts see it. The next time a host needs a list of print spoolers, it already has the list in its cache and does not need to reissue the query. The Multicast DNS responder is responsible for maintaining the cache; application developers do not need to do anything to maintain it.

Suppression of Duplicate Responses

To prevent repeated answers to the same query, Bonjour service queries include a list of known answers. For example, if a host is browsing for printers, the first query includes no print services and gets, say, twelve replies from available print servers. The next time the host queries for print services, the query includes a list of known servers. Print servers already on the list do not respond.

Bonjour suppresses duplicate responses in another way. If a host is about to respond, and notices that another host has already responded with the same information, the host suppresses its response.

Application developers do not need to take any action to suppress duplicate responses. Bonjour handles duplicate response suppression.

Exponential Back-off and Service Announcement

When a host is browsing for services, it does not continually send queries to see if new services are available. Instead, the host issues an initial query and sends subsequent queries exponentially less often, for example: after 1 second, 3 seconds, 9 seconds, 27 seconds, and so on, up to a maximum interval of one hour.

This does not mean that it can take over an hour for a browser to see a new service. When a service starts up on the network, it announces its presence a few times using a similar exponential back-off algorithm. This way, network traffic for service announcement and discovery is kept to a minimum, but new services are seen very quickly.

Services running on a Bonjour-equipped host are announced automatically when they register with the mDNSResponder daemon. Services running on other hardware, such as printers, should implement service announcement with exponential back-off to take full advantage of Bonjour.