NYU-NET Technical Handbook
Upcoming SlideShare
Loading in...5

NYU-NET Technical Handbook






Total Views
Slideshare-icon Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    NYU-NET Technical Handbook NYU-NET Technical Handbook Document Transcript

    • NYU-NET Technical Handbook Help & Information > Computer Security > Documentation > Multi-User Guidelines Search the ITS Site NYU-NET TECHNICAL HANDBOOK Submit First Edition, Revised, August 26, 1994 [Ed: This document is for reference only. Much of the information contained within is now outdated. Please note especially that ACF is now known as Information Technology Services. If you have questions about the accuracy of information contained within this document, please write to its.pubs@nyu.edu.] Table of Contents q Audience q Acknowledgment q 1. Introduction q 2. Overview of NYU-NET r 2.1 Description r 2.2 Connection to Internet r 2.3 The Management of NYU-NET r 2.4 The Network Operations Center q 3. History of the NYU-NET Infrastructure q 4. Standard Practices and Policies r 4.1 Local Network Manager Obligations r 4.2 Network Changes r 4.3 Security Issues r 4.4 Internet Access r 4.5 Host Configuration Issues q 5. Major Protocol Suites on NYU-NET r 5.1 TCP/IP r 5.2 DECnet and Related Protocols r 5.3 Novell IPX/SPX r 5.4 AppleTalk q 6. Configuration Guidelines r 6.1 Summary of Requirements r 6.2 Network Management Aspects - SNMP q 7. Configuration Guidelines: TCP/IP Hosts r 7.1 General Points r 7.2 Fundamental TCP/IP Information r 7.3 Unix Workstation r 7.4 Apple Macintosh r 7.5 IBM PC q 8. Configuration Guidelines: Routers r 8.1 General Router Issues r 8.2 IP Router Configuration q 9. Configuration Guidelines: AppleTalk Routers r 9.1 General Configuration Aspects r 9.2 Shiva Fastpath Configuration r 9.3 Novell NetWare Configuration q 10. Configuration Guidelines: Novell NetWare r 10.1 NetWare File Server r 10.2 NetWare PC Client http://www.nyu.edu/its/security/handbook.html (1 of 55)8/31/2006 1:23:12 PM
    • NYU-NET Technical Handbook q 11. Guidelines for Setting Up Departmental LANs q 12. NYU-NET Purchasing Guidelines r 12.1 Advisory: Peer-to-Peer Networking r 12.2 Advisory: Network Modem Products r 12.3 Standard Brands on NYU-NET q Glossary q Appendix A: A Description of NYU-NET q Appendix B: Obtaining Network Names and Numbers q Appendix C: Notes on Peer-to-Peer Networking at NYU q Appendix D: MacTCP - Availability and Installation q Appendix E: Recommended Readings q Addendum 1.9: Changes to the NYU-NET Technical Handbook q Addendum 2.0: Primary NYU-NET Contacts q Addendum 3.0: NYU-NET Architecture Diagram q Addendum 4.0: NYU Staff with Network Responsibilities q Addendum 5.0: Recent NYU-NET Developments q Addendum 6.0: List of TCP/IP Subnets q Addendum 7.8: Current Microcomputer Networking Software q Addendum 8.0: AppleTalk on NYU-NET q Addendum 9.0: Viruses and Novell NetWare q Addendum 10.0: NetWare 4 and NYU-NET. q Addendum 11.0: Policy on Internet Access Audience The primary audience for this handbook is NYU staff members responsible for planning, purchasing, configuring, and managing the systems and network infrastructure devices which collectively form NYU-NET, New York University's campus-wide data communications network. Acknowledgment Portions herein are based on internal ACF networking documentation developed by Bill Russell, senior networking engineer. Technical review has been performed by staff of the Academic Computing Facility's technical services group. This document has also been reviewed for accuracy and acceptability by representatives of the university's Data Communications Task Force. Corrections or suggestions should be directed to Gary W. Chapman; send electronic mail to chapman@nyu.edu. 1. Introduction This handbook describes technical aspects of NYU-NET, the university's campus-wide data communications network. Two basic kinds of information are contained here: q technical details relevant to configuring various types of devices and systems attached to the network, and q descriptions of standard practices and policies that must be observed on a large and complex network like NYU-NET. Chapter 4 on Standard Policies and Practices, in particular, describes many of the obligations of computer and network managers at New York University. In the 1990s, a communications network like NYU-NET is a complex and evolving system: countless hardware and software components are used by a rapidly increasing number of students, faculty, research, and support staff as an integral part of their academic lives. NYU-NET intermixes computer and communications technologies spanning two decades of technological evolution, with no end of new developments in sight. As a cooperative venture -- both at the level of human use and at the level of interrelated hardware and software components -- every new addition or modification to NYU-NET must fit into the established system in a conformant, seamless fashion. It is the task of the university's computing and networking staff to preserve the smooth running of http://www.nyu.edu/its/security/handbook.html (2 of 55)8/31/2006 1:23:12 PM
    • NYU-NET Technical Handbook NYU-NET while extending its use and its capabilities. The primary audience for this handbook are such staff members: network and system managers responsible for planning, purchasing, configuring, and managing the systems and network infrastructure devices which collectively form NYU-NET. These staff members are often referred to here as "local network managers." The Network Operations Center (NOC) of the Academic Computing Facility is the focal point for NYU- NET coordination, information, and central network management activities. To reach the NOC: Via E-Mail (preferred): noc@nyu.edu Via Telephone: (212) 998-3450 or 998-3333 (the ITS Helpline) This first edition of a NYU-NET handbook does not attempt the impossible: a complete description of all technical aspects of configuring and managing elements of the network. It does attempt to touch upon the most fundamental issues relating to configuration of the most popular protocols and kinds of devices currently used on the network. Please note that some portions of this handbook, especially its addenda, are subject to frequent update as changes to NYU-NET take place. The handbook, and the latest versions of these sections, may be obtained electronically via anonymous ftp from acfcluster.nyu.edu in files nyunet/handbook. * It will also be available from the NYU Gopher-based Campus-Wide Information System in the NYU- NET section (gopher to gopher.nyu.edu, port 70). 2. Overview of NYU-NET 2.1 Description NYU-NET is New York University's campus-wide data communications network. A computer network - especially one the size of NYU-NET - is a complex assemblage of wiring, network infrastructure devices, computer systems, and software which together allow for communications between the connected computers - and therefore between computer users. The different kinds of communications which take place between computers and computer users are, collectively, termed "network services". Examples include: electronic mail, data file transfer, access to local and remote library catalogs and databases, and access to campus-wide information systems. As of January 1993, NYU-NET interconnects more than 3500 computer systems located in over 40 NYU buildings. The network encompasses the Washington Square campus, the Dental Center, and Medical Center facilities in Manhattan and Sterling Forest. NYU-NET is a rapidly evolving and growing communications network, with steady addition of new locations, infrastructure devices, computers, services, and users. A good way to understand NYU-NET is as a hierarchy of computer networks: small departmental networks in buildings; buildings tied together at each campus; each campus connected to the other campuses; and the whole of NYU-NET connected to the national and international communications network, the Internet. See Appendix A for a more technical definition and description of NYU-NET. Addendum 3 contains an overview diagram of some major NYU-NET elements. 2.2 Connection to Internet NYU-NET is one of the thousands of computer networks which, together, comprise the Internet. Universities, private companies, government agencies, research installations and, increasingly, private individuals are interconnected via this world-wide network of networks. More than 1.3 million computers are connected world-wide to the Internet with the number growing at an apparently geometrical rate. 2.3 The Management of NYU-NET NYU-NET and its link to the world-wide Internet are managed by the Academic Computing Facility's network operations staff at our Network Operations Center - in cooperation with the cross-university Data Communications Task Force and scores of local, departmental network management staff. The network, therefore, is maintained in a collaborative, cooperative fashion by computer and networking experts from many divisions of the university. The Academic Computing Facility operates the Network Operations Center, which contains a variety of monitoring and fault-detection tools used to maintain NYU-NET; the staff works closely with computing professionals from around the university to ensure the smooth workings of the network, http://www.nyu.edu/its/security/handbook.html (3 of 55)8/31/2006 1:23:12 PM
    • NYU-NET Technical Handbook and to quickly solve problems if they arise.The ACF also provides many educational, consulting, installation, and management services for members of the community who wish to learn about and begin to use NYU-NET, and to departmental representatives who wish to attach departmental computers to the campus-wide network. 2.4 The Network Operations Center A network operations center is a fundamental resource for managing a large and diverse internet like NYU-NET. It is concerned, from a central vantage point, to: q Maintain network standards The NOC seeks to ensure that technical standards are established, understood and observed throughout NYU-NET in order to guarantee the integrity and smooth functioning of the network. Central coordination for network-related naming and numbering is an important component of this function. q Assist in solving network-related problems The NOC is directly responsible for some of the network infrastructure and its services (e.g. gateways to external networks, central name service), but a large portion of the network is under the direct management control of school and departmental network managers. The NOC does not have the resources to solve all manner of network problems for local network managers: the NOC staff will assist to the degree possible, with special concern for problems in any area of the network which may negatively affect others. In such cases, the NOC acts as a coordinating intermediary amongst the involved staff. 3. History of the NYU-NET Infrastructure The origins of NYU-NET date back to the early 1970's - the days of early experiments with networking and the establishment of the government-sponsored ARPANET, the forerunner to today's worldwide Internet. Staff at the Courant Mathematics and Computing Laboratory were involved in those early days with research and experimental implementation to explore the feasibility and capabilities of computer networking. In the early 1980's, New York University was among the first institutions to install Ethernet technology, attaching DEC VAX mini-computers to a Warren Weaver Hall cabling system which represented the first portion of NYU-NET. In 1982-83, cabling was extended to 715 Broadway. Protocols in use in this period were XNS, DECnet, and IP. By late 1983 a fiber-optic link replaced the original coaxial cable between Warren Weaver Hall and 715 Broadway, and in 1984 a T1 microwave link was established between the Square and the Business school down-town. NYU-NET had become a full multi-media, multi-protocol network. In 1985, NYU decided to install its own voice telephone system, managed by the Office of Telecommunications. A Data Task Force - forerunner to today's Data Communications Task Force - was established to investigate the possibility of using the occasion of the telephone system installation to also provide data communications infrastructure wiring from offices to phone closets throughout the campus. The Task Force recommended and supervised the installation of a multi- purpose broadband cable plant, initially connecting 35 buildings. This CATV cable system - a.k.a. the "broadband" - is managed by a Network Operations Group (NOG); it has become a backbone cable for NYU-NET at Washington Square, providing a 5 MB Ethernet channel as well as a channel for point-to-point SNA connections via broadband modems and up to 23 cable television channels. Since this time, many additions, modifications, and enhancements have been made to the NYU-NET wiring infrastructure, including: q fiber-optic cabling links to the Third North Residence, and to the Dental and Medical Centers q fiber-optic cabling links amongst many buildings at the Medical Center q additional broadband points of presence added in several Washington Square buildings q fiber-optic link to the newly-acquired Fairchild Building on 12th St. q establishment of leased-line links to the Public Health Research Institute and the Sterling Forest outpost of Environmental Medicine q establishment of numerous Ethernet and LocalTalk installations within NYU buildings and departments For the most part, NYU-NET is currently a bridged, as opposed to routed, local area network. In the early 1990s, however, NYU-NET is making a transition to a fully-routed network. 4. Standard Practices and Policies Because our network is managed in distributed fashion, local computer and network managers must http://www.nyu.edu/its/security/handbook.html (4 of 55)8/31/2006 1:23:12 PM
    • NYU-NET Technical Handbook understand, and agree to follow, the basic practices and policies in effect on NYU-NET. 4.1 Local Network Manager Obligations The managers of portions of NYU-NET must be quickly reachable by the NOC, via phone and/or E- mail, in the event of a network emergency - for example a malfunctioning device negatively affecting other systems, or a security event such as a system break-in, or virus epidemic. In the event of a sufficiently serious network event caused from within a locally managed sub-network of NYU-NET, the NOC staff might be forced to disconnect that sub-network from the rest of the network until the problem can be resolved. Local network managers must have electronic mail accounts to assist in communications with the NOC.Local network managers should take a lively interest in computer and network security issues. The sections below on Security Issues and Host Configuration Issues describe the basic security standards on NYU-NET; more detailed security measures can be explored with the NOC and ACF staff members who have significant experience in this area. Personnel changes which affect management of the network must be communicated to the NOC. 4.2 Network Changes The NYU-NET Network Operations Center must be notified of the attachment of new wiring extensions to NYU-NET and of the procurement of any "network infrastructure devices" prior to their attachment to NYU-NET. Such devices include all: q repeaters q hubs/concentrators q bridges, routers, and brouters q network modems/asynchronous gateway devices q hosts, workstations, file servers capable of routing All such devices must be procured with SNMP capabilities and then configured with SNMP enabled in order to participate in basic NYU-NET management efforts. When a computer or network infrastructure device (such as a hub, bridge, or router) is ready for attachment to NYU-NET, an Internet name and numeric address must be assigned by the Network Operations Center, or by an authorized NYU-NET sub-domain authority. The "database" of such Internet names and numbers is part of the "DNS" (Domain Name Service). This rule applies to all equipment, including Novell NetWare file servers, with the general exception only of Macintoshes being attached to a LocalTalk network (which are 'named' and 'numbered" for TCP/IP purposes via the router which attaches them to NYU-NET). 4.3 Security Issues The Network Operations Center maintains liaison with the Internet CERT/CC (Computer Emergency Response Team Coordination Center at Carnegie Mellon University) and receives advisories and alerts relating to computer and network security events and issues. Any departmental or school network manager who wishes may receive copies of these advisories. (Send request via E-mail to noc@nyu.edu). Local network managers are, in a general sense, responsible for security concerns within the portion of NYU-NET which they manage - and therefore should seek to ensure good system security within their domains. It must be realized that a given hosts's lack of integrity can potentially affect the integrity of other systems on the campus network. Basic security guidelines for local network and system managers are as follows: q Recognize that physical security is a key to good system and network security: locate systems (including file servers and shared-access hosts) in physically secure (locked!) locations whenever possible. q Attempt to create or utilize secure communications pathway for network cabling in so far as is practical. q Restrict "root" or "supervisor" privileges to the minimum number of system users; turn off the ability to perform remote logins as "root" on UNIX systems. When initially configuring a new system and its accounts, provide users with the minimum necessary privileges; add account privileges over time as necessary. q All user accounts should require both "username" and "password" authentication - avoid use of "anonymous" accounts whenever possible. Give all accounts an expiration date, and purge expired accounts after a reasonable amount of time. Actively discourage users from sharing their user names/passwords with others. Require passwords to be periodically changed, and whenever possible prevent old passwords from being re-used. When possible, require passwords to be non-trivial and of substantial length. Disable accounts of staff members who leave your department or the university. If cross-network password encryption is a viable option, use it. q Recognize that peer-to-peering networking (as in Macintosh System 7 file sharing between http://www.nyu.edu/its/security/handbook.html (5 of 55)8/31/2006 1:23:12 PM
    • NYU-NET Technical Handbook microcomputers) presents potential problems if microcomputer users do not configure their machines to prohibit 'guest' access: individual machines within departments must be carefully set up to require username/password access. Otherwise, the date on hard disks will be available to snoopers (playful or otherwise) anywhere on the network. A related problem arises when microcomputer Telnet programs are run: this programs typically allow FTP access to the microcomputer; such access should be limited through use of username/ password controls. q Employ anti-viral software on all microcomputer systems. Free software for Macintosh and IBM PC-type microcomputers is available from the ACF). Be sure to obtain updates of these programs as they become available. q Speak to NOC and ACF staff members about security issues specific to the platforms in use in your area. 4.4 Internet Access Anonymous - i.e. unauthenticated - access from NYU-NET to the rest of the Internet is prohibited: access to machines and services outside of NYU-NET may ONLY be made available to known and authorized account holders on shared-access machines within NYU. NYU-NET practice extends this policy to include microcomputers belonging to well-known members of the community - users who have registered their computers with the domain name service authority (hostmaster@nyu.edu) or with delegated sub-domain name service authorities within divisions of the university. In particular, laboratorymicrocomputers which do not require user login authentication (username/ password login to a file server for example) are prohibited from direct Internet access.Local network managers are obligated to follow procedures in accordance with this policy. 4.5 Host Configuration Issues In accordance with Internet requirements for electronic mail service, every host computer system involved in SMTP mail delivery must have an electronic mail address of the form: postmaster@hostname from which users and network authorities at other institutions can seek assistance in answering mail- related questions and solving mail-related problems involving that host. As RFC-1123 "Requirements for Internet Hosts" states: 'A host that supports a receiver-SMTP MUST support the reserved mailbox "Postmaster".' As a rule, it is expected that inquiries to "postmaster" be answered within twenty-four hours of receipt. The ACF maintains a staff "postmaster" function for the university at large, reached by the SMTP mail address postmaster@nyu.edu. All network-attached hosts which present a text-based display upon user login (e.g. traditional terminal-type access to VMS, UNIX machines) should provide a banner notification to users of the system, according to the following form: "Access to this computer system is restricted to authorized account holders and its use is limited to approved educational, research or administrative activities." The recommended form of this notification is expected to change in recognition of legal and security aspects of computer use (and misuse). Check the addenda to this handbook to see if an updated recommendation for banner notifications is available. 5. Major Protocol Suites on NYU-NET A communications or networking protocol is a set of rules describing how hardware and software elements of the network exchange information. A protocol suite is a set of interrelated protocols. Many such protocols and protocol suites have been (are being) developed, and NYU-NET, unlike some networks, does not mandate use of only a single protocol suite. NYU-NET is a multi-protocol network. (It should not be thought, however, that NYU-NET is suitable now or in future for all networking protocols. The viability of Netbios, for example, is highly questionable given its non-routed design.) The primary protocol suites in use on NYU-NET are TCP/IP, DECnet, Novell IPX, and AppleTalk. 5.1 TCP/IP TCP/IP represents, in a sense, the most important protocol suite on NYU-NET: the widest range of network services utilize TCP/IP protocols and virtually all network communications to and from the external Internet are conducted using these protocols. TCP/IP protocols can be viewed as occupying one of three basic levels, where higher-level protocols/ services (i.e., the "application" and "transport" protocols) rely on the lower-level protocols: http://www.nyu.edu/its/security/handbook.html (6 of 55)8/31/2006 1:23:12 PM
    • NYU-NET Technical Handbook Application: TELNET FTP SMTP SNMP NFS RIP DNS BOOTP Transport: TCP UDP Network: IP Physical: [Assorted media access protocols, such as Ethernet 2, 802.3 Ethernet, FDDI, 802.5 Token Ring, etc.) Protocol... Is an acronym for... providing... TELNET -- terminal emulation FTP File Transfer Protocol error-free file transfer SMTP Simple Mail Transport mail transfer SNMP Simple Network Management network management Protocol sharing disks among computer NFS Network File System systems RIP Routing Information Protocol routing information exchange OSPF Open Shortest Path First routing information exchange IS-IS Intermediate System - routing information exchange Intermediate System DNS Domain Name Service name/numbering information BOOTP Boot Protocol obtaining network info at machine boot time reliable byte-stream data TCP Transmission Control Protocol transmission UDP User Datagram Protocol unverified packet delivery IP Internet Protocol connectionless, best-effort packet delivery service TCP/IP also contains various support protocols used by IP over broadcast media. These protocols are NOT routable: if two cable segments are connected by an IP-level router, these protocols are not bridged (passed) through the router - even if the router bridges all other protocol types: ARP Address Resolution Protocol find MAC-level address when host knows IP addr RARP Reverse Address Resolution Protocol acquire IP address when know Mac- level address Two protocols are defined for asynchronous (serial) communications support of IP: SLIP (serial line internet protocol) and PPP (Point-to-Point Protocol). SLIP is a de facto (not official) standard protocol, with numerous host and microcomputer implementations. PPP, an emerging standard as defined in RFC-1331, "provides a method for transmitting datagrams over serial point-to-point links... and is comprised of three main components: q A method for encapsulating datagrams over serial links. q A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. q A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. NCPs, such as for Novell NetWare's IPX/SPX, are currently in development. http://www.nyu.edu/its/security/handbook.html (7 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook 5.2 DECnet and Related Protocols DECnet is a collection of protocols providing all the normal network service requirements. It was originally developed on and for DEC computer systems but the specifications for all of DECnet and many of the related protocols are publicly available and they have been implemented on many other systems, all the way down to MS-DOS and Apple Macintosh microcomputers. Application level protocols include CTERM for remote login over a wide area network, DAP for transparent file access, MAIL-11, MAILbus Transport, and X.400 for electronic mail transport. These are layered on NSP, the Network Services Protocol, which provides Session and Transport layer services which are in turn layered on various transport protocols such as Asynchronous or Synchronous DDCMP, Ethernet, Token Ring, etc. The level of DECnet currently implemented on NYU-NET is DECnet Phase IV which supports two levels of routers, adaptive least-cost routing, and a maximum of 63K nodes. A new level of DECnet being planned is DECnet Phase V which moves many services to the OSI networking protocol suite (including FTAM, X400, etc.) DECnet also include a set of auxiliary protocols such as MOP and Remote Console which exist to support downline loading, upline dumping, and remote operation of various devices, most often network infrastructure elements. DECnet protocols can be routed, but the auxiliary protocols such as MOP are parallel to the routing layer and typically must be bridged. Associated with, but not actually part of, the DECnet protocol suite are a set of high performance local area network protocols. These protocols are designed to sit directly on a Data Link (or Data Link + lower-network) layer protocol such as Ethernet. These protocols have been optimized for local services and generally offer very high performance even under heavy loads. There is some work underway to experiment with layering them on top of IP. The remote terminal protocol from this family is LAT (Local Area Terminal) which includes both name services and bi-directional support, and is especially efficient at handling the case of many users on a single terminal server sending data to the same host. The remote data access protocol suite in the family is commonly called LAD/LAST (Local Area Disk/ Local Area Storage Transport). It supports access to shared read-only blocked storage devices such as CD-ROMs and single-Writer multiple-Reader disks, with support recently added for sequential allocation and use of tape devices. The principle use of LAD/LAST services on NYU-NET are the DEC Infoservers which are used to provide general access to CD-ROMs as well as remote booting and paging disk services to DEC X-window terminals. LAT and LAD/LAST protocol spaces define 255 valid groups. Group numbers must be centrally assigned and service names other than DECnet names (already coordinated) must be coordinated through the NYU-NET Network Operations Center. LAT and LAD/LAST services need to be bridged at this time. Another important DEC protocol used on NYU-NET is the Local Area VMScluster (LAVc) protocol. This layers the DEC software which permits a group of VMS systems to act like one large system in all important respects onto an Ethernet transport layer. It too must be bridged. The LAVc protocol defines two subranges of a 16-bit cluster number space. This number space is password protected, but for best performance it should be coordinated. 5.3 Novell IPX/SPX (Novell NetWare) Novell NetWare, and associated products, use a variety of protocols collectively referred to as the "IPX/SPX" protocols. IPX, the Internetwork Packet Exchange, is a network-layer protocol, responsible for forwarding IPX packets through IPX routers (such as Novell servers) and to end clients and servers. SPX, the Sequenced Packet Exchange, is one of two transport-layer protocols and is occasionally used for client-client guaranteed packet delivery. More commonly, clients use the NetWare Core Protocol (NCP) packets atop a simple "Packet Exchange Protocol" for client<->server communications: http://www.nyu.edu/its/security/handbook.html (8 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook A variety of other protocols are used: RIP the Routing Information Protocol used by IPX routers to exchange routing information Error used to tell a destination IPX socket of an error Echo used to test end-to-end connectivity between nodes SAP the Service Advertisement Protocol, used by servers to advertise services (such as file or print services) or clients to find such services on the network Netbios not a part of the "IPX/SPX" protocol suite, but implemented by Novell on top of IPX in order to provide compatibility for applications which are built to rely on Netbios capabilities. The "NetWare Core Protocols" form a programming API for providing services to end-user applications. NCP is used to provide basic operating system services such as file and queue system access, as well bindery access, locking and synchronization capabilities, and printer access. In recent years, NetWare systems have come to also support AppleTalk and TCP/IP protocols for native support of Apple Macintosh and Unix-based clients and for network management purposes. The NetWare Management System, for example, uses a combination of IPX and SNMP-based services for locating and monitoring network nodes. 5.4 AppleTalk AppleTalk is Apple Computer's proprietary (but licensed) network architecture, closely modeled on the OSI 7-Layer Reference Model: http://www.nyu.edu/its/security/handbook.html (9 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook There is often confusion over the differences between AppleTalk-related terms; here are the "Talk" terms and their meanings: AppleTalk Apple's networking protocols (and software) for communications among computers systems, printers, and other peripherals attached to a network. LocalTalk the name given to AppleTalk protocols when they are utilized over Apple's low-cost, medium- speed (230,400 bps) coaxial cabling system (or third-party twisted-pair equivalents). The "localtalk" icon in a Macintosh's Network Control Panel directs the system to use the built-in LocalTalk hardware (the printer port). EtherTalk the name given to AppleTalk protocols when they are utilized over Ethernet media. The "EtherTalk" icon (or icons) in a Macintosh's Network Control Panel directs the system to use an Ethernet interface on the system for network communications. Ethernet a packet delivery system (and data link-level protocol) for local area network, developed by Xerox, Intel, and DEC; today run at 10 megabits per second. Note: In the MacTCP Network Control Panel, both "EtherTalk" and "Ethernet" icons are typically found. In this context, "EtherTalk" refers to encapsulating TCP/IP inside of AppleTalk packets on the Ethernet; "Ethernet" refers to direct use of IP on "top" of Ethernet - the norm on NYU-NET. 6. Configuration Guidelines 6.1 Summary of Requirements http://www.nyu.edu/its/security/handbook.html (10 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook Computer hardware elements on NYU-NET fall into two categories: q End-user computing systems (e.g. microcomputers, workstations) q Infrastructure devices (e.g. repeaters, hubs, bridges, routers, file servers capable of routing) Both kinds of computing devices must be configured for proper cooperative use on NYU-NET. Later sections of this document go into some degree of detail, but since many particulars vary from device to device or vendor to vendor, it will sometimes be necessary for network managers to consult with the Network Operations Center (NOC) to determine various configuration parameters. Infrastructure devices, in particular, require special care from time of selection through configuration and ultimate attachment to NYU-NET in order to guarantee that they have no negative impact on the network. Both end-users and local network managers must observe the following general rules: q When a new end-user computing system, such as a UNIX workstation or PC, is intended for attachment to NYU-NET, its networking software must be properly configured. Most important, TCP/IP connectivity requires assignment by the NOC of a numeric address and name for the system. See the section below on Congiguration Guidelines: TCP/IP Hosts and Appendix B: Obtaining Network Names and Numbers. q File servers, such as Novell NetWare file servers, also require careful configuration in order to coexist on NYU-NET. See the section below on Novell NetWare file server configuration. q All new infrastructure devices to be attached to NYU-NET must be procured with SNMP capabilities, and then must be configured with SNMP enabled in order to participate in basic NYU-NET management. q The NOC must be notified prior to the attachment of new infra- structure devices. q Any proposed augmentation of the NYU-NET cabling system must be discussed with networking staff members at the NOC. 6.2 Network Management Aspects - SNMP SNMP (the Simple Network Management Protocol) is the primary network management protocol used on NYU-NET. All capable systems should run an SNMP daemon (SNMPD) which allow the equipment to be asked questions about its setup, traffic counts, routing information, and so on. All new network infrastructure devices (e.g. hubs, bridges, routers) and hosts (including workstations and file servers) MUST be equipped at time of purchase with SNMP. If there is not a local, well-maintained, SNMP network management station used by a school or department network manager, then: 1. All SNMP-manageable devices which can send traps should be configured do so. 2. Traps should be sent to the NOC, to address If there is a local SNMP management console, then the following rules govern the sending of traps: 1. All SNMP-manageable devices which can send traps should be configured to do so. 2. Devices which can send traps to multiple management consoles should send to both the NOC ( and to the local console. 3. For devices which can only send traps to a single management console: r if the device is a network infrastructure device like a bridge or router, it should trap to the NOC ( r if the device is a purely locally managed device (e.g. a local workstation) it should trap to the local management console. The community string "public" is used on NYU-NET. 7. Configuration Guidelines: TCP/IP Hosts 7.1 General Points The precise details of network hardware and software configuration depend, in every case, on the specifics of machine hardware configuration, operating system version, and network software to be used. In general, however, it is necessary to follow these steps before connecting a TCP/IP-enabled machine to NYU-NET: 1. Prior to purchase, make sure that your networking hardware (typically Ethernet board plus cabling) is of the correct type for your local connection to the NYU-NET cabling system. For example, there are three different types of Ethernet connections: "thick", "thin", and http://www.nyu.edu/its/security/handbook.html (11 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook "twisted-pair". 2. When a new machine (or network interface board) is ready to be installed, an Internet (IP) name and numeric address must be assigned. See Appendix B: Obtaining Network Names and Numbers for details on the procedure to follow. (This step is not necessary if you are installing a Macintosh on a LocalTalk network.) If you are installing a Macintosh on an Ethernet, see Appendix D which describes MacTCP and its installation, including the procedure used to obtain the Ethernet address (firmware address) of a Macintosh Ethernet interface. 3. The Academic Computing Facility and Network Operations Center wish to guarantee that all workstations and other TCP/IP devices be configured correctly for NYU-NET, and will provide assistance to assist departmental staff in configuring and attaching these devices to the network. 7.2 Fundamental TCP/IP Information for NYU-NET Q. What is the name of the network? A. NYU-NET. The Internet domain name for NYU-NET is "NYU.EDU". Q. What is the network number? A. NYU-NET is assigned a Class-B Internet network number: (in hex: 80.7A.00.00) Q. How are network addresses and names assigned? A. For TCP/IP address and name assignment, send E-mail to hostmaster@nyu.edu or to your local school authority for network address and name assignment. For details, see Appendix B: Obtaining Network Names and Numbers. Q. Is subnet routing done on NYU-NET? A. To a limited (but growing) degree. The numeric address space of NYU- NET's class B network ( is sub-divided into 254 8-bit subnets (128.122.x.0), where x can range between 1 and 254. For the most part, these are "logical" subnets, since the physical network segments for these subnets are not yet, for the most part, behind IP routers. As more routers are introduced, "logical" subnets become true, physical, routed subnets. Addendum 6 provides a complete listing of NYU-NET subnets which are currently in use, with indication of whether or not they are currently "logical" or "routed" subnets. Q. Within subnet "x", what addresses can be assigned to nodes on NYU-NET? A. Address 128.122.x.2 through 128.122.x.253 may be used. 128.122.x.0 means the subnet itself. 128.122.x.1 is the bridge/router connecting this subnet to NYU-NET 128.122.x.254 is reserved for test equipment 128.122.x.255 is reserved for IP broadcasting Q. What is the network mask? A. For logical subnets, (FF.FF.00.00). For routed subnets, (FF.FF.FF.00). Q. What is the broadcast address? A. For logical subnets, (80.7A.00.00) For routed subnets, 128.122.x.255 (80.7A.XX.FF) Q. Why isn't the broadcast address for logical subnets? A. Because of a technical problem with various implementations of TCP/IP that are derived from the BSD 4.2 UNIX distribution. Once the last group of Suns running SunOS 3.2 through 3.5 are gone from the bridged backbone, we will be able to switch universally to the official IP broadcast address form (all-1s in the host portion). http://www.nyu.edu/its/security/handbook.html (12 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook Q. What is the default router for machines on NYU-NET? A. For logical subnets, (NYEGRESS.NYU.EDU) For routed subnets, 128.122.X.1 (the router which attaches subnet X to NYU-NET) Q. What domain are NYU-NET machines in? A. All NYU-NET machines are in the domain "NYU.EDU". But most machines are identified specifically in a "sub-domain" of NYU.EDU such as "med.nyu.edu" or "stern.nyu.edu" or "acf.nyu.edu". The use of sub-domains continues the hierarchical Internet naming scheme into NYU-NET, and allows greater precision in naming machines to indicate their ownership. Q. What are the official NYU-NET names servers? A. The Academic Computing Facility operates the primary NYU.EDU domain name servers: EGRESS.NYU.EDU CMCL2.NYU.EDU NYUNSB.NYU.EDU The Stern School of Business and the Medical Center also maintain domain names servers for their delegated subdomains MED.NYU.EDU and STERN.NYU.EDU. EXCHANGE.STERN.NYU.EDU CAMBIO.STERN.NYU.EDU MCCLB0.MED.NYU.EDU MCHIP00.MED.NYU.EDU In the case of machines in 'med.nyu.edu', the ACF's name servers (EGRESS, CMCL2, NYUNSB) act as secondary name servers; med.nyu.edu hosts may be configured to use ACF name servers in case of local name service failure. The proper TCP/IP configuration for workstations (/etc/resolv.conf typically) and microcomputers with respect to domain name service depends, therefore, upon the location of the computer on NYU- NET. Q. What TCP/IP routing protocol is used on NYU-NET? A. RIP, the "Routing Information Protocol". Q. What external TCP/IP routers are there on NYU-NET? A. There are two routers to external networks: NYEGRESS.NYU.EDU NYSERNet/PSINet IP router connects network NYU-NET ( to network NYU-EXT- NET (, and thence to the rest of the Internet. Only routers and multi-homed network service hosts are found on NYU-EXT-NET. ENTRADA.NYU.EDU Router to ESnet (Energy Science network), to IP network 7.3 Unix Workstation All UNIX computers, including both workstations and minicomputers, come equipped for TCP/IP networking. You will need to consult the operating system documentation in order to learn the precise and full details (and commands) for performing the networking configuration. The examples below pertain to a traditional, BSD-type machine and attempt only to provide the "highlights" of performing its networking configuration. When first booting a UNIX machine, you can expect its console to display the q Ethernet device designation http://www.nyu.edu/its/security/handbook.html (13 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook (e.g. "le0" for a Lance Ethernet Interface or "ie0" for a Intel Ethernet Interface) and the q firmware Ethernet address in the form NN:NN:NN:NN:NN:NN. The Ethernet device designation is needed (on some machines) for its configuration; when obtaining an IP name and number from the Network Operation Center (see Appendix B), report the firmware address. The basic steps which need to be accomplished are: q configure the Ethernet interface (set basic TCP/IP parameters) q configure the loopback address q configure for IP routing q configure the internet daemon (inetd) q configure the domain name resolver q edit configuration files Configure the Ethernet Interface In this example, the ifconfig (interface configure) command is used to assign the IP address, subnet mask and broadcast address to the interface. Given the following features, and assignment of IP address by the NOC, q Ethernet Interface: le0 q IP Address: 128.122.x.y q Name: newmachine.nyu.edu q Location: on logical subnet 128.122.x.0 then the correct netmask is and the broadcast address is The ifconfig command is: # ifconfig le0 128.122.xx.yy netmask broadcast If subnet "x", on the other hand, was a "routed" subnet (i.e. behind an IP router), then the correct netmask would be and the broadcast address would be 128.122.x.255: # ifconfig le0 128.122.x.y netmask broadcast 128.122.x.255 Configure the Loopback Address It is sometimes necessary to configure the IP address of the "loopback" interface, which is used for troubleshooting purposes. The ifconfig command for this purpose is: # ifconfig lo0 is used on all machines for the loopback address. If your machine has the netstat command installed, you can use it to identify and check the configuration of its network interfaces: # netstat -ain Ifconfig displays configuration and status information for a known interface, e.g. # ifconfig le0 might display something like: le0: flags=63< UP,BROADCAST,NOTRAILERS,RUNNING > inet 128.122.x.y netmask ffff0000 broadcast Configure for IP routing If the machine is diskless, you should set a default route. For example, on a BSD-based machine you can do this as follows. For a machine on a logical subnet: % /etc/route add default 1 For a machine on routed subnet X: % /etc/route add default 128.122.X.1 1 If the machine is not diskless, and you can spare a process slot and some memory and CPU cycles, http://www.nyu.edu/its/security/handbook.html (14 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook you can run a routing daemon to listen (only) for dynamic routing information. Again, on a BSD- based machine you do this with the command: % /etc/routed -q This command will configure the machine to listen only, and not itself propagate IP routing information. Configure the Internet Daemon The internet daemon (inetd) is started at boot time, reading its configuration from the file /etc/inetd. conf. This file contains the identities of the TCP/IP services which the internet daemon will run upon client request. You should comment out the line which configures tftp, since tftp is rarely used and, if improperly configured, can represent a security hole. Configure the Domain Name Resolver The domain name resolver is software which allows TCP/IP applications to translate between IP names and numbers, e.g. to determine that the user command: # telnet ACF1 means to telnet to the IP address Typically, the resolver configuration is kept in the plain-text file /etc/resolv.conf and consists of only a few lines: # Sample domain name resolver configuration file # domain NYU.EDU nameserver nameserver nameserver A machine at the Medical Center or Stern School (which have their own primary name servers) would have a different /etc/resolv.conf file which first lists local nameservers. Edit Configuration Files TCP/IP implementations traditionally also use a variety of text configuration files, especially: q /etc/hosts q /etc/networks q /etc/protocols q /etc/services Since the advent of the domain name service (DNS) the importance of /etc/hosts is vastly reduced. The NOC discourages you from attempting to build up an old-style, huge hosts file. You should, however, make an entry in this file for the machine itself: # sample /etc/hosts file # 127.1 localhost 128.122.x.y newmachine.nyu.edu The /etc/networks file should contain, minimally, the following two lines: # sample /etc/networks file # 127 loopback-net 128.122 nyu-net The /etc/protocols and /etc/services files typically require no special configuration. 7.4 Apple Macintosh Every Apple Macintosh which is to communicate via TCP/IP on NYU-NET must be assigned an internet name and number by the Network Operations Center. See Appendix B: Obtaining Network Names and Numbers. The NOC strongly recommends the use of BOOTP to provide network-related information at boot/run- time to all microcomputers on the network. Information provided includes the IP address of the requesting microcomputer, as well as the identity of name servers and external routers - thereby reducing the necessity for management of ASCII configuration files on individual microcomputers. Use of BOOTP also assists network managers in limiting off-campus Internet access to authorized http://www.nyu.edu/its/security/handbook.html (15 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook members of the community. TCP/IP applications for Apple Macintosh rely upon Apple's MacTCP drivers: use of MacTCP frees the software developer from a great deal of work implementing the core TCP/IP protocols. The Academic Computing Facility has licensed MacTCP on behalf of New York University for use on machines connected to NYU-NET. See Appendix D: MacTCP - Availability and Installation for a detailed discussion of installing MacTCP on NYU- NET Macintoshes. The majority of Macintoshes on NYU-NET which utilize TCP/IP protocols do so with non-commercial (no cost!) software developed primarily at other universities on the Internet, including: q TELNET: Telnet from NCSA/BYU TN3270 from Brown University q FTP: Fetch from Dartmouth College q E-Mail: Eudora (originally from U. Illinois, now from Qualcomm, Inc.) Pegasus Mail with Clarkson University's Charon SMTP gateway q Gopher: Gopher Client to NYU Campus-Wide Information Service from University of Minnesota Here is a portion of a configuration file for NCSA/BYU Telnet, showing valid TCP/IP-related settings. Be sure to observe the FTP-related settings, as this version of Telnet also can act as an FTP server (incoming file transfer requests to your Mac); at a minimum, this capability should be password protected. http://www.nyu.edu/its/security/handbook.html (16 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook 7.5 IBM PC Every IBM-type PC which is to communicate via TCP/IP on NYU-NET must be assigned an internet name and number by the Network Operations Center. See Appendix B: Obtaining Network Names and Numbers. The NOC strongly recommends the use of BOOTP to provide network-related information at boot/run- time to all microcomputers on the network. Information provided includes the IP address of the requesting microcomputer, as well as the identity of name servers and external routers - thereby reducing the necessity for management of ASCII configuration files on individual microcomputers. Use of BOOTP also assists network managers in limiting off-campus Internet access to authorized members of the community. The majority of IBM-type PCs on NYU-NET which utilize TCP/IP protocols do so with non-commercial (no cost!) software developed primarily at other university's on the Internet, including: TELNET: Telnet/TN3270 from Clarkson University NCSA Telnet MS Kermit from Columbia University FTP: Clarkson University FTP NCSA FTP E-Mail: NUpop from Northwestern University Pegasus Mail with Clarkson University's Charon SMTP gateway Gopher Gopher Client to NYU Campus-Wide Information Service from University of Minnesota The capabilities of all these software packages are based upon PC use of a "packet driver". The original packet driver concept was to develop Ethernet board drivers which would allow multiple http://www.nyu.edu/its/security/handbook.html (17 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook protocols to co-exist in a PC - especially to allow a NetWare client to run TCP/IP software packages while attached to a file server. Packet drivers were originally distributed by Clarkson University, but are now distributed by Crynwr Software on a no-cost basis. It should be noted that many commercial TCP/IP software offerings for PCs are not compatible with Crynwr packet drivers; use of such software on a PC might preclude ready use of the non- commercial TCP/IP software listed above. For users of Novell ODI network board drivers, there is a special packet driver (ODIPKT) which allows packet driver-based TCP/IP software to run on top of ODI. A typical PC packet driver configuration (e.g. in autoexec.bat) would be: 1. wd8003e 0x7f 0x0A 0x300 0xCC00 2. winpkt 0x7e 0x7f Line [1] loads the packet driver for Western Digital Ethernet boards, grabbing software interrupt 0x7f for subsequent communications between software and the packet driver. In this particular case, the Ethernet board is set up for IRQ 10, I/O port 300, RAM (paragraph) address of CC00. IRQ 10 is a good choice on AT-class (or above) PCs, as it does not conflict with standard PC hardware devices (e. g. serial and parallel ports). Line [2] is a special packet-driver "shim" which is designed to allow the basic WD packet driver to function safely under Microsoft Windows. Note that software interrupt 0x7e is now used for applications to communicate with the packet driver. A TCP/IP application would then be configured for packet driver use. Here is a portion of a configuration file for Clarkson Telnet, showing valid packet driver and TCP/IP-related settings. Be sure to observe the FTP-related settings, as this version of Telnet also can act as an FTP server (incoming file transfer requests to your PC); at a minimum, this capability should be password protected. http://www.nyu.edu/its/security/handbook.html (18 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook http://www.nyu.edu/its/security/handbook.html (19 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook 8. Configuration Guidelines: Routers 8.1 General Router Issues Routers are networking devices which "route" or "forward" data packets from one machine to another and from one network to another network. There are many different kinds of routers, depending upon the specific functions desired and the type of software and hardware used to perform them. One special type of router is called a "brouter" - a device which "routes" some protocols, and "bridges" others. Above all it should be remembered that routers route specific protocols: there are IP routers for communications via TCP/IP; there are IPX routers for communications via the Novell IPX protocol; there are AppleTalk routers for communications via AppleTalk protocols used by Apple Macintosh computers. There are routers which only route one kind of protocol; there are multi-protocol routers which can handle many protocols simultaneously. Note the following facts: q Almost any UNIX workstation or minicomputer can be (mis)configured as a router. See the section above on Unix Workstation Configuration for basic guidelines in this regard. q Any AppleTalk device which interconnects AppleTalk networks may be an Appletalk router. A Macintosh can run software (e.g. Apple's Internet Router software) and become an AppleTalk router. q A Novell server is automatically an IPX router. A Novell server may also be configured as an AppleTalk or as an IP router. Routers and brouters require special care in their selection, configuration, and installation. The Network Operations Center must be advised of and consulted on all bridge, brouter, and router procurement and installation prior to purchase. http://www.nyu.edu/its/security/handbook.html (20 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook The most prevalent types of routers on NYU-NET are: q Novell file servers (IPX, AppleTalk, potentially TCP/IP) q Shiva "Fastpath" AppleTalk routers q Multi-Protocol dedicated routers (for TCP/IP above all) Novell server and Shiva router configurations are discussed in sections below. 8.2 IP Router Configuration Because of the importance of the TCP/IP protocol suite on NYU-NET and the intricacies of TCP/IP routing, IP routers require careful attention. IP routers, for routed physical subnets of the form 128.122.x.0, must be configured according to the following guidelines: Subnet mask: Broadcast address: The network address of a router's interface that is attached to the NYU- NET backbone MUST HAVE an address on the subnet (to allow proper routing information exchange among routers). The network address of a router's interface to routed subnet x should be 128.122.x.1. Note that a host on a subnet "x" can only directly communicate with other hosts on the same subnet "x". Thus, for example, two hosts 128.122.x.4 (on routed subnet 128.122.x.0) 128.122.y.4 (on logical subnet 128.122.y.0) cannot "see" or communicate with each other (even if they are located on the same physical cable segment): they require a router to forward packets between them. During NYU-NET's transition from bridged to fully-routed network this situation arises frequently: the need to forward packets between a routed subnet "x" and an un-routed "logical" subnet "y". (See the section above Fundamental TCP/IP Information for a discussion of subnet routing on NYU- NET and an explanation of the distinction between "logical" and "routed" subnets). So router 128.122.x.1 must forward packets to logical subnet "y" - which requires the router to have an "interface" (an address) on the logical subnet. For example, it can be assigned 128.122.y.253. For each and every logical subnet to and from which the router needs to forward packets, such a "secondary IP address" from the logical subnet must be assigned to the router. So during this transitional period, IP routers must be assigned a number (not predictable) of secondary IP addresses within logical subnets, so that they can "pretend" to have interfaces on http://www.nyu.edu/its/security/handbook.html (21 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook those "subnets", so they can "route" packets between their subnet interfaces. 9. Configuration Guidelines: AppleTalk Routers All network infrastructure devices which utilize AppleTalk protocols must be assigned AppleTalk network numbers by the Network Operations Center (noc@nyu.edu) in order to guarantee uniqueness across the campus. Such devices are: q Shiva Fastpath or other Ethernet/LocalTalk routers q Novell NetWare file servers and external bridges q Macintoshes running Apple (or other) internet routing software q Shiva LanRover or other AppleTalk Remote Access servers q Multi-Protocol (e.g. Cisco) routers q Any device which is capable of "defining" an AppleTalk "zone" All such devices must be configured correctly in several respects in order to co-exist on the network. The majority of AppleTalk routers on NYU-NET are Shiva Fastpath routers (formerly Kinetics Fastpath) and Novell NetWare 3.11 file servers. Shiva Fastpaths require especially careful configuration, as they are versatile devices which can perform several functions beyond basic AppleTalk routing (e.g. encapsulation of TCP/IP packets within LocalTalk packets). 9.1 General Configuration Aspects Consider NYU-NET as having a "backbone" Ethernet cabling system to which routers are attached. NYEGRESS.NYU.EDU and ENTRADA.NYU.EDU are the two "external routers" which lead to networks outside of NYU. All other routers are "internal routers" which segment NYU-NET into subnetworks; there is no "external router", at this time, which routes AppleTalk protocols to the outside world. From the AppleTalk point of view, the NYU-NET "backbone" is a pure AppleTalk Phase 2 internet, i.e. all routers which attach to the backbone are configured for Phase 2-only with zone "NYU Ether" on the backbone side. All Macintoshes, and any other systems which "speak" AppleTalk which are connected to Ethernet cabling systems on NYU-NET must be configured to use "Phase 2" drivers. Macintoshes on "localtalk" cabling systems continue to use their "built-in" LocalTalk network drivers. As of winter 1992-1993, the AppleTalk network numbering range for the "backbone" is 10-20 and NYU Ether is the only AppleTalk zone defined for this range. Important: please note that zone names are "case-sensitive"; routers on NYU-NET must be configured with "NYU Ether" - not "NYU ETHER" or any other variation. 9.2 Shiva Fastpath Configuration The Shiva Fastpath 5 is the most prevalent AppleTalk internet router on NYU-NET; the most commonly-used capabilities of this device are as a gateway between LocalTalk and Ethernet cabling segments, and as a provider of dynamic IP addresses to Macintoshes on a LocalTalk segment. The discussion below for properly configuring a Shiva Fastpath is based on its standard use for these functions; configuration issues for less commonly used functions should be discussed with the NOC staff. Any router has two or more ports; the Shiva Fastpath 5 has two: an Ethernet port and a LocalTalk port, each of which must be configured correctly. In the configuration process, a new AppleTalk "zone" may or may not be defined: the devices on the LocalTalk side of a Fastpath may be defined as part of a new zone, or as part of an existing zone on NYU- NET. It is thus possible for a geographically dispersed unit of the university (like the ACF) to have all of its LocalTalk devices appear in the same zone ("NYU ACF" in the case of the ACF). As of Spring 1993, only a single AppleTalk zone appears on the NYU-NET Ethernet backbone - "NYU http://www.nyu.edu/its/security/handbook.html (22 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook Ether". As Ethernet-Ethernet routers are introduced into NYU-NET, multiple Ethernet sections of the campus network will be assigned one or more zones. See Addendum 8, AppleTalk on NYU-NET, for up-to-date information on this subject. Here are guidelines for setting the various parameters for a Shiva Fastpath; please note that, at several points, information is required which must be obtained from or discussed with the NOC (e.g. AppleTalk network numbers, TCP/IP network numbers, new zone names). When viewed with the Shiva NetManager application, several major configuration sections are found: q Gateway q At Startup q LocalTalk Configuration q Ethernet Configuration The "Show LocalTalk Configuration" and "Show Ethernet Configuration" buttons are used to expand these configuration sections allowing viewing and setting of the relevant parameters. In describing parameter settings below, only "selected" items (selected with a "check" next to the item) are described; unless mentioned here, check boxes should be left empty (unselected). At the very top of the Shiva NetManager configuration screen, a box is available for entering the "name" of the FastPath. The NOC recommends DNS-style naming (using the assigned TCP/IP name of the device), e.g. WWH-MGW.ACF.NYU.EDU is used for ACF's FastPath located in Warren Weaver Hall. Gateway section: Serial Number Every Fastpath is labeled with a serial number sticker. Enter the serial number here. This section also shows various information about the FastPath, such as its Ethernet address, the date of last configuration, and versions of the software last used to download it. At Startup section: Register "Fastpath" in... The Fastpath must be "registered" in "LocalTalk". This means that the device will appear as a device in the zone on the LocalTalk side of the Fastpath. LocalTalk Configuration section: AppleTalk Zone: ....... The AppleTalk zone defined by this Fastpath, or in which this FastPath is to be registered, is entered here. Creation of new zones on NYU-NET must be done in coordination with the NOC. AppleTalk Network Number: ..... AppleTalk network numbers must be unique across NYU-NET. Obtain a valid network number for the LocalTalk side of the FastPath from the NOC. As a rule, "Use DDP Checksums" option should be selected. However, there is a known problem with this setting and Apple LaserWriter NTR printers installed on the LocalTalk side of Fastpaths. If you have LaserWriter model NTR printers so located, "Use DDP Checksums" should not be selected at this time. Ethernet Configuration section: EtherTalk Phase 2 The "EtherTalk Phase 2" box should be checked; "EtherTalk Phase 1" must NOT be checked. Start Net.../ End Net... / Default Zone... The values should be left BLANK. This makes the FastPath a non-seed AppleTalk router. (If the parameters were set they would be set to 10 / 20 / NYU Ether as of Spring 1993). DECnet (sub-section): As a rule, the DECnet configuration section should be left BLANK. IP Configuration (sub-section): The following values are correct as of Spring 1993; some of these values will change in the future as TCP/IP routers are introduced. (Check addenda to this document to see if different values are recommended). IP Address of FastPath: 128.122.mmm.nnn An IP address must be assigned by the NOC to new FastPaths. http://www.nyu.edu/its/security/handbook.html (23 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook IP Subnetwork Mask: This will be different in future for FastPaths behind TCP/IP routers. IP Broadcast Address: This will be different in future for FastPaths behind TCP/IP routers. IP Address of Default Router: This will be different in future for FastPaths behind TCP/IP routers. IP Address of Name Server: Medical Center FastPaths can use a local name server if desired. IP Address of File Server: The "Use BSD 4.2 Broadcast address" should not be checked. "Address Gleaning" should be checked. IP Forwarding (sub-section): In most cases on NYU-NET, FastPaths are used to provide IP forwarding services for Macintoshes located on their LocalTalk side; the FastPath provides dynamic IP address assignment as well for as many Macintoshes as desired. The set of dynamically assignable IP addresses is pre- allocated in the DNS, and configured into the FastPath with the settings typically as follows, where "N" represents the agreed-upon number of IP addresses: N Dynamic IP Clients 0 Static IP Clients IP Forwarding Options: Normal Forwarding The "Disable Proxy NBP ARP" item SHOULD be checked. IPTalk (sub-section): Typically NOT selected. SNMP (sub-section): FastPaths are SNMP-manageable. In this section, basic identification and contact information is provided: q Contact: (Name of responsible person, phone number) q Name: (Name of FastPath; the NOC recommends DNS-style naming, e.g. WWH-MGW.ACF. NYU.EDU is used for ACF's FastPath located in Warren Weaver Hall) q Location: (The building/floor/office location of the FastPath) q Host Address: 128.122.mmm.nnn (the IP Address of the FastPath) q Trap Address: (the standard SNMP trap address on NYU-NET). Atalkatab (sub-section): As a rule, NOT selected. 9.3 Novell NetWare Configuration Any Novell NetWare 3.x (or greater) file server which has NetWare for Macintosh NLMs loaded will function as an AppleTalk router. Several lines in the configuration file AUTOEXEC.NCF determine the AppleTalk configuration. In particular, the "load appletlk" command assigns an Appletalk network number to the server _itself_ and designates the AppleTalk zone in which the AFP file server will be advertised; for example, load appletlk net=9876 zone={"NYU SERVERSZONE"} On NYU-NET, AppleTalk network numbers and zone names are centrally assigned by the NOC. See the section below on Configuration Guidelines: Novell NetWare for an annotated example of the AUTOEXEC.NCF file. 10. Configuration Guidelines: Novell NetWare 10.1 NetWare File Server Two versions of Novell NetWare are in common use at New York University: NetWare 2.x and NetWare 3.1x. These two versions differ substantially in their features and manner of configuration. NetWare 2.x requires a "generation" or "re-generation" process to set its parameters; NetWare 3.1x http://www.nyu.edu/its/security/handbook.html (24 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook is far easier to configure and re-configure (if necessary): only its AUTOEXEC.NCF configuration file needs to be edited and (at most) the server be restarted. Several NetWare configuration parameters relate to NYU-NET standards: 1. Ethernet packet type NYU-NET exclusively uses "Ethernet 2" (ethernet_ii) packet types for Novell NetWare, as opposed to the default Novell 802.3 packet type. Ethernet 2 is the standard because Novell's 802.3 is not correctly formatted 802.3. A server (and client PCs) which did not use Ethernet 2 would be unable to communicate with the majority of Novell devices on campus, would possibly cause problems with third- party NetWare print servers, and would possibly conflict with systems which utilize correct 802.3 packets. NetWare 3.x file servers are configured for Ethernet 2 in the "AUTOEXEC.NCF" configuration file; NetWare 2.x file servers require that, after "netgen" is run, the ECONFIG program be used to change the packet type. The following command is used: econfig net$os.exe a:e 8137 This example assumes that the servers primary (first, "a") interface is connected to the NYU- NET backbone. Similarly, the NetWare workstation software (IPX.COM) must be set to use Ethernet 2 packets, if a standard, old-fashioned WSGEN shell is used: econfig ipx.com shell:e 8137 This is not the case, however, if the PC uses a packet driver-based ipx.com or if Novell's ODI drivers are used. 2. Backbone IPX network address The IPX network address of the NYU-NET backbone is 807A0000; during a NetWare 2.x "netgen" this number is used when you are prompted for the network "address". This number is also used in the NetWare 3.x "AUTOEXEC.NCF" configuration file (see below for an example). 3. Internal IPX network address NetWare 3.x file servers require an "internal" IPX network address which needs to be unique across the campus network. NYU-NET practice is to assign an IP address to each server and derive the internal IPX network address from this IP address (see below). 4. NetWare also "does" AppleTalk and TCP/IP The sample "AUTOEXEC.NCF" file below illustrates proper configuration of a NetWare 3.x server for AppleTalk and TCP/IP purposes. The following template AUTOEXEC.NCF file illustrates the proper configuration of a NetWare 3.1x server on NYU-NET. Explanatory notes explain many of the parameter settings. ; Template AUTOEXEC.NCF file for NetWare 3.1x file servers ; on NYU-NET ; ; This file illustrates configuration commands for a server ; supporting both PCs and Macintoshes (via NetWare for Macintosh) ; [1] ; System Supervisor: Susan Q. Expert ; E-Mail address: expertsq@acfcluster.nyu.edu ; [2] file server name NYUFILESERVERNAME http://www.nyu.edu/its/security/handbook.html (25 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook [3] ipx internal net 807A0502 ; [4] set allow unencrypted passwords=on load nmagent [5] load ups type=mouse discharge=8 recharge=36 ; [6] load NE2 slot=3 frame=ethernet_ii name=ipx_ip load NE2 slot=3 frame=ethernet_snap name=etalk2 ; [7] load appletlk net=9876 zone={"NYU SERVERSZONE"} ; [8] load tcpip rip=no trap= load snmplog ; [9] bind IPX ipx_ip net=807A0000 ; [10] bind APPLETLK etalk2 net=10-20 zone={"NYU Ether"} ; [11] bind IP ipx_ip addr= mask=0xff.0xff.0x0.0x0 bcast= ; load remote load rspx mount all ; [12] load afp ncpw delay300 load atps -v ; [13] patchit.ncf ; load monitor Explanatory notes: [1] ; System Supervisor: Susan Q. Expert ; E-Mail address: expertsq@acfcluster.nyu.edu All departmental network managers must obtain campus electronic mail addresses in order to facilitate communications with other NYU-NET networking groups and staff members. [2] file server name NYUFILESERVERNAME The file server name is decided upon by the system supervisor for that server. There is no authoritative server naming scheme, but the following guidelines follow from NYU-NET tradition and common sense: use relatively short names which attempt to capture the ownership of the server; http://www.nyu.edu/its/security/handbook.html (26 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook where a department has more than one file server, a number can be used as part of the name. For example, the Controller's Division has file servers named: CDVFS01 (file server) CDVGW01 (SAA gateway) The ACF has used file server names which reflect the locations of the server, e.g. ACFSE - ACF Server at the Education building ACFSW - ACF Server at 14 Washington Place Names of more than 10 or 12 characters may not display well by programs which assume that file servers will have short names. [3] ipx internal net 807A0502 The internal IPX network address of each NetWare file server must be unique across NYU-NET. In order to guarantee this uniqueness, the following scheme is used: A. Obtain a TCP/IP address for the file server from the NYU-NET Network Operations Center. See Appendix B for a description of the information required to accomplish this. The assigned addressed is guaranteed to be unique across NYU-NET. B. Take the assigned address - e.g. - and convert each of its elements from decimal to hexadecimal pairs: --> 80 7A 05 02 C. The resultant number - 807A0502 in this example - is used as the internal ipx network number. [4] set allow unencrypted passwords=on Most Novell servers on NYU-NET do not use encrypted passwords, because this makes a variety of third-party print servers unusable, and complicates logins from Apple Macintoshes. [5] load ups type=mouse discharge=8 recharge=36 Using a 'ups' (Uninterruptable Power Supply) on file servers is strongly recommended. [6] load NE2 slot=3 frame=ethernet_ii name=ipx_ip load NE2 slot=3 frame=ethernet_snap name=etalk2 In this example, the network board driver 'NE2' is loaded twice, once for 'ethernet_ii' packets (used by IPX and IP protocols) and again for 'ethernet_snap' packets (used by AppleTalk protocols). All Novell file servers on NYU-NET MUST be configured to use the "ethernet_ii" packet type for standard PC-to-server communications. This is a departure from Novell's out-of-the-box 802.3 packet-type, done because Novell's 802.3 uses non-standard, pseudo-802.3 data packets which might cause problems with networking equipment on campus which utilizes correct 802.3. [7] load appletlk net=9876 zone={"NYU SERVERSZONE"} 9876 (just an example!) is the internal AppleTalk network number for this server; this number is centrally assigned by the NYU-NET Network Operations Center (or delegated local authorities) in order to guarantee uniqueness across NYU-NET. The zone name - the AppleTalk zone in which this file server will "appear" - is also centrally assigned; if the server is not being configured to appear in a pre-existing AppleTalk zone, than a request must be sent to 'hostmaster' regarding the establishment of a new AppleTalk zone. (Send E- Mail to hostmaster@nyu.edu). [8] load tcpip rip=no trap= load snmplog Every Novell 3.1x server on NYU-NET MUST load these TCP/IP and SNMP NLMs in order to provide minimal compliance with campus- wide network management via SNMP. http://www.nyu.edu/its/security/handbook.html (27 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook [9] bind IPX ipx_ip net=807A0000 The IPX protocol is used on net 807A0000, the network address for the NYU-NET backbone cabling system. The number 807A0000 MUST be used. [10] bind APPLETLK etalk2 net=10-20 zone={"NYU Ether"} The server communicates over the backbone via AppleTalk protocols using network range 10-20; the name of the "backbone zone" is "NYU Ether". Routing for AppleTalk Phase 2 ONLY is permitted on the NYU-NET backbone. [11] bind IP ipx_ip addr= mask=0xff.0xff.0x0.0x0 bcast= This command configures the server for TCP/IP protocols. Substitute the correct internet (IP) address for the server for "addr=" (just an example number!). [12] load afp ncpw delay300 When loading "afp" (AppleTalk Filing Protocol) to support Macintosh file service, a "delay" parameter like "delay300" reduces the frequency of server updates of Mac workstation desktops. (The ACF uses the 'ncpw' - no change password - parameter, which prohibits Macintosh users from changing their passwords. This is done because ACF servers are part of a NetWare name service domain in which passwords changed from PCs are synchronized across servers in the domain; passwords from MACS are not similarly synchronized, thanks to insufficient Macintosh support by Novell.) [13] patchit.ncf Load NetWare operating systems patches from another .ncf file; the ACF uses one called "PATCHIT. NCF". 10.2 NetWare PC Client There are several software alternatives for DOS clients to Novell servers. In all cases, the workstation software necessary for PCs to communicate with servers is "terminate-and-stay- resident". Special provision must be made for PCs running Microsoft Windows (i.e. extra software elements are used), and particular care should be taken to always run the _latest_ version of Windows/NetWare-related software components. A key consideration when using Novell (or other network operating system software) in the NYU-NET context is the availability (and possible cost) of compatible TCP/IP-based network applications. This is because a majority of campus-wide network services (e.g. electronic mail, campus- wide information service access, library catalog access) are offered via TCP/IP protocols and not NetWare protocols (IPX). The PC workstation software for Novell server access is generically called the NetWare "shell". The various possible configurations which may be used are: 1. Old-fashioned custom-generated workstation shell One component of the workstation software (IPX.COM) is customized by the network manager for the specific network board and its settings for each individual PC. This is the least flexible option, and Novell no longer recommends it. TCP/IP-based software (like Clarkson Telnet and Kermit) cannot generally be used while such a workstation shell is loaded. If this option is used on an Ethernetted PC at NYU, it is necessary for the IPX.COM file to be set to use "Ethernet II" framing. This is done with a utility called ECONFIG. (The NET$OS. EXE server operating system executable for NetWare 2.x file servers must also be ECONFIG'ed.) 2. Packet driver-based standard workstation shell Here, a pre-configured Crynwr "packet driver" (specific to the model of network board being used) underlies a pre-configured, traditional-style IPX.COM. Originally the IPX.COM used for this purpose was generated by BYU; a more up-to-date version comes from Intel, and is found under the name of PDIPX.COM. As found on Internet archives and bulletin boards, http://www.nyu.edu/its/security/handbook.html (28 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook PDIPX.COM needs to be 'econfiged' for the Ethernet 2 packet type; this step has already been performed in ACF-distributed copies. This solution was originally designed to allow the use of TCP/IP applications (like NCSA Telnet) while a NetWare shell is loaded on a PC, and is probably the most common Novell client configuration found on NYU-NET in early 1993. This may be the optimal configuration for users who primarily use packet driver-based TCP/ IP software, but also need some NetWare server access. 3. New-fashioned Novell standard shell sitting atop an ODI (Open Data- Link Interface) network board driver; a PC-based configuration file (NET.CFG) sets any network, PC, or board- specific parameters. This is the official Novell-recommended configuration. Here are extracts from typical configuration files for PCs using ODI: AUTOEXEC.BAT FILE: lsl smc8000 <-- for SMC (Western Digital) boards odipkt 0 127 <-- packet driver atop ODI; interrupt 0x7F winpkt 0x7E 0x7F <-- packet driver shim for Windows use ipxodi <-- if using Novell NetWare netx.exe <-- if using Novell NetWare NET.CFG FILE: Link support buffers 10 2048 Link driver SMC8000 <-- for SMC (Western Digital) boards Frame ETHERNET_II Port #1 300 20 <-- board set to I/O 300 Mem #1 CC000 2000/10 <-- board set to RAM CC000 Int #1 10 <-- board set to IRQ 10 Protocol IPX 8137 ETHERNET_II Protocol IP 0800 ETHERNET_II Protocol ARP 0806 Ethernet_II <-- if using Novell NetWare, then SHOW DOTS = ON <-- use this section READ ONLY COMPATIBILITY = ON LONG MACHINE TYPE = IBM_PC SHORT MACHINE TYPE = IBM IPX RETRY COUNT = 50 SPX ABORT TIMEOUT = 4000 FILE HANDLES = 99 <-- should match config.sys files=99 PRINT HEADER = 255 PRINT TAIL = 50 CACHE BUFFERS = 0 GET LOCAL TARGET STACKS = 10 PREFERRED SERVER = ACFS1 <-- substitute local file server Novell's TCP/IP workstation software, Lan WorkPlace, is one of several networking products which is compatible with ODI drivers. There is also a special "packet driver" (ODIPKT.COM used in the example above) which sits atop ODI drivers and allows use of networking software written to the packet-driver specification (like Clarkson Telnet). This may be the optimal configuration for users whose primary concern is NetWare access, but sometimes use packet driver-based TCP/IP programs. 4. Microsoft Windows for Workgroups NDIS-based NetWare client software. Microsoft's peer-to-peer PC networking software, Windows for Workgroups, is distributed with Novell NetWare compatible software. At initial release (late Fall 1992) this software uses a modified NDIS protocol stack which is not compatible with ODI- or packet driver- based software. As a result, commercial TCP/IP based application software must be run. In the future, Microsoft promises Windows for Workgroups software which runs directly atop TCP/IP, which would better fit into the NYU-NET context than the initial Netbios-based networking software. Please see Appendix C: Notes on Peer-to-Peer Networking at NYU for more information on the viability of Windows for Workgroups on NYU-NET. 11. Guidelines for Setting Up Departmental LANs Establishing a new departmental local area network (LAN) involves many choices and tradeoffs. It is recommended that departmental representatives take the following steps: http://www.nyu.edu/its/security/handbook.html (29 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook q inventory current department computer hardware and software, and determine if any NYU- NET connections are already in place; make a departmental floor-plan indicating the locations of telephones, computers, printers. q survey department staff to determine their communications/networking needs, bearing in mind that the full versatility and value of a departmental network may not be known to people unfamiliar with the technology. q gauge the availability of funds for enhanced computing/networking purposes, both at this time and in coming years. q gauge the availability and ability of internal school/departmental staff to competently manage a LAN, given the following minimum responsibilities: participate in initial installation; train/assist departmental staff; perform basic hardware and software troubleshooting; obtain and install software updates; maintain departmental computing procedures, especially with regard to backup; act as departmental liaison to the NYU-NET Network Operations Center. q bring this information to a consultation with staff members at the Academic Computing Facility who will discuss with you benefits and costs of various networking alternatives. Installation and maintenance services performed by the ACF may also be available. q In the past, some departments have engaged outside consultants to design, install, and even manage departmental networks. Problems have developed in some cases when the outside consultants were unfamiliar with NYU-NET conventions or characteristics. The ACF will gladly work cooperatively with consultants and departmental representatives to prevent any such problems. NYU-NET standard practices should serve as models for new installations; departmental network planners should therefore consider the following points: q Ethernet is the predominant physical connection method on NYU-NET; token-ring is reserved for the exceptionally stout of heart, Arcnet should be avoided entirely. q New Ethernet installations within departmental offices are typically twisted-pair (10BASET) Ethernet; occasionally thin Ethernet (10BASE2) is utilized in laboratory or other contexts where a number of machines are located in the same room; all 10BASET hubs or other concentrators must be purchased with SNMP (network management) capabilities. q Novell NetWare is the predominant network operating system used by departmental networks, so quite a bit of local expertise exists. q Finite bandwidth across the NYU-NET backbone exists; therefore any cross-building departmental networks must be very carefully planned in conjunction with the ACF and the Network Operations Center. q Four to six years after installation, a departmental network is likely to be at least partially "obsolete". Within this interval, various components will require replacement or enhancement, and software may be upgraded many times. Planners are advised to consider both short and long-term budgetary implications of computer networking. 12. NYU-NET Purchasing Guidelines With few exceptions, the choice of networking devices and software is up to the school/department making the purchase; the Network Operations Center staff is ready to advise on the compatibility and suitability of a wide variety of infrastructure and end-user computing devices. In some cases, such as basic infrastructure objects like routers and bridges, it is customary for the Academic Computing Facility to purchase the devices (with departmental transfer of funds) and install them on behalf of schools and departments. 12.1 Advisory: Peer-to-Peer Networking Prospective purchasers of peer-to-peer network operating system products such as: q Windows for Workgroups q Lantastic q NetWare Lite should be sure to consult with the Network Operations Center staff as there may be serious limitations to the use/utility of such products on NYU-NET. If such a product is based on standard routed protocols such as TCP/IP, IPX, or AppleTalk then they should function well at NYU; if, however, they are based on Netbios like Windows for Workgroups and Lantastic, then they may not function well at all in a routed network environment like NYU-NET. 12.2 Advisory: Network Modem Products Prospective purchasers of network modem-service devices such as NetModems, LanRovers, and so on should consult with the Network Operations Center. The ACF maintains a large network modem pool which is growing in size and flexibility; local network modem services will not be necessary if the central pool can satisfy a department's requirements. http://www.nyu.edu/its/security/handbook.html (30 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook 12.3 Standard Brands on NYU-NET The most common, standard brands of networking hardware and software used on NYU-NET are as follows: Ethernet boards: q IBM-type PC - SMC (formerly Western Digital) q Apple Macintosh - Apple, Asante; transceiver connectors from Asante q Novell Server - Novell (typically 16- or 32-bit) 10BASET hubs: q Digital Equipment Corporation q David Systems q Cabletron Systems q LocalTalk hubs: q Farallon Bridges/Routers: q ACC (brouters) q Cisco q Digital Equipment Corporation q Shiva (Fastpath) File Server Operating Systems: q Novell NetWare 3.11 q Apple AppleShare file server Novell NetWare Backup Software: q Cheyenne ArcServer NLM (version 4.0) 3270 Gateway Support: q NetWare for SAA 3270 Gateway (server portion) q 3270 LAN Workstation for DOS/Windows/Macintosh (Client portion) q Rumba 3270 for Windows and OS/2 (client portion) Uninterruptable Power Supply (UPS): q American Power Conversion Smart-UPS w/Power Shute Plus 386 Glossary ACFcluster The Academic Computing Facility's group of VMS-based minicomputers, unified through the Local Area VMScluster (LAVc) protocol. This collection of machines is a major provider of network-based services to the NYU user community, especially electronic mail services. Address A unique code assigned to each device connected to a network. A device may have different and multiple kinds of addresses associated with it: (a) physical address - e.g. the Ethernet address built-in to an adapter; (b) network address - e.g. the IP address assigned to a network interface of a computer for IP purposes, the DECnet address assigned for DECnet purposes. AppleTalk Apple's networking protocols (and software) for communications among computers systems, printers, and other peripherals attached to a network. BOOTP (BOOTstrap Protocol) A client-server, UDP-based protocol for providing network-related startup information including IP host, domain name server, and gateway addresses. This protocol is heavily used at New York University by IBM PC-type and Macintosh microcomputers. The ACF maintains a http://www.nyu.edu/its/security/handbook.html (31 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook set of redundant BOOTP servers. Bridge A device which interconnects (at the data link layer) two sections of network cabling; a data packet is retransmitted from one side of a bridge, typically, if the packet's destination is on the other side. A bridge, therefore, constrains unnecessary traffic across a network. Brouter A device which contains characteristics both of bridges and routers: a brouter will bridge some protocols, and route others. Broadband A network technology which multiplexes multiple, independent network carriers (channels) onto a single cable. The NYU "broadband" is a CATV- type coaxial cable plant, carrying a 5 megabit "Ethernet" channel, a channel for multiplexing point-to-point connections via RF modems, and multiple video channels. A "buffered repeater" is a device used to attach a baseband Ethernet cable segment to the broadband cabling system. CCITT The Comite Consultatif International Tekegraphique e Telephonique International; a standards-making body administered by the International Telecommunications Union. Client A software or hardware component of a system which obtains services from other components, called servers. For example, the user of a client PC can access files over a network from a file server, and may print to a shared printer via a print server. DCTF (Data Communications Task Force) At New York University, the interdepartmental organization which coordinates operation of NYU-NET. DECnet A full set of network service protocols, quite distinct from the TCP/IP protocols but providing many of the same capabilities, originally developed on and for DEC computer system but now implemented on many other platforms. The level of DECnet currently implemented on NYU-NET is DECnet Phase IV; DECnet Phase V, now under development, moves many services to the OSI networking protocol suite. Domain Name System (DNS) The application protocol offering naming service in the Internet suite of protocols. Ethernet A best-effort packet delivery system for local area networks, invented by Xerox in the mid- 1970s and formalized by DEC, Intel and XEROX (DIX). Notable for its use of a "collision detection" mechanism in which simultaneous transmissions by network devices are detected and retransmissions performed. Ethertalk The designation given to AppleTalk protocols when utilized on Ethernet media. FTP (File Transfer Protocol) The application protocol in the Internet suite of protocols offering file services. Gateway A computer system, typically a dedicated special-purpose device, which attaches to two or more networks and routes packets among them. More commonly referred to as a "router" today. The term "gateway" is also commonly used for a variety of devices which route network information from one type of system to another, such as a "mail gateway" which converts and transfers electronic mail from one type of mail system to another. Gopher A distributed information-service protocol (and set of implementations); increasingly used for deploying network-accessible campus-wide information services and other repositories of data. Developed and maintained by the University of Minnesota. Host Any computer system that connects to a network; typically used in the context of TCP/IP network where it usually refers to end-user systems. Internet A set of networks interconnected via routers into a single virtual network. An IP internet is connected by IP routers; an AppleTalk internet is connected by AppleTalk routers. NYU-NET is a member network of the worldwide TCP/IP "Internet". IP (Internet Protocol) The network layer protocol in the TCP/IP protocol suite, providing connectionless, best-effort packet delivery service across a TCP/IP internet. Defines the IP datagram as the fundamental unit of information passed between systems. IPX/SPX http://www.nyu.edu/its/security/handbook.html (32 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook Network layer (Internetwork Packet Exchange) and transport layer (Sequenced Packet Exchange) protocols used by Novell NetWare for communication among clients and servers. Kermit A file transfer protocol (and set of implementations) developed originally at Columbia University, now implemented for most commonly- used computers and operating systems. Requires only a 7-bit data path, allowing its use over and through virtually all communications systems. LAN (Local Area Network) Any one of a number of technologies providing high-speed, low-latency transfer and being limited in geographic size. LocalTalk The name given to AppleTalk protocols when they are utilized over Apple's low-cost, medium- speed (230,400 bps) coaxial cabling system (or third-party twisted-pair equivalents). MacTCP Apple Computer's standard implementation of the TCP/IP protocol stack for Apple Macintosh computers. Most Macintosh TCP/IP applications are written to sit atop MacTCP. MIME (Multi-purpose Internet Mail Extensions) The emerging standard for incorporating multi-media mail contents into Internet (SMTP- based) electronic mail; a set of extensions to SMTP now in the early stages of development and deployment. Netbios A network protocol, typically used for peer-to-peer network communications, which allows a client to communicate with a server process. Not supported as an NYU-NET protocol. Network A collection of inter-connected computer systems, typically composed of end-user computers, wiring (or other communications medium), and infrastructure connection devices (such as hubs, bridges, routers). NIC (Network Information Center) An organizational focal point for providing network information to end- users. Often association with a "network operations center" (NOC). NIU (Network Interface Unit) A terminal server - connecting asynchronous communication devices such as terminals, modems, and microcomputers to an Ethernet - manufactured by Ungermann-Bass and widely used at New York University. Many NIUs on NYU-NET connect physically to the "broadband" cabling system, but more specifically to the Ethernet channel on that cable. A few NIUs are "baseband" NIUs, and connect to Ethernet cables. NNTP (Network News Transfer Protocol) The application protocol offering news article transfer service in the Internet suite of protocols. Thousands of news "groups" (each on a different topic) are read and contributed to by people all over the world. NOC (Network Operations Center) A network operations center is a computer network's focal point for network coordination, information, and central management activities. The NOC for NYU-NET is managed by the university's Academic Computing Facility. NOG (Network Operations Group) At New York University, the group which maintains the University's "broadband" cable system - a cable TV-type cabling system with multiple "channels" for different kinds of data; some channels are used for computer data communications and some are used as video channels. NetWare The flagship product of Novell Incorporated, using Intel-based PCs as file and print servers. An extremely versatile product, NetWare can support a wide range of client systems: DOS and OS/2 PCs, Macintoshes, and UNIX machines. NYU-NET New York University's campus-wide data communications network. Operating System The primary program which runs in a computer and allows other programs to run and use the machine's hardware capabilities. Most IBM-type PCs run the DOS operating system; a newer operating system for PCs is IBM's OS/2. Most minicomputers and workstations use the UNIX operating system. OSI (Open Systems Interconnection) A collection of standards and protocols, developed by the ISO (International Standards Organization), for the interconnection of computer systems from different vendors. http://www.nyu.edu/its/security/handbook.html (33 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook Physical layer That portion of a network system responsible for the electro-mechanical interface to a communications medium and that communications medium itself. POP (Post Office Protocol) An application protocol in the Internet suite of protocols offering mailbox retrieval. Protocol / Protocol Suite A "protocol" is a set of rules describing and formalizing some aspect of a communications process between computer system elements. A "protocol suite" (such as TCP/IP) is a set of interrelated protocols. RARP (Reverse Address Resolution Protocol) A TCP/IP protocols which a client (e.g. a diskless) machine can use to obtain IP information at boot time. Little used on NYU-NET. Router A computing device attached to one or more physical networks responsible for forwarding packets from one network to another as necessary. A router typically works at the "network" layer, as compared with a bridge, which works at the data-link layer. On NYU-NET, one finds: Network Layer Device Network Router Data Link Bridge Physical Repeater, Buffered Repeater A "multi-protocol" router is capable of routing multiple protocols (e.g. IP and AppleTalk and IPX) and can typically act as a bridge for protocols which are non-routable. SMTP (Simple Mail Transport Protocol) The application protocol in the Internet suite of protocols offering message transfer and submission service. SNMP (Simple Network Management Protocol) The application protocol in the Internet suite of protocols offering network management service. Subnet A physical network within an IP network. Subnet Mask A 32-bit quantity indicating which bits in an IP address identify the physical network. TCP/IP (Transmission Control Protocol/Internet Protocol) The two fundamental communications protocols in the Internet suite of protocols, providing for error-free communications of an arbitrarily large inter-connection of computer networks (the Internet). End-user service programs, like Telnet and FTP, are built "on top of" TCP/IP. Telnet The application protocol offering virtual terminal service in the Internet suite of protocols. Terminal Server A communications device which connects multiple asynchronous communication devices such as terminals, modems, and microcomputers to a network. UNIX The multi-user, multi-tasking operating system used on most workstations and minicomputers. There are many variants of UNIX. VMS The Digital Equipment Corporation (DEC) operating system which runs on DEC workstations and minicomputers (such as the ACFcluster). A multi- user, multi-tasking, virtual memory- based system. XNS The Xerox Network System, a network architecture which survives today, primarily, as the source and basis for Novell NetWare's IPX/SPX protocol suite. X.25 The CCITT standard for packet-switched networks. X.400 The CCITT standard for message handling services (electronic mail). X.500 The CCITT standard for directory information on an X.400 network. http://www.nyu.edu/its/security/handbook.html (34 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook Appendix A: A Description of NYU-NET NYU-NET may be characterized as a multiple media The networking infrastructure of NYU-NET is composed of many building blocks: cabling of different kinds (e.g. fiber-optic, coaxial, copper twisted-pair) and infrastructure devices which interconnect the wiring of different types. The resulting "multiple media" cabling plant is flexible and adaptable to new users and new technologies. multi-protocol A multi-protocol network is one that can be used by different communications protocols simultaneously. "Protocols" are the "rules" for communications between computers, and many sets of such rules are currently in wide use. Some computer networks are restricted to using a single communications protocol; NYU-NET, by comparison, has been designed for the greater flexibility afforded users of a multi-protocol network. standards-based The hardware, software, and communications protocols used on NYU-NET are "standards"- based. That is, they are defined and designed in accordance with "standards" (some official, some de facto; some written, some not) which thereby permit a wide variety of equipment to cooperatively interoperate. The core (but not sole) standards observed by NYU-NET equipment are those of the TCP/IP protocol suite. multi-campus NYU is comprised of several different campuses; NYU-NET ties together these locations using different media depending on the needs of users at a particular campus. Some of the connections are via high speed fiber-optic cable, and some are via slower leased telephone lines. multi-building At each campus center of the university, a different wiring media may be used to interconnect the various buildings, thus forming a "backbone network" at that campus. At Washington Square the backbone wiring currently is a CATV broadband cabling system; at the Dental Center, an Ethernet backbone is used; at the Medical Center a complex collection of fiber optic and coaxial cabling forms the backbone tying buildings together. evolving NYU-NET is an evolving, rapidly-growing entity. As technology has advanced, and continues to advance, the network adapts to changes in the computer field and in end-user needs. bridged extended local area network. NYU-NET is, for the most part, a bridged - as opposed to a routed - network. Bridging technology was adopting in the early years of NYU-NET (mid 1980s) for cost and convenience reasons. At selected locations, however, routers have recently been introduced as the first steps in the evolution of NYU-NET from a bridged to a routed network. A full transition to a routed network may not take place until 1994, since this evolution must be slowly and carefully implemented in order that network users not be negatively impacted by the transition. Appendix B: Obtaining Network Names and Numbers When a computer or network infrastructure device (such as a workstation, PC, hub, bridge, or router) is ready for attachment to NYU-NET, an Internet name and numeric address must be assigned by the Network Operations Center, or by a authorized NYU-NET sub-domain authority. This rule applies to all equipment, including Novell NetWare file servers, with the general exception only of Macintoshes being attached to a LocalTalk network segment. The "database" of such Internet names and numbers is part of the "DNS" (Domain Name Service). Most NYU-NET protocols require coordinated networking naming and numbering: TCP/IP, AppleTalk, Novell IPX, and DECnet. For address and name assignment, send E-mail to hostmaster@nyu.edu or to your local school authority for network address/name assignment. The following information is required: q Proposed name of machine: q Type of machine: q Machine operating system: q Location of machine: q Person responsible for machine: http://www.nyu.edu/its/security/handbook.html (35 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook q E-mail address of responsible person: q Ethernet address of machine: All PC and Macintosh microcomputers which are assigned IP addresses and names by the NOC are required to use the BOOTP protocol to obtain authoritative IP information at the runtime. When the addresses and names are assigned, entries in BOOTP tables are also made. Other divisions of the university are strongly encouraged to adopt the use of BOOTP as well. In the case of machines at the Medical Center, the Stern School, and several smaller locations, sub- domain naming authority has been delegated to network managers at those locations: q Medical Center - send E-Mail to smith@nyu-medical.med.nyu.edu q Stern School - send E-Mail to kwieman@stern.nyu.edu q 10th/12th Floors - send E-Mail to kenner@vlsi1.ultra.nyu.edu q 715/719 Broadway (this is subnet) q CIMS - send E-Mail to staff@cs.nyu.edu subnets 153 and 140 in WWH and 715/719 Broadway) Appendix C: Notes on Peer-to-Peer Networking at NYU Microcomputer networks fall into two rough categories: server-based and peer-to-peer. In a server- based network, there's one or more rather powerful machines (servers) which individual PCs or Macintoshes can access - e.g. they can store files on the server's hard disk or print on a printer attached to the server. In a peer-to-peer network, individual microcomputers can access the resources of other microcomputers - e.g. user A can print on user B's printer. There are various gradations between these two poles: for example, with Macintosh System 7, "file sharing" between Macintoshes is a built-in operating system feature. This capability can be used in combination with a file server - there is no conflict between Macintosh peer-to-peer file sharing and file server access. In the case of Macintosh peer-to-peer networking, the only problems which arise in the larger NYU- NET context are security- related: individual machines must be carefully set up to require username/ password access. Otherwise the data on hard disks will be available to snoopers (playful or otherwise) anywhere on the network. Third-party add-on products (such as Lantastic or NetWare Lite) typically provide peer-to-peer networking for IBM-type PCs. With the release, however, of Microsoft's Windows for Workgroups, peer-to-peer networking is for the first time an "operating system feature" on IBM- type PCs. While peer-to-peer networking of PCs is not very common at New York University, there are various departmental networks - unattached to NYU-NET - which use such products (particularly Lantastic). There are serious problems using IBM PC peer-to-peer networking on machines or departmental networks attached to NYU-NET. These derive from the protocols used: Peer-to-peer products like Windows for Workgroups typically use the Netbios protocol for network communications. Unfortunately, Netbios was not designed with large internets (like NYU-NET) in mind; it is unlikely that Netbios-based products will work across the NYU-NET multiprotocol routers planned for installation in 1993. In order to use TCP/IP-based utilities (such as TELNET) in conjunction with such products, it is typically necessary to purchase additional commercial TCP/IP software - the standard "free" TCP/IP software commonly used at NYU doesn't work in combination with peer-to-peer networking products. Windows for Workgroups - although basically Novell NetWare compatible - is not compatible with Novell ODI drivers, the recommended data-link drivers for Novell NetWare. Many organizations have banned Windows for Workgroups on their networks as a result of the technical, support, and security issues involved in its use. In fact, as of Winter 1992-93, Microsoft has released information on how to disable various networking features of the product and has announced that peer-to-peer networking features will not be a standard part of MS-DOS 6. These changes resulted from wide-spread concerns about integrating Windows for Workgroups into pre- existing networks. If Microsoft releases TCP/IP transport support for Windows for Workgroups, as promised, then it should fit into NYU-NET as well as does Macintosh System 7: primary concerns at that point will be privacy of local data and the possible necessity still for commercial TCP/IP utilities to be purchased http://www.nyu.edu/its/security/handbook.html (36 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook for full NYU-NET functionality. As of March 1993, the ACF and the Network Operations Center strongly recommend AGAINST purchasing or using Windows for Workgroups on machines attached via network connections to NYU- NET; if end-users deploy the product and later wish to attach their departmental networks to NYU- NET, it may be required that the product's networking capabilities be disabled. Appendix D: MacTCP - Availability and Installation MacTCP is Apple Computer's TCP/IP networking software for Macintosh computers. This software provides the necessary foundation for other Mac networking software (such as the Eudora electronic mail program and the NCSA Telnet terminal emulator). The Academic Computing Facility has licensed MacTCP on behalf of New York University for use on machines connected to NYU-NET. MacTCP, as configured and distributed by the ACF, requires that Macintoshes obtain their fundamental networking information via the network itself at the time that the software is used. For a Mac on a localtalk network, this means that a Shiva Fastpath gateway (to the rest of NYU-NET) provides IP information to the Mac; for a Mac on a Ethernet which is part of NYU-NET, MacTCP is configured to obtain IP information via the BOOTP protocol. This configuration policy is designed to simplify installation and configuration for end-users, and reduce the possibility that misconfigurations will occur. If your Mac is directly connected to an 'Ethernet' network, a unique Internet address must be assigned it prior to your being able to use MacTCP-based networking software. Note the instructions in step 4 (B), below. To obtain MacTCP: A copy the MacTCP software - properly configured for use on NYU-NET - can be obtained from the Academic Computing Facility, Faculty Micro- computer Laboratory, Room 312 Warren Weaver Hall (212-998-3044). A floppy disk is required. Hours 12 noon - 8 PM. Note: When using MacTCP 1.1 (now outdated) on a Macintosh Plus running System 7, be sure to use Apple's MacTCP+ Tool to overcome serious performance problems with MacTCP on that system. MacTCP version 1.1.1 or later rectifies the problem with MacTCP 1.1, and the MacTCP+ Tool is no longer required. To install MacTCP: 1. Turn off any virus protection software you have installed on your Macintosh (with the exception of Disinfectant, which presents no problems). 2. On a System 6 Macintosh, drag the MacTCP control panel into your System Folder. Continue with step 3 below. On a System 7 Macintosh, drag the MacTCP control panel on top of the closed System Folder, and watch it go into the System Folder's Control Panels folder. Continue with step 3. 3. Restart your Macintosh. 4. Select Control Panel(s) from the Apple Menu. r If your Mac is on a 'localtalk' network, make sure that the Network control panel has 'LocalTalk' (Built-In) selected. Continue with step 5 below. r If your Mac is on an 'Ethernet' network, make sure that the Network control panel has 'Ethertalk' selected. On the Ethernet, your Macintosh _must_ be assigned its own, unique Internet address. If this has not already been done, send electronic mail to hostmaster@nyu.edu and provide the following information: s Your name s Your departmental affiliation s Your phone number s Location of your machine, and model of Macintosh s Proposed name for your machine (e.g. 'smithmac' or 'jonesmac') s Built-in Ethernet address of your Macintosh You obtain the built-in Ethernet address of your Macintosh by performing 'option- click' on the 'Ethernet' icon in the MacTCP control panel. The numerical Ethernet http://www.nyu.edu/its/security/handbook.html (37 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook address will materialize just below the Ethernet icon. r Open the MacTCP control panel, and click on the "More..." radio button. Observe the "Domain Name Server Information" in the lower right-hand quadrant of the display. Two entries should appear, as follows: Domain IP address Default nyu.edu * . Note the "." (period) below "nyu.edu". These settings must be correct, in this fashion, for MacTCP to be able to correctly query NYU-NET's redundant name servers. If you find different settings, you will want to obtain an updated version of the MacTCP control panel from the Academic Computing Facility. 5. If you disabled Virus protection in step 1 above, re-enable it now. 6. At this point, MacTCP-based networking applications (such as NCSA Telnet) can be installed. Appendix E: Recommended Readings Comer, Douglas E. Internetworking with TCP/IP, Volume I: Principles, Protocols, and Architecture, Second Edition, Prentice-Hall, 1991. The classic textbook for gaining basic knowledge about the TCP/IP protocol suite and a fundamental understanding of internetworking principles and issues. Hunt, Craig. TCP/IP Network Administration, O'Reilly & Associates, 1992. A practical guide for UNIX system managers, which detailed specific examples drawn from Berkeley, SCO, and UNIX System 5 versions of UNIX. Kosiur, Dave and Nancy E. H. Jones. MacWorld Networking Handbook, IDG Books Worldwide, Inc., 1992. An excellent practical guide to understanding, setting up, and managing AppleTalk networks. Malamud, Carl. Analyzing Novell Networks, Van Nostrand Reinhold, 1990. A now-aging, but still excellent, overview of Novell NetWare and its protocols. Emphasis is on NetWare 3.x and related products. McCann, John. NetWare Supervisor's Guide, M&T Books, 1992. A practical guide to Novell NetWare management, covering both NetWare 2.2 and NetWare 3.11 versions. Provides both background networking information as well as many practical hints. Sidhu, Gursharan. Inside AppleTalk, Second Edition, Addison Wesley, 1990. The authoritative guide to the AppleTalk protocol suite. Stallings, William. Handbook of Computer-Communications Standards, Volume 2: Local Area Network Standards, Second Edition, Howard W. Sams & Company, 1990. An authoritative and fairly technical reference source for understanding the basic IEEE 802 standards; also covers such diverse topics as network topologies, FDDI standards, MAC-layer bridges and the Spanning Tree algorithm, the OSI reference model, and error detection. Addendum 1, Revision 9, 8/26/94 Changes to the NYU-NET Technical Handbook 9. 8/26/94 Updated: Addendum 7.8 - Current Microcomputer Networking Software - Update of some NetWare components and SMC SuperDisk 6.5 and Win32S 8. 7/01/94 Updated: Addendum 7.7 - Current Microcomputer Networking Software - Addition of Microsoft Windows software Update of WINPKT and ODIPKT 7. 11/14/93 Updated: Addendum 7.6 - Current Microcomputer Networking Software - Addition of Novell updates 6. 09/27/93 New: Addendum 11.0 - Policy on Internet Access 5. 09/27/93 Updated: Addendum 7.5 - Current Microcomputer Networking Software - Addition of many updates 4. 09/11/93 Updated: Addendum 7.4 - Current Microcomputer Networking Software Addition of 3 NetWare updates: seclog.exe, pserv5.exe, isa311.exe 3. 08/06/93 New: Addendum 10.0 - NetWare 4 on NYU-NET http://www.nyu.edu/its/security/handbook.html (38 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook 2. 08/02/93 Updated: Addendum 7.1 - Current Microcomputer Networking Software - Addition of many NetWare updates 1. 06/23/93 New: Addendum 9.0 - Viruses and Novell NetWare 0. 06/01/93 Edition 1 published Addendum 2, Revision 0, 6/1/93 Primary NYU-NET Contacts In order to... Contact... Obtain general end-user ACF HelpLine informationand assistance (212) 998-3333 Contact Network Operations Center on E-Mail: noc@nyu.edu NYU-NET and external network issues (212) 998-3450 Request network numbers/names E-Mail: hostmaster@nyu.edu Arrange for consulting assistance on Gary W. Chapman, Coordinator Systems & setting up departmental networks Networks Services, ACF (212) 998-3045 E-Mail: chapman@nyu.edu Discuss aspects of networking at New Network news group: nyu.nyunet York University with other members of the community Discuss NYU-NET policies and future George Sadowksy, ChairData developments Communications Task Force (212) 998-3040 E-Mail: sadowsky@nyu.edu Addendum 3, Revision 0, 4/1/93 NYU-NET Architecture Map It is impossible, in a simple diagram, to fully indicate the architecture of NYU-NET with its many connection media, sub-nets, service hosts (such as routers and name servers), and end-user equipment. The following sketch shows the basic connection of NYU-NET to the Internet and some of the basic media connections to different NYU areas. http://www.nyu.edu/its/security/handbook.html (39 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook Addendum 4, Revision 0, 6/1/93 NYU Staff with Network Responsibilities [Ed: This list is no longer current or accurate.) http://www.nyu.edu/its/security/handbook.html (40 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook Name E-Mail Affiliation Carlo Cernivani cernivani@acfcluster.nyu.edu ACF/NOC Gary Chapman chapman@acfcluster.nyu.edu ACF/NOC Mario Clagnaz clagnaz@acfcluster.nyu.edu ACF Eray Ekici ekici@acfcluster.nyu.edu ACF Edi Franceschini franceschini@acfcluster.nyu.edu ACF Larry Mingione mingione@acfcluster.nyu.edu ACF Gary Rosenblum rosenblg@acfcluster.nyu.edu ACF/NOC Bill Russell russell@acfcluster.nyu.edu ACF/NOC George Sadowsky sadowsky@acfcluster.nyu.edu ACF Stephen Tihor tihor@acfcluster.nyu.edu ACF Admin/Personnel/ Scott Baker baker_s@precords.pers.nyu.edu Ctrller Gillian Carter gillian@facrec.admin.nyu.edu Admin/Faculty Records Jeff Dong dongje@acfcluster.nyu.edu Admin/Purchasing Admin/Sponsored Alex Garrison garrisna@acfcluster.nyu.edu Programs Jim Gibby none at present Admin/Reprographics Admin/Sponsored Amy O'Hara oharaamy@acfcluster.nyu.edu Programs John Johnson none at present Admin/Career Services Admin/Office- Irene Zabarkes zabarkes@acfcluster.nyu.edu President Diane Aquila aquila@acfcluster.nyu.edu BOBST Scott Yates yates@boblab1.bobst.nyu.edu BOBST/Microlab Susan Kallenbach skallenbach@acfcluster.nyu.edu BOBST Tim O'Connor tim.oconnort@nyu.edu BOBST Kathy Bear beark@acfcluster.nyu.edu Book Center Andy Hagerty hagerty@thewheel.nyu.edu CIMS Andy Howell howell@spunky.cs.nyu.edu CIMS Matthew Smosna smosna@cs.nyu.edu CIMS Bob Picardi rp@cns.nyu.edu CNS/Psychology Jeff Fookson jeff@cns.nyu.edu CNS Ariel Spivakovsky spiv@cns.nyu.edu CNS David Tanzer davidt@cns.nyu.edu CNS Eric B Buvron buvrone@acfcluster.nyu.edu DENTAL/AIS David Romand romand@acfcluster.nyu.edu DENTAL http://www.nyu.edu/its/security/handbook.html (41 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook Frank Boyer none at present FAS/Expository Writing Dan Chusid none at present FAS/Journalism Allan Gottlieb gottlieb@allan.ultra.nyu.edu FAS/CS Ultra Lab Cathy Moran Hajo hajo@acfcluster.nyu.edu FAS/History Edward J. Huff huff@mcclb0.med.nyu.edu FAS/Chemistry Robert Jackson jackson@acfcluster.nyu.edu FAS/Sociology Helen Jones jonesh@acfcluster.nyu.edu FAS/Applied Science Richard Kenner kenner@vlsi1.ultra.nyu.edu FAS/CS Ultra Lab Ken Rogoza rogoza@fasecon.econ.nyu.edu FAS/Economics Steve Wilson wilsons@acfcluster.nyu.edu FAS/Chemistry Moy Wong moy@xp.psych.nyu.edu FAS/Psychology Julie Baker bakerj@acfcluster.nyu.edu LAW Kina Leitner sad_kd@vhlawsis.law.nyu.edu LAW/MIS Stuart Spore spore@acfcluster.nyu.edu LAW/Library Joe Dorn dorn@acfcluster.nyu.edu NOG Basil Katradis katradis@acfcluster.nyu.edu NOG Serf_Aguas@macmail.med.nyu. Serf Aguas MED/MIS edu Kenny Chu chu@mcclb0.med.nyu.edu MED/Medical Library Michael Downs downs@mcclb0.med.nyu.edu MED/MIS Suzy Gottesman gottesman@mcclb0.med.nyu.edu MED/Cell Biology John Graefe graefe@sfclu.med.nyu.edu MED/Sterling Forest John Hill hill@mcclb0.med.nyu.edu MED/Cell Biology Sanj Hiranandani hira@mcclb0.med.nyu.edu MED/MIS DJ James djjames@charlotte.med.nyu.edu MED/Sterling Forest Sara Kranczer kranczer@mcclb0.med.nyu.edu MED/Pharmacology Jim Kyriannis jimmy@wombat.phri.nyu.edu MED/PHRI MED/Brain Research Pierre Landau pierre@cs.nyu.edu Labs Peggy Lim plim@mcclb0.med.nyu.edu MED/Medical Library Ravi Narsipur narsipur@mcgcr0.med.nyu.edu MED/GCRC Marilyn E. Noz noz@nucmed.med.nyu.edu MED/Nuclear Med David Ohlmer ohlmerd@acfclu.nyu.edu MED/Sterling Forest Danny Orellana orellana@mcclb0.med.nyu.edu MED/CC/Pediatrics Frieda Pavel pavel@mcclb0.med.nyu.edu MED/Cell Biology Edwin Ramirez ramirez@mcclb0.med.nyu.edu MED/Library http://www.nyu.edu/its/security/handbook.html (42 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook Keith Ruskin ruskin@acfcluster.nyu.edu MED/Anaesthesiology Ross Smith smith@mcclb0.med.nyu.edu MED/Cell Biology Roy Smith roy@mchip00.med.nyu.edu MED/Microbiology MED/Environmental Mark Waldman waldman@mcgcr0.med.nyu.edu Med Zelda Owens zso@wombat.phri.nyu.edu MED/ADARC Waters Ron Wood wood@mvax.med.nyu.edu MED/Sterling Forest Troy Downing downing@acfcluster.nyu.edu SEHNAP/Art Nixy Kuttemperoor kuttmprr@acfcluster.nyu.edu SEHNAP/HEOP Flo Ragusa ragusa@acfcluster.nyu.edu SEHNAP/Metro Center Don Plym plymd@acfcluster.nyu.edu SEHNAP/Music Bob Corre corre@option.stern.nyu.edu Stern/CIS Rafael Esparra resparra@stern.nyu.edu Stern/CNS Stanley Fogg fogg@stern.nyu.edu Stern/CNS Daniel Graham dgraham@stern.nyu.edu Stern/CNS Binh Ho bho@stern.nyu.edu Stern/ATG Manny Ho mho@stern.nyu.edu Stern/CNS Damir Mijacika damir@stern.nyu.edu Stern/CNS Carlos Webb cwebb@stern.nyu.edu Stern/CNS Karl Wieman kwieman@rnd.stern.nyu.edu Stern/ATG Jeffrey Berg berg@acfcluster.nyu.edu TSOA/ITP Bill Bruns bruns@acfcluster.nyu.edu TSOA/Student Affairs Catherine Holter holter@acfcluster.nyu.edu TSOA/Cinema Studies Michael Keeler keelerm@acfcluster.nyu.edu TSOA/Info Services Phil Sanders ps@acfcluster.nyu.edu TSOA/ITP Joe DiMeo urjdm@uccvm.nyu.edu UCC Ted Dzierzynski urtjd@uccvm.nyu.edu UCC Kwong Kam urkwk@uccvm.nyu.edu UCC Efim Rubenchik uzexr@uccvm.nyu.edu UCC Sharif Samman ursas@uccvm.nyu.edu UCC Addendum 5, Revision 0, 4/1/93 Recent NYU-NET Developments Transition to Phase 2-only AppleTalk Routing Complete, 2/19/93 AppleTalk NYU-NET Backbone Re- Numbering Performed In early February, the last remaining Phase 1 - Phase 2 transitional AppleTalk routers were reconfigured for Phase 2 routing only. At that point the backbone network range remained "3-3", allowing a maximum of 253 Ethertalk devices on the campus network as a whole. This number was http://www.nyu.edu/its/security/handbook.html (43 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook achieved during February, leading to intermittent AppleTalk problems on the network. On February 19, all AppleTalk routers were reconfigured to use network range "10-20" (except a few configured as non-seed routers). This new range would permit over 2500 Ethernet devices on "the backbone" - a number which will never be achieved due to planned segmentation of NYU-NET by multi-protocol routers. The mid- to long- range vision is that the NYU-NET backbone will consist only of routers and service hosts, and not end-user computing systems (such as PCs or Macintoshes). The move to network range "10-20" can thus be seen as a short term solution for a serious problem due to rapid network growth. Transition to Phase 2-only AppleTalk Routing on NYU-NET, 1/15/93 As of January 15, 1993 the changeover of NYU-NET from AppleTalk transitional routing (Phase 1 and Phase 2 both present on the campus backbone), is almost complete. Only four Phase 1 devices remain, three ACF Novell servers which act as transitional routers, and one departmental NetWare 2.15 server (NYU_REPRO) which only has software (presently) for Phase 1 AppleTalk. As soon as updated AppleTalk software is procured for that server, it will be updated to use a Phase 2 driver, and the ACF Novell servers will be reconfigured as Phase 2- only AppleTalk routers. Estimated time of completion: 2/1/93 10 MBPS from Washington Square to the Dental/Medical Centers, 1/15/93 The link from Warren Weaver Hall to the Dental Center, and thence to the Medical Center, has been upgraded to a full 10 MBPS as a result of installation of a new fiber-optic link at 8 Washington Place (replacing the broadband link there). The broadband now provides a partial backup link for access to NYU-NET from the Dental/Medical centers. Addendum 6, Revision 0, 6/1/93 List of TCP/IP Subnets IP Speed/Type B/R Router Manage 128 10MB EN Bridge ACF - routers/servers 129 10MB EN Bridge CIMS - Robotics / Ultra 130 10MB EN Bridge Stern - misc 131 10MB EN Bridge Stern - misc Pyschology - Meyer 132 10MB EN Bridge Hall Chemistry - Brown / 133 10MB EN Bridge Main 134 10MB EN Bridge Physics - Meyer Hall 135 10MB EN Bridge MC - various PHRI & ADARC - 136 10MB EN Bridge various 137 56KB SL Route PHRI (NC) 138 5MB BB Bridge ACF - WSQ Broadband 139 10MB EN Bridge MC - Bellevue C&D 140 10MB EN Bridge CIMS - CS 141 10MB EN Bridge ACF - Education Site ACF - 3rd Ave North 142 10MB EN Bridge Basement 143 10MB EN Route MC - Sterling Forest http://www.nyu.edu/its/security/handbook.html (44 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook 144 10MB EN Route MC - Bellevue MIS 145 10MB EN Bridge FAS - Journalism 146 4MB TR Route ACF - Test Token 147 10MB EN Bridge UCC - Broadway FAS - EW in 269 148 10MB EN Bridge Mercer 149 10MB EN Bridge Bobst - Library 150 10MB EN Bridge ACF - 14 Wash Site ACF - Tisch Hall LC 151 10MB EN Bridge Site 152 10MB EN Bridge OSP - 15 Wash Site 153 10MB EN Bridge CIMS - CS Pyschology - CNS - 154 10MB EN Bridge Meyer Hall 155 10MB EN Bridge Dental - Weismann 156 10MB EN Route MC - NucMed Ether 157 10MB EN Route Stern - spare (NC) FAS - Economics & 158 10MB EN Bridge Sociology 159 10MB EB Bridge LAW - Vanderbilt Hall Pyschology - CCS - 160 10MB EN Bridge Meyer Hall ACF - 25W4th Street 161 10MB EN Bridge various 162 10MB EN Bridge MC - Kips Bay 163 10MB EN Bridge MC - Schwartz HCC ADMIN - Bobst Exec 164 10MB EN Bridge Offices ADMIN - Shimkin Info 165 10MB EN Bridge (NC) 166 3MB BP Route CIMS - Robotics 167 10MB EN Bridge MC - Milhauser 168 10MB EN Bridge MC - Bellevue 169 10MB EN Bridge TSOA - Film / Photo ADMIN - Kimball Hall 170 10MB EN Bridge (RG) ADMIN - 269 Mercer 171 10MB EN Bridge (PURCH) 172 10MB EN Bridge MC - 25th Street 173 10MB EN Route Stern - spare (NC) 174 10MB EN Route Stern - spare (NC) http://www.nyu.edu/its/security/handbook.html (45 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook Pyschology - CNS - 175 10MB EN Route Meyer Hall Bobst - Library Micro 176 10MB EN Bridge Lab ADMIN - Kimball Hall 177 10MB EN Bridge (PERS) 178 10MB EN Route Stern - spare (NC) Stern - MEC G 179 10MB EN Route Students Stern - MEC UG 180 10MB EN Route Students Stern - MEC UG 181 10MB EN Route Students 182 10MB EN Route Stern - TH Servers 183 10MB EN Route Stern - TH Servers 184 10MB EN Route Stern - TH Servers 185 10MB EN Route Stern - TH Servers 186 10MB EN Route Stern - TH Servers 187 10MB EN Route Stern - TH Faculty 188 10MB EN Route Stern - TH Faculty Stern - MEC UG 189 10MB EN Route Students 190 10MB EB Bridge LAW - Vanderbilt Hall 191 10MB EB Bridge LAW - Fuchsberg Hall 192 10MB EB Bridge LAW - DAG Hall 193 10MB EB Bridge LAW - Mercer Hall (NC) 194 10MB EN Route Stern - MEC Faculty 195 10MB EN Route Stern - MEC Faculty 196 10MB EN Route Stern - MEC Faculty 197 10MB EN Route Stern - MEC Faculty 198 10MB EN Route Stern - spare (NC) 199 100MB FR Route Stern - TH FDDI 200 10MB EN Route Stern - Shimkin Dean 201 10MB EN Route Stern - Admin 202 16MB TR Route MC - MIS Token Ring 203 16MB TR Route MC - MIS Token Ring ADMIN - Kimball Hall 204 10MB EN Bridge (CDV) 205 10MB EN Bridge MC - Ehrman-Library http://www.nyu.edu/its/security/handbook.html (46 of 55)8/31/2006 1:23:13 PM
    • NYU-NET Technical Handbook ACF - WWH 2nd Floor 206 10MB EN Bridge (NC) 207 10MB EN Bridge ACF - WWH 3rd Floor 208 10MB EN Bridge ACF - WWH RISC 209 100MB FR Bridge ACF - WWH FDDI (NC) ACF - 25W4th Street 210 10MB EN Bridge various FAS - EW in Wing 211 10MB EN Bridge Building ADMIN - Health 212 10MB EN Bridge Services 213 10MB EN Route MC - MRI Ether 214 10MB EN Route MC - MIS Ether 215 10MB EN Route MC - MIS MVS MC - MIS Test Ether 216 10MB EN Route (NC) MC - 2 Penn Plaza 217 56KB SL Route (NC) 218 16MB TR Route MC - 30th Street 219 56KB SL Route MC - 30th Street 220 16MB TR Route MC - Food Service 221 16MB TR Route MC - spare (NC) 222 16MB TR Route MC - NYC CME (NC) 223 10MB EN Bridge Dental - Schwartz (NC) ADMIN - 7E12th 224 10MB EN Bridge Street (REG) ADMIN - Wash Square 225 10MB EN Bridge North 226 10MB EN Bridge SE - Press Building 227 10MB EN Route SE - HEOP - Admin 228 10MB EN Bridge ACF - Goddard Hall 229 10MB EN Bridge SE - Wash Square East ACF - Third Ave North 230 10MB EN Bridge Res Tower 231 56KB SL Route MC - Sterling Forest MC - Tisch Hospital 232 10MB EN Route OR (NC) MC - Bellevue 233 10MB EN Route NeuroSurg (NC) MC - Bellevue 234 10MB EN Route Radiology (NC) 235 10MB EN Route MC - spare (NC) http://www.nyu.edu/its/security/handbook.html (47 of 55)8/31/2006 1:23:14 PM
    • NYU-NET Technical Handbook 236 10MB EN Route Physics - HEP (NC) ACF - WWH RISC 237 10MB EN Route Switch 238 10MB EN Route SE - HEOP - PCs 239 10MB EN Route SE - HEOP - PCs 240 10MB EN Bridge SE - ALT 241 10MB EN Route ACF - spare (NC) 242 10MB EN Bridge LEOB - Students 252 10MB EN Route ACF - Test Ether 253 10MB EN Route ACF - Test Ether 254 10MB EN Route ACF - Test Ether Notes: 56KB 56 Kilobits / Second 1.5MB 1.5 Megabits / Second 4MB 4 Megabits / Second 10MB 10 Megabits / Second 16MB 16 Megabits / Second 100MB 100 Megabits / Second BB = Broadband EN = Ethernet (Baseband) FR = FDDI Ring SL = Serial Line TR = Token Ring Addendum 7, Revision 8, 8/26/94 Current Microcomputer Networking Software The following list gives the most recent version numbers of micro- computer networking software in use on NYU-NET. Obtain these items via "anonymous FTP" to acfcluster.nyu.edu; 'cd' to directory NYUNET/. Changes for Revision 8 of this addendum are: For IBM PCs: New: NET33X.EXE 11/17/93 Current NetWare shells New: WINUP9.EXE 01/20/94 Netware-related Windows components New: DOSUP9.EXE 01/21/94 Netware DOS components New: SUPR65.ZIP 03/17/94 SMC SuperDisk version 6.5 Updated: WIN32S.ZIP WIN32s extensions for Windows, version 1.15 For Microsoft Windows: (directory 'windows') Product Version File WINSOCK-based TCP/IP stack 1.0b6 winsock.zip WIN32s extensions for Windows 1.15 win32s.zip http://www.nyu.edu/its/security/handbook.html (48 of 55)8/31/2006 1:23:14 PM
    • NYU-NET Technical Handbook Describes ACF collection of software --- wnyunet1.txt ACF collection of TCP/IP software 1 wnyunet.zip GV gif, jpeg graphics viewer 0.58x gv057.zip LVIEW gif, jpeg graphics viewer 3.1 lview31.zip MPEG movie viewer (requires win32s) 3.2e mpegw32e.zip QTW quicktime movie viewer 1.1 qtw11.exe Sound file player (for audio boards) 1.31 wham131.zip BCgopher client 0.8b3 bcgo8ba3.zip Cello WWW browser 1.01a cello.zip Eudora mailer 1.4 eudora14.exe Eudora mailer update 1.42b16 weudora.exe HGCSO (Ph client) 1.1 hgcso.exe TN3270 for Windows 3.1e qws3270.zip Telnet/FTP (QVTNET, shareware) 3.97 qvtws397.zip Telnet (Peter Tattam, not very good) 0.6 trmptel.exe TCP/IP applets (Tattam, not very good) --- winapps.zip Mosaic WWW browser 1.0 wmos1_0.zip Mosaic WWW browser, version 2 2.0a5 wmos20a5.zip WSgopher client 1.0 wsg-10.exe Trumpet netnews reader (shareware) 1.0a wtwsk10a.zip Trumpet netnews reader (shareware) 1.0b wt_wsk.exe For Apple Macintosh (directory mac): Product Version File Utils to find Mac Ethernet Address ------ enetaddress.sithqx Eudora (Qualcomm) 1.3.1 eudora131.sithqx Eudora (Qualcomm) - System 7 only 1.4 eudora14.sithqx Fetch (Dartmouth College) 2.1.1 fetch211.sithqx K-Star (Shiva) 9.1.2 shiva24.sithqx MacTCP CDEV (Apple) 1.1.1 (NYU site use) NCSA Telnet (NCSA) 2.5 ncsa25.sithqx Network Installer Disk (Apple) 1.4 netinstall14.seahqx Pegasus Mail for Macintosh 2r4 pmail204.sithqx Shiva NetManager (Shiva) 2.4 shiva24.sithqx TN3270 (Brown University) 2.3d26 tn327023.sithqx http://www.nyu.edu/its/security/handbook.html (49 of 55)8/31/2006 1:23:14 PM
    • NYU-NET Technical Handbook TN3270 (Brown University) 2.4 tn327024.sithqx TurboGopher (U. Minnesota) 1.0.7c turbogopher.sithqx Xferit 1.5b4 (NYU site use) MacTCP and Xferit are available from the ACF to members of the NYU community. Contact the ACF Faculty Microcomputer Lab at 998-3044. For IBM PC (directory msdos): Product Version File Charon SMTP Gateway (Clarkson Univ) 4.0a charon40.zip Clarkson Telnet (Clarskon Univ) 2.2E tn3270.zip HYTELNET 6.5 hyteln65.zip Mercury 1.1 1.1 merc110.zip MS-Kermit (old) 3.12 kerm312.zip MS-Kermit (as distributed by ACF) 3.13 kerm313.zip MS-Kermit (full as distrib by Columbia) 3.13 msvibm.zip NCSA Telnet (NCSA) 2.305 ncsa2305.zip NUpop (Northwestern University) 1.0.3 nupop103.zip NUpop (Northwestern University) 2.0 nupop20.zip ODIPKT (Harvard) 3.0 odipkt30.zip Packet Driver collection (Crynwr) 10.x packet10.zip PC Gopher III (U. Minnesota) 1.1.2 pcgopher.zip PDIPX (Intel) 1.03 pdipx103.zip Pegasus Mail (David Harris) 2.3.5 pmail235.zip Pegasus Mail, latest version 3.0.1 pmail301.zip Pegasus Mail, Windows version 2.3.5 winpm201.zip Rutgers/Clarkson Telnet/TN3270 1.0 rucutcp.zip SMC SuperDisk (SMC) 4.6 supr46.exe SMC SuperDisk (SMC) 6.5 supr65.zip Trumpet News Reader 1.06b trmp106b.zip WINPKT (from Crynwr) 11.2 winpkt.zip For Novell NetWare: NetWare patches and updates (in Released: reverse chronological order) DOS Client Files Update Kit #9 9 dosup9.exe 01/21/94 http://www.nyu.edu/its/security/handbook.html (50 of 55)8/31/2006 1:23:14 PM
    • NYU-NET Technical Handbook Windows Update Kit #9 9 winup9.exe 01/20/94 NetWare DOS shell files 3.32 net33x.exe 11/17/93 DOS utility FILER.EXE version 3.76 3.76 fil376.exe 11/10/93 IPX RIP/SAP filter update for MPR+ 2.1 ----- ripsap.exe 11/04/93 LANalyzer for Windows fixes ----- lzfwdi.exe 10/15/93 Updated Server LAN drvers ----- landr3.exe 10/06/93 Adds software compression to MPR+ 2.1 ----- pppcmp.exe 10/04/93 NDS Patches for NetWare 4.01 ----- dspat.exe 09/24/93 Corrected ROUTE.NLM for Netware 3.11/4 ----- srtfx.exe 09/15/93 Novell's Black Screen of Death fix ----- bsdup1.exe 9/13/93 PSERVER/RPRINTER updates ----- pserv5.exe 9/10/93 Updated NW 3.11 ISA disk driver ----- isa311.exe 8/xx/93 ATTOKLLC.NLM update 3.1 atok31.exe 7/29/93 TCPIP.NLM v2.02j and SNMP.NLM v2.08 ----- tcp162.exe 7/28/93 FLeX/IP update for NW 3.11 and NW 4.0 ----- flx146.exe 7/28/93 NW/NFS 1.2b update for NW 3.11 and NW 4.0 nfs153.exe 7/28/93 New style, modular server drivers ----- landr2.exe 7/20/93 NetWare DOS printing utilities 3.75 putil4.exe 7/19/93 Patch to update SIDEWIND.NLM 1.5 sidewd.exe 6/23/93 Novell NetWare Update Kit ----- upd311.exe 6/03/93 Updated versions of SPX-related NLMS ----- strtli.exe 5/24/93 Appletalk Support Package / NWfMAC 3.011 atsup.zip 4/23/93 PS/2 SCSI 2/4/93, ESDI 4/08/93 drivers ----- ps2311.ZIP 4/08/93 IPCONFIG.NLM 2.02 ip129.zip 3/25/93 FLeX/IP 1.2A patch 1.2A flx135.zip 3/24/93 Updated DOS utils for NW Name Service ----- secnns.exe 3/16/93 Appletalk NLM 3.06a 3.06a atk306.exe 3/16/93 Novell NetWare 3.11 patches D 311ptd.zip 2/22/93 ODI Driver Update Kit 5 odiup5.zip 1/31/93 NCOPY.EXE utility updated 3.58 ncy358.zip 1/25/93 NDIR.EXE utility update 3.45 ndr345.zip 1/25/93 USERDEF.EXE utility updated 3.55 udf355.zip 1/22/93 LOGIN.EXE updated 3.70 log370.zip 1/15/93 NW311 monitor.nlm updated 1.75 mon175.zip 11/25/92 NLM to clear not-logged-in attachment ----- nliclr.zip 9/21/92 http://www.nyu.edu/its/security/handbook.html (51 of 55)8/31/2006 1:23:14 PM
    • NYU-NET Technical Handbook IDE.DSK 6/11/92 server driver update ----- ide386.zip 9/10/92 NETBIOS.EXE updated 3.10 nb310.zip 8/28/92 Relevant to NetWare 4.x: DOS Client Files Update Kit #9 9 dosup9.exe 01/21/94 Windows Update Kit #9 9 winup9.exe 01/20/94 Updated Server LAN drvers ----- landr3.exe 10/06/93 NDS Patches for NetWare 4.01 ----- dspat.exe 09/24/93 Corrected ROUTE.NLM for Netware 3.11/4 ----- srtfx.exe 09/15/93 Novell's Black Screen of Death fix ----- bsdup1.exe 9/13/93 Novell NW4 DOS/Windows Requestor (VLM) 1.02 wkstndos.zip 8/30/93 Updated LOGIN.EXE 4.02 seclog.exe 8/02/93 NW4.0->NW4.01 ElectroText stylesheets ----- sty401.exe 7/26/93 Updated VNETWARE.386 for VLM clients 2.02 vnw202.exe 7/01/93 VLM components update 1.02 vlmup1.exe 6/15/92 Addendum 8, Revision 0, 2/19/93 AppleTalk on NYU-NET As of February 1993, all AppleTalk routers on the NYU-NET backbone must be configured to use AppleTalk network number range 10-20. (The former network range 3-3 was eliminated in late February 1993). Addendum 9, Revision 0, 6/23/93 Viruses and Novell NetWare Managers of Novell NetWare servers are often concerned about computer virus threats to their servers. A study of this issue was recently conducted by David Stang, Director of Research at the Virus Research Center, International Computer Security Association, and written up as a white paper and as an article "Virus Dangers to NetWare Lans" in the Jan/Feb 1993 "NetWare Connection", the bimonthly magazine of NetWare Users International. The white paper entitled "Viruses and NetWare" can be ordered from: NetWare Users International Virus White Paper P.O. Box 19007 Provo, UT 84605-9007 Enclose a $15 check or money order to cover production and handling costs. [Note: I tend to view this as reasonably reliable and reassuring information on this subject - with the caveat that the survey is based on study of a small number of, presumably, representative DOS computer viruses. It tends to indicate that strong anti-viral protection on DOS workstations, in combination with common-sense server protection measures, will provide good security against a server participating in the spread of viruses. Believing the conclusions of this article does not, however, relieve NYU-NET Novell system managers of the obligation to seriously consider deploying server-based anti-viral software. - Gary Chapman] The study seems to have focused on the DOS client/NetWare 3.11 server context. Here is a more-or- less verbatim summary of the findings as described in the article. q If a common file virus is memory-resident at the time of running IPX, NETX, and LOGIN, http://www.nyu.edu/its/security/handbook.html (52 of 55)8/31/2006 1:23:14 PM
    • NYU-NET Technical Handbook NetWare will permit the login, but many viruses will be disabled. q If IPX and NETX are resident when a memory-resident virus is first executed, login may be successful, or the workstation may hang, depending upon the virus. q If IPX or NETX are infected, login will proceed smoothly with the q NetWare is never attacked by a workstation boot virus, it never contributes to the spread of that virus, it does not disable the virus, and the virus is not disabled by the login process. q All of the file viruses we tested were NetWare compatible, permitting them to be run from server directories. q The only way that some viruses can get into files on the server (Frodo and Yankee Doddle, for instance) is by infecting a file on a local drive that is later copied to the server. Other viruses (Jerusalem, Cascade, Green Caterpillar) are able to infect files on the server. q The Read-Only attribute provides protection against viruses only when the user is also denied Modify rights in the directory in question. q The Execute-Only attribute stops all viruses cold. q A virus cannot infect any file in any directory in which the user does not have write permission. Addendum 10, Revision 0, 8/06/93 NetWare 4 on NYU-NET Novell recently released a major new version of NetWare - version 4.0 - and superseded almost immediately by version 4.01 in July 1993. Proper deployment of NetWare 4.x, both within a department and across NYU-NET as a whole, requires even more attention to planning and coordination than earlier versions of NetWare. The purpose of this addendum is to alert network managers of the most important issues involved in implementing NetWare 4.x at NYU. Important features of NetWare 4.x 1. NetWare Directory Services NetWare 4.x replaces the "bindery" (database of users, groups, queues, etc.) with the "NetWare Directory Services" (NDS). NDS is an enter- prise-wide, distributed, hierarchical database of NetWare entities, modeled upon X.500 principles. The database is viewed as a tree in which all servers, volumes, users, groups, queues, and so on have a place. "Bindery emulation" is an option, however, allowing older software which depends upon bindery access (through old APIs) to continue working. The overall NDS hierarchy must be centrally coordinated for purposes of consistency and addition/deletion of network objects. While it is possible to have more than one NDS tree on NYU-NET, this option requires careful consideration: an object in one tree is invisible to objects in another tree; a workstation oriented toward one tree cannot access objects such as servers in another tree. The primary application for multiple trees would be situations where a group intentionally wished to hide (to some degree) their network resources. A key notion of NDS is that a user/workstation no longer logs in to specific servers, but rather "logs into the network" of NetWare devices, and has access then to all resources (servers, print queues, etc.) for which he has privileges. 2. File compression NetWare 4.x improves various aspects of its file system; e.g. under the configuration control of the server administrator, the operating system will transparently compress and de- compress data files on disk. 3. Hierarchical storage There is new provision for file migration through a hierarchy of storage media: server hard disk -> read/write optical storage -> tape. 4. NetWare for Macintosh Each copy of NetWare 4.x comes with a 5-user version of NetWare for Macintosh. Aside from that, NetWare for Macintosh is available only in a 1000-user version. The first release of NetWare for Macintosh is not fully NDS compatible. 5. Windows-based management tools While DOS tools for server and NDS management are present, there are now Microsoft Windows-based management tools as well. Novell has reduced the number of DOS utilities, although at the price of adding numerous parameters to the remaining commands! Important Facts 1. Server installation / NDS coordination The ACF has installed the first NetWare 4.x server (NYUACF1) on NYU- NET, and thereby http://www.nyu.edu/its/security/handbook.html (53 of 55)8/31/2006 1:23:14 PM
    • NYU-NET Technical Handbook created the primary NYU directory tree (NEW_YORK_UNIVERSITY in name). Subsequent servers installed on NYU-NET will attempt to join this tree, but this will only be possible through coordination with an ACF staff member. During installation various configuration decisions must be made. In particular, ethernet frame type and network time synchronization parameters must be chosen in conformity with the first server, NYUACF1. The implementations of NDS in NetWare 4.0 and 4.01 are NOT compatible; only NetWare 4.01 (or later) may be installed on NYU-NET at this time. 2. New DOS/Windows workstation software NetWare 4.x uses a new generation of modular workstation drivers; ODI data link drivers are now required, and the NETX series shells are replaced by the new "VLM" (virtual loadable module) drivers. Potential deployers of NetWare 4.x are advised to gain experience with ODI and VLM drivers (which are NetWare 3.x compatible) prior to server installations. The biggest observable effect of the new drivers is that NetWare 4.x allocates DOS drives _up to_ LASTDRIVE, and not _after_ LASTDRIVE. An explicit config.sys LASTDRIVE setting is now required. A second notable features is that, upon initial server attachment, the server drive is "root mapped" to the SYS:LOGIN directory: one no longer sees F:LOGIN, but simply F: instead. Happily, ODIPKT works fine with the new workstation software; so packet-driver based software (e.g. NCSA Telnet, PC Gopher, NUPop) continues to work. 3. CD-ROM distribution of software and manuals NetWare 4.x software and documentation are distributed on CD-ROM; floppy disks and paper manuals are added-cost options. The ACF has purchased one paper copy of the manuals, which may be inspected by NYU staff members. Third-party books are starting to appear in quantity. 4. Planning of NDS tree critical Each unit or department installing NetWare 4.x needs to carefully plan the organization of their part of the NDS tree, in order to organize things in a good way for their use and to minimize the likelihood of making frequent or major changes in the structure of the NYU- wide NDS. NDS is a distributed database with portions replicated on several servers on campus; unnecessary changes to the database (involving wholesale re-synchronization of the database) should be avoided. Novell has included substantial documentation on NDS concepts and planning which should be examined carefully prior to NetWare 4.x installation. 5. Potential incompatibilities NetWare 4.x is quite compatible with software designed for NetWare 3.x. There are, however, many examples of DOS-based tools or server- based NLMs which require update to either work compatibly with the new operating system or take full advantage of it. Less predictably, however, it is possible for local configuration methods or tools to break under NetWare 4.x. The ACF finds, for example, various aspects of its login and logout process to be "broken". Work will be required to restore similar functionality, and it's not clear if a single set of scripts/programs can work on both NetWare 3.x and NetWare 4.x servers (during a period of transition). Addendum 11, Revision 0, 9/27/93 Policy Statement on Providing Internet Access, September 2, 1993 [The following policy statement was adopted by the New York University Data Communications Task Force at its September 1993 meeting. It is intended to provide guidelines for NYU departments and schools which receive requests from outside organizations requesting computer accounts which thereby provide Internet access. The general policy is that outside groups, including non-profit ones, need to obtain Internet access through a commercial service provider - and that it is no longer appropriate for the university to provide this access unless there is a strong collaborative and programmatic affiliation between the requesting (non-profit) organization and the university.] Policy Statement: In the past, computing organizations at New York University have provided accounts on our machines to specific not-for-profit institu- tions having a programmatic affiliation with the University that depends upon access to NYU computing and network services. We will continue to consider such requests and evaluate them on their merits. Under the terms of our agreement with CREN, such organizations may have access to Bitnet only if they become affiliate members of CREN. There is a yearly charge for such affiliation. http://www.nyu.edu/its/security/handbook.html (54 of 55)8/31/2006 1:23:14 PM
    • NYU-NET Technical Handbook Historically, universities have often offered the only convenient way to obtain Bitnet and Internet connectivity. There are now an increasing number of commercial IP service providers offering a variety of connectivity and service options. Performance Systems International and Advanced Networks and Services are examples of firms operating in this new industry. We recommend that not-for- profit institutions having no programmatic affiliation with NYU contact these IP service providers to obtain the connectivity that they require. Selected Commercial Network Providers PSI Performance Systems International, Inc. (800) 82PSI82 (703) 620-6651 E-mail: info@psi.com NYSERnet New York State Education and Research Network (NYSERnet) Jim Luckett (315) 453-2912 E-mail: info@nysernet.org ANS Advanced Networking and Services Joel Maloff (313) 663-7610 E-mail: info@ans.net. For further help and information, contact ITS Technology Security Services at security@nyu.edu. Questions or comments about this site? Send e-mail to: its.website@nyu.edu. http://www.nyu.edu/its/security/handbook.html (55 of 55)8/31/2006 1:23:14 PM