NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Erik Guttman <email@example.com>
Stuart Cheshire <firstname.lastname@example.org>
Thomas Narten <email@example.com>
Erik Nordmark <firstname.lastname@example.org>
Thomas Narten <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe zeroconf your_email_address
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.
Submit internet-draft to be considered as an Informational RFC on Requirements for Zero Configuration Networking.
Submit Automatic Address Configuration for IPv4 to be considered as a Standards Track RFC.
Submit Multicast Address Allocation Protocol for Zeroconf Networks to be considered as a Standards Track RFC.
Submit internet-draft to be considered as an Informational RFC on Host Profile for Zero Configuration Networking.
Minutes for ZEROCONF Meeting
9:00am - 11:30am, Thursday, 22nd March 2001
50th IETF Meeting, Minneapolis, Minnesota, 18th - 23rd March 2001
Thanks to Aidan Williams for taking notes for these minutes.
9:00 5min Agenda Bashing Stuart
9:05 15min IPv4 LinkLocal Last Call Stuart
9:20 15min Zeroconf Requirements WG Last Call Progress Report Erik
9:35 45min Zeroconf Multicast Address Allocation Protocol (ZMAAP) Discussion Erik & Dave Thaler
10:20 30min Remote Access to ZC Networks Stuart
10:50 10min Going Forward - Schedule and Goals Erik & Stuart
Changes to the agenda were solicited; no changes were requested.
IPv4 Linklocal WG last call
- mature draft, gone to last call, no major objections
* either/or mode with dhcp/IPv4LL is no longer mandatory
* no borrowing 169.254/16 for anything else
* clarified ARP probes, gratuitous ARPs, etc
* Hugh Holbrook suggested rate limiting of requests rather than just giving up after 10 retries
* not OK to forward packet off link -- this is link local
* section on secure remote access
Zeroconf Requirements WG last call progress report
Erik Guttman & Stuart Cheshire
- many changes, going slow
- substantial changes in style and substance between draft-5 and draft-7
* routable requirement protocol => should not use broadcast
* default route is not a requirement
Bill Woodcock: why must we have routing information? for the "internet" scenario
Stuart Cheshire: The exact wording is a compromise between what various different parties wanted to see in the document. Our charter says that networks with a single router are within the group's scope, and if hosts have even just a default route pointing to that router, that could be considered routing info.
Michael Patton: We can use proxy ARP for this
Bill: This is a layer violation!!
Stuart: ... but, depending on your definition, could be still be considered to be "routing information", in that it directs an IP packet based on its IP destination address.
Bill: couldn't we just remove the MUST statement entirely?
* name -> address -> name, but not uniquely
* idea of defending addresses changed
In multicast, how addresses are defended is probably up to the protocol. Funcationally, such an address should be unique, and reused when it is no longer in use.
* Service discover requirements changed, subtle differences
- Still to do:
* applications rather than hosts make mcast address allocations
* netmasks: just specify
* various typos
* Erik: should we go back to working group last call
Michael Patton: yes. provoke people to read the document
Erik: but we don't want to reopen every issue that we have consensus on
Dave Thaler: can the diffs/changebars be produced?
Erik: called for a volunteer, sighed and said he would do it
Zeroconf Multicast Address Allocation Protocol (ZMAAP) discussion
Requirements -- Erik Guttman
- straw poll to see if wg thinks this is useful: a reasonable number of people indicated that they would implement ZMAAP
- zeroconf multicast requirements:
* should we require protocol to support scope and lifetime selection
* Dave Thaler: need to do what applications expect
* Stuart Cheshire: we certainly want scope and lifetime in an API, but possibly not in the protocol. We don't want to prohibit a simple claim/collide protocol.
* Dave Thaler: OK, can remove lifetime, but the scope is necessary. Protocol must respect the scope requirement of the application.
* Bernard Aboba: need to be able to allocate addresses from multiple scopes
Address Allocation Architecture -- Dave Thaler
- description of multicast scopes and semantics
- description of multicast address allocation architecture (rfc2908)
- for zeroconf, we adapt AAP for zeroconf, which would be ZMAAP
- transitions between "configured" and "unconfigured" state are painful, so it is better to define the Zeroconf multicast address allocation rules *only* for addresses that are never allocated using MADCAP. This means that Zeroconf multicast address allocation can be used on all networks, configured, and unconfigured, without conflict with MADCAP, thereby avoiding the need for any state transitions.
- ASM unicast prefix based address allocation has not yet been defined by malloc working group
- Dynamic link/subnet-scoped groups currently defined for IPv6 only
- Unicast-prefix-based allocation may be the primary ASM allocation mechanism in IPv6. Will see and IPv4 draft real soon now.
- Unicast prefix based allocation for IPv4 could allow address allocation from an orthogonal address range.
- The requirements document needn't mandate that "the multicast address allocation protocol MUST specify scope." The protocol MUST respect an application's scope requirements, but allocating an address in the right scope range is not the same thing as saying that the on-the-wire packet format must explicitly include a specification of the scope being used. Sometimes the scope of a multicast address can be determined implicitly simply from examination of the address, and doesn't need to be also specified explicitly.
Design Considerations -- Erik Guttman
- Lots of stuff on Erik's slides, scooting along quickly
- desire to avoid transition to configured network. This implies that we do not allocate addresses out of scopes we would use MADCAP for.
- Address allocation is renewed/extended by claiming with a non-zero lifetime
- Any mini-MAAS can claim with a 0 lifetime, and thus deallocate the address, which could have some security consequences
Michael Patton: it isn't "anybody in the session", it is "anybody on the wire" that can do this. Probably we need to allow devices to defend against a deallocation.
Dave Thaler: security requirements are different here. The security is application<->application rather than host<->host. Protocol should allow the allocator to restrict who can extend/renew the lease. Perhaps the initial allocator can create a private key, which it can share (or not) with others. Only hosts with the key can extend or modify the allocation.
Mark Stapp: there is a race in address allocation when there are lots of people trying to allocate an address in trying to create a new session of some sort. What if a fire alarm and smoke detector both power on at the same time and both try to allocate and advertise a 'fire detection' multicast address? Do you get one address allocated or two?
Erik: yes. There is an interaction between session creation and address allocation. Perhaps they must be the same protocol.
Mark Stapp: does the mini-MAAS have persistent state?
Erik: yes, possibly. Good question.
Dave Thaler: if the application is using the address allocation as persistent state, the protocol should reflect that.
Mark Stapp: is there an implied set of state in the applications, what is it, what are the problems?
Erik: a session discovery mechanism is probably required to create a rendezvous between applications sharing an address
- Transition: lets not bother
- changes from AAP
* allocation scope table is wrong: will be fixed
* transition mechanism won't work
* need to discuss interaciton between session management and address allocation. What are the implications for conflict detection and deallocation of addresses.
* is 1 AIU upon allocation enough?
* is AAP incompatibility OK
* should we work on an API
Dave Thaler: an abstract API OK, concrete API NO
(IETF doesn't standardise APIs)
Erik Guttman: concrete API is better, portability might improve
Michael Patton: abstract APIs work fine for me
Rob Austein: see the example in TCP
Michael Patton: how about we do both
Erik: no overwhelming desire to make this a wg item
* document needs to go on a diet
- Erik: we might want to produce a "zeroconf host requirement" document a la the existing "internet host requirements"
Michael Patton: this is a whole lot of work for the people who maintain these documents
Question: would these be a superset, or a subset
Erik: a disjoint set. The zeroconf host would potentially not need a global IP address. A win for interoperability.
Michael Patton: a profile is a good idea (as an RFC)
Remote Access to ZC networks
- slides will be in the minutes
- extruded address vpn:
Bill Woodcock: there are a whole pile of protocols to do this other than ipsec
Dave Thaler: the vpn server is a "bridge", needs to bridge ARP if we are going to use IPv4 LL address allocation
Stuart: eg, vpn server dishes out IPv4LL using ppp to client and defends the address allocation on the clients behalf
Erik: a large organisation wanted to access their appliances in a whole collection of homes run the risk of LL address conflicts between homes
Bill Woodcock: this is the right way to go. But, you can only get one address, which could be a problem if you dialled up and needed a global address as well.
Stuart: addressing scopes (even with IPv6) will need API changes to disambiguate addresses on multihomed hosts with >1 address in the same level scope
Erik: do we really want to all the IPv6 scoping stuff again for IPv4??
Discussion about APIs, binding, address ambiguity, ratholes, ...
Aboba: a draft talking about security considerations for zeroconf networks would be a good idea.
Erik: the other direction (from the device, out to a service) is also important. This could be done with application level signalling (eg over email)
Michael Patton: I buy a box from maytag which sits on my local network and does the interaction.
Aboba: if you have a NAT, you probably can get a private address which can reach the internet, so use that.
Wrap-up, Going Forward
- issue final draft-08 requirements doc
- complete last call for ipv4 ll
- continue ZMAAP or equivalent
- wrap up by August 2001
IPv4 Link-Local Addresses
Zeroconf Requirements Update
Multicast Address Allocation Architecture and Zeroconf
Zeroconf Multicast Address Allocation Protocol
Going Forward - Schedule and Goals