Cover | Table of Contents

Table of Contents

Chapter 1: Introduction to Bonjour and Zeroconf

Content preview·Buy reprint rights for this chapter

You walk in a few minutes late to a meeting and want to know what you've missed. You open your text editor and your computer automatically discovers a shared document in which one or more attendees are taking notes. You have a couple of colleagues who are busy in another meeting but are interested in the topics being discussed in your meeting. You invite your colleagues to view the notes being taken and to contribute their comments and questions. A presenter announces that anyone wanting a copy of his slides should let him know. You open your local Instant Messenger application and see his name in the list of available names, even though you have never met before and he is not in your buddy list. A moment later, he has placed his presentation in your drop box in your Public folder, which he has discovered in his network directory.

The meeting comes to an end. Before anyone erases the whiteboard, someone snaps a quick picture or two and puts it in their photo-sharing library so that anyone interested can download it. You notice a new entry in your audio software that announces that the person who was recording the session has already posted it in her shared audio library. Before you save the notes on the session, you decide to print out a copy to read on the plane ride back. In the print dialog, you discover several printers and choose the one labeled "Third Floor Meeting Rooms."

This is not a fantastical glimpse of the elusive future. It is a concrete description of what is available today using Zeroconf. In this chapter, you will get a quick overview of the various components that make up Zeroconf. In the following four chapters, these details will be fleshed out. The second half of this chapter examines the Zeroconf design principles that build on two decades of experience with the AppleTalk Name Binding Protocol.

None of the examples that took advantage of Zeroconf began with someone thinking, "You know what I could really use right now? An IP address." Certainly, it's a

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Service Discovery with Zeroconf

Content preview·Buy reprint rights for this chapter

None of the examples that took advantage of Zeroconf began with someone thinking, "You know what I could really use right now? An IP address." Certainly, it's a

The seeds of Zeroconf were planted in some postings by Stuart Cheshire on the Net-Thinkers mailing list in 1997. This led to the IETF holding two "Birds of a Feather" (BOF) sessions at the March and July 1999 IETF meetings on the subject of "Networking in the Small" (NITS), co-chaired by Stuart Cheshire and Peter Ford.

Out of the NITS BOF meetings, the Zero Configuration Networking (Zeroconf) Working Group was formed in September 1999.

In May 2002, Apple announced its trademark "Rendezvous" for the Zeroconf technologies, a little like the way Apple uses its trademark "AirPort" for IEEE 802.11 wireless networking.

Unfortunately for Apple, another company also had a networking product by the name of "Rendezvous," and in April 2005, Apple announced the new Apple name for the Zeroconf technologies: "Bonjour." Other third-party products can also carry the Bonjour name and logo. Apple doesn't charge any money to license the name and logo; the products just have to pass Apple's Bonjour Conformance Test to verify that they do in fact implement the specifications properly.

Meanwhile, other open source implementations of the Zeroconf technologies have also been created, including Howl and Avahi.

The terms "Bonjour" and "Zeroconf" are often used interchangeably, but as a general rule, this book uses the term "Zeroconf" when referring to the technology in general and "Bonjour" when referring to it in an Apple-specific context. For example, iChat on Mac OS X doesn't have a "Zeroconf" window; it has a "Bonjour" window (it says "Bonjour" at the top of the window).

rare person who takes the time to say, "Now that I have an IP address, I could use a friendly domain name. I should learn how to set up DNS on my laptop." A typical user of Zeroconf should not be aware of the infrastructure required. She just wants to use a printer, stream music, exchange photos, or use some other service.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Replacing the AppleTalk Name Binding Protocol

Content preview·Buy reprint rights for this chapter

At the end of any software engineering effort, the developers have a deep understanding of the problem they were solving. Imagine how much better the finished product would be if they had time to start over with the benefit of the experience they have gained. The DNS Service Discovery (DNS-SD) layer of Zeroconf builds on years of experience with AppleTalk and its Name Binding Protocol (NBP) and improves on the earlier technology while building an all-IP solution.

Over the last 30 years, many protocols have competed in both the wide-area networking (WAN) and local-area networking (LAN) arenas. In the WAN arena, it is clear that IP won, and even in the LAN arena, IP is rapidly gaining ground. When people have networks within their homes today, using Ethernet or IEEE 802.11 wireless, it is generally IP that they use most over those networks, rather than other protocols like AppleTalk or NetBEUI. The last remaining place where non-IP protocols still thrive is in short-distance links tethered close to the computer, but even these are showing signs of migrating to IP. USB, FireWire, and Bluetooth all now have ways to carry standard IP packets in addition to their own various task-specific protocols. To illustrate with just one example, when using the native file copying protocols, copying files between two computers using Bluetooth uses different software and a different user interface than copying over FireWire, which is different than copying over USB, and so on. In contrast, when using IP over those same physical links, any given software application (e.g., FTP) works exactly the same way, regardless of whether the underlying hardware is USB, FireWire, Bluetooth, Ethernet, 802.11, or something else.

What made USB and FireWire attractive compared to IP for short-distance communication is that they are relatively easy to use and hassle-free. With Zeroconf bringing the same convenience and ease of use to IP, one of the last remaining objections to using IP for short-distance communication, as well as wide-area communication, has been eliminated.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Summary

Content preview·Buy reprint rights for this chapter

Zero Configuration Networking—Bonjour, as Apple calls it—provides a three-layer foundation to enable hardware and software makers to produce great products. Zeroconf doesn't do printing. Zeroconf doesn't do network music. Zeroconf doesn't do photo sharing or multiuser document editing or instant messaging. What Zeroconf does is provide the rock-solid foundation so that those great products can be built without worrying that, from time to time, TCP/IP might fall apart and let them down.

Chapter 2 describes the first layer of the three-layer foundation: getting an IP address when there's no working DHCP server. Chapter 3 describes the second layer: being able to refer to hosts by name when there's no working DNS server. Chapter 4 describes the third layer: discovering what's available on the network without having to ask the person sitting next to you for help. Chapter 5 extends Chapter 4's local service discovery out to the global Internet. The second half of the book, Chapters 6 and onward, presents the APIs in various different languages that allow you to use local- and wide-area service discovery in your hardware and software products.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: IP Addresses Without DHCP

Content preview·Buy reprint rights for this chapter

Each device on an IP network will need at least one unique IP address. Until you run your own network, you may not think very hard about how this works. You or someone from the IT staff most likely configured your computer at work to use a specified IP address or to use the company DHCP server, but the days when networks existed only at a few large universities and companies are behind us. Nowadays, there are small networks popping up everywhere. Computers and devices need to communicate. Your home may have a computer or two, a printer, a scanner, a digital camera, and a phone. You do not want to learn to be a network administrator just to get these devices to play nicely together, and there's no reason you should have to—just like there's no reason you should have to learn to be a car mechanic before you can drive a car.

You will see even more of these small local networks connecting various devices pop up at homes, coffee shops, or while on a walk. If we are to standardize on IP for communication among devices, it needs to be easier for them to obtain IP addresses. Suppose you take a bunch of pictures with your digital camera and wish to print them, save them to your computer, or transfer them to a friend's. When you cable that digital camera to a printer or a hard drive, or you connect your computer to your friend's wirelessly, you don't really want to have to depend on a DHCP server being present, and you don't really want to have to configure each device manually with an IP address. You would like there to be an automatic configuration of IP addresses that provides each device with a unique address.

In this chapter, we present three different ways in which a device may obtain an IP address: manual, DHCP, or self-assigned. As a motivating analogy, imagine that you want to enter a 65,000-seat auditorium to attend a networking lecture. At the moment, several seats are occupied. There are a variety of strategies that could be used:

• We could require that every student attending the lecture obtain a seat assignment in advance from an auditorium administrator. Each student arrives at the auditorium with a preprinted ticket and will refuse to sit in any seat other than his assigned one. If, by mistake, two students have been assigned to the same seat, then one of two things will happen. The first possibility is that if either of the two students behaves like Mac OS or Windows, one of the two students will leave the auditorium and complain to the administrator about the mistake. The administrator is expected to correct the mistake. The second possibility is that if both of the students behave like some other operating systems, a violent fistfight will ensue, not stopping until either at least one participant is dead or the human administrator intervenes and forcibly drags one or the other combatant (or both) from the auditorium against their will. This is analogous to manual address assignment. It is heavily dependent on the auditorium administrator never making a mistake.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Obtaining an IP Address

Content preview·Buy reprint rights for this chapter

There are two components to choosing an IP address for a given network. You need to find a legitimate address and you need to confirm that you are the only one using this particular address on this network. A network administrator can manually assign your IP address. In this case, the administrator is responsible for ensuring the assigned address is available and unique. If there is a DHCP server configured for your network, you can use it to obtain a unique IP address. Zeroconf allows you to automatically select an IP address in the absence of a DHCP server or network administrator.

Whatever your platform of choice, there is usually some way to configure your network settings by hand. Often, there is a GUI that makes it easy for you to enter your IP address, subnet mask , and gateway/router information. In Mac OS X 10.4, you either select Network after choosing Apple Menu → System Preferences...or by selecting the Apple Menu → Location → Network Preferences...item.

Section 2.1.1.1: Entering an IP address

In the example shown in Figure 2-1, the IP address 192.168.1.123 has been selected. For now, this discussion is limited to IPv4 addresses. These are 32-bit values that are usually written as four positive integers, each between 0 and 255, separated by dots. This familiar format is known as dotted decimal.

Figure 2-1: Assigning an IP address manually

The second number that you enter is the subnet mask. This is also a 32-bit number and is used to indicate which portion of the IP address contains information about the network and which portion contains information about the host. The network information corresponds to those bits that are turned on in the subnet mask. In the example shown in Figure 2-1, the first 24 bits are on and the last 8 bits are off. You can also represent the information contained in the IP address and subnet mask fields together by writing 192.168.1.123/24. The forward slash and the 24 at the end indicate that the first 24 bits are reserved for the network information, so the remaining 8 bits are for the host information. The host uses this information to determine how to deliver IP packets. When sending a packet, the host checks the network number (the first 24 bits, in this example) in the destination address, and if that exactly matches the network number in its own address, that means that the destination is on the same subnet and the packet is sent directly to the destination machine. Otherwise, the destination is not on the same subnet, so the packet is sent to the default gateway for forwarding on to its eventual destination.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Claiming a Link-Local IP Address

Content preview·Buy reprint rights for this chapter

You do not have the right to use the address you have selected until you test that no one else on the network is already using it. In Figure 2-9, you see the output captured by Ethereal as the machines foo and dimsumthinking try to build a local network.

Figure 2-9: ARP probes on generating Zeroconf addresses

Each machine first picks an address it thinks it would like to use. The machine dimsumthinking has chosen 169.254.187.245. It then sends some Address Resolution Protocol (ARP) requests asking for the MAC address that goes with 169.254.187.245. ARP is the protocol that's used when a computer wants to talk to another machine on the local network. The computer knows the IP address it wants to talk to but not the Ethernet/MAC address of the machine with that IP address, so it broadcasts an ARP request asking for that information. In this case, we're using ARP slightly differently: we're sending an ARP request for our own address and hoping that we actually don't witness anyone else respond to that request. If someone answers, that means they already have the address, so we can't.

Note that, in the Tell section, the address is 0.0.0.0 because dimsumthinking is not yet asserting that it owns that address. These are ARP probes. After a couple of seconds without receiving any reply, dimsumthinking concludes that no one is using the address, so it may proceed to use it. dimsumthinking then sends out a couple of ARP announcements. Ethereal displays these in the "Who has" format, but in reality they are statements, not questions. The "Tell 169.254.187.245" section is saying, "I am 169.254.187.245."

Later in the trace, around the 26-second mark, dimsumthinking wants to communicate with foo.local. It sends an ARP request, saying "Who has 169.254.186.86? Tell 169.254.187.245," and foo replies with an ARP reply, saying "IP address 169.254.186.86 is at MAC address 00:03:93:ef:c4:8c."

We cover this process in more depth next.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Summary

Content preview·Buy reprint rights for this chapter

Link-local addressing, like all of Bonjour/Zeroconf, has two important goals: simplicity and reliability. Simplicity is important because this technology is not only for powerful $1,000 computers; it is for all manner of emerging ultra-low-cost devices that will use IP networking. Reliability is important because this technology is not just for today's computer experts. This technology is for use by the general public, who have neither the knowledge nor the patience to struggle with all manner of arcane and inexplicable computer failures, and indeed they shouldn't have to. Global communication on the worldwide Internet is very powerful and very useful, but there are many ways that global connectivity can fail, so it's beneficial to have an alternative backup technology that can be relied upon to always work, no matter what. Sometimes, reduced functionality—communication only on the local link—is better than no communication at all.

Consequently, following the goals of simplicity and reliability, the steps for obtaining a link-local address are designed to be as straightforward and simple as possible. Choose a potential IP address in a reasonable way. Select from the allowable addresses in the 169.254/16 range. As Zeroconf is designed for situations in which fewer than 2% of the IP addresses have been assigned, your host will almost surely obtain an address within the first one or two tries. To increase this likelihood, your best strategy is to first try to reclaim an address you have previously successfully claimed. You can then use this address to seed your pseudorandom-number generator. After selecting an address, your host ARPs three times with the target address in the ARP set to the desired IP address. If there is no response during a reasonable time period, the address is claimed by sending a further ARP with the desired IP address entered as both the source and target address in the ARP broadcast. Once an address is selected and in use, the reliability requirement calls for ongoing vigilance, to handle the extremely rare (but possible) case where conflicts are not detected until later.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: Names Without DNS

Content preview·Buy reprint rights for this chapter

In Chapter 2, you saw how Zeroconf allows your device to obtain a locally unique IP address without a DHCP server or a network administrator. The next step is to obtain a name that can resolve to this address. The method you use to do that is independent of how you have obtained your IP address; for example, you may have taken advantage of link-local addressing, been assigned an address using DHCP, or manually assigned an IP address. If you need a name that is at least locally unique and there is no DNS server available, the Multicast DNS (mDNS) mechanism will help you obtain one.

This stage may feel unnecessary. After all, why not just use the IP address obtained in the last step as the device name? IP addresses may change over time, and network location and IP addresses are not a convenient form for people to remember or recognize devices. In other words, you need to assign locally unique names and not use the automatically assigned IP addresses for the following reasons:

• The IP address provided may be temporary . If you are communicating with a device at a given address, it is quite possible that, at a later time, the device may have a different address. Attempting to contact the device by connecting to its old address will not succeed. Even worse, that address could be reused by a different device, so when you attempt to connect to it, you may apparently succeed, except you're not actually communicating with the device you intended.
• With mobile devices and devices connected to many networks, the device cannot expect to keep the same IP address in every location and on every different network. In a world where IP addresses are fluid and changeable, having a persistent name that's relatively much more stable is a big benefit. Of course, names also have to be unique—two devices cannot have exactly the same name—but the space of all possible names is so much larger than the space of possible IP addresses that coming up with unique names is relatively much easier.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

A Brief Tour of DNS

Content preview·Buy reprint rights for this chapter

Your mobile telephone number is used to reach your phone while you travel from place to place and even if you switch providers. When you register an Internet domain name, you can be assured that it is unique and you can publish it so others can use it to find you. If you later move your host machine(s) to a different location or IP address, this name that you have advertised will still correctly direct people to your web site. Some central authority must administer telephone numbers and domain names if we want to ensure consistency and stability. This section provides a quick overview of DNS.

Consider a typical URL, such as the one for Apple's Bonjour home page:

http://developer.apple.com/bonjour/

The http identifies the protocol as the hypertext transfer protocol. The developer.apple.com identifies the machine where the resource can be found, and /bonjour/ identifies the particular resource on that machine.

A domain name read left to right moves from the specific to the general. So, developer is a node in the apple.com domain and apple is a node in the com domain. There are other domains at the same level as com that sit under the root of the domain name space in the same way that bin, dev, and usr directories sit under the root of a Mac OS X machine. On a Mac OS X or other Unix machine, you might have a path such as /usr/lib. The leading slash (/) character is used as a separator, and we also think of the root of a Unix file system as being (/) and navigate to the root by typing cd / in a terminal window. When you type a filename or pathname in Unix without a leading slash, it's interpreted relative to your current working directory, whatever that might be. If you're not currently in the directory you thought you were in, then the filename or pathname might not actually refer to the file you intended. When you type a filename or pathname with a leading slash, it's an absolute name, relative to the root of the file system, so there's no ambiguity.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Zeroconf Namespace

Content preview·Buy reprint rights for this chapter

When you want to run a global web server that's reachable from anywhere on the planet, you need a globally unique name that's resolvable from anywhere on the planet. However, if you're setting up a web server that's only used locally, then it would be nice if you didn't have to incur all of that overhead. Running a web server on Mac OS X is as simple as just clicking one checkbox, so it would be nice if getting a name for that server were as easy. As shown in Figure 3-3, you check the Personal Web Sharing checkbox to start up the Apache web server.

The content of the computer's web site is contained in the /Library/Webserver/Documents/ directory. The index.html file will appear when the browser is pointed at the provided IP address. In addition, each user can have a personal web site that is accessed using the IP address followed by ~ username /. The pages being served are in this machine under the ~username/Sites directory.

Note that, in the Figure 3-3, the displayed URL contains an embedded IP address. This is not very memorable, nor user-friendly, and because it's a DHCP-assigned address, it may well be different tomorrow. What we need is a memorable, stable name in place of this IP address.

Figure 3-3: Starting the Apache Web Server on Mac OS X

In order to distinguish local names from existing domain names, Zeroconf uses .local. as a pseudo-top-level domain (TLD). Just as IP addresses beginning with 169.254 are deemed special, not globally unique, and therefore only meaningful on the local link, names under the pseudo-TLD "local" are similarly deemed special, not globally unique, and only meaningful on the local link. The benefit of local names is that you don't need an arbiter who hands out names and you don't have to pay money for them. The drawback of local names is that because there's no arbiter and you didn't pay any money for your name, you can't claim unique ownership and prevent others from using that same name if they want. Instead, devices using local names have to follow a set of cooperative rules (i.e., protocol) by which they detect if two devices try to use the same name at the same time, and, if this happens, one of them voluntarily selects a new unique name. You cannot assume, if you see the name

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Multicast DNS

Content preview·Buy reprint rights for this chapter

Most conferences have a message board somewhere where you can post and retrieve messages. The key is that there is a well-known place for you to visit to send or read items of interest to an individual or to a group. The message board is not generally secure and you cannot be assured that messages have been reliably delivered unless the target of your message replies. Other people can see the same messages you can see. Often, a friend will stop you in the hall to let you know that there is a message waiting for you on the message board. The message board is a great mechanism to announce a so-called "birds of a feather" session where people who share a common interest convene.

A multicast address is the network world's equivalent of a shared public-notice board. Using a previously agreed-upon IP Multicast address and port, messages can be delivered that will be received by all subscribed devices. Devices on a local link can use Multicast DNS to resolve locally unique hostnames. Every device on the local link listens for queries that are sent to the multicast address, and when it sees any query for its own name, it answers. In this section, you will see how the multicast part of mDNS works.

Any DNS query for a name ending in .local is sent to the address 224.0.0.251, which is the IPv4 address that has been reserved for mDNS. For a list of assigned multicast addresses, see the IANA document "INTERNET MULTICAST ADDRES-SES" at http://www.iana.org/assignments/multicast-addresses (IPv4) and http://www.iana.org/assignments/ipv6-multicast-addresses (IPv6). The IPv6 mDNS link-local multicast address is FF02::FB. The concepts of Multicast DNS apply equally, whether the data is sent in IPv4 multicast packets or IPv6 multicast packets.

Because 224.0.0.251 and FF02::FB are in the link-local multicast ranges for IPv4 and IPv6, respectively, packets sent to these addresses are never forwarded outside the local link nor forwarded onto the local link from outside. A device can therefore be sure that any link-local multicast packets it sends remain on the local link, and any link-local multicast packets it receives must have originated on the local link.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Claiming Your Local Name

Content preview·Buy reprint rights for this chapter

This section looks at the dance that results in a device obtaining a locally unique name. The details of the Multicast DNS Querier and Responder, and other mechanics of where the messages are being sent and which devices are listening, were covered in the previous section. For now, consider a device that has an IP address that is now trying to claim a unique name in the .local domain. The steps and precautions parallel much of what was described in Chapter 2. The sequence is very similar: first, a name has to be chosen, then the device probes to check for uniqueness , and then it announces its chosen name.

Once a hostname is chosen for a particular device and an IP address has been selected or assigned, the next step is to create a local Multicast DNS address record that maps the name to the IP address. DNS Record types are documented in the IETF's RFC 1035 "Domain Names - Implementation and Specification" (http://www.ietf.org/rfc/rfc1035.txt). DNS Record type A is the IPv4 address record type.

Having created our tentative address record (also known as an A record), we need to check to see if someone is already using an address record with that same name. (The name of the A record and our desired hostname are one and the same.)

We could send an mDNS query for our desired hostname, DNS type A, and see if we get any responses. However we may also want to create other record types for our hostname, such as host info (HINFO), so we instead send a query for DNS query type T_ANY, in order to find if there are records of any type with that name.

What does DNS query type T_ANY mean? Many assume it's a wildcard search that returns all matching records, but this is incorrect. The query type is called T_ANY, not T_ALL. The semantics of the T_ANY query are that if there are any records with that name, of any type, it will return at least one of them. Sometimes, it may return all records, but not always. This is particularly true with DNS caches. If a cache has

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Structure of the Multicast DNS Message

Content preview·Buy reprint rights for this chapter

The Multicast DNS Message format is modeled closely on the Unicast DNS Message format. In fact, they are so similar that packet-sniffing software such as Sniffer, EtherPeek, and Ethereal can decode and display mDNS packets using the same decoder as uDNS packets. There are, however, a few minor differences:

• Unicast DNS packets are limited to, at most, 512 bytes. Multicast DNS packets are allowed to be up to 9,000 bytes, though it's recommended that implementations try to limit themselves to using packets only as large as the local link can carry without breaking the packet into multiple IP fragments. Standard Ethernet can carry packets up to 1,500 bytes without fragmentation. Subtracting 28 bytes for the IP and UDP headers, this leaves up to 1,472 bytes for the DNS portion of the packet.
• Multicast DNS uses UDP port 5353 instead of port 53.
• Multicast DNS uses UTF-8, and only UTF-8, to encode resource record names. Unicast DNS, for a variety of legacy compatibility reasons, has to use arcane encoding for non-roman text, but Multicast DNS is a new technology not saddled with those limitations, so it has the luxury of using the much simpler UTF-8 for everything.
• Unicast DNS only allows query packets to contain one question each. For efficiency, Multicast DNS allows clients to pack in as many questions as they wish. They're still treated by the receiver just the same as if they were separate packets—packing them into a single packet is just an optional optimization to save network bandwidth.
• Multicast DNS "borrows" the top bit of the rrclass field in a resource record. Remember that the only DNS class in widespread use today—out of the 65,536 possible values for this 16-bit field—is the Internet class. By repurposing the top bit, we cut the range of possible class values in half to 32,768, but that's still a lot when you consider that we're only actually using one today. In responses, the top bit of the rrclass field is called the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Summary

Content preview·Buy reprint rights for this chapter

Zeroconf's Multicast DNS, like RFC 3927 link-local addressing, provides a safety net when the equivalent conventional infrastructure is not present or working. When there's no DHCP server, link-local addressing gets you an address that's at least good for the local link. When there's no DNS server, or there is one but you have no way to add your own hostnames to it, Multicast DNS gives you a way of referring to devices by name that at least works on the local link. This gets us to a useful level of functionality: even when DHCP and DNS are broken, link-local addressing and Multicast DNS mean that you can give your devices names, refer to them from other computers using those names, and establish working TCP connections so that you can do useful networking. Zeroconf doesn't stop there, though. With the technology described so far, you can do useful networking, but you need to know the hostname, you need to remember it, and you need to type it in correctly. If you mistype it, misremember it, or just don't know the name of the printer, you're in trouble. Wouldn't it be better if you didn't have to know the name of the printer in advance? Wouldn't it be better if you could just say, "I need to print a document. Is there anything on the network that can help me with that?" That's Zeroconf's DNS Service Discovery technology, and that's the subject of the next chapter.

The American Standard Code for Information Interchange (ASCII) has long been the standard way most computers represent text in their memories and on their disks. Each letter, digit, and symbol is represented by a different seven-bit binary code. Rather than write the codes in binary, they are usually written in numerical form, as numbers from 0 to 127. For example, the code for A is 65.

The problem is that while 128 values are enough to represent English uppercase letters, lowercase letters, digits, and punctuation, they're not enough to represent all the accented characters used in European languages, and definitely not enough to represent all the characters used in Japanese, Hebrew, Indian languages, and so on.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 4: Browsing for Services

Content preview·Buy reprint rights for this chapter

Once you are on a network where you have a working IP address and hostname, you are in a position to begin doing some useful networking. Your IP address may change over time, particularly if you are using IPv4 link-local addressing, but your Multicast DNS hostname generally won't. People on the local network can access services running on your machine using your mDNS hostname anywhere a conventional hostname would be used, automatically connecting to your current address, even if your address changed since the last time they connected. People can use your mDNS hostname on the command line to connect with FTP or SSH commands. If your machine is running a web server, others can connec[t to it by entering your mDNS hostname into their web browser. Note that web servers can take many forms apart from the conventional collection of static pages: if you have a typical network-connected camera with Multicast DNS, you can connect by typing its name (e.g., netcam.local) into your web browser. This is, of course, a big improvement over having to know the IP address to type, but in some ways we've merely moved the problem, not solved it. Instead of having to know what IP address to type, you now have to know what name to type. In the case of IPv6 addresses, which are 20-40 characters long, a short, memorable hostname is definitely an improvement, but imagine how much better it would be if you didn't have to know the name at all, and your web browser could simply instruct the network, "Show me the list of services that I know how to talk to."

This chapter introduces DNS Service Discovery (DNS-SD), the mechanism in Zeroconf that lets you discover what services are available on the network without having to know device or service names in advance via some other means. DNS Service Discovery is accomplished by building on existing standard DNS queries and resource record types, not by creating a new set of technologies and hoping they will be adopted over time. Enhancing and extending existing technologies is one of the things that has helped lead to the quick adoption of DNS-based service discovery.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Zero Configuration Operation

Content preview·Buy reprint rights for this chapter

Finding services should be as easy as turning on a lamp. If technological devices continue to be unreasonably hard to set up and use, the market for those devices is going to be stifled because the buying public simply won't be willing to expend the time and effort it takes to get them to work.

Consider a table lamp. The customer needs to plug the lamp into a live AC outlet, the lamp needs to have a working bulb properly in place, and the customer needs to locate and operate the switch. When a customer flicks a switch and the light does not come on, there are not many things that could have gone wrong. The tech support script is pretty basic: "You say the light doesn't come on. Did you try the bulb in a different lamp to make sure the bulb is good? Did you try connecting some other appliance to the outlet to make sure it's providing power? What? I see. You hadn't actually plugged the lamp into a power outlet? That may be your problem. Sure, I'll hold while you try that. Works now? Great. No, really it's no problem, your service contract allows you unlimited calls for the first year you own your lamp." This scenario is comical because, of course, no one has technical support service contracts for table lamps. We need to arrive at a world where we think of consumer electronics and networked devices the same way we think of table lamps.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Finding Services, Not Devices

Content preview·Buy reprint rights for this chapter

In the world of networked devices, it does you no good to locate a device with which you cannot communicate. We commonly anthropomorphize devices in ways that are not quite correct. We say that we "pinged a server," though, in fact, what we pinged was a piece of software on the server that answers ICMP echo request packets. If you take away that software, it stops answering ping requests, even though the server is still there and may still be performing other functions perfectly well.

When designing a service discovery system, it's important to remember that what network software clients need to discover are software entities with which they can communicate, not pieces of hardware. The difference between discovering services and discovering hardware may seem small and subtle, but it makes all the difference in actual use. In a print dialog, you want to see the list of things you can print to. In iTunes, you want to see the list of music sources you can play. In iPhoto, you want to see the list of photo albums you can view. In a web browser, you want to see a list of offered web pages you can view. Any given piece of hardware on the network may offer zero, one, or more of each of these kinds of resources. What you want to see is the list of resources you can use, not a list of the hardware where they may or may not reside.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Knowing the Protocol

Content preview·Buy reprint rights for this chapter

A visitor staying in Paris wants to know whether she should take her umbrella on her travels around the city. Standing in the hotel lobby in the morning, she sees a local newspaper, which has the day's weather forecast, but it is in French. She doesn't read French. Also in the hotel lobby is a copy of an English newspaper, which she can read, but the English newspaper doesn't include a weather forecast for Paris. This illustrates one of the challenges of network software. To be useful, a service has to (1) provide the conceptual service the client wants (e.g., a weather forecast) and (2) provide it using a language (protocol) the client can speak and understand (e.g., English). Because of this, a Zeroconf service type name conveys not just the "what" of a service but also the "how." For example, the Zeroconf service type _ipp encodes both the "what"—printing—and the "how" via Internet Printing Protocol.

When an IPP printing client browses for services of type _ipp, it is not looking for printers in a broad, fuzzy, not-very-precisely defined human sense. It is looking specifically for printers it can talk to. It is looking specifically for printers that implement IPP, the Internet Printing Protocol. There may be an old AppleTalk printer nearby, which may be a printer as far as human beings are concerned, but from the point of view of an IPP printing client that has no way to communicate with an AppleTalk printer, it may as well not exist. From the point of view of IPP printing client software, it's only useful to discover things that it can actually use. This is one of the reasons that proliferation of network protocols is a bad thing. While we may

DNS-SD service types—i.e., application protocol names—all begin with an underscore. There's no particular reason for this; it is simply a convention inherited from RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)." The original motivation was to avoid accidental conflicts with existing DNS hostnames. Since DNS hostnames are not supposed to begin with an underscore, requiring all service names to begin with an underscore was seen as a way to prevent accidental overlap of the namespaces. It's not really necessary; it's one of those conventions where there's no particularly compelling reason for it, but there's also no particularly compelling reason to change it either.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Building on DNS

Content preview·Buy reprint rights for this chapter

As early as the 1980s, AppleTalk had an effective service discovery mechanism. Many attempts have been made to replicate that on IP, but none have been a resounding success. Zeroconf took an unconventional approach to solving this problem. Rather than inventing an entirely new protocol from scratch, it built on an existing ubiquitous standard, DNS. A scalable service discovery mechanism needs to work both on small networks, operating peer-to-peer with no infrastructure, and on large networks, where peer-to-peer multicast would be too inefficient and, instead, service discovery data needs to be stored at some central aggregation point. As pointed out in the Internet Draft on DNS Service Discovery, DNS and its related protocols already provide the properties we need:

Service discovery requires a central aggregation server

DNS already has one: it's called a DNS server.

Service discovery requires a service registration protocol

DNS already has one: it's called DNS Dynamic Update.

Service discovery requires a query protocol

DNS already has one: it's called DNS.

Service discovery requires security mechanisms

DNS already has security mechanisms: they're called DNSSEC.

Service discovery requires a multicast mode for ad-hoc networks

Zeroconf environments already require a multicast-based, DNS-like name lookup protocol for mapping hostnames to addresses, so it makes sense to let one multicast-based protocol do both jobs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Late Binding

Content preview·Buy reprint rights for this chapter

Sometimes, when a user chooses a service from a list, it is for immediate use.

Other times, a user makes a choice, like picking a default printer, which may be used repeatedly in the coming hours, days, or weeks. In the latter case, it's important that the client software store the chosen service name, type, and domain, instead of resolving the named service to an IP address and storing that. This is because IP addresses and port numbers can change, whereas service names are the intended stable identifier for a given logical service instance. As long as the client resolves the service name at printing time, it will be sure to get the current address and port number, even if they have changed in the time since the service was first discovered.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

DNS-SD TXT Records

Content preview·Buy reprint rights for this chapter

In many cases, all a client needs to know to contact and use a service are the hostname or IP address where that service resides and the port number on that host.

There are other cases where more information is required. For example, a print server may advertise three LPR printers. All three logical printing services are being offered on the same host. All are being offered via the LPR port. What distinguishes them is the LPR queue name. How does a client, having discovered an advertised printer, know what LPR queue name to specify when contacting the machine hosting that service? If it doesn't specify the right LPR queue name, its output may not go to the right physical printer. The answer is the DNS TXT record. In addition to the SRV record, every DNS-SD service has a TXT record, optionally containing additional parameters and attributes of interest to clients. DNS-SD uses the DNS TXT record to store a series of key/value pair attributes in the form "key=value." The TXT record is a standard DNS record type, but DNS-SD establishes some conventions about how it is used for DNS-SD service types. Those conventions are described in this section.

The TXT record should not duplicate information that is stored elsewhere—for example, the host and port number for the service—since those are obtained from the SRV record.

Since DNS-SD uses standard DNS TXT records , these records must conform to format rules. In particular, the data consists of one or more strings , each of which consists of a single length byte followed by 0-255 bytes of text. An example of such a string is:

    | 0x08 | p | a | p | e | r | = | A | 4 |

In this diagram, the first byte of data is a binary byte with value 8. It is then followed by eight more bytes of data, each containing the ASCII (or UTF-8) codes for the character indicated. For example, the second byte contains the value 0x70, the ASCII code for lowercase P; the third byte contains the value 0x61, the ASCII code for lowercase A. Note that there is no terminating zero at the end of the string, as there conventionally is with strings in the C programming language.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Summary

Content preview·Buy reprint rights for this chapter

DNS Service Discovery using Multicast DNS provides a simple, efficient, lightweight way to discover what services of a given type are available to you on the local network. Next, Chapter 5 shows how DNS Service Discovery using Unicast DNS takes the same elegant, simple concepts and scales literally to the entire planet, using the existing hierarchy of DNS servers that's already in place and well understood at just about all large companies, universities, and other similar organizations around the world.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 5: Service Discovery Beyond the Local Link

Content preview·Buy reprint rights for this chapter

Zeroconf is designed to make it easy for you to discover services that are close to you. The word close can be ambiguous. You go to your neighborhood coffee shop and the people drinking their cappuccinos at the next table are physically close to you. You may be able to use a Zeroconf-enabled chat client, text editor, or audio application to interact with them, to collaborate on a document, or to listen to their music library. In the preceding three chapters, you have been introduced to the components of Zeroconf that are designed to allow you to painlessly discover and offer services to devices that are close to yours—where close implies proximity in a network sense. Devices on the same link can use IP to communicate with one another and can present a list of available services in a user-friendly format.

As you drink your morning coffee, the person at the next table may be just a couple of feet away, but you may have never met them. They are not what you would describe as close in the sense of someone who is personally close, they just happen to be near you. There are many people who you might describe as being personally close: friends, family members, coworkers, and people you interact with on a regular basis.

If you are a Mac OS X user who uses iChat as your chat client, the differences in these two notions of close are reflected in the two windows you can use to find people to chat with. The Bonjour window shows you names of people on your local link who are available to chat. You may never have met these people and may not know their email addresses or chat usernames. If they have authorized the Bonjour connection, they just automatically appear in your Bonjour window. All that is required is that they have advertised a service of type _presence._tcp. Contrast this with your Buddy window. This only includes people who you have designated as buddies. These people may not be nearby, but they are people you are most interested in interacting with on a regular basis.

Chapter 4 described how DNS Service Discovery (DNS-SD) allows you to discover and to advertise services using PTR, SRV, and TXT records. In Chapter 4, we conveniently avoided the question of whether we were talking about Unicast or Multicast DNS. This was intentional, because it really doesn't matter. DNS-SD was created to work with both Unicast and Multicast DNS. Multicast DNS is perfect for small networks because of its zero-configuration nature. Instead of trying to predict where each query and announcement needs to go, it just sends them all to every peer on the network and lets the peers sort what they need. Clearly, this can't work on a global scale. If every machine on the Internet were busy sending packets that were replicated and delivered to every other machine on the Internet, every machine would be buried under an avalanche of unwanted traffic. Clearly, at a certain stage, we have to move out of the zero-configuration world and into the world of configuration and infrastructure. By building DNS-SD on top of Multicast DNS on the local network, that gives us a natural candidate for what configuration and infrastructure we should use when operating on larger networks: Unicast DNS. In most respects, the DNS-SD part of the protocol works just the same, regardless of whether it's running over Multicast DNS or Unicast DNS. The difference is that Multicast DNS is configuration-free and infrastructure-free, whereas Unicast DNS is more efficient on large networks but requires some configuration and infrastructure.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Domain Enumeration

Content preview·Buy reprint rights for this chapter

When you browse on the local network, it's clear that the domain you want is local. When you browse on the Internet, you can ask DNS-SD to browse in any valid DNS domain, like apple.com or oreilly.com . Whether you get any results will depend on whether the domain is advertising any services. Clearly, one way to decide which domain(s) to browse is to have the user type them in. However, the spirit of Zeroconf is zero configuration, so we don't want to make the user start manually configuring things now. The computer should automatically learn from its environment about interesting domains to browse. The way DNS-SD does this is with Domain Enumeration queries. DNS-SD performs five Domain Enumeration queries:

• Where are interesting domains to browse for services?
  The Domain Enumeration query string for this is b._dns-sd._udp.
• Of that list, what is the recommended default domain to browse?
  The Domain Enumeration query string for this is db._dns-sd._udp.
• Where are recommended places I might want to register to advertise my services?
  The Domain Enumeration query string for this is r._dns-sd._udp. (Advertising services may require authorization and credentials, so just because a given domain is recommended to people on this network doesn't necessarily mean that you have permission to advertise services there.)
• Of that list, what is the recommended default domain to register services?
  The Domain Enumeration query string for this is dr._dns-sd._udp.
• For legacy client applications that don't specify any particular domain when browsing for services, are there any additional domains that we should browse in addition to the usual

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Advertising Static Services

Content preview·Buy reprint rights for this chapter

If you run your own DNS server, or are friendly with the network administrator who does, then you can create magical results just by adding a few lines to your DNS zone file to create the right records to support the domain-based or address-based Domain Enumeration queries. You just need to add a couple of lines to answer those queries and then add three records for each static service you want to advertise. At Apple, various interesting web pages are statically advertised, so that they magically show up in Safari's Bonjour Bookmarks list. For example, the web page of information for new employees is advertised. You can imagine a scenario that used to happen quite frequently: on a new employee's third day, she would want to find out some information that's available on the New Employees page, but she couldn't remember the URL. She'd ask coworkers around her, but they'd all been at Apple for years and hadn't looked at the New Employees page for a long time, so they couldn't remember the URL either. Thus, a hunt for the New Employees page would begin. That scenario doesn't happen anymore. Now, the page appears in Safari's Bonjour Bookmarks list and any employee, new or old, can find it easily, even if she doesn't remember the URL.

Any organization can easily advertise services this way. A hotel offering network access in its rooms can just add a few lines to their DNS server and have the hotel's web page magically show up in clients' web browser's list of discovered pages. An airport offering 802.11 wireless service can have airport information pages and flight departure times magically appear in passengers' web browsers. A school or university can advertise pages of information relevant to students and visitors. An ISP can advertise pages of information relevant to its customers. A café or coffee shop can advertise pages with menus and price lists.

Example 5-1 shows a very simple example of the lines to add to a DNS zone file to answer Domain Enumeration queries and advertise a single web page in that domain.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Wide-Area Preference Settings

Content preview·Buy reprint rights for this chapter

As provided by Apple in Mac OS X 10.4 Tiger and in Bonjour for Windows 1.0, Wide-Area service discovery is a behind-the-scenes technology. The APIs are there for developers to use, but until developers start using those APIs or DNS administrators start advertising the automatic legacy browse domains described above, end users will see no difference. However, if you look in Apple's Darwin open source repository, you'll find source code for user-interface control panels for Mac OS X and for Windows, to allow developers (and adventurous end users) to experiment with the technology. Also, at time of writing, precompiled binaries of those control panels are available with instructions at http://www.dns-sd.org/ClientSetup.html. These control panels allow you to set system-wide defaults that will cause standard, unmodified Zeroconf applications to browse for and/or register network services in wide-area domains, rather than only on the local link.

Figure 5-1 shows the Bonjour Preference Pane as it appears when installed on Mac OS X.

Figure 5-1: Bonjour Preference Pane for Mac OS X

Figure 5-2 shows the Bonjour Control Panel as it appears when installed on Microsoft Windows.

On both Windows and Macintosh, the Bonjour Control Panel has three tabs: Hostname, Registration, and Browsing.

Figure 5-2: Bonjour Control Panel for Windows

If you have a Dynamic DNS hostname assigned to you by your DNS server admin, who ensures that everyone's hostname is unique, (or if you run your own DNS server with Dynamic Update), you can enter it here and click Apply. The hostname must be fully qualified, so don't enter a hostname like steve, enter a hostname like steve.bonjour.example.com

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Dynamic DNS Updates

Content preview·Buy reprint rights for this chapter