NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 29-Feb-00
Chair(s):
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 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. |
Internet-Drafts:
No Request For Comments
Minutes for ZEROCONF Meeting
47th IETF, Adelaide, Australia, 26th-31st March 2000
Date: Monday, 27th March 2000
Thanks to Scott Corson for recording these minutes.
The ZEROCONF WG met for two hours, from 9:30am to 11:30am.
Agenda bashing and introduction covering goals of meeting given by (E. Guttman). Meeting goals are:
1) Work through issues in zeroconf requirements document
2) Discuss work in different protocol areas
· informational
· implications for requirements doc
· potential future WG to work with them
Requirements Document Revisions and Issues (M. Hattig)
WG is producing two documents:
1) requirements document
2) profiles document
Changes to requirements document (version 3)
Removed "zeroconf network" concept, instead focusing on zeroconf protocols.
· removed topology section
· replaced gateway with a specialized router
Added IPv6 considerations
Intro Section
· clarified ZC to non-ZC transitions
· clarified intro to four protocol sections
· removed topology discussion
Scenarios and Requirements
· more realistic and concise
Security Section
· still needs work
Draft v4 of requirements document is targeted to be *final* version.
Issue of ZC to non-ZC transitions was raised. Regarding ZC to non-ZC transitions, there is an assumption of a *hard* transition. This assumption concerns the MUST transition statement in of using global identifier and throwing away local ones...Question? Is the ZC conf information still useful even if global info is available? Maybe this would require multiple configurations per interface and therefore changes to IP stacks...this should NOT be a MUST for IPv6 (Thaler). In case of DNS (B. Gudmundsson)...maybe not. There may be situations where we want the capability to do both (Thaler), probably need to add IPv4 issues.
Host requirements RFCs specify a set of protocols (Guttman).
What about alternative service discovery protocols (other than SLP, such as multicast DNS using SRV records)? What is the WG opinion? A long discussion followed.
We have an IETF standard for service discovery...should this be part of charter or not? Service discovery likely should be part of ZC. Should SLP be adopted as standard, or should others be used...like DNS? Characteristic-based discovery adds complexity without which SLP is a lot like multicast DNS SRV, only tweaked. Bill says we should define the requirements now and see what other protocols (if any) match up well or not afterwards. Should WG consider other protocol aspects before defining requirements? Is characteristic-based service discovery a MUST for ZC? This has been found to be useful for large networks as it reduces network traffic (perhaps MUST to SHOULD is appropriate). Is characteristic-based service discovery useful for small networks?
(Perkins) says we should agree on something to get something quickly. (Deering) asks if the new "Minimal SLP" proposal answers criticisms of SLP being too complicated for embedded devices. (Stuart) If I have a printer with Minimal SLP, and a client desiring to discover printers sends a full SLPv2 query including attributes, will the Minimal SLP printer respond?... (Eric) A printer using Minimal SLP would define an different service template (not 'service:printer:') that allowed no attributes, and then advertise that service using Minimal SLP, so a client trying to locate services of type 'service:printer:' would, by definition, not be trying to find that particular printer.
(Deering) asks lots of SLP questions...(Eric) fills him in...we degenerate into a service discovery discussion regarding the merits of SLP in directory-based large networks. Are there any advantages that SLP gives in the real world via attribute-based discovery that ZC needs. As an example, SIP servers for call processing. Could be querying for a DB with my information. What about keeping things simple? Suggestion that requirements document should point towards easy near-term goals that can be met in a sequence. WG is supposed to avoid rat holes...is this
debate SLP vs. DNS one of those? ZC is looking at peer-to-peer primarily, but how to transition to client- server when a larger DNS server appears.
(Charlie) This is not only for interactive environments, but automated/embedded devices (lots of them) should not mess things up. How to do this cheaply in ZC environments with this in mind. (Hattig) how should the WG address scaling properly in ZC requirements? DNS scales...what are the effects of peer-to-peer scaling (Guttman). We know how SLP scales in some contexts. DNS does scale to the Internet, but certain types of lookups may not scale well. (Guttman) multiple service discovery approaches may be feasible. It should probably not be in the requirements document.
***
IPv4 link-local addresses (Stuart)
Prerequisite for ZC IP networking is an IP addresses. Mac OS and Windows both use self-allocation of 169.254/16 addresses when no DHCP server is present, but there is no IETF Standard describing how this works. Stuart presented draft-cheshire-ipv4-linklocal-00.txt to document this functionality to enable third-party inter-operable implementations. This draft was presented because it meets the ZC requirement for address allocation, but it is a personal submission, not a working group document (ZC charter is, at present, to define requirements, not new protocols).
The draft documents previous Mac OS and Windows behavior, with two enhancements:
· multiple IPv4 addresses per interface (like IPv6)
· multiple interfaces
Rationale:
· Having both a global IPv4 address and a local IPv4 address on a computer allows a user to browse the web via the global IPv4 address, and simultaneously print those web pages using the local IPv4 address on a local network printer that does not have a global address. Currently Mac users browse the web using IP and print locally using AppleTalk, but as we retire AppleTalk we need to be able to provide the same functionality using only IP.
· - Supporting multiple interfaces is a requirement for Apple because all current Apple hardware is multi-homed - every machine Apple sells has 100Mb/s Ethernet for wired networking, and built-in 11Mb/s 802.11 antennas for wireless networking. Supporting link-local addresses on a multi-homed machine raises some new issues, which are described in this draft.
· (Deering) multiple global/link local addresses make selection of which to use non-trivial from source perspective. (Stuart) I think if both endpoints have both self-assigned local and administratively-assigned global addresses, they should prefer the global addresses since they are likely to remain more stable over time, but I'm open to suggestions on the issue.
Should ARP responses be broadcast as Stuart suggests? Might help address conflict detection/resolution. Perhaps querying node can detect response and inform other endpoints (but a third host needed here...consensus that this is not good).
How does this effect ZC requirements? Current requirements doc says that ZC and non-ZC protocols MUST NOT co-exist at same time -- but in this draft ZC and non-ZC addresses are specifically described co-existing. Should requirements doc be revised?
Draft should refer to link local and "non-link local" addresses, rather than global addresses.
****
Multicast DNS (Bernard)
draft-adoba-dnsext-mdns-00.txt
Goals: want an IP solution using DNS
Name resolution is small networks
· where there is no DNS service
· where DNS server does not accept dynamic updates to register local names
Scalable behavior in large networks (this option needs to be OFF)
· no mDNS usage here
· limitation of ZC mDNS to link-local scope
· administrative control over mDNS conf
Non-goals
· not a substitute for Dynamic DNS
· don't want Internet-wide behavior
· not for service location
Scope of Multicast DNS (small networks)
· always send to link local scope, may then also send to local scope
DNS service discovery
· host sends SRV query
· not very useful for IPv4
· typical no DNS server around
ZC behavior
· hosts with only linklocal addresses use mDNS after unicast query (H- node)
· send DNS queries via unicast if DNS available
Non-ZC behavior
· host configures with DHCP but without an mDNS conf option...must NOT send mDNS queries.
Name Conflicts
· Gratuitous name query, when hosts joining a network or changing names or being configured to use mDNS
Query Suppression
· want to maximize chances of resolution in link-local scope
· multicast (ACK suppression used)
Questions on duplicate link local/name conflict resolution. Conflicts are on A records...what to do here? Important for Server to respond to overrule other responses...need to authenticate server to avoid impersonation.
*****
Security Issues
Punt vs. no Punt
No one has defended "No punt" position, but no one has figured out to do it.
(Schiller) What about consumer market? Should need no configuration by hand. Connecting to rest of Internet is when security problem happens...but this may occur at time of ZC in a business setting? Should L2 handle some of this...yes...what and where? Configuration "leap of faith" may be better than at every power on. Should protocol specifics be looked at?