TOPIC
This article is the Reference Q & A (questions and answers) on network planning and administration for Open Transport 1.1.
DISCUSSION Question : Does Open Transport offer network managers more control over Mac OS networking? Answer : 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". Question : Will Open Transport require organizations to make changes in network administration, planning, or design? Answer : 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. Question : Does the use of AppleTalk manual addressing increase the requirement for network administration? Answer : 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 (that is, 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. Question : Are there other benefits that arise from the new support for AppleTalk manual addressing? Answer : Yes. Manual configuration of static AppleTalk addresses supports Mac OS products that utilize WAN datalinks where non-full-mesh topologies are important. This includes datalinks such as Frame Relay, SMDS, and ATM. Question : Does Open Transport/TCP support BootP? Answer : Yes. Open Transport v1.1 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, that is, xxx.xx.x.255; replies sent to the all-nets broadcast address (that is, 255.255.255.255) were handled properly. Both situations are correctly handled by Open Transport v1.1. Open Transport 1.1 now also supports BootP gateways located 1 or more hops away. Earlier versions of Open Transport required that the BootP gateway be zero hops away. Question : Which DHCP servers are supported by Open Transport/TCP? Answer : 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 ). Question : Does Open Transport/TCP support DHCP address leases? Answer : 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. Question : Are there interoperability issues of note regarding DHCP servers? Answer : Some DHCP servers require padding to a fixed packet size; other servers do not accept padded packets. Open Transport 1.1 automatically adapts to the type of DHCP requests that a given server accepts, while earlier versions sent non-padded packets. Network managers should also note that Open Transport 1.1 now supports DHCP gateways located one or more hops away. Earlier versions of Open Transport required that the gateway be zero hops away. Question : Can Open Transport/TCP act as a DHCP client to a Windows NT Advanced Server? Answer : Yes. With Open Transport v1.1, Mac OS clients are fully interoperable with the Windows NTAS DHCP server. Macintosh clients running earlier versions of Open Transport (1.0.x) could experience some of the following 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. 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, and so on) were 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 described in RFC 1541 (Dynamic Host Configuration Protocol), and it appears to be unique to the NTAS implementation. However, in interest of interoperability, Open Transport v1.0.8 and v1.1 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. Question : Can Open Transport/TCP act as a WINS client to a Windows NT Advanced Server? Answer : 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 Mac OS WINS client would be dependent upon Microsoft releasing sufficient technical detail regarding their proprietary extensions to IP to make an interoperable implementation possible. Question : When installing and configuring Open Transport, are there any additional issues of note for network managers? Answer : The following observations and comments have been developed based on the recent OT 1.1 b16 Internet-based public preview program. * 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, some configuration changes may be desirable or necessary. Areas of interest and caution are noted in the section TCP/IP Features and System Requirements. * Network managers should also 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 will be displayed in the TCP/IP control panel. This will be resolved in a release after OT 1.1. * Users are occasionally encountering "Error -3205" when opening a connection in a TCP application. This can result if the user has manually modified (moved, renamed, or deleted) some of the files installed by Open Transport. In particular, both the Shared Library Manager and Shared Library Manager PPC files must be installed when running on a PowerPC Mac OS system. For more information on these two files, refer to the description of files installed by Open Transport elsewhere in this Q&A. 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) some of the files installed by Open Transport. In particular, the MacTCP DNR file must remain in the System Folder at the root level for backward compatibility to function. In general, users should not attempt to modify the OT installation through any means other than the Apple supplied installer scripts. * Beginning with System 7.5, TCP/IP support was included with the Mac OS 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. |
Document Information | |
Product Area: | Communications-Networking |
Category: | Open Transport |
Sub Category: | General Topics |
Copyright © 2000 Apple Computer, Inc. All rights reserved.