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?