Path: news1.ucsd.edu!ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!lll-winken.llnl.gov!apple.com!seeding.apple.com!user From: garryh@seeding.apple.com (Garry Hornbuckle) Newsgroups: comp.sys.mac.comm Subject: Open Transport FAQ part five - System Requirements Date: Tue, 31 Oct 1995 08:46:23 -0800 Organization: Apple Computer, Inc. Lines: 261 Message-ID: NNTP-Posting-Host: seeding.apple.com Apple Open Transport Frequently Asked Questions Part Five - System Requirements, Availability & Distribution, Network Planning & Administration Extracted from: Open Transport Background Q & A Version 1.8 (OT 1.0.8 Release) October 19, 1995 System Requirements Q: Which MacOS systems will be able to take advantage of Open Transport? A: Open Transport is designed to work on any Apple Macintosh or MacOS compatible computer with a Motorola 68030 or 68040 family microprocessor, or a PowerPC 601, 603, or 604 microprocessor. Systems supporting Open Transport must be running System 7.5.x. For 680x0 Macs, 8 MB of total memory is recommended. For Power Macintosh computers, 12 MB of total memory is recommended. Open Transport is compatible with the use of Virtual Memory, and takes full advantage of the Power Macintosh Code Fragment Manager to offer a much lower system RAM footprint when VM is turned on. Q: Is Open Transport available for all these systems now? A: Open Transport v1.0 was initially released to support only the Power Macintosh 9500. Beginning with v1.0.6, Open Transport is designed to support all PCI-bus Power Macintosh models, including the Power Macintosh 7200, 7500, 8500, and 9500 systems. Support for 680x0 and NuBus-based Power Macintosh systems is planned for release later in 1995. Q: Will Open Transport v1.0.x run on other Macintosh systems? A: The installer for Open Transport v1.0.x is designed for use specifically on the PCI-bus Power Macintosh systems. While it would be possible to move such an installation of Open Transport to another Macintosh system (for example, on an external hard drive), it is not supported by Apple and is not recommended. Q: Why was Open Transport made available on PCI-bus Power Macintosh CPUs 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 bus. This strengthened the business case for new and existing third party developers who could, as a result, include Power Macintosh 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-based Power Macintosh systems. It also minimized the work by third parties needed to create drivers for new PCI-bus networking cards. As a result, customers are able to find a broad selection of third party networking options for Macintosh with PCI bus. Q: Can PCI-bus Power Macintosh systems run "classic" AppleTalk or MacTCP instead of Open Transport? A: Open Transport is required to support PCI-bus networking. Beginning with the Power Macintosh 9500, classic networking applications are supported through Open Transport backward compatibility. Availability and Distribution Q: What is the current production version of Open Transport? A: Open Transport v1.0.8. This maintenance release was designed and is recommended for all PCI-bus Power Macintosh systems. It includes the following changes: * Open Transport/AppleTalk's DDP implementation will now properly handle a checksum of $FFFF. In earlier versions, packets with a checksum of $FFFF would be rejected, resulting in unnecessary retransmissions of data. * When attempting to verify addresses with the QuickMail 3.0.4 client, the software would come back with an error message that read "NameServer Communications Error. Try again, or increase time outs for NameServer using QM Time outs." This bug has been fixed. * Corrected a bug in the Open Transport/TCP control panel that could, under some circumstances, prevent the acceptance of the gateway and domain name server information provided by the BootP server. * Problems with sending mail from Eudora when using SLIP or PPP have been fixed. * Aborting NetScape connections could sometimes cause a crash. This problem has been fixed. * Previous versions of Open Transport/TCP were unable to fully configure from Windows NT DHCP servers. Unlike most DHCP servers, Windows NT does not provide DHCP options unless specifically requested by the client. Open Transport/TCP 1.0.8 now requests a domain name, default gateway address, domain name server address(es), subnet mask, and subnet broadcast address, in addition to an IP address. More complete details on the changes incorporated in v1.0.8 are found in the current Open Transport Release Notes. These are available by anonymous ftp from ftp://seeding.apple.com/opentransport/ Q: How is Open Transport v1.0.8 made available to customers? A: Open Transport v1.0.8 is planned to be distributed via a variety of information services such as eWorld, and a number of Internet sites including ftp://seeding.apple.com/opentransport/. This release is distributed as a full installation of Open Transport software - not an updater or patcher. The software is only designed to work on PCI-bus Power Macintosh systems, and is recommended to customers who are experiencing one or more of the problems identified above as fixed with the 1.0.8 release. Q: Summarize the earlier Open Transport v1.0.x releases? A: Open Transport version 1.0 was focused on offering strong backward compatibility with existing networking client applications, and on significantly upgrading the feature set and performance of TCP/IP on the MacOS. Version 1.0.1 was a maintenance update, designed to correct a potential problem with data truncation in large file transfers. Version 1.0.6 added support for the Power Macintosh 7200, 7500, and 8500 systems, and addresses bugs discovered since the initial 1.0 release. Version 1.0.7 included further changes to improve performance and compatibility of Open Transport/TCP with third party SLIP and PPP connections, and to accommodate certain Internet Service Provider (ISP) address assignment practices. Q: How was Open Transport v1.0.7 made available to customers? A: Open Transport v1.0.7 is distributed electronically, as an update to be applied to an existing installation of Open Transport v1.0.6. The update is available on a variety of information services, including eWorld and a number of Internet sites including ftp://seeding.apple.com/opentransport/update/OT_1.0.7_patch/ Q: How was Open Transport v1.0.6 made available to customers? A: Open Transport v1.0.6 ships as a built-in component of MacOS system software (System Software 7.5.2 version 2) on the Power Macintosh 7200, 7500, and 8500 models. Software on newly manufactured Power Macintosh 9500 systems is updated to this release as well. ustomers who previously bought a 9500 can get this system software update (which contains System 7.5.2 version 2 and Open Transport 1.0.6) by calling 1-800-769-2775 ext. 5617. This system software update is recommended for all Power Macintosh 9500 customers. Q: Will Open Transport be made available to software developers, publishers, and/or Internet Service Providers (ISPs) for redistribution and bundling options? A: Yes. Following the availability of Open Transport v1.1 Apple is planning to offer two redistribution licensing agreements for Open Transport, to meet the needs of publishers, developers, and ISPs. he 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 planned to be based on a sliding-scale per-unit license fee, and will require annual reporting of licenses issued. he 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 to be based on the MacOS SDK, and would allow qualified developers to ship the Open Transport run-time environment to end-users as a part of their product. o qualify, developers would execute the Open Transport License Addendum, and meet the following requirements: * have developed an Open Transport-ready or Open Transport-enhanced software product, * 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 may apply, however, no additional fees (beyond the MacOS SDK subscription) are planned for this license. Final details on these agreements will be available later this year. Interested developers should send electronic mail to OT.LICENSE@seeding.apple.com Network Planning & Administration Q: Will 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 does require 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. See TCP/IP Features for more information. 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: Can Open Transport/TCP act as a DHCP client to a Windows NT Advanced Server? A: Yes. However, due to significant differences between the Microsoft Windows NTAS implementation of DHCP and typical UNIX-based servers, there have been some interoperability issues with Open Transport 1.0.x: * Customers running Open Transport v1.0 or v1.0.1 will not be able to acquire leased IP addresses. This is 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. * Customers running versions of Open Transport prior to v1.0.8 will be incompletely configured via DHCP. NTAS sends only IP address, IP address lease information, the configuring server's IP address, and a subnet mask. Investigation revealed that other configuration options entered in the NT DHCP server's database (default gateway address, domain name server addresses, domain name, broadcast address, etc.) were not sent unless specifically requested by the client using the DHCP Parameter Request List option. Apple believes that this practice - requiring use of this option in order for the client to be properly configured - is contrary to the DHCP server specification described in RFC 1541 (Dynamic Host Configuration Protocol). This RFC documents the Parameter Request List option as a MAY, rather than a MUST or SHOULD, making required use of the parameter inappropriate. Further, this behavior appears to be unique to the NTAS implementation. In interest of interoperability, Open Transport v1.0.8 (and the planned v1.1) uses 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 Windows NT DHCP servers, without adversely affecting interoperability with other fully compliant DHCP 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. ------------------------------------------------------------------- Garry Hornbuckle Product Manager, Communications & Collaboration ------------------------------------------------------------------- "If I told you that I | email garryh@seeding.apple.com spoke only for myself | applelink HORNBUCKLE1 would you believe me?" | fax (408) 974-1211 -------------------------------------------------------------------