Open Transport Q&A 2.3

Apple
Open Transport
Reference Q & A
New and substantially revised material in this version is

marked by change bars in the left margin.
Version 2.3 (OT 1.1.1 GM release) October 11, 1996

Apple Open Transport Reference Q & A
Updated: October 11, 1996 Page ii

Table of Contents
General Information.........................................................................................1
Key Features and Benefits...........................................................................2
Component Technologies...............................................................................4
AppleTalk Features............................................................................................7
TCP/IP Features...................................................................................................8
System Requirements....................................................................................12
Open Transport and MacOS System 7.5.3.........................................14
Open Transport and MacOS System 7.5.5.........................................20
Availability and Distribution......................................................................21
Network Interface Options...........................................................................25
Network Planning & Administration....................................................25
Applications Compatibility...........................................................................28
Network Compatibility.....................................................................................32
Performance...........................................................................................................36
Open Transport and Servers.....................................................................39
Open Transport and Cross-Platform Issues....................................40
Apple Adoption of Open Transport........................................................40
Developer Adoption..........................................................................................42
Future Directions................................................................................................43
For More Information......................................................................................45
Updated: October 11, 1996 Page iii

Updated: October 11, 1996 Page iv

General Information
Q:
What is Apple Open Transport?
A:
Apple Open Transport is the modern networking and communications subsystem for the Mac™ OS. Open
Transport is based on industry standards and brings a new level of networking connectivity, control, and
interoperability to MacOS systems, while preserving and enhancing the hallmark of the Macintosh and MacOS –
built-in support for easy-to-use networking.
Q:
What long-range Apple goals are advanced through Open Transport?
A:
Apple believes that communications and collaboration technologies are integral and fundamental to personal and
workgroup computing. With Open Transport our goal is to provide the foundation to make MacOS the best
desktop OS for multiprotocol networking, anywhere.
Q:
What needs must be addressed to be “the best”?
A:
Networking and communications technologies are mission critical – thus reliability is a base-level requirement.
Organizations require interoperability in heterogeneous environments; full compliance with standards is
necessary.
High performance is also key. Increasing file sizes – often related to the rich media types found in graphics and
publishing, multimedia, video production, and technical markets – create a demand for effective use of higher
bandwidth communications technologies such as ISDN, FDDI, fast ethernet and ATM.
Beyond these base-level requirements, network managers, end-users and developers each have additional
needs.
• Network managers need networked systems to support a flexible model of administration that
accommodates both centralized and decentralized management models.
• Users are typically more interested in communications as a basis for productivity applications. As such,
they want networking that is easy to set up and easy to use. This becomes even more important when users
are mobile, needing access to networking services from wherever they may be – without requiring complex
reconfiguration for each connection type and location.
• Developers need to address the broadest possible markets with minimum incremental investment. In short,
they need standards based, cross-platform APIs and development tools.
Q:
What were some of the key goals driving the development of Open Transport?
A:
Apple began with two key assumptions: that networking is inherently a multiplatform, multiprotocol proposition;
and that customers should not have to start over to achieve networking interoperability. This led us to adopt five
key design goals:
• Open Transport must protect customer and developer investments in existing network infrastructure and
applications.
• Open Transport must be based on existing cross-platform industry standards.
• Open Transport must provide users with an easy to set-up, easy to use abstraction of the underlying
complexity of multiprotocol networking.
• Open Transport must also provide a complementary abstraction of networking and communications
services for applications developers.
• Open Transport must offer a flexible run time model - one that lets a specific protocol be configured and
selected at run time, rather than linked at compile time.
Updated: October 11, 1996 Page 1

Key Features and Benefits

Q:
How can Open Transport benefit users?
A:
Open Transport provides individual computer users with many benefits. Two of the most immediately visible and
important benefits relate to making networking more accessible - that is, easier to configure and easier to use.
For example, Open Transport makes it easy to switch from one network configuration to another. A computer
user “on the go” might want to hook up to the Internet in various locations, each requiring a different network
configuration. With Open Transport settings for each network location can be stored for easy access and use.
Changed settings are available immediately - no reboot of the computer is required to use the new configuration.
Open Transport also integrates on-line help, based on Apple Guide™ technology, to make it easier for an
individual to hook up to an network, with fewer demands on network manager and support resources.
Q:
How can Open Transport benefit network managers and organizations?
A:
Open Transport provides significant new flexibility in setting up network configurations; with Open Transport, the
network manager can recommend or require configuration settings for users on the network, or allow users to
determine their own settings.
Open Transport also improves support for centralized configuration management. For example, Open
Transport/TCP supports the Dynamic Host Configuration Protocol (DHCP), allowing network managers to
administer addressing and other TCP/IP configuration information from a central server.
Q:
How can Open Transport benefit developers?
A:
Open Transport is designed to make it easier and more cost-effective to develop MacOS-applications for a wide
variety of customers and markets. With Open Transport, MacOS has built-in networking and communications
based on cross-platform industry standards including the POSIX compliant X/Open Transport Interface (XTI),
UNIX STREAMs and Data Link Provider Interface (DLPI).
Applications written to support Open Transport can directly support a wide range of networking environments
(serial, dial-up network, LAN, and WAN), and multiple protocols (AppleTalk, TCP/IP, serial, and others) from a
common code base. This capability is sometimes referred to as transport independence.
Q:
What is transport independence? Why is it important?
A:
Different people judge networking in different ways. End-users focus on what they can do using the network, and
tend to select applications based on functionality and ease of use. Network managers are interested in
delivering reliable network services in a cost efficient manner. Developers want to create compelling
functionality for users, but are strongly influenced by the availability of networking infrastructure.
Unfortunately, with current networking tools and systems developers are forced to tie their applications to
specific network infrastructure requirements - driven by their API choices. This creates a potential conflict
between individual and organizational needs. If network managers restrict protocols to control support costs,
users may not have access to the applications they need. If user require specific applications they may
increase support costs for the network manager by “dragging along” specific network infrastructure
requirements. Developer are stuck in the middle, making decisions for both users and network managers by
selection of an API at compile time.
Transport independence is a concept that breaks this undesirable linkage. When implemented, it allows
developers to write to a uniform set of APIs, users to focus on selecting the best applications, and network
managers to make independent decisions about network infrastructure, all on an ongoing basis.

Q:
What benefits can be realized through use of transport independent applications?
A:
For end-users, transport independence brings an increased freedom to select applications that meet their
needs, without being concerned with the bits and bytes of networking protocols. For network managers,
transport independence allows increased flexibility in designing and controlling infrastructure demands arising
from support of end-user applications, i.e., the freedom to manage the bits and bytes of networking protocols.
Developers who create transport independent applications will find access to broader markets with incremental
resources; code written for the AppleTalk market, for example, can be delivered to TCP/IP markets as well.
Q:
How does Open Transport enable transport independence?
A:
Open Transport brings together four technologies to support the development and deployment of transport
independent applications on MacOS:
• a set of look-and-feel guidelines that promote consistency for configuration of network services across
protocols,
• a unified set of cross-platform, standards based APIs for all networking and communications protocols; for
example, applications can send and receive data over an AppleTalk LAN or the TCP/IP based Internet using
the same programming interfaces,
• a dynamic link-and-load architecture and set of protocols; protocols are loaded and unloaded on demand,
conserving system resources, and making it possible to substitute TCP for ADSP at application launch time
(for example), and
• an addressing and naming support tool box; for example, applications can open a communications end-point
by name (i.e., “seeding.apple.com” or “printer16:LaserWriter@sales”; Open Transport will automatically
provide the appropriate name-to-address mapping services (i.e., DNR, NBP, etc.).
Together these support the creation of transport independent applications on MacOS.
Q:
Are all Open Transport applications transport independent?
A:
No. While Open Transport provides the necessary foundation, there are certain guidelines and programming
practices required for developers to create transport independent applications. For example, most protocols
have many features in common - but also some features that are protocol-specific. If an application depends on
a protocol-specific feature, then it will depend upon that protocol as well.
In some cases it may be appropriate or desirable to develop a transport-specific application. For example, an
MBone client is currently only useful when communicating using TCP/IP.
Q:
Does transport independence imply that an organization can offer “AppleTalk services” without supporting
AppleTalk protocols?
A:
For each service and network environment, protocol and services choices will be determined by a combination of
factors; transport independence is only one of them.
This begins with both the client and the server implementations of the particular service of interest (file, print, e-
mail, directory, security, back-up, calendar, etc.) supporting the Open Transport APIs. Next, both the client and
server must have the protocol stack(s) of choice installed. Finally, the server application must include some
administration utility to allow the network manager to specify the protocol(s) over which application and/or
presentation layer services are to be provided.
The user experience for selecting the server (i.e., “Choosing”, or “name-binding”) may vary depending on the
underlying protocol. For example, AppleTalk offers a distinctive user experience through the “Chooser” and the
underlying NBP/ZIP protocols. TCP/IP offers a substantially different model for name-to-address translation
(DNS); NetWare/IPX still another (NDS).
Apple is committed to evolving MacOS networking services, including but not limited to AppleEvents,
FileSharing, electronic mail, and AppleShare to Open Transport and to transport independent operation.

Q:
In addition to providing for transport independence, how is the Open Transport standards based architecture
important?
A:
Although it might seem that the use and support of standards based APIs is of direct interest only to developers
writing applications code, Apple’s adoption of a fully standards based architecture for networking also has
important benefits for individual users, network managers, and organizations. Some of these include:
• Porting of network protocols, drivers, and applications from other platforms (especially UNIX) to MacOS
becomes easier, resulting in an even wider selection of networking software for the MacOS,
• A larger developer community is focused on STREAMs than would be focused solely on the MacOS, making
it possible to leverage development efforts underway outside Apple – for example, Apple’s demonstration of
IPv6 (next generation TCP/IP) on the Macintosh platform in cooperation with Mentat Inc., and,
• Developers experienced in writing high-performance, high-reliability networking hardware and software for
UNIX systems can apply their expertise directly to the MacOS, accelerating the availability of similar
solutions for MacOS customers.
Component Technologies
Q:
What technology components comprise Open Transport?
A:
Open Transport supports LANs and WANs and will integrate serial communications, modems, and remote (dial-
up) networking in a consistent model for end-users, network managers, and developers. The Open Transport
architecture consists of:
• standards based programming interfaces for applications developers and for network interface controller
developers,
• a new cross-platform development model for integration of networking with the underlying operating system,
• a set of dynamic link-and-load memory management services,
• new implementations of MacOS protocol stacks,
• new human interface applications and control panels, and
• a set of backward-compatibility support modules.
Q:
What current MacOS technologies and components will Open Transport replace?
A:
When installed, Open Transport replaces the current MacOS implementations of AppleTalk and TCP/IP
(including the protocols and the “Network”, “MacTCP”, and “MacTCP Admin” control panels).
Over time, Open Transport is also designed to replace the Connection Manager and the Communications
Resource Manger of the current Communications Toolbox architecture.
Q:
Does that mean that Apple is migrating serial communications away from the Communications Toolbox (CTB)?
A:
Over time, plans call for the CTB Connection Manager and its tools to be phased out in favor of Open Transport.
MacOS 8 is expected to provide support for the Connection Manager APIs, although Apple has no current plans
to port existing Connection Manager tools other than the Serial Tool to MacOS 8. Apple recommends that
developers plan their update to Open Transport/Serial (and away from CTB Connection Manager) to coincide with
(or precede) the availability of MacOS 8.
At this time, there are no plans to replace or eliminate the File Transfer or Terminal Manager services.

Q:
What standards are implemented in the Open Transport architecture?
A:
Open Transport brings standards based networking into MacOS with support for:
• the X/Open Transport Interface (XTI), the POSIX compliant API for support of networking applications,
• the Datalink Provider Interface (DLPI), for development of network interface controller (NIC) drivers, and,
• a port of a UNIX System V release 4.2 compatible STREAMs environment for network protocol developers.
Q:
Did Apple develop the STREAMs environment for Open Transport?
A:
To maximize the stability, performance, and robustness of Open Transport, Apple selected Mentat Inc. – the
leading supplier of high performance kernel-level network software – to supply the STREAMs environment for
Open Transport.
Mentat Portable STREAMs (MPS) is an independent fast, full-featured, multiprocessor safe version of the UNIX
System V Release 4 STREAMs environment. Its incorporation into Open Transport provides a reliable platform
for protocol development, including Apple’s own implementation of a STREAMs based AppleTalk stack. MPS
also allows easy porting from other platforms of third party protocols. MPS is the same implementation of
STREAMs found inside many industry standard UNIX operating systems, including those from IBM and OSF, as
well as other platforms such as Novell NetWare.
Q:
Did Mentat supply other technology to Apple in connection with Open Transport?
A:
Yes. Mentat supplied the source code base for Open Transport/TCP, and has worked closely with Apple on the
development of an archetypal high-performance DLPI driver.
Mentat TCP (MTCP) is a robust implementation of TCP/IP that conforms with all industry standards, and is the
basis of another leading workstation TCP stack. It makes a significant contribution to the performance and
functionality of Open Transport/TCP.
Q:
Is there more information available about Mentat Inc. and its products?
A:
Mentat maintains a presence on the world wide web at:
http://www.mentat.com
Q:
What dynamic link-and-load technology is used by Open Transport?
A:
On 680x0 MacOS systems, Open Transport uses the Apple Shared Library Manager (ASLM) 2.0. On PowerPC
MacOS systems, Open Transport is based on a combination of ASLM (for 680x0 applications) and the newer
Code Fragment Manager, CFM (for PowerPC applications).
Q:
Which protocols are supported by Open Transport?
A:
Open Transport version 1.1.1 includes implementations of AppleTalk and TCP/IP, and consistent API access to
serial communications.
Apple and third parties are investigating or working to add support to Open Transport for Point to Point Protocol
(PPP), NetWare (NCP/IPX), Windows 95 and Windows NT (SMB/TCP/NetBIOS), DECnet and LAT. Some of
these additional capabilities may be incorporated or bundled with future releases of Apple Open Transport (see
Future Directions).

Q:
Are there any changes in AppleTalk or TCP/IP with Open Transport?
A:
Yes. The new Open Transport/AppleTalk and Open Transport/TCP protocol stacks both have been implemented
as Open Transport STREAMs modules and as native code on PowerPC MacOS computers. They support the
new XTI APIs, and their shared libraries can be dynamically loaded and unloaded as needed.
Both protocols also support dynamic reconfiguration (changed settings without requiring reboot), and feature
new configuration applications offering Basic, Advanced, and Administrator tools. The new configuration
applications – AppleTalk and TCP/IP – replace the older control panel implementations – Network, MacTCP, and
AdminTCP. For backward compatibility the new applications continue to be stored in the Control Panels folder.
Each protocol stack also offers addition protocol-specific feature enhancements.
Q:
When should users update their systems to Open Transport?
A:
With the availability of Open Transport v1.1, Apple encourages all MacOS System 7.x users with systems
meeting the minimum configuration requirements to take advantage of the increased performance and new
features provided by System 7.5.3 and Open Transport v1.1 and greater.
Q:
Does this mean that Apple expects everyone to stop using current AppleTalk and MacTCP?
A:
Open Transport is designed to replace current AppleTalk (58.x) and MacTCP (2.0.x) on Apple Macintosh and
MacOS compatible systems meeting minimum configuration requirements. The transition will happen over time,
as developers deliver Open Transport-ready and enhanced applications, as users gain experience with Open
Transport, and as Apple continues to enhance Open Transport.
Open Transport is not designed to run on 68000 or 68020 Macintosh systems, which should stabilize on current
versions of classic AppleTalk and MacTCP software. If Open Transport is installed on these systems, classic
networking will still be selected and loaded at system start-up time.
Developers are strongly encouraged to begin all new development for MacOS using Open Transport.
Q:
What files are installed as a part of Open Transport?
A:
When installed, Open Transport adds the following to the Control Panels Folder:
• AppleTalk - the control panel application replacing the classic Network control panel.
• TCP/IP - the control panel application replacing the classic MacTCP and AdminTCP control panels.
Open Transport adds the following files to the Extensions Folder:
• Shared Library Manager and Shared Library Manager PPC - extensions that implement the Apple Shared
Library Manager for 680x0 and PowerPC, respectively. Both libraries are required for proper operation on
PowerPC MacOS systems.
• OpenTransportLib and Open Transport Library - shared libraries that implement core Open Transport
services on PowerPC systems. The first library contains the modules and APIs for PowerPC native
applications; the second for 680x0 applications running in emulation on PowerPC systems. Both libraries
are required for proper operation on PowerPC MacOS systems.
• OpenTptAppleTalkLib and Open Tpt AppleTalk Library - shared libraries that implement Open Transport
AppleTalk protocols and services on PowerPC systems. The first library contains the modules and APIs for
PowerPC native applications; the second for 680x0 applications running in emulation on PowerPC systems.
Both libraries are required for proper operation on PowerPC MacOS systems.
• OpenTptInternetLib and Open Tpt Internet Library - shared libraries that implement Open Transport TCP/IP
protocols and services on PowerPC MacOS systems. The first library contains the modules and APIs for
PowerPC native applications; the second for 680x0 applications running in emulation on PowerPC systems.
Both libraries are required for proper operation on PowerPC MacOS systems.

• Open Transport 68K Library - shared library that implements core Open Transport on 680x0 systems.
• Open Tpt ATalk 68K Library - shared library that implements Open Transport AppleTalk protocols and
services on 680x0 MacOS systems.
• Open Tpt Inet 68K Library - shared library that implements Open Transport TCP/IP protocols and services
on 680x0 MacOS systems.
Depending on the specific system configuration, the following Extensions also may be installed. These
extensions contain drivers used on Power Macintosh systems with PCI Bus.:
• Ethernet (Built-In) - code resource to allow access to built-in ethernet port.
• Serial (Built-In) - code resource to allow access to built-in serial port.
Open Transport documentation is also provided in electronic format:
• Open Transport Guide Additions - AppleGuide database that updates the Macintosh Guide with information
about Open Transport (System 7.5.3 only);
• a User’s Guide (in Acrobat Reader format) which parallels the printed manual;
• the Open Transport Read Me containing any late-breaking news; and,
• a text file called “Open Transport Technical Info” which contains a distillation of this Q&A.
AppleTalk Features
Q:
What are some of the upgraded features of Open Transport/AppleTalk?
A:
Open Transport/AppleTalk now includes new support for assigned (manually administered) protocol addresses.
This allows AppleTalk nodes to be managed using protocol address as a unique identifier. It also may reduce the
network traffic associated with AppleTalk’s dynamic address assignment features (AARP).
Dynamic addressing continues to be available for those customers who prefer automated address allocation.
Q:
AppleTalk preferences, such as the last used protocol address and the selected network interface, have been
stored in persistent parameter RAM in the past. How does this relate to the new Open Transport network
configurations and manual addressing?
A:
Under the classic AppleTalk networking architecture, AppleTalk’s ON/OFF state, the selected network interface,
the previous network (protocol) address, and the previous AppleTalk zone name were saved in persistent
memory (parameter RAM) for reuse at boot time. To ensure backwards compatibility, this information is still
stored and retrieved on systems using Open Transport/AppleTalk.
However, there are some changes made with Open Transport to accommodate the expanded capabilities of
multiple, saved configuration files, and required network settings.
• At boot time, Open Transport reads the current Open Transport/AppleTalk configuration file to determine if
AppleTalk should be set to ON or OFF. This value will override the value saved in parameter RAM.
• If the network interface specified in the current AppleTalk configuration file is locked (i.e., it is a required
setting) and the specified port is not available or cannot be initialized, AppleTalk will not automatically switch
to LocalTalk; instead AppleTalk will remain OFF. The user will receive notification in the event this occurs.
Q:
What happened to the “Network” control panel?
A:
The Network Control Panel has been replaced by the Open Transport/AppleTalk configuration utility (control
panel). This change was made to reflect the function of the utility - to configure AppleTalk network connections.

Q:
Are there other changes to the human interface for AppleTalk?
A:
Yes. The AppleTalk configuration utility now provides basic troubleshooting information. For example, the
Advanced and Administrator views provide access to the hardware (Media Access Control) address, current
AppleTalk router address and the current AppleTalk network number range for the cable. Previously this
information was only available through the use of router administration or protocol analysis software.
Q:
Are there other changes to AppleTalk of interest?
A:
Yes. Beginning with Open Transport/AppleTalk v1.1, AppleTalk now includes integrated support for both
multinode and multihomed operation, accessible to developers at the API level. Configuration and use of the
second, third, or more network interfaces or protocol addresses requires application program support.
Multihoming is the term applied to the capability to communicate using more than one network interface at a time
using the same protocol. This term is taken from the idea that the workstation makes a “home” on more than one
network at the same time.
Multinode is the term applied to the capability to communicate through more than one network protocol address
at the same time on a given network interface, using a single protocol. This term is taken from the idea that the
workstation or PC appears to outside parties to be multiple end-nodes on the network.
Q:
Earlier information about Open Transport said that AppleTalk could be dynamically loaded and unloaded only as
needed, similar to Open Transport/TCP. Is this feature available?
A:
This capability has been removed from Open Transport at this time. It was not technically feasible to provide this
feature without creating undesirable compatibility problems with existing applications.
Q:
Is Open Transport/AppleTalk “AppleTalk Phase 3”?
A:
No. Open Transport/AppleTalk is a new, modern implementation of the AppleTalk Phase 2 protocol architecture
for MacOS – from the people who invented AppleTalk.
TCP/IP Features
Q:
What are some of the features of Open Transport/TCP?
A:
With the broad cross-platform adoption of TCP/IP – and the tremendous visibility of the Internet – Apple has
made a significant investment in bringing a workstation-class implementation of TCP/IP protocols to MacOS. As
with Apple's earlier MacTCP, Open Transport/TCP is a full 32-bit stack.
Open Transport/TCP adds support for:
• dynamic path MTU discovery, for more efficient network use in heterogeneous network topologies;
• Dynamic Host Configuration Protocol (DHCP), for centralized IP address configuration management. DHCP
is an Internet Engineering Task Force (IETF) standards-track protocol;
• IP multicast, for participation as an MBone client;
• simultaneous TCP connections limited only by installed memory and processor power, for increased
functionality as a Internet or other TCP/IP network server;
• a new, more robust and standards-compliant domain name resolver (a caching stub DNR);

• support for RFC 1123 and RFC 793 TCP Urgent Pointer semantics;
• support for developer access to raw IP services, as well as TCP and UDP;
• ethernet version 2 and IEEE 802.3 framing, for better interoperability with a wider range of TCP/IP hosts;
• implicit and explicit domain name search paths, for increased control of domain name resolution; and,
• multiple IP routers with fail-over, for increased robustness in mission critical applications.
Q:
How does the new support for Dynamic Path MTU discovery work?
A:
Open Transport/TCP sets the “don’t fragment” bit in the IP datagram header on transmission unless the packet
size is larger than the MTU for the network. Intermediate routers are required by current RFCs to send back an
“ICMP can't fragment” error when presented with a “don’t fragment” packet that cannot be forwarded without
fragmentation with that MTU size. In that event, Open Transport/TCP moves to the next smaller MTU size for that
path and re-sends the packet, again with the “don’t fragment” bit set. This process automatically results in using
the largest supported MTU size for off-subnet traffic.
Q:
How does the Open Transport/TCP domain name resolver (DNR) work?
A:
The Open Transport/TCP DNR implements name-to-address (A), address-to-name (PTR), system CPU and OS
(HINFO), and mail exchange (MX) queries. It does not implement negative caching, but depends on a local full
service resolver to provide this facility. The DNR will always request recursion, but will follow references if
recursion is not available.
The DNR caches name-to-address and cname-to-name mappings; this feature cannot be disabled. However,
conforming to DNS practice, a reply that includes a Time to Live (TTL) of zero will result in a mapping that is used
only once - it will not be cached and not be reused. (TTL values for DNS entries are configured by the
administrator of the DNS server.) Unlike the older MacTCP DNR implementation, which has a cache limited to a
maximum of nine entries, the Open Transport DNR is dynamically-sized with no hard limit; it expands as needed,
limited only by the available system RAM.
The DNR does not cache host info (OS and CPU type information) nor does it cache Mail Exchange/Preference
information. It does not save name server references after a query is resolved; further queries begin anew at the
configured name servers.
Fully qualified domains names or FQDNs (those ending with a “.”), and provisional FQDNs (those containing at
least one “.” internally but not ending with “.”) are submitted for resolution without manipulation. Otherwise the
name is assumed to be a partially qualified domain (PQDN).
The first - but optional - step in PQDN resolution is the use of an Implicit Search Path. To be used, Implicit Search
must first be configured using the Advanced or Administrator view by entering values in the “Implicit Search
Path: Starting Domain Name” and “Ending Domain Name” fields. When so configured the DNR will attempt to
change the PQDN to a FQDN for resolution by concatenating the PQDN with domain names in the ancestor
hierarchy delimited by the Starting and Ending Domain Name values (i.e., searching for a PQDN of joe could
result in a search for joe.hdware.support.apple.com, joe.support.apple.com and joe.apple.com).
Implicit searching stops when the FQDN is resolved, or when the Ending Domain Name value has been tried and
fails (i.e., joe.com would not be tried, assuming an Ending Domain Name value of apple.com).
If the PQDN has not yet been resolved (including the case where an Implicit Search Path was not configured),
explicit Additional Search Domains are searched. For each Search Domain configured, name server(s) are
contacted in the order specified in the Name Servers field. If the name is resolved in the first search domain from
which an answer is returned other Search Domains will not be checked. Note that at least one Search Domain
(roughly equivalent to MacTCP's Default Domain) must be explicitly configured in order to resolve any PQDNs.
If an authoritative answer that the “name-does-not-exist” is returned, the DNR immediately begins the search in
the next configured Search Domain. The search continues through the configured Search Domains.
The DNR has an overall time-out of 2 minutes, after which it will abandon the search.

Q:
Does Open Transport/TCP support a local HOSTS file?
A:
Open Transport/TCP supports one or more HOSTS file, stored in the System Preferences folder, that may be
used to supplement and/or customize the domain name resolver's initial cache of information. The selected file is
opened and parsed when Open Transport/TCP is initialized. As with MacTCP, the supported HOSTS file features
follow a subset of the Domain Name System Master File Format (RFC 1035).
Supported features include blank lines, comments (indicated by a semicolon), and data entry. Comments may
begin at any location in a line; they may follow data entry on the same line. A comment extends from the
semicolon to the end of the line. Data entry must follow the format:
<domain-name> <rr> [<comment>]
where <domain-name> is an absolute or Fully Qualified Domain Name, and where
<rr> = [<ttl>] [<class>] <type> <rdata> OR [<class>] [<ttl>] <type> <rdata>
The only <class> currently supported is IN (Internet Domain); <ttl> , time to live, indicates the record’s
configured lifetime in seconds; and <type> can be A (host address), CNAME (canonical name of an alias), or NS
(name server). If <ttl> is not present the entry is assumed to have an infinite lifetime; this may also be indicated
by specifying a value of minus-one (-1). $INCLUDE and $ORIGIN are not supported.
Open Transport/TCP is more stringent regarding the content and format of the HOSTS file than was MacTCP,
which permitted violation of the FQDN requirement for <domain-name>. For instance, this format:
charlie A 128.1.1.1
which was acceptable to the MacTCP DNR, is no longer permitted because of the use of domain search lists in
Open Transport/TCP (charlie could potentially exist in any or all of the configured domains). To accomplish the
same effect, use this format instead:
charlie CNAME myhost.mydomain.edu
myhost.mydomain.edu A 128.1.1.1
This associates the local alias charlie with the fully qualified domain name myhost.mydomain.edu, and
resolves it to the address 128.1.1.1. Use of local aliases is limited to CNAME entries; NS and A entries must use
fully qualified domain names.
If a HOSTS file is used, every effort should be made to keep it as small as possible and to only include entries
that will be accessed frequently. This reduces the total memory footprint required to cache the DNS information
and minimizes the need to maintain and update the HOSTS files as system information changes over time.
In order to activate a HOSTS file, the Advanced or Administrator mode must be used to select the desired file.
The text file must already exist; it could have been created with any text editor or word processor.
The HOSTS file is tied to the selected configuration. An administrator might, for example, specify different
HOSTS files for use when connecting via ethernet to the campus LAN and when dialing-in from a remote location.
Thus, each OT/TCP configuration must individually specify a HOSTS file - even if the same one is to be used with
each configuration.
Q:
What are some of the changes to the human interface for Open Transport/TCP?
A:
The Open Transport/TCP configuration application represents a complete overhaul of the human interface from
the MacTCP software it replaces. In addition to generic new features noted elsewhere (multiple saved
configurations, recommended and required settings, on-line documentation, etc.), key new features include:
• direct entry of IP addresses and subnet mask in standard “dot notation”;
• explicit selection of desired configuration method, now including Manual, RARP, BootP, MacIP, and DHCP;
• support for attachment to networks using Classless InterDomain Routing (CIDR);
• support for multiple entries in the router, name server, and explicit domain search lists; and
• improved support for large AppleTalk networks when using MacIP server/gateways.

Q:
Does Open Transport/TCP support MacTCP “Server” addressing?
A:
MacTCP Server mode addressing is a combination of the Bootstrap Protocol (BootP) and Reverse Address
Resolution Protocol (RARP) configuration methods. When Server mode is selected, MacTCP will use BootP to
attempt to acquire an IP address. If BootP fails to provide a valid address it then tries RARP. Whichever protocol
is successful is stored as a preference, and is used first on next system startup. While this “fall-back” approach
adds a degree of robustness from the users point of view, it also adds a degree of unpredictability from a network
administrators point of view.
Based on customer feedback, Open Transport/TCP has been designed to allow a network administrator to
explicitly specify the single method they prefer to use. Thus while both RARP and BootP are individually
supported, Server mode does not appear as a choice in the Open Transport/TCP configuration utility.
Q:
Does Open Transport/TCP support MacTCP “Dynamic” addressing?
A:
No. MacTCP “Dynamic” mode addressing was based on an Apple-proprietary extension to TCP/IP protocols,
which applied the address negotiation and assignment rules used by the AppleTalk protocols to TCP/IP
networks. This made it very easy to set-up a MacOS only TCP/IP network, but could create additional work for a
network administrator in more typical heterogeneous TCP/IP networks.
The Internet community (the IETF) has since developed a multivendor standard for the dynamic assignment of IP
addresses, known as Dynamic Host Configuration Protocol (DHCP). Apple has adopted the industry standard
DHCP and dropped support for the earlier Apple “Dynamic” mode addressing with Open Transport/TCP.
Q:
What is MacIP?
A:
MacIP, sometimes also referred to as KIP (Kinetics Internet Protocol), is a protocol specification developed as a
method for carrying TCP/IP traffic on AppleTalk only networks – originally these would have been LocalTalk
networks. MacIP is today frequently used in conjunction with AppleTalk Remote Access Protocol (ARAP) to
provide mobile users access to TCP/IP network services. MacIP specifies encapsulation of TCP/IP datagrams
in AppleTalk packets for transmission over such connections.
Use of MacIP requires a gateway. AppleTalk encapsulated IP packets are sent to the gateway using AppleTalk
protocols (DDP). The gateway strips off the encapsulation and places the IP packet on the TCP/IP LAN. When
packets are destined for a MacIP end-node, the gateway provides the needed encapsulation services.
MacIP gateway support is most frequently offered as an integrated service within a multiprotocol router. The
gateway (router) attaches to both an AppleTalk and a TCP/IP network, acting as a middleman between the MacIP
end-node and the appropriate TCP/IP based hosts on the LAN or WAN.
Open Transport supports MacIP end-nodes. It is selected using the TCP/IP configuration utility by choosing
“AppleTalk (MacIP)” in the “Connect via:” pop-up menu. The user (or network administrator) must also specify
which zone contains the desired MacIP gateway. Once selected, TCP/IP will be encapsulated in AppleTalk and
will be sent to the gateway via the NIC selected using the AppleTalk configuration utility.
Q:
How is MacIP support improved with Open Transport/TCP?
A:
Open Transport/TCP offers new features in the human interface for selecting the MacIP server, including:
• AppleTalk zones are now displayed in a scrolling list in a movable window. This display is easier to view
compared to MacTCP’s pop-up menu, especially when there are a large number of zones in the network.
• The Zone list window now supports selection using the mouse, the arrow keys, and/or “type-select”, allowing
the user to more quickly select a specific zone from the list.
• There is an option to display only those AppleTalk zones containing MacIP servers. When selected, this
creates a background search task which when completed filters the zone list display to show only those
zones containing active MacIP servers.

• There is a short cut “Current Zone” option which causes the Mac to check the current AppleTalk zone for a
MacIP server without requiring the user to select a specific zone. This can be a time-saver for the user and a
potential bandwidth-saver on the network, especially when there are mobile users that connect in different
locations to a enterprise-wide network for MacIP services.
System Requirements
Q:
Which MacOS systems can take advantage of Open Transport?
A:
Open Transport is designed to work on portable and desktop Apple Macintosh or MacOS compatible computers
with a Motorola 68030 or 68040 family microprocessor, or a PowerPC 601, 603(e), or 604 microprocessor.
Apple recommends running MacOS System 7.5.3 with Open Transport, although the earlier System 7.1, 7.1.1
and 7.1.2 releases are also compatible. System 7.5.3 requires a minimum of 4 MB (680x0) or 8 MB (PowerPC)
total memory; Open Transport requires a minimum of 5 MB (680x0) or 8 MB (PowerPC).
Systems running Open Transport may be able to benefit from larger than minimum memory configurations when
using FDDI or ATM, as these datalinks can provide increased performance by taking advantage of larger
datagrams and buffer sizes. Effective use of additional system RAM for buffers is application dependent.
Q:
How do settings such as Virtual Memory and RAM disk affect Open Transport's minimum memory requirements.
A:
Open Transport minimum memory requirements are based on total system memory including VM, less the size of
any RAM disk and Disk Cache defined.
Q:
How is the Memory Available as reported by the “About this Macintosh…” dialog related to Open Transport’s
actual memory requirements.
A:
The “About this Macintosh…” dialog reports on both the total free memory and the largest block of contiguous
free memory. In practice, the latter figure is a better indicator of whether an additional application can be
launched.
If a user repeatedly opens (launches) and closes (quits) multiple applications that use Internet networking
services, and if the user has set Open Transport TCP/IP preferences to load networking services only when
needed, this can, over time, result in a situation where Open Transport loads into memory “between” other
running applications. This “memory fragmentation”, in turn, can result in a smaller value reported by “About this
Macintosh…” for free contiguous memory. In extreme cases, this could limit the number of concurrent
applications that a user could run.
If this situation arises, Apple recommends use of the Advanced Mode of the TCP/IP Control Panel to access the
Options dialog; remove the “X” in the “Load only when needed” option. After restarting the system, Open
Transport TCP/IP will load when called on by an application for the first time, but will then remain loaded. This will
help avoid memory fragmentation.
Open Transport 1.1.1 includes some additional internal changes designed to reduce the frequency and
significance of memory fragmentation due to the dynamic loading and unloading of TCP/IP. Depending on the
pattern of use, however, it may still be desirable to disable the "load only when needed" option as discussed
above.
Q:
Does Open Transport require more system RAM than classic networking? If so, how much more, and why?
A:
Open Transport provides many new features and capabilities to MacOS customers and, in general, will require
more system memory (RAM) than does classic networking. However, the actual memory requirements of Open
Transport are dynamic; they vary depending upon the networking services in use at a given time. This is different
from classic networking, which allocates memory to networking services and keeps it allocated even after
networking services are no longer in use.

Factors which contribute to differences in memory requirements include:

• Open Transport provides implementations of networking as both 680x0 and native PowerPC code; RISC
code is typically larger - but also faster - than CISC programming,
• Open Transport provides “mixed-mode” applications support, making it possible for both PowerPC native
and 680x0 applications to use native networking on PowerPC MacOS systems,
• Open Transport includes both the new implementations of networking and the libraries required to provide
backward compatibility support for the older AppleTalk and MacTCP programming interfaces,
• Open Transport is fully Virtual Memory (VM) aware, and as a result has a lower memory footprint on systems
with virtual memory enabled; classic network has about the same footprint regardless of the VM setting,
• Open Transport is based on the cross-platform standard STREAMs environment, which increases the total
size of the implementation as compared to the proprietary classic networking implementation, and,
• To lay the groundwork for the MacOS 8 protected memory model, Open Transport allocates memory for
TCP/IP applications in the system area; MacTCP allocated memory in each application.
Thus the difference in memory requirements will depend upon which configurations are measured. Some
examples of base memory requirements include:
• On a PowerPC system with VM on, classic AppleTalk and MacTCP require about 350-450K; Open Transport
will require about 200K to load; i.e., Open Transport base memory requirements are about 200K smaller.
• On a 680x0 system with VM off, classic AppleTalk and MacTCP require about 350-450K total system
memory; Open Transport will require about 700-800K to load; i.e., Open Transport is about 350K larger.
• On a PowerPC system with VM off, classic AppleTalk and MacTCP require about 350-450K; Open Transport
can require up to 1.2 MB to load, i.e., Open Transport is about 800K larger.
Q:
Why does Apple recommend System 7.5.3 (System 7.5 Update 2.0) or later? What about System 7.5, 7.5.1, and
7.5.2?
A:
Open Transport internal and external testing included work with all MacOS system software releases from
System 7.1 forward, however, Apple’s testing was most concentrated on System 7.1.x , System 7.5.3 and
System 7.5.5.
In moving from earlier versions of System 7.5 to System 7.5.3 or later a user’s system will benefit from a number
of updates and bug fixes that -- while not a part of Open Transport -- can improve system performance and
reliability on the network for a variety of tasks, including printing and file transfers. The combination of the
deeper test coverage and the important system updates that are a part of the system software update leads the
Open Transport team to overall recommend System 7.5.3 or later.
System 7.1.x users are encouraged to evaluate their needs and to consider updating to System 7.5.3 or later.
Q:
Was Open Transport 1.1 released in Japan for System 7.5.2? If so, why isn't this generally recommended?
A:
Apple did not provide Kanji localized versions of Open Transport 1.0.8; thus, Kanji customers with PCI MacOS
systems had not been able to benefit from the fixes released in OT 1.0.8. Because of the lead times required to
localize System 7.5.3 for Kanji, Apple elected to complete the localization and testing of Open Transport 1.1
independently of plans to localize System 7.5.3-J.
This decision resulted in delivery of Open Transport 1.1-J for System 7.5.2-J customers. This is a regional
exception to Apple's overall recommendation to use Open Transport 1.1 in combination with System 7.5.3.
KanjiTalk 7.5.3 is now available, Apple recommends that all KanjiTalk 7.5.2 customers update to 7.5.3.
Q:
Why didn't Open Transport 1.1 support Power Macintosh 5200/5300/6200/6300 desktop computers?
A:
Very late in the final quality assurance cycle of Open Transport 1.1, the OT team was notified of a reproducible
crash affecting some, but not all, customers with Power Macintosh or Performa 5200/5300/6200/6300 desktop
computers.

Rather than delay the release of OT 1.1 and System Update 2.0 (System 7.5.3) further - which both brought
many significant improvements to MacOS customers - the Performa, Open Transport, and System 7.5.3 teams
working together decided that the best alternative was to disable OT 1.1 on these systems until the problem(s)
were fully identified and an appropriate solution could be implemented and tested.
After additional research, this problem was isolated as a hardware issue. In response, Apple announced an
Repair Extension program.
Open Transport 1.1.1 - which includes Apple Shared Library Manager 2.0.1 - (re-)enables Open Transport on
these previously restricted MacOS systems. The OT 1.1.1 installer now includes a hardware test that runs at
install time and will not install on a system affected by the hardware problem. OT 1.1.1 now also includes a
hardware test that runs at boot time. If OT is called for on a system affected by the hardware problem, a new
dialog alerts the user that classic networking is being substituted, and directs them to consult their Apple
service provider for hardware service.
Q:
What models are included in the Repair Extension program; that is, which models require Open Transport 1.1.1 to
take advantage of Open Transport?
A:
The models included are:
• Power Macintosh 5200/75 LC, 5300/100 LC
• Macintosh Performa 5200, 5215, 5300
• Macintosh Performa 6200, 6205, 6214, 6216, 6218, 6220, 6230, 6290, 6300
Q:
What is the nature of the hardware issue that led to the original decision to disable Open Transport on these
systems?
A:
These systems might experience a system freeze upon start-up. The system freeze may be caused by known
component problems on the logic board. The Repair Extension program includes replacing the logic board, as
appropriate, to correct the system freezes.
Open Transport and MacOS System 7.5.3

Q:
After installing System Update 2.0 (System 7.5.3) I've noticed that the ethernet address of a system has
changed from 00:A0:40:xx:xx:xx to 00:05:02:xx:xx:xx. Why? Is this due to Open Transport?
A:
Apple was initially assigned ethernet MAC (Media Access Control) addresses of 00:08:07:xx:xx:xx. Apple
NuBus and on-board ethernet implementations from 1989 through part of 1995 were given addresses from this
range. In 1995, however, Apple began to reach the end of the available addresses in that range, and petitioned
the IEEE for an additional vendor code (address range) assignment. We were granted 00:A0:40. Apple began
using these new addresses ( 00:A0:40:xx:xx:xx) in some of our ethernet implementations mid-year 1995.
MAC addresses are typically stored in an EPROM (erasable programmable read-only memory) on the ethernet
chip set, in "token ring format". This format has each byte stored in bit-reversed order. For example:
Ethernet format (hex): 00 A0 40
Binary equivalent: 0000 0000 1010 0000 0100 0000
Token ring format (hex): 00 05 02
Binary equivalent: 0000 0000 0000 0101 0000 0010
Some Macintosh systems - the Power Macintosh 7200, 7500, 8500, and 9500 - and some Apple NuBus Ethernet
cards had their MAC address unintentionally stored in ethernet format; not in the standard token ring format.
That is, rather than storing the address as 00:05:02:xx:xx:xx and then converting to yield the assigned
address range of 00:A0:40:xx:xx:xx, the addresses were stored as 00:A0:40:xx:xx:xx and would convert
to 00:05:02:xx:xx:xx on the wire.

At the same time, however, there was also a bug in the Open Firmware code for these same systems that caused
them to NOT convert the address stored in the EPROM. The result was that the intended MAC addresses
(00:A0:40:xx:xx:xx) were being used on the wire by these ethernet implementations, even though they were
not stored in the correct format. (A rare case of "two wrongs do make a right".)
MacOS network utilities also access the EPROM to read MAC addresses, however, and correctly assume the
token ring format. Thus they convert stored addresses at the application layer before presentation to the user.
When running on one of the affected systems, such a utility would report an address of 00:05:02:xx:xx:xx,
even though a network analyzer packet trace would show an address in the range 00:A0:40.
Because the Open Firmware bug did not apply to Apple NuBus Ethernet cards with MAC addresses in the new
range (Open Firmware is a PCI specific technology), the MAC addresses WERE converted from
00:A0:40:xx:xx:xx to 00:05:02:xx:xx:xx, resulting in the use of unauthorized addresses on the wire.
Fortunately, the 00:05:02 range was still unassigned, and these cards did not create interoperability problems.
Upon original discovery of this situation, Apple quickly petitioned the IEEE and was granted the 00:05:02 range.
This was in addition to the already approved 00:08:07 and 00:A0:40 ranges.
System Update 2.0 (System 7.5.3) includes a fix for the Open Firmware bug that impacted the Power Macintosh
7200, 7500, 8500, and 9500 systems. Once updated to MacOS System 7.5.3, these systems will now convert
their address before use, and as a result appear as 00:05:02:xx.xx.xx on the wire. This change impacted a
Open Firmware component, and was not a part of Open Transport v1.1.
Note that because Apple has been granted use of the 00:05:02 range, these PCI MacOS systems now have
properly stored and communicated addresses. This change brings consistency to the behavior of all Apple on-
board and NuBus ethernet implementations, and allows Apple and third party network management utilities to
correctly read and report these addresses to users without requiring new versions of utility software.
These changes were necessary to assure ongoing standards compliance, and to remedy the compatibility
issues with network management utilities. However, they may impact networks including the Apple ethernet
implementations noted above. Specifically, any network access and configuration services which depend upon
statically configured MAC addresses will require reconfiguration by the network administrator once System 7.5.3
is introduced into the environment. Such services can include BootP, DHCP, RARP, certain firewall and security
products, some routing Access Control Lists, and smart ethernet hubs incorporating MAC-level security.
The 00:A0:40 address range is now reserved for future Apple expansion, at such time as the 00:08:07 and
00:05:02 ranges are exhausted.
This situation did not effect Power Macintosh 7200, 7500, 8500, and 9500 systems or other Apple ethernet
implementations with physical Ethernet addresses in the original 00:08:07 range.
Q:
Does System 7.5.3 require the use of Open Transport?
A:
System 7.5.3 supports and includes both classic and Open Transport networking.
Doing an Easy Install of System 7.5.3 on an 68030, 68040, or NuBus PowerPC MacOS system installs Open
Transport v1.1 and classic networking. Easy Install on a 68000 or 68020 Macintosh will install only classic
networking. Easy Install on PCI MacOS systems will install only Open Transport.
Q:
Why does System 7.5.3 include both classic and Open Transport networking?
A:
System 7.5.3 includes both classic and Open Transport networking to support a Universal System Folder, which
could provide networking services for any MacOS system, from the Mac Classic to the most powerful PowerPC.
Q:
Since both Open Transport and classic networking are included with System 7.5.3, which network software will
actually be used?
A:
The networking software used by System 7.5.3 depends upon four factors:

• the configuration of the system where 7.5.3 was installed;

• an initial stored preference, established at system software installation time;
• the configuration of the system currently being booted, which might be the same as or different from the
system where 7.5.3 was installed; and
• the user’s change to the stored preference, if any.
Together these factors determine the networking software system loaded at system startup (boot) time:
• Classic networking will load and run when booting System 7.5.3 on a 68000 or 68020 Macintosh, even if
Open Transport is also installed;
• Open Transport will load and run when booting System 7.5.3 on PCI MacOS systems meeting Open
Transport minimum memory requirements, even if classic networking is also installed;
• Both classic and Open Transport options are available on 68030, 68040 and NuBus PowerPC MacOS
systems meeting Open Transport minimum memory requirements. The networking software used at boot
time is selected based upon the stored preference.
When System 7.5.3 is Easy Installed on these machines, the initial preference is to load and run classic
networking. Open Transport can be enabled using the Network Software Selector utility, discussed below.
If Open Transport is Custom Installed from the System Update 2.0, or installed using the stand-alone Open
Transport installer, the initial preference is to load and run Open Transport networking. Classic networking
can be enabled using the Network Software Selector utility.
• Classic networking will load and run when booting MacOS systems with less than 5 MB (680x0) or 8 MB
(PowerPC) total system memory.
If this constrained-memory situation occurs on a 68030, 68040, or NuBus MacOS system, classic
networking will load and run, with full support for AppleTalk and MacTCP.
If this constrained-memory situation occurs on a PCI MacOS system - perhaps due to the definition of a
large RAM disk - classic networking will become available, but will be limited to support only for AppleTalk on
LocalTalk; no TCP/IP services will be available.
Q:
What happens if a boot device is moved to a different system after the preference has been established?
A:
The stored preference for network software will be honored, if possible, at each and every boot time. If the
system configuration being booted meets the minimum requirements for the preferred network software, it will
load and run. If the stored preference has been deleted, or is not appropriate for the system being booted, the
rules noted above around minimum and recommended memory size, processor, and bus type determine which
network software system loads.
Q:
Why is the network software preference initially set during system installation time?
A:
As described above, a number of system configuration checks are made at boot time - including processor, bus
type, and system RAM - and influence the choice of network software when booting a Universal System Folder.
On MacOS systems that support both networking software systems, however, an initial preference is
established based on system configuration at installation time. For the majority of users, this system (the
installation system) is the same one as where the System Folder being created will be used. In these cases, the
update / installation script establishes a preference based on the recommended memory configuration (vs. the
minimum required memory, which is still always tested at boot time).
There are two reasons for doing this in this manner:
• Testing for minimum memory requirements at system start-up time assures a compatible hardware-software
combination each time a system is booted. If a system configuration changes to fall below Open Transport's
minimum memory requirements - which might happen due to reconfiguration, or by moving an external boot
device to a different system - System 7.5.3 automatically drops back to classic networking to provide basic
connectivity to the outside world.

• When there is no stored preference, System 7.5.3 selects between classic and Open Transport networking
based on the system configurations described above. As this check is based on total memory (including VM
but less RAM disk), in the absence of a preference, a seemingly unrelated user action such as turning VM
on or off could change the network system used at (next) boot time. For example, enabling VM on an 8 MB
system would provide at least 9 MB RAM at next startup, moving the system from classic to Open Transport
“unexpectedly”; turning on a RAM Disk could cause another reversal. Thus, setting an initial preference
“locks in” a predictable behavior.
Q:
How can a user specify a preference for a specific network software system, overriding the system installation
preference?
A:
Apple has developed a utility called the “Network Software Selector” (NSS), which allows a user to indicate a
preference for classic or Open Transport networking. Network Software Selector is distributed as a part of
System Update 2.0, and in other System 7.5.3 configurations - it is located in the Apple Extras Folder.
NSS may not be supplied in all configurations of System 7.5.3; for example, PCI MacOS systems manufactured
with System 7.5.3 will not have the Network Software Selector utility included, because these systems require
Open Transport.
To indicate a preference, the user launches NSS and clicks the radio-button control indicating either classic or
Open Transport networking. After quitting NSS, the system must be re-started for the preference to have a
change to take effect.
Q:
Does the Network Software Selector allow a user to specify a preference for a networking system that is “not
valid” for the current system configuration?
A:
Yes, with the Network Software Selector it is possible to set a preference for classic networking while currently
booted on a PCI MacOS system, or to set a preference for Open Transport while booted on a 68000 or 68020
Macintosh. This is designed to allow an administrator to prepare an external boot device with an Universal
System Folder that has a configuration different than their own machine.
The Network Software Selector indicates a user preference ; the actual network software loaded is determined
when the system is booted. If a preference for Open Transport is set but the device is a 68000 or 68020, classic
networking would load, ignoring the preference. If that boot volume is moved to a Power Macintosh 9500, Open
Transport would load, as this PCI system requires Open Transport. Move the boot volume to a Quadra 800 and
restart; Open Transport would load based on the stored preference.
Q;
Can the stored preference be deleted? Why might this be a useful action?
A:
The preference for network software system is stored as a part of the AppleTalk Prefs file, kept in the System
Folder. Deleting this file will also delete the stored preference.
In some support environments it may be useful to create a Universal System Folder that does not include a
stored preference. For example, if a network administrator's system is configured differently from the systems
found with end-users, the preference set at system software installation time (based on the configuration of the
administrator's system) may not be optimum for end-users' systems.
If all of the end user population is configured similarly, the network administrator could use the Network Software
Selector utility to modify the stored preference before distributing system software. However, if end-users'
system configurations vary widely, deleting the preference would have the effect of deferring the selection of
network software to boot time for each individual user.
Should an end-user want to “lock-in” a preference for their system, they would need to simply launch and then
close the NSS utility on their machine. This records the network system currently in use as the preference.
Q:
When might a user want to use NSS to enable Open Transport, disabling classic networking?

A:
The Network Software Selector provides System 7.5.3 users an easy way to update to Open Transport
networking, without requiring custom system software installations.
Open Transport should be enabled when the user is ready to take advantage of any of Open Transport’s
features, such as multiple saved network configurations, reconfiguration without restart, support for PowerPC
native code; when the user want to run Open Transport-ready or Open Transport-enhanced applications; or when
a network manager requires the use of Open Transport to connect to a centrally administered network.
Of course, users that have previously dropped back to classic networking in order to maintain compatibility with
an older network application will want to re-enable Open Transport once the application has been updated.
Q:
When might a user override the default for Open Transport and specify a preference for classic networking?
A:
The Network Software Selector provides an easy way to temporarily drop back to classic networking, if needed,
on systems that support both networking models. There are two basic reasons why there might be a call to do so:
• a need to maximize RAM available for running other applications, especially if VM is turned off; or,
• a need to run older networking software that is not yet Open Transport compatible.
Before dropping back to classic networking, users are encouraged to check with the application developer to
find out if an Open Transport-compatible or Open Transport-ready version of the application is available.
Q:
On systems that support both classic and Open Transport networking, how are configuration preferences
managed? How does the Network Software Selector interact with these preferences?
A:
When initially installed, Open Transport AppleTalk and TCP Preferences files are created based on the current
settings for classic networking. The Prefs files will each contain a single configuration, entitled “Default”. Classic
settings are not modified by this installation process.
When booted with Open Transport active, classic networking components and preferences are hidden, and
Open Transport initializes with the default configurations. Should the system switch back to classic networking
at a later time, Open Transport settings are hidden and the saved classic settings are restored.
Each time the system switches between classic and Open Transport - whether through the use of the Network
Software Selector utility or by moving an external boot volume from system to system (where different memory
sizes or processor types could cause a switch) - this process will be repeated.
Note that after the initial installation, there is no exchange of configuration information between classic and
Open Transport networking. If changes are made in network addressing, etc. while running classic networking,
those changes will not be in effect up on switching back to Open Transport. The inverse holds true as well.
For AppleTalk users this would very rarely be any sort of problem, as AppleTalk dynamic addressing and
dynamic naming would typically adjust to the system environment at network initialization time.
For TCP/IP users, this could create the potential for some confusion if a user installed Open Transport but
continued to run classic networking for a while -- making some configuration changes during that time. Later,
when they enable Open Transport networking using the Network Software Selector utility, they'll find that the
default Open Transport/TCP configuration reflects their “old” MacTCP settings, not the most recent version.
While there is some potential confusion for users in this behavior, Apple looked carefully at the alternatives,
including the possibility of converting information every time the stored preference for network system changed.
That approach would have resulted in more frequent and more difficult end-user problems, so was abandoned in
favor of the single-conversion at installation time.

Q:
On systems that support both classic and Open Transport networking, how are control panels managed? How
does the Network Software Selector interact with these files?
A:
During the boot process, a MacOS system running System 7.5.3 checks for the stored preference for
networking software as described above. Once the selection of network software has been determined and
validated, the load process also causes the appropriate control panels -- “Network” and “MacTCP” for classic
networking; “AppleTalk” and “TCP/IP” for Open Transport -- to be “unhidden”. Those associated with the disabled
network software are hidden (made invisible).
For the Network Software Selector "show and hide" mechanism to work, it is very important that all files
associated with networking be stored in their original and proper locations, with their original file names. Users
should not rename these files, nor should they partially install or de-install networking software by draging copies
of files into or out of the System Folder.
Q:
Does the Network Software Selector allow running Open Transport on a 68000 or 68020 Mac? If not, why not?
A:
While NSS can change the stored preference to Open Transport at any time, the preference will be honored at
boot time only on those models that can use Open Transport - 68030, 68040, and PowerPC MacOS systems.
68000 and 68020 systems always load and run classic networking. Open Transport was not engineered to
support these two older processors as the overall processor and system memory requirements associated with
Open Transport's additional features are generally higher than that available in these older systems.
Q:
Does the Network Software Selector allow running classic networking on a PCI Power Mac? If not, why not?
A:
While NSS can change the stored preference to classic networking at any time, that preference will be honored
at boot time only on those models that can use classic - 68030, 68040, and NuBus PowerPC MacOS systems.
However, certain MacOS systems with PCI – designed for entry-level markets, where users’ networking needs
and system memory configurations may be limited – may ship with a initial preference to support only AppleTalk
on LocalTalk using classic networking. On these systems, a user can easily enable Open Transport using NSS
when they are ready to take advantage of PCI network cards, or when they want to gain direct access to TCP/IP
networks such as the Internet.
Classic networking is not generally supported on PCI MacOS systems for a number of reasons:
• PCI MacOS systems are based on PowerPC, and only Open Transport provides PowerPC native code;
• Apple simultaneously adopted hardware and software standards for networking by supporting PCI
networking via Open Transport's DataLink Provider Interface (DLPI) driver architecture;
• Many of the new features provided by Open Transport, such as multiple saved configurations,
reconfiguration without restart, and support for current standards (DHCP, IP multicast, etc.) would have
been technically difficult or impossible to retrofit to classic networking; and,
• Open Transport prepares the way for MacOS 8, by carefully defining an execution model consistent with
protected memory and preemptive scheduling.
Q:
Can MacTCP be installed on a PCI MacOS system running System 7.5.3 and Open Transport?
A:
With System 7.5.2 it was possible - although not recommended or supported - to install MacTCP on PCI MacOS
systems through drag-copy of specific files. Beginning with System 7.5.3, this is no longer possible.
In order to meet the requirements of the Universal System Folder, System 7.5.3 automatically hides files
associated with classic networking on systems where Open Transport is in effect (and correspondingly hides
Open Transport files on systems where classic networking is running). If a user installs MacTCP on a PCI
machine - where Open Transport is always active - the “just installed' MacTCP files will be automatically be
hidden by the MacOS immediately upon reboot of the system. This could be confusing to users who may not be
aware that this software configuration (MacTCP on PCI machines) is not supported.

If, for any reason, it becomes necessary to reinstall MacTCP on a 68030, 68040, or NuBus PowerPC MacOS
system running Open Transport, the end-user must first use the Network Software Selector utility to specify a
preference for classic networking and reboot the system. Only after the reboot will MacTCP and the other
components of classic networking be visible. The converse would also be true for Open Transport on these
machines - only the currently running network system is visible and can be modified or updated.
Q:
Does System 7.1.x support both classic and Open Transport networking?
A:
System 7.1.x continues to support classic networking, and gains the option of running Open Transport v1.1.
Customers running 7.1.x on 68000 and 68020 systems will continue to use classic networking; Open Transport
v1.1 will not install on these systems. (System 7.1.x does not support PCI MacOS systems.) Customers running
System 7.1.x on 68030, 68040, and NuBus PowerPC MacOS systems can use either classic or Open Transport
networking. To enable Open Transport, users must run the Open Transport installer, available as a part of the
stand-alone retail distribution package.
Q:
Is the Network Software Selector available for System 7.1.x customers?
A:
No, the Network Software Selector is a feature only found in System 7.5.3.
Open Transport and MacOS System 7.5.5

Q:
I have System 7.5.3 installed and want to update to OT 1.1.1 and System 7.5.5, which installation should I
perform first?
A:
Apple recommends installing the System 7.5.5 installer first, and then the OT 1.1.1 installer
Q:
When I installed System 7.5, Update 2.0, I chose to custom-install without Open Transport 1.1. Then I updated
to System 7.5.5 and find I can not use the System 7.5.3 installer to custom install OT 1.1. How do I now install
OT 1.1.1?
A:
System 7.5 Update 2.0 installer is designed to install only on System 7.5 through 7.5.3. Once System 7.5.5
Update is installed, you cannot use System 7.5 Update 2.0 to install system components, including those
previously available via the Custom Install option. Open Transport 1.1.1 will not install if Open Transport 1.1 or
later is not previously installed. Therefore it is possible via custom installations of System 7.5, Update 2.0 and
the System 7.5.5 Update to generate a configuration that can not update directly to OT 1.1.1.
In this situation, the only recourse is to perform a "clean install" of system software , creating a new system
folder. As part of the clean install of System Software, when you update to 7.5.3 (via System 7.5, Update 2.0) be
sure you either (1) use the easy install or (2) include OT 1.1 in the list of components you select to custom
install. You can then install the System 7.5.5 Update and the OT 1.1.1 Update.
Customers using the retail version of System 7.5.3 will not encounter this situation. Customers with the retail
version of System 7.5.3 who have installed System 7.5.5 Update can still use the Custom Install option of
System 7.5.3 to install Open Transport 1.1.

Availability and Distribution

Q:
What is the current version of Open Transport, and what are its key features?
A:
Open Transport v1.1.1. This release is an update to Open Transport v1.1, to address the most pressing
customer requests, in advance of the next feature release of Open Transport (currently planned as OT 1.5 - see
Future Directions). Open Transport v1.1.1 includes the following updates and new features as compared to the
earlier Open Transport 1.1 release:
• now also supports the Performa 5200, 5300, 6200, and 6300 systems;
• includes internal changes to minimize memory fragmentation resulting from dynamic loading and unloading
of TCP/IP;
• includes changes to the TCP/IP DNR for interoperability with sites using the load-balancing name daemon,
and improved stability and performance for high volume servers;
• includes performance enhancements for servers that use TCP/IP;
• improves compatibility with ARA 2.0.1 and later;
• improves compatibility with PowerBook features including sleep;
• includes changes for support of the Open Transport/PPP release later this year;
• includes a new utility, the AppleTalk Options control panel for use with ISDN Bridges;
• support for additional 3rd party SLIP and PPP implementations;
• includes all bug fixes available to date.
Q:
How is Open Transport v1.1.1 available?
A:
Open Transport v1.1.1 is built as a stand-alone installer, and is distributed online from a variety of Apple, and
Internet sites. A fulfillment program will be available that will allow ordering a CD with OT 1.1.1 for $13. More
details about the fulfillment program will be included in the OT 1.1.1 Press Release
Q:
Does System 7.5.3, System 7.5.5 or System Update 2.0 include Open Transport 1.1.1?
A:
No. MacOS system software ships with Open Transport 1.1. Open Transport 1.1.1 was not yet available at the
time these products went to manufacturing. Future releases of MacOS system software are planned to include
the most current release of Open Transport available at the time. However, incremental updates to OT may be
provided independently (such as with OT 1.1.1) to provide responsive customer support.
Q:
Does the Open Transport single-user software package contain Open Transport 1.1.1?
A:
No. The retail software package ships with Open Transport 1.1. Open Transport 1.1.1 was not yet available at
the time this product went to manufacturing. Current plans call for the Open Transport software package to be
updated with each feature-based release of Open Transport; however, incremental updates to OT may also be
provided independently (such as with OT 1.1.1) as needed to provide responsive customer support.
Q:
Are there changes in the system requirements for Open Transport 1.1.1?
A:
There are no changes from the previous release, Open Transport 1.1, in the memory, processor, or OS
requirements (see Open Transport and MacOS System 7.5.3). Installation of Open Transport 1.1.1 requires that
a previous version of Open Transport already be installed and (on applicable systems) selected as the active
network system via the NSS.

Q:
Some Power Macintosh and Performa 52xx, 53xx, 62xx, 63xx systems came with System 7.5.3, but without
Open Transport 1.1. Can Open Transport 1.1.1 be installed on these systems?
A:
The Open Transport 1.1.1 installer includes a special case for these machines. Open Transport 1.1.1 will install
directly on these systems even if Open Transport 1.1 was not previously installed. These are the only system
models where this exception in the installer script is activated, all other systems must have OT 1.1 previously
installed to update to OT 1.1.1.
Q:
What of the earlier Open Transport 1.1 release?
A:
Open Transport v1.1 included the following updates and new features as compared to the earlier 1.0.x releases:
• added support for 68030 and 68040 MacOS systems,
• added support for PowerPC MacOS systems with NuBus,
• added support for NuBus, SCSI, and CommSlot network interface adapters,
• offered tuning to optimize performance of high speed datalinks,
• offered tuning to support multiple client, multithreaded server applications,
• added support for multinode and multihomed operation of AppleTalk protocols,
• added support for raw packet access and promiscuous mode, to enable the development of Open
Transport-ready network analyzers and other network management utilities,
• recognized a significantly expanded selection of MacTCP dial-up network extensions (mdevs),
• allowed reconnection of a dial-up TCP/IP session without reloading networking and without system restart,
• provided display of the datalink Media Access Control address for ethernet and token ring networks,
• provided user notification in the event duplicate AppleTalk or TCP/IP addresses are established,
• automatically converted users’ existing AppleTalk and MacTCP setting to Open Transport configuration files
during installation (only if Open Transport preferences do not already exist),
• included improved compatibility with Apple Remote Access 2.0.1,
• included improved compatibility with a wider range of DHCP servers,
• provided a basis for future support for PPP-based AppleTalk and TCP/IP remote networking,
• provided a basis for future support for modem and ISDN communications devices,
• included support for MacOS system software System 7.5.3,
• included support for the creation of a “universal system folder”,
• included support for the Network Software Selector utility to provide easy transition from classic to Open
Transport networking on MacOS systems supporting both,
• offered improved Balloon Help text for System 7 users, and,
• included all bug fixes available to date.
Q:
How is Open Transport v1.1 available?
A:
Open Transport v1.1 is available through a broad range of distribution channels:
• as a no-charge upgrade to customers with existing MacTCP volume license software maintenance
agreements;
• as a no-charge upgrade to customers with existing system software volume license software maintenance
agreements;
• as a component of MacOS system software release System 7.5.3;
• as a component of MacOS system software update System 7.5 System Update 2.0;
• as a retail software product in single-user software package;

• through an OEM redistribution licensing program from Apple Software Licensing,

• bundled with Apple and third party applications software that are Open Transport-ready; and,
• from select Apple-licensed publishers and Internet Service Providers.
Q:
How do volume license software maintenance customers receive Open Transport?
A:
A master copy of the Open Transport software and documentation is automatically be mailed to the contact of
record for customers with active MacTCP or MacOS System Software maintenance contracts.
Q:
How can a customer receive a copy of System 7.5.3?
A:
System 7.5.3 will be pre-installed on MacOS systems beginning in first half calendar 1996. System 7.5.3 is to be
available as a shrink-wrap retail product.
Q:
How could a customer receive a copy of System Update 2.0?
A:
System Update 2.0 is available through a variety of channels, including:
• On the Internet, from locations including www.info.apple.com, www.support.apple.com,
ftp.info.apple.com, and ftp.suport.apple.com;
• on electronic information services such as America OnLine and CompuServe;
• through Apple User Groups;
Q:
What is the part number and pricing for the Open Transport single-user software package?
A:
In the U.S. order number M4252Z/A; the estimated retail price is $39.
Q:
Since Open Transport is included with System Update 2.0 and System 7.5.3, why might a customer want to
purchase the Open Transport single-user software package?
A:
The Open Transport single-user software package is designed for customers running System 7.1.x who are not
ready to upgrade to System 7.5.3, yet want to take advantage of Open Transport features. It might also be of
interest to customers running System 7.5.3 or later who want a printed copy of the user documentation.
Q:
Is Open Transport localized for non-English speaking countries?
A:
As a part of MacOS System 7.5.3, Open Transport 1.1 is being localized around the world. Please contact the
Apple Assistance Center in your area for details.
Availability of localized versions of OT 1.1.1 will vary on a country by country basis.

Q:
How is Open Transport available to software developers, publishers, and/or Internet Service Providers (ISPs) for
redistribution and bundling?
A:
Apple offers two different redistribution licensing agreements for Open Transport, designed to meet the needs of
publishers, software developers, and ISPs.
The first agreement is designed for Internet service providers, network and communications reference work
authors and publishers, and others interested in bundling Open Transport software as an added customer
benefit to their product or service offering. This license is based on a sliding-scale per-unit license fee, and
requires annual reporting of licenses issued. Interested parties should send electronic mail to
SW.LICENSE@applelink.apple.com.
The second agreement is designed for software developers with products that adopt the new Open Transport
APIs who wish to ship Open Transport as a part of an integrated product installation process. This agreement is
based on an addendum to the MacOS SDK, and allows qualified developers to ship the Open Transport run-time
environment to end-users as a part of their product.
To qualify, developers must execute the Open Transport License Addendum through Apple Software Licensing,
and meet the following requirements:
• have developed an Open Transport-ready or Open Transport-enhanced software product (including
applications developed for Apple's NetSprockets game architecture),
• be current subscribers to the MacOS SDK,
• provide Apple advance notice of their intent to ship their Open Transport product(s),
• distribute the required Open Transport components only in conjunction with their product(s), and,
• annually report the total number of licenses issued.
Other terms and conditions apply, however, no additional fees (beyond the MacOS SDK subscription) are
required for this license. Interested parties can send electronic mail to SW.LICENSE@applelink.apple.com.
Q:
Will localized versions of Open Transport software be available for developer and ISP licensing?
A:
Initially the Open Transport redistribution licensing program will only have the U.S. English version of the
software available. Licensing of localized versions of Open Transport will depend upon demand and availability.
Q:
What of the earlier Open Transport v1.0.x releases?
A:
Open Transport v1.0.x releases were all designed for use only on the Apple PCI Macintosh systems:
• Open Transport version 1.0, for the Power Macintosh 9500, was focused on offering compatibility with
existing networking client applications and on upgrading the feature set and performance of TCP/IP. It
shipped only as an integral part of system software with the 9500.
• Version 1.0.1 was a maintenance update, designed to correct a potential problem with data truncation in
large file transfers. Open Transport v1.0.1 was distributed electronically, as an update to be applied to an
existing installation of Open Transport v1.0.
• Version 1.0.6 added support for the Power Macintosh 7200, 7500, and 8500 systems and addressed bugs
discovered since the 1.0 release. Open Transport v1.0.6 shipped as a component of System Software 7.5.2
version 2 on the Power Macintosh 7200, 7500, 8500, and 9500 models.
• Version 1.0.7 included changes to improve performance and compatibility of Open Transport/TCP with third
party SLIP and PPP software and with certain Internet Service Providers (ISPs). Open Transport v1.0.7 was
distributed electronically, as an update to be applied to an existing installation of Open Transport v1.0.6.
• Version 1.0.8 was also a maintenance release, and included better compatibility with Qualcomm Eudora,
Claris Emailer and Emailer Lite, CE Software QuickMail, and Netscape Communications client software, as
well as improvements in BootP and DHCP interoperability. Open Transport v1.0.8 was distributed via a
variety of information services - such as AppleLink and eWorld, and a number of Internet sites - as a full
installation of Open Transport software.

Q:
Why was Open Transport made available on PCI Power Macintosh systems first?
A:
Starting with the introduction of the Power Mac 9500, Apple moved to adopt industry standards for both network
driver software – Open Transport DLPI – and network hardware – PCI. This strengthened the business case for
new and existing third party developers who could, as a result, include MacOS on PowerPC in their plans for
cross-platform network connectivity products. The Power Macintosh 9500 was the first system to incorporate
both of these standards, and has since been followed by additional systems and configurations.
In particular, Apple made the business decision to move to standards for networking on the hardware and
software fronts in tandem, i.e., PCI and DLPI. This created a dependency that required customers deploy Open
Transport with their PCI MacOS systems. It also minimized the work by third parties needed to create drivers for
new PCI networking cards. As a result customers have found a broad selection of third party PCI networking
options for MacOS.
Network Interface Options

Q:
What network interface options are available with Open Transport?
A:
Open Transport v1.1 and greater supports PCI and NuBus NICs, CommSlot and built-in (LocalTalk and ethernet)
network adapters. For models without slot-based expansion options, Open Transport v1.1 and greater supports
SCSI-attached network adapters, including PC Cards compliant with the Macintosh PC Card specifications.
NIC options available for Open Transport include ethernet, token ring, fast ethernet, FDDI, and ATM.
Q:
What about dial-up network connectivity solutions?
A:
For connectivity to AppleTalk networks, Open Transport v1.1 and greater is fully compatible with Apple Remote
Access v2.0.1 and greater client and personal server.
For dial-up connectivity to TCP/IP networks including the Internet, Open Transport recognizes third party
MacTCP software extensions (known as mdevs), providing SLIP or PPP connectivity. See Network Compatibility
for more information.
Apple has now reached the beta milestone with a new, PowerPC native implementation of PPP for Open
Transport. This software, OT/PPP, will support TCP/IP connections in its first released version, with AppleTalk
on PPP (ATCP) in a future version.
Q:
Does Open Transport influence or restrict the choice of modems for dial-up communications?
A:
No. Open Transport provides a new, consistent programming interface for serial communications from within
system software. However, there are no changes in the external behavior of the serial ports based on the
presence or absence of Open Transport on a system.
Network Planning & Administration

Q:
Does Open Transport offer network managers more control over Mac OS networking?
A:
Yes. Open Transport allows network managers to specify details of the network connection and configuration in
advance, via a “preferences” file. These configurations may contain a mixture of user-provided information and
network manager recommended and/or network manager required settings. Recommended data provides a
default for the end-user, while required configuration data is locked with an administrator's password.

Open Transport configurations can be prepared on one machine and distributed to other systems. To support
this, the Open Transport configuration utilities allow a configuration to “exported” and “imported”. Exported
configurations can be distributed via electronic mail, a file server, or even “sneaker net”.
Q:
Does Open Transport require organizations to make changes in network administration, planning, or design?
A:
The first Open Transport protocols – AppleTalk and TCP/IP – offer new features that give a network manager
more flexibility and control. Some of these features, when implemented in a network environment will require
additional thought and planning by a network manager.
In particular, Open Transport/AppleTalk adds support for the use of static (manually assigned) AppleTalk node
addresses. If implemented, a network manager may prefer to assign addresses based on a pre-designed
protocol address management plan. Open Transport/TCP adds support for the Dynamic Host Configuration
Protocol (DHCP). DHCP allows network managers to allocate IP addresses and other configuration information
from a DHCP server. Optimum deployment of DHCP services within an enterprise requires planning.
In order to better conform to applicable standards, Open Transport/TCP also has somewhat more rigorous
requirements regarding the content and format of the local HOSTS file. This could require some updating of
existing MacTCP-compatible host files. See TCP/IP Features for more information.
Q:
Does the use of AppleTalk manual addressing increase the requirement for network administration?
A:
Open Transport/AppleTalk offers network administrators a choice. Sites that prefer to have the network
infrastructure automatically assign unique protocol addresses can continue to rely on AppleTalk Address
Resolution Protocol (AARP). Sites that find advantage in having fixed and well-known protocol addresses for
each end-node can implement manual addressing.
When manual addressing is selected there will be a requirement to allocate and assign the initial protocol
addresses, which will subsequently be “locked”. Some administrators may prefer to do this allocation based on a
central numbering plan, creating individual configuration templates (recommended or required settings) for each
user. Others may prefer to allow the network to determine the initial address configuration (i.e., use dynamic
addressing once), and then lock the uniquely assigned addresses after initialization.
It is important that all nodes on each individual AppleTalk subnet (a given cable segment assigned a unique
network number or network number range) be administered consistently - either all with dynamic addressing or all
with pre-assigned static addresses. This avoids a potential conflict between a new dynamic node acquiring an
address assigned to an off-line, manually-addressed node. Administrators can enforce the addressing policy for
a subnet by locking the addressing mode in the “dynamic” or in the “manual” state. As an administrative
precaution, however, Open Transport/AppleTalk does continue to check for the presence of duplicate protocol
addresses on the LAN when static addressing is configured.
Q:
Are there other benefits that arise from the new support for AppleTalk manual addressing?
A:
Yes. Manual configuration of static AppleTalk addresses supports MacOS products that utilize WAN datalinks
where non-full-mesh topologies are important. This includes datalinks such as Frame Relay, SMDS, and ATM.
Q:
Does Open Transport/TCP support BootP?
A:
Yes. Open Transport v1.1 and greater fully supports Boot Protocol (BootP).
With Open Transport v1.0.x, there was an error condition in which Open Transport would fail to accept a BootP
Reply if it were sent to the unicast (subnet broadcast) address, i.e., xxx.xx.x.255; replies sent to the all-nets
broadcast address (i.e., 255.255.255.255) were handled properly. Both situations are correctly handled by Open
Transport v1.1 and greater.
Open Transport 1.1 and greater also correctly support BootP gateways located 1 or more hops away. Earlier
versions of Open Transport required that the BootP gateway be zero hops away.

Q:
Which DHCP servers are supported by Open Transport/TCP?
A:
Apple’s implementation conforms to the current versions of the applicable specification documents (RFCs). To
date, Open Transport/TCP has been tested with the following DHCP server implementations:
• Competitive Automation,
• FTP Software (http://www.ftp.com),
• Hewlett Packard HP-UX (http://www.hp.com),
• Microsoft Windows NT Advanced Server,
• Silicon Graphics ( http://www.sgi.com),
• Sun Solaris and SunOS (http://www.sun.com), and
• TGV (http://www.tgv.com).
Q:
Does Open Transport/TCP support DHCP address leases?
A:
Yes. Open Transport/TCP fully supports DHCP address leases. Open Transport/TCP will automatically attempt
to renew any address lease that reaches it’s renewal interval, which defaults to half of the lease’s lifetime. (The
Renewal Interval may be configured to a different value by making changes to the configuring DHCP server).
Renewal will be attempted regardless of how many times the lease has already been renewed.
Should an interface’s IP address lease expire, the interface will be closed down.
Q:
Are there interoperability issues of note regarding DHCP servers?
A:
Some DHCP servers require padding to a fixed packet size; other servers do not accept padded packets. Open
Transport 1.1 and greater automatically adapt to the type of DHCP requests that a given server accepts, while
earlier (1.0.x) versions sent non-padded packets.
Network managers should also note that Open Transport 1.1 and greater support DHCP gateways located one or
more hops away. Earlier versions of Open Transport required that the gateway be zero hops away.
Q:
Does Open Transport/TCP support the optional DHCP CLIENT-ID feature?
A:
This feature is an optional feature of the DHCP specification and is not implemented in Open Transport/TCP as of
Open Transport v1.1.1. Due to customer requests, we are looking to include it in a future release of Open
Transport.
Q:
Can Open Transport/TCP act as a DHCP client to a Windows NT Advanced Server?
A:
Yes, Open Transport v1.1 and greater are interoperable with the Windows NTAS DHCP server on LAN links.
MacOS clients cannot acquire configuration information from an NT DHCP server across a dialup (PPP) link, as
there is not yet an accepted industry standard for DHCP over dial-up.
Macintosh clients running earlier versions of Open Transport (1.0.x) could experience some interoperability
problems due to differences between the Microsoft implementation and that of a typical UNIX server.
• Clients running Open Transport v1.0 or v1.0.1 were not able to acquire leased IP addresses.
This was due to unusually long reply-time-out values used in the NTAS implementation. Open Transport
v1.0.6 was changed to accommodate NTAS behavior in this regard.

• Clients running Open Transport versions prior to v1.0.8 would be incompletely configured via DHCP.
NTAS sends only IP address, IP address lease information, the configuring server's IP address, and a
subnet mask. Other configuration options entered in the NT DHCP server's database (default gateway
address, domain name server addresses, domain name, broadcast address, etc.) are not sent unless
specifically requested by the client using the DHCP Parameter Request List option.
Apple believes that requiring use of this option in order for the client to be properly configured is contrary to
the DHCP server specification. In interest of interoperability, Open Transport v1.0.8 and greater use the
Parameter Request List option to request default gateways, DNS servers, domain name, subnet mask, and
broadcast address. This permits Open Transport/TCP clients to be fully configured by these servers, at the
expense of a few additional packets on the wire during the initialization phase.
Q:
Can Open Transport/TCP act as a WINS client to a Windows NT Advanced Server?
A:
No, not at this time. The Microsoft WINS server is dependent on Microsoft extensions to TCP/IP (requiring
NetBIOS support) that provide some automation for assignment and registration of IP host and domain names.
The Internet Engineering Task Force (IETF) is developing a cross-platform industry standard technology for
dynamic registration and look-up of IP names through the Dynamic Service Location working group.
Apple has no current plans to implement the WINS extensions. Instead, we are fully committed to implementation
of the applicable IETF standards as they emerge. We welcome customer feedback on this topic – should
sufficient demand for a WINS client materialize, we’d be open to exploring this issue. A future MacOS WINS
client would be dependent upon Microsoft releasing sufficient technical detail regarding their proprietary
extensions to IP to make an interoperable implementation possible.
Q:
When installing and configuring Open Transport, are there other issues of note for network managers?
A:
The following comments have been developed based on feedback from customers.
• Because the new domain name resolver supplied with Open Transport/TCP is both more capable and more
standards compliant than the one included with MacTCP, configuration changes may be desirable or
necessary. For example, although common practice in configuring MacTCP, it is no longer necessary to
repeat the primary DNS server address in the configuration.
• Network managers should note that although the TCP/IP control panel can properly receive and utilize
multiple gateway and name server addresses from a DHCP server, only the first one returned has been
displayed in the TCP/IP control panel. This has been resolved in OT 1.1.1.
• Error -3205 can result if the user has manually modified (moved, renamed, or deleted) files installed by Open
Transport. Both the Shared Library Manager and Shared Library Manager PPC files must be present on a
PowerPC MacOS system. In general, users should not attempt to modify the OT installation through any
means other than the Apple supplied installer scripts.
• Users are occasionally encountering an error message like “Cannot open connection to DNS Name Server”
when trying to run classic MacTCP applications. This can result if the user has manually modified (moved,
renamed, or deleted) files installed by Open Transport. The MacTCP DNR file must remain in the System
Folder at the root level for backward compatibility to function.
• With System 7.5, TCP/IP support was included but was not automatically installed (it required a Custom
Install action). As of System 7.5.3 and Open Transport, TCP/IP services are always installed. However, if
there are no MacTCP preferences on the target disk, TCP/IP is installed with a default configuration
specifying configuration via MacIP in the current AppleTalk zone, but it is set to “Never Load”. To enable
TCP/IP, use the TCP/IP Control Panel in the Advanced or Administrator mode and select the Options dialog.
Applications Compatibility

Apple Open Transport Background Q & A
Q: .enet
Application
Classic AT
Application
MacTCP
Application
WinSock
Application
Is Open Transport compatible with existing
applications and network extensions?
A:
68K .enet AppleTalk MacTCP NetManage
CODE Compat. Compat. Compat. WinSock
Apple and third party developers have announced

hundreds of Open Transport compatible PPC
CODE
applications. STREAMS
Open Transport includes software libraries that

provide “backward compatibility” services in four AppleTalk TCP/IP IPX Serial
areas:
• to support existing applications that utilize the
documented AppleTalk APIs;
• to support existing applications that utilize the
documented MacTCP APIs;
Built In NuBus PCI Bus PCMCIA
Network Driver Compatibility Network Interface Network
• to support MacTCP Link Access Extensions
(mdevs) on case by case basis; and,
• to support existing NuBus based network NuBus
Network Interface
interface cards and drivers.
Figure 1 shows an overview of the Open Transport Figure 1. Open Transport Compatibility Services
architecture, including compatibility services.
Note that the WinSock compatibility services are provided through third party software, available from
NetManage. For more information, please refer to Open Transport and Cross-Platform Issues.
Open Transport compatibility services are available to applications accelerated for PowerPC as well as for 680x0
applications, as it provides the necessary “mixed-mode glue” as part of the Software Developer's Kit (SDK).
Q:
What is implied when an application is “Open Transport Compatible”? Does that mean that it takes advantage of
new Open Transport features?
A:
Apple has defined three levels of interoperability with Open Transport. The first – known as Open Transport
Compatible – is used to describe a network application originally developed for “classic” AppleTalk or MacTCP,
that now takes advantage of Open Transport Compatibility Services. These applications automatically gain the
benefits associated with the new Open Transport configuration utilities. However, they will not realize a
significant performance increase on PowerPC MacOS systems, nor can they take advantage of Open
Transport’s transport-independence capabilities.
Open Transport Ready applications are those that have been modified to adopt the new Open Transport APIs
(XTI). They are PowerPC native, in addition to running on 680x0 MacOS systems. Open Transport Ready
applications not only benefit from the new configuration utilities, but have the opportunity for a significant
performance boost when running on PowerPC MacOS.
The third and final category of interoperability is referred to as Open Transport Enhanced. In addition to adopting
the new Open Transport APIs and being PowerPC native, these applications have been modified to exploit the
transport-independent capabilities of Open Transport, i.e., they can be dynamically configured to support
AppleTalk, TCP/IP, or serial communications.
Q:
How is backward compatibility for AppleTalk implemented?
A:
AppleTalk applications backwards compatibility is accomplished by intercepting all AppleTalk networking calls at
the DDP level. Above this protocol layer, applications written to the classic AppleTalk APIs continue to rely on
the classic (680x0 based) implementation of AppleTalk. Calls to the “.ddp” driver are translated to the
corresponding Open Transport XTI calls and are then passed to the new native implementation of DDP for
processing. The process is reversed for incoming packets.

Using this approach, backwards compatibility is very robust - the classic implementations of ADSP, ASP, ATP,
NBP, ZIP, and PAP are actually present (vs. simply mimicked). This also decreases the total memory footprint of
backwards compatibility as compared to an implementation based on individual adaptation layers for each of the
AppleTalk protocols. The primary trade-off of this approach is that applications relying on backwards
compatibility do not gain any meaningful performance increases on PowerPC MacOS; essentially only native
DDP is actually in use in these cases. (see Figure 1)
Open Transport/AppleTalk also includes broad support for existing applications software and network devices
that rely on the Chooser or the Network Control Panel software for selection and configuration, known as “rdevs”
and “adevs” respectively.
Q:
How is backward compatibility for MacTCP implemented?
A:
TCP/IP (MacTCP) applications backwards compatibility is accomplished by intercepting all MacTCP networking
calls at the “.ipp” driver level. Calls to the “.ipp” driver are translated to corresponding Open Transport XTI calls
and then passed to the native TCP/IP stack for processing. The process is reversed for incoming packets.
This approach allows most MacTCP applications to benefit from the native implementation of the TCP/IP
protocols on PowerPC MacOS, at least to some degree. While the backwards compatibility layer itself must run
as 680x0 code, most of the handling of the packet happens in the new native Open Transport/TCP
implementation. The drawback of this implementation is that “warts and all” backward compatibility is somewhat
less robust; applications depending on idiosyncrasies of MacTCP or referencing internal MacTCP data
structures are likely to need an update. (See Figure 1)
TCP/IP backward compatibility also includes targeted support for select software products that rely on the
MacTCP (or MacTCP Admin) Control Panel software for configuration. Support for these software modules,
known as MacTCP Link Access Modules, or simply “mdevs”, is more limited than that provided for AppleTalk
“adevs”, due to certain technical considerations.
Q:
Are there other compatibility issues with PCI MacOS systems and existing network software products?
A:
Certain network software products – such as MacIPX from Novell, PathWORKS (LAT and DECnet) from Digital
Equipment Corp. or Thursby Software Systems, and Insignia Solutions SoftWindows – interact directly with the
MacOS ethernet hardware, expansion slots, and driver software. With the introduction of PCI and Open
Transport to MacOS these elements have changed substantially; PCI has replaced NuBus, the system Registry
has replaced the Slot Manager, Open Firmware has replaced the role of NuBus ROMs, and DLPI has replaced the
“.ENET” driver API.
To support these types of products, MacOS System Software 7.5.x includes a compatibility library that allows
these products to identify and communicate with the built-in ethernet controller on PCI MacOS systems as if it
were a NuBus ethernet device. This compatibility software emulates the necessary low-level ethernet driver
calls, as well as the Slot Manager and related APIs necessary to preserve compatibility.
This compatibility software is limited, however, in that it supports access only to the built-in ethernet adapter of
PowerPC MacOS systems with PCI. Thus, existing versions of products such as MacIPX and SoftWindows will
not be able to take advantage of PCI network interface options such as token ring, fast ethernet, or FDDI. New
versions of these applications will be required to gain full access to all PCI NIC options.
With the availability of System 7.5.3 this compatibility library is included as a core part of system software.
Customers using MacIPX should note that an updated version of the compatibility library is included as a Custom
Install option with the System Update 2.0 installer. For more information regarding this updated library, please
refer to the System Update 2.0 release notes.
Q:
How is backward compatibility for NuBus network interface cards implemented?
A:
For 680x0 and PowerPC MacOS systems with NuBus, Open Transport v1.1 and greater will allow use of existing
NuBus NICs and drivers. This compatibility is provided by software support mapping DLPI driver calls generated
by new Open Transport protocols to corresponding calls to “classic” MacOS LAP Manager, .ENET and .TOKN
APIs.

Q:
Are there other known limitations to applications backward compatibility?
A:
Yes, there are some. Applications that rely on undocumented APIs or examine private data structures in classic
AppleTalk or MacTCP will not be fully compatible with Open Transport.
Examples include the MacSNMP AppleTalk and TCP/IP Agents (however, MacSNMP and the Macintosh System
Agent are compatible), the Apple Internet Router 3.x and some utilities like MacTCP Spy.
Updated versions of these software products will be required for full compatibility.
Q:
MacTCP Watcher was listed in this Q&A as a utility that was not fully compatible with Open Transport, has that
changed?
A:
Yes, MacTCP Watcher v2.0 has now been released and is compatible with Open Transport. It is available on the
Internet and can be downloaded from ftp://ftp.share.com/peterlewis/
Q:
There have been reports of problems with MacX 1.2. Is there an Open Transport compatible X Window System
server available?
A:
Apple MacX 1.5 is compatible with Open Transport and is a recommended upgrade for all customers who have
any earlier versions of MacX.
Although not related to Open Transport, there is a known bug in MacX 1.2 that can cause a system crash when
running on System 7.5.2.
Q:
There have been reports of problems with Apple Remote Access 2.0.1 and Open Transport. What is the status?
A:
Apple Remote Access 2.0.1 is fully compatible with Open Transport v1.1 and greater.
Apple Remote Access 2.0.1 running on a system with the earlier Open Transport 1.0.x releases always operated
in the “Remote Only” mode. In that mode, only resources at the remote site would be visible in the Chooser while
connected via dial-up; local resources would reappear when the dial-up link was disconnected.
Q:
There have been reports of problems with the use of Open Transport 1.0.x and network protocol analysis tools
such as ag Group Etherpeek and Neon Software NetMinder. What is the status of this?
A:
Open Transport v1.1 and greater includes support for promiscuous mode and raw packet access. Apple is
currently working with vendors to assure that ethernet and other NIC driver developers are implementing
promiscuous mode support in a consistent manner.
Open Transport v1.0.x did not include support for the DLPI messages necessary to enable promiscuous mode
on ethernet hardware. Because applications such as Etherpeek and NetMinder rely on this capability, they could
not perform data collection on systems running these earlier versions of Open Transport.
Q:
There have been reports of problems with the Apple LaserWriter Bridge and LocalTalk Bridge and Open
Transport. What is the status?
A:
Apple LaserWriter Bridge (LWB) and LocalTalk Bridge (LTB) software were designed to check for a specific
version of AppleTalk software. Because Open Transport registers itself as a more recent version, these
programs currently will not launch. An update for Open Transport-compatibility is currently underway.

LWB 2.1 and LTB 2.1 are compatible with Open Transport. LWB 2.1 will be posted on Apple's Software Updates
Sites shortly after OT 1.1.1 is available. Two patchers are under development for earlier versions of LTB and will
also be posted on Apple's Software Updates sites shortly after OT 1.1.1 is available. The first patcher will
update LTB 2.0 to LTB 2.1. The second patcher will update LTB 2.0.1 to LTB 2.1.
Q:
There have been reports of problems with MacTCP Ping and Open Transport. What is the status?
A:
MacTCP Ping is an unsupported utility developed by Apple Computer specifically for MacTCP. It is not
compatible with Open Transport.
Compatible Ping utilities, such as MacPing Pro from Dartmouth, are currently available.
Q:
There have been reports of problems with Assistant ToolBox and Open Transport. What is the status?
A:
Prior versions of Assistant Toolbox (v1.2 and earlier) , which have shipped as a component of the PowerBook
Productivity Bundle, were discovered to have a conflict with Open Transport v1.1.
An updated version of Assistant Toolbox is included as a part of System Update 2.0 (System 7.5.3).
Q:
There have been reports of problems with At Ease and Open Transport. What is the status?
A:
At Ease v3.0.1 and earlier have a conflict with Open Transport. At Ease v3.0.2 and later are compatible.
Network Compatibility
Q:
Is Open Transport interoperable with installed AppleTalk and TCP/IP networks?
A:
Open Transport 1.0.x is compatible with existing AppleTalk and TCP/IP networks at the “packets on the wire”
level. Organizations can introduce one, a few, or hundreds of new MacOS systems running Open Transport into
their environment without worrying about interoperability with existing networking services.
Q:
There have been reports of problems with the PCI MacOS systems when transferring large files over ethernet
networks. Is this due to running Open Transport software?
A:
Apple has received reports describing problems transferring large files from PCI Macintosh systems to a variety
of AFP servers. The reports state that file transfers stop and a -1072 error is generated. The reports also state
that after the problem occurs, both AppleTalk and TCP/IP services are lost and systems must be restarted to
restore them. If ethernet traces are taken, they show that the system disappears from the network.
This problem has been identified as a bug in the ethernet driver that can exhibit itself if there is a lot of PCI bus
activity. In this case, it is possible that ethernet DMA will start to transmit a packet, and an underrun will occur
because DMA cannot get enough bandwidth to transfer the entire packet to the ethernet controller. If this
condition occurs more than 10 times in sequence, the bug in the driver causes it to not recover the buffers
associated with the underrun. The driver allocates 10 buffers; when they are gone the transmitter will not longer
be able to send packets. This problem could occur in some normal situations with a lot of disk activity.
This problem is present only in the built-in ethernet drivers that shipped with the Power Macintosh 7200, 7500,
8500, and 9500 systems prior to the availability of System 7.5.3. (The first Power Macintosh 9500 systems
shipped with v1.0 of this driver; the Power Macintosh 7200, 7500, and 8500 systems shipped with v1.0.1.)
Apple has released an updated driver that fixes this problem, first available as version 1.0.2 of the “Ethernet
(Built-In)”. The most current version of this driver is included with System 7.5.3.

Q:
There have been reports of problems with the Power Mac 7200/90 and its operation on ethernet networks. Is this
due to running Open Transport software?
A:
Apple has determined that under certain network conditions, independent of the protocol being utilized, a Power
Macintosh 7200/90 may fail to send large packets over it’s built-in ethernet. The trouble mode is that the 7200/90
may lock-up, time-out, or have extremely slow ethernet performance under certain conditions. These conditions
generally occur only when transferring large packets of data over large and busy networks.
The problem has been isolated to the 7200/90 system logic board, and is limited to the subset of 7200/90
systems with a serial number lower than “XX544XXXXXXX”. No other Power Macintosh, Power Macintosh LC,
Performa or PowerBook models experience this problem, including the 7200/75. The problem is not related to
Open Transport.
Apple has proactively notified customers of this issue, and has instituted troubleshooting procedures to make it
easy to determine if a system is impacted. All manufacturing sites have implemented a logic board change and
Power Macintosh 7200/90 systems currently available should not be affected by this issue.
If a customer has completed the troubleshooting procedures and finds that their 7200/90 experiences the
trouble mode, they should contact their local Apple Authorized service provider or call Apple (1-800-SOS-APPLE
in the US) to be advised on how to have the logic board replaced free of charge.
Q:
There have been reports of problems with connecting the Power Mac 7200 to token ring networks. Is this due to
running Open Transport software?
A:
Currently, the Apple PCI Token Ring Card will not work with the Power Macintosh 7200. Apple is working on a
solution that will provide support for Power Macintosh 7200 models and will advise Apple Authorized Service
Providers when that solution becomes available. This problem is due on a bus timing issue and is not related to
the use of Open Transport software.
Q:
Open Transport doesn't seem to send packets larger than 1500 bytes on a token ring network. Is this normal?
A:
Due to limitations in Apple's currently available token ring drivers, an artificial limit is imposed on the maximum
packet size. This limit is planned to be addressed in a future version of driver software. Open Transport fully
supports larger frame sizes.
Q:
Is Open Transport compatible with existing Internet Service Provider offerings?
A:
Open Transport/TCP currently supports dial-up connectivity to TCP/IP networks, including the Internet, through
backward compatibility with select third party software modules known as mdevs.
With the appropriate software installed, end-nodes can use either SLIP or PPP to connect to Internet Service
Providers and other dial-up IP-access points. Not all versions of all mdevs are supported by Open Transport
compatibility services, thus it is important that recommended versions of software be installed for the greatest
level of compatibility.
It is also very important that TCP/IP addressing and other configuration information be properly configured. As
there is a new human interface provided by Open Transport/TCP, there are some differences in the process as
compared to the older MacTCP software. In particular, when running TCP/IP over a SLIP or PPP link only, it is
recommended that the “router address” and “subnet mask” fields be left blank in the TCP/IP control panel.

Q:
Which MacTCP dial-up extensions (“mdevs”) are supported by Open Transport/TCP?
A:
Apple has worked together with third party developers to test a variety of mdevs with Open Transport 1.1. The
following mdevs, when installed, will appear listed by name in the “Connect Via:” pop-up menu in the TCP/IP
control panel:
• FreePPP - Apple and the developer recommend that you use version 1.0.5 or more recent.
• InterPPP II - Apple and the developer recommend that you use version 1.1 or more recent.
• InterSLIP - Apple and the developer recommend that you use version 1.0.1 or more recent.
• MacSLIP - Apple and the developer recommend that you use version 3.0.3 or more recent.
• MacPPP - Apple and the developer recommend that you use version 2.1.4 or more recent.
• SonicPPP - Apple and the developer recommend that you use version 1.0.2 or more recent.
• NTS PPP - Apple and the developer recommend that you use version 2.0 or more recent.
• SAGEM ISDN PPP - SAT/SAGEM PPP - Apple and the developer recommend that you use version 1.02b1
or more recent.
• LeoTCP - Apple and the developer recommend that you use version 2.0.1 or more recent.
• T-Online CSLIP - - Apple and the developer recommend that you use version 1.0.3 or more recent.
• Michigan ISDN -- University of Michigan ISDN PPP - - Apple and the developer recommend that you use
version 2.0.6 or more recent.
Q:
Are there any PPP solutions available that uses STREAMS technology, not MacTCP extensions ("mdevs") and
are supported by Open Transport/TCP?
A:
Apple's Open Transport/PPP is currently available in beta format and uses STREAMS. Open Transport/PPP
appears under the name "PPP" in the "Connect Via:" pop-up menu in the TCP/IP control panel. OT/PPP version
1.0f1c9 or later is compatible with OT 1.1.1.
Q:
Earlier versions of this Q&A listed VersaTerm SLIP as compatible with Open Transport. What is the current
status?
A:
After additional testing and field experience, Apple and Synergy Software have jointly determined that there is a
compatibility problem between the current releases of VersaTerm SLIP and Open Transport. Apple and Synergy
are continuing to investigate and work towards a solution.
Q:
Are any other mdevs recognized by Open Transport?
A:
There are a number of third party PPP mdevs that are all derived from a common technology base, FCR PPP. The
derivative implementations have not been individually tested by Apple, although Apple and FCR have worked
closely together in testing the core technology.
Each of these derivatives registers with Open Transport using the same “signature”. When any one is installed, it
will appear as “TCP/IP PPP” in the menu, rather than as it's own brand name. These include:
• About Software FCR PPP
• 4-Sight 4-Sight PPP
• InterCon InterPPP
• Pacer Software PacerPPP
• SAT/SAGEM PlanetPPP
• Tribe TribePPP
• White Pine Software WhitePine PPP

Users are always encouraged to check with the third party developer of interest for the most recent information
on versions and compatibility.
Q:
Is PPP connectivity distributed as a bundled component of Open Transport v1.1.1?
A:
Not at this time.
Apple is developing an Open Transport implementation of PPP, for support of TCP/IP and AppleTalk protocols.
When available, current plans call for OT/PPP to be included with future distributions of Open Transport.
At the time this document is being written, Open Transport/PPP 1.0 is available publicly in a beta form from the
"Unsupported" folder in the "US" area of Apple's Software Updates Sites. Open Transport 1.1.1 requires OT/PPP
1.0f1c9 or later, earlier beta versions of OT/PPP are not compatible with OT 1.1.1.
Q:
Does Apple currently offer a solution for SLIP or PPP dial-up to the Internet?
A:
Yes. The Apple Internet Connection Kit (AICK) is a selection of the most popular Internet applications from third
party companies, including the Netscape Navigator and RealAudio Player from Progressive Networks, as well as
Claris Emailer Lite.
AICK 1.1 includes MacPPP 2.5 (Version 1.0 included MacPPP 2.1.4) along with the Apple Internet Dialer -
software designed to make it simpler for MacOS customers to register with a qualified Internet Service Provider
(ISP) and get connected to the Internet. To help users work with their Internet applications, the Apple Internet
Connection Kit includes AppleGuide software for on-line assistance.
Q:
Does the Apple Internet Connection Kit require Open Transport?
A:
The Apple Internet Connection Kit (AICK) can support either MacTCP 2.0.6 or Open Transport/TCP 1.x.
Customers should update their copy of AICK with the Apple Internet Dialer 1.1. This revision of the dialer is fully
compatible with Open Transport 1.1 and System 7.5.3
Q:
What is MacPPP 2.5 / 2.1.4? Is it available on the Internet?
A:
MacPPP 2.5 and 2.1.4 are derivatives of the MacPPP 2.1.x SD versions of Merit’s PPP. They include code
contributed by Apple engineering to enhance compatibility with Open Transport/TCP.
Q:
There have been reports of problems with Open Transport, PPP, and the use of Virtual Memory. Is Open
Transport compatible with Virtual Memory?
A:
Open Transport fully supports the use of virtual memory. However there were some problems with MacPPP
versions 2.1.x SD and versions of FreePPP prior to 1.0.4; MacPPP 2.5 and FreePPP 1.0.5 have corrected these
problems . Users are advised to update to the most recent version of the software, or temporarily turn VM off.

Q:
Are there known limitations to backward compatibility mdev support?
A:
Due to some shortcomings in the Open Transport 1.0.x backward compatibility services, there were some
additional limitations with earlier versions of Open Transport:
• Some mdevs were not be able to auto-dial, i.e., automatically connect to the service provider when
launching a TCP/IP application. This has been addressed with updated versions of mdevs.
• Once a TCP/IP application launched and used a SLIP or PPP mdev, use of a different mdev could have
required restarting the Macintosh. Disconnecting from and re-dialing a service provider could also have the
same effect. This has been corrected in Open Transport v1.1 and greater.
Q:
Are there differences in configuring Open Transport/TCP and MacTCP for Internet Service Providers (ISPs)?
A:
Some ISPs do not strictly follow standards, which call for assigning end-node IP addresses on the same subnet
as the router (gateway). Open Transport strictly enforced this requirement in versions prior to 1.0.7. In versions
since OT 1.0.7 ( including 1.1), the TCP/IP Control Panel automatically generates a compatible router address to
facilitate connectivity to the ISP. To take advantage of this feature, the user simply leaves the router and subnet
mask fields empty when configuring Open Transport/TCP for dial-up access.
Q:
If a user needs an updated copy of an mdev, where can they find the software?
A:
Sources for software vary, as some products are commercial, and some are shareware or public domain.
• FreePPP is shareware and can be found on a variety of Internet sites; typically at “info-mac” mirror sites in
the comm/tcp directory. A list of info-mac mirror sites can currently be found at:
http://www.mcp.com.hayden/iskm/info-mac-mirrors.html
Some sites where FreePPP can be found currently include:
ftp://mirrors.aol.com/pub/info-mac/comm/tcp/
ftp://mirror.apple.com/mirrors/Info-Mac.Archive/comm/tcp/
• InterPPP™ and InterPPP II are commercial software products. For availability and ordering information
contact InterCon Systems, US +1(800) 468-7266 or (703) 709-5500.
• MacSLIP is commercial software developed by Hyde Park Software. For availability and ordering information
contact TriSoft, US +1(800) 531-5170 or (512) 472-0744.
• MacPPP (v2.1.4) is available as a part of the Apple Internet Connection Kit, Apple Computer Inc.,
US +1(800) 462-4396 for fax information or +1(800) 538-9696 to locate an Apple reseller near you.
Performance
Q:
Is Open Transport native on PowerPC MacOS? Does this make networking faster?
A:
Open Transport is written to take advantage of the PowerPC™ processor – it is native code. This provides the
necessary foundation for significantly increased networking performance in MacOS. To realize the performance
gains at the application level, however, it is equally important that networking applications also be accelerated
for Power Macintosh, and that applications adopt the new Open Transport XTI programming interfaces.
The compatibility services for existing AppleTalk and TCP/IP applications run as 680x0 code in emulation on
Power Macintosh. This protects a customer's investment in networking applications, but also obscures - or in
some cases, outweighs - the underlying performance increases from the native protocol implementations.

Q:
Does Open Transport PowerPC native code include drivers for Macintosh onboard ethernet?
A:
PCI Power Macintosh systems ship with a PowerPC native DLPI driver for built-in ethernet. Power Macintosh
6100, 7100, and 8100 models currently have 680x0 drivers.
Q:
Will existing networking applications see performance improvements with Open Transport on PowerPC MacOS
systems?
A:
In general, current MacOS networking applications are written for the 680x0 processor and use the classic
networking programming interfaces. These are not likely to see performance boosts with Open Transport, as
most of the performance potential comes from the move to native code for the PowerPC processor. Even for
PowerPC native applications, use of the backward compatibility libraries offsets most of the performance gains
in the low level protocol handling.
Users that select PowerPC native applications that are Open Transport-ready will realize the greatest
performance gains. Performance of specific network applications may also be significantly influenced by the
underlying processor speed of the system. Customers with demanding, network I/O intensive applications
should give strong consideration to the higher performance PowerPC MacOS systems.
However, even with existing applications using backward compatibility, TCP/IP users are likely to see some
performance improvements with Open Transport. This is because of the differences in the way compatibility is
provided for MacTCP vs. AppleTalk, and differences in the two protocol architectures.
Q:
Will networking applications see performance improvements with Open Transport on 680x0 based applications?
A:
Not in general, as most of the potential for increased performance with Open Transport comes from the move to
PowerPC native code. However, users may find that Open Transport TCP exhibits superior performance to
MacTCP, especially under adverse networking circumstances (slow links, lossy lines), due to its more robust
implementation and more sophisticated error handling and recovery.
Q:
When will new or updated applications that support the native Open Transport APIs become available?
A:
Applications that are PowerPC native and Open Transport ready are available now. Users are urged to contact
the specific third party vendor of interest for more details on their specific products.
Q:
How is Open Transport performance being measured?
A:
Apple has established plans for measuring the performance of Open Transport and related system components
through four benchmark test suites:
• SpudPPC - this low-level benchmark tool focuses on measuring the raw throughput potential of Open
Transport. It supports both AppleTalk and TCP/IP protocols, is PowerPC native code, and uses Open
Transport programming interfaces. Because it measures point-to-point, memory-to-memory data transfers,
it most directly measures the performance of Open Transport.
Because this test has the most direct access to Open Transport (the application layer is “thin”), and
because it is fully accelerated for PowerPC, this benchmark will generally indicate an upper bound on the
performance potential of Open Transport.

• AppleShare file copy - this end-user benchmark focuses on measuring the throughput of the AppleShare
client while drag-copying a file from the MacOS desktop using the Finder. It is specific to the AppleTalk
protocol suite, runs in 680x0 emulation, and depends upon backward compatibility services to access Open
Transport networking. Because it measures user-perceived throughput of a complete application chain, this
test only indirectly measures the performance of Open Transport.
Because this test depends upon emulated code, backward compatibility, and AppleTalk protocols, this
benchmark will generally indicate a lower bound on the performance potential of Open Transport.
• Fetch 3.x - this end-user benchmark focuses on measuring the throughput of the popular ftp client, Fetch. It
is specific to the TCP/IP protocol suite, runs as PowerPC native code, and uses Open Transport
programming interfaces. Because it measures user-perceived throughput of a complete application chain,
this test only indirectly measures the performance of Open Transport.
Because this test is PowerPC native, Open Transport ready, and is based on TCP/IP protocols, this
benchmark will generally tend toward the upper bound on the performance potential of Open Transport.
• ZD Labs NetBench 4.0 - this suite of benchmarks is designed to test file server implementations. It is
specific to the AppleTalk protocol suite, runs in 680x0 emulation, and depends upon the File System and
backwards compatibility services to access Open Transport networking. Because it measures user-
perceived throughput of a complete client-server environment, this test only indirectly measures the
performance of Open Transport.
Because this test depends upon emulated code, backward compatibility, and AppleTalk protocols, this
benchmark will generally indicate a lower bound on the performance potential of Open Transport. However,
because it interacts with an AFP server - which may be PowerPC native and Open Transport ready - it can be
useful in measuring the multi-client scaleability of file server implementations built on Open Transport.
Only a combination of tests can provide good coverage, as user-perceived networking performance is heavily
influenced by a combination of a number of MacOS components including the file system, the Finder, driver
code, and the applications used to move data across the network.
Q:
How much faster will native Open Transport applications be?
A:
Networking performance is influenced by many factors. As noted elsewhere in this document, customers will see
the highest performance when using PowerPC native applications that fully support Open Transport APIs.
Performance potential will be greater with protocols that use larger datagram sizes, such as TCP/IP, than with
AppleTalk which has a fixed and limited datagram size. On high-speed datalinks such as fast ethernet, FDDI, or
ATM, both the performance of the network interface card (NIC) driver code and the number of allocated buffers
are significant factors.
Open Transport has been clocked at over 9.3 Mbps using the SpudPPC tool. A pre-release version of a third
party implementation of NFS was benchmarked at over 8.4 Mbps. Both figures approach theoretical maximum
performance for 10 Mbps ethernet.
Q:
What about high-speed networking connections like fast ethernet, ATM, and FDDI?
A:
Benchmarking on fast ethernet, FDDI, and ATM datalinks has been underway for some time. Some sample
results include:
• 48 Mbps with a RNS (formerly Rockwell) fast ethernet card and driver (1500 byte block size)
• 72 Mbps with a RNS FDDI card and driver (4K block size)
• 93 Mbps with an Interphase ATM-155 card and driver (8K block size)
These tests were performed using Open Transport/TCP 1.1 beta software, running on a Power Macintosh
9500/132, using the SpudPPC tool.
Other tests, such as a the one conducted by Fore Systems on their 155 Mbps ATM cards, have shown even
higher throughput. In one test, Fore was able to transmit UDP over their LAN-E stack on ATM (using 1500 byte
datagrams) at over 100 Mbps.
AppleTalk performance is lower than TCP/IP performance due to the smaller DDP packet size and the ATP retry-
acknowledgment algorithm. Current testing on fast ethernet is turning in figures around 35-45 Mbps with a
PowerPC native ATP test tool. This is a significant performance improvement, and further progress should be
realized as application code is revised to take full advantage of Open Transport and PowerPC.

Q:
Does Open Transport support the use of large datagram sizes? Does datagram size have an impact on network
throughput?
A:
Maximum allowable datagram size is dependent on both the selected datalink and the selected protocol stack.
Open Transport supports the use of large datagram sizes as appropriate to the protocol and datalink in use.
Because Open Transport/AppleTalk is based on the Phase 2 architecture, datagram size for AppleTalk is limited
to a maximum of 617 bytes. Open Transport/TCP supports larger datagrams; up to 1,500 bytes on ethernet and
fast ethernet, and up to 16K on token ring; even larger block sizes can be used on FDDI and ATM.
Block size does play a role in maximum throughput; the larger the block size used, the greater the potential end-
to-end throughput. Users demanding the highest network throughput may find FDDI to be a more attractive
alternative than fast ethernet because it can support larger block sizes at the same bit rate.
Open Transport and Servers

Q:
What role does Open Transport play for servers?
A:
The Open Transport architecture is designed to provide server applications – file, print, database, e-mail,
directory, and other – with a foundation for higher performance and for more flexible configuration, while
maintaining the historical differentiation of MacOS servers – ease of configuration and administration.
Q:
How will Open Transport enhance server flexibility?
A:
Open Transport introduces the capability of activating more than one network connection at the same time,
using the same networking protocol. This capability is known as multihoming, and enables servers to support
more clients, to offer greater total performance, and to increase the reliability of mission critical applications.
Open Transport also enables the development of transport independent applications. This will be especially
valuable for server applications which need to be deployed in AppleTalk, or TCP/IP, or NCP/IPX, or other
protocol environments.
Q:
How will Open Transport enhance server performance?
A:
Servers, as network-aware applications, gain access to the higher performance PowerPC native implementation
of networking protocols that Open Transport provides. To exploit this performance opportunity, server
applications must be accelerated for PowerPC and must utilize the new Open Transport XTI APIs.
Severs will also benefit through access to new high-speed PCI datalink implementations such as fast ethernet
and ATM.
Q:
Will Apple’s server products such as AppleShare exploit Open Transport features?
A:
Yes. AppleShare 4.2.1 is the first version of AppleShare to be both PowerPC native and Open Transport ready. It
takes advantage of other Open Transport features as well, including support for multihoming.

Q:
Are PCI MacOS systems with Open Transport recommended as application servers?
A:
Apple recommends that server application developers adopt Open Transport v1.1 as the basis for new network
applications development as soon as is possible within their product life cycles. As these updated versions of
server software become available customers will find that the combination of PCI, Power Macintosh, and Open
Transport makes a great platform for flexible, high-performance network applications.
It should also be noted that Apple generally recommends the Apple WorkGroup Server product family, rather
than re-purposed desktop hardware, for use as server platforms.
Open Transport and Cross-Platform Issues

Q:
Will Apple port Open Transport to Windows or UNIX?
A:
Apple does not plan to port Open Transport to other operating systems. Rather, Open Transport is based on
Apple porting three existing, cross-platform industry standards to MacOS. These standards have their roots in
the UNIX community and experienced UNIX network developers will find themselves “right at home” when
developing for Open Transport.
Q:
What about Windows developers? What about Windows Sockets?
A:
NetManage, the leading developer of TCP/IP protocols and applications for DOS and Windows, now offers
Windows Socket tools for MacOS, to provide access to Open Transport/TCP and MacTCP services via the
Windows Sockets (Winsock 1.1) API.
NetManage's WinSock for the MacOS is WinSock 1.1 compliant and is being certified by the WinSock Labs
operated by Stardust Technologies, Inc., which performs compatibility testing. The SDK for MacOS costs $250
per license, with free distribution.
For more information, contact NetManage at +1 408 973-7171.
Q:
With both XTI and Windows Sockets available for Open Transport, which API should a developer use?
A:
The choice of API will depend upon a developer’s background, experience, and goals. For developers with a
background in UNIX, a need for POSIX compliance, or a need to deploy an application across MacOS and UNIX
systems, XTI is the logical choice. For developers with a background on Microsoft Windows, or a need to deploy
an application across MacOS and Windows, Windows 95, and/or Windows 95 systems, the planned Winsock
tools from NetManage will provide an attractive cross-platform alternative.
Apple is committed to XTI and will focus development on transport independence around this API. MacOS
developers now using classic AppleTalk or MacTCP APIs are encouraged to move to Open Transport XTI API.
Apple Adoption of Open Transport

Q:
When will Open Transport become part of MacOS?
A:
Open Transport is a standard component of the MacOS beginning with System 7.5.3 (System Update 2.0).
Open Transport v2.0 is being developed as an integral part of MacOS 8; support is planned for all MacOS 8
platforms, including the Power PC Platform (PPCP), formerly know as the Common Hardware Reference Platform
(CHRP).

Q:
What Apple products will support Open Transport? Will these also be native on Power Macintosh?
A:
Apple includes or plans to include support for Open Transport in the following products, as well many other
unannounced products:
• Apple Remote Access 3.0
• MacSNMP 1.5
• MacOS 8

Developer Adoption
Q:
Which third party developers support Open Transport?
A:
Seeding of Open Transport among developers began more than a year in advance of release, and reached more
than 5,000 developers. Several hundred developers are actively working with Apple on development efforts.
The following software developers are among those who have announced support for Open Transport to date:
• ACI • Neon Software
• Adobe Systems • NetManage, Inc.
• AG Group • NorthWestern University
• AGE Logic, Inc. • Novell
• Asanté • Pacer Software
• Atomic Games • Pole Position Software GmbH
• Carnegie Mellon University • Progressive Networks
• CE Software • Quark, Inc.
• Claris Corporation • Remedy Corp.
• Dantz Development • Seaquest Software
• Delphic Software, Inc. • SoftArc
• Digital Ocean • StarNine Technologies, Inc.
• EveryWare Development Corp. • Stairways Software
• Farallon Computing, Inc. • Starlight Networks
• Gradient Technologies • Systematics Softworks GmbH
• HI Resolution Software • The University of Michigan
• Hughes Advanced Systems • The Wollongong Group
• IBM • Thursby Systems Software, Inc
• Intercon Systems, Inc. • Vicom Technology
• Maxum • Wall Data
• Mentat Inc. • White Pines
• Metrowerks, Inc. • WRQ
The following developers have announced support for both Open Transport and PCI on Power Macintosh:
• Asanté • Innosys
• Attachmate • Interphase
• Creative Solutions • Newer Technology
• Dayna • Neutral
• Digiboard • QLogic
• Digital Equipment Corporation • RNS (formerly Rockwell)
• Efficient NW • SAT/Sagem
• Farallon Computing, Inc. • SCii Telecom
• Focus • Silicon Valley Bus
• Fore Systems, Inc. • Spectra Systems
• 4-Sight International Limited • Workstation Technologies
• Hermstedt GmbH

Future Directions
Q:
What is the next planned release of Open Transport?
A:
Open Transport 1.5 is the next planned release of Open Transport. OT 1.5 is planned to be feature-driven, and is
expected for release in CY1997. Some of the key features planned include:
• AppleScript support in AppleTalk and TCP/IP control panels
• API for developers to access configuration data
• Integrated PPP
• Multi-homing for AT & TCP
• Multi-node support for AT & TCP
• SNMP support
Q:
What about the Apple Internet Router? Will it be revised for Open Transport?
A:
Apple is not announcing future plans regarding this product at this time.
Q:
Will Apple or Novell deliver an Open Transport-ready MacOS client that uses IPX protocols?
A:
Novell currently offers the NetWare Client for MacOS v5.1, providing access to file, print, and NetWare Directory
Services (NDS) using NCP/IPX protocols.
An Open Transport-ready implementation of NetWare protocols and client services is currently under
investigation. The two companies are not ready to announce product details or availability at this time.
Q:
Will Apple or Microsoft deliver an Open Transport-ready MacOS client that uses NetBIOS/TCP protocols?
A:
Windows NT AS currently includes strong MacOS connectivity solutions based on AppleTalk protocols. Other
protocol options are under investigation at Apple, Microsoft, and with third parties. No additional details are
available at this time.
Q:
What standards are to be supported by OT/PPP?
A:
. Dial-up access to AppleTalk and TCP/IP networks will be based on the following RFCs:
• RFC 1661 - PPP
• RFC 1662 - PPP in HDLC-like framing
• RFC 1570 - PPP LCP extensions
• RFC 1334 - PPP Authentication protocols
• RFC 1663 - PPP Reliable transmission
• RFC 1378 - ATCP AppleTalk Control Protocol
• RFC 1332 - IPCP Internet Protocol Control Protocol

Q:
Is there currently an implementation of the IP Security Protocol (ipsec) available for Open Transport?
A:
The IP Security Protocol (ipsec) implementations are currently being investigated by Apple and 3rd Party
developers but Apple is not aware of any shipping implementations at this time.
Q:
Where can I get more information about ipsec?
A:
The IP Security Protocol (ipsec) is described in detail in documents from the Internet Engineering Task Force.
More information is available from the IETF web site: http://www.ietf.org/html.charters/ipsec-
charter.html
Q:
What about IP version 6 (IPv6) support in Open Transport?
A:
IPv6 is an proposed update of the current Internet Protocol (IPv4), part of the TCP/IP suite of protocols used to
allow computers to communicate with each other over the Internet. The Internet Engineering Task Force (IETF) is
in the process of specifying the standards for IPv6.
IPv6 is being designed to respond to the limitations of IPv4 – including an upcoming shortage of new IP
addresses – to allow for the continued expansion of the Internet and deployment on corporate networks. IPv6
also incorporates new functionality to provide security, multimedia support, and plug and play capabilities,
features necessary to usher the Internet into the twenty-first century.
At the October 1995 Networld+InterOp trade show, Apple and Mentat demonstrated a prototype of Internet
Protocol Version 6 running on Open Transport. The demonstration showed the flexibility of the Open Transport
environment – with current IPv4 applications such as Fetch, Netscape, and WebStar running unmodified with
IPv6 support – and showed the benefits of Open Transport’s underlying standards based architecture -
facilitating code portability. The demonstration also included basic interoperability testing with IPv6 prototype
implementations from DEC and HP, using standard IP utilities such as Ping and Telnet.
Apple and Mentat will continue to work together to ensure timely availability of IPv6 for MacOS once the standard
has been completed.
Q: AppleTalk TCP/IP Transport

Independent
Will Open Transport v2.0, for MacOS 8, offer any Application Application Application
new capabilities?
Copland OS Protected Memory

A: XTI
STREAMS
Yes. Open Transport v2.0 is being designed to take
full advantage of the new microkernel services
available in MacOS 8. As a result, Open Transport
networking on MacOS 8 is planned as a set of AppleTalk TCP/IP IPX
multithreaded, preemptively scheduled tasks
running in protected memory.
To a user, this will mean that networking will be even
more robust and higher performance. To a DLPI
developer, this will mean that a rogue application
running in another memory space will not be able to
corrupt system level networking task. Built In PCI Bus PCMCIA
Network Network Interface Network
Figure 2 provides an overview of Open Transport
running on MacOS 8. Figure 2. Open Transport Architecture
In addition, Open Transport v2.0 is expected to incorporate a second generation update to the human interface
introduced with Open Transport v1.0.

Current plans call for this release to include support for features such as:
• Configuration selection will be integrated with system level workspaces and the location assistance toolbox;
• Advanced end-users and network administrators will be able to configure a protocol stack for simultaneous
support of multiple network connections (multihoming);
• Administrators will find additional trouble-shooting tools (such as Ping, traceroute, local ARP cache, access
to local routing tables, and others) integrated with the configuration utilities;
• Support for AppleScript™; and
• Desktop aliases for network configurations to allow double-click reconfiguration of services.
Open Transport 2.0 is also planned to include integrated support for NetWare/IPX, X.25, ATM, and ISDN.
For More Information

Q:
How can interested parties get more information on Open Transport?
A:
Documentation for Open Transport is publicly available by anonymous ftp on the Internet at a number of sites,
including ftp://seeding.apple.com/opentransport/.
Q:
Can customers apply to receive pre-release copies of Open Transport for implementation testing?
A:
The Open Transport Early Access program provided pre-release access to Open Transport v1.1. Since the
product is now shipping, pre-release seeding of the Open Transport 1.1 has been discontinued. As plans for
future versions of Open Transport develop, Apple expects to offer a similar customer testing and preview
program. Announcement of details will occur at the appropriate time.
Q:
Can developers apply to receive pre-release copies of Open Transport for development and testing?
A:
The Open Transport v1.1 developer seeding program reached over 5,000 developers. Since the product is now
shipping, pre-release seeding of the Open Transport 1.1 has been discontinued. A new seeding program is
anticipated for future versions of Open Transport. Details will be announced at a later date.
The Open Transport software developers kit (SDK) is available as a component of the MacOS SDK, and is
available on the Internet at ftp://seeding.apple.com/ess/public/opentransport/SDK OT Client
Q:
How can developers get support while developing Open Transport applications?
A:
Apple Developer Support services have engineering specialists fully trained on Open Transport development
and debugging. Access to these engineers is just one of the benefits of the Apple Developer Partner’s program.
For more information on Apple’s Developer Support services, including information on how to register as an Apple
Developer Partner, contact the Macintosh Developer Services Information Line at US +1(408) 974-4897.
For developers not a part of Apple’s Developer Support services programs, Apple has assigned evangelism
resources to the support of Open Transport. All interested developers are encouraged to contact Open
Transport Evangelism by email to opentpt@seeding.apple.com.

Q:
Are there general reference sources on XTI, STREAMs and DLPI?
A:
Sources of information that are applicable to XTI and STREAMs include:
• OSF/1 Operating System: Network Applications Programmer’s Guide; Open Software Foundation,
Prentice Hall, ISBN 0-13-640145-7
• UNIX Network Programming; W. Richard Stevens, Prentice Hall, ISBN 0-13-949876-1
• UNIX System V Release 4: Programmer's Guide: STREAMs; Unix Press (A Prentice Hall title),
ISBN - 0-13-020660-1
• Programming UNIX SVR4.2: Network Programming Interfaces; UNIX Press (A Prentice Hall title),
ISBN 0-13-017641-9
• X/Open CAE Specification: X/Open Transport Interface (XTI); X/Open Company, Ltd. (XO/CAE/91/600)
ISBN 1-872630-29-4
• Transport Provider Interface Specification, rev 1.5 (92/12/10); UNIX International,
OSI Special Interest Group
• Data Link Provider Interface Specification, rev 2.0.0 (91/08/20); UNIX International, OSI Work Group

Open Transport Q&amp;A 2.3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Open Transport Q&amp;A 2.3

Uploaded by

Copyright:

Available Formats

Apple

New and substantially revised material in this version is

Version 2.3 (OT 1.1.1 GM release) October 11, 1996

Updated: October 11, 1996 Page ii

Updated: October 11, 1996 Page iii

Updated: October 11, 1996 Page iv

Updated: October 11, 1996 Page 1

Key Features and Benefits

Updated: October 11, 1996 Page 2

Updated: October 11, 1996 Page 3

Updated: October 11, 1996 Page 4

Updated: October 11, 1996 Page 5

Updated: October 11, 1996 Page 6

Updated: October 11, 1996 Page 7

Updated: October 11, 1996 Page 8

Updated: October 11, 1996 Page 9

Updated: October 11, 1996 Page 10

Updated: October 11, 1996 Page 11

Updated: October 11, 1996 Page 12

Factors which contribute to differences in memory requirements include:

Updated: October 11, 1996 Page 13

Open Transport and MacOS System 7.5.3

Updated: October 11, 1996 Page 14

Updated: October 11, 1996 Page 15

• the configuration of the system where 7.5.3 was installed;

Updated: October 11, 1996 Page 16

Updated: October 11, 1996 Page 17

Updated: October 11, 1996 Page 18

Updated: October 11, 1996 Page 19

Open Transport and MacOS System 7.5.5

Updated: October 11, 1996 Page 20

Availability and Distribution

Updated: October 11, 1996 Page 21

Updated: October 11, 1996 Page 22

• through an OEM redistribution licensing program from Apple Software Licensing,

Updated: October 11, 1996 Page 23

Updated: October 11, 1996 Page 24

Network Interface Options

Network Planning & Administration

Updated: October 11, 1996 Page 25

Updated: October 11, 1996 Page 26

Updated: October 11, 1996 Page 27

Updated: October 11, 1996 Page 28

Apple and third party developers have announced

Open Transport includes software libraries that

Updated: October 11, 1996 Page 29

Updated: October 11, 1996 Page 30

Updated: October 11, 1996 Page 31

Updated: October 11, 1996 Page 32

Updated: October 11, 1996 Page 33

Updated: October 11, 1996 Page 34

Updated: October 11, 1996 Page 35

Updated: October 11, 1996 Page 36

Updated: October 11, 1996 Page 37

Updated: October 11, 1996 Page 38

Open Transport and Servers

Updated: October 11, 1996 Page 39

Open Transport and Cross-Platform Issues

Apple Adoption of Open Transport

Updated: October 11, 1996 Page 40

Updated: October 11, 1996 Page 41

Updated: October 11, 1996 Page 42

Updated: October 11, 1996 Page 43

Q: AppleTalk TCP/IP Transport

Open Transport Q&A 2.3

Open Transport Q&A 2.3