NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Erik Guttman <erik.guttman@sun.com>
Stuart Cheshire <cheshire@apple.com>
Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>
Thomas Narten <narten@raleigh.ibm.com>
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/
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.
Done |
|
Submit internet-draft to be considered as an Informational RFC on Requirements for Zero Configuration Networking. |
Done |
|
Submit Automatic Address Configuration for IPv4 to be considered as a Standards Track RFC. |
Aug 01 |
|
Submit Multicast Address Allocation Protocol for Zeroconf Networks to be considered as a Standards Track RFC. |
Aug 01 |
|
Submit internet-draft to be considered as an Informational RFC on Host Profile for Zero Configuration Networking. |
· Dynamic Configuration of IPv4 link-local addresses
· Zeroconf Multicast Address Allocation Protocol (ZMAAP)
· An API for the Zeroconf Multicast Address Allocation Protocol (ZMAAP)
Minutes for the ZEROCONF Meeting
3:30pm - 5:30pm, Thursday, 9th August 2001
51st IETF Meeting, London, England, 5th - 10th August 2001
Chairs: Erik Guttman (Erik.Guttman@sun.com)
Stuart Cheshire (Cheshire@apple.com)
Thanks to Aidan Williams for taking notes for these minutes.
By request the previously published agenda was rearranged to move ZMAAP discussion earlier.
Revised Agenda:
1) Agenda discussion & finalization 5 minutes
Stuart and Erik
2) ZMAAP - Status, issues, next? 30 minutes
draft-ietf-zeroconf-zmaap-01.txt
draft-ietf-zeroconf-zmaap-api-00.txt
Erik
GOAL: Settle technical issues. Agree to disposition of the document (standards track or experimental?)
What remains to do before WG last call?
3) Wrap up of requirements doc 5 minutes
draft-ietf-zeroconf-reqts-08.txt
Erik
GOAL: Agree work on this document is complete.
4) Wrap up of IPv4 link-local doc 5 minutes
draft-ietf-zeroconf-ipv4-linklocal-03.txt
Stuart
GOAL: Agree work on this document is complete.
5) Multicast Address Allocation using 10 minutes
IPv4 Link-local Address
draft-hong-autoconf-multicast-ipv4-00.txt
Yong-Geun Hong
GOAL: Determine if this document has contribution to make to continuing effort to standardize mc address allocation in the zeroconf group. If so, come up with a plan.
6) Zeroconf Host Profile 30 minutes
draft-ietf-zeroconf-host-prof-00.txt
Erik
GOAL: Kick off this work. Get as far as we can on it.
Various questions about document structure to answer.
7) Where to - charter discussion 5 minutes
Stuart & Erik
GOAL: Determine whether to take on more work.
8) Operational Zeroconf questions 10 minutes
Peter van der Stok
----------------------------------------------------------------------
2) ZMAAP - Status, issues, next? 30 minutes
draft-ietf-zeroconf-zmaap-01.txt
draft-ietf-zeroconf-zmaap-api-00.txt
GOAL: Settle technical issues. Agree to disposition of the document (standards track or experimental?)
What remains to do before WG last call?
Erik Guttman
- discussion of zmaap requirements
* new requirement: Enumerate supported scopes
(requirement from RFC 2771)
* new requirement: Notification of a conflict
- description of protocol (see draft)
- IPv4 link local multicast address space is scarce, therefore listen to learn of existing allocations
Dave Thaler: This is not required for IPv6 because the address space is not scarce
- Should we prevent races?
- Timely detection of conflict. Two ways:
* poll (not good -- wastes bandwidth)
* advertise (current approach)
There's no general mechanism that would allow you to tell whether an address collision has occurred, in the general case, purely by listening to the multicast traffic. Only the applications involved know what constitutes a collision. For this reason, either
(a) the multicast allocation protocol has to use periodic polling, or
(b) there needs to be an API for the application to inform ZMAAP when the application detects what it deems to be a conflict. No such API currently exists. However, unlike unicast address allocation, multicast address collisions are not disastrous. Robust multicast applications need to be resilient to collisions anyway, so immediate detection of collisions is not essential.
Steve Hanna: There is no mention of advertising in the current (-01) ZMAAP draft
Erik Guttman: There has been discussion on the mailing list of adding periodic messages, to detect conflicts and allow address caches to be built up.
Steve Hanna: Collisions are unlikely to be noticed at the application level, because unless the applications are using the same UDP port number, conflicting packets will be discarded in the kernel before the application sees them. (This is a general problem for multicast, because the existence of UDP port numbers within the packet gives an extra layer of filtering that's outside the control of whatever multicast address allocation protocol is being used).
However, for link-local multicast, perhaps we don't even care that there are undetected conflicts at the multicast address level, if filtering by UDP port number is giving applications behaviour that's adequate for their needs.
Dave Thaler agreed; we can safely ignore conflict detection
Summary: No periodic messages to actively seek out conflicts, but if a conflict is detected when AUIs are sent for other reasons, then that conflict should be dealt with.
- Rather than allocating blocks of addresses, could we simplify the protocol by allocating single addresses instead?
Dave Thaler: Especially on IPv6 where addresses are plentiful, there are applications that want to allocate large ranges and use them sparsely. It is common to allocate a large range where the size is a power of two so and hash within that range.
Summary: No. Some applications need to allocate large contiguous ranges, and the protocol should support that directly.
- Should there be a deterministic tie-breaker algorithm?
Steve Hanna: What's the harm?
Michael Patton: Watch out for DoS
If the tie-breaker is based on highest host IP address, it gives hosts an incentive to always want the highest IP address they can get.
Mark Handley: 3rd party defense is a problem
Even if the tie-breaker algorithm is deterministic, it's not guaranteed to generate the same result everywhere if some hosts do not receive all the packets. Some participants may realize they were forced to choose a new address while other members of the group do not.
Summary: We don't need to do this, if we were going to we would have to be very careful so the tie-breaker algorithm does not encourage bad behaviour.
Take it to the list.
- Session Discovery
Problem: When a single address is desired, and a race happens during formation, multiple groups could be inadvertently created.
Suggestion: Discover duplicate session creations and collapse them into one?
Dave Thaler: How do they know they should be part of the same group?
Erik Guttman: The devices know they are looking for a multicast session with some particular name. When they find no multicast session with that name exists, the device(s) then proceed to allocate a multicast address and give it that name. If a whole network of devices are powered on at the same time, they could all do this simultaneously, resulting in the creation of multiple groups instead of one.
Erik: Suggestions:
Include a minimal session description in AIUs?
Combined allocation/session discovery.
Could define a ZSAP separate protocol.
Steve Hanna: Could Service Location Protocol do this?
Stuart Cheshire: Perhaps. The issue is that the operation of looking up a session name, and creating the session if it doesn't already exist, needs to be an atomic operation.
Steve Hanna: It is the insertion of the session into the "directory" which needs to be atomic.
Stuart Cheshire: Agreed. Furthermore, consider this line of reasoning: If your session naming protocol has the ability to generate conflict indications when the same name appears in the namespace more than once (as it must), then it can also easily have the ability to generate conflict indications when the same multicast address appears more than once. Now you don't need a separate multicast address allocation protocol. Instead of picking a random address and using ZMAAP to test if the address is already in use, you can just pick a random address and try to register it using the session naming protocol, and if that address (or range) is already in use, then your session naming protocol will inform you of the conflict. The end result is that we've combined multicast address allocation and session naming into a single protocol, which I believe is the correct solution.
Erik: Should we enrich the existing ZMAAP proposal to do naming as well?
Dave Thaler: Multicast DNS is a naming protocol which already has the capability to do conflict detection. If you could express the the multicast address allocation in the form of a DNS name, then Multicast DNS solves this problem.
Steve Hanna: Lets do this in an existing protocol, unless we absolutely need something new.
Third comment: Lets try to do this with Multicast DNS if we can.
- API
Erik: The API currently conforms to RFC 2771. Abstract API, plus specific APIs for C and Java
Do we pass on conflict detection? We don't want to burden the network with lots of traffic to support conflict detection if it's not needed.
However, if we do notice a conflict, do we want to have an API where we can inform the application of that fact?
Michael Patton: Yes, we should have that API
Collision is probably going to happen often (in v4 at least)
Stuart Cheshire: Question: Is this notification from the OS to the application a message of the form, "A collision happened, what should we do?", or is it a message of the form, "A collision happened, and your multicast address range has been forcibly revoked." If it is the latter, this may be an aspect of application software that does not get tested very well, just like many applications today that don't cope well if the machine's unicast address changes while they're running.
Erik: The message indicates a forcible revocation
Steve Hanna: There are two issues here:
1. ZMAAP notifies application of detected collision
2. Application notifies ZMAAP of a detected collision
Also, recommending that applications put a magic number at the start of every packet helps detect accidental collisions
Michael Patton: That's just the UDP port number.
Consensus: Include collision detection notification API (both directions)
API document will be advanced to Informational RFC
Michael Patton: If we are expecting to have only 16 link-local IPv4 multicast addresses available for dynamic allocation, we will have to live with collisions. If there are more than 16 applications on the network needing a multicast address, some are going to have to share.
Again, demultiplexing based on UDP port number may be the answer.
Erik: OK, we'll look at this
Dave Thaler: This is once again another good reason to be using IPv6.
Mark Handley: We could perhaps get more IPv4 link-local multicast addresses allocated if we need them
Erik: But there are only 256 IPv4 link-local multicast addresses in total.
Dave Thaler:
1. We can't get a new range allocated for dynamic link-local addresses because existing routers won't filter them, so they won't be link-local.
2. ZMAAP can also allocate global addresses, so it is not as constrained as we might think.
3. Forget v4 and go straight to IPv6
Mark Handley: Agreed, but if we anticipate needing more IPv4 link-local multicast addresses, we should start working on that sooner rather than later
Erik: Lets ask IANA for a block of 16 or 32 addresses out of the existing 224.0.0/24 link-local multicast range.
Dave Thaler: Ask for 128 addresses. They can always say no and give fewer if they choose.
----------------------------------------------------------------------
3) Wrap up of requirements doc 5 minutes
draft-ietf-zeroconf-reqts-08.txt
Erik
GOAL: Agree work on this document is complete.
No disagreements.
----------------------------------------------------------------------
4) Wrap up of IPv4 link-local doc 5 minutes
draft-ietf-zeroconf-ipv4-linklocal-03.txt
Stuart
GOAL: Agree work on this document is complete.
This is in IETF last call.
- Move comments re general checking of uniqueness of IPv4 addrs to a new document
- We have a long list of comments from Keith Moore
* Security (link-local != no security needed)
However, we're not going to move to an all-IP world if we tell USB printer vendors that they're not allowed to make link-local IP printers unless they have IPSEC in them.
* Guideline for max number of hosts?
Protocol should not enforce limit, but document should indicate applicability.
* Self-assignment necessarily implies lower reliability?
Not necessarily. Appletalk uses self-assignment and does not have significant problems with it.
* Keith asserts that link-local packets *will* be routed
But:
Not if TTL checks work, routers are implemented properly
Narten: How does this interoperate with Windows 98 for example? (Windows sends a 128 TTL)
Stuart: The specification should state what we believe is the right thing to do, and implementations should strive to converge towards that. Mac OS didn't send all link-local packets with TTL=255 either, but I thought that TTL=255 was a good suggestion and the right thing to do, so we changed Mac OS and shipped a software update.
Erik: MUST drop =) not backward compatible. Document should perhaps say "SHOULD drop if a host wants to ensure that it's not receiving off-link packets."
Narten: WG consensus needed.
Dave Thaler: Supports TTL=255. Indeed, mDNS draft says the same thing. The draft should say that this check is specifically for devices that care about this aspect of security, not mandatory for all devices. Also, note that default TTL is a configurable option in Windows.
Erik: Note: TTL=255 for mDNS is not without issues itself -- it breaks compatibilty some existing resolvers.
Need to discuss this on the list.
* Keith asserts: Random addresses are no use.
But: they are if you have service discovery or some other name-to-address mapping mechanism.
Does the draft need to state this?
Will discuss this on the list.
* Keith asserts: Current applications don't cope with address changes
But: This varies with operating system. Most Mac OS networking applications do cope with address changes. On other operating systems it is less common for application software to handle address changes properly.
Erik: This is a very interesting issue; one that I have discussed with Patrik Faltstrom. It would be helpful to gather a list of issues emerging from new developments in the Internet Area, and hold a BOF to discuss how these impact the Applications Area.
Stuart: Agreed. The goal of Zeroconf is to make applications work as well as possible without changes; that doesn't mean they can't work better if they are aware of Zeroconf issues.
* Keith points out the problem of synchronized ARPs.
Having a small random delay before the first ARP is a good suggestion.
* Keith questions whether it is in the scope of this document to say: 169.254/16 packets MUST NOT be forwarded.
Narten: This WG appears to have decided that 169.254/16 is link-local, so that is the decision.
Erik: We could create a separate router requirements doc for ZC
Narten: Just make it a separate section under its own heading in the current document.
----------------------------------------------------------------------
5) Multicast Address Allocation using 10 minutes
IPv4 Link-local Address
draft-hong-autoconf-multicast-ipv4-00.txt
Yong-Geun Hong
GOAL: Determine if this document has contribution to make to continuing effort to standardize mc address allocation in the zeroconf group. If so, come up with a plan.
Erik: Please address:
* How this relates to ZMAAP; why do we need two proposals?
[Presentation]
- IPv4: map two lower octets of 169.254/16 -) 239.255/16 to form multicast address
- IPv6: map IPv6 interface ID into IPv6 multicast
Overlaps the TLA/SLA and host portion
- Goal is to radically simplify multicast address allocation protocol
Erik: If an IPv4 host needs more than one multicast address, how does it get one?
Yong-Geun Hong: Applications need to use different UDP port numbers.
Michael Patton: Deja vu, already discussed. Doesn't cope with the requirement to share a multicast address between several hosts. Doesn't support the case where a multicast group persists longer than the life of the host that originated the group.
Dave Thaler:
In IPv4, some applications require more than one multicast address. However, in IPv6, this may have real use, similar to unicast-prefix-based-address assignment.
Mark Handley:
Forcing applications to share group addresses may result in hosts getting swamped with more traffic than they can handle.
Erik:
We want to support more than just link-local networks, eventually. In this case, a host may not have a 169.254/16 address. Also, to run two instances of an application on one host, using that application's well-known port number, would require two multicast addresses. The only way to do that with this proposal is to have two link-local addresses.
Stuart:
The general theme here is that we can trade off reduced complexity (and fewer on-the-wire packets) in the multicast address allocation protocol in exchange for a higher degree of multicast address sharing by applications. Taking this theme to its logical conclusion, we could mandate that all Zeroconf multicast applications use 224.0.0.1. In this case the allocation protocol is trivial (just a hard-coded constant in every host, with no on-the-wire packets at all) in exchange for the most extreme case of sharing, where everything shares one address. We need to decide where on that spectrum we want to be.
Dave Thaler: Suggest you move this to IPNGWG, pursue it.
Erik: This is a proper subset of ZMAAP's functionality. I haven't heard any compelling argument why it is better than ZMAPP.
Yong-Geun Hong: I'll take this up with IPNGWG.
Erik: Is there interest in pursuing this proposal in this WG?
Consensus: No.
Erik thanked Yong-Geun Hong for his work, and encouraged him to pursue it in IPNGWG.
Thaler: Works for a particular scope (e.g. link-local for IPv6) and as such may be a valid zeroconf solution for IPv6.
Stuart: Clarification:
What Erik is saying is NOT that this is a bad proposal. What Erik is saying is that the charter of this working group is primarily to define requirements, and only to define protocols where no adequate protocol already exists, and no other appropriate working group exists to develop the protocol. If this work is appropriate for IPNGWG, then it is NOT appropriate for this working group to take on a protocol that properly belongs in that working group's charter.
----------------------------------------------------------------------
6) Zeroconf Host Profile 30 minutes
draft-ietf-zeroconf-host-prof-00.txt
Erik
GOAL: Kick off this work. Get as far as we can on it.
Various questions about document structure to answer.
-00 draft is currently in the Internet Drafts directory.
-01 revision of document has been submitted and will be available shortly.
What kind of RFC should the "Host Profile" be?
Bob Braden suggests "Applicability Statement" -- in the sense defined in RFC 2026 "The Internet Standards Process".
According to RFC 2026 these can be Standards Track documents.
[Narten: These documents are usually Informational or BCP, not Standards Track.]
- New title: Zero Configuration Host Requirements Applicability Statement
- Document Structure taken from RFC 1122 (Host Requirements)
- Include implementation notes?
- Protocol Requirement Levels:
* v4/v6 address autoconfiguration: Required
* mDNS: Required
* ZMAAP: Elective
* SLPv2 and mDNS + RRs: Recommended
Thaler: mDNS only required for those hosts which participate in name resolution.
Patton: No, mDNS is required. Randomly generated IP addresses are effectively useless without it.
- Try to get agreement on this soon, even if other documents are not finished.
Patton: WG doesn't even have to wait, document can just sit in the RFC editors queue
Narten: Deal with this when we need to. In any case, the WG can't go away until every last RFC in the queue is issued.
Please comment.
----------------------------------------------------------------------
7) Where to - charter discussion 5 minutes
Stuart & Erik
GOAL: Determine whether to take on more work.
Four items:
- Submit Requirements for Zero Configuration Networking to be considered as an Informational RFC. (Done)
- Submit Automatic Address Configuration for IPv4 to be considered as a Standards Track RFC. (Done)
- Submit Multicast Address Allocation Protocol for Zeroconf networks to be considered as a Standards Track RFC. (In progress)
- Submit Host Profile for Zero Configuration Networking as an Informational RFC. (In progress)
The Zeroconf Working group will not tackle the following:
- Zeroconf routers
- Zeroconf edge servers
- Secure remote access
----------------------------------------------------------------------
8) Operational Zeroconf questions 10 minutes
Peter van der Stok
- Home networks
- Devices entering the home might have conflicting names
Want protection from this
- Want mDNS to work at the *same* time as uDNS
- Connection of two ZC networks in homes needs policies?
Issues:
* Multiple dns servers
* Connection/disconnection to ISP
* Concatenation of networks
* Multiple names
* Authority to add/mod/delete?
* ...
Erik: these are mostly related to mDNS
This work is in the dnsext WG.
See draft-guttman-dhc-mdns-enable-00.txt.
Name conflicts could be dealt with by doing service discovery rather than naming..
Establishing specific policy for what is allowed and what is not allowed on the local network is a question of administration, which is by definition not zero configuration
Peter van der Stok: Want to use mDNS at the same time as uDNS
Erik: There is work on this subject already going on
See draft-cheshire-dnsext-multicastdns-00.txt
Patton: The working group has been focussed on protocol details for a while. This may be a good time to revisit some of the larger issues. These should be discussed on the mailing list.
Tony Hain: Applicability statement needs to deal with these issues.
Thaler: mDNS explicitly allows names to be duplicates, when that is appropriate.
Agenda
Operational ZeroConf Issues
ZMAAP Status, Work
IPv4 Link-Local Addresses
Multicast Address Allocation using IPv4 Link-local Address
Zeroconf Host Profile