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?