Macs, as well as other devices supporting the protocol, could be added to the network by simply plugging them in; all further configuration was automated.
NBP included not only a name but the type of device and any additional user-provided information such as its physical location or availability.
Discovering the DHCP-assigned address of another host requires either distributed name resolution or a unicast DNS server with this information; Some networks feature DNS servers that are automatically updated with DHCP-assigned host and address information.
IPv6 hosts generally combine a prefix of up to 64 bits with a 64-bit EUI-64 derived from the factory-assigned 48-bit IEEE MAC address.
The IPv6 protocol stack also includes duplicate address detection to avoid conflicts with other hosts.
[4] Internet protocols use IP addresses for communications, but these are not easy for humans to use; IPv6 in particular uses very long strings of digits that are not easily entered manually.
This has reduced the user-side administration requirements and provides a key element of zero-configuration access.
Assigning an address to a local device, e.g., thirdfloorprinter.example.org, normally requires administrator access to the DNS server and is often accomplished manually.
Additionally, traditional DNS servers are not expected to automatically correct for changes in configuration.
For instance, if a printer is moved from one floor to another it might be assigned a new IP address by the local DHCP server.
The protocols NetBIOS can use are part of the Server Message Block (SMB) suite of open protocols[6] which are also available on Linux and iOS, although Windows typically supports a wider range of so-called dialects which can be negotiated between Windows clients that support it.
Use of either NetBIOS or LLMNR services on Windows is essentially automatic, since using standard DNS client APIs will result in the use of either NetBIOS or LLMNR depending on what name is being resolved (whether the name is a local name or not), the network configuration in effect (e.g. DNS suffixes in effect) and (in corporate networks) the policies in effect (whether LLMNR or NetBIOS are disabled), although developers may opt into bypassing these services for individual address lookups.
mDNS allows a network device to choose a domain name in the local DNS namespace and announce it using a special multicast IP address.
This introduces special semantics for the top-level domain local,[11] which is considered a problem by some members of the IETF.
[12] The current LLMNR draft allows a network device to choose any domain name, which is considered a security risk by some members of the IETF.
NetBIOS on Windows supports individual hosts on the network to advertise services, such as file shares and printers.
Depending on how a device is attached (to the network directly, or to the host which shares it) and which protocols are supported.
As the name suggests, the actual communication between nodes is done using web services standards, notably SOAP-over-UDP.
The specification is compatible with existing unicast DNS server and client software, but works equally well with mDNS in a zero-configuration environment.
The SRV record resolves to the domain name providing the instance, while the TXT can contain service-specific configuration parameters.
[19] In 1997 Stuart Cheshire proposed adapting Apple's mature Name Binding Protocol to IP networks to address the lack of service discovery capability.
[20] Cheshire subsequently joined Apple and authored IETF draft proposals for mDNS and DNS-based Service Discovery, supporting the transition from AppleTalk to IP networking.
For example, many OS X network applications written by Apple, including Safari, iChat, and Messages, can use DNS-SD to locate nearby servers and peer-to-peer clients.
SSDP uses HTTP notification announcements that give a service-type URI and a Unique Service Name (USN).
It is supported by certain brands of network equipment, and in many SOHO firewall appliances, where host computers behind it may pierce holes for applications.
[27] RFC 2608, the SLP standard for figuring out where to get services, was published in June 1999 by the SVRLOC IETF working group.
[28] RFC 3927, a standard for choosing addresses for networked items, was published in March 2005 by the IETF Zeroconf working group.
[29] LLMNR was submitted for official adoption in the IETF DNSEXT working group, however, failed to gain consensus and thus was published as informational RFC 4795 in January 2007.
Because mDNS operates under a different trust model than unicast DNS—trusting the entire network rather than a designated DNS server, it is vulnerable to spoofing attacks by any system within the same broadcast domain.
Using a link-local address, hosts can communicate over this link but only locally; Access to other networks and the Internet is not possible.