Having obtained a suitable network layer (IP layer) address, the transport layer (TCP or UDP, and now SCTP) normally does not need additional configuration. This leaves configuration at the application layer. This section and the next deal with key issues at the application layer.
While using IP addresses is obviously possible, most users have at least some need for use of abstract names. This is normally managed by the Domain Name System (DNS). However setting up DNS can never be considered zeroconf, since it requires both substantial server side work, and configuring of the resolver setup.
The zeroconf equivalent uses a little version of a DNS resolver that responds to DNS type queries received on a known multicast address (224.0.0.251), which provides a standardised way to resolve names to addresses, and addresses back to names.
There are two different proposals for how name to address translation might work:
Link Local Mulicast Name Resolution (LLMNR), pushed by people from Microsoft[1].
Multicast DNS (mDNS), pushed by people from Apple[2].
The general focus of both drafts is to use normal DNS Resource Records, transmitted over multicast to a known port (5353), with a multicast DNS responder running on each host on the network. Because there is no central authority for names, it is possible that there can be naming collisions, where two or more hosts have the same name. Both drafts attempt to avoid this occurring (with a similar claim and defend process to that used for IP addresses), but allow for duplicate responses, and make dealing with this an application layer responsibility.
| [1] | At the time of writing, the current draft was available at http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-13.txt |
| [2] | At the time of writing, the current draft was available at http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-multicastdns-01.txt |
| <<< Previous | Home | Next >>> |
| Technology - Part 1 - Address Assignment | Technology - Part 3 - Service Location or Discovery |