Zero Configuration / IETF

Zero Configuration is an Internet Engineering Task Force Protocol that enables the automatic configuration of network services,

through the use of multicast on local area networks.  It has been implemented by Apple Computers as Rendevous.

Projects that achieve a similar functionality by different means include;

the Distributed Home Working Group, SUN Microsystem's JINI protocols, the IETF Mobile Ad Hoc Network Protocols, and Piconet of the 802.16.3 specification.
 

From the ZeroConf web site.

To achieve small-network functionality in IP, there are four main areas of work:

Overview

 Autoconfiguration for IP Networking: Enabling Local Communication  (.pdf) is a Zeroconf tutorial article by Erik Guttman,

which appeared in the June 2001 issue of IEEE Internet Computing.

Documents

Zeroconf Host Profile outlines which protocols are available that could meet the requirements specified in the requirements document.

In effect this draft is the embyonic form of a possible future RFC which could become an update to RFC 1122  (Host Requirements).
 

       IPv4 Address Conflict Detection  describes how a host can detect when some other host on the same link is trying to use the
same IP address (a Bad Thing). This is the same mechanism used for Link-Local Addresses, but it is equally useful and applicable no matter how an address was configured, whether via manual entry by a human user, via information received from a DHCP server, or via any other source of configuration information.
 
 

       Dynamic Configuration of IPv4 Link-Local Addresses defines how IP hosts can assign addresses in the absence
of outside configuration information.  Hardware manufacturers should implement self-assigned link-local addressing on their devices to obtain the full benefit of Rendevous. That means assigning addresses without depending on information entered by a human user, and without depending on information obtained over the network from a special server, such as a DHCP server.
 
 

       Zeroconf Multicast Address Allocation Protocol (ZMAAP) defines how IP hosts can allocate multicast addresses in the
absence of outside configuration information.
 

       An APIfor the Zeroconf Multicast Address Allocation Protocol (ZMAAP) is an informational draft extending RFC 2771 ("An Abstract API for Multicast Address Allocation") to the Zeroconf environment.
 

Further Information

       Multicast DNS is a proposed way of enabling name-to-address translation and other DNS-like operations in the absence of a conventional DNS server.

       DNS Service Discovery is a proposed way of extending Multicast DNS to also provide simple service discovery (network browsing).
 

DNS Service Discovery API Apple documentation (.pdf)

DNS Service Discovery API: What is Rendezvous? - html second location

UNIX Porting Guide: Rendezvous - Size: 12k

Source Code

A cross platform SDK for embedding Zeroconf functionaliy in applications is available from PorchDog Software.

The source code for OSX's mDNSResponder , has been released under the Darwin Open Source Code license, which allows both commercial and non-commercial use.

mDNSResponder listens for and responds to DNS-format query packets sent via IP Multicast to UDP port 5353.  Additional source code, bootp-110, handles DHCP IP configuration and link-local addressing. This System allows the services and capabilities such as file sharing and printing of each device to be registered on the network, and allows these services to be dynamically discoverable by other devices on the network.

OpenPlay Net Modual Manager
- gaming system auto configuration

Apple's Rendezvous makes use of  DAAP (Digital Audio Access Protocol).

An open source DAAP hack is available through a Source Forge project: icommune
 
 

Apple Rendezvous and Zeroconf
From the ZeroConf web site.

Apple has announced that Zeroconf, under the product name Rendezvous, forms the foundation for completing Apple's transition from AppleTalk to all-IP networking. Apple's customers have high expectations for ease of use, and Zeroconf enables Apple to meet those expectations. Apple is providing Zeroconf services beginning in the Jaguar release of the Mac OS X Operating Sytem, and will be using those services aggressively in its own applications.
 

Frequently Asked Questions

Note: This FAQ is maintained privately by Stuart Cheshire. Over time many of the answers here migrate over to the official Apple Developer Support Rendezvous FAQ

How does Rendezvous / DNS-SD scale to networks bigger than a single link?

Multicast DNS is intended for use on small networks with no infrastructure support, and intentionally uses link-local multicast. If a network has two links then it needs a bridge or router to connect those links, so by definition you now have a box that is (or should be) capable of providing some level of infrastructure support.

It is important to understand that DNS Service Discovery (DNS-SD) is orthogonal to Multicast DNS (mDNS). You can use one without the other. In the example given above, the router that is connecting the two links should also include a DHCP server to assign addresses, and a little mini-DNS server which handles both standard DNS queries and Dynamic DNS Updates [RFC 3007]. The devices offering services on that network then advertise their services by using Dynamic Update to register their service records with the mini-DNS server in the router, and clients looking for services use normal unicast DNS queries addressed to that server to retrieve those service records.

The first release of DNS-SD for Mac OS X concentrates on Multicast DNS for single-link networks, because those are the networks worst served by current IP software. Future versions will add Dynamic Update and unicast query support.

What value should I pass for the name parameter in "DNSServiceRegistrationCreate()"?

If you are content to just register your service under the default service name entered by the user in the "Computer Name" field of the Sharing Control Panel, you can pass empty string and the default name will be filled in for you. If you want to register with a specific name, pass that string, as canonically precomposed UTF-8 text.

What value should I pass for the regtype parameter in "DNSServiceRegistrationCreate()"?

       You MUST pass a string of the form "_applicationprotocol._transportprotocol".

       Currently "_transportprotocol" MUST be either "_tcp" or "_udp"

You "_applicationprotocol" MUST be a protocol name registered with IANA and appearing in the list of registered IANA protocol names and port numbers. If your application protocol does not appear in this list, it is a simple matter to fill out the IANA "Application for User (Registered) Port Number" form. You will also be allocated a registered port number for your protocol, but of course you don't actually need a registered port number because you will be using DNS Service Discovery SRV records which specify the port number, so the client can find you no matter what port your server is running on today.

What value should I pass for the domain parameter in "DNSServiceRegistrationCreate()"?

       Right now Jaguar only supports local multicast service discovery. If you pass empty string (""), then Jaguar will automatically do the right thing. Today it will register using just link-local multicast. Future versions will automatically register in the default unicast DNS domain, if applicable. You only need to pass a specific string to DNSServiceRegistrationCreate() if you have some particular reason to want to register in some specific remote domain.

After the user browses the network in my application and selects the service instance they wish to use, I should save that IP address
in my application's preference file, right?

       Wrong. This is a common mistake. With DHCP (and with link-local addressing) it is not safe to assume that the service instance will have the same IP address tommorow. Addresses can change. Service names are the intended stable identifiers for a service instance. Save the instance name (name, type, and domain) in your application's preference file, then resolve it on demand each time the user accesses the service. Note also that you should not store the host name and port number, because you shouldn't assume that the service instance will necessarily be running on the same port number tomorrow. Instead of storing the host name, store the service instance name (name, type, and domain) and then when you resolve the service instance name at the time of use you are sure to get the up-to-date IP address and port number.

Security across networks and a Windows Security issue.

IP TTL.

It is sometimes possible for hackers to send packets to a remote network which purport to be from local devices on that network, even
though they are not. Properly designed routers will block such rogue packets, but not all routers do this. To guard against off-net attacks such as this, modern devices using link-local addresses set the IP TTL field of all outgoing packets to the maximum value, 255. When a device receives a packet purporting to be from a local peer, it can then check the TTL value. It it is still 255, then the packet must have come from a local device.
              If the TTL in a supposedly link-local packet has been decremented, then the packet has passed through one or more gateways and is therefore a probable attack from a remote hacker, and should be discarded. Unfortunately, Microsoft Windows still sends link-local packets with the TTL set to 128, making it impossible to distinguish between Microsoft Windows and an attack by a distant hacker. This Windows deficiency may be what led to the myth that, "UPnP addresses are not compatible with Rendezvous." The myth is false and there are two simple answers: (1) It is easy to change the default TTL used by windows, as described in the appendix to Dynamic Configuration of IPv4 Link-Local Addresses. If you are making a device that wants to benefit from the TTL check, then you can make your Windows installer software set the correct default TTL at the time the user installs the device software. (2) If your product does not come with an installer CD, and you don't want the user to have to change the default TTL manually, then you can simply make your device neglect to do the TTL check. Of course your device should still set the TTL correctly on outgoing packets, so that it will interoperate with other devices that do check the TTL.

How do I configure my PC so that it can communicate with devices using Rendezvous link-local addresses, when my PC is using a
global or routable (non-link-local) IP address?

(And the inverse) How do I configure my PC so that it can communicate with devices using routable addresses when my PC is using
a link-local address?

       The philosophy of Zero Configuration Networking is that no configuration should be required. However, some vendors are slower than others to embrace this philosophy. Fortunately, there are workarounds:

 IPv6 already supports link-local addresses on every interface.

Linux.
Apple Documentation Linux and Rendevous.

Linux (and similar Unix systems) can be configured to send link-local packets directly to local devices with two simple commands, as shown below. If your primary interface is not "eth0" then substitute the name of your primary interface instead.
              route add -net 169.254.0.0 netmask 255.255.0.0 dev eth0 metric 99
              route add default dev eth0 metric 99

Windows.
Apple Documentation Windows and Rendevous.

The following Windows command, typed at a DOS prompt, works just like the Linux example above. In place of "put_my_address_here" put the Windows machine's own IP address.

              route add 169.254.0.0 mask 255.255.0.0 put_my_address_here