NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Erik Guttman <firstname.lastname@example.org>
Stuart Cheshire <email@example.com>
Internet Area Director(s):
Thomas Narten <firstname.lastname@example.org>
Erik Nordmark <email@example.com>
Internet Area Advisor:
Thomas Narten <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe zeroconf your_email_address
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:
Submit internet-draft to be considered as an Informational RFC on Requirements for Zero Administration Networking.
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
Minutes for ZEROCONF Meeting
1:00pm - 2:00pm, Tuesday, 1st August 2000
48th IETF Meeting, Pittsburgh, Pennsylvania, 30th July - 4th August 2000
Thanks to Steve Hanna for taking notes for these minutes.
Charter Discussion (30 minutes)
Requirements Document Discussion (30 minutes)
We have almost completed the primary item of our existing charter (developing a requirements document). This document identifies areas where new work is needed. Should we expand the Zeroconf charter to include the portions of this new work that are not already covered by other working groups?
Erik Guttman listed the needed protocols, noting which ones are being addressed elsewhere and which are not:
* Service Discovery
SLPv2 & DNS SRV are both Proposed Standards. No need for new service discovery protocols. Any comments?
Bill Woodcock and one other called out in agreement.
* Interface Configuration
IPv6 stateless addrconf is already a Draft Standard from IPNGWG. No new protocol work is needed here.
IPv4 linklocal address assignment has two drafts but no WG. The DHC working group has stated that it has no interest in pursuing work on this. Should IPv4 linklocal address assignment become an official work item of Zeroconf?
Side discussion: IPv4 linklocal address assignment bears on the question of transitions vs. peaceful coexistence. The current charter of Zeroconf assumes that Zeroconf protocols are harmful to large configured networks, and must automatically shut down on such networks. However, the true requirement that the charter should have stated is that Zeroconf protocols must do no harm on large configured networks. Whether that requires them to shut down depends on whether they cause harm to large configured networks if they do not. Given that no transition can be instantaneous, there will always be some period of coexistence, so it is desirable that Zeroconf protocols should not cause harm to large networks in this case. Consequently, if Zeroconf protocols can be created that do not cause harm to large networks, then there is no reason to require them to automatically shut down on such networks.
Comment from the floor: Didn't we agree in Adelaide that there was broad consensus that IPv4 LL should coexist with configured addresses? Why are we still discussing this?
Erik Guttman then asked anyone who disagreed to come to a microphone to present an opposing argument, and when no one was forthcoming, declared rough consensus on the issue of peaceful coexistence.
Question from the floor: Should we update Host Requirements?
Erik Guttman: Host Requirements was not written prescriptively, in advance; it was written descriptively, after we had gained considerable experience. We cannot even consider updating Host Requirements until after we have gained a similar level of operational experience with Zeroconf protocols.
Return to original question: Should IPv4 linklocal address assignment become an official work item of Zeroconf?
No one spoke out to oppose this.
Comment from the floor: IPv4 LL draft should be a standard-track document, not Informational.
No one spoke out to oppose this.
* Name Resolution
This is being considered outside Zeroconf, by IPv6 (hostinfo request/reply proposal) and DNSEXT (mDNS proposal).
* Multicast Address Allocation
Erik Guttman: Address Allocation Protocol, designed in MALLOC WG, is designed for large configured networks. However, it might be feasible to Zeroconf to write a profile document defining how AAP is used in Zeroconf networks. Dave Thaler has published a draft on these lines (draft-thaler-zeroconf-multicast-01.txt).
Comment from the floor: AAP is a peer-to-peer protocol anyway.
Erik Guttman: AAP does all we need and more. We just need to identify the "more" and remove it.
Assertion from Erik Guttman: All Zeroconf security requirements can be met by stating that a host needs to be able to determine whether packets it receives are from a trusted peer. All we need to do is say that there should be a way for packets to be authenticated. This protects claim-and-defend protocols against DOS attacks. This protects against rogue hosts masquerading as infrastructure services like DHCP servers. We've already agreed that securing ARP is out-of-scope. DNS, DHCP and SLP already have application-level authentication methods. Is that sufficient? Zeroconf does not claim to address confidentiality of user data transmitted over the wire. With configured or zeroconf networking, ensuring appropriate confidentiality protection remains the responsibility of higher-layer protocols.
Open question is how to make all this application-level authentication easy to do. Perhaps we could consider a future "Securing the LAN" document explaining how to make security set-up easy without requiring 'sneakernet', but we should clearly and simply state that this work is NOT in the Zeroconf charter.
Question from the floor: Will you identify another working group that should have responsibility for security?
Erik Guttman: I have identified elements of it, namely, SLP security is the responsibility of the SLP WG. DNS security is the responsibility of the DNS WG. DHCP security is the responsibility of the DHCP WG. What I am proposing here is that we find those people who are interested, and take them off to consult with the security directorate and security advisors, and possibly charter a new working group, but we should explicitly state that we are not going to do that work here.
Question from the floor. Isn't this the same as the work of the AAA working group?
General Consensus: No.
Dave Thaler: Requirements document should not solve the security problems, but should state security requirements that need to be addressed in any proposed protocol.
Erik Guttman: Agreed. The requirement for Zeroconf networking is not that it solve all security problems. The requirement for Zeroconf networking is that it not make networking less secure than configured networks are today.
Discussion from the floor: If light switches and light bulbs and other appliances start using networking, then their security requirements are the same regardless of whether they are using configured networking or zeroconf networking.
Erik presented a new list of charter goals:
9/00 Submit requirements draft for Informational
12/00 Submit IPv4 Host Autoconfiguration draft for Proposed Standard
12/00 Submit Zeroconf AAP Profile draft for Proposed Standard
3/01 Submit Zeroconf Protocol Profile draft for Informational
The Zeroconf Protocol Profile would list protocols needed for a zero configuration network, pointing at protocol specifications. Since this document would depend on all the protocol specs (including several that are in other working groups), it might have to wait at the IESG for those documents.
Question from the floor: Will the profile have to wait for the "Securing the LAN" document?
Answer: No. The requirement for Zeroconf networking is that it not make networking less secure than configured networks are today. The "Securing the LAN" document is a step beyond that.
Dave Thaler says authors of zeroconf protocol drafts need guidelines for writing their Security Considerations sections. Erik says that will go in the Requirements draft.
Stuart Cheshire: In addition, some parts of the charter need some minor rewording. For example, host configuration should be called interface configuration, since "host configuration" is already overloaded with other meanings, such as configuring the address of a DNS server, which may not apply in the Zeroconf case. These minor changes will be discussed on the mailing list.
The group generally agreed to the list of work items above.
Review of Draft 04
Erik listed several open issues pertaining to the requirements document:
* "MUST Transition" requirement
Erik Guttman: Current draft says "MUST transition to configured operation in the presence of a DHCP server" when a DHCP server is detected. An alternative, which we've heard support for here, is to allow peaceful coexistence, where a host maintains its self-configured link-local address, and any active TCP connections using it, in addition to obtaining an additional address from the DHCP server. Note that if we allow two IPv4 addresses like this, then we've created a scoped address architecture like IPv6.
Bill Woodcock: Lets decide this now.
Erik Guttman asked for people to hum in support of "MAY retain zeroconfigured operation", and then in support of "MUST transition". Broad support for being able to retain zeroconfigured operation; one person (Bill Manning) supported "MUST transition".
Unfortunately, some people were not clear about what was meant by "MAY retain" and "MUST transition":
Comment from the floor: When a small network becomes connected to a larger network, do we allow a hybrid state?
Stuart Cheshire: The agreement we thought we just reached is that devices should be allowed to implement the hybrid state. We're not mandating that devices MUST support a hybrid state and we're not mandating that devices MUST NOT support a hybrid state. We're saying that implementers are free to implement the hybrid state if they want to.
Comment from the floor: I supported "ability to retain zeroconfigured operation" because I thought it meant that devices must stay in zeroconf mode and MUST NOT support a hybrid state where they also get an address from the DHCP server as well.
Erik Guttman: So, based on what was just said, you would have hummed into the silence then?
Thomas Narten: The question is whether zeroconf and non-zeroconf protocols can exist in the same network.
Erik Guttman: The current spec says you MUST detect the presence of a DHCP server, and you MUST transition, and you have no choice. This allowed us to simplify a lot of issues by saying that a host is either zeroconf, or not zeroconf, and never both. However, many strong arguments have been made showing that this simple model is inadequate.
Bill Simpson: There are many useful potential applications of IP, such as home automation systems, and I don't want us to say that you're not allowed to make an IP-speaking light bulbs unless it also includes a DHCP client.
Comment from the floor: Saying that zeroconf protocols MUST NOT coexist with configured protocols simplifies the protocols.
Erik Guttman: It's not that simple. When a DHCP server comes up, there is necessarily some period of time before a zeroconf host detects the DHCP server, so there is always some period of overlap, so the protocols will have to accommodate that case anyway.
Even if we require a transition, we still have to consider the times when the transition has not fully occurred. All we're doing by saying "may coexist" is that we're taking off the duration requirement on the transition, and allowing that period of overlap to last indefinitely. It just has to be safe.
Bill Woodcock: Remember that Zeroconf devices can't use lack of transition as a substitute for security. Even for a device that doesn't transition to configured operation, designers need to be aware that other hosts on the same network may transition and may be accessible to hosts outside the local network.
Bill Manning: Saying that devices MUST transition to configured operation is a smaller set of work.
Comment from the floor: This WG shouldn't be working on IPv4 problems at all when IPv6 has already solved all these problems.
Stuart Cheshire: The primary work of this WG is not IPv4 address assignment. The primary work of this WG is to come to agreement on the requirements for zeroconf networking. The question in front of us right now is whether our requirements document should state that you MUST give up auto-configured operation when configuration information comes into existence on the network. In the context of IPv6 that's saying that you're not allowed to use IPv6 link-local addresses if you're seeing IPv6 router advertisements on the network. The question in front of us right now is whether we think that is a sensible requirement.
Erik Guttman again asked for people to hum in support of allowing hosts to continue using zeroconf protocols even in the presence of configured alternatives, or not. Again, the outcome was strongly on the side of allowing hosts to choose. Erik declared rough consensus on this point and asked anyone who still disagreed to present arguments on the mailing list.
* "Periodic actions" Requirement
Erik Guttman: Several sections of draft-04 include text that says zeroconf protocols MUST require hosts to perform periodic actions. The reason why it states that, is that we have a requirement in many cases to detect state changes, and it so happens that some of the mechanisms that exist today use periodic messages to achieve that state change detection in a timely way. It turns out that what we really want to do is to detect those state changes in a timely way. We have no desire to send out periodic messages for their own sake. Unnecessary periodic messages have been the death of many protocols and they are certainly not a requirement, or even a desirable feature, of a protocol.
* Host Name Resolution
Erik Guttman: Right now in the document we talk about Domain Name Resolution. We propose that we change this to Host Name Resolution. One reason for this is that the IPv6 hostinfo protocol requests names that are the names of hosts, but not necessarily Domain Names in the Domain Name System. Can we simplify the requirements document by talking about Host Names instead of Domain Names?
Stuart Cheshire: The requirements document should focus on the requirements, not the artefacts of the implementation, and the requirement is for users to be able to access hosts by name. Twenty years ago, this was achieved by having a big "/etc/hosts" file. When that became unmanageable the Domain Name System took over, but that's just one way of implementing name resolution. The requirement we want for zeroconf is looking up host names. Because we made the mistake of assuming that we necessarily achieve this using DNS, the current requirements draft is cluttered up with language about domains and subdomains and delegation, which are implementation details of a particular name system, not zeroconf requirements in their own right. The right solution for zeroconf networking may very well turn out to be some variant of DNS running over IP multicast, but the requirements document should not mandate that. The requirement is the ability to access hosts by name.
* Interface Configuration
Erik Guttman: There is text in the current requirements document that describes the use of netmasks and default routers as pieces of required host configuration. There is a suggestion that the real requirement being expressed is routing table configuration, and describing it as such would be a more general and more correct way of describing how IP hosts actually operate.
Also, a default route is *not* required for a zeroconf host to communicate with a peer zeroconf host.
* Configuration Servers (DHCP)
Erik Guttman: If you deploy a configuration server on your network, and that configuration server then goes and adds configuration to your hosts, then you're no longer in zeroconf any more. If I turn on a DHCP server, then the hosts that use configuration information from that DHCP server are configured. They're not using a zero configuration protocol. Now it could be that that DHCP server is itself automatically configured, but that's a totally different thing. Right now the requirements document is ambiguous about this. At one point it even states that DHCP may be a zero configuration protocol.
Erik asked for comments.
No disagreements were voiced.
Erik Guttman: Proposal for discussion on the mailing list: Zeroconf security requirements can all be met by the single requirement that hosts should be able to verify that messages they receive are from trusted peers.
* Final closing comment from the floor:
The requirements document should indicate what the assumptions are for zero configuration networking. Is a MAC address required, for example?
Erik agreed that this was a good point.
// Stuart Cheshire <firstname.lastname@example.org> \\
\\ Wizard Without Portfolio, Apple Computer //