CURRENT_MEETING_REPORT_ Reported by Bob Morgan/Stanford APPLEIP Minutes IP-in-DDP John Veizades led a discussion of his draft RFC for IP-in-DDP. These issues were discussed: o The use of the name ``MacIP'' for this protocol was criticized. People are encouraged to think of a new name. o There was agreement that gateways should never do proxy ARP replies to NBP ARPs. In fact, clients are discouraged from doing NBP ARPs at all unless they have reason to believe that the destination is on the same AppleTalk internet. Clever clients can do NBP ARPs to optimize communication in this admittedly rare case. The user will probably have to specify the zone in which to do the NBP lookup in this case. o Clients must be prepared to get responses from multiple gateways. o The dotted decimal format for IP addresses used in NBP lookups must be better specified. Text might be borrowed from an existing RFC. o Gateways currently send regular NBP confirms to their IP clients to determine whether the IP address is still in use. Gateways should try to minimize the bandwidth used for this, perhaps by only doing confirms when they are running short of IP client addresses. o It was proposed that gateways should be able to be configured with a list of acceptable zones in which to do NBP ARPs. This should help to prevent duplicate IP address assignment, and let gateways and users search the entire ``subnet'' more easily when necessary. o There could be a CEASE ATP message from gateway to client to tell the client to stop using an IP address (useful in case of duplicate assignment). There could also be a REDIRECT message from gateway to client, similar to ICMP redirects. o It was suggested that gateways should have throttles on the rate at which they forward NBP lookups, to prevent clients from flooding internetworks with broadcasts. LBL has a working implementation. Apple suggested that System 7.0 will improve Macintosh client behavior in this area. o The gateway's ATP response to a client ASSIGN request should be able to contain more information. It was proposed to define or redefine some of the response fields. The new format will be distinguished by putting a version number in the first 16 bits of the ATP User Data area. The second 16 bits must be zero. The first version to be defined will be version 1. New field uses: The ``Other #1'' field is redefined to be the subnet mask. The ``Other #2'' field is defined as a time server address. Some implementors are already using some of the ``Other'' fields for their own purposes. They will report on these to the RFC author. 1 o Gateway implementors should report any error codes that they send in ATP responses to the RFC author, who will compile a generic list. o A new ATP REGISTER STATIC request should be defined to allow clients with static IP addresses to register them with the server and get any useful response information. The client will put the static address into the ``Assigned IP address'' field. Gateways should do a sanity check on the address and send an error response if necessary. o Several changes were suggested to the draft RFC. Among them: - Drop references to Macintosh. - Drop AARP definition. - Drop the line ``The IP address used by a gateway with multiple IP addresses is the address that is responded to using the NBP ARP.'' - Hosts do not use ATP XO requests, but ATP ALO. - The line ``There is no response to a RELEASE packet'' should be ``The ATP response to a RELEASE request is empty''. - Drop the suggestion to limit IP-in-DDP datagrams to 576 octets. - Drop Step 3 in the sample transaction stream. MIB A draft MIB, written by Steve Waldbusser of CMU, was distributed. People found it generally acceptable. There was concern that it be clearly labelled as an ``AppleTalk-IP gateway MIB'' and not an ``AppleTalk MIB''. It was noted that there is no AppleTalk-in-PPP MIB. Frank Slaughter from Shiva , who is working on AppleTalk-in-PPP, and Steve Waldbusser will work together on this. It was suggested that the rtmpNextHop variable be extended with a Type string to distinguish between different protocol transports such as IP, DECnet, OSI, etc. AppleTalk-in-UDP Allan Oppenheimer from Apple led a discussion of wide-area networking using AppleTalk encapsulated in UDP/IP. The general idea is to connect existing AppleTalk internets via the IP Internet. There are a number of issues: o Can/should a world-wide AppleTalk Internet be created using the facilities of the existing IP Internet? o How much administration within a site is necessary/acceptable? How much coordination between pairs of sites, or between all sites, is necessary/acceptable? o Is administrative control of routing necessary for security 2 purposes, or is plug-and-play more crucial? o Can the existing DDP-in-UDP encapsulation meet the need, or are changes required? o Can all AppleTalk-based applications be supported? Is a subset such as LaserWriter printing and AppleShare file service acceptable/easier? o Are there solutions to network number scaling and clashes? Are there solutions to zone name scaling and clashes? o Is it important that hosts be able to communicate directly in this internet using the standard encapsulation, or is communication through routers sufficient? Van Jacobson from LBL described a scheme that addresses some of these issues. He has impemented this method on software running on FastPaths at LBL and some other sites. In Jacobson's scheme, each site maintains a table with one entry for each external AppleTalk network with which it wishes to communicate. Each entry in the table contains three fields. The first is the real 16-bit AppleTalk network number of an AppleTalk network at a remote site. The second is a 24-bit IP network number that is associated one-to-one with the previous AppleTalk network number. The third is a 16-bit AppleTalk network number which is used to identify the remote network within the local AppleTalk internet. The first two numbers form a pair that a site can give to any other site with which it wishes to communicate. The table is distributed to some number of routers in the local AppleTalk internet that are running software that understands this scheme. Not all routers in the local internet are required to run this software. When a participating router receives a datagram to be forwarded, it looks up the destination network number in its mapping table. If the number matches an entry (using the third field as described above), the router proceeds to encapsulate the datagram in the standard DDP-in-UDP encapsulation used by KIP and CAP for transmission across the IP Internet. The router forms the destination IP address by using the IP network number from the table entry and the 8-bit DDP node number. The router also inserts the ``real'' AppleTalk network number from the table into the destination network field in the DDP datagram. It then transmits the IP datagram. The datagram proceeds across the IP Internet to a router at the remote site. This router has been advertised as a router for the IP network which is associated with the destination AppleTalk network, so the datagram goes to it. Somehow this router inserts the appropriate AppleTalk network number into the source network part of the DDP header [I DON'T KNOW HOW IT DOES THIS] and forwards the datagram to the destination AppleTalk network through the local internet. 3 This scheme has these advantages: o It uses the existing DDP-in-UDP encapsulation. o In order for two sites to communicate, each site has to manually enter the other's networks of interest into its mapping table. This provides desirable administrative control. o By inspecting source IP addresses, a host using DDP-in-UDP (eg CAP) can communicate directly with another DDP-in-UDP host, without requiring routers, after the first few datagrams. o Each site can have up to 64K (minus the number of internal AppleTalk networks) remote networks with which it can communicate. Since communities of interest will vary, the entire meta-internet can have many more than 64K networks. o There is a working implementation. People thought that Jacobson's scheme was very interesting and deserving of more study. After this discussion, Phil Budne of Shiva volunteered to write a draft RFC describing the current practice of DDP-in-UDP encapsulation. KIP and Phase II Karen Frisa from Novell sent to the Apple-IP mailing list a draft proposal for extending the KIP routing and zone information protocols to handle AppleTalk Phase II. There wasn't time to discuss this proposal at this meeting . Next Meeting John Veizades proposed that this Working Group have another meeting before the December IETF plenary. A time in the vicinity of the October INTEROP conference was suggested. Attendees Philip Budne phil@shiva.com Cyrus Chow cchow@orion.arc.nasa.go Steve Deering deering@pescadero.stanford.edu Robert Elz kre@munnari.oz.au Tom Evans wcc@cup.portal.com Alf Farnham carolf@mcescher.unl.edu Karen Frisa karen@kinetics.com Peter Harrison harrison@miden.ucs.unimelb.edu.au Van Jacobson van@helios.ee.lbl.gov Holly Knight holly@apple.com Sam Lam Olivier Martin martin@cearn.cern.ch Milo Medin medin@nsipo.nasa.gov 4 Robert Morgan morgan@jessica.stanford.edu Rebecca Nitzan nitzan@nsipo.nasa.gov Zbigniew Opalka zopalka@bbn.com Allan Oppenheimer Brad Parker brad@cayman.com Michael Roberts roberts@educom.edu Gregory Vaudreuil gvaudre@nri.reston.va.us Steve Waldbusser sw0l+@andrew.cmu.edu Jonathan Wenocur jhw@shiva.com Steve Willis swillis@wellfleet.com Allan Young rcoay@possum.ecg.rmit.oz.au 5