2.3.9 Zero Configuration Networking (zeroconf)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 20-Oct-99


Erik Guttman <erik.guttman@sun.com>
Stuart Cheshire <cheshire@apple.com>

Internet Area Director(s):

Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>

Internet Area Advisor:

Thomas Narten <narten@raleigh.ibm.com>

Mailing Lists:

General Discussion:zeroconf@merit.edu
To Subscribe: zerocong-request@merit.edu
In Body: subscribe zeroconf your_email_address
Archive: http://www.merit.edu/mail.archives/html/zeroconf/

Description of Working Group:

The goal of the Zero Configuration Networking (ZEROCONF) Working Group is to enable networking in the absence of configuration and administration. Zero configuration networking is required for environments where administration is impractical or impossible, such as in the home or small office, embedded systems 'plugged together' as in an automobile, or to allow impromptu networks as between the devices of strangers on a train.

ZEROCONF requirements will make networking as easy as possible, but no easier. In some cases other considerations may dominate ease of use. For example, network security requires some configuration which may not be as easy as the unacceptable alternative of 'no security.'

Networks where ZEROCONF protocols apply can include (but are not limited to) environments where no DHCP, MADCAP or DNS servers are present.

This working group will address both IPv4 and IPv6.

Many functions which are not of fundamental importance to host and application configuration are outside the scope of the working group. This is not because there are no other problems to solve for networking in an environment without administration. This working group will focus on an achievable subset of these problems. The ZEROCONF WG will precisely define the requirements for each of the following functions:

* Automatic Host Configuration (IP address, network prefix, gateway router location, DNS server location)

* Name-to-Address Translation

* Service Discovery

* Automatic allocation of Multicast Addresses

* Sufficient security features to prevent ZEROCONF networks from being abused

The working group will define the requirements to provide these functions on two distinct network topologies:

1. A single network segment, where all hosts are reachable by link-layer broadcast or multicast messages.

2. A set of network segments, (on different IP subnetworks) interconnected by a single router.

Automatic configuration of an arbitrary topology of routers and subnets is out of the scope of the ZEROCONF WG charter.

The working group will also define how such a network will automatically transition from 'administered' to 'unadministered' behavior, as well as from 'unadministered' to 'administered'. That is, the same hosts must be able to function on networks with no configuration as well as be capable of direct IP connectivity to the global Internet, including DNS entries supplied through standard DNS services. It is also possible that both modes (ZEROCONF and administered) may coexist on the same network; the modes may not be exclusive of each other.

When ZEROCONF networks or hosts which are configured using ZEROCONF protocols are connected to the big 'I' internet, they should not automatically become vulnerable to new security threats.

This WG will produce two documents. The first describes the requirements for the configuration (and security) services, defaults, and mechanisms a node needs to fully participate on ZEROCONF networks and/or configured networks. The second, which follows the first, will detail a 'profile' specifying which standards specifically satisfy ZEROCONF requirements.

The WG will not engage in any new protocol work. If there is no existing standard protocol which satisfies ZEROCONF requirements, the profile document may specify that a new protocol should be developed or recommend a change to an existing standard to apply to the ZEROCONF environment.

Goals and Milestones:

Mar 00


Submit internet-draft to be considered as an Informational RFC on Requirements for Zero Administration Networking.

Jul 00


Submit internet-draft to be considered as an Informational RFC on Host Profile for Zero Administration Networking. If this profile cannot be written since required protocols are not yet standardized, recharter or dismiss the ZEROCONF WG.


No Request For Comments

Current Meeting Report

Zero Configuration Networking (zeroconf)

[Charter, mailing list info, etc., goes here]

Current Meeting Report

Minutes for ZEROCONF Meeting
46th IETF, Washington, DC, 8-12th November 1999
Date: Wednesday, 10th November 1999

Thanks to Craig Schamp for recording these minutes.

The ZEROCONF WG met for two and a half hours, from 9:00am to 11:30am.

Introduction -- Stuart Cheshire

What does ZEROCONF mean? What does it _not_ mean?

ZEROCONF means IP protocols that can operate without external configuration information, like AppleTalk or NETBEUI do today. The WG name was chosen very carefully. It is not "ZEROADMIN", or "EASYNET" or even "HOMENET". For example, a consumer gateway product that automatically assigns Net 10 addresses using DHCP may require no user administration, and it may be very easy to use, and it may be very suitable for home networks, but it is not ZEROCONF. DHCP is a configuration protocol (that's what the 'C' stands for) so DHCP is NOT a ZEROCONF protocol. In fact, use of DHCP is one of the canonical examples of a transition out of ZEROCONF, to configured network operation.

The canonical example of ZEROCONF operation is two laptop computers connected using a crossover Ethernet cable. There's no DHCP server, no DNS server, no gateway, router or firewall, just two laptop computers trying to exchange files. Currently this is easy using AppleTalk, and hard using IP.

If we can make two laptop computers communicate using IP, how far up can we scale? Two computers and a printer on a coax Ethernet? Four, five, six computers using a 10Base-T hub? At some point we will reach the limits of ZEROCONF, and networks above this size will benefit from configured operation, using DHCP servers, DNS servers, and so forth. We want ZEROCONF to scale up as far as is practical, as long as we don't forget our canonical example of two laptop computers connected using a crossover Ethernet cable. The IETF is very good at producing scalable protocols, but often we end up with protocols that scale so well that they work for a million hosts but they forget the simple case of a small network with just two or three hosts.

Some people argue that a small network with just two or three hosts is "not interesting", and it is precisely because of this that IP fails to provide the ease of use that AppleTalk or NETBEUI offer in these environments. Connecting to the worldwide Internet is important and useful, but it is not the only thing that IP can be useful for. If we limit ourselves to saying that the IETF exists only to promote IP as a struggling alternative to AOL, then we do the world a great disservice. If we do things right, then email and web browsing are not the final word for IP, just one early chapter in a long successful history of future innovation.

In wide area protocols we have gone from a gaggle of incompatible protocols just a few years ago to a clear convergence on IP as the One True Protocol. In short-distance protocols we still struggle with a gaggle of incompatible protocols -- serial port protocols, parallel port protocols, USB, Firewire, SCSI, IrDA, etc. IP could be the answer to unify all of these disparate hardware technologies, if only it worked better in these zero-configuration environments.

Review of requirements document -- Myron Hattig

An hour-long discussion ensued.

Steve Deering: Don't agree with the "at most one router" restriction. Perhaps this is a more useful way to think: Scope is admin multicast address range, greater than link local and less than site local. All productive work is done in terms of sending to that multicast range. "Site" in IPv6 is one administrative "domain". The discussion that there is just one router is unnecessary. What's important is that if there are routers, they be zero configuration routers.

Erik Guttman: Are you asking that we change the charter? Are you saying that what we really want to say is that "you can have no routers in the network that require configuration"?

Deering: Yes....

Stuart: I was the one who suggested the language about "no more than one router" because I wanted to control the complexity of the problem we were trying to solve.

Erik: Need to take an action item to revise the charter. Is that right? Who wants to address this point? Should we revise "zero or 1 routers" to "zeroconfigured routers"? (or possibly "zero configured routers")

Steven Ungar, Telcordia: I'm not an IP expert, but I'm working with the VESA home network standard. If you were to implement that architecture, you might have multiple routers in the home. If you have multiple media types, you're going to have to connect them at layer 3, by definition a router. Don't limit yourself to single router configurations. My point: I understand the need to address the simpler config first, but the more complex configuration may be the more practical one.

Bill Woodcock: Is there a reason why the hosts need to know that they're on a multi-router network? If the VESA standard wants to have multiple routers, then it is their responsibility to define how that will work.

Margaret Wasserman, Integrated Systems: Question on reconfiguration of IP addresses. You talk of reconfiguring network addresses when two networks come together. Somehow the zeroconf addresses should still be used, even while new addresses are brought into the mix. This allows you to continue using the zeroconf addresses for existing connections.

Erik G: You're saying 3 things. 1. you want to keep local addresses and keep using them. 2. You may want to use globally routable addresses in addition. 3. If there are any kinds of renumbering events, how can it be done in the least disruptive way possible? Maybe we need to add application level considerations to the document.

Stuart Cheshire: You are correct. Windows 98 and Mac OS 9 currently implement IPv4 link-local addresses ("autonet") as mutually exclusive with DHCP-assigned addresses, but this is not a requirement. This was simply because, historically, these operating systems have not handled multi-homing very well. As multi-homing support improves, each interface on a host should have an IPv4 link-local addresses in addition to whatever other addresses that interface may have, just like IPv6 link-local addresses. There's no need to tear down local TCP connections just because a DHCP server has become available.

Wasserman: "addresses MUST be locally routable" Why this restriction?

Bill Woodcock: How do you get a globally routable addresses without configuration?

Roger Kermode, Motorola: Question about using private IP addresses. Why does the draft mandate that you cannot ever have a globally routable address?

Dave Thaler: You want hosts to be able to get addresses, if globally routable ones are not available, then local addresses are fine. Your DHCP server should be able to claim globally routable addresses from your DSL or Cable Modem ISP, and then act as a proxy and hand out those addresses locally.

Erik Guttman: Once you're using DHCP you're not in a zeroconf net anymore, you're in a zero-admin network. If we have administrative information, we should use it, but if the DHCP server got routable addresses from the ISP and then the Internet link goes down, should it keep using them indefinitely?

Dave Th : If I can get a global IP address, say via a local DHCP relay agent that gets the global address from the ISP, then I'd like to make sure we don't preclude this scenario.

Franklin Reynolds, Nokia: What is the relationship of this group to others, such as Roaming Ops, on the boundary of zero config and zero admin? I'm not volunteering from Roaming Ops.... If we're in the zero admin group, if I want to set up a short-lived VPN, how do I advertise this VPN?

Myron: Setting up an encrypted secure tunnel to another site may be out of scope for the zero configuration charter.

Observation: If you're going to have a private conversation between two parties, you have to have a shared secret between the two parties, and then it's out of scope for this group. You have to configure it, therefore it's out of scope for this working group.

Very heated discussion about whether this VPN example is within scope of this WG....

Richard "Barr" Hibbs, PacBell: In favor of changing wording so that we don't limit the size of a network within the charter. Scale is relative. Pac Bell may well use ZEROCONF protocols for networks of over 100,000 hosts.

William Simpson: First point: I oppose the change to the charter. I don't want to hear about sites, expanding scopes, etc. Otherwise you won't get the work done. Zeroth point: Thanks to the chairs for assuming that people have read the drafts before opening discussion on the drafts and not wasting time with long boring presentations. Second point: Security language in document needs work.

Erik G: Charter says that we deal with ZEROCONF case, and the transition out of ZEROCONF. Maybe the exchange of secrets is out of scope for the ZEROCONF case, but we do want to say what the transition boundaries are. How the configured security protocols work are things that other WGs consider. Also, we can't assume that we only have one router, but we can't solve all multi router problems now.

Thomas Narten, IBM: Regarding charter change motivation: The wording changes aren't requiring additional work, but are clarifications. We're not proposing to solve the multi-router case, but if a vendor wants to do that we're not prohibiting it.

Private addresses: This group would do well to discourage their use as much as possible. Sometimes they're the only alternative, but whenever global addresses are available, those are the ones we want to use.

Karl Aurbach, Cisco: Don't want to limit the charter to be unrealistic. Every company these days is building a router, so we can't say "don't plug in a second box." ... Caching: The caches need to be flushed everytime we change a configuration. We need to put some metrics on the rate at which we change configurations.

Myron: Is that a realistic requirement (Timers?)

Karl: Maybe we need a new ICMP message to notify config change.

Margaret Wasserman: Gateway, you find one then lose it, such as on an RF network. Two machines with no base station are in communication, and then they move close to a base station that can route them to the net. Now what do you do?

Stuart: You're right, operating systems need to implement IPv4 multihoming, so that you can use link-local addresses simultaneously with global addresses. Another possible answer to this question is to say that IPv4 is dead, and we should be concentrating on IPv6.

Bill Woodcock: No one is saying that you shouldn't have two routers, that you shouldn't have globally routed addresses.... This WG is supposed to be addressing a temporary situation where you don't have multiple routers, globally routed addresses, etc, and that you want to work in this scenario where you don't have the resources to get you connected to the global internet. It's a temporary state which we're trying to address. Arguing about this is a waste of time.

To put it another way, when you have multiple routers, a DHCP server, a DNS server and globally routable addresses, that's great, and you should use them. The questions is that when you unfortunately *DON'T* have all that, can you still do something useful, like print on your local Ethernet printer?

Comment: Host names on systems have to be configured, so host names are out of scope of this WG, but you can't do anything without host names, so ZEROCONF can never be useful.

Disagreement: Host names are out of scope. (Bill Woodcock and Erik Guttman) We won't preclude people from generating their own names, but that's out of scope.

Stuart Cheshire: Whenever we say that nothing useful is possible, we need to remember that AppleTalk is a proof-by-example that we can make local networking easy and useful, without requiring configuration of addresses and net masks and name servers. To answer the specific question of host names, here is an example: When you buy an Epson Stylus 900N ink-jet printer, is ships with the default AppleTalk network name "Epson Stylus 900N". For the vast majority of small networks that don't have more than one Epson Stylus 900N ink-jet printer, no name configuration is required.

Other point: Requirement that routers on a zeroconf network be zeroconf routers.... A router that is a gateway to a global network is not zeroconf. Is it out of scope?

Scott Surner (?), Nokia: How can you do any security at all if zeroconf means no manual configuration? We may have addressed it, but did we say what should be done with the draft?

Erik: If you have specific language that you want to put in the document in this regard, let Myron know about it. We're still writing the requirements document.

William Sampson: Router redirects, ICMP redirects. If you have ICMP redirects, then you have more than one router, which means we're out of scope. Also, we don't want to be arguing about whether we should even use ICMP redirects on a network. 2nd comment: Myopia of a single address of an interface or one address of a box. In the DOS world we had multiple IP addresses per interface years ago. When you know you're not talking to a globally allocated IP address, you should continue to use the local addresses so that you can continue to talk to your neighbors in the event that you lose your global addresses.

Erik: We are all in agreement. Hosts should implement IPv4 multi-homing, and IPv4 link-local addresses should exist concurrently with other IPv4 addresses on the same interface.

Roger Kermode, Motorola: Important is transition case, local to global address scenario. Zeroconf for whom? Do we need to specify a scenario where you have a boundary at which you connect multiple zeroconf networks?

Dave Crocker: It's not comforting that we're oscillating between focused and unfocused discussion. I was hoping that we were going to solve a problem that I understood and that I felt need to be solved. Now, after discussion, I'm not sure I understand what we are trying to solve. What is a "mini DHCP server"?

Erik: I advise, hang on tight. Things will get clear.

Dave: You've just confirmed that there is a DHCP server, and that's a mistake.

Erik: DHCP server is the transition point between zeroconf mode and the non-zeroconf mode.

Steve Deering: Adding a router that connects a self-configured thing to the public Internet should not push you into a new mode of operation. Don't write the charter to imply this.

Stuart: Bridging

Bridges operate below IP, so maybe we shouldn't mention them. However bridging has caused a lot of debate, so we need to discuss it briefly. Maybe we should simply say that bridges are allowed as long as they are invisible to the IP layer, and leave it at that.

Thomas Narten: I don't want to imply that briding is out of scope, but restrict it to certain areas where it has specific implications on zeroconf.

Erik Guttman: Bridges have implications for claim and defend protocols as the topology is not necessarily static. As the LAN includes new members there is the possibility for a collision which did not occur initially. For this reason claims have to be repeated to detect and correct for collisions.

Stuart: This is not only a problem for bridging. I can join two segments of coax ethernet and change a topology.

Presented by Erik Guttman

Erik: Bernard couldn't make it. The internet draft is based on practical experience with the techniques described.

Dave Thaler, Mcast requirements
Zeroconf Multicast Address Allocation
Problem I have with the spec: Multicast addresses are allocated out of "the pool."
cf. draft-ietf-malloc-api-04.txt
Currently defined mcast scopes: Node-local (ipv6 only), single-source (ipv4 only), link-local (ipv6 only), "local," "other"

Some of these are well-known in the sense that they're IANA defined.

Steve Deering: Can you explain what the "single source" scope is?

Since it's orthogonal to this group, Dave Thaler arranged to discuss with Steve off-line.

Erik Guttman: How does allocation work when there are no (MADCAP, AAP, other) services? Can you talk to this?

Dave: Node-local have no impact on requirements. Link-local: for unicast, the equivalent is ARP. I don't want the requirements to say that you must.

Myron Hattig: ARP isn't an allocation protocol, it's a resolution protocol.

Dave: It's analogous, you claim a random address then claim and defend it.

Myron: OK, this is "claim and defend," not "allocation." OK.

Erik: We won't have any knowledge that a bigger scope exists, unless there was
(a) configuration info to give us this knowledge, or
(b) we knew about the bigger scope but then it went away. [doesn't (b) imply (a)?]

Alloc: Gateway behavior
Act as mini-MAAS, listens for MADCAP queries, and acts on them as follows: Node-local, single-source, link-local gateway not involved.
"local" (= zeroconf area scoped). Since these scopes are not globally administered, the mini-MAAS can pick addresses from them any way it wants.

Bill Woodcock: What's the benefit of this rather than continuing to use ARP in the local case?

Dave: I agree, we should look at it to see which one is more efficient. It doesn't change the requirements, though.

(cont) other "small" Forward MADCAP query to a MADCAP server If that fails, MAY pick random and ARP for it with AAP in the given scope other "large", global forward MADCAP query to a MADCAP server if that fails, cannot allocate an address in the given scope

Summary: Same host behavior in zeroconf/configured environments Gateway servers as mini-address allocation server to connect a zeroconf area to a configured environment. Allows address allocation in all scopes

o Steve Deering
IPv6 Plug & Play Architecture?
(Presentation given at Tokyo interim IPv6 meeting)
Supposed to be a major feature of IPv6....
How are we doing (in IPv6 group)? We've defined stateless addr config, DHCP configured, and neighbor discovery.... work on mobile IP is close to done (has IPsec issues) dyn DNS updates? many issues with server/service discovery? We have had some debate about discovering the DNS service. Positions: 1. include addresses of DNS servers in RA messages. 2. mcast discovery of DNS. 3. Having well-known non-global anycast address to reach DNS server.... How does it all fit together?

Erik: Our goal is to create requirements document. Second goal is to create a profile document for those things that have proposed std or std track items.

What constitutes "Plugging In"?
Different Plgging-In scenarios will require different host behavior.
Some discussion about mobile IP and DNS and initialization of a new node on a home network.

Deering: Zeroconf doesn't necessarily mean "zero local state".
Mobile IP requires state in the local device.

Erik Guttman: Needs to be possible that devices have no initial identifier at all.... Also, zeroconf networks may be large, and we need to be able to keep our zeroconf addresses as we move....

William Sampson: when you talk about mobility, there is a requirement that you share a secret with the entity that is acting as the home agent, which takes it out of the scope of zeroconf.

Dupont: You don't need shared secret, if you use IKE.

Simpson: Disagreement. IKE doesn't make it less painful to configure.

Deering (cont)
Point is that just plugging in means you do the same thing each subsequent time you plug in.

Erik G: Is there a mechanism such that when I attach an IPv6 cloud to an ISP,is there a way to hand out a range of addresses?

Deering: Yes.

Erik: Where is that in the standards track?

Hinden: WG has forwarded it to the IESG. What is not quite complete yet is the renumbering, the router advertisement is standards track.

George Tsirtsis: Number of things quite fuzzy between zeroconf and non-zeroconf. Mobile Telephones are pre-configured. Are they zeroconf?

Service Discovery requirements for ZeroConf networking.
Erik - Overview
Stuart - Moderator

Dongyan Wang, Samsung

Presentation on Service Discovery.

Described example of discovering each kind of "service" a video recorder offers: the ability to start recording, the ability to record for a specified time period, the ability to record at a specified time in the future, etc.

Question: Is this what everyone else means when they use the term
"Service Discovery"?

Cheshire: I think Service Discovery usually means discovering the video recorder itself. It means discovering the services on the network that speak a certain protocol, in this case the video recorder control protocol. Perhaps we should call fine-grained interrogation of the video recorder's specific capabilities "function discovery".

Woodcock: Isn't this what SLP is for? We still need to decide whether it is sufficient for a service discovery protocol to locate a service on the network, or whether it must also interrogate the service to discover detailed properties of that service.

Nordmark: Are you assuming that there's a way to enumerate all services and devices on the network in order to interrogate them?

Answer: No. That's not a requirement.

Comment from the floor: Maybe we should align our terms: Service vs. Resource. Maybe you don't then make a clear distinction between service discovery and resource discovery.

Discussion moved to XML-based service discovery.

Kempf: Is there currently no standardized way for an XML parsing device to have a DTD encoded already, or do you have to send a DTD with the XML text?

Comment from the floor: The parsing device cannot have the DTD encoded already because different vendors won't all agree to use the same DTD. Also, XML is very verbose.

Wang: Service Discovery must work for both simple and complex devices.

Yaron Goland: You don't need a DTD to parse XML.


Comments on ZeroConf Requirements from a Home Network View