Rendezvous: Revolutionary Networking Technology Author: Erik Regis Research Project 4C03 April 6, 2004
Introduction. Wireless technology has created a unique situation that has been the catalyst to innovation in networking. Never before has it been so easy for computers to be connected together. The number of wireless hot spots increases everyday and this has prompted a large increase in computers with wireless cards. With all of these computers connected together through their wireless cards as well as wired networks, it is a shame they have not been able to communicate without the aid of additional hardware. Rendezvous technology has been created by Apple to enable computers to setup and control local networks without the normal equipment that is required to accomplish this. The benefit of this technology is that this resolution is done with the existing hardware and thus a network can be made even when this outside resolution is not present. Rendezvous technology allows for the creation of instant networks that create the opportunity to discover other hosts, devices and services on that local network. This incredible breakthrough is also known as Zero Configuration networking. This technology has been introduced to the IETF to be a part of the standard and is available for all to examine and use. The purpose of this document is to inform the reader of this technology and to examine the three services that must be available for a device to be a part of this revolution. The three requirements are: The ability to allocate an IP address without DHCP server The ability to translate between names and IP addresses without the aid of a DHCP server The ability to both locate and provide services without the aid of a directory server These are the services that are essential to the ability of a computer to be a part of a network and enjoy the benefits that networking brings. Allocation of IP Addresses.. The purpose for having an IP address is evident. An IP address is necessary for a computer to be able to communicate to other computers on a network. The need to be uniquely identified is paramount in any situation where communication must occur. As such there is an algorithm designed by Rendezvous for any computer that wishes to create an IP address to identify itself on the local network. This algorithm is guaranteed to create an address that is guaranteed to be unique and valid for use according to the IANA. Communication is achieved by configuring the link-local IPv4 address. The method to get this address is to use a random number generator that produces a number in the range from 169.254.1.0 to 169.254.254.255 1. These addresses are reserved with the IANA for just such a purpose. The first 236 hosts and the last 256 hosts are reserved and must be excluded. As a rule, the host should not have the same sequence of numbers as another host. This requires the random number generator to be seeded in an individual way. Using something like the MAC address of the computer to seed this random number generator would work very well. A way to improve the efficiency of this algorithm is to have the number that the host uses be the same one chosen each time the host comes back to the network. This way any time computer restarts it is likely that it will use the same 1 Cheshire, Steward & Krochmal Marc, Dynamic Configuration of Link-Local Ipv4 Addresses. Section 2.1, Page 8.
number. This can be very effective since when the computer comes back online again the number it chooses has already been proven to be free of conflict. When a number is chosen it is necessary that a test be done to check to see if the number is safe to use. If it is in use by another computer this would be very disruptive to the network so it is important that the number is proven to be unique. This process referred to as claiming the address is done by sending an ARP for the desired address by broadcast. This ARP packet has the hardware address as the interface that it is sending that packet through and has the sender IP address must be all zeros so no other host tries to add this information. The target IP address is the address that is being tested and the hardware address is not important. When the ARP is not replied to, the computer testing this addresses can be assured that the address is safe to use. For full details on this topic please visit http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt Multicast Translation between names and IP addresses.. Once the IP address has been set up for the host on the link-local network then the host can move on to the next step in being able to communicating on the network, address resolution. The host must be able to resolve host names without the aid of the services provided by the DHCP server. In place of that service is the multicast DNS (mdns). This new technology works much like the DHCP server but has a couple of key features. There is little to no administration when setting up this service. Also, it will work when the normal infrastructure is not present and further than that it will work when the infrastructure fails 2. The innovation of this method of providing this service is that it is not changing the structure of a DNS message. That structure remains constant and the technology for that is present on every host automatically. What changes is how a DNS message is to be dealt with when they are being sent to a multicast address and how the other hosts are to react to this situation. One would think that broadcasting DNS messages would create a horrendous amount of traffic but it has been seen that the amount of traffic is around the same amount as what a host already creates with the ARP messages that it sends. For most of the computers in a network the user does not have the ability to create an individual name in the global DNS namespace. A user that belongs to an organization can create a name and it looks like this regisem.mcmaster.ca. For the rest of the world and specifically those interested in the link-local network there is the ability to give their computers link-local Multicast DNS host names of the form: "single-dns-label.local." 3 An example of this could be regisem.local. There are a lot of benefits to the multicast method of address resolution. The end result of using multicast is an overall lowering of traffic for a variety of reasons. When a multicast message is sent the answer is seen by all of the computers on the network so those computers that were going to issue the same query have their answer and need not send a redundant request. Multicast responses allow for something called passive conflict detection. Without going into the details, it is enough to know that conflict detection is necessary and vital to the traffic on a network. In the absence of the passive conflict detection there would have to be some other way to deal with collisions, this would 2 Cheshire, Steward & Krochmal Marc, Multicast DNS. Abstract, Page 0 3 Cheshire, Steward & Krochmal Marc, Multicast DNS. Section3, Page 4
invariably increase network traffic. Since a multicast serves to accomplish the task of updating information on each computer without an increase in traffic, it is a natural choice as a solution to this requirement for a local network. For full details on this topic please visit http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt. Service Directory.. The last step in being able to function as a real network in scheme is to be able to see and provide services to the local network of which the host is a member. The local network is required to provide the ability to file share, print, chat etc. between any of the computers on the network. The major framework for this has already been laid and again, this is more a modification to what the hosts already use for finding services on a network that is created by more conventional means (DNS servers, etc). There are a few abilities required of a host to participate in a service directory. The host must be able to read and package its services into a resource record. The host must have an algorithm that allows the host to use these records to become aware of the services it is interested in that are located in a certain domain. Additionally, the host is to use the standard DNS query to find each of the services, thus making the procedure very close to what is already standard for the host when using a DNS-based Service Discovery (DNS-SD). The main principles that allow the functionality of the directory are the ability to query for a list of services of a certain type located on a certain domain and the ability to resolve a service into the pertinent information which includes IP address (this resolution procedure is described above) and port number. In addition this, the names of the services should remain fairly constant from session to session, this allows the user to be able to more quickly recognize and use services that they desire to use and have used before. This does not mean that the information behind that service has not changed. That is the benefit of this scheme; it is possible to have the name and low-level information independent of each other so regardless of the IP address assigned, the user will still see the service they are looking for in a way that they recognize. The service directory that is a part if the rendezvous technology uses records that are very close in structure to that of a DNS records. The modification boils down to a layer that is on top of the DNS records that makes the records requested of type PTR instead of type SRV as in the regular DNS server. This pointer is a pointer from one name to another in the DNS namespace 4. This change gives the requester a pointer that contains a list of what files are in the directory that is given by the name of the SRV record. The result of a request that is looking for a specific service on a specific domain (as listed as a necessary ability for a service directory) is a list of PTR records that give the service instance name for each instance they are of the form: Service Instance Name = <Instance>. <Service>. <Domain> 5 Where the request was of the form <Service>. <Domain>. The <Instance> portion of this name is the DNS label, the user then chooses the instance they desire from this list. The <Service> is the application protocol name which are listed by the IANA followed by the transportation layer used (_tcp or _udp). The <Domain> portion of the name is the 4 Cheshire, Steward & Krochmal Marc, DNS-Based Service Directory. Section 4.1, Page 4. 5 Cheshire, Steward & Krochmal Marc, DNS-Based Service Directory. Section 4.1, Page 5.
real DNS name i.e. google.ca or apple.com. With this method of creating a service directory no additional server is needed and this fulfills the last step in creating a local network. For full details on this topic please visit http://files.dns-sd.org/draft-cheshirednsext-dns-sd.txt. Conclusion.. The introduction of wireless technology has made connections between computers effortless. Simply walking into a room that has another wirelessly enabled computer presents the opportunity for a network to be created. However, this technology is not restricted to wireless networks. Any connection between computers can run Rendezvous technology to create link-local networks. This document was designed to outline the important services that any computer must provide to be a part a network and how Rendezvous technology has created an answer to each of these services. With this technology in place every computer is able to join and create a network allowing for limitless possibilities for sharing between computers. Look for this technology to become standard on computers in the future. Communication is at the heart of innovation in the digital world. Communication with Rendezvous technology just got a lot easier.
Research Papers Cited.. http://developer.apple.com/macosx/rendezvous/ Cheshire, Steward & Krochmal Marc, Dynamic Configuration of Link-Local Ipv4 Addresses. February 14, 2004 http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt Cheshire, Steward & Krochmal Marc, Multicast DNS. February 14, 2004 http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt Cheshire, Steward & Krochmal Marc, DNS-Based Service Directory. February 14, 2004 http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt