2.3.12 Zero Configuration Networking (zeroconf)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 17-Nov-00


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: zeroconf-request@merit.edu
In Body: subscribe zeroconf your_email_address
Archive: http://www.merit.edu/mail.archives/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 preexisting configuration. 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:

* Interface Configuration (IP address, network prefix, gateway router)

* Name-to-Address Translation

* Service Discovery

* Automatic allocation of Multicast Addresses

* Sufficient security features to prevent networks from being any less secure than networks which do not use ZEROCONF protocols

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 may automatically transition from 'configured' to 'unconfigured' behavior, as well as from 'unconfigured' to 'configured'. 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 also produce two protocol specifications. First, the WG will develop a document describing automatic generation and assignment of link-local IPv4 addresses in environments lacking host configuration (static or using DHCP). The document will describe existing practice as well as define recommendations for future implementations. Second, the WG will develop a profile of the Address Allocation Protocol (AAP) to provide Zero Configuration Multicast Address Allocation support for IPv4 and IPv6. No protocol modifications to AAP are expected. Rather, a subset of existing feature will be profiled for use in ZEROCONF environments.

Goals and Milestones:

Oct 00


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

Dec 00


Submit Automatic Address Configuration for IPv4 to be considered as a Standards Track RFC.

Dec 00


Submit Multicast Address Allocation Protocol for Zeroconf Networks to be considered as a Standards Track RFC.

Dec 00


Submit Multicast Address Allocation Protocol for Zeroconf Networks to be considered as a Standards Track RFC.

Mar 01


Submit internet-draft to be considered as an Informational RFC on Host Profile for Zero Configuration Networking.

Mar 01


Submit internet-draft to be considered as an Informational RFC on Host Profile for Zero Configuration Networking.


No Request For Comments

Current Meeting Report

Minutes for ZEROCONF Meeting
3:30pm - 5:30pm, Monday, 11th December 2000
49th IETF Meeting, San Diego, California, 10th - 15th December 2000


5 - intro/agenda buffing
Stuart & Erik

30 - IPv4 Link Local Addresses draft-01
see: draft-ietf-zeroconf-ipv4-linklocal-01.txt

10 - brief discussion of end result of reqts draft
see: draft-ietf-zeroconf-reqts-06.txt

30 - mc address allocation protocol discussion
see: draft-thaler-zeroconf-multicast-02.txt
Steve Hanna

10 - report on DNSEXT work on mdns
see: draft-ietf-dnsext-mdns-00.txt
Bernard Aboba

15 - ZC security draft
see: draft-williams-zeroconf-security-00.txt
Aidan Williams & Steve Hanna

15 - Plug for future BOF on Networked Appliances
Simon Tsang and Stan Moyer
see: draft-tsang-appliances-reqs-01.txt
see: draft-moyer-sip-appliances-framework-00.txt

5 - going forward - work schedule and goals
Erik & Stuart


Changes to the agenda were solicited; no changes were requested.


Stuart Cheshire, IPv4 Link Local Addresses

Question: Should there be two drafts, one standards-track, and one informational describing existing implementations? It was agreed that it is better to have one single draft, with an appendix describing the current limited implementations (with warnings that producing other similarly limited implementations is not recommended).

Question: Should DHCP servers be allowed to allocate in the 169.254 link-local range? It was agreed that since there are existing site-local address ranges already available (e.g Net 10), there is no reason to use 169.254 for this, so the draft should state that DHCP servers SHOULD NOT allocate in the 169.254 link-local range.

Question: Should NAT gateways be allowed to rewrite 169.254 link-local packets and forward them off-link? It was agreed that since there are existing site-local address ranges already available which can be allocated via DHCP, a NAT gateway product MUST NOT rewrite 169.254 link-local packets. It is useful if devices using 169.254 link-local addresses can assume that those packets will not leave the local link, so NAT gateways MUST NOT forward these packets off-link.

An issue is that legacy stuff (Mac OS 8.5+, Windows 98, ME, 2000) won't be able to communicate with local address only devices.

Bernard Aboba stressed that we should focus on devices which are either global only, local only or both, as opposed to devices which transition automatically.

Bernard was concerned that we might find it hard to specify devices which have only linklocal addresses if we have only one draft. (Later in discussion, he was persuaded otherwise).

Lingering issues: Some routers do not currently handle 169.254 correctly.

Of some 20 readers, half thought this document is about ready to progress, and no one thought it wasn't.

After adding an appendix to describe legacy linklocal implementations and their problems, the consensus was to move this document to WG last call.


Erik Guttman, Requirements Draft

Erik presented the state of the requirements draft. The draft has gone though last call; some changes were agreed during that period. Draft-ietf-zeroconf-reqts-06.txt reflects most of those changes, but due to time pressure, a few changes were missed and a few typos were introduced. For example, it was agreed during the last-call period that a default route is NOT a requirement for communication between two hosts on the same link, but draft-06 does not reflect this change. This will be rectified in draft-07.

A point was raised that, although it may seem obvious to many that forward name lookups and reverse name lookups go hand-in-hand, the draft does not *explicitly* require the capability to do reverse name lookups. This omission could be a problem, because if a zeroconf name resolution protocol were implemented which did not support reverse name lookups, it would be compliant with the requirements document yet fail to usefully meet the needs of many current IP applications.

It was generally agreed that this omission was not a deliberate design decision by the working group, but merely an oversight which should be corrected along with the other typographic corrections being made for draft-07. This will be proposed on the mailing list, and if no arguments are made against it, this correction will be incorporated into draft-07.

The WG agreed that the draft, after completion of the changes described above, is complete and ready to be sent to the RFC editor.


Steve Hanna, Zeroconf multicast address allocation

* There are many Multicast Address scopes:
* Global scope - This is not useful unless connected to the internet. Since there are a limited number of global addresses, it is useful to break things up into administrative units.
* Big - Transcends administrative domains.
* Small - Does not.
* Node-local - Used only in IPv6, presently. It is local to a host.
* Single-source - For this type of address there can only be a single source, you specify the source as well as the group address.

* Dynamic allocation architecture for IPv4

Addresses are a scarce resource, do allocation efficiently.

The architecture is hierarchical, intradomain, interdomain and client-server interdomain.


If one uses only AIU and ACLM messages this would be enough for peer to peer allocation within a (small) administrative domain.

Note that this is a subset of malloc.

It might make sense to do peer to peer allocation only when MADCAP was unavailable. It may also be possible to assign a specific range of addresses which would only be used for Zeroconf multicast address allocation which could be used at any time - analogous to the way link local addresses can be retained even if an interface is configured with a global address using DHCP. This is an open question.

There are still some issues to work out, e.g. AAP currently requires a 150-second wait before allocating addresses.

It was observed that a client machine needs to implement BOTH MADCAP and AAP clients (but both are quite simple).

Erik presented implementation experience of Zeroconf multicast address allocation. He has discovered some poor timer choices that can make the protocol vulnerable to a single packet loss. Also, AAP clients are supposed to keep track of all addresses currently in use and defend on their behalf. Should we make this optional in the zeroconf context?

The WG is ready to proceed with an AAP profile for multicast address autoconfiguration, as per Dave Thaler's draft -- with modifications suggested by Erik G. Dave and Erik volunteered as document editors.


Bernard Aboba invited anyone interested in mDNS to attend the DNSEXT working group meeting.


Aidan Williams, Security for Zeroconf Networks

The presentation followed draft-williams-zeroconf-security-00.txt

* L2 solutions

These are non-uniform, so a variety of configuration mechanisms would have to be supported at a bridge, gateway, or multihomed device.

In discussion it was pointed out that 802.x L2 security seems to be supported on an ever larger set of link technology. Perhaps if there is great convergence on this it will make more sense to pursue this option. But for the present there is firewire, ppp & other link layer technology, with different security mechanisms.

Dave Thaler recommended keeping our minds open about L2 solutions -- e.g. they also solve the insecure ARP problem for us too.

Bernard Aboba pointed out that the IEEE is converging on a common encryption technology for all IEEE-standard 802.x protocols.

* IPSec or individual protocol security

IPSec could be used as a single layer to provide all security properties required by individual ZC protocols, it was argued. Securing them one by one is more complicated since each protocol requires different parameters and cryptographic code.

* Secret sharing

The document does not discuss this. Upcoming work from Steve Hanna will address key distribution mechanisms to make securing a network require as little configuration as possible.

A pre-shared secret can authenticated IKE Phase I, but... IKE cannot negotiate SAs for multicast or broadcast.

Zeroconf security should include confidentiality -- you may not want your neighbours to be able to compile an inventory of your equipment.

* Issues:

ARP is insecure, but IPv6 neighbour discovery can be secured
DNS signs records, but does not encrypt
AAP can use IPSEC -- but not IKE
IKE is complicated, especially for very simple devices. It may be better to just derive a key from a single shared secret.

Steve Hanna suggested pre-programming a random number into each device, and attaching a label or bar code which can be scanned to read the key. Steve Hanna disclosed that Sun has patents in this area, which Sun intends to license on the usual Reasonable Nondiscriminatory Terms.

* The upshot

More discussion and specifics are welcome here. We can't take this on as a charter item yet. Once we have completed more charter items and there is a specific proposal, we can revisit the question of taking this work item on.


Stan Moyer, Plug for future BOF on Network Appliances over the WAN

* This discussion took place as a plug for a BOF by Stan Moyer, who is interested in this topic. This is not a work item for ZEROCONF, but there may areas of common interest.

There was little or no discussion of this presentation - it represents Stan's views.

* see http://agreenhouse.com which has a prototype of what this might be like.

* there are drafts this presentation was based on - see the slides.

* What is an appliance?

Any host?

* Direct or indirect communication is possible

Indirect communication is through some protocol translation gateway.

* Operations

commands, queries, asynchronous operations, media streaming, discovery

* How do you address devices when devices may or may not be in a private address space?

Naming and discovery have to cross administrative boundaries

How do you communicate with devices on non-IP networks?

* This does not conflict with ZEROCONF

Network appliance work would assume configured networks

* Where we are

There is a mailing list with >100 participants. Stan wants to organize a BOF at IETF 50.


Erik & Stuart, going forward

* Finish requirements draft and submit
* Move IPv4 Link Local Addresses to last-call
* Dave and Erik will work on AAP profile for zeroconf


Stuart Cheshire <cheshire@apple.com>
* Wizard Without Portfolio, Apple Computer
* www.stuartcheshire.org


ZC Multicast Address Allocation
Wide Area Communication with and Interworking of Networked Appliances
Securing ZEROCONF Networks