Subject: IETF 51 ZEROCONF Minutes

From: Stuart Cheshire <[email-masked]>
Date: Thu, 6 Sep 2001 01:07:32 -0700

The following minutes will be sent to <[email-masked]>

----------------------------------------------------------------------

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 <[email-masked]>
         Stuart Cheshire <[email-masked]>

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.

----------------------------------------------------------------------

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: Peter Johansson <[email-masked]>
Date: Thu, 06 Sep 2001 08:52:39 -0700

>The following minutes will be sent to <[email-masked]>

Please amend the minutes (if you have not already done so) to include the 
attendance list.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Fri, 07 Sep 2001 01:10:10 +0700

Date:        Thu, 06 Sep 2001 08:52:39 -0700
    From:        Peter Johansson <[email-masked]>
    Message-ID:  <[email-masked]>

  | Please amend the minutes (if you have not already done so) to include the 
  | attendance list.

IETF minutes don't include attendance lists - ever.

That info used to be captured by the secretariat from the info
recorded on the famous "blue sheets" and made available in a
separate file.

See ftp://ftp.ietf.org/ietf/dnsind (or any other old working group)

That practice stopped several years ago - probably partly due to the
workload involved (attempting to convert data hand written while sitting
in a chair with nothing to write on into correct names & addresses),
but more importantly, to avoid the lists being used for non IETF purposes
(spam, head hunters, ...)

kre