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