Peer to Peer TCP/IP?

Published December, 1997
This paper provides technical information related to deployment and management of Microsoft® TCP/IP on computers running Microsoft Windows® 95. This paper was prepared for network administrators working in the corporate environment. However, the first section provides instructions for users with less technical backgrounds who may be responsible for setting up a small TCP/IP-based network.
Introduction
This paper supplements information provided in Microsoft Windows 95 Resource Kit about Microsoft TCP/IP, which uses the same basic protocol stack provided with Windows NT™ 3.5 and later and TCP/IP-32 for Windows for Workgroups.
Microsoft TCP/IP is compatible with TCP/IP implementations on LAN Manager and other networks that implement the standard TCP/IP protocol suite defined in Requests for Comments (RFCs) published by the Internet Engineering Task Force (IETF).
 
For more information about      See

Installing, configuring, and troubleshooting TCP/IP      Chapter 12, “Technical Networking Discussion,” Microsoft Windows 95 Resource Kit, Microsoft Press, 1995. ISBN 1-55615-678-2.
Configuring TCP/IP to connect to Internet access providers      Chapter 30, “Internet Access,” Microsoft Windows 95 Resource Kit.
Using the command-line TCP/IP utilities provided with Microsoft TCP/IP      Appendix A, “Command-Line Commands Summary,” Microsoft Windows 95 Resource Kit (page 1136, U.S. edition).
Microsoft TCP/IP on Windows NT networks, including details about DHCP, WINS, and Internet servers      Windows NT Networking Guide (volume 2 in Microsoft Windows NT 3.5 Resource Kit), Microsoft Press, 1995. ISBN 1-55615-656-1.
Technical details about the implementation of Microsoft TCP/IP      Microsoft Windows NT 3.5 and 3.51 TCP/IP Protocol Stack and Services: Implementation Details, a Microsoft Windows NT white paper (part no. 098-62170).
Technical details about browsing and name resolution on networks using Microsoft TCP/IP      Browsing and Windows 95 Networking, a Microsoft Windows 95 white paper (part no. 098-61903).
Product information from Microsoft support engineers, plus software and documentation corrections and additions      Microsoft KnowledgeBase on http://www.microsoft.com
Details from Microsoft Windows 95 Resource Kit can also be searched and read online by using the WIN95RK.HLP file, available in the Admin\Reskit\Helpfile directory on the Windows 95 compact disc or with the Windows 95 Resource Kit utilities.
Setting Up a New Local Area Network with TCP/IP
The topics in this section are written for the administrator or project lead responsible for planning and creating a new small local area network (LAN) using Windows 95 and Microsoft TCP/IP.
Typically a network is set up to use TCP/IP when you need to create a routed environment that connects subnets or separate LANs. Therefore, in many cases, a better choice for a small single local network is the IPX/SPX-compatible protocol or NetBEUI, because these protocols are easier to configure and manage in a small LAN.
However, if you are configuring a small LAN that requires direct or nearly direct access to the Internet or to another LAN that uses TCP/IP, you might want to configure the network to use TCP/IP, even if your network involves only 2 – 10 computers.
Note   For networks that will grow to 20 or more computers, you should plan to include at least one domain controller running Windows NT Server, which can also be configured to act as a server for Dynamic Host Configuration Protocol (DHCP) and Windows Internet Name Service (WINS) services, and which can also provide robust support for remote access services (RAS) on TCP/IP networks.
Such a configuration takes advantage of the advanced features of Microsoft TCP/IP while also creating a LAN that can take advantage of the advanced administrative and security features of both Windows 95 and Windows NT.
This section describes how to set up a small network that uses Microsoft TCP/IP but does not use Windows NT Server to provide automatic configuration and name resolution services.
The information presented here focuses solely on issues related to installing and configuring Windows 95 for IP networks. For information about hardware-related issues such as installation of wiring and network adapters, contact a qualified systems integrator.
 
For more information about      See

Issues and recommendations for peer-to-peer networks using Client for Microsoft Networks      Chapter 8, “Windows 95 on Microsoft Networks,” Microsoft Windows 95 Resource Kit (page 267, U.S. edition)
Installing and configuring peer resource sharing services      Chapter 11, “Logon, Browsing, and Resource Sharing,” in Microsoft Windows 95 Resource Kit (page 398, U.S. edition)
Installing DHCP, WINS, RAS, and Internet servers using Windows NT Server      Windows NT Networking Guide (v. 2 in Microsoft Windows NT 3.5 Resource Kit)
Configuring TCP/IP for Computers on a Small LAN
The first issue in creating a small LAN is selecting the network client. To create a network that uses Microsoft TCP/IP, you must select the 32-bit, protected-mode Client for Microsoft Networks. This client is installed by default with Windows 95 when upgrading Windows for Workgroups or when the computer has a network adapter but no other networking client is currently installed on the computer.
The next issue for creating a TCP/IP-based LAN is to define the IP addresses and other TCP/IP configuration settings to be used for computers on the local network.
Each network that connects directly to the public Internet must obtain an official network ID from the InterNIC to guarantee unique IP network IDs. After receiving a network ID, the local network administrator must assign unique host IDs for computers within the local network. Although private networks not connected to the Internet can choose to use their own network identifiers, obtaining a valid network ID from InterNIC allows a private network to connect to the Internet in the future without reassigning addresses.
Note   You can use the IP addresses provided automatically by your Internet provider for connections to the Internet, and then use privately-defined IP addresses for the local network. However, this is not recommended. Such a private network configuration can cause name-resolution and packet routing problems for simultaneous dial-up and LAN connections. Most importantly, if you later need to use valid network IDs on the local network, the process of converting the private IP network addresses can be a large and expensive administrative task.
To obtain an official network ID
·      Contact the InterNIC by sending electronic mail to info@internic.net.
      Internet registration requests can be sent to hostmaster@internic.net. You can also use File Transfer Protocol (FTP) to connect to is.internic.net, then log on as anonymous and change to the /INFOSOURCE/FAQ directory.
      In the U.S., you can call (800) 444-4345. For Canada and overseas, call (619) 455-4600.
 
After you obtain an official network ID, the basic tasks for creating a small Windows 95-based TCP/IP network include the following:
·      Assign unique IP configuration settings per workstation.
·      Configure HOSTS and LMHOSTS files to manage name resolution.
·      Install Windows 95 on all computers with correct configuration of network client, protocols, and services.
 
These tasks are described in the following sections.
Managing IP Addresses and Name Resolution on a Small LAN
The network administrator has two major tasks related to establishing and maintaining network communications that use TCP/IP:
·      Assigning and maintaining IP address assignments and other configuration settings for each network connection.
·      Managing the methods used to ensure that each workstation can find and communicate with all others on the network.
 
Overview of IP Addresses and Subnet Masks
Every computer on a TCP/IP network is identified by a unique 32-bit IP address, which also specifies routing information in an internetwork. An IP address looks like this:
 
102.54.94.97

 
This is referred to as dotted decimal notation, with each eight bits of an IP address (called an octet) separated from the next eight bits by a period. An IP address is a single value that contains two pieces of information:
·      The network ID, which is the portion of the IP address that identifies a group of computers and other devices that are all located on the same logical network.
·      The host ID, which identifies a particular computer within a particular network ID. A host, or node, is any device that is attached to the network and uses TCP/IP.
 
Each host on the network uses the network ID and host ID to determine which packets it should receive or ignore, and to determine the scope of its transmissions (only hosts with the same network ID accept each other’s IP-level broadcasts).
The Internet community uses address classes to differentiate networks of various sizes. The network class can be determined from the first octet of its IP address. The following table summarizes the relationship between the first octet of an IP address and its network ID and host ID. The table also identifies the total number of network IDs and host IDs for each address class that participates in the Internet addressing scheme. This sample uses w.x.y.z to designate the four octets of the IP address.
IP Address Classes
 
Class      w values1,2      Network ID      Host ID      Available networks      Available hosts per net


A      1–126      w      x.y.z      126      16,777,214
B      128–191      w.x      y.z      16,384      65,534
C      192–223      w.x.y      z      2,097,151      254


1   Inclusive range for the first octet in the IP address.2   The address 127 is reserved for loopback testing and interprocess communication on the local computer; it is not a valid network address. Addresses 224 and above are reserved for special protocols (IGMP multicasting and others), and cannot be used as host addresses.                              
Because the sender’s IP address is included in every outgoing IP packet, the receiving computer can derive the originating network ID and host ID from the IP address field. This is done by using subnet masks, which are 32-bit values that allow the recipient of IP packets to distinguish the network ID and host ID portions of the IP address.
The value of a subnet mask can also be represented in dotted decimal notation. Subnet masks are determined by assigning ones to bits that belong to the network ID and zeroes to bits that belong to the host ID. When the bits are in place, the 32-bit value is converted to dotted decimal notation, as shown in the following table.
Default Subnet Masks for Standard IP Address Classes
 
Address class      Bits for subnet mask      Subnet mask

Class-A      11111111 00000000 00000000 00000000      255.0.0.0
Class-B      11111111 11111111 00000000 00000000      255.255.0.0
Class-C      11111111 11111111 11111111 00000000      255.255.255.0
The result allows TCP/IP to determine the host ID and network ID of the local computer. For example, if the IP address is 102.54.94.97 and the subnet mask is 255.255.0.0, then the network ID is 102.54 and the host ID is 94.97.
Subnet masks are also used to further segment an assigned network ID among several local networks. For example, a network using the Class-B network address 144.100 is one of over 16,000 Class-B addresses capable of serving more than 65,000 nodes each. But if this corporate network includes 12 international LANs with 75 to 100 nodes each, it is better to use subnetting to make effective use of 144.100 than to apply for 11 more network IDs. In this case, the third octet of the IP address can be used as a subnet ID, using the subnet mask 255.255.255.0, which splits this Class-B address into 254 subnets: 144.100.1 through 144.100.254, each of which can have 254 nodes. Any of these network addresses could be assigned to the 12 international LANs in this example. Within each LAN, each computer is assigned a unique host ID, and they all have the subnet mask 255.255.255.0.
Note   For all systems on the local network, the subnet mask must be the same for that network ID.
Host IDs 0 and 255 should not be assigned to a computer; they are used as broadcast addresses that are typically recognized by all computers.
In addition to IP addresses and subnet masks, for a TCP/IP client to access computers on other subnetworks, the computer must be configured to use one or more gateways. A gateway (or IP router) is a computer connected to the local network plus other networks and that has knowledge of the network IDs for other networks in the internetwork and how to reach them.
A gateway can be provided by dedicated router hardware such as routers provided by Cisco, Proteon, and other hardware vendors. A dedicated router uses physical connections to each subnet on the network. It can maintain route tables automatically and might also provide basic support for creating security firewalls. Most dedicated routers can provide security by filtering packets from certain subnets, and might be able to provide simple protocol encapsulation for security, as described in the section “Maintaining Security for Internet Connections” later in this paper.
A gateway can also be provided by a server such as Windows NT Server or a UNIX® host running routing software. Such servers perform standard routing duties, but might not necessarily maintain routing tables automatically. Servers that act as gateways can also be configured with sophisticated firewall software to filter packets and to provide proxy access to a network and protocol encapsulation, as described in the section on security later in this paper.
If computers on your network must communicate with computers on another network (including any direct connection to the public Internet), then at least one gateway called the default gateway needs to be configured. Each computer needs to have the address of the default gateway in order to connect to any other network. A Windows 95 computer cannot be configured to act as a gateway.
However, for a small TCP/IP network, gateways will be an issue only if you are connecting to an Internet provider or to another TCP/IP network.
Managing IP Addresses on a Small LAN
If your network does not use Windows NT Server to provide automatic configuration using DHCP, you will have to assign, configure, and track all IP configuration settings manually for each computer.
You might set up a spreadsheet to define entries for each user, specifying columns that contain the following kinds of information:
·      IP address
·      Subnet mask
·      Host name
·      Fully qualified domain name (FQDN)
·      NetBIOS computer name
·      MAC address of the network adapter
·      User name
·      Location of computer
 
This spreadsheet can be used as a reference for manually assigning configuration information when installing Windows 95 and when troubleshooting networking and communications problems.
Managing Name Resolution on a Small LAN
For computers on the local network, Client for Microsoft Networks uses network broadcasts to NetBIOS computer names to find other computers. If you use an Internet access provider as the only method for communicating with computers outside of your network, that service provider offers the name-resolution services necessary for finding computers on the Internet.
However, if you have connections to other networks through a means other than an Internet service provider, you will have to provide a method for finding computers on the other networks. For a small network that does not have Windows NT Server available, you must rely on the HOSTS and LMHOSTS files to provide mappings for computer names to IP addresses, so that users can communicate with computers on other networks using “friendly names” rather than IP addresses.
The HOSTS file is used as a local equivalent to the Domain Name System (DNS) used on the Internet. This file contains IP address-to-host name mappings for the local network and for computers that you want to communicate with on remote networks. This ASCII text file looks something like the following:
 
127.0.0.1     localhost
102.54.94.97  rhino.acme.com          # source server
38.25.63.10   x.acme.com              # x client host

 
The LMHOSTS file is used as a local equivalent to WINS servers. This file contains IP address-to-NetBIOS computer name mappings for computers on other subnets or networks across routers. This ASCII text file looks something like the following:
 
102.54.94.98   localsrv
102.54.94.97   trey    
102.54.94.102  printsvr
102.54.94.123  popular  

 
Each of these files is also known as a host table. Sample versions of LMHOSTS and HOSTS files (named LMHOSTS.SAM and HOSTS.SAM) are added to the Windows folder when you install Microsoft TCP/IP.
You can create correct HOSTS or LMHOSTS files for your network by using a text editor to change the sample files provided with Windows 95. The following lists compare the basic differences between the two name-resolution files.
 
HOSTS file      LMHOSTS file

Resolves host names of local and remote TCP/IP host computers.      Resolves NetBIOS computer names of remote NetBIOS-based computers.
Used to resolve names with TCP/IP utility commands such as ping or ftp.      Used to resolve names in Windows Explorer and with Microsoft networking commands such as net use or net view.
Each entry can consist of one IP address with multiple names per host computer.      Each entry consists of one IP address followed by one NetBIOS name for each host computer.
Host names are case-sensitive in that case is preserved but not generally required.      Names entered in LMHOSTS are interpreted as  uppercase unless the name is enclosed in quotation marks in the file. NetBIOS names are not case sensitive when used in Windows Explorer or with net commands, and case is not preserved.
The file is parsed sequentially.      Entries can be tagged for preloading in the computer’s name cache, or the file can be parsed sequentially to find a computer name.
Tips for Host Tables
·      The host name is not the same as the NetBIOS computer name used for Microsoft networking. Host names are used by TCP/IP utilities and are relevant for UNIX environments and the public Internet. NetBIOS computer names are used in UNC designations with net commands and in the Windows 95 shell.
·      Check the HOSTS.SAM and LMHOSTS.SAM sample files in the Windows folder for information about how to use these files and about the special flags that can be used in LMHOSTS. In particular, the #PRE flag can be used to preload entries in a computer’s name cache, and the #DOM flag can be used to associate entries with particular domains.
·      Windows 95 uses the HOSTS file for name resolution if it is present on the computer and if the Use DNS option is selected in the TCP/IP properties.
·      Windows 95 uses the LMHOSTS file for name resolution if it is present on the computer and if a value for LmhostFile is specified in the Registry. (This is the default configuration when TCP/IP is installed.)
 
The other more complex (and more efficient) name resolution methods for TCP/IP networks include the following:
·      Windows Internet Name Service (WINS), which is a method used on Windows NT networks to map NetBIOS names to IP addresses for computers running Windows 3.x, Windows 95, or Windows NT.
      This method requires one or more Windows NT Server computers configured as WINS servers on the network. In addition, each workstation must be configured to use WINS for name resolution.
·      Domain Name System (DNS), which is the method used on the Internet to map friendly host names to IP addresses. DNS servers query other DNS servers to resolve portions of the address that they cannot map, until the entire IP address has been built.
      This method requires either that your Internet service provider assign you the IP addresses to specify for the DNS server to be used or you need an official DNS server on the network. In addition, each workstation must be configured to use DNS for name resolution.
 
 
For more information about      See

Creating and managing name resolution files      Appendix G, “HOSTS and LMHOSTS Files for Windows 95,” Microsoft Windows 95 Resource Kit
Using DNS for Name Resolution in Windows 95      Chapter 12, “Technical Networking Discussion,” Microsoft Windows 95 Resource Kit (page 440, U.S. edition)
Using WINS for Name Resolution in Windows 95      Chapter 12, “Technical Networking Discussion,” Microsoft Windows 95 Resource Kit (page 437, U.S. edition)
How names are resolved, depending on the system configuration      The illustrations on page 4 in this paper
Installing Windows 95 with Network Services for a Small LAN
You can create custom setup scripts to automatically install Windows 95 on each computer with the appropriate network services for your new LAN. A custom setup script is a batch file in the format of MSBATCH.INF, with specific settings for a particular user and computer. You should use setup scripts to install Windows 95 whenever you have five or more computers to configure, rather than running Windows 95 Setup manually for each computer.
The basic steps for automatic installation include:
·      Use BATCH.EXE to create custom setup scripts for installing Windows 95 with predefined TCP/IP parameters and network services to be installed.
·      Run Windows 95 Setup at each computer, using appropriate custom setup script as a part of the setup command line.
·      If required for communicating with other networks, copy custom HOSTS and LMHOSTS files to each computer.
 
 
For more information about      See

Customizing and automating Windows 95 Setup, including using BATCH.EXE and running Setup with a setup script      Chapter 5, “Custom, Automated, and Push Installations,” Microsoft Windows 95 Resource Kit.
MSBATCH.INF reference      Appendix D, “MSBATCH.INF,” Microsoft Windows 95 Resource Kit
Using Setup Scripts to Configure TCP/IP on a Small LAN
The important issue for installing Windows 95 with networking on your LAN is to ensure that each workstation has the correct settings for TCP/IP.
To make this task easy for yourself as the administrator, you can create a custom setup script for each user to automatically define the correct settings for all networking components.
The instructions here assume that a network might not already be in place to support installing Windows 95 from network source files. In this case, you can still use setup scripts to install Windows 95 from a compact disc or from floppy disks.
To create custom setup scripts for installing Windows 95 with TCP/IP
 1.      Use BATCH.EXE to create a setup script with custom settings.
      The Batch Setup utility is on the Windows 95 compact disc and is also part of the Windows 95 Resource Kit utilities.
 2.      In the custom setup script, specify the following:
·      Custom settings for user name, workgroup name, computer name, and so on
·      Client for Microsoft Networks
·      Microsoft TCP/IP protocol
·      Correct settings for TCP/IP
·      File and Printer Sharing services, with share-level security
·      Other components, depending on what you want to be available on each workstation
 
 3.      Save the custom script, perhaps using the related user’s name as part of the filename, so you can easily determine which script defines which user’s settings for installing Windows 95.
 4.      Modify this first script with the TCP/IP settings and other unique settings for the next user, and save it under another filename. Then repeat this process to create each user’s setup script.
 
After all scripts are created, you can use each script to install Windows 95 on the related workstations.
To run Windows 95 Setup using a setup script
 1.      Start the computer, and start Windows.
 2.      Copy the setup script to the root directory on the C drive.
 3.      Switch to the drive that contains the Windows 95 source files.
 4.      In File Manager, choose the Run command, and type:
      a:setup c:\msbatch.inf
      Where msbatch.inf is the filename of the setup script you created and copied to drive C. If the Windows 95 source files are on compact disc rather than a floppy disk in drive A, use the drive letter for the CD-ROM drive.
 
The following shows an example of a custom setup script in MSBATCH.INF format that defines all the required settings for installing Windows 95 with TCP/IP:
 
[Setup]
Express=1               ; does not allow user input
InstallType=1           ; Typical Setup
EBD=1                   ; create startup disk
ProductID=999999999     ; type the correct product ID number

[NameAndOrg]
Name="Jane Doe"         ; user on this computer
Org="Acme Company Name"
Display=0               ; User Information dialog box is not displayed

[Network]
Display=0               ; Network Options do not appear in Setup
ComputerName=JaneD      ; Unique name on the network
Workgroup=acme_Win95
Description="Jane Doe’s PC"
Clients=vredir          ; Client for Microsoft Networks
Security=share          ; Share-level security
services=vserver        ; File and Printer Sharing services
protocols=mstcp         ; Microsoft TCP/IP

[MSTCP]                 ; settings described following this example
DHCP=0
DNS=1
Hostname=janed          ; unique host name on this network
IPAddress=156.56.61.4   ; unique IP addresses
IPMask=255.255.255.0
WINS=0

 
In the [MSTCP] section of a setup script, the following settings should be defined for Microsoft TCP/IP.
 
Required setting in [MSTCP]      Description

DHCP=0      Specifies that TCP/IP is not configured to use DHCP for dynamic TCP/IP configuration.
DNS=1      Enables the ability to use DNS for NetBIOS name resolution.
Hostname=name      Sets the DNS host name for this computer (usually the same value as ComputerName, but it can be different).
IPAddress=###.###.###.###      Sets the computer’s unique IP address.
IPMask=###.###.###.###      Sets the IP subnet mask for this network.
WINS=0      Disables WINS for NetBIOS computer name resolution.
The following settings for the [MSTCP] section in MSBATCH.INF are optional, depending on whether you need to define gateways or DNS servers.
 
Optional setting in [MSTCP]      Description

DNSServers=comma-separated list of DNS server names      Defines the list of the DNS servers to use in the order to try them, when DNS servers are used to resolve host names.
Domain=name      Sets the DNS domain that this computer is in. If you don’t have an official domain name assigned by InterNIC, this can be the domain name assigned by your Internet provider.
DomainOrder=comma-separated list of DNS domains      Sets a list of DNS domains for host name resolution in the order to try them. Only required if you use DNS servers to resolve host names.
Gateways=comma-separated list of IP addresses      Lists the IP gateways (sometimes called IP routers) in the order they are to be used if the first gateway fails. This setting is required only if your network uses gateways to connect to other networks. For more information about gateways, see “Editing the Routing Table” on page 4 in this paper.
LMHOSTPath=directory path      Sets the path and filename of the LMHOST file. You need to add this setting only if LMHOSTS will be located somewhere other than the Windows folder. (This setting sets the value of LmhostFile in the Registry, as described on page 4 in this paper.)
The following settings should not have values defined in [MSTCP] if you have a small LAN that does not use DHCP, WINS, or NetBIOS scopes:
·      PrimaryWINS and SecondaryWINS, which set the IP addresses for WINS name server.
·      ScopeID, which sets the NetBIOS scope ID. The option is not likely to be used in a small TCP/IP network, and should be left blank in a setup script and in the TCP/IP properties in the Network option in Control Panel.
 
Selecting Optional Network Components
You can specify all the optional components and services that you want to install as settings in the custom setup script. Typically, for a peer network, you will want to install at least File and Printer Sharing services and Net Watcher on each computer.
The following table shows the components that must be installed and configured on computers to support other components, assuming that Client for Microsoft Networks is used as the network client for a small LAN or peer-based network.
Required Components for Network Services on a Client Computer
 
Component      File and Printer Sharing      Dial-Up Networking

File and Printer Sharing      X      Optional
Password List Editor      –       –
System Monitor      –       –
Net Watcher      X      –
Windows 95 Briefcase       X (host)      –
Microsoft Exchange components1      –       –
Remote mail1      –       X
Dial-Up Networking client1      Optional      X
SLIP protocol, Scripter      –       X
Internet mail and dial-up server from Microsoft Plus!1      For dial-up server      X


1   Dial-Up Networking, Microsoft Fax, The Microsoft Network, remote mail, and Internet mail require a modem.
Using Peer Servers on a Small TCP/IP LAN
The Windows 95 File and Printer Sharing services allow users to share information with other Windows-based and MS-DOS®-based network computers. Shared resources can include files, printers, CD-ROM drives, and fax/modem peripherals.
You will want to install File and Printer Sharing services on each computer that contains resources that are to be shared among other users on the network. This service can be installed by using custom setup scripts, or by using the Network option in Control Panel. Resource sharing capabilities can be enabled or disabled locally using Control Panel.
After File and Printer Sharing services are installed on a computer, each user can configure which directories, files, and peripheral devices such as printers or CD-ROM drives will be shared on the network. With share-level security, the kind of access other users have to shared resources can be restricted to read-only, or can be password-protected.
Planning for File and Printer Sharing Services
 
Requirements      Limitations

·   Can only be installed on computers that use a 32-bit, protected-mode network client·   File and Printer Sharing service must be installed on the client computer if an administrator wants to use Net Watcher to view or administer the file system remotely      ·   Access to shared resources can only be restricted with share-level security unless a Windows NT computer is installed on the network
Managing Shared Printers on a Small LAN
You can install one or more printers attached to computers running Windows 95, and then share the printers as resources that other users can connect to on the network. Even for small networks, you will want to have at least two printers available on the network, so that users have a printing alternative if one printer is busy or offline.
For information about how to define printer settings as part of Windows 95 installation when using setup scripts, see Appendix D, “MSBATCH.INF Parameters,” in Microsoft Windows 95 Resource Kit (page 1199, U.S. edition).
UNIX-based print hosts can be installed on an IP network. Such print hosts are either connected to a UNIX computer or are connected directly to the network using a built-in network adapter or through a serial/parallel Ethernet print server. Your systems integrator can provide information about such print hosts.
If your site already has UNIX print hosts installed, you need to obtain an LPR client for Windows 95 computers. Several vendors provide Windows Sockets-compatible LPR clients. Again, your systems integrator can provide information about LPR clients.
Windows 95 does not include either an LPR client or an LPD server service, and does not support the lpr or lpq utilities provided with Windows NT. (Windows NT, however, provides support to allow UNIX clients to print to Windows NT printers and to allow Windows networking clients to print to UNIX print hosts.)
 
For more information about      See

Installing and managing network printers      Chapter 23, “Printing and Fonts,” in Microsoft Windows 95 Resource Kit (page 758, U.S. edition)
Setting Up Dial-Up Services for a Small LAN
If you want to provide dial-up services on a small IP LAN, you can choose these options:
·      Configure a Windows 95 computer using the Dial-Up Server provided with Microsoft Plus! or using Windows 95-compatible remote-access software from another vendor that supports TCP/IP PPP dial-in connections.
      The Dial-Up Server supports only a single dial-in connection.
·      Configure a Windows NT Server computer to provide remote access services (RAS) for dial-up connections.
      This option can support TCP/IP PPP connections, and can also be configured to provide Internet dial-up server support for multiple dial-in clients.
 
The following sections present issues related to configuration and security for Internet connections for any network size.
 
For more information about      See

Installing and configuring dial-up clients using Microsoft Dial-Up Networking      Chapter 28, “Dial-Up Networking and Mobile Computing,” Microsoft Windows 95 Resource Kit (page 892, U.S. edition)
Installing Windows NT RAS and related Internet server support      Windows NT Networking Guide (v. 2 in Microsoft Windows NT 3.5 Resource Kit)
Setting Up Internet Connections for a TCP/IP LAN
For a single computer that will use a dial-up connection over a modem to an Internet service provider, the Internet Jumpstart Kit available with Microsoft Plus! and other download sources provides the most straightforward solution to establishing connections and setting up to browse the Internet.
The topics in this section are written for network administrators responsible for planning services and ensuring security on any size network that will include connections to the public Internet.
To begin, you need a physical connection to the Internet. Depending on your needs, the connection might be a 14,400 bits per second (bps) modem and dial-in PPP account, or a dedicated high-volume line supplied by an Internet service provider (for an Internet server or providing an Internet gateway to a LAN). If you set up a dedicated computer to act as a router or gateway server to the Internet, it should use a high-speed connection such as T1 or T3 lines using a special network adapter, instead of a slower telephone line.
 
For more information about      See

Using Dial-up Networking on the Internet      Chapter 30, “Internet Access,” in Microsoft Windows 95 Resource Kit
Security for Internet connections      “Maintaining Security for Internet Connections,” page 4 in this paper
Freeware and shareware Windows Sockets applications      ftp://129.79.26.27/pub/pc/win3/winsock/
Planning Internet Services for a Small LAN
A computer running Windows 95 can be configured for the following kinds of Internet connections:
·      As a dial-in client to the Internet, using any of these software options:
·      Windows 95 Dial-Up Networking, with a modem connection to an Internet access provider
·      The Microsoft Network
·      Dial-in software from another software vendor
 
·      As a server for information exchange on the Internet, when File and Printer Sharing services are installed and the computer is configured for dial-up access using the Dial-Up Server provided with Microsoft Plus! or Windows 95-compatible software from another vendor.
 
You must install and configure Dial-Up Networking client software on Windows 95 computers that will access the Internet unless you purchase leased-line services from your Internet service provider to create Internet servers. If you are creating connections only for Internet clients, you only need a modem and a dial-in PPP or SLIP connection for your Windows 95 computer.
If you create an Internet server, have a high volume of traffic, or multiple subnets, you will most likely use a leased line and a dedicated router. (To support high volumes of traffic and provide greater security, you should use Windows NT version 3.5 or higher, rather than Windows 95.)
As the name implies, the Internet is a group of interconnected networks. When you create an Internet server, you are adding another network to the network of networks. The network you add to the Internet can be one computer, a small workgroup, or your entire corporation’s local area network, depending on the software and server support on your network.
The Internet is an IP network, so of course a Windows 95 computer connecting to the Internet must use TCP/IP to participate.
Windows 95 cannot act as a TCP/IP router. If you have a larger network with more than one subnet, you probably need the performance and security provided by a dedicated router (and likely have routers in your network already).
Direct access to the Internet using a dedicated router for clients on a large LAN
Remote clients can dial into a remote-access server that has additional communications equipment to provide an Internet gateway. If you want to allow more than one simultaneous dial-in connection, this scenario requires Windows NT Server RAS or other advanced dial-up software.
Maintaining Security for Internet Connections
Security becomes an important issue when you are connected to the Internet. This section describes only basic Internet service configurations. Many options exist to protect a single computer or the entire LAN from external Internet clients that are not mentioned in this section.
Although you might want some users on your corporate network to use the Internet and Dial-Up Networking, and you might want users from the Internet to access certain information, you probably do not want dial-in and Internet users to have full access to the corporate network.
You can use physical isolation, protocol isolation, dedicated routers from other vendors, and other router security in your network to provide security, although the topology you choose also affects the services that can be provided to LAN users.
Caution   If a computer is connected directly to the Internet without a firewall, you should turn off the TCP/IP binding for File and Printer Sharing on that computer to avoid possible security breaches.
If you allow Internet users to connect to a computer on your internal network while using only password protection on files, your security is always endangered by possible password cracking or by user carelessness or ignorance.
The following figure summarizes the different network topology scenarios you can implement and how each scenario influences security and service for LAN users. Details about each scenario are provided in the following sections.
Network scenarios and security levels
Windows 95 can act as a robust network client and Internet client in each of these scenarios
Windows 95 cannot act as a router in any of these scenarios
Windows NT Server can act as a robust server or router in all of these scenarios, including robust support for remote dial-in connections
Physical Isolation for Internet Security
A computer physically isolated from your LAN is the safest and easiest to plan and configure for Internet access. Only the Internet server can see and be seen by the Internet. Even the most clever hacker cannot browse your corporate network without physical access. Of course, the Internet server itself is still open to attack.
A limitation to this configuration is that you cannot share files between the corporate network and the Internet. For example, if you have a single computer connected to the Internet, it can act as an Internet server that provides information to share with Internet users, and (optionally) act as an Internet client that allows the users in your organization access to the Internet. For this computer to serve as an Internet client, however, it must be physically accessible to employees because it is not on the corporate network. You have to use floppy disks to share information between the two systems.
Physical isolation security model
Windows 95 can act as kiosk in this scenario
To give users in your organization easier access to the Internet, you can set up a small, separate network consisting of the Internet server, additional Internet servers, and individual workstations, or kiosks. The kiosks can be located in conference rooms, hallways, libraries, or in special offices scattered throughout the company. Individuals who need to make heavy use of the Internet can have kiosks in their offices. The kiosks can be used to retrieve information from your Internet server, to place new information on the server, and to gather information from the Internet at large. This type of scenario, however, will probably require additional cable installation, since it is its own separate network.
Protocol Isolation for Internet Security
If you want both Internet and LAN computers to see your Internet server, you can use protocol isolation security. In this model, the Internet server has two network adapters. The network adapter connected to the Internet is bound to TCP/IP. The network adapter connected to the LAN runs NetBEUI or an IPX/SPX-compatible protocol, but not TCP/IP.
Protocol isolation security model
Windows 95 can act as server for a very small LAN in this scenario
The key to this model is that the Internet requires use of the IP protocol. If a different protocol, such as IPX, connects your Internet server to the corporate network, then the corporate network cannot be accessed by Internet users because they aren’t using the correct protocol. Likewise, corporate network users cannot directly access the Internet because they are not using TCP/IP.
The protocol isolation security model is useful for users who spend most of their time making information available to Internet users and who want to copy files directly from the corporate network to the Internet server. Or some users might need to frequently download information that is left in a “drop box” by Internet users.
The resources on this server are accessible from either direction, but data cannot be passed through. In this way, there is a virtual barrier to passing packets through the server. Such barriers are often referred to as firewalls.
The advantage of the protocol isolation security model is that your users can share information with Internet users while using their own workstations on the corporate network without exposing the corporate network to unauthorized use. One disadvantage of using this type of model is that your users cannot directly access the Internet. The users cannot search for or retrieve Internet resources, other than those resources placed on the Internet server you have set up. Users also cannot exchange mail with other Internet users unless you have provided the necessary Internet mail server services on the server. Another disadvantage is that an Internet hacker can penetrate this security model.
A variation on the protocol isolation security model is to replicate the data from the Internet server onto another computer on the internal LAN using a replication service. This ensures security and also allows more control over what is brought into the LAN and permitted out of the LAN. Files can be checked for viruses or other problems. This variation requires a server such as Windows NT Server that provides a replication service.
For example, if you are using the Internet server as a drop box where customers use the Internet to leave questions and suggestions, a replication service can replicate the contents of the Internet server to an intermediary computer on the LAN. Conversely, if your LAN users need to post information to the public, they can copy the information to be shared to the LAN intermediary computer, and then that information can be replicated to the Internet server.
Router Security on TCP/IP-based LANs
If you are using TCP/IP on a large corporate network with a high volume of traffic or multiple subnets, you will probably use a dedicated router from another vendor and a leased-line connection to the Internet. Some dedicated routers can create a firewall by filtering packets.
On some networks, UNIX hosts or Windows NT Server computers might be configured to act as gateways, instead of using hardware routers.
TCP/IP router security using hardware or software routers
Windows 95 cannot serve as a router in this configuration
IP routing controls whether data is passed through the Internet server to and from the corporate network; that is, it controls whether the computer acts as a gateway. The router feature works both ways. Either traffic can pass both ways or traffic cannot pass through the server at all.
A Windows 95 computer cannot act as a router between different TCP/IP networks. Therefore, if you are using TCP/IP on your local network, a Windows 95 computer connected to the Internet can provide a limited firewall, because it does not provide routing between the public Internet and the private network. This type of security model, however, has all the advantages and disadvantages of the protocol isolation model.
Disabled TCP/IP router security
Windows 95 can act as the server for a very small network in this scenario, because it does not act as a TCP/IP router
Caution   Any private network connection on a Windows 95 computer acting as the server is available to the entire Internet in this configuration.
With this type of security model, you need to be especially careful to control physical and administrative access to the computer used as an Internet server. Many network administrators keep such servers and routers physically inaccessible to users who do not have appropriate administrative permissions.
Unrestricted Internet Gateway
Some organizations need to provide an unrestricted Internet gateway to their users. For example, you might have researchers who need to scan the Internet directly as a major part of their work and then combine information gleaned from the Internet with information on the corporate network. Rather than have each of these users connect to the Internet through a modem, you can have one computer that serves as a simple gateway to the Internet.
At some sites, this gateway might be provided by a UNIX host or Windows NT Server. A computer running Windows 95 cannot be configured to act as the Internet gateway.
Caution   This configuration poses great security risks for your local network.
Unrestricted Internet gateway using a UNIX or Windows NT server
Windows 95 cannot act as the gateway in this scenario
If you use this type of router, you need to protect sensitive data on the network by other means, such as file protections and user access control as described later in this section. Make sure that the users who have direct access to the Internet gateway are aware of the security issues. You might want to periodically remind them of these issues.
You’ll probably want to use the computer that acts as the Internet gateway for some Internet server services as well. This server is an ideal place for shared directories where Internet users and users of the corporate network can deposit and retrieve files and indexes.
Additional Methods for Internet Security
You can use methods other than network topology to secure your network. Some routers from other vendors use packet filtering to prevent unwanted access. On Windows NT networks, user account security can be configured to control access of the Guest account and others. Logon authentication in FTP and Telnet can also prevent unauthorized users from accessing your servers. On Windows NT computers (but not Windows 95), file system security can be used to prevent access to disk partitions.
Use firewalls and other inbound security. Products from other vendors can be used to create firewalls between the Internet and your LAN. Most of these products are based on filtering packets. Many dedicated routers used to connect a LAN to the Internet can be configured to filter packets based on the source or destination IP address. You can specify the IP addresses that are allowed into your LAN. Consult dedicated router vendors for more information about the packet-filtering products available.
If you are using a proxy or firewall on the local network to improve security for Internet connections, you can configure the Internet Explorer from Microsoft Plus! to use the proxy for Internet connections.
To use a proxy or firewall when connecting to the Internet
 1.      Run the Internet Setup wizard during the Microsoft Plus! Installation process.
      To run the wizard after Microsoft Plus! has been installed, click Start, point to Programs, then Accessories, then Internet Tools, and then double-click Internet Setup Wizard.
 2.      Configure your computer to use TCP/IP on the local area network.
 3.      When asked for the gateway address, type an address only if your network uses gateways for routing.
      Note   The gateway computer is not the same as the proxy or firewall computer that protects the local network from the Internet, so do not type your proxy or firewall address here.
 4.      In Control Panel, click the Internet icon, and then click the Advanced tab.
 5.      Make sure the Use Proxy Server box is checked.
 6.      In the Proxy Server box, type the HTTP server address and port number for the computer you want to use as the proxy server.
      Notice that 80 is the default port number assigned for WWW HTTP. The following is an example of an entry for proxy server address and port number.
 
http://myproxy.mycompany.com:80

 
 7.      In the box named Bypass Proxy On, type the names of the computers, domains, and ports on the Internet that, when accessed, will not go through the proxy server. Use a comma to separate each name you type.
 
Use file-system security. If you create an FTP server (for example, by using the capabilities available with Windows NT Server — FTP server support is not provided with Windows 95), you can and should use security settings to control specific access to files and directories and to configure the behavior of files and directories. It is a good idea keep the files available through FTP or HTTP on a volume separate from your operating system, application, or personal files. A basic use of file-system security is to create read-only directories so Internet users cannot change files. Windows NT Server can provide additional security as part of Windows NT File System (NTFS).
Use user-level security. A primary security measure that should be observed at all times is guarding the access privilege on computers connected to the Internet. Only employees with appropriate security clearances should be given the passwords for these accounts. Notice, however, that user-level security requires a Windows NT computer (or Novell® NetWare® server, depending on the type of network) configured with user accounts to validate access.
With user-level security, external Internet users can access your LAN under the Guest account. You should ensure that the permissions for the Windows NT Guest account on your Internet gateway is configured to provide adequate security.
If your Internet users are using any Microsoft networking client, such as Client for Microsoft Networks, you can use Windows NT user accounts to validate these users and define users’ permissions. These users can still access the system without a Windows NT user account using Guest or an anonymous FTP logon.
Also notice that users of two computers on the Internet with Microsoft Windows-based networking software (such as Windows 95, Windows for Workgroups, LAN Manager, or MS-DOS clients) can connect to resources on the distant computer — even if that computer is on another continent. A hacker using Windows-based software who knows the computer name and IP address of a computer on your network could use a net view command to see a list of your corporate servers. All Windows-based networking client security is controlled through Windows NT user account permissions and file permissions, just as it is on the local LAN.
Publish security guidelines. As part of your company policies, warn users that dial-up connections to external service providers when connected to the corporate network can jeopardize corporate security. This includes connections to Prodigy, America Online, CompuServe, Netcom, The Microsoft Network, and other Internet service providers. You may want to specify disciplinary consequences in addition to prescribing the correct methods for accessing outside providers.
Establishing the Infrastructure for an Internet Connection
After you determine the type of Internet connection to offer on the LAN, you must create the structure for providing services. This section explains Internet connection types, service providers, and formal requirements for participating in the Internet.
Internet connection types. A connection to the Internet is measured in the amount of data transferred per second as bits per second (bps). The connection types described in the following table represent typical levels of service for full Internet connections. The Internet services and providers in your area might differ slightly.
The following table lists the common connection types for full Internet connections. Some services (not listed) only provide Internet mail service or Internet news service.
Common Internet Service Connection Types
 
Connection type      Bits per second       (bps)      Approximate number of users      Approximate cost per month

UNIX shell account      Network speed       –        –
Dial-in, limited      Modem speed      1      $20 – 30
Dial-in, 24-hour      Modem speed      2      $200 – 300
Frame relay      56,000      5 – 10      $150 – 300
ISDN      128,000      10 – 25      $70 – 1001
Partial T1        Varies      Varies      Varies
T1      1 ,500,000      100 – 500      $1,500 – 2,0001
T3      45,000,000      5000+      $65,000 – 80,0001


1   Plus equipment costs.
The connection type you choose depends on the amount of traffic you expect:
·      To browse the servers on the Internet using a hypertext browser, you probably want to get a PPP dial-in account. These accounts can transfer data up to the speed of your modem and usually are metered or have time-use restrictions.
·      To establish a light-traffic FTP or World-Wide Web (WWW) server, you could probably use a 24-hour dial-in account. These accounts can transfer data up to the speed of your modem and are available 24 hours a day. Speeds faster than modem speeds are possible using frame relay or integrated services digital network (ISDN) lines. You will also need to have your computer registered with a DNS server and confirm with your Internet provider that you are creating this configuration. Your provider usually will register your computer with a DNS server.
·      To accommodate a medium amount of traffic, a server or access gateway might need to have a T1 or some fraction of a T1 line installed. Large businesses that expect heavy Internet traffic might need multiple T1 lines or a T3 service to handle thousands of users.
 
Internet service providers. You can find Internet service providers listed in your local phone book (usually under computer network services). Internet service providers also frequently advertise in local newspapers. Windows 95 Resource Kit Help (WIN95RK.HLP) also lists many PPP and SLIP service providers in locations around the world.
The services available on the Internet vary widely. The basic services used by Internet clients are shown in the following table, together with information about support provided in Windows 95 and Microsoft Plus!
 
Internet service      Support in Windows 95

Internet gateway (default gateway)      Can be provided by your Internet service provider or by Windows NT or UNIX gateways on your WAN.
TCP/IP addresses and subnet mask      Can be configured for the LAN and Dial-Up Adapter in the Network option in Control Panel or for individual dial-up connections, using official IP addresses from your Internet service provider or from InterNIC.
DNS name resolution      Can be configured in TCP/IP properties in the Network option in Control Panel. DNS server capabilities are not provided with Windows 95, so DNS server support must be available from a host on your network or from your Internet service provider.
Simple network mail protocol (SMTP) services      Can be installed from Microsoft Plus! or from the Internet Jumpstart Pack. Or software support might be provided by your Internet service provider.
Network news transfer protocol (NNTP) news groups      Requires software support from another software vendor. Or it might be provided by your Internet service provider.
Note   The Windows Sockets-based software provided by some Internet service providers might use different DLLs from those required under Windows 95. Depending on which software you install first, supporting files for your service software might be replaced by Windows 95 Setup, or required Windows 95 DLLs might be replaced by your service software. In either case, errors could result when you try to use either TCP/IP utilities or your service software.
To resolve related problems, you might have to reinstall service software in a separate folder (not the Windows folder), or reinstall Microsoft TCP/IP. If you continue to experience problems, contact your service provider for assistance or to obtain a Windows 95-compatible update.
IP addresses and domain names for Internet connections. Each computer on the Internet must have an IP address. For a simple dial-in connection through an Internet provider, your computer is usually assigned an address by the provider. If you use a PPP dial-up connection to the Internet through a service provider, it does not matter whether the computer is assigned a random IP address by the PPP server for the duration of the call.
However, if you want to offer a WWW server, you need a permanent IP address for the server. You must have as many IP addresses as you have computers connected to the Internet. For an Internet server to be reached using a friendly name, such as microsoft.com, rather than an IP address, you must use a DNS domain name. Most Internet service providers can register a DNS domain name for your Internet connection and provide IP addresses. Both are required to be seen and used by others on the Internet. For more information about obtaining official network IDs, see page 4 in this paper.
Internet information exchange. The Internet provides a vast collection of information and tools for publishing and accessing the information. Consult the Internet or your local library or bookstore for comprehensive discussions of the tools available for using the Internet. Gopher servers and WWW servers now provide formatted text, sounds, and animation to Internet users. To use these Internet services, you must use the proper browser (such as the Internet Explorer from Microsoft, Netscape, Cello, or Mosaic, or a Gopher client). These browsers also often support the older standards, such as FTP, so you can use these browsers to access multiple services and data types.
For information about using FTP and other tools for navigating the Internet, see Chapter 30, “Internet Access,” in Microsoft Windows 95 Resource Kit (page 955, U.S. edition).
Internet Information Publishing Tools
 
Service      Description

Microsoft Internet Assistant 2.0      Allows authors to create hypertext markup language (HTML) documents by converting existing Word documents or by authoring in a custom HTML template. (Version 2.0 is a 32-bit add-on for Microsoft Word 7.0.)
Microsoft Internet Explorer      Allows you to browse and access multimedia information and text on the Internet, copy information from a Web page to a document, and create shortcuts to return to favorite places.
FTP server service      Transfers files from one computer to another. Only an FTP client is provided with Windows 95, but Windows NT Server includes FTP server services.
Gopher server service      Supports searching files and directories distributed across thousands of gopher servers.
Wide Area Information Server (WAIS) service      Allows you to query full-content indexes of distributed databases and retrieve requested data.
WAIS Toolkit      Builds and queries indexes of words used in a set of files. These capabilities are included in the Microsoft Internet Assistant.
WWW server service      Provides access to multimedia information using the Hyper Text Transfer Protocol (HTTP).
Windows 95 and Multiple IP Network Connections
The combination of Client for Microsoft Networks with Microsoft TCP/IP with built-in DHCP and WINS clients make Windows 95 an ideal workstation on IP networks. In addition, Dial-Up Networking capabilities, The Microsoft Network, and the Internet Jumpstart Pack all contribute to make Windows 95 an ideal platform for connecting to and communicating on the public Internet.
However, a Windows 95 computer can also be configured with multiple network adapters or otherwise be configured for simultaneous connection to multiple subnetworks. A Windows 95 computer cannot be configured to support routing between IP networks, but some routing table issues can arise for a Windows 95 computer that is connected to multiple IP networks.
This section provides details for configuring and troubleshooting multihomed and routing capabilities in Windows 95.
Managing Multihomed Configurations
This section is written for network administrators on any size network who need to establish multihomed capabilities for one or more computers running Windows 95.
When a computer is configured with more than one IP address, it is referred to as a multihomed system. Network administrators create multihomed configurations for purposes such as the following:
·      To connect a computer simultaneously to the local network and to the Internet
·      To connect to different subnets when the computer is on a single physical network that contains multiple logical IP networks
·      To allow a computer to communicate simultaneously on two otherwise isolated networks
 
For example, a company might have only one physical network, but might want to prevent users from seeing certain private servers on logical IP networks that are different from the logical IP networks used by most of the company’s workstations. For a user who needs to see the usual public servers as well as the private servers, the computer can have an IP address for the logical IP network used by most workstations plus an IP address for the logical IP network used by the private servers. Such workstations can then access computers on both networks. Such multihomed configurations might be used by network administrators who administer certain servers in addition to standard workstations.
Multihomed Windows 95 computer connected to two separate networks
As another example, a workstation on the local area network at a branch office that also requires a network connection to certain computers on the corporate enterprise network might require a multihomed configuration. Such a configuration might be used, for example, by financial or human-resources personnel who must access servers on a private subnet.
A more common configuration using multiple IP addresses in Windows 95 is a combination of LAN and dial-up connections to the Internet or another IP network. This is discussed in “Configuring IP LAN and Dial-Up Connections” on page 4 in this paper.
This section provides information for configuring and troubleshooting problems on multihomed computers running Windows 95.
Note   For corporate computing environments that require routing among subnetworks, you should use dedicated routers such as a Cisco routers, UNIX hosts, or a computer running Windows NT Server 3.5 or later. Multihoming on a Windows 95 computer is only suitable as a limited solution for connecting a single computer to other networks.
Configuring TCP/IP on Multihomed Computers
Multihoming capabilities are usually configured by using multiple network adapters on a single computer, multiple media, or multiple IP addresses for a single network adapter.
For a multihomed computer that uses multiple network adapters for physical connections to the LAN, or a Dial-Up Adapter for remote access, there is an instance of Microsoft TCP/IP for each adapter in the Network option in Control Panel.
Networking components for a multihomed computer, showing two network adapters for LAN connections, plus a Dial-Up Adapter for remote-access connections
Multiple network adapters per physical network. Windows 95 places no restrictions on such configurations, so you can add as many network adapters as the computer hardware can accommodate, and assign each a separate address.
To configure a multihomed system using multiple network adapters
·      Add TCP/IP configuration information for each network adapter in the Network option in Control Panel, either by using DHCP or by entering information for static IP addresses.
 
Multiple networks and media types. There are no restrictions for this type of configuration other than hardware and media support. Microsoft TCP/IP supports the following:
·      Ethernet (and 802.3 SNAP)
·      Token Ring (802.5)
·      FDDI and ArcNet®, using NDIS 2 real-mode network adapter drivers (only a few protected-mode adapter drivers are available for FDDI supporting TCP/IP)
·      WAN, using switched virtual-circuit wide-area media such as ISDN, X.25, and dial-up or dedicated asynchronous lines
 
Multiple IP addresses per network adapter. For LAN connections, this kind of multihoming option is not available in the TCP/IP properties in the Network option in Control Panel. However, additional addresses can be added directly in the Registry, although this is not a recommended method for configuring TCP/IP.
To configure multiple IP addresses for a single network adapter
·      Use Registry Editor to add lists of values for the Registry entries IPAddress, IPMask, and DefaultGateway as described on page 4 in this paper.
      The values you manually enter in the Registry are static and cannot be updated or changed using DHCP.
 
This has the same effect on your computer as if there were multiple network adapters connected to different logical networks.
Note   For general networking, name resolution using NetBIOS over TCP/IP supports only one IP address per network adapter. When a NetBIOS name registration broadcast is sent, only one IP address will be registered per network adapter.
If DHCP is enabled for configuring TCP/IP, only one DHCP-assigned address can be provided per adapter, and this address will be the first address in the list in the Registry. A DHCP-provided address always appears as 0.0.0.0 in the Registry.
Troubleshooting for Multihomed Computers
If TCP/IP is configured for multiple network adapters, or for both LAN and Dial-Up connections, the following issues must be considered.
A unique IP address and subnet mask are defined for each adapter. For each network adapter or Dial-Up Adapter, an instance of TCP/IP is bound to the adapter. You can choose to have all IP addresses dynamically assigned by DHCP, all addresses defined manually as static addresses, or have some addresses assigned by DHCP and some defined as static addresses.
The default gateway can be different for each adapter. For multiple physical connections to the WAN, you will need to assign a different default gateway for each network connection. The default gateway for the Dial-Up Adapter is assigned by the access provider. Different gateways can also be defined per connection using the Make New Connection wizard.
The WINS and DNS configuration settings are global. The settings on the WINS Configuration and DNS Configuration tabs in TCP/IP properties are used for all adapters on the computer. For example, if you change the DNS settings in the TCP/IP properties for the Dial-Up Adapter to enable DNS, then DNS is also enabled for every LAN adapter on the computer. If you enable the option named Use DHCP For WINS for a LAN adapter, this option is also enabled for the Dial-Up Adapter and every other LAN adapter on the computer.
Therefore, for a multihomed computer, you must carefully define options for DNS and WINS that are applicable for all adapters using TCP/IP. Usually, this means that you want the following:
·      If you want to use DNS or the HOSTS file for name resolution with any TCP/IP connection, then make sure DNS is enabled.
      Note   In the case when WINS is used for name resolution on the network (including using WINS servers for host-name resolution) and when DNS is used only for dial-up connections, it is easy for a user to mistakenly disable DNS in the TCP/IP properties for the LAN adapter, without realizing that this also disables DNS for the remote connection. The result would be an inability to find remote hosts when using the remote connection.
·      If WINS is used for name resolution on the network, make sure WINS is enabled. However, in general for multiple physical adapters connected to separate networks, WINS is not recommended, because the WINS server is not likely to be able to resolve names for multiple isolated networks. Instead, configure NetBIOS name resolution using LMHOSTS.
 
Editing the Routing Table
This section is written for network administrators on any size network who need to modify the static routing table for one or more computers running Windows 95.
IP networks are connected by gateways, which are hardware routers or servers running routing software with the information necessary to interpret IP addresses in the internetwork. Usually the default gateway is used to find remote destinations, although each IP host can maintain static routes for specific destination addresses that are part of the internetwork. Dedicated routers from some vendors use a protocol such as RIP to exchange routing tables automatically.
Because the default gateway knows the network IDs of the other networks in the internetwork to which it is attached, it can forward the packet to other gateways until the packet is eventually delivered to a gateway connected to the specified destination. This process is known as routing.
When IP prepares to send a packet, it inserts the local (source) IP address and the destination address of the packet in the IP header and checks whether the network ID of the destination matches the network ID of the source:
·      If they match, the packet is sent directly to the destination computer on the local network.
·      If the network IDs do not match, the routing table is examined for routes.
·      If none is found, the packet is forwarded to the default gateway for delivery.
 
Internetwork routing, showing hardware routers acting as gateways, although servers such as Windows NT can also be used as gateways to support routing among subnets
When TCP/IP is configured on a computer, the IP address for a default gateway can be specified. On networks that are not subnetworks of an internetwork, IP gateways are not required. If a network is part of an internetwork or is connected to the public Internet, a default gateway must be specified in order to communicate beyond the local subnet.
Windows 95 computers cannot behave as routers, and so cannot act as gateways.
If the default gateway becomes unavailable, the computer cannot communicate outside its own subnet. Multiple default gateways can be assigned to prevent such a problem. When a computer is configured with multiple default gateways, transmission problems cause the system to try other gateways in the configuration if the first default gateway does not respond. To configure multiple default gateways in Windows 95, you must provide an IP address for each gateway in the Microsoft TCP/IP properties.
When multiple default gateways are defined, TCP/IP tries the first gateway on the list when a packet is addressed to a computer outside the local subnet. If that gateway does not respond, the next gateway is tried. However, if the first gateway responds but cannot find the destination computer, TCP/IP does not subsequently try the next gateway in the list. A gateway provides only a method for routing between networks, not another method of name resolution.
Configuring IP LAN and Dial-Up Connections
For Windows 95, a typical configuration using multiple IP addresses is a computer using multiple Dial-Up Networking connections in addition to a LAN connection.
Important   Do not enter the static settings for a dial-in connection using the Dial-Up Adapter properties in the Network option in Control Panel. Instead, enter static settings for a dial-up connection only in the properties for the specific connection in the Dial-Up folder in My Computer.
To configure multiple IP addresses for Dial-Up Networking connections
·      Use the Make New Connection wizard in the Dial-Up Networking folder to define the correct IP address information for the particular connection.
      The unique settings for each Dial-Up connection (sometimes called a connectoid) include separate IP address, DNS server addresses, and WINS server addresses.
 
Configuring Dial-Up Clients and Servers
This section focuses on common configuration issues for Dial-Up Networking.
To specify server type and protocol settings for a Dial-Up client
 1.      In the Dial-Up Networking folder, right-click the icon for a dial-up connection, and then click Properties.
 2.      Click the Server Type button to specify the type of server — which must be a PPP or SLIP server if you a dialing into an Internet server. For an Internet connection or to dial into an IP network, the network protocols allowed must include TCP/IP.
      Server-type settings for a Dial-Up client connection
       3.      If you need to manually configure IP information for a dial-up connection, click the TCP/IP Settings button, and enter the correct settings here.
      By default, Dial-Up Networking is configured to use an IP address assigned by the dial-in server.
        
The following describes configuration options when the Dial-Up Server capabilities from Microsoft Plus! are installed on a Windows 95 peer server.
To specify server type and protocol settings for a Dial-Up Server
 1.      From the Connections menu in the Dial-Up folder, click Dial-Up Server.
 2.      Click the option named Allow Caller Access, and then click the Server Type button.
       3.      In the Type Of Dial-Up Server list, click the PPP option. Leave the advanced options checked (the default) unless you specifically know that either of these options should not be checked. Then click OK.
      Server-type settings for the Microsoft Dial-Up Server provided with Microsoft Plus!
        
Notice that if you are using the Dial-Up Server from Microsoft Plus! to dial into an Internet server while the computer is connected to the local network, you do not have to specially configure Registry settings on the client computer. (Special Registry settings are required for a Windows NT computer that is a RAS client making an Internet connection while connected to the LAN.)
SLIP configuration issues. If you are using a SLIP connection, you need to ensure that the IP Header Compression setting is correct. If you choose the wrong setting, IP and UDP programs such as ping might work normally, but TCP programs such as a Web browser will not work.
Tip   If you are using SLIP for slow connections to an Internet services provider, you might need to change the Registry value for MaxMTU (the MTU size), as described on page 4 in this paper.
PPP configuration issues. You can create dial-up connections to PPP servers such as Windows 95 Dial-Up servers, Windows NT RAS servers, Novell NetWare Connect servers, Shiva® LanRover servers, and Internet service providers. If you are connecting to a Windows NT RAS server, make sure to type a valid user name and password when you start the connection.
When dialing into a third-party server, you might experience long delays. The following shows how to solve this.
To avoid long logon delays when dialing in to a PPP server
·      In the Server Type dialog box, clear the following options:
·      Under Advanced Options, clear Log On To Network.
·      Under Allowed Network Protocols, clear NetBEUI and IPX/SPX-compatible.
 
 
If the Log On To Network option is enabled, then Dial-Up Networking tries to find a Microsoft Windows network. If it does not find a network, it times out, which causes the long delay when logging on to an Internet provider, since the PPP server for the Internet provider will not be running Microsoft Windows networking software.
In most cases, the PPP server will be running only the TCP/IP protocol. If the NetBEUI and IPX/SPX-compatible protocols are bound to the Dial-Up Adapter, then removing these two protocols from the connectoid also saves a few more seconds, because the system will not try to bind these protocols to the Dial-Up Adapter.
If a computer is using TCP/IP for WAN connections but no DHCP server is present on the LAN, and if TCP/IP is bound to both a LAN adapter and a Dial-Up Adapter using PPP, the computer may pause for a couple of seconds every once in a while.
·      To avoid this in most WAN configurations, unbind Microsoft TCP/IP in the network adapter’s properties until the DHCP server is available again, but keep the TCP/IP binding for the Dial-Up Adapter, which the PPP dial-up connection uses.
·      If the dial-up connection also requires a simultaneous LAN connection, you can turn off DHCP in the TCP/IP properties and manually configure the IP address for the LAN adapter.
 
Troubleshooting Dial-Up Configuration
If the modem dials but no connection is established with the dial-in server, check the following items:
·      Make sure you chose the correct server type, as described earlier.
·      Make sure that compatible protocols are installed and bound in the Dial-Up Adapter properties in the Network option in Control Panel.
·      Try turning off software compression. To do so, right-click the icon for the connection in the Dial-Up Networking folder, then click Properties. Click Configure, click the Connection tab, then click Advanced. Use Windows 95 Help for guidance in selecting settings.
·      Open the Terminal window after dialing to determine whether additional logon information is required. To do so, right-click the icon for the connection, then click Properties. On the Options tab, make sure the option named Bring Up Terminal Window After Dialing is checked. Use the Terminal window to enter any required logon information. This is especially useful if you dial into several different servers.
·      Check the PPPLOG.TXT file to ensure that the provider has assigned an IP address. For information, see Microsoft Windows 95 Resource Kit (page 914, U.S. edition).
·      Check with your Internet provider to confirm that the connection is using the required settings for protocols, logon information, and TCP/IP addressing.
 
PPP issues on IP networks. A Windows 95 computer can be configured with both a LAN adapter connected to an IP network and a Dial-Up Adapter for a PPP connection to the Internet or another IP LAN. When such a computer attempts to access a particular IP address, the destination server is located by checking the routing table and using the following process:
·      If the destination IP address indicates that it is on the same IP subnet as the workstation’s LAN adapter, then data is sent using the LAN adapter.
·      If the destination IP address indicates that it is not on the same subnet as the workstation’s LAN adapter, then data is sent to the default gateway. The default gateway then locates the destination route on behalf of the remote workstation.
·      If the default gateway IP address was previously configured for the LAN adapter, it is ignored by default. If required, the remote workstation can be configured so that the default gateway on the LAN adapter is used instead of the default gateway on the remote connection.
 
This configuration becomes complicated for a user who is either dialing into the Internet when connected to a local private IP network or, conversely, when connected directly to the Internet and dialing into a private IP network. This is because PPP creates a default route if the option named Use Default Gateway On Remote Net is checked.
The default route that PPP creates establishes a priority for this connection in the computer’s routing table. This priority allows full access to the remote network for name resolution and forwarding packets. However, it means more limited access for the local connection, because the default gateway used for network communications becomes the default gateway specified for the PPP connection. You will probably become aware of problems that this can cause when you try to connect to computer on a remote subnet, but Windows 95 reports that it can’t find that computer name.
Basically this problem occurs because neither the Domain Name System nor the TCP/IP protocol suite is not designed to support multiple address spaces, which is the situation that occurs when a computer is simultaneously connected to a private IP network and the public Internet (or another private IP network).
To resolve the name resolution problems that can occur when you maintain a local network connection while using a Dial-Up connection to the Internet, see the section on how modify the route table, as described in the following section.
Defining Static Routes in Windows 95
The route utility is provided with Windows 95 when Microsoft TCP/IP is installed. The syntax for the route command is the following:
route [-f] [command [destination] [MASK netmask] [gateway]]
 
Parameter      Description

-f      Clears the routing tables of all gateway entries. If this parameter is used in conjunction with a command, the tables are cleared prior to running the command.
Command      Specifies one of four commands:·   print to print a route·   add to add a route·   delete to delete a route·   change to modify an existing routeIf the command is print or delete, wildcards can be used for the destination and gateway, or the gateway argument can be omitted.
Destination      Specifies the host to which the command is to be sent. All symbolic names used for destination are looked up in the NETWORKS file.
MASK      Specifies, if present, that the next parameter be interpreted as the netmask parameter.
Netmask      Specifies, if present, the subnet mask value to be associated with this route entry. If not present, this parameter defaults to 255.255.255.255.However, the route utility does not accept a subnet mask value of 255.255.255.255 on the command line. To specify a subnet mask with this value, you must accept the default.
Gateway      Specifies the gateway. All symbolic names for gateway are looked up in the HOSTS file.
/p      Not a valid parameter for Windows 95. Under Windows NT 3.51, this switch specifies permanent routes.
Note   Although you cannot define a permanent route as a parameter with the route command, you can create a batch file that runs as part of system startup to define the route parameters that you want.
The route utility uses the NETWORKS file to convert destination names to addresses (network ID). The following shows the basic NETWORKS file installed in the Windows folder when you install Microsoft TCP/IP on a computer running Windows 95. Modify this file by using a text editor to add the network name and network ID for other local networks.
 
# Copyright (c) 1993-1995 Microsoft Corp.
#

# This file contains network name/network number mappings for
# local networks. Network numbers are recognized in dotted decimal form.
#
# Format:
#
# <network name>  <network number>     [aliases...]  [#<comment>]
#
# For example:
#
#    loopback     127
#    campus       284.122.107
#    london       284.122.108

loopback                 127
 
To troubleshoot the NETWORKS file on a local computer
 1.      Make sure the format of entries in the file matches the format defined in the sample file installed with Microsoft TCP/IP.
 2.      Check for and correct spelling errors.
 3.      Check for and correct invalid IP addresses and identifiers.
 4.      If problems occur when using the route utility, add trailing zeroes as the fourth octet for each entry. For the route utility to work correctly, the network numbers in the NETWORKS file must specify all four octets in dotted decimal notation. For example, a network number of 284.122.107 must be specified in the NETWORKS file as 284.122.107.0, with trailing zeroes appended.
      Notice, however, that the sample entries provided in the basic NETWORKS file installed with Microsoft TCP/IP will correctly support the ping utility without including a trailing zero as the fourth octet.
 
The route table maintains four different types of routes. The following list shows the order in which they are searched for a match:
 1.      Host (a route to a single, specific destination IP address)
 2.      Subnet (a route to a subnet)
 3.      Network (a route to an entire network)
 4.      Default (used when there is no other match)
 
For example, if the Dial-up Adapter is connected to the Internet and a network adapter is using TCP/IP on the local LAN (creating the problem described in the previous section), the following route command allows this workstation to connect to a computer on a remote subnet in the enterprise network, rather than routing to the Internet:
 
route add 11.1.0.0 mask 255.255.0.0 130.25.0.1
 
In this example:
·      11.1.0.0 is the remote subnet.
·      255.255.0.0 is the subnet mask.
·      130.25.0.1 is the default gateway on the local LAN.
 
Notice that this will fail unless the destination gateway can always be reached from the directly connected network. In this example, the local computer must always be able to reach the node with the address 130.25.0.1 without going through a router.
Troubleshooting Gateway Problems
If a host computer on one subnet has problems communicating to computers on another subnet when using TCP/IP, the following information can help you determine whether the problem is with the gateway. For these troubleshooting steps, it does not matter whether gateway that provides routing capabilities is a hardware router or a Windows NT or UNIX server configured to act as a router.
First, to troubleshoot gateway problems, you need a network map, plus the IP addresses and subnet masks for the host computer with problems, the near side of the hardware or software router that acts as the gateway, the remote side of the gateway, and the destination computer (node). For example, the following illustration shows two subnets connected by a router.
The following example of troubleshooting steps uses the IP addresses from this illustration.
To troubleshoot possible gateway (router) problems
 1.      Use ping to access the host computer that is having problems communicating outside the subnet. For example:
 
ping 195.22.3.33

 
      If this works, this host is probably healthy at the IP level.
      If this doesn’t work, use the usual methods to check the IP configuration and network connections on this host.
 2.      If the problem is not solved, use ping to access the near side of the router (that is, the default gateway). For example:
 
ping 195.22.3.1

 
      If this works, this side of the router is healthy.
      If this doesn’t work, use the usual methods to check the actual IP configuration and network connection for the near side of the router. Adjust the gateway settings on the problem host computer, if required.
      Notice, however, that if you can use ping to get a response from this address, it does not necessarily mean that this is actually a router.
 3.      If the problem is not solved, use ping to access the far side of the router. For example:
 
ping 195.22.4.25

 
      If this works, the router is working.
      If this doesn’t work, have another user use the same ping command from the destination node (195.22.4.66 in the example).
      If this works, the router is not working correctly.
 4.      If the problem is not solved, use ping to access the remote host. For example:
 
ping 195.22.4.66

 
      If this works and all problems in the previous steps have been resolved, TCP/IP should be working fine.
      If this doesn’t work, check the IP configuration and network connections on the destination computer. Typically, at this point the problem is that the remote computer has not route configured back to the original host computer.
 
When troubleshooting router connections, note the following:
·      Do not use the host name when you are testing the router; instead, use the IP address to avoid any problems related to the HOSTS or LMHOSTS files, DNS server, WINS server, or any other methods of name resolution.
·      In most cases, the subnet mask should be the same for all hosts on the same side of the router.
·      There could be two routers at separate sites performing the same job as described above; if this is the case, treat this situation the same as above, keeping in mind that each router could have a near and far side, depending on the configuration.
·      If multiple routers exist between the source and destination, use tracert to see an ordered list of routers used.
 
Tip for using SNMP for routing   The TCP/IP utilities use the public interface provided by INETMIB1.DLL in both Windows NT and Windows 95. This API can be used with SNMP for actions such as setting and getting routing information programmatically on Windows 95 computers. For information about the management information base (MIB) object types provided for Microsoft networking, see Windows NT Networking Guide (v. 2 in Microsoft Windows NT 3.5 Resource Kit).
Notice, however, that you cannot use a Windows 95 computer to run the SNMPUTIL tool provided with the Windows NT Resource Kit utilities.
Integrating Windows 95 in the TCP/IP-based Enterprise
The topics in this section are written for network administrators responsible for integrating Windows 95 in enterprise networks that use TCP/IP as a transport protocol.
This section focuses on these topics:
·      Planning automated setup for Microsoft TCP/IP in the enterprise.
·      Using standard TCP/IP utilities with Windows 95.
·      Enterprise issues for Microsoft TCP/IP and Windows 95, including DHCP and WINS client issues, DNS issues, and additional connectivity notes.
 
Planning Automated Setup for Microsoft TCP/IP
This section provides some notes and recommendations for implementing automated setup for Windows 95 in the WAN environment, depending on whether DHCP is used to configure TCP/IP.
Planning Setup for DHCP Sites
Obviously, one of the tasks in preparing to roll out Windows 95 is to ensure that DHCP servers and backups are available on the network and properly configured to provide complete TCP/IP configuration parameters, including WINS server information, if applicable.
The following shows the required parameters in MSBATCH.INF for automated setup with DHCP:
 
[network]
protocols=mstcp

[mstcp]
dhcp=1
wins=1               ; or WINS=DHCP if DHCP servers assign WINS settings
PrimaryWINS=Ipaddress
SecondaryWINS=Ipaddress
ScopeID=value       ; If NetBIOS scope IDs are used on this network

 
Planning Setup for Non-DHCP Sites
For Windows 95, you cannot use the IPINFO.INF method provided with Windows NT for static TCP/IP configuration.
The only method currently available for automatically installing Windows 95 for static TCP/IP configuration information is to use the INF Generator utility together with comma-separated text files (CSV) that contain specific entries with settings for each user and workstation. INF Generator is a Win32®-based wizard that helps create individual batch setup files for multiple users. It can use information from your data acquisition tools to define specific configuration settings, such as IP addresses, subnet masking, default gateway, and workgroup information.
For information about how to use INF Generator for automated setup of Windows 95, see the documentation included with the utility on the Microsoft Web site at www.windows.microsoft.com.
Configuration Notes for NetBIOS Scope ID
The NetBIOS scope allows interoperation with other NetBIOS implementations that use the NetBIOS scope ID. Before any packets that contain a NetBIOS name are transmitted, the NetBIOS scope ID is appended to the name. This includes packets such as name queries, name registrations, and session requests. On the receiving end, the NetBIOS scope in a packet must match the locally configured NetBIOS scope; otherwise, the packet is ignored. Therefore, only computers that have the same scope can communicate with each other using NetBIOS.
In the Network option in the Windows 95 Control Panel, you must first enable WINS name resolution in order to manually configure the NetBIOS scope ID in the TCP/IP properties. Therefore, you must also enter at least one IP address for a WINS server, even though a WINS server might not be present on the network. However, if you install Windows 95 using a setup script and define the NetBIOS scope ID in the setup script, you do not also have to specify wins=1 plus a WINS server IP address.
Notice that since NetBIOS scope IDs are used to segment network traffic, you must be very careful about assigning NetBIOS scope IDs. With a faulty scope ID configuration, users may not be able to connect to other computers.
In most cases, the NetBIOS scope ID is null.
Using TCP/IP Utilities
Microsoft TCP/IP allows access to resources on other networks, such as VMS, IBM mainframe, and UNIX, through the ftp and telnet utilities, which are installed automatically with TCP/IP. Windows Sockets-based TCP/IP utilities from any other vendor may also run under Windows 95.
When Microsoft TCP/IP is installed under Windows 95, TCP/IP utilities are installed automatically. In addition to arp, nbtstat, netstat, ping, route, and tracert, Windows-based versions are provided for telnet, ftp, and winipcfg (the Windows-based version of the ipconfig utility provided with Windows NT).
Windows 95 does not provide any components to allow connectivity to NFS-based UNIX resources. Network File System (NFS) connectivity must be added by installing additional software from another vendor that includes an NFS redirector, such as that provided by Sun® Microsystems or Beame and Whiteside.
The additional TCP/IP utilities provided with Windows NT Server 3.5 and later will not run under Windows 95.
The key utilities in Windows 95 for checking configuration are ping, tracert, and winipcfg, which are all included automatically with TCP/IP on Windows 95. The key items to check for TCP/IP configuration problems are:
·      Invalid subnet mask
·      Invalid default gateway address
 
 
Tool      Description

ping      Used to send ICMP echo requests to an IP address and then wait for ICMP echo responses. The ping utility reports on the number of responses received and the time interval between sending the request and receiving the response.
tracert       Used to trace the route of networking messages. Tracert sends ICMP echo requests to an IP address while incrementing the TTL (Time To Live) field in the IP header by 1 starting at 1, and then analyzes the ICMP errors that are returned. Each succeeding echo request should get one hop further into the network before the TTL field reaches 0 and before an ICMP Time Exceeded error is returned by the router attempting to forward it. Tracert creates an ordered list of the routers in the path that returns these error messages.
winipcfg      With DHCP, used to report the IP configuration settings provided by the DHCP server for the local computer.
Enterprise Issues for Microsoft TCP/IP and Windows 95
This section presents brief notes on items related to configuring and using Windows 95 with TCP/IP in the enterprise.
Issues for Enterprise Networks with Multiple Client Software
This section summarizes configuration and maintenance issues for enterprise networks that include multiple network clients, or that must provide for communications among several distinct types of networks, such as combinations of Microsoft networking, NetWare, and Banyan®.
Most basically, two computers on the network can communicate when both of the following are true:
·      Both systems are running a standard implementation of TCP/IP, such as Microsoft TCP/IP.
·      Both systems are running the same application-layer program, such as a Windows Sockets-based application, or an FTP client on one system and an FTP server on the other.
 
For File and Printer Sharing services, Microsoft TCP/IP cannot be used with NetWare/IP in NetWare networks, because that implementation chiefly provides for NCP requests to be sent over IP headers. In this network configuration, where Windows 95 clients and NetWare clients are on the same network, the Windows 95 computers must use the IPX/SPX-compatible protocol to communicate with NetWare clients and servers. However, Microsoft TCP/IP will work fine for FTP and similar services.
Microsoft TCP/IP can be used to communicate with real-mode Banyan network clients that run a generic TCP/IP protocol. Any clients that run the Banyan proprietary TCP/IP protocol cannot communicate with Windows 95 computers using NetBIOS over TCP/IP. In this case of mixed protocols, you can use ping, ftp, and telnet to exchange information, but NetBIOS name resolution will not work between the real-mode Banyan client and Windows 95 running Microsoft TCP/IP.
Contact your software and networking vendor to determine the availability of TCP/IP and Windows Sockets software that is compatible with Microsoft TCP/IP. Many vendors, including FTP Software, Chameleon, and Sun Microsystems, are developing software and implementations of TCP/IP that are compatible with Windows 95 and Microsoft TCP/IP.
Issues for Shared Installations of Windows 95
For computers that run a shared copy of Windows 95 from a server, real-mode network components are required for the first connection to the network during system startup. Microsoft TCP/IP in Windows 95 runs only in protected mode, so the computer must load NetBEUI or the IPX/SPX-compatible protocol to make the real-mode connection to the network. After the operating system loads and switches to protected mode, then Microsoft TCP/IP can be used for network communication.
For shared installations, real-mode versions of NetBEUI and IPX/SPX-compatible protocols are built into the real-mode software that is used to make the first connection to the server before Windows 95 starts. The server must also be running the NetBEUI or IPX/SPX protocol in this configuration.
Notice also that the real-mode networking used in shared installations for the first connection to the server does not support mailslots or named pipes. However, the full network redirector that is used after the first connection does support mailslots and named pipes.
Important   You cannot use the real-mode TCP/IP stack provided with LAN Manager to support the initial system startup for shared installations of Windows 95 on IP networks.
DHCP and WINS Client Issues for Windows 95
This section summarizes some technical issues related to using DHCP and WINS client services with Windows 95. For a detailed technical discussion of browsing with or without WINS servers, see the Windows 95 technical white paper titled Browsing and Windows 95 Networking.
BOOTP and DHCP implementation issues. DHCP is a specific protocol defined in RFC 1541 and 1542. Although DHCP is based on an extension of BOOTP, these are not equivalent protocols, and BOOTP cannot be used to configure Microsoft TCP/IP for either diskless workstations or for other configurations running Windows 95.
To support DHCP forwarding across a router that is configured to support BOOTP, the router must be RFC 1542-compliant. Other vendors, including Sun Microsystems and FTP Software, also provide DHCP server products, in addition to the DHCP server capabilities provided with Windows NT Server 3.5 and later.
WINS proxy agent issues. Microsoft TCP/IP allow a WINS-enabled computer to act as a WINS proxy agent for b-node clients on the network. The WINS proxy agent can resolve broadcast name queries from the b-node clients through the WINS server. A proxy agent does not participate in the name registration process, nor does it check for duplicate names in the WINS server database for the b-node client.
Examples of computers on the network that might be b-node clients include computers running MS-DOS, Windows 3.1, or Windows for Workgroups that do not have WINS client software installed, or SMB-based network servers such as IBM® LAN Server, DEC™ PATHWORKS™, AT&T® StarLAN, and LAN Manager for OS/2® or UNIX Systems.
When a b-node client tries to access a resource, it sends a broadcast for that name on the local subnet. If a WINS proxy agent is enabled on that subnet, this proxy agent picks up the name query and tries to resolve it through its internal cache of remote names. If the name is not registered in the cache, the proxy agent contacts the WINS server to resolve the names. If the name query for the remote name is successful, the proxy agent receives the IP address of the remote name from the WINS server and then caches the name. The proxy agent waits for the next query for that name, and then responds from the cache, indicating that the name query is successful.
If the WINS proxy agent cannot resolve a name through either its internal cache or the WINS server, the proxy agent does not return any response to the b-node client.
Note   There should only be one or two WINS proxy agents enabled per subnet. Enabling more than two proxy agents causes multiple requests to be sent to the WINS server, and multiple responses to be generated for each name query on the local subnet.
To enable the WINS proxy agent capabilities on a Windows 95 computer, set EnableProxy=1 in the Registry, as described on page 4 in this paper.
Global WINS settings. If WINS is enabled (or the Use DHCP For WINS option) for any instance of TCP/IP on a computer, for all TCP/IP connections, name queries will be sent to the WINS server for all NetBIOS name resolution. Conversely, if you disable WINS settings in the TCP/IP properties for any adapter, then WINS is disabled for all network adapters on the computer. All WINS settings are stored in the Registry.
To enable and configure WINS for name resolution, use the WINS Configuration tab in the TCP/IP properties
WINS name resolution in Windows 95. If any WINS server replies to a name resolution request, then any additional WINS servers listed in the TCP/IP properties are not checked, even if the first WINS server responds that the requested computer name is unknown. Windows 95 only checks with additional WINS servers if no response at all is received from the first WINS server.
The following illustration summarizes how name resolution using NetBIOS over TCP/IP works, depending on whether WINS servers are used.
 
For more information about      See

Node types and basic name resolution information      Chapter 12, “Network Technical Information,” Microsoft Windows 95 Resource Kit (page 436, U.S. edition)
How computer names are registered and how NetBIOS over TCP/IP name resolution works      Browsing and Windows 95 Networking, a Microsoft Windows 95 white paper.
DNS Client Issues for Windows 95
Microsoft TCP/IP for Windows 95 includes only a DNS client. The DNS server that provides host and domain lookups must be provided by another vendor, by a Windows NT computer configured as a DNS server, or by your Internet service provider. Both Windows Sockets-based applications and NetBIOS over TCP/IP name resolution will check the HOSTS files on the local computer before attempting to find a DNS server for name resolution.
To use DNS for name resolution in Windows 95, you must enable DNS in the TCP/IP properties using the Network option in Control Panel
Global DNS settings. If DNS is enabled for any instance of TCP/IP on a computer, then name queries will use DNS. Conversely, if you disable DNS in the TCP/IP properties for any adapter, then DNS is disabled for all network adapters on the computer, including Dial-Up connections. All network adapters use the last settings defined for DNS servers. These settings are stored in the Registry, and will continue to be used on the computer unless you specifically use the Remove button to remove the DNS server listing from the TCP/IP properties.
Tip   If you are troubleshooting TCP/IP name resolution problems for a client computer that uses WINS or has a Dial-Up Adapter installed, check the entries for DNS. If the user mistakenly entered the DNS information for a specific dial-up connection in the Dial-Up Adapter properties, then all network adapters are trying to use that setting. If DHCP is supposed to supply the DNS configuration or if WINS is used for DNS resolution, but the user has added static DNS settings, then DNS resolution might be attempting to contact the wrong servers. Remove any existing entries to make corrections.
DNS name resolution in Windows 95. If any DNS server replies to a name resolution request, then any additional DNS servers listed in the TCP/IP properties are not checked, even if the first response is negative. That is, if the DNS server responds that the requested host name is unknown, then Windows 95 does not check with other servers listed in the TCP/IP properties. Windows 95 only checks with additional DNS servers if no response at all is received from the first DNS server.
The key troubleshooting tasks are to ascertain that the default gateway address is correct for each adapter in the TCP/IP properties, and to ensure that any static settings for DNS servers specify correct addresses that can be used globally by all adapters on the computer. DNS settings for each particular dial-up connection should be set only in its properties in the Dial-Up folder in My Computer.
The following illustration summarizes how DNS names are resolved in Windows 99 networking, if previous attempts to resolve names fail using NetBIOS over TCP/IP.
 
For more information about      See

Troubleshooting DNS issues when a PPP dial-up connection is used on a network computer      “Configuring IP LAN and Dial-Up Connections” on page 4 in this paper.
How computer names are registered and how NetBIOS over TCP/IP name resolution works      Browsing and Windows 95 Networking, a Microsoft Windows 95 white paper.
Windows Sockets Application Issues
Windows Sockets-based applications, including some TCP/IP utilities such as ping, can use host names instead of IP addresses by using the Windows Sockets gethostbyname() API. The following is the sequence used for name resolution in such cases:
 1.      Check whether the host name matches the local computer name.
 2.      Check whether the host name is found in the HOSTS file in the Windows folder.
 3.      If the computer is configured to use DNS, check whether the host name can be resolved using DNS. If no DNS server responds, then check the LMHOSTS file in the Windows folder.
 4.      If the computer is configured to use WINS, check whether the host name can be resolved using WINS.
      If this method is used, the host name is converted to a NetBIOS name by padding the name with spaces up to 16 bytes and making the 16th byte a zero to refer to the other computer’s redirector.
      If the computer is configured to use WINS, a second DNS search occurs if WINS fails, because the application accesses WINS by way of NetBIOS over TCP/IP, which automatically uses DNS if WINS fails.
 5.      Use name-resolution broadcasts.
 
Connectivity Issues
This section supplements the topic “Host Connectivity and Windows 95” in Chapter 10, “Windows 95 on Other Networks,” in Microsoft Windows 95 Resource Kit (page 349, U.S. edition).
Microsoft RPC for Windows 95. The Microsoft RPC facility is compatible with the Open Software Foundation (OSF) Data Communication Exchange (DCE) specification for remote procedure calls and is completely interoperable with other DCE-based RPC systems such as those for HP® and IBM AIX® systems. The RPCLT*.DLL, RPCNS4.DLL, and RPCRT4.DLL files installed with Microsoft TCP/IP provide support for DCE-compliant RPC applications.
32-bit support for Microsoft DLC. The Data Link Control (DLC) protocol is used by host terminal emulation programs to communicate directly with IBM mainframe computers, but not for general networking with Windows 95. The first tune-up pack for Windows 95 includes a 32-bit, protected-mode implementation of Microsoft DLC to support both 16-bit DLC applications that use CCB1 and Win32-based applications that use CCB2 (but not 32-bit applications created to run under OS/2). This protocol works with either token-ring or Ethernet network adapter drivers, and can also be used for connectivity to local-area printers with direct network connections, such as an HP LaserJet® 4Si printer that uses an HP JetDirect® network adapter.
 
For more information about      See

Availability of 32-bit DLC protocol      www.windows.microsoft.com
Using 16-bit Microsoft DLC      Chapter 10, “Windows 95 on Other Networks,” in Microsoft Windows 95 Resource Kit (page 350, U.S. edition)
Using RPC applications      Chapter 32, “Windows 95 Network Architecture,” in Microsoft Windows 95 Resource Kit (page 1012, U.S. edition)
Note   If your site uses applications that require a TCP/IP stack other than Microsoft TCP/IP, contact the protocol vendor for information about the availability of a Windows 95-compatible version.
More TCP/IP Troubleshooting Tips
This section provides some additional troubleshooting topics for TCP/IP and Windows 95. For basic troubleshooting information for Microsoft TCP/IP, see Chapter 12, “Network Technical Discussion,” in Microsoft Windows 95 Resource Kit (page 449, U.S. edition).
Some tips provided here recommend unbinding the TCP/IP protocol from one or more adapters or services. To unbind a protocol from an adapter, follow the instructions under the Windows 95 Help topic named “Binding an adapter to a protocol,” making sure that the related protocol or service is not checked in the list. When you need to use the Microsoft TCP/IP protocol again for a particular connection, it must be bound to the client, service, and adapter again by making sure the related boxes are checked.
Summary of Tips for Troubleshooting TCP/IP
The most common areas where some users have problems related to TCP/IP include the following:
·      Errors with ping, winipcfg, and stack initialization can occur if files exist in the Windows folder from TCP/IP-32 for Windows for Workgroups. Any TCP/IP files in the Windows folder should be deleted. (TCP/IP supporting files for Windows 95 are stored only in the Windows SYSTEM folder.)
·      By default, TCP/IP uses DHCP for automatic configuration of IP-related settings. The user must manually configure correct IP address, subnet mask, and default gateway for TCP/IP to work.
·      DNS and WINS settings are global for all adapters. If a user enters information for DNS servers or WINS servers for any adapter in the Network option in Control Panel (including the Dial-Up Adapter), these settings will be used for all name resolution on the computer. This problem is corrected by removing erroneous entries and then entering correct DNS and WINS settings in Control Panel.
·      Name resolution problems can occur when using PPP to connect to the Internet while a network adapter is connected to a private IP network. If simultaneous connections are required, this problem can be resolved by configuring the routing table using the route command, as described earlier in this paper.
·      Each Dial-Up Networking connection can be configured with unique IP settings, but all configuration changes should be made for the particular connection in the Dial-Up folder in My Computer, not using the Network option in Control Panel.
 
Resolving TCP/IP-related errors after upgrading from Windows for Workgroups.
The following errors might occur when trying to use TCP/IP utilities and services after upgrading from Windows for workgroups:
·      A general-protection fault with a blue screen appears after running winipcfg.
·      The ping command reports error 10043, “Stack not initialized.”
·      The IP address cannot be configured when using dialing in to a PPP server.
 
These kinds of errors occur if old Windows for Workgroups TCP/IP-32 files are in the Windows folder after Windows 95 is installed. This could occur if a user mistakenly attempts to install the TCP/IP-32 files under Windows 95 when Microsoft TCP/IP is already installed. All files for Microsoft TCP/IP under Windows 95 are installed in the Windows SYSTEM folder.
To resolve “Stack Not Initialized” errors
·      Any of the following files should be deleted from the main Windows folder if they appear there:


vip.386vdhcp.386      vnbt.386vtcp.386      vtdi.386
 
Checking Microsoft TCP/IP device drivers.
The following device VxDs are provided for Microsoft TCP/IP and should be present on the computer in the Windows SYSTEM folder. If any of these files are missing, remove Microsoft TCP/IP in the Network option in Control Panel, and then reinstall it.
 
Filename      Description

icmp.dll      Provides Windows Sockets support for ping.
vdhcp.386      Provides the DHCP and WINS protocols. This file uses the 32-bit Windows Sockets interface.
vip.386      Provides the Internet Protocol (IP), Internet Control Message Protocol (ICMP), and Address Resolution Protocol (ARP).
vnbt.386      Provides support for NetBIOS over TCP/IP. Used by NetBIOS applications (such as Client for Microsoft Networks) to access NetBIOS over TCP/IP services, including name, session, and datagram services. (Notice that support for NetBIOS over TCP/IP does not involve NetBIOS encapsulation in any packets.)
vtcp.386      Provides the TCP and UDP protocols over IP.
vtdi.386      Provides support to TCP for TDI applications.
wsock.vxd, afvxd.vxd      Provide Windows Sockets-based access to TCP or UDP for sockets. The related DLL and helper files are WSHTCP.VXD and WSOCK32.DLL.
rpclt*.dll, rpcns4.dll, rpcrt4.dll      Provide support for DCE-compliant remote procedure call (RPC). These files are required to support RPC applications.
Checking configuration problems in TCP/IP properties.
If a DHCP server is not available on the network, make sure that the box named Obtain An IP Address Automatically is not checked in the TCP/IP properties.
Make sure appropriate options are checked for WINS and DNS name resolution:
·      Either the Enable WINS or Obtain WINS From DHCP option must be checked for name resolution using WINS.
·      The Enable DNS option must be checked if DNS or the HOSTS file is used for name resolution. This setting must also be checked to ensure NetBIOS name resolution for Windows Sockets applications.
 
Resetting warnings for DHCP configuration.
By default, Microsoft TCP/IP is configured to use the setting named Obtain An IP Address Automatically, which enables DHCP configuration. This can cause problems for users who do not have a DHCP server available on the network. If a user does not specify an IP address and subnet mask and does not have a DHCP server, the next time Windows 95 is started, the following error message appears.
If the user selects No in this message, DHCP error messages will no longer appear. However, because there is no DHCP server on the network, the computer will not be configured for an IP address, subnet mask, and default gateway, and therefore will not have any TCP/IP connectivity.
To enable this message to display again (if the user erroneously chose No in the message shown earlier), change the value of the entry named PopupValue to 0 in the following Registry key:
 
Hkey_Local_Machine\System\CurrentControlSet\Services\VXD\DHCP

 
Checking configuration information from DHCP.
Always confirm that the user is using DHCP before accepting the WINIPCFG information as valid. The DHCP-provided IP configuration settings are stored in binary form in the registry. The WINIPCFG utility merely reads and displays the contents of registry. If a user enabled DHCP and then disabled it, and then manually entered an IP address configuration, running WINIPCFG will still show the registry contents and, hence, the old IP address information obtained through DHCP rather than the current manually configured IP address.
Note   The version of Microsoft TCP/IP-32 provided for Windows for Workgroups stored DHCP information in the DHCP.BIN file in the computer’s Windows folder. After upgrading a Windows for Workgroups computer to Windows 95, this file might still be present, but it is no longer used by Microsoft TCP/IP and can be deleted.
Checking configuration information without DHCP.
For a Windows 95 computer that is not using DHCP, always get the IP configuration information from the Network option in Control Panel.
If you can connect to the computer remotely, you can check the TCP/IP settings in the following Registry key, as described on page 4 in this paper:
 
Hkey_Local_Machine\System\CurrentControlSet\Services\Class\netTrans\000n

 
where 000n represents the key for the Microsoft TCP/IP protocol.
Avoiding slow timeouts while attempting to connect to a nonexistent computer.
When you are using a program such as System Monitor or Registry Editor that uses Remote Registry services, if you try to connect to a computer that does not exist on the network, it may take several minutes before a response indicates that the remote computer cannot be located. This situation occurs with the following configuration:
·      The computer uses a physical LAN connection
·      Windows 95 is configured for Microsoft Remote Registry services
·      Dial-Up Networking is installed
·      The TCP/IP protocol is installed and bound to both the network adapter and the Dial-Up Adapter
 
This situation can occur because Domain Name Service (DNS) resolution is using User Datagram Protocol (UDP) to send name-resolution packets to the DNS server, which is unreachable. When this occurs, the resolver times out repeatedly, taking approximately one minute per attempt.
To avoid slow timeouts when using Remote Registry services
·      Unbind the Microsoft TCP/IP protocol in the properties for the network adapter while using dial-up connections. Conversely, unbind TCP/IP from the Dial-up Adapter while using local network connections for Remote Registry administration.
      – Or –
      Disable DNS name resolution on the source computer.
 
Microsoft TCP/IP Registry Entries
Configuration settings for Microsoft TCP/IP are stored in the Registry as part of the protocol installation process. If DHCP is used on the network, configuration information can also be provided by the DHCP client service. DHCP-provided information is stored in the Registry in binary format and cannot be altered by editing it. However, static information can be entered in the Registry, which overrides DHCP default values.
Microsoft TCP/IP should perform correctly and efficiently using the automatic settings defined during installation, because the optimum default values for most situations have been defined for TCP/IP under Windows 95.
In rare cases, for particular installations, alternate values might need to be defined in the Registry for some parameters. This section describes additional Registry settings that can be modified for Microsoft TCP/IP. Other TCP/IP settings should be changed only by using the Network option in Control Panel.
Caution   Using Registry Editor incorrectly can cause serious, system-wide problems that might require reinstalling Windows 95.
Any manual changes to the Windows 95 Registry are made at your own risk. Changing Registry parameters for TCP/IP (or other system settings) without careful consideration and testing can adversely affect system performance. Microsoft does not recommend changing Registry settings manually under most circumstances, because Microsoft TCP/IP for Windows 95 is almost entirely self tuning.
Each parameter must be added to the correct Registry key and using the correct value type, as described in the following sections. For information about how to use Registry Editor to add entries to the Registry, see Chapter 33, “Windows 95 Registry,” in Microsoft Windows 95 Resource Kit.
TCP/IP Registry Entries in the MSTCP Subkey
The entries described here must be added to the following Registry key:
 
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP

 
ArpAlwaysSourceRoute
Value Type: String
Valid Range: 0 or 1 (false or true)
Default: 0
If this parameter is set to 1, then TCP/IP transmits ARP queries with source routing enabled on token-ring networks. By default, Microsoft TCP/IP transmits ARP queries without source routing first and retries with source routing enabled if no reply was received.
BroadcastAddress
Value type: Binary (four-byte, little-endian encoded IP address)
Valid range: 0 – 0xFFFFFFFF
Default: The “ones” broadcast address for each network (based on the IP address and the subnet mask)
Forces NetBIOS over TCP/IP to use a specific address for all broadcast name-related packets. By default, the protocol uses the ones-broadcast address appropriate for each network — that is, for a network of 11.101.0.0 with a subnet mask of 255.255.0.0, the subnet broadcast address would be 11.101.255.255. This parameter can be set, for example, if the network uses the zeros-broadcast address, where the appropriate subnet broadcast address for the previous example would be 11.101.0.0, so the value for this parameter would be 0x0b650000. This parameter is global and is used on all subnets to which Microsoft TCP/IP is bound.
BcastNameQueryCount
Value type: String (integer)
Valid range: 1 – 7
Default: 3
Specifies the number of times the system will retry NetBIOS name query broadcasts for a give name without receiving a response.
BcastQueryTimeout
Value type: String (milliseconds)
Valid range: 100 – 0xFFFFFFFF
Default: 750 decimal (0x2ee hex)
Specifies the period of time to wait between successive name query broadcasts for the same name.
BSDUrgent
(Entry name is TcpUseRFC1122UrgentPointer in Windows NT Registry)
Value type: String
Valid range: 0 or 1 (false or true)
Default: 1
If this value is 1, it specifies that Microsoft TCP/IP is to treat urgent data the way some UNIX systems do (with a maximum of 1 byte of urgent data, for example). If this value is 0, it specifies that TCP is to handle urgent data using the BSD mode, as specified by RFC 1122. The two mechanisms interpret the urgent pointer in the TCP header and the length of the urgent data differently, and are not interoperable. Microsoft TCP/IP in both Windows NT and Windows 95 uses the BSD mode by default.
CacheTimeout
Value type: String (milliseconds)
Valid range: 60000 – 0xFFFFFFFF
Default: 360000 milliseconds (6 minutes)
Specifies how long NetBIOS names are cached in the remote name table. You might want to lengthen this time to decrease name-resolution traffic on a stable network where computer names, locations, and addresses do not change often.
DeadGWDetect
Value type: String
Valid range: 0 or 1 (false or true)
Default: 1
Specifies whether Microsoft TCP/IP will use Dead Gateway Detection. When this value is 1, TCP will ask IP to change to a backup gateway if it retransmits a segment several times without receiving a response. Backup gateways are defined in the Gateway settings for Microsoft TCP/IP properties.
DefaultRcvWindow
Value type: String (16-bit number of bytes)
Valid range: 0 – 0xFFFF
Default: The smaller of 0xFFFF, or the larger of four times the maximum TCP data size on the network, or 8192 rounded up to an even multiple of the network TCP data size; for Ethernet, the default is 8760
Specifies the maximum receive window advertised by TCP. The receive window specifies the number of bytes a sender can transmit without receiving an acknowledgment. Usually, setting a larger size for this value will improve performance on networks with high (delay * bandwidth). For the greatest efficiency, the receive window should be an even multiple of the TCP Maximum Segment Size (MSS), which is negotiated during connection setup, in order to increase the percentage of full-sized TCP segments used during bulk data transmission.
DefaultTOS
Value type: String
Valid range: 0 – 255
Default: 0
Specifies the default Type Of Service (TOS) value set in the header of outgoing IP packets. Values are defined in RFC 791.
DefaultTTL
Value type: String (8-bit number)
Valid range: 1 – 255
Default: 32
Specifies the default Time To Live (TTL) value set in the header of outgoing IP packets. This TTL value determines the maximum amount of time an IP packet can live on the network without reaching its destination. This is effectively a limit on the number of routers that an IP packet can pass through before being discarded.
EnableProxy
Value type: String
Valid range: 0 or 1 (false or true)
Default: 0
Specifies whether this computer is a WINS proxy agent. A proxy name server answers broadcast queries for names that it has resolved through WINS, which allows a network with workstations using b-node name resolution to connect to servers registered with WINS on other subnets.
EnableProxyRegCheck
Value type: String
Valid range: 0 or 1 (false or true)
Default: 0
Specifies whether the proxy name server will send a negative response to a broadcast name registration if the name is already registered with WINS or is in the proxy’s local name cache with a different IP address. The hazard of enabling this feature is that it prevents a system from changing its IP address as long as WINS has a mapping for the name. For this reason, it is disabled by default. This setting is only used if EnableProxy=1.
IGMPLevel
Value type: String
Valid range: 0, 1, or 2
Default: 2
Specifies the level of support allowed for IP multicasting, corresponding to the levels in RFC 1112. At level 0, the system provides no multicast support. At level 1, the system can only send IP multicast packets. At level 2, the system can send IP multicast packets and fully participate in the Internet Group Management Protocol to receive multicast packets.
For details about IP multicasting with Microsoft TCP/IP, see the Microsoft white paper titled Microsoft Windows NT 3.5 and 3.51 TCP/IP Protocol Stack and Services: Implementation Details.
InitialRefreshT.O.
(Entry name is InitialRefreshTimeout in Windows NT Registry)
Value type: String (milliseconds)
Valid range: 960000 – 0xFFFFFFFF (about 16 minutes to 50 days)
Default: 960000 milliseconds (16 minutes)
Specifies the interval over which to contact a WINS name server to refresh the name. The protocol driver tries to contact the WINS server at one-eighth of this time interval when it first registers names. When it receives a successful registration response, that response will contain the new refresh interval to use.
For information about the WINS registry and renewal processes, see Microsoft Windows NT Server 3.5 TCP/IP or Windows NT Networking Guide (v. 2 in Microsoft Windows NT 3.5 Resource Kit).
KeepAliveInterval
Value type: String (milliseconds)
Valid range: 1 – 0xFFFFFFFF
Default: 1000 (1 second)
Specifies the interval for keepalive retransmissions until a response is received. Once a response is received, the next keepalive transmission occurs after the value of KeepAliveTime has expired. Once the KeepAliveTime value has expired, keepalive transmissions are sent every KeepAliveInterval milliseconds until a response is received, up to a maximum of MaxDataRetries before the connection is aborted.
KeepAliveTime
Value type: String (milliseconds)
Valid range: 1 – 0xFFFFFFFF
Default: 7200000 (2 hours)
Specifies how often TCP attempts to verify that an idle connection is still intact by sending a keepalive packet, if keepalives are enabled on a connection. If the remote system is still reachable and functioning, it will acknowledge the keepalive transmission, Keepalive packets are not sent by default; this feature can be enabled on a connection by an application.
LmhostFile
Value type: String
Valid range: valid path and filename
Default: c:\windows\lmhosts
Specifies the path to the LMHOSTS file. This value must be defined for LMHOSTS to be used for NetBIOS name resolution on Windows 95.
LmhostsTimeout
Value type: String (milliseconds)
Valid range: 1000 – 0xFFFFFFFF
Default: 10000 (10 seconds)
Specifies the period of time the system will wait before timing out when seeking LMHOSTS and DNS for name resolution.
MaxConnections
(Entry name is TcpNumConnections in Windows NT Registry)
Value type: Binary (32-bit number)
Valid range: Based on memory constraints
Default: 100
Specifies the maximum number of connections that TCP can have open simultaneously.
MaxConnectRetries
(Entry name is TcpMaxConnectRetransmissions in Windows NT Registry)
Value type: Binary (32-bit number)
Valid range: 0 – 0xFFFFFFFF
Default: 3
Specifies the number of times that TCP will retransmit a connect request (SYN) before giving up. The initial retransmission timeout is 3 seconds, and it is doubled with each successive retransmission in a given connect attempt.
MaxDgramBuffering
Value type: String (number of bytes)
Valid range: 0 - 0xFFFFFFFF
Default: 0x20000 (128 Kb)
Specifies the maximum amount of memory that the NetBIOS over TCP/IP driver will dynamically allocate for all outstanding datagram sends. Once this limit is reached, further sends will fail due to insufficient resources.
MaxDataRetries
(Entry name is TcpMaxDataRetransmissions in Windows NT Registry)
Value type: Binary (32-bit number)
Valid range: 0 – 0xFFFFFFFF
Default: 5
Specifies the maximum number of times that TCP will retransmit an individual data segment or an FIN (that is, a non-connect segment) before giving up. The retransmission timeout is doubled with each successive retransmission on a connection. The timeout is reset when responses resume. The base timeout value is determined dynamically by the measured round-trip time on the connection, so it will vary according to link conditions.
NameServerPort
Value type: String (UDP port number)
Valid range: 0 – 0xFFFF
Default: 137 decimal (89 hex)
Specifies the UDP destination port (on the WINS name server) to which to send name service packets such as queries or registrations. Microsoft WINS listens on port 0x89. NetBIOS name servers from other vendors might listen on different ports.
NameSrvQueryCount
Value type: String (integer)
Valid range: 0 – 0xFFFF
Default: 3
Specifies the number of times TCP/IP will try to contact the WINS server for NetBIOS name resolution without receiving a response.
NameSrvQueryTimeout
Value type: String (milliseconds)
Valid range: 100– 0xFFFFFFFF
Default: 1500 (1.5 seconds)
Specifies how long TCP/IP waits between successive name queries to the WINS server for a particular name query before timing out.
NameTableSize
Value type: String (integer)
Valid range: 1 – 255
Default: 100
Specifies the maximum number of names in the NetBIOS name table.
NodeType
Value type: String
Valid range: 1, 2, 4, or 8
Default: 1 (b-node) if no value is specified or no WINS servers are configured on the network; 8 (h-node) if WINS servers are specified and NodeType is not otherwise defined in the Registry.
Specifies the mode of NetBIOS name resolution used by NetBIOS over TCP/IP, where 1 = b-node (broadcasts), 2 = p-node (point-to-point name queries to a WINS server), 4 = m-node (broadcast then query name server), and 8 = h-node (query name server, then broadcast). If DNS is enabled (which also enabled LMHOSTS in Windows 95), name resolution will also follow the mode defined by this parameter. This value can also be configured using DHCP.
PMTUBlackHoleDetect
Value type: String
Valid range: 0 or 1 (false or true)
Default: 0
Specifies whether TCP will attempt to detect “Black Hole” routers when performing Path Maximum Transmission Unit (MTU) discovery (as described for the PMTUDiscovery parameter). A black-hole router is one that does not return ICMP Destination Unreachable messages when it needs to fragment a TCP packet that has the Don’t Fragment bit set. TCP depends on receiving these messages to perform Path MTU Discovery. If this value is 1, TCP will try to send segments without the Don’t Fragment bit set when several retransmissions of a segment are not acknowledged. Setting this parameter to 1 increases the maximum number of retransmissions performed for a given segment (which can cause performance degradation if this feature is not needed).
For information on how to specify the maximum size datagram that IP can pass to a media driver, see the entry for MaxMTU on page 4 in this paper.
PMTUDiscovery
Value type: String
Valid range: 0 or 1 (false or true)
Default: 1
Specifies whether Microsoft TCP/IP will attempt to discover the largest packet size (the MTU) over the path to a remote computer. By discovering the path MTU and limiting TCP segments to this size, TCP can eliminate fragmentation along the path at routers connecting networks with different MTUs. Fragmentation can adversely affect TCP throughput and network congestion. Path MTU Discovery is performed as specified in RFC 1191. For implementation details about path PMTU discovery in Microsoft TCP/IP, see the Microsoft white paper titled Microsoft Windows NT 3.5 and 3.51 TCP/IP Protocol Stack and Services: Implementation Details.
RandomAdapter
Value type: String
Valid range: 0 or 1 (false or true)
Default: 0 (not random — return the address of adapter that received the request)
For a computer with multiple network adapters, specifies whether to respond with an IP address selected randomly from the set of addresses defined on the computer or whether to return the IP address of the adapter over which the request came. This feature can be used for load balancing by a server with two network adapters on the same network. This parameter is ignored unless SingleResponse=1.
SessionKeepAlive
Value type: String (milliseconds)
Valid range: 60000 – 0xFFFFFFFF
Default: 3600000 (1 hour)
Specifies how often to send session keepalive packets on active sessions. Setting this value to 0xFFFFFFFF disables sending keepalive packets.
SingleResponse
Value type: String
Valid range: 0 or 1 (false or true)
Default: 0
For a computer with multiple network adapters, specifies whether to send all IP addresses on a name query request from WINS. If this value is 1, the system will send one address in a name query response; if 0, it will return all the addresses of its adapters. This value must be 1 for RandomAdapter=1 to be enabled.
SessionTableSize
Value type: String (integer)
Valid range: 1 – 255
Default: 255
Specifies the maximum number of sessions in the TCP session table.
Size/Small/Medium/Large
Value type: String
Valid range: 1, 2, or 3
Default: 1 (or 3 if the WINS proxy agent is enabled)
Specifies the size of the name tables used to store local and remote NetBIOS computer names, where 1 = small (16 names), 2 = medium (128), and 3 = large (256). Usually, Small (1) is adequate. If the computer is acting as a WINS proxy agent, then the value is set automatically to Large (3) to increase the size of the name cache hash table.
WinsDownTimeout
Value type: String (time in milliseconds)
Valid range: 1000 – 0xFFFFFFFF
Default: 15,000 (15 seconds)
Determines the amount of time that NetBIOS over TCP/IP will wait before again trying to use WINS after it fails to contact any WINS server. This feature primarily allows computers that are temporarily disconnected from the network, such as laptops, to proceed through boot processing without waiting to individually timeout out each WINS name registration or query.

The following Registry entries in this key are created and maintained automatically when TCP/IP is configured using the Network option in Control Panel. The specific parameters that might appear and their default values depends on whether DHCP is enabled for automatic configuration of TCP/IP parameters.
Caution   Do not change the following values manually using Registry Editor. The following values should be maintained only by using the Network option in Control Panel. The details provided here are for informational purposes only.
EnableDNS=0
Specifies whether to use DNS for NetBIOS name resolution. To change this value, select the Enable DNS option in DNS Configuration settings in TCP/IP properties. This value can be configured by DHCP.
LANABASE=0
Specifies whether TCP/IP is the default protocol. To change this value, check the relation option in Advanced settings in TCP/IP properties.
Domain=name
Specifies the DNS domain name for the computer. This value is used by the Windows Sockets interface. To change this value, type a valid domain name in the related box in the DNS Configuration settings in TCP/IP properties.
HostName=name
Specifies the DNS host name for the computer. To change this value, type a valid host name in the related box in the DNS Configuration settings in TCP/IP properties.
NameServer=DNS nameserver IP address
Specifies a comma-separated list of valid IP addresses for the DNS name servers to be queried by Windows Sockets to resolve names. To change this value, add addresses in the DNS Server Search Order box in the DNS Configuration settings in TCP/IP properties.
NameServer1=WINS nameserver IP address
Specifies the IP address of the primary WINS server. To change this value, type a value for the relation option in WINS Configuration settings in TCP/IP properties. If this parameter is defined by changing either TCP/IP properties or this Registry entry, it overrides any related DHCP setting.
NameServer2=WINS nameserver IP address
Specifies the IP address of the WINS backup server. To change this value, type a value for the relation option in WINS Configuration settings in TCP/IP properties. If this parameter is defined by changing either TCP/IP properties or this Registry entry, it overrides any related DHCP setting.
ScopeID=dot-separated DNS name
Specifies the NetBIOS name scope for the node. If this parameter is defined, it overrides any DHCP setting that uses the same name, but a blank value is ignored. To set a null scope that overrides the DHCP settings, use the “*” value. This value can be any valid DNS domain name consisting of two dot-separated parts, and must not begin with a period. To change this value, type a value for Scope ID in the WINS Configuration settings in TCP/IP properties.
SearchList=list
Specifies a list of domain name suffixes to append to a DNS server name to be resolved using DNS if resolution fails when using the plain NameServer value. To change this value, add suffixes in the Domain Suffix Search Order box in the DNS Configuration settings in TCP/IP properties.

Notice that the Registry entries for ArpUseEtherSNAP, DatabasePath, ForwardBufferMemory, IPEnableRouter, and NumForwardPackets that can be defined in Windows NT are not valid under Windows 95.
TCP/IP Registry Entries in the NetTrans Subkey
The entries in this section must be added to the following Registry key, where n represents the particular TCP/IP-to-network adapter binding.
 
Hkey_Local_Machine\System\CurrentControlSet\Services\Class\netTrans\000n

 
MaxMTU
Value type: String (16-bit integer)
Default: size in bytes as reported by the media driver; on an Ethernet network or for a PPP dial-up connection, MaxMTU will default to 1500 (bytes)
Specifies the maximum size datagram that IP can pass to a media driver. SNAP and source routing headers (if used on the media) are not included in this value. The actual value used will be the minimum of the value specified with this parameter and the size reported by the media driver. For slow connections such as SLIP as used by some Internet service providers, this value should be 296.
ZeroBroadcast
(Entry name is UseZeroBroadcast in Windows NT Registry)
Value Type: String
Valid Range: 0 or 1 (false or true)
Default: 0
If this parameter is set to 1, then IP will use zeros-broadcasts (0.0.0.0) instead of ones-broadcasts (255.255.255.255). Most systems use ones-broadcasts, but some systems derived from BSD implementations use zeros-broadcasts. Interoperation will not work well on the same network for systems that use different broadcasts.

The following values appear in this Registry key, but should be configured only by using the Network option in Control Panel, unless you must enter values to create a multihomed configuration using a single network adapter. The actual parameters that appear in the Registry and their default values depend on whether DHCP is used to configure Microsoft TCP/IP automatically.
DefaultGateway=list of IP addresses
Value Type: String (comma-separated list of dotted-decimal IP addresses)
Valid Range: Any set of valid IP addresses
Default: None
Specifies a comma-separated list of gateways to be use to route packets not destined for a subnet to which the computer is connected directly and for which a more specific route does not exist. If this value is defined by changing the TCP/IP properties or this Registry entry, it overrides the related DHCP setting. To change this value, add addresses in the Installed Gateways box in the Gateway settings in TCP/IP properties.
IPAddress
Value type: String (comma-separated list of dotted-decimal IP addresses
Valid range: Any set of valid IP addresses
Default: None
Specifies the IP address for each instance of TCP/IP bound to a particular network adapter. If the first address in the list is 0.0.0.0, then the primary interface on the network adapter will be configured using DHCP. A system with more than one IP interface for an adapter is called “logically multihomed.” A valid value for IPMask must also be defined for each entry in this list. To change this value for a network adapter that is not multihomed, type an address in the IP Address settings in TCP/IP properties.
IPMask=list of subnet mask
Value type: String (comma-separated list of dotted decimal IP addresses)
Valid range: Any set of valid IP addresses.
Default: None
Specifies the subnet mask to be used for each instance of TCP/IP bound to a particular network adapter. If the first mask in the list is 0.0.0.0, then the primary interface on the adapter will be configured using DHCP. There must be a valid subnet mask value in the this parameter for each IP address specified in the IPAddress parameter. To change this value for a network adapter that is not multihomed, type a subnet mask value in the IP Address settings in TCP/IP properties.

The following values are defined during installation and should not be modified in the Registry:
DeviceVxDs=vtdi.386,vip.386,vtcp.386,vdhcp.386,vnbt.386
DevLoader=ndis
DriverDesc=TCP/IP
InfPath=NETTRANS.INF
TCP/IP Registry Entries in the MSTCP\ServiceProvider Subkey
This section describes variables for parameters that appear in the following Registry key:
  parameter indicates that TCP/IP is a name service provider, and
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD
    \MSTCP\ServiceProvider

 
The Class and ProviderPath values are used by the service resolution and registry APIs in Windows Sockets. The Class its binary value (8) should not be changed. The ProviderPath parameter is a string that defines the location and filename for the 32-bit Windows Sockets DLL (the default is %windir%\system\wsock32.dll).
The following keys describe the order used to resolve host names. A lower number sets a higher priority for name resolution. These settings are binary values used for 16-bit Windows Sockets applications that use the GetHostByName() and GetAddressByName() APIs, which need to rely on the resolvers that are expected to take the least time. The numbers shown here indicate the default values specified in Windows 95. To change the order used for name resolution, adjust the related priority values.
LocalPriority = 0x1F3 (499)
HostsPriority = 0x1F4 (500)
DNSPriority = 0x7D0 (2000)
NetbtPriority = 0x7D1 (2001)
Note   For these parameters, values under 1000 (decimal) are considered fast name resolution providers, so settings values under 1000 might have undesirable effects for network-based resolution mechanisms related to DNSPriority and NetbtPriority.
TCP/IP Registry Entries in the MSTCP\Parameters\Winsock Subkey
Windows 95 includes two helper files for Windows Sockets, WSHTCP.VXD and WSOCK32.DLL. In addition to the parameters in this subkey, additional settings for the kernel-mode driver that supports Windows Sockets applications are defined in another Registry key (AFVXD). None of these settings should be changed manually.
HelperDllName= %windir%\system\wsock32.dll
MaxSockAddrLength=binary value
MinSockAddrLength=binary value
Microsoft Information Access
 
Online or support service      Access procedures

The Microsoft Network      From the Microsoft menu, select Windows 95, and click WinNews. Or access the Microsoft Knowledge Base.
America Online®      Use the keyword winnews
CompuServe®      Type go winnews. To access the Microsoft Knowledge Base for product information, type go mskb
FTP on the Internet      Type ftp://ftp.microsoft.com/PerOpSys/Win_News
Genie™      Download files from WinNews area in Windows 95 RTC.
Prodigy™      Type jump winnews
World Wide Web (Internet)      Type http://www.windows.microsoft.com
Microsoft FastTips for Windows 95      Call (800) 936-4200, available seven days a week, 24 hours a day, including holidays.
Microsoft Download Service (MSDL)      Contact by modem at (206) 936-6735, seven days a week, 24 hours a day, including holidays.
Microsoft Solution Provider for installation and support      Call Microsoft at (800) SOLPROV (or (800) 765-7768) for a referral.
Microsoft Text Telephone (TT/TDD) services      Call (206) 635-4948, between 6:00 A.M. and 6:00 P.M. Pacific time, Monday through Friday.
Microsoft Product Support Services       Standard support for non-networking issues: Call (206) 637-7098 between 6:00 A.M. and 6:00 P.M. Pacific time, Monday through Friday. After 90-day free period, call (900) 555-2000 or (800) 936-5700. For support outside the U.S., contact your local Microsoft subsidiary.Priority support, including networking issues: Priority telephone access to Windows 95 support engineers 24 hours a day, 7 days a week, excluding holidays, in the U.S. In Canada, the hours are from 6:00 A.M. to midnight, 7 days a week, excluding holidays. Priority support phone numbers and availability can be found in the Windows 95 User Guide or Readme file. Networking issues are defined as setup, configuration, or usage of Windows 95 in a networked environment. This includes, but is not restricted to the following: Setting up a computer to be used in a networked environment, network administration, dialing in to a computer, connecting to the Internet using a service provider, and using e-mail or fax from within Windows 95.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, MS-DOS, Visual Basic, Win32, Windows, and the Windows logo are registered trademarks and Windows NT and the Start logo are trademarks of Microsoft Corporation.
Acknowledgments: Diagrams describing name resolution with NetBIOS over TCP/IP were created by Prakash Narasimhamurthy, Microsoft Consulting Services. Material related to security issues originally appeared in another form in Windows NT Networking Guide (volume 2 in Microsoft Windows NT 3.5 Resource Kit, Microsoft Press, 1995).
0995
Part No. 098-61902

 

I need a bit of clarification:
1-What do I need to do to add the second connection?  My ISP uses a dynamic IP address, and for the peer to peer I will need to assign static IP's.  How do I set this up so that the new connection comes in to use only when I dial in to this other computer?  I want to make sure that my e-mail/browser etc. still work with my ISP, and that they still access the log in on demand. (Log in to the other machine will be manual).  Can I just create a second instance of TCP/IP protocol and assign IP and Submask with static IP option?  Will this mess up the internet connection?  

2. Any suggestions RE IP and Submask?  I understand there is a small block of numbers available for "private" use.  As previously mentioned, the two connections will not be in use simultaneously, therefore I really don't care what numbers I use as long as it doesn't create problems.  For this exercise I will need 2 sets of IP's.

3. What do I put in for default gateway?

4. On the WINS Server tab what options do I specify?  I would assume disable WINS and DCHP?  Will it allow both disabled?  Or should I do something else?

Thanks for your help

I need a bit of clarification:
1-What do I need to do to add the second connection?  My ISP uses a dynamic IP address, and for the peer to peer I will need to assign static IP's.  How do I set this up so that the new connection comes in to use only when I dial in to this other computer?  I want to make sure that my e-mail/browser etc. still work with my ISP, and that they still access the log in on demand. (Log in to the other machine will be manual).  Can I just create a second instance of TCP/IP protocol and assign IP and Submask with static IP option?  Will this mess up the internet connection?  

2. Any suggestions RE IP and Submask?  I understand there is a small block of numbers available for "private" use.  As previously mentioned, the two connections will not be in use simultaneously, therefore I really don't care what numbers I use as long as it doesn't create problems.  For this exercise I will need 2 sets of IP's.

3. What do I put in for default gateway?

4. On the WINS Server tab what options do I specify?  I would assume disable WINS and DCHP?  Will it allow both disabled?  Or should I do something else?

Thanks for your help

See Above

To elaborate on my answer.
Simply create another dialup section for this second peer-to-peer connection under dialup networking.
Configure it with the telephone no etc.
Under its properties section configure to use netbeui and log onto a network. Ensure PPP for win95 is chosen.
Ensure your netbeui protocol is also installed for your dialup adapter under networking in the control panel.
This is all there is to it.