Need for zeroconf

• A new device added to a network needs to be configured to know about the network, with the following information
  • its IP address so that it can include its address in packets sent to other systems
  • its own name
  • the gateway address so that it can communicate with systems outside of its LAN
  • the netmask so that it can work out which addresses are local and which are external
  • the address of nameservers for "name to address" translation
  • other information such as local printers, etc
• When a new device is added to the network, the network needs to be informed about
  • the name and IP address of the device
• These require network admin skills
• Untrained users (e.g. home users) do not want these skills, they just want devices to configure themselves

DHCP

• The Dynamic Host Control Protocol is an attempt to solve some of these issues
• A DHCP client will attempt to contact a DHCP server
• The attempt consists of a UDP multicast, and listen to any replies that are broadcast back (the client has no IP address at this stage, so the server can't reply directly to it)
• If successful, the DHCP server will assign an IP address, and inform the client about any network parameters that it needs
• The drawback of DHCP is that it requires a network administrator to configure the DHCP server - a once-off task, but still requiring skills

Requirements of zeroconf

From the IETF "Requirements for Automatic Configuration of IP Hosts", a zeroconf protocol

• MUST configure an appropriate netmask.
• MUST allocate unique IP addresses within an IP subnet.
• MUST allow configuration of zero or more gateways (for the internetwork scenario).
• MUST be capable of discovering whether an IP address is currently in use.
• A zeroconf name resolution protocol MUST allow host names to be mapped into IP addresses.
• A zeroconf name resolution protocol SHOULD allow IP addresses to be mapped back to names.
• A zeroconf name resolution protocol MUST support mechanisms to probe whether a host name is currently in use.
• A host moving to a new network or powering up MUST ensure that all names it will respond to do not conflict with names already in use.
• Conflict detection procedures (such as probing for the existence of a desired host name) MUST NOT prevent valid hostnames from being resolved.

Link-local addresses

• When a device tries to join a network, it should use any pre-configured values e.g. its own hostname
• If it still needs values, it should try to contact a DHCP server
• If there is no DHCP server, the device can assign itself a link-local address in the range 169.254.1.0 to 169.254.254.255
• The address should be chosen at random, but should not already be in use on that LAN (e.g. it should make an ARP probe)
• Routers should not forward packets from or to any link-local addresses, so that these devices can only talk to other systems on the same LAN
• Devices with link-local addresses that need to talk outside the LAN must do so through a special-purpose gateway that will do e.g. NAT (network address translation)
• Link-local addresses were introduced into IPv6, and retrofitted to IPv4
• Link-local addressing can be done under Mac O/S, Windows and Linux

Dynamic DNS

• A DNS (domain name service) server maps between IP addresses and names (e.g. 130.194.11.4 <-> www.monash.edu.au)
• Early DNS servers used a fixed table. If the table changed, then the server would need to re-read the table, often by being stopped and restarted
• Dynamic DNS servers can have their internal table changed without stopping and starting
• "Link-local multicast DNS" can be used to resolve names when there is no DNS server available

Service Location Protocol

• The location of services is often stored in lookup directories such as LDAP directories, UDDI directories, etc - these require administration
• The IETF SLP protocol uses multicast to locate services such as printers, DNS servers, etc on a LAN
• OpenSLP is an open source implementation with API calls

  
        SLPReg()
        Registers a service URL and service attributes with SLP.
        
        SLPDeReg()
        Deregisters a previously registered service.
        
        SLPFindSrvs()
        Finds services based on service type or attributes.
        
        SLPFindAddrs()
        Obtains a list of attributes for services registered with SLP.
        
        SLPFindSrvTypes()
        Obtains a list of the types of services that have been registered with SLP.