5.  Network setup  

      4.4BSD provides support for the standard Internet protocols IP, ICMP, TCP, and UDP. These protocols may be used on top of a variety of hardware devices ranging from serial lines to local area network controllers for the Ethernet. Network services are split between the kernel (communication protocols) and user programs (user services such as TELNET and FTP). This section describes how to configure your system to use the Internet networking support. 4.4BSD also supports the Xerox Network Systems (NS) protocols. IDP and SPP are implemented in the kernel, and other protocols such as Courier run at the user level. 4.4BSD provides some support for the ISO OSI protocols CLNP TP4, and ESIS. User level process complete the application protocols such as X.400 and X.500.

5.1.  System configuration  

      To configure the kernel to include the Internet communication protocols, define the INET option. Xerox NS support is enabled with the NS option. ISO OSI support is enabled with the ISO option. In either case, include the pseudo-devices ``pty'', and ``loop'' in your machine's configuration file. The ``pty'' pseudo-device forces the pseudo terminal device driver to be configured into the system, see pty(4), while the ``loop'' pseudo-device forces inclusion of the software loopback interface driver. The loop driver is used in network testing and also by the error logging system.

      If you are planning to use the Internet network facilities on a 10Mb/s Ethernet, the pseudo-device ``ether'' should also be included in the configuration; this forces inclusion of the Address Resolution Protocol module used in mapping between 48-bit Ethernet and 32-bit Internet addresses.

      Before configuring the appropriate networking hardware, you should consult the manual pages in section 4 of the Programmer's Manual selecting the appropriate interfaces for your architecture.

      All network interface drivers including the loopback interface, require that their host address(es) be defined at boot time. This is done with ifconfig(8) commands included in the /etc/netstart file. Interfaces that are able to dynamically deduce the host part of an address may check that the host part of the address is correct. The manual page for each network interface describes the method used to establish a host's address. Ifconfig(8) can also be used to set options for the interface at boot time. Options are set independently for each interface, and apply to all packets sent using that interface. Alternatively, translations for such hosts may be set in advance or ``published'' by a 4.4BSD host by use of the arp(8) command. Note that the use of trailer link-level is now negotiated between 4.4BSD hosts using ARP, and it is thus no longer necessary to disable the use of trailers with ifconfig.

      The OSI equivalent to ARP is ESIS (End System to Intermediate System Routing Protocol); running this protocol is mandatory, however one can manually add translations for machines that do not participate by use of the route(8) command. Additional information is provided in the manual page describing ESIS(4).

      To use the pseudo terminals just configured, device entries must be created in the /dev directory. To create 32 pseudo terminals (plenty, unless you have a heavy network load) execute the following commands.

# cd /dev
# MAKEDEV pty0 pty1
More pseudo terminals may be made by specifying pty2, pty3, etc. The kernel normally includes support for 32 pseudo terminals unless the configuration file specifies a different number. Each pseudo terminal really consists of two files in /dev: a master and a slave. The master pseudo terminal file is named /dev/ptyp?, while the slave side is /dev/ttyp?. Pseudo terminals are also used by several programs not related to the network. In addition to creating the pseudo terminals, be sure to install them in the /etc/ttys file (with a `none' in the second column so no getty is started).

5.2.  Local subnets  

      In 4.4BSD the Internet support includes the notion of ``subnets''. This is a mechanism by which multiple local networks may appears as a single Internet network to off-site hosts. Subnetworks are useful because they allow a site to hide their local topology, requiring only a single route in external gateways; it also means that local network numbers may be locally administered. The standard describing this change in Internet addressing is RFC-950.

      To set up local subnets one must first decide how the available address space (the Internet ``host part'' of the 32-bit address) is to be partitioned. Sites with a class A network number have a 24-bit host address space with which to work, sites with a class B network number have a 16-bit host address space, while sites with a class C network number have an 8-bit host address space[note 6] . To define local subnets you must steal some bits from the local host address space for use in extending the network portion of the Internet address. This reinterpretation of Internet addresses is done only for local networks; i.e. it is not visible to hosts off-site. For example, if your site has a class B network number, hosts on this network have an Internet address that contains the network number, 16 bits, and the host number, another 16 bits. To define 254 local subnets, each possessing at most 255 hosts, 8 bits may be taken from the local part. (The use of subnets 0 and all-1's, 255 in this example, is discouraged to avoid confusion about broadcast addresses.) These new network numbers are then constructed by concatenating the original 16-bit network number with the extra 8 bits containing the local subnet number.

      The existence of local subnets is communicated to the system at the time a network interface is configured with the netmask option to the ifconfig program. A ``network mask'' is specified to define the portion of the Internet address that is to be considered the network part for that network. This mask normally contains the bits corresponding to the standard network part as well as the portion of the local part that has been assigned to subnets. If no mask is specified when the address is set, it will be set according to the class of the network. For example, at Berkeley (class B network 128.32) 8 bits of the local part have been reserved for defining subnets; consequently the /etc/netstart file contains lines of the form

/sbin/ifconfig le0 netmask 0xffffff00
This specifies that for interface ``le0'', the upper 24 bits of the Internet address should be used in calculating network numbers (netmask 0xffffff00), and the interface's Internet address is ``'' (host 7 on network 128.32.1). Hosts m on sub-network n of this network would then have addresses of the form ``128.32.n.m''; for example, host 99 on network 129 would have an address ``''. For hosts with multiple interfaces, the network mask should be set for each interface, although in practice only the mask of the first interface on each network is really used.

5.3.  Internet broadcast addresses  

      The address defined as the broadcast address for Internet networks according to RFC-919 is the address with a host part of all 1's. The address used by 4.2BSD was the address with a host part of 0. 4.4BSD uses the standard broadcast address (all 1's) by default, but allows the broadcast address to be set (with ifconfig) for each interface. This allows networks consisting of both 4.2BSD, 4.3BSD and 4.4BSD hosts to coexist while the upgrade process proceeds. In the presence of subnets, the broadcast address uses the subnet field as for normal host addresses, with the remaining host part set to 1's (or 0's, on a network that has not yet been converted). 4.4BSD hosts recognize and accept packets sent to the logical-network broadcast address as well as those sent to the subnet broadcast address, and when using an all-1's broadcast, also recognize and receive packets sent to host 0 as a broadcast.

5.4.  Routing  

      If your environment allows access to networks not directly attached to your host you will need to set up routing information to allow packets to be properly routed. Two schemes are supported by the system. The first scheme employs a routing table management daemon. Optimally, you should use the routing daemon gated available from Cornell university. We use it on our systems and it works well, especially for multi-homed hosts using Serial Line IP (SLIP). Unfortunately, we were not able to obtain permission to include it on 4.4BSD.

      If you do not wish to or cannot obtain gated, the distribution does include routed(8) to maintain the system routing tables. The routing daemon uses a variant of the Xerox Routing Information Protocol to maintain up to date routing tables in a cluster of local area networks. By using the /etc/gateways file, the routing daemon can also be used to initialize static routes to distant networks (see the next section for further discussion). When the routing daemon is started up (usually from /etc/rc) it reads /etc/gateways if it exists and installs those routes defined there, then broadcasts on each local network to which the host is attached to find other instances of the routing daemon. If any responses are received, the routing daemons cooperate in maintaining a globally consistent view of routing in the local environment. This view can be extended to include remote sites also running the routing daemon by setting up suitable entries in /etc/gateways; consult routed(8) for a more thorough discussion.

      The second approach is to define a default or wildcard route to a smart gateway and depend on the gateway to provide ICMP routing redirect information to dynamically create a routing data base. This is done by adding an entry of the form

/sbin/route add default smart-gateway 1
to /etc/netstart; see route(8) for more information. The default route will be used by the system as a ``last resort'' in routing packets to their destination. Assuming the gateway to which packets are directed is able to generate the proper routing redirect messages, the system will then add routing table entries based on the information supplied. This approach has certain advantages over the routing daemon, but is unsuitable in an environment where there are only bridges (i.e. pseudo gateways that, for instance, do not generate routing redirect messages). Further, if the smart gateway goes down there is no alternative, save manual alteration of the routing table entry, to maintaining service.

      The system always listens, and processes, routing redirect information, so it is possible to combine both of the above facilities. For example, the routing table management process might be used to maintain up to date information about routes to geographically local networks, while employing the wildcard routing techniques for ``distant'' networks. The netstat(1) program may be used to display routing table contents as well as various routing oriented statistics. For example,

# netstat -r
will display the contents of the routing tables, while
# netstat -r -s
will show the number of routing table entries dynamically created as a result of routing redirect messages, etc.

5.5.  Use of 4.4BSD machines as gateways  

      Several changes have been made in 4.4BSD in the area of gateway support (or packet forwarding, if one prefers). A new configuration option, GATEWAY, is used when configuring a machine to be used as a gateway. This option increases the size of the routing hash tables in the kernel. Unless configured with that option, hosts with only a single non-loopback interface never attempt to forward packets or to respond with ICMP error messages to misdirected packets. This change reduces the problems that may occur when different hosts on a network disagree on the network number or broadcast address. Another change is that 4.4BSD machines that forward packets back through the same interface on which they arrived will send ICMP redirects to the source host if it is on the same network. This improves the interaction of 4.4BSD gateways with hosts that configure their routes via default gateways and redirects. The generation of redirects may be disabled with the configuration option IPSENDREDIRECTS=0 or while the system is running by using the command:

sysctl -w net.inet.ip.redirect=0
in environments where it may cause difficulties.

5.6.  Network databases  

      Several data files are used by the network library routines and server programs. Most of these files are host independent and updated only rarely.

File               Manual reference   Use
/etc/hosts         hosts(5)           local host names
/etc/networks      networks(5)        network names
/etc/services      services(5)        list of known services
/etc/protocols     protocols(5)       protocol names
/etc/hosts.equiv   rshd(8)            list of ``trusted'' hosts
/etc/netstart      rc(8)              command script for initializing network
/etc/rc            rc(8)              command script for starting standard servers
/etc/rc.local      rc(8)              command script for starting local servers
/etc/ftpusers      ftpd(8)            list of ``unwelcome'' ftp users
/etc/hosts.lpd     lpd(8)             list of hosts allowed to access printers
/etc/inetd.conf    inetd(8)           list of servers started by inetd
The files distributed are set up for Internet hosts. Local networks and hosts should be added to describe the local configuration; the Berkeley entries may serve as examples (see also the section on /etc/hosts). Network numbers will have to be chosen for each Ethernet. For sites connected to the Internet, the normal channels should be used for allocation of network numbers (contact hostmaster@SRI-NIC.ARPA). For other sites, these could be chosen more or less arbitrarily, but it is generally better to request official numbers to avoid conversion if a connection to the Internet (or others on the Internet) is ever established.

5.6.1.  Network servers  

      Most network servers are automatically started up at boot time by the command file /etc/rc or by the Internet daemon (see below). These include the following:

Program                Server                            Started by
/usr/sbin/syslogd      error logging server              /etc/rc
/usr/sbin/named        Internet name server              /etc/rc
/sbin/routed           routing table management daemon   /etc/rc
/usr/sbin/rwhod        system status daemon              /etc/rc
/usr/sbin/timed        time synchronization daemon       /etc/rc
/usr/sbin/sendmail     SMTP server                       /etc/rc
/usr/libexec/rshd      shell server                      inetd
/usr/libexec/rexecd    exec server                       inetd
/usr/libexec/rlogind   login server                      inetd
/usr/libexec/telnetd   TELNET server                     inetd
/usr/libexec/ftpd      FTP server                        inetd
/usr/libexec/fingerd   Finger server                     inetd
/usr/libexec/tftpd     TFTP server                       inetd
Consult the manual pages and accompanying documentation (particularly for named and sendmail) for details about their operation.

      The use of routed and rwhod is controlled by shell variables set in /etc/netstart. By default, routed is used, but rwhod is not; they are enabled by setting the variables routedflags and rwhod to strings other than ``NO.'' The value of routedflags provides host-specific options to routed. For example,

would run routed -q and would not run rwhod.

      To have other network servers started as well, commands of the following sort should be placed in the site-dependent file /etc/rc.local.

if [ -f /usr/sbin/timed ]; then
	/usr/sbin/timed & echo -n ' timed'			>/dev/console

5.6.2.  Internet daemon  

      In 4.4BSD most of the servers for user-visible services are started up by a ``super server'', the Internet daemon. The Internet daemon, /usr/sbin/inetd, acts as a master server for programs specified in its configuration file, /etc/inetd.conf, listening for service requests for these servers, and starting up the appropriate program whenever a request is received. The configuration file contains lines containing a service name (as found in /etc/services), the type of socket the server expects (e.g. stream or dgram), the protocol to be used with the socket (as found in /etc/protocols), whether to wait for each server to complete before starting up another, the user name by which the server should run, the server program's name, and at most five arguments to pass to the server program. Some trivial services are implemented internally in inetd, and their servers are listed as ``internal.'' For example, an entry for the file transfer protocol server would appear as

ftp	stream	tcp	nowait	root	/usr/libexec/ftpd	ftpd
Consult inetd(8) for more detail on the format of the configuration file and the operation of the Internet daemon.

5.6.3.  The /etc/hosts.equiv file  

      The remote login and shell servers use an authentication scheme based on trusted hosts. The hosts.equiv file contains a list of hosts that are considered trusted and, under a single administrative control. When a user contacts a remote login or shell server requesting service, the client process passes the user's name and the official name of the host on which the client is located. In the simple case, if the host's name is located in hosts.equiv and the user has an account on the server's machine, then service is rendered (i.e. the user is allowed to log in, or the command is executed). Users may expand this ``equivalence'' of machines by installing a .rhosts file in their login directory. The root login is handled specially, bypassing the hosts.equiv file, and using only the /.rhosts file.

      Thus, to create a class of equivalent machines, the hosts.equiv file should contain the official names for those machines. If you are running the name server, you may omit the domain part of the host name for machines in your local domain. For example, four machines on our local network are considered trusted, so the hosts.equiv file is of the form:


5.6.4.  The /etc/ftpusers file  

      The FTP server included in the system provides support for an anonymous FTP account. Because of the inherent security problems with such a facility you should read this section carefully if you consider providing such a service.

      An anonymous account is enabled by creating a user ftp. When a client uses the anonymous account a chroot(2) system call is performed by the server to restrict the client from moving outside that part of the filesystem where the user ftp home directory is located. Because a chroot call is used, certain programs and files used by the server process must be placed in the ftp home directory. Further, one must be sure that all directories and executable images are unwritable. The following directory setup is recommended. The use of the awk commands to copy the /etc/passwd and /etc/group files are STRONGLY recommended.

# cd ~ftp
# chmod 555 .; chown ftp .; chgrp ftp .
# mkdir bin etc pub
# chown root bin etc
# chmod 555 bin etc
# chown ftp pub
# chmod 777 pub
# cd bin
# cp /bin/sh /bin/ls .
# chmod 111 sh ls
# cd ../etc
# awk -F: '{$2="*";print$1":"$2":"$3":"$4":"$5":"$6":"}' < /etc/passwd > passwd
# awk -F: '{$2="*";print$1":"$2":"}' < /etc/group > group
# chmod 444 passwd group
When local users wish to place files in the anonymous area, they must be placed in a subdirectory. In the setup here, the directory ~ftp/pub is used.

      Aside from the problems of directory modes and such, the ftp server may provide a loophole for interlopers if certain user accounts are allowed. The file /etc/ftpusers is checked on each connection. If the requested user name is located in the file, the request for service is denied. This file normally has the following names on our systems.

Accounts without passwords need not be listed in this file as the ftp server will refuse service to these users. Accounts with nonstandard shells (any not listed in /etc/shells) will also be denied access via ftp.