9. Which Network Service Is Also Known As Zero Configuration Networking?

COLLECTED By

The IT History Guild (ITHS) is a world-wide group of over 500 members working together to assist in and promote the documentation, preservation, cataloging, and researching of Information Technology (IT) history. We offering a place where individuals, academicians, corporate archivists, curators of public institutions, and hobbyists alike tin assemble and share information and resources. This catalog of resource sites concerning IT history is the merely one of its kind and is a valuable resource for Information technology historians and archivists akin.

TIMESTAMPS

The Wayback Car - https://web.archive.org/spider web/20160103040954/http://www.isoc.org/inet2000/cdproceedings/3c/3c_3.htm

Null Configuration Networking

Abstruse

TCP/IP networking has been deployed in many environments and has been specially successful in big networks such every bit those in universities, corporations, and regime agencies. Operating an IP network requires specialized technical skills. For this reason, IP networking has non been peculiarly well suited for smaller networks (such as in the home, in pocket-size businesses, for impromptu networks in conference rooms or construction sites), where capable network assistants is non feasible. Currently developments in the computer manufacture equally well as in the Internet Applied science Task Strength (IETF) hold out the promise that it will soon be possible to deploy and apply IP-based hosts in environments completely defective in assistants and infrastructure. This article explains why static IP network configuration is hard, describes the electric current dynamic configuration mechanisms used to overcome those difficulties, and explores a rapidly emerging new set of automatic configuration capabilities.

Introduction
Essential network services and configuration
Managing IP host configuration
- Destination address discovery
Motivation for nil configuration networking
Architectural issues of nil configuration networking
- Ease of use
- Scalability
- Automatic Transition to and From Configured Networking
- Secure Operation
- Transparency
- Independence
Status of ongoing work
- Automatic host configuration
- Service discovery
- Multicast domain proper name to accost resolution
- Automatic multicast accost allocation
- Transition to secure operation
7. Implications for the future
eight. References
Author information

Introduction

The evolution of the IP standards suite[one] has concentrated on achieving a reliable and scalable networking architecture. Emphasis has always been placed on mechanisms that let decentralized administration. Individual networks have been operated with local configuration, while Internetwide configuration has been coordinated through dissimilar agencies handling registration of domain names, network numbers, and other parameters.

Network operation requires consistent configuration of all hosts and servers and ordinarily requires centralized, knowledgeable network assistants and increasingly complex configuration direction services.

It is important to note that at that place are other networking protocol suites with different priorities and deployment characteristics. In particular the AppleTalk Protocol Suite[2] is simple to operate in small-scale networks, though information technology requires system administration in larger deployments. Automated configuration and ease of deployment were of primary importance to AppleTalk'south designers. As a outcome, AppleTalk networks tin can exist and are used in homes, schoolrooms, minor offices, and conference rooms. In short, AppleTalk is successful in environments where IP networks have been absent, since IP networks have been besides complicated and costly to administer. Ane advantage AppleTalk has over IP is that it functions even in networks where no services have been deployed.

As computers get cheaper and more than pervasive, the obvious thing to exercise is network them together. Many companies are investigating adding features to their products to let communication between consumer electronics, home appliances, personal computers, telecommunications devices, and more. Until the IP suite becomes every bit easy to operate as the AppleTalk Protocol Suite, the notion of a networked home or office using IP is impractical. In that location are many new networking protocols that offering easy deployment (for devices using that engineering) in very unproblematic network topologies.[3] This diverseness complicates the integration of communicating entities into a single network -- precisely what the IP suite is supposed to reach.

Several computer software companies take taken the initiative to enhance the IP suite to accost this challenge. The IETF has begun work on zero configuration networking for IP. The goal is to allow hosts to communicate using IP without requiring any prior configuration or the presence of network services. True to the traditional architectural principals of the IP suite, intendance is being taken to ensure that goose egg configuration networking protocols and operation exercise non detract from the scalability of larger configured networks with fully administered services.

This newspaper discusses the services and configuration essential for IP networking and surveys the IP suite standards for providing configuration to IP-enabled devices. The central topic of this paper is the emergence of protocols for performance without services or configuration. Piece of work in the surface area of zip configuration protocols has been motivated past new demands in the market place. Some architectural principles are generally agreed upon and undergird the development of standards in this expanse. Finally, the paper summarizes the status of this piece of work and concludes by discussing implications for the future.

Essential network services and configuration

An IP network is equanimous of devices that have interfaces that let them to access one or more networks. A IP host is a device that is capable of sending and receiving IP datagrams using these interfaces. An IP host that frontward packets it receives from 1 interface onto another of its interfaces is called a router.

Figure 1

In Figure 1, host A can communicate with B directly merely requires the router to communicate with host C, since host C is on a dissimilar network.

This paper concerns host configuration and performance exclusively. Zero configuration mechanisms could be deployed on networks with routers, but how the routers themselves are configured is beyond the scope of this document.

The essential configuration required past an IP host is the following:

IP address: Each interface of an IP host is assigned an IP accost.
Subnet mask: A subnet mask is the gear up of bits (in practice, high-guild bits) in the IP address that identify the network portion of the accost. For case, if the subnet mask is 255.255.0.0 this means that the high-order bytes of the accost are the network number and the lower-order 2 bytes are the host portion of the accost.
Default router address: If a host sends an IP datagram to a destination accost that is not on the same network number as the interface, it must transport the datagram to a router to be forwarded.
Domain name: A hierarchical name. When this name corresponds to configuration of the domain name service (DNS),[four] the name tin exist used past DNS clients to retrieve information from a DNS server.
Domain proper noun server: A server that obtains information on behalf of clients. The DNS server accesses the global distributed proper noun service to think data for remote domains.

In summary, there are 2 essential networking services: routers and DNS servers. Without routers, simply IP hosts that take interfaces on the same network are reachable. Without DNS servers, hosts take to be configured with the IP addresses of hosts they will communicate with. IP addresses are very poor persistent identifiers to use for configuring hosts. Hosts may exist moved (given new addresses) or replaced by other hosts with the same addresses. Using domain names allows a host to obtain destination addresses on demand based on a permanent name. This allows resilient and consequent performance.

The parameters listed above are essential; without them hosts would non be able to communicate. These parameters may be assigned in iii ways:

Static configuration requires IP host parameters to be manually entered into each host. This is possible only in pocket-sized deployments, as soon as the complexity of managing transmission deployment becomes excessive. Farther, this technique quickly degenerates into anarchy every bit information technology is very difficult to proceed everything consistent (i.due east., to ensure that IP address assignments are unique). Furthermore, static configuration requires technical competence and noesis of networking parameters.
Dynamic configuration allows IP host parameters to exist assigned to hosts on demand, using network protocols. This makes it possible to make consequent assignments to a very big number of hosts. Information technology makes networking much easier since the hosts practice not need to be manually configured. Dynamic configuration requires a dedicated dynamic configuration server to exist deployed in the network.
Automatic configuration assigns IP host parameters by default and through agreement with other IP hosts. Automated configuration is platonic for settings that completely lack network assistants. In such settings no dynamic configuration is available. In dissimilarity to dynamic configuration, which requires some centralized administration, automatic configuration is decentralized -- hosts create their own configuration independently. Automated configuration protocols do non "scale up" to the aforementioned degree as dynamic configuration protocols, but they are quite useful in smaller networks.

Managing IP host configuration

The principal machinery used to provide IP host configuration on IP-based networks today is the dynamic host configuration protocol (DHCP).[v] This protocol is specifically designed to allow hosts to discover a DHCP server or relay and obtain the essential network configuration described in the previous department. DHCP can also be used to deliver other configuration parameters.

IP Version 6 (IPv6)[6] provides automatic network configuration mechanisms. Hosts are able to obtain a link local address (useful only on a single network) using address autoconfiguration[7] and a routable address past discovering routers, using Neighbor Discovery.[8] While there is piece of work under manner to provide DHCP for IPv6, ane of the distinct advantages of IPv6 is that hosts do not demand equally much configuration to operate. That being said, the problems discussed in the remainder of this paper exist equally for both IP Version 4 and IP Version 6.

Figure 2

Figure 2 illustrates the unlike kinds of configuration discussed in this paper. This figure shows hosts configured with IPv4 addresses and domain names. Other configuration is not shown (subnet mask, default router, DNS server). Host A obtains its configuration from a file. Host B gets its configuration using IPv4 auto configuration. Host C gets its configuration from the DHCP server. Both IPv4 automatic configuration and DHCP are discussed further below.

Assuming that A and C share the same subnet mask, they share the same network number, also. They volition communicate with each other directly; without attempting to forward traffic by means of their default router.

B has a different accost -- from the link-local address range. Since it is in this range, a router volition not forward traffic from B to other networks. Since B has a different network number, A and C would assume they would have to forward messages to it through a router, non knowing that B is on the aforementioned physical network. In the future, when support for IPv4 link local addresses is more pervasive, hosts with not-link-local addresses may recognize link-local destinations and attempt to ship letters directly to hosts that accept them.

Note that in Figure 2, B but gets an address. IPv4 auto configuration provides only address and subnet mask configuration, not domain name, default router, or DNS server configuration.

Destination address discovery

Another important aspect of network configuration is obtaining the address (or location) of other hosts on the network. Customer applications on IP hosts require this information to communicate with servers.

In order for an IP host Due south to communicate with another host D, Due south needs to obtain D'due south address. This accost may exist obtained in the following means, each of which requires Southward to have some initial configuration:

IP address configuration: S may have D's IP address.
Domain name configuration: Due south may have D'due south domain name and utilize the DNS to expect up D's IP address.
Service discovery: Due south may have an identifier for the kind of service information technology requires and use a service discovery protocol to discover D's domain name or IP address.

DHCP may provide the address of certain services on the network.

Additionally, the DNS SRV[9] resource record allows IP hosts that back up this feature to asking the domain name of a service in a specific domain. In each case, the IP host needs to be configured with only the type of service required.

The service location protocol (SLP)[10] too allows the location of servers to be discovered. Different DHCP and DNS SRV resource record mechanisms, SLP allows services to be discovered by query, that is, SLP obtains the location of services that encounter the customer'due south requirements. For case, a client may be able to use merely a server with a sure software version, a server on which the client's user has an account, or a server in a particular concrete location.

The lightweight directory access protocol (LDAP)[11] could be used to store various network configurations. IP hosts, upon discovery of an LDAP server, could request and obtain all further parameters from the directory. An instance of how such a directory could be organized is documented in an experimental RFC.[12]

Annotation that neither DNS SRV RRs, SLP, nor LDAP tin substitute for the host configuration mechanisms described in the previous department. An IP host requires host configuration in order to be able to communicate at all, let alone utilise DNS, SLP, or LDAP.

Motivation for zero configuration networking

The IETF has already produced standards to provide automatic host configuration (for IPv6) and for service discovery (SLP, DNS SRV resources records, and DHCP service configuration options).

Automatic host configuration features are defective in IPv4. These features are and then useful, vendors are starting to add them. (Notably, Microsoft and Apple tree have included automated host configuration for IPv4 in their latest operating organization releases.) The stateless address autoconfiguration mechanism[xiii] for IPv4 is unlike from that for IPv6 since IPv4's address infinite is much more constrained (four bytes instead of 16). Thus, the potential of contention for the aforementioned address is much larger and the address that is arrived at cannot be used in any simple fashion to derive a globally routable accost, as it tin can in IPv6.

Operating organization vendors with proprietary networking protocols (similar Apple and Microsoft) are planning to stage out their proprietary network protocols. To do this, the IP suite must support the facilities that one finds in AppleTalk or NetBIOS.[14] This involvement has added impetus to provide solutions inside the IETF.

The facilities that are lacking are automatic host configuration and service discovery (both of which accept already been discussed) and, additionally, name resolution without proper noun servers and zero configuration multicast accost allocation.[15] The latter ii features volition exist discussed in the section on ongoing work.

Architectural bug of zero configuration networking

Nada configuration networking must operate nether sure constraints. From these we tin ameliorate sympathise the overarching goals besides every bit the hurdles that must exist overcome to standardize this technology.

Ease of apply

The primary motivation for zero configuration is ease of employ. Ideally this ways that adding IP hosts to the network will be as easy as plugging into a power socket. This creates the possibility of networking together devices for which no manual configuration is possible, ever, such as embedded controllers. Information technology likewise facilitates commodification of IP-enabled devices.

Scalability

In that location are two aspects to scalability.

The first is scaling up. Zero configuration networking protocols need to operate in a variety of networks. They may be used in isolation, where the network consists of only ii IP connected hosts. Or they may exist on a network with tens of thousands of systems (such as a loftier-tech vehicle with networked transducers all over the identify). Zero configuration protocols cannot forestall deployment of networks with many hosts. That is not to say that these networks take to calibration to be the size of the Internet. At a certain betoken it will make sense to add configuration and rent administrators to manage and plan network operations. Zero configuration protocols must present a scalability problem in configured networks (run into beneath).

The other extreme is scaling down. Aught configuration protocols have to be extremely unproblematic and require little calculating and memory resources to run. That is because they volition likely be implemented in constrained devices.

Automated Transition to and From Configured Networking

Information technology is expected that hosts may sometimes be on zero configuration and other times exist on configured networks. It is therefore vital that cipher configuration protocols have a simple automatic mechanism to observe the transition between the two states. Further, the transition has to be smooth. For example, service discovery and name resolution services have to obtain the same results whether zero configuration or configured protocols are available.

It may exist the case that zero configuration protocols are e'er available for communicating with local hosts, using local names and addresses, equally long equally this doesn't interfere with communication and operation of fully configured networks.

It is vital that system administrators be able to turn off zilch configuration behavior in sure circumstances.

Information technology is also advantageous if zero configuration protocols can become available in the instance when network services neglect. This increases the robustness of the network.

Secure Operation

The utilize of zero configuration protocols cannot brand the IP protocol suite less secure than it would be otherwise. Since automatic host configuration allows whatsoever IP host to easily make utilise of network resource without whatsoever administrative intervention, this is challenging. New wireless network access applied science makes physical security impossible. In an apartment building, neighbors would be able to eavesdrop on each other's data communications and perhaps even use their unprotected resources without permission. It might be possible to pass up the book of a neighbour'due south network-enabled radio, for instance, if safeguards are not in place to preclude information technology.

Transparency

A lot of software exists for IP hosts that runs over traditional IP networking system software. This software should run the same fashion "over" zero configuration protocols. The system interfaces that be today should not demand to be inverse -- only the underlying networking system software. Equally important, the beliefs of zero configuration networking protocols should be the same as their "configured" network equivalent.

Independence

Zero configuration networking should non be all or nothing. A network may, for instance, accept a DHCP server simply lack a DNS server. In that case, host configuration volition be available, merely hosts will be able to apply the zero configuration protocol for DNS name resolution.

Status of ongoing piece of work

The Cipher Configuration Working Group[16] in the IETF has been chartered to produce a requirements specification for zero configuration networking for both IPv4 and IPv6. These requirements will set the goals for the subsequent product, a contour certificate. These documents are works in progress. Links can be found to them off of the ZEROCONF Working Group charter page.

The zero configuration contour is in a sense a supplement to the document discussing host requirements for IP.[17] Section 1.2.four of that certificate reads:

It would be ideal if a host implementation of the Internet protocol suite could be entirely cocky-configuring. This would allow the whole suite to be implemented in ROM or cast into silicon, it would simplify diskless workstations, and it would exist an immense benefaction to harried LAN administrators as well every bit system vendors. Nosotros have not reached this ideal; in fact, nosotros are not even shut.

The profile document volition list standards for tracking IETF protocols and indicate whether their use is recommended, required, or mandatory. The profile document will likewise specify mechanisms for transitioning from zero configuration to configured behavior for each protocol surface area under consideration.

The working group is currently working to produce the requirements specification and making practiced progress.

The nada configuration protocol areas nether consideration for the working grouping are:

automatic host configuration
service discovery
multicast domain name to address resolution
automatic multicast accost resource allotment
transition to secure performance

The current understanding of the requirements and initial ideas for the profile document are summarized below.

Automatic host configuration

The requirements include the power to configure the essential parameters described above likewise as a unique address. Address autoconfiguration for IPv6 satisfies these requirements. There is ongoing work on address autoconfiguration for IPv4. Eventually a specification will be published by the IETF.

An open up issue in automatic host configuration is handling two or more than nix configuration networks "fusing together." In that case, claim-and-defend protocols are insufficient: reclaiming is required to maintain uniqueness. A claim-and-defend protocol requires a host to broadcast (or multicast) a merits, similar "My address is 10.0.0.one." All other hosts have to defend their ain claims, so if another host has already claimed that address, that must be detected, and the indistinguishable claims must be retracted. The complication is that the network definition (the periphery) is not static. Distinct "consistent" populations may merge, potentially creating conflicts that tin can be resolved simply by a new round of claims every once in a while.

It is articulate that DHCP will be used as the "transition" mechanism out of automatic host configuration mode, for IPv4 hosts to obtain dynamic configuration. For IPv6, the presence of IPv6 routers is sufficient to provide a further host configuration.

Service discovery

Service discovery requirements include the ability of clients to discover services without the need for prior configuration or whatsoever "service discovery" servers beingness present. Queries are sent via multicast by clients to observe servers on the network. Replies must be swift (i.east., later on an acceptably short delay after a request is issued). The service discovery protocol must non cause broadcast storms or other unscalable behavior. (This is a real chance, as many existing service discovery protocols require an inordinate corporeality of network resources).

SLP can exist used in IPv4 and IPv6 networks. SLP has its own mechanisms to transition from zero configuration peer-to peer-performance to a highly scalable client/server operation. All that is required is that an SLP "server" exist deployed. All configuration of SLP agents is washed automatically.

Although SLP is a standards track protocol in the IETF that meets the criteria of zero configuration service discovery requirements (as they are before long formulated), there is dissent. Other protocols are existence developed or discussed that could be alternatives to SLP for service discovery in the zero configuration contour.

Multicast domain proper noun to accost resolution

The zero configuration requirement for this protocol area is to exist able to resolve domain names using multicast in the absence of a DNS server. In order to back up this requirement, an IP host will as well take to listen for such requests and respond when the request corresponds to the host's own name. This machinery volition form the basis of a merits-and-defend mechanism allowing hosts to select unique domain names and maintain their uniqueness over fourth dimension. Multicast is required and then that requests can span the entire zilch configuration network.

In that location are two ongoing efforts in the IETF related to this function. The first is multicast DNS,[18] which involves multicasting DNS queries to the network instead of unicasting them to a DNS server. The 2d is an Internet control message protocol (ICMP) based multicast name resolution protocol called "IPv6 Node Information Queries." This protocol is beingness developed in the IPNG Working Grouping[19], and a reference to the electric current version of the specification is available from the lease folio.

In both cases, each host would run a "stub" naming service, which would listen for requests for the host'southward own proper noun and respond. The reason this name service is considered a stub is that the host's name service would neither provide proper name-to- address resolution for other hosts nor necessarily participate in the hierarchical global DNS at all.

In whatsoever case, information technology is articulate that when a DNS server is present, it should exist used (at least for names outside of the zero configuration network). Information technology is not clear how the transition from zero configuration proper name resolution to normal DNS operation volition work.

There has been some discussion of using multicast DNS in conjunction with DNS SRV resource records for service discovery. At that place is debate over whether this protocol would present scalability problems and whether it has enough features to provide an adequate service discovery protocol.

Automatic multicast address allotment

Automatic multicast address allocation allows a host to obtain an address allocation for a multicast grouping for the host's own purposes. This prevents different applications from colliding, that is, using the aforementioned multicast group for different purposes. A multicast address resource allotment architecture[15] is being developed for allocation of global, administratively local addresses.

The list of requirements for this protocol is notwithstanding under development, but it is clear that information technology volition involve a claim-and-defend mechanism similar to IP address autoconfiguration. It is not clear whether a new address space (the zero configuration multicast accost scope) is necessary.

Just as DHCP is the obvious transition machinery from IP address autoconfiguration, multicast address dynamic allotment profile (MADCAP)[20] is the obvious protocol for making a transition from automated to dynamic multicast accost allocation.

Transition to secure performance

Security requires configuration; at that place is no getting around that fact. Zilch configuration networking security is an oxymoron.

Security configuration constitutes a transition from zippo configuration operation. It is such a vital transition that it must be worked out in detail, then that every protocol in the cipher configuration profile will have a "required to implement" security configuration component. Ideally, this configuration will be simple, and 1 solution (indeed, one configured item) will work for all zero configuration protocols.

seven. Implications for the future

An increasing number of zero configuration features will be bachelor in networking products. As IP host software becomes cheaper and consumer devices include the software, these features will make a tremendous, though silent, impact. Ideally, the owners and operators will non know there is a information network at all, in the same manner they are oblivious to the power network.

IP networks volition exist possible in settings where they are currently unthinkable, such as inside computers or in emergency shelters (where there's no fourth dimension, let lonely expertise, to configure a network).

The claiming for the future is to push zero configuration as far equally possible. It is theoretically possible to deploy extremely large networks that use nada configuration protocols. Large networks include routers to interconnect smaller networks. These routers currently requires considerable configuration. Maybe that too will be addressed with automatic configuration mechanisms.

As data communication becomes more pervasive, network security will change in status. Currently it is a preventive mensurate with no credible positive proceeds. Since i normally isn't aware of attacks, network security seems about superfluous. That will non be the case if networking touches every attribute of our lives. It has become inconceivable to live without a lock on the doors of our homes to prevent theft. In the futurity we will have to secure items inside our homes, equally thieves won't necessarily have to physically enter our homes to make off with or misuse our property.

8. References

[one] The condition of the IP suite is given in Reynolds, J., and Braden, R., Editors, "Internet Official Protocol Standards," RFC 2500, June 1999.

[ii] Sidhu, G., Andrews, R., and Oppenheimer, A., "Inside Appletalk, 2d Edition," Addison Wesley, 1990.

[3] While in that location were clearly many good technical reasons for IEEE 1394, USB, BlueTooth and other protocols, information technology is clear that IP was not an option, since it doesn't provide automatic addressing and operation without a name server.

[4] Mockapetris, P., "Domain Names: Concepts and Facilities," RFC 1034, November 1987.

[5] Droms, R., "Dynamic Host Configuration Protocol," RFC 2131, March 1997.

[6] Deering, Southward., and Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460, December 1998.

[7] Thomson, S., and Narten, T., "IPv6 Stateless Address Autoconfiguration," RFC 2462, Dec 1998.

[8] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998.

[9] Gulbrandsen, A., Vixie, P., and Esibov, L., "A DNS RR for Specifying the Location of Services (DNS SRV)," RFC 2782, February 2000.

[10] Guttman, Eastward., Perkins, C., Veizades, J., and Day, Thousand., "Service Location Protocol, Version 2," RFC 2608, June 1999.

[eleven] Wahl, M., Howes, T., and Kille, S., "Lightweight Directory Access Protocol (v3)," RFC 2251, December 1997.

[12] Howard, L. "An Arroyo for Using LDAP equally a Network Data Service," RFC 2307, March 1998.

[xiii] The protocol is partially documented in Troll, R., "DHCP Choice to Disable Stateless Auto-Configuration in IPv4 Clients," RFC 2563, May 1999. A formal specification for accost autoconfiguration for IPv4 has not yet been published.

[14] Auerbach, K., "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods," RFC 1001, March 1987.

[15] The multicast address allocation architecture is still a work in progress. The current specification can be seen past visiting the Multicast-Address Allocation Working Group charter page.

[sixteen] Zero Configuration Working Grouping charter folio.

[17] Braden, R., Editor, "Requirements for Internet Hosts: Communication Layers," RFC 1122, October 1989.

[18] Multicast DNS is offset mentioned on folio 76 of Braden, R., "Requirements for Internet Hosts: Application and Support," RFC 1123, October 1989.

[19] IPNG Working Groupcharter page.

[20] Hanna, S., Patel, B., and Shah, M., "Multicast Address Dynamic Allocation Protocol (MADCAP)," RFC 2730, Dec 1999.

Author information

Erik Guttman is a Senior Staff Engineer in the Sun Microsystems Laboratories Networking and Security Center and lives in Germany. His principal professional interests are automated network configuration and practical network security. He is the chairman of the Service Location Protocol IETF Working Group and cochairman of the Zero Configuration IETF Working Group.

Source: https://www.isoc.org/inet2000/cdproceedings/3c/3c_3.htm

Posted by: connellyhica1947.blogspot.com