CURRENT_MEETING_REPORT_ Reported by John Veizades/ Apple Minutes: There was quite a bit of lively debate over the priorities of the working group, but all priorities involve the effective support of Macintosh computers on the Internet. AppleTalk over IP discussion: The issues involving AppleTalk encapsulation over IP networks are these: 1. There's no standard for the existing state of IPTalk. 2. There are several areas where the current state of IPTalk might be improved. The problems with IPTalk derive from the mismatch in pairing the IP/UDP layer with the AppleTalk DDP layer; a better match might be at the level of IP and DDP (i.e. encapsulate AppleTalk DDP packets just above the IP layer, beside UDP). However, this would come at the expense of making changes for every IP implementation in existence, which isn't feasible. There are also problems with the number of UDP ports a MacTCP machine can open, and the number of UDP ports the IPTalk server is required to maintain; an IPTalk machine (such as a UNIX machine running CAP) is required to listen on 256 UDP ports which are mapped to 256 AppleTalk DDP ports, while a MacTCP host can only maintain 64 UDP ports. Therefore, MacTCP machines can't fully interoperate with IPTalk machines. AppleTalk might scale better over large networks if IP is used effectively as a transport. Simplicity versus scale-ability. To what extent does support for large networks require extensive configuration from the maintainer? AppleTalk has always been constructed to be ``plug-and-play,'' but that has introduced some problems with support over larger networks. How well will AppleTalk Phase 2 be supported by IPTalk, if at all? IPTalk routing isn't documented anywhere except within the KIP code itself. Documents describing Ed Moy's work (at UCB) were distributed. Since not everyone attending was familiar with the work, it was agreed to examine it, and follow up with it as a base for further work, since it seems to show considerable promise. Ed Moy's work not only attempts to document the existing state, but to propose a new IPTalk standard. Ed Moy's report can be used as a starting point to address the issue where there is no documentation for the current state of IPTalk 1 networking. It might also be used to address the problems with the current level of IPTalk networking. IP over AppleTalk Networks: John Veizades (veizades@apple.com) presented an outline for a document to standardize the methods by which the IP is conducted over an AppleTalk network. The outline was generally accepted, and several areas were discussed. An optional feature of the IP implementation on each Macintosh might be to send a packet to the IP address assignment agent to shutdown IP service. When a Mac in tosh completes a session and no longer requires an IP address, it may send a request to the gateway to free that address. If the feature is not implemented the address will age out of the asigning agents table of assigned addresses. In discussion of the operation of higher layer protocols, two regimes were addressed: when the locally attached DDP-IP gateway is acting as a IP router, and when it's serving as an IP forwarding agent. If the DDP-IP gateway is serving as a router, it should comply with RFC-1009, the Router Requirements Specification. This would also require that the IP implementaion on all Macintoshes handle ICMP packets (of all varieties). If the locally attached DDP-IP gateway is only forwaring IP packets, then "non-intuitive" things may occur when two IP-forwarders are connected to the same LocalTalk network, and connected to the same IP (sub)network. Proxy-ARP in this case leads to some confusion. It was recommended that there should be no mention of DDP-ARP in the standards document. The AppleTalk MIB: The only reservations raised about the proposed MIB for AppleTalk were that the KIP section of the MIB had to refer to documented standard protocols (i.e. we need to document the KIP routing protocol), and that the buffer section had some FastPath-specific sectionns that might be better addressed in a vendor-specific MIB. In particular, the buffer section of the MIB might be geared more toward a FastPath than to any other product. Leaving information about buffer counts was agreed to be better left to a vendor-specific MIB. Conclusions: Several documents need to be drafted: 1. A specification for IP over AppleTalk (based on John Veizades' outline) 2. A specification for AppleTalk over IP (based on Ed Moy's report) 3. A further revision of the AppleTalk MIB (Steve Waldbusser's, with modifications) 2 ATTENDEES Leo McLaughlin ljm@twg.com Rob Chandhok chandok@cs.cmu.edu+ Bruce Crabill bruce@umdd.umd.edu Peter DiCamillo cmsmaint@brownvm.brown.edu Karen Frisa karen@kinetics.com Kanchei Loa loa@sps.mot.com Tom Holodnik tjh@andrew.cmu.edu Jonathan Wenocur jhw@shiva.com Mike Horowitz mah@shiva.com Frank Slaughter fgs@shiva.com Josh Littlefield jash@cayman.com Brad Parker brad@cayman.com Zbigniew Opalka zopalka@bbn.com Russ Hobby rdhobby@ucdavis.edu Van Jacobson van@helios.ee.lbl.gov Peter Vinsel farcomp!pvc@apple.com Terry Braun tab@kinetics.com Matthew Nocifore matthew@durp.ocs.drexel.edu Milo Medin medin@nsipo.nasa.gov David Kaufamn dek@proteon.com Steven Willis swillis@wellfleet.com Greg Satz satz@cisco.com Zaw-Sing Su zsu@srz.com John Veizades veizades@apple.com 3