<chapter id="X-087-2-intro"><title>Introduction <?lb>to Networking</title>
<sect1 id="X-087-2-intro.history"><title>History</title>

<para>
<indexterm id="chit.netwks.intro"
class="startofrange"><primary>networks</primary><secondary>introduction
to</secondary></indexterm> The idea of networking is probably as old
as telecommunications itself.  Consider people living in the Stone
Age, when drums may have been used to transmit messages between
individuals. Suppose caveman A wants to invite caveman B over for a
game of hurling rocks at each other, but they live too far apart for B
to hear A banging his drum. What are A's options? He could 1) walk
over to B's place, 2) get a bigger drum, or 3) ask C, who lives
halfway between them, to forward the message. The last option is
called <emphasis>networking</emphasis>.
</para>

<para>
Of course, we have come a long way from the primitive pursuits and devices of
our forebears. Nowadays, we have computers talk to each other over vast
assemblages of wires, fiber optics, microwaves, and the like, to make an
appointment for Saturday's soccer match.<footnote id="X-087-2-FNIT01"><para>
The original spirit of which (see above) still shows on some occasions in
Europe.
</para>
</footnote>
In the following description, we will deal with the means and ways by which
this is accomplished, but leave out the wires, as well as the soccer part.
</para>

<para>
We will describe three types of networks in this guide. We will focus on
TCP/IP most heavily because it is the most popular protocol suite in use on
both Local Area Networks (LANs) and Wide Area Networks (WANs), such as the
Internet. We will also take a look at UUCP and IPX. UUCP was once commonly
used to transport news and mail messages over dialup telephone connections.
It is less common today, but is still useful in a variety of situations. The
IPX protocol is used most commonly in the Novell NetWare environment and we'll
describe how to use it<?troff .ne 7> to connect your Linux machine into a Novell network.
Each of these protocols are networking protocols and are used to carry data
between host computers. We'll discuss how they are used and introduce you to
their underlying principles.
</para>

<para>
<indexterm><primary>sites</primary></indexterm>
<indexterm><primary>hosts</primary></indexterm> We define a network as
a collection of <emphasis>hosts</emphasis> that are able to
communicate with each other, often by relying on the services of a
number of dedicated hosts that relay data between the
participants. Hosts are often computers, but need not be; one can also
think of X terminals or intelligent printers as hosts. Small
agglomerations of hosts are also called <emphasis>sites</emphasis>.
</para>

<para>
<indexterm><primary>networks</primary><secondary>protocols</secondary></indexterm>
<indexterm><primary>protocols</primary></indexterm> Communication is
impossible without some sort of language or code. In computer
networks, these languages are collectively referred to as
<emphasis>protocols</emphasis>. However, you shouldn't think of
written protocols here, but rather of the highly formalized code of
behavior observed when heads of state meet, for instance. In a very
similar fashion, the protocols used in computer networks are nothing
but very strict rules for the exchange of messages between two or more
hosts.
</para>

</sect1>

<sect1 id="X-087-2-intro.tcpip"><title>TCP/IP Networks</title>

<para>
<indexterm><primary>networks</primary><secondary>TCP/IP</secondary></indexterm>
<INDEXTERM id="chit.networks.tcp-ip"
class=startofrange><PRIMARY>TCP/IP (Transmission Control
Protocol/Internet
Protocol)</PRIMARY><SECONDARY>networks</SECONDARY></INDEXTERM>
<indexterm><primary>Local Area Networks (LANs)</primary></indexterm>
<indexterm><primary>networks</primary><secondary>Local
Area</secondary></indexterm>
<indexterm><primary>networks</primary><secondary>packet-switched</secondary></indexterm>
<indexterm><primary>packet-switched networks</primary></indexterm>
Modern networking applications require a sophisticated approach to
carrying data from one machine to another. If you are managing a Linux
machine that has many users, each of whom may wish to simultaneously
connect to remote hosts on a network, you need a way of allowing them
to share your network connection without interfering with each
other. The approach that a large number of modern networking protocols
uses is called <emphasis>packet-switching</emphasis>. A
<emphasis>packet</emphasis> is a small chunk of data that is
transferred from one machine to another across the network. The
switching occurs as the datagram is carried across each link in the
network. A packet-switched network shares a single network link among
many users by alternately sending packets from one user to another
across that link.
</para>

<para>
<INDEXTERM><PRIMARY>datagrams</PRIMARY></INDEXTERM> The solution that
Unix systems, and subsequently many non-Unix systems, have adopted is
known as TCP/IP. When talking about TCP/IP networks you will hear the
term <emphasis>datagram</emphasis>, which technically has a special
meaning but is often used interchangeably with
<emphasis>packet</emphasis>. In this section, we will have a look at
underlying concepts of the TCP/IP protocols.
</para>

<sect2 id="X-087-2-intro.tcpip.intro"><title>Introduction to TCP/IP Networks</title>

<para>
<indexterm><primary>ARPANET</primary></indexterm>
<indexterm><primary>networks</primary><secondary>ARPANET</secondary></indexterm>
TCP/IP traces its origins to a research project funded by the United States
Defense Advanced Research Projects Agency (DARPA) in 1969. The ARPANET was an
experimental network that was converted into an operational one in 1975 after
it had proven to be a success.
</para>
<?troff .Nd 7>
<para>
<indexterm><primary>networks</primary><secondary>Internet</secondary></indexterm>
<indexterm><primary>Internet</primary></indexterm>
<indexterm><primary>networks</primary><secondary>corporate</secondary></indexterm>
In 1983, the new protocol suite TCP/IP was adopted as a standard, and
all hosts on the network were required to use it.  When ARPANET
finally grew into the Internet (with ARPANET itself passing out of
existence in 1990), the use of TCP/IP had spread to networks beyond
the Internet itself. Many companies have now built corporate TCP/IP
networks, and the Internet has grown to a point at which it could
almost be considered a mainstream consumer technology. It is difficult
to read a newspaper or magazine now without seeing reference to the
Internet; almost everyone can now use it.
</para>

<para>
<indexterm><primary>Marx, Groucho</primary></indexterm>
<indexterm><primary>Groucho Marx University
(GMU)</primary></indexterm> For something concrete to look at as we
discuss TCP/IP throughout the following sections, we will consider
Groucho Marx University (GMU), situated somewhere in Fredland, as an
example.  Most departments run their own Local Area Networks, while
some share one and others run several of them. They are all
interconnected and hooked to the Internet through a single high-speed
link.
</para>

<para>
<indexterm><primary>remote</primary><secondary>login</secondary></indexterm>
Suppose your Linux box is connected to a LAN of Unix hosts at the Mathematics
department, and its name is <systemitem role="sitename">erdos</systemitem>. To
access a host at the Physics department, say
<systemitem role="sitename">quark</systemitem>,
you enter the following command:

<screen>
$ <userinput>rlogin quark.physics</userinput>
Welcome to the Physics Department at GMU
(ttyq2) login:
</screen>
</para>

<para>
<indexterm><primary>remote</primary><secondary>login</secondary><tertiary>via TCP/IP</tertiary></indexterm> 
At the prompt, you enter your login name, say
<systemitem role="userid">andres</systemitem>, and your password. You are then
given a shell<footnote id="X-087-2-FNIT02"><para>
The shell is a command-line interface to the Unix operating system. It's
similar to the DOS prompt in a Microsoft Windows environment, albeit much
more powerful.
</para>
</footnote> on <systemitem role="sitename">quark</systemitem>, to which you
can type as if you were sitting at the system's console. After you exit the
shell, you are returned to your own machine's prompt. You have just used one
of the instantaneous, interactive applications that TCP/IP provides: remote
login.
</para>

<para>
<indexterm><primary>remote</primary><secondary>login</secondary><tertiary>X Windows session</tertiary></indexterm>
<indexterm><primary>X Windows</primary></indexterm>
<indexterm><primary>DISPLAY (environment variable)</primary></indexterm> 
<indexterm><primary>environment variables</primary><secondary>DISPLAY</secondary></indexterm> 
While being logged into <systemitem role="sitename">quark</systemitem>,
you might also want to run a graphical user interface application,
like a word processing program, a graphics drawing program, or even a
World Wide Web browser. The X windows system is a fully network-aware
graphical user environment, and it is available for many different
computing systems. To tell this application that you want to have its
windows displayed on your host's screen, you have to set the
<systemitem role="keyword">DISPLAY</systemitem> environment variable:
<screen>
$ <userinput>DISPLAY=erdos.maths:0.0</userinput>
$ <userinput>export DISPLAY</userinput>
</screen>
</para>

<para>
If you now start your application, it will contact your X server instead of
<systemitem role="sitename">quark</systemitem>'s, and display all its windows
on your screen. Of course, this requires that you have X11 runnning on
<systemitem role="sitename">erdos</systemitem>. The point here is that TCP/IP
allows <systemitem role="sitename">quark</systemitem> and
<systemitem role="sitename">erdos</systemitem> to send X11 packets back and
forth to give you the illusion that you're on a single system. The network
is almost transparent here.
</para>

<para>
<indexterm><primary>NFS (Network File System)</primary><secondary>via TCP/IP</secondary></indexterm> 
Another very important application in TCP/IP networks is NFS, which
stands for <emphasis>Network File System</emphasis>. It is another
form of making the network transparent, because it basically allows
you to treat directory hierarchies from other hosts as if they
were local file systems and look like any other directories on your
host. For example, all users' home directories can be kept on a
central server machine from which all other hosts on the LAN mount
them. The effect is that users can log in to any machine and find
themselves in the same home directory. Similarly, it is possible to
share large amounts of data (such as a database, documentation or
application programs) among many hosts by maintaining one copy of
the data on a server and allowing other hosts to access it. We will
come back to NFS in <xref linkend="X-087-2-nfs">.
</para>

<para>
Of course, these are only examples of what you can do with TCP/IP networks.
The possibilities are almost limitless, and we'll introduce you to more as you
read on through the book.
</para>

<para>
We will now have a closer look at the way TCP/IP works. This information will
help you understand how and why you have to configure your machine. We will
start by examining the hardware, and slowly work our way up.
</para>

</sect2>

<sect2 id="X-087-2-intro.tcpip.history"><title>Ethernets</title>

<para>
<indexterm><primary>protocols</primary><secondary>Ethernet</secondary></indexterm>
<indexterm><primary>networks</primary><secondary>Ethernet</secondary></indexterm> 
<indexterm><primary>Local Area Networks (LANs)</primary><secondary>hardware for</secondary></indexterm> 
The most common type of LAN hardware is known as <emphasis>Ethernet</emphasis>.
In its simplest form, it consists of a single cable with hosts attached to it
through connectors, taps, or transceivers. Simple Ethernets are relatively
inexpensive to install, which together with a net transfer rate of 10, 100,
or even 1,000 Megabits per second, accounts for much of its popularity.
</para>

<para>
<indexterm><primary>Ethernet</primary><secondary>thick/thin</secondary></indexterm>
<indexterm><primary>Ethernet</primary><secondary>twisted pair</secondary></indexterm>
<indexterm><primary>thinnet</primary></indexterm>
<indexterm><primary>BNC connector</primary></indexterm>
<indexterm><primary>active hubs</primary></indexterm>
<indexterm><primary>networks</primary><secondary>thinnet</secondary></indexterm>
Ethernets come in three flavors: <emphasis>thick</emphasis>,
<emphasis>thin</emphasis>, and <emphasis>twisted pair</emphasis>.
Thin and thick Ethernet each use a coaxial cable, differing in
diameter and the way you may attach a host to this cable. Thin
Ethernet uses a T-shaped &ldquo;BNC&rdquo; connector, which you insert
into the cable and twist onto a plug on the back of your computer.
Thick Ethernet requires that you drill a small hole into the cable,
and attach a transceiver using a &ldquo;vampire tap.&rdquo; One or
more hosts can then be connected to the transceiver. Thin and thick
Ethernet cable can run for a maximum of 200 and 500 meters
respectively, and are also called 10base-2 and 10base-5. The
&ldquo;base&rdquo; refers to &ldquo;baseband modulation&rdquo; and
simply means that the data is directly fed onto the cable without any
modem. The number at the start refers to the speed in Megabits per
second, and the number at the end is the maximum length of the cable
in hundreds of metres. Twisted pair uses a cable made of two pairs of
copper wires and usually requires additional hardware known as
<emphasis>active hubs</emphasis>. Twisted pair is also known as
10base-T, the &ldquo;T&rdquo; meaning twisted pair. The 100 Megabits
per second version is known as 100base-T.
</para>

<para>
To add a host to a thin Ethernet installation, you have to disrupt
network service for at least a few minutes because you have to cut the
cable to insert the connector. Although adding a host to a thick
Ethernet system is a little complicated, it does not typically bring
down the network. Twisted pair Ethernet is even simpler. It uses a
device called a &ldquo;hub,&rdquo; which serves as an interconnection
point. You can insert and remove hosts from a hub without interrupting
any other users at all.
</para>

<para>
Many people prefer thin Ethernet for small networks because it is very
inexpensive; PC cards come for as little as US &dollar;30 (many
companies are literally throwing them out now), and cable is in the
range of a few cents per meter. However, for large-scale
installations, either thick Ethernet or twisted pair is more
appropriate. For example, the Ethernet at GMU's Mathematics Department
originally chose thick Ethernet because it is a long route that the
cable must take so traffic will not be disrupted each time a host
is added to the network. Twisted pair installations are now very
common in a variety of installations. The Hub hardware is dropping in
price and small units are now available at a price that is attractive
to even small domestic networks. Twisted pair cabling can be
significantly cheaper for large installations, and the cable itself is
much more flexible than the coaxial cables used for the other Ethernet
systems. The network administrators in GMU's mathematics department
are planning to replace the existing network with a twisted pair
network in the coming finanical year because it will bring them up to
date with current technology and will save them significant time when
installing new host computers and moving existing computers around.
</para>

<para>
<indexterm><primary>Ethernet</primary><secondary>drawbacks</secondary></indexterm> 
<indexterm><primary>repeaters</primary></indexterm> 
<indexterm><primary>bridges</primary></indexterm> 
<indexterm><primary>routers</primary></indexterm> 
One of the drawbacks of Ethernet technology is its limited cable length, which
precludes any use of it other than for LANs. However, several Ethernet
segments can be linked to one another using repeaters, bridges, or routers.
Repeaters simply copy the signals between two or more segments so that all
segments together will act as if they are one Ethernet. Due to timing
requirements, there may not be more than four repeaters between any two hosts
on the network. Bridges and routers are more sophisticated. They analyze
incoming data and forward it only when the recipient host is not on the local
Ethernet.
</para>

<para>
<indexterm><primary>Ethernet</primary><secondary>addresses</secondary></indexterm>
<indexterm><primary>addresses</primary><secondary>Ethernet</secondary></indexterm>
Ethernet works like a bus system, where a host may send packets (or
<emphasis>frames</emphasis>) of up to 1,500 bytes to another host on the same
Ethernet. A host is addressed by a six-byte address hardcoded into the
firmware of its Ethernet network interface card (NIC). These addresses are
usually written as a sequence of two-digit hex numbers separated by colons,
as in <systemitem role="sitename">aa:bb:cc:dd:ee:ff</systemitem>.
</para>

<para>
<indexterm><primary>Ethernet</primary><secondary>collisions</secondary></indexterm>
<indexterm><primary>collisions (Ethernet)</primary></indexterm> A
frame sent by one station is seen by all attached stations, but only
the destination host actually picks it up and processes it. If two
stations try to send at the same time, a
<emphasis>collision</emphasis> occurs. Collisions on an Ethernet are
detected very quickly by the electronics of the interface cards and
are resolved by the two stations aborting the send, each waiting a
random interval and re-attempting the transmission. You'll hear lots
of stories about collisions on Ethernet being a problem and that
utilization of Ethernets is only about 30 percent of the available
bandwidth because of them.  Collisions on Ethernet are a
<emphasis>normal</emphasis> phenomenon, and on a very busy Ethernet
network you shouldn't be surprised to see collision rates of up to
about 30 percent. Utilization of Ethernet networks is more
realistically limited to about 60 percent before you need to start
worrying about it.<footnote id="X-087-2-FNIT03"><para> The Ethernet
FAQ at <systemitem
role="url">http://www.faqs.org/faqs/LANs/ethernet-faq/</systemitem>
talks about this issue, and a wealth of detailed historical and
technical information is available at Charles Spurgeon's Ethernet web
site at <systemitem
role="url">http://wwwhost.ots.utexas.edu/ethernet/</systemitem>.
</para>
</footnote>
</para>

</sect2>

<sect2 id="X-087-2-intro.tcpip.other-hardware"><title>Other Types of Hardware</title>
<para>
In larger installations, such as Groucho Marx University, Ethernet is usually
not the only type of equipment used. There are many other data communications
protocols available and in use. All of the protocols listed are supported by
Linux, but due to space constraints we'll describe them briefly. Many of the
protocols have HOWTO documents that describe them in detail, so you should
refer to those if you're interested in exploring those that we don't describe
in this book.
</para>

<para>
<indexterm><primary>FDDI (Fiber Distributed Data Interface)</primary></indexterm>
<INDEXTERM><PRIMARY>Fiber Distributed Data Interface (FDDI)</PRIMARY></INDEXTERM>
<INDEXTERM><PRIMARY>protocols</PRIMARY><SECONDARY>token-passing</SECONDARY></INDEXTERM>
At Groucho Marx University, each department's LAN is linked to the
campus high-speed &ldquo;backbone&rdquo; network, which is a fiber
optic cable running a network technology called <emphasis>Fiber
Distributed Data Interface</emphasis> (FDDI). FDDI uses an entirely
different approach to transmitting data, which basically involves
sending around a number of <emphasis>tokens</emphasis>, with a station
being allowed to send a frame only if it captures a token. The main
advantage of a token-passing protocol is a reduction in collisions.
Therefore, the protocol can more easily attain the full speed of the
transmission medium, up to 100 Mbps in the case of FDDI.  FDDI, being
based on optical fiber, offers a significant advantage because its
maximum cable length is much greater than wire-based technologies. It
has limits of up to around 200 km, which makes it ideal for linking
many buildings in a city, or as in GMU's case, many buildings on a
campus.
</para>

<para>
<indexterm><primary>Token Ring</primary><secondary>networks</secondary></indexterm>
<INDEXTERM><PRIMARY>networks</PRIMARY><SECONDARY>Token
Ring</SECONDARY></INDEXTERM> <INDEXTERM><PRIMARY>IBM Token Ring
networks</PRIMARY></INDEXTERM> Similarly, if there is any IBM
computing equipment around, an IBM Token Ring network is quite likely
to be installed. Token Ring is used as an alternative to Ethernet in
some LAN environments, and offers the same sorts of advantages as FDDI
in terms of achieving full wire speed, but at lower speeds (4 Mbps or
16 Mbps), and lower cost because it is based on wire rather than
fiber. In Linux, Token Ring networking is configured in almost
precisely the same way as Ethernet, so we don't cover it specifically.
</para>

<para>
Although it is much less likely today than in the past, other LAN
technologies, such as ArcNet and DECNet, might be installed. Linux
supports these too, but we don't cover them here.
</para>

<para>
<indexterm><primary>protocols</primary><secondary>X.25</secondary></indexterm>
<indexterm><primary>X.25 protocol</primary></indexterm>
<indexterm><primary>PAD (Packet Assembler
Disassembler)</primary></indexterm> Many national networks operated by
Telecommunications companies support packet switching
protocols. Probably the most popular of these is a standard named
X.25. Many Public Data Networks, like Tymnet in the U.S., Austpac in
Australia, and Datex-P in Germany offer this service. X.25 defines a
set of networking protocols that describes how data terminal
equipment, such as a host, communicates with data communications
equipment (an X.25 switch). X.25 requires a synchronous data link, and
therefore special synchronous serial port hardware. It is possible to
use X.25 with normal serial ports if you use a special device called a
PAD (Packet Assembler Disassembler). The PAD is a standalone device
that provides asynchronous serial ports and a synchronous serial
port. It manages the X.25 protocol so that simple terminal devices can
make and accept X.25 connections. X.25 is often used to carry other
network protocols, such as TCP/IP. Since IP datagrams cannot simply be
mapped onto X.25 (or vice versa), they are encapsulated in X.25
packets and sent over the network. There is an experimental
implementation of the X.25 protocol available for Linux.
</para>

<para>
<indexterm><primary>protocols</primary><secondary>Frame Relay</secondary></indexterm>
<indexterm><primary>FRAD (Frame Relay Access Device)</primary></indexterm>
A more recent protocol commonly offered by telecommunications
companies is called <emphasis>Frame Relay</emphasis>. The Frame Relay
protocol shares a number of technical features with the X.25 protocol,
but is much more like the IP protocol in behavior. Like X.25, Frame
Relay requires special synchronous serial hardware. Because of their
similarities, many cards support both of these protocols. An
alternative is available that requires no special internal hardware,
again relying on an external device called a Frame Relay Access Device
(FRAD) to manage the encapsulation of Ethernet packets into Frame
Relay packets for transmission across a network. Frame Relay is ideal
for carrying TCP/IP between sites. Linux provides drivers that support
some types of internal Frame Relay devices.
</para>

<para>
<indexterm><primary>protocols</primary><secondary>ATM (Asynchronous Transfer Mode)</secondary></indexterm>
<indexterm><primary>ATM (Asynchronous Transfer Mode)</primary></indexterm>
If you need higher speed networking that can carry many different
types of data, such as digitized voice and video, alongside your usual
data, ATM (Asynchronous Transfer Mode) is probably what you'll be
interested in. ATM is a new network technology that has been
specifically designed to provide a manageable, high-speed, low-latency
means of carrying data, and provide control over the Quality of
Service (Q.S.). Many telecommunications companies are deploying ATM
network infrastructure because it allows the convergence of a number
of different network services into one platform, in the hope of
achieving savings in management and support costs. ATM is often used
to carry TCP/IP.  The Networking-HOWTO offers information on the Linux
support available for ATM.
</para>

<para>
<indexterm><primary>protocols</primary><secondary>AX.25</secondary></indexterm>
<indexterm><primary>protocols</primary><secondary>NetRom</secondary></indexterm>
<indexterm><primary>protocols</primary><secondary>Rose</secondary></indexterm>
<indexterm><primary>amateur radio protocols</primary></indexterm>
<indexterm><primary>ham radio</primary></indexterm>
<indexterm><primary>packet radio</primary></indexterm>
<indexterm><primary>AX.25 protocol</primary></indexterm>
<indexterm><primary>NetRom protocol</primary></indexterm>
<indexterm><primary>Rose protocol</primary></indexterm>
<indexterm><primary>TNC (Terminal Node Controller)</primary></indexterm>
<INDEXTERM><PRIMARY>AX25 HOWTO</PRIMARY></INDEXTERM>
<INDEXTERM><PRIMARY>HOWTOs</PRIMARY><SECONDARY>AX25</SECONDARY></INDEXTERM>
Frequently, radio amateurs use their radio equipment to network their
computers; this is commonly called <emphasis>packet
radio</emphasis>. One of the protocols used by amateur radio operators
is called AX.25 and is loosely derived from X.25. Amateur radio
operators use the AX.25 protocol to carry TCP/IP and other protocols,
too. AX.25, like X.25, requires serial hardware capable of synchronous
operation, or an external device called a &ldquo;Terminal Node
Controller&rdquo; to convert packets transmitted via an asynchronous
serial link into packets transmitted synchronously. There are a
variety of different sorts of interface cards available to support
packet radio operation; these cards are generally referred to as being
&ldquo;Z8530 SCC based,&rdquo; and are named after the most popular
type of communications controller used in the designs. Two of the
other protocols that are commonly carried by AX.25 are the NetRom and
Rose protocols, which are network layer protocols. Since these
protocols run over AX.25, they have the same hardware
requirements. Linux supports a fully featured implementation of the
AX.25, NetRom, and Rose protocols. The AX25-HOWTO is a good source of
information on the Linux implementation of these protocols.
</para>

<para>
Other types of Internet access involve dialing up a central system
over slow but cheap serial lines (telephone, ISDN, and so on).  These
require yet another protocol for transmission of packets, such as SLIP
or PPP, which will be described later.
</para>

</sect2>

<sect2 id="X-087-2-intro.tcpip.ip"><title>The Internet Protocol</title>

<para>
<indexterm><primary>protocols</primary><secondary>Internet (IP)</secondary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary></indexterm>
Of course, you wouldn't want your networking to be limited to one
Ethernet or one point-to-point data link. Ideally, you would want to
be able to communicate with a host computer regardless of what type of
physical network it is connected to. For example, in larger
installations such as Groucho Marx University, you usually have a
number of separate networks that have to be connected in some way. At
GMU, the Math department runs two Ethernets: one with fast machines
for professors and graduates, and another with slow machines for
students. Both are linked to the FDDI campus backbone network.
</para>

<para>
<indexterm><primary>forwarding</primary><secondary>IP</secondary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>forwarding</secondary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>gateways</secondary></indexterm>
<indexterm><primary>gateways</primary></indexterm>
This connection is handled by a dedicated host called a
<emphasis>gateway</emphasis> that handles incoming and outgoing
packets by copying them between the two Ethernets and the FDDI fiber
optic cable. For example, if you are at the Math department and want
to access <systemitem role="sitename">quark</systemitem> on the
Physics department's LAN from your Linux box, the networking software
will not send packets to <systemitem role="sitename">quark</systemitem>
directly because it is not on the same Ethernet. Therefore, it has to
rely on the gateway to act as a forwarder. The gateway (named
<systemitem role="sitename">sophus</systemitem>) then forwards these
packets to its peer gateway <systemitem
role="sitename">niels</systemitem> at the Physics department, using
the backbone network, with <systemitem
role="sitename">niels</systemitem> delivering it to the destination
machine. Data flow between <systemitem
role="sitename">erdos</systemitem> and <systemitem
role="sitename">quark</systemitem> is shown in <xref
linkend="X-087-2-intro.fig.ip-flow">.
</para>

<figure id="X-087-2-intro.fig.ip-flow">
<title>The three steps of sending a datagram from erdos to quark</title>
<!-- <graphic fileref="lag2_0101.jpg"></graphic> -->
<!-- 2016-01-28; MAB, TLDP -->
<mediaobject> 
  <imageobject>
    <imagedata fileref="images/lag2_0101.jpg" format="jpg">
  </imageobject>
  <imageobject>
    <imagedata fileref="images/lag2_0101.eps" format="eps">
  </imageobject>
</mediaobject>
</figure>

<para>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>routing</secondary></indexterm>
<INDEXTERM><PRIMARY>datagrams</PRIMARY></INDEXTERM>
This scheme of directing data to a remote host is called
<emphasis>routing</emphasis>, and packets are often referred to as
<emphasis>datagrams</emphasis> in this context. To facilitate things,
datagram exchange is governed by a single protocol that is independent
of the hardware used: IP, or <emphasis>Internet Protocol</emphasis>.
In <xref linkend="X-087-2-issues">, we will cover IP and the issues of
routing in greater detail.
</para>

<para>
<indexterm><primary>internetworking</primary></indexterm>
<indexterm><primary>networks</primary><secondary>interconnecting</secondary></indexterm>
<indexterm><primary>Internet</primary><secondary>versus internetworking</secondary></indexterm>
The main benefit of IP is that it turns physically dissimilar networks into
one apparently homogeneous network. This is called internetworking, and the
resulting &ldquo;meta-network&rdquo; is called an
<emphasis>internet</emphasis>. Note the subtle difference here between
<emphasis>an</emphasis> internet and <emphasis>the</emphasis> Internet.
The latter is the official name of one particular global internet.
</para>

<para>
<indexterm><primary>addresses</primary><secondary>IP</secondary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>addresses</secondary></indexterm>
<indexterm><primary>dotted quad notation</primary></indexterm>
<indexterm><primary>dotted decimal notation</primary></indexterm>
<INDEXTERM><PRIMARY>IPv4 (Internet Protocol)</PRIMARY></INDEXTERM>
<INDEXTERM><PRIMARY>IP (Internet Protocol)</PRIMARY><SECONDARY>IPv4</SECONDARY></INDEXTERM>
Of course, IP also requires a hardware-independent addressing
scheme. This is achieved by assigning each host a unique 32-bit number
called the <emphasis>IP address</emphasis>. An IP address is usually
written as four decimal numbers, one for each 8-bit portion, separated
by dots. For example, <systemitem role="sitename">quark</systemitem>
might have an IP address of <systemitem
role="sitename">0x954C0C04</systemitem>, which would be written as
<systemitem role="sitename">149.76.12.4</systemitem>. This format is
also called <emphasis>dotted decimal notation</emphasis> and sometimes
<emphasis>dotted quad notation</emphasis>. It is increasingly going
under the name IPv4 (for Internet Protocol, Version 4) because a new
standard called IPv6 offers much more flexible addressing, as well as
other modern features. It will be at least a year after the release of
this edition before IPv6 is in use.
</para>

<para>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>addresses</secondary><tertiary>versus hostname</tertiary></indexterm>
<indexterm><primary>Ethernet</primary><secondary>addresses</secondary><tertiary>versus IP address</tertiary></indexterm>
You will notice that we now have three different types of addresses:
first there is the host's name, like <systemitem
role="sitename">quark</systemitem>, then there are IP addresses, and
finally, there are hardware addresses, like the 6-byte Ethernet
address. All these addresses somehow have to match so that when you
type <command>rlogin quark</command>, the networking software can be
given <systemitem role="sitename">quark</systemitem>'s IP address; and
when IP delivers any data to the Physics department's Ethernet, it
somehow has to find out what Ethernet address corresponds to the IP
address.
</para>

<para>
We will deal with these situations in <xref linkend="X-087-2-issues">.
For now, it's enough to remember that these steps of finding addresses are
called <emphasis>hostname resolution</emphasis>, for mapping hostnames onto IP
addresses, and <emphasis>address resolution</emphasis>, for mapping the latter
to hardware addresses.
</para>

</sect2>

<sect2 id="X-087-2-intro.tcpip.slip"><title>IP Over Serial Lines</title>

<para>
<indexterm><primary>protocols</primary><secondary>CSLIP</secondary></indexterm>
<indexterm><primary>protocols</primary><secondary>SLIP</secondary></indexterm>
<indexterm><primary>protocols</primary><secondary>PPP</secondary></indexterm>
<INDEXTERM><PRIMARY>telephones</PRIMARY><SECONDARY>sending data over</SECONDARY></INDEXTERM>
<indexterm><primary>SLIP (Serial Line IP) protocol</primary></indexterm>
<indexterm><primary>CSLIP (Compressed Serial Line IP) protocol</primary></indexterm>
<indexterm><primary>PPP (Point-to-Point Protocol)</primary></indexterm>
On serial lines, a &ldquo;de facto&rdquo; standard exists known as SLIP, or
<emphasis>Serial Line IP</emphasis>. A modification of SLIP known as CSLIP,
or <emphasis>Compressed SLIP</emphasis>, performs compression of IP headers
to make better use of the relatively low bandwidth provided by most serial
links. Another serial protocol is PPP, or the
<emphasis>Point-to-Point Protocol</emphasis>. PPP is more modern than
SLIP and includes a number of features that make it more attractive. Its
main advantage over SLIP is that it isn't limited to transporting IP
datagrams, but is designed to allow just about any protocol to be carried
across it.
</para>

</sect2>

<sect2 id="X-087-2-intro.tcpip.tcp"><title>The Transmission Control Protocol</title>

<para>
<indexterm><primary>protocols</primary><secondary>TCP</secondary></indexterm>
<indexterm><primary>TCP (Transmission Control Protocol)</primary></indexterm>
Sending datagrams from one host to another is not the whole story. If you
log in to <systemitem role="sitename">quark</systemitem>, you want to have a
reliable connection between your <command>rlogin</command> process on
<systemitem role="sitename">erdos</systemitem> and the shell process on
<systemitem role="sitename">quark</systemitem>. Thus, the information sent
to and fro must be split up into packets by the sender and reassembled into
a character stream by the receiver. Trivial as it seems, this involves a
number of complicated tasks.
</para>

<para>
A very important thing to know about IP is that, by intent, it is not
reliable.  Assume that ten people on your Ethernet started downloading
the latest release of Netscape's web browser source code from GMU's
FTP server. The amount of traffic generated might be too much for the
gateway to handle, because it's too slow and it's tight on memory. Now
if you happen to send a packet to <systemitem
role="sitename">quark</systemitem>, <systemitem
role="sitename">sophus</systemitem> might be out of buffer space for a
moment and therefore unable to forward it. IP solves this problem by
simply discarding it. The packet is irrevocably lost. It is therefore
the responsibility of the communicating hosts to check the integrity
and completeness of the data and retransmit it in case of error.
</para>

<para>
This process is performed by yet another protocol, <emphasis>Transmission
Control Protocol</emphasis> (TCP), which builds a reliable service on top of IP. The
essential property of TCP is that it uses IP to give you the illusion of a
simple connection between the two processes on your host and the remote
machine, so you don't have to care about how and along which route your data
actually travels.  A TCP connection works essentially like a two-way pipe that
both processes may write to and read from. Think of it as a telephone
conversation.
</para>

<para>
<INDEXTERM id="chit.networks.tcp.ports" class=startofrange><PRIMARY>networks</PRIMARY><SECONDARY>ports</SECONDARY></INDEXTERM>
<INDEXTERM id="chit.networks.ports" class=startofrange><PRIMARY>ports</PRIMARY></INDEXTERM>
TCP identifies the end points of such a connection by the IP addresses
of the two hosts involved and the number of a
<emphasis>port</emphasis> on each host. Ports may be viewed as
attachment points for network connections.  If we are to strain the
telephone example a little more, and you imagine that cities are like
hosts, one might compare IP addresses to area codes (where numbers map
to cities), and port numbers to local codes (where numbers map to
individual people's telephones). An individual host may support many
different services, each distinguished by its own port number.
</para>

<para>
<indexterm><primary>remote</primary><secondary>login</secondary></indexterm>
In the <command>rlogin</command> example, the client application
(<command>rlogin</command>) opens a port on <systemitem
role="sitename">erdos</systemitem> and connects to port 513 on
<systemitem role="sitename">quark</systemitem>, to which the
<command>rlogind</command> server is known to listen. This action
establishes a TCP connection. Using this connection,
<command>rlogind</command> performs the authorization procedure and
then spawns the shell. The shell's standard input and output are
redirected to the TCP connection, so that anything you type to
<command>rlogin</command> on your machine will be passed through the
TCP stream and be given to the shell as standard input.
</para>
</sect2>

<sect2 id="X-087-2-intro.tcpip.udp"><title>The User Datagram Protocol</title>

<para>
<indexterm><primary>protocols</primary><secondary>UDP</secondary></indexterm>
<indexterm><primary>UDP (User Datagram Protocol)</primary></indexterm>
<indexterm><primary>User Datagram Protocol (UDP)</primary></indexterm>
Of course, TCP isn't the only user protocol in TCP/IP networking. Although
suitable for applications like <command>rlogin</command>, the overhead
involved is prohibitive for applications like NFS, which instead uses a
sibling protocol of TCP called UDP, or
<emphasis>User Datagram Protocol</emphasis>. Just like TCP, UDP allows an
application to contact a service on a certain port of the remote machine, but
it doesn't establish a connection for this. Instead, you use it to send single
packets to the destination service&mdash;hence its name.
</para>

<para>
Assume you want to request a small amount of data from a database
server. It takes at least three datagrams to establish a TCP
connection, another three to send and confirm a small amount of data
each way, and another three to close the connection. UDP provides us
with a means of using only two datagrams to achieve almost the same
result. UDP is said to be connectionless, and it doesn't require us to
establish and close a session. We simply put our data into a datagram
and send it to the server; the server formulates its reply, puts the
data into a datagram addressed back to us, and transmits it
back. While this is both faster and more efficient than TCP for simple
transactions, UDP was not designed to deal with datagram loss. It is
up to the application, a name server for example, to take care of
this.
</para>

</sect2>

<sect2 id="X-087-2-intro.tcpip.ports"><title>More on Ports</title>

<para>
<indexterm><primary>networks</primary><secondary>services</secondary></indexterm>
<indexterm><primary>services</primary></indexterm> Ports may be viewed
as attachment points for network connections. If an application wants
to offer a certain service, it attaches itself to a port and waits for
clients (this is also called <emphasis>listening</emphasis> on the
port). A client who wants to use this service allocates a port on its
local host and connects to the server's port on the remote host. The
same port may be open on many different machines, but on each machine
only one process can open a port at any one time.
</para>

<para>
An important property of ports is that once a connection has been
established between the client and the server, another copy of the
server may attach to the server port and listen for more clients.
This property permits, for instance, several concurrent remote logins
to the same host, all using the same port 513. TCP is able to tell
these connections from one another because they all come from
different ports or hosts. For example, if you log in twice to
<systemitem role="sitename">quark</systemitem> from <systemitem
role="sitename">erdos</systemitem>, the first
<command>rlogin</command> client will use the local port 1023, and the
second one will use port 1022. Both, however, will connect to the same
port 513 on <systemitem role="sitename">quark</systemitem>. The two
connections will be distinguished by use of the port numbers used at
<systemitem role="sitename">erdos</systemitem>.
</para>

<para>
<indexterm><primary>services</primary><secondary>well-known</secondary></indexterm>
<indexterm><primary>services</primary><secondary>port numbers and</secondary></indexterm>
<indexterm><primary>IETF (Internet Engineering Task Force)</primary></indexterm>
This example shows the use of ports as rendezvous points, where a client
contacts a specific port to obtain a specific service. In order for a client
to know the proper port number, an agreement has to be reached between the
administrators of both systems on the assignment of these numbers. For
services that are widely used, such as <command>rlogin</command>, these
numbers have to be administered centrally. This is done by the IETF
(Internet Engineering Task Force), which regularly releases an RFC titled
<emphasis>Assigned Numbers</emphasis> (RFC-1700). It describes, among other
things, the port numbers assigned to well-known services. Linux uses a file
called <filename>/etc/services</filename> that maps service names to
numbers.
</para>

<para>
It is worth noting that although both TCP and UDP connections rely on ports,
these numbers do not conflict. This means that TCP port 513, for example, is
different from UDP port 513. In fact, these ports serve as access points for
two different services, namely <command>rlogin</command> (TCP) and
<command>rwho</command> (UDP).
<INDEXTERM startref="chit.networks.tcp.ports" class=endofrange>
<INDEXTERM startref="chit.networks.ports" class=endofrange>
</para>

</sect2>

<sect2 id="X-087-2-intro.tcpip.sockets"><title>The Socket Library</title>
<para>
<indexterm><primary>networks</primary><secondary>programming interfaces</secondary></indexterm> <indexterm><primary>Berkeley Socket Library</primary></indexterm>
<indexterm><primary>sockets</primary></indexterm>
<indexterm><primary>bind(&thinsp;)</primary></indexterm>
<indexterm><primary>connect(&thinsp;)</primary></indexterm>
<indexterm><primary>listen(&thinsp;)</primary></indexterm>
<indexterm><primary>accept(&thinsp;)</primary></indexterm>
<indexterm><primary>XNS (Xerox Networking System)</primary></indexterm>
<indexterm><primary>protocols</primary><secondary>XNS</secondary></indexterm>
In Unix operating systems, the software performing all the tasks and
protocols described above is usually part of the kernel, and so it is
in Linux. The programming interface most common in the Unix world is
the <emphasis>Berkeley Socket Library</emphasis>. Its name derives
from a popular analogy that views ports as sockets and connecting to
a port as plugging in. It provides the <function>bind</function> call
to specify a remote host, a transport protocol, and a service that a
program can connect or listen to (using <function>connect</function>,
<function>listen</function>, and <function>accept</function>). The
socket library is somewhat more general in that it provides not only a
class of TCP/IP-based sockets (the <function>AF_INET</function>
sockets), but also a class that handles connections local to the
machine (the <function>AF_UNIX</function> class). Some implementations
can also handle other classes, like the XNS (<emphasis>Xerox
Networking System</emphasis>) protocol or X.25.
</para>

<para>
<indexterm><primary>IPX (Internet Packet eXchange)</primary></indexterm>
<indexterm><primary>protocols</primary><secondary>Internet Packet eXchange (IPX)</secondary></indexterm>
<indexterm><primary>X.25 protocol</primary></indexterm>
<indexterm><primary>protocols</primary><secondary>X.25</secondary></indexterm>
<indexterm><primary>ATM (Asynchronous Transfer Mode)</primary></indexterm>
<indexterm><primary>protocols</primary><secondary>ATM (Asynchronous Transfer Mode)</secondary></indexterm>
<indexterm><primary>AX.25 protocol</primary></indexterm>
<indexterm><primary>protocols</primary><secondary>AX.25</secondary></indexterm>
<indexterm><primary>NetRom protocol</primary></indexterm>
<indexterm><primary>protocols</primary><secondary>NetRom</secondary></indexterm>
<indexterm><primary>Rose protocol</primary></indexterm>
<indexterm><primary>protocols</primary><secondary>Rose</secondary></indexterm>
In Linux, the socket library is part of the standard
<filename>libc</filename> C library. It supports the
<function>AF_INET</function> and <function>AF_INET6</function> sockets
for TCP/IP and <function>AF_UNIX</function> for Unix domain
sockets. It also supports <function>AF_IPX</function> for Novell's
network protocols, <function>AF_X25</function> for the X.25 network
protocol, <function>AF_ATMPVC</function> and
<function>AF_ATMSVC</function> for the ATM network protocol and
<function>AF_AX25</function>, <function>AF_NETROM</function>, and
<function>AF_ROSE</function> sockets for Amateur Radio protocol
support. Other protocol families are being developed and will be
added in time.
</para>
<INDEXTERM startref="chit.networks.tcp-ip" class=endofrange>
</sect2>
<?troff .Nd 7>
</sect1>

<sect1 id="X-087-2-intro.uucp"><title>UUCP Networks</title>
<para>
<indexterm><primary>networks</primary><secondary>UUCP</secondary></indexterm>
<INDEXTERM><PRIMARY>UUCP</PRIMARY><SECONDARY>networks</SECONDARY></INDEXTERM>
Unix-to-Unix Copy (UUCP) started out as a package of programs that
transferred files over serial lines, scheduled those transfers, and
initiated execution of programs on remote sites. It has undergone major
changes since its first implementation in the late seventies, but it
is still rather spartan in the services it offers. Its main
application is still in Wide Area Networks, based on periodic dialup
telephone links.
</para>

<para>
UUCP was first developed by Bell Laboratories in 1977 for
communication between their Unix development sites. In mid-1978, this
network already connected over 80 sites.  It was running email as an
application, as well as remote printing.  However, the system's
central use was in distributing new software and bug fixes. Today, UUCP
is not confined solely to the Unix environment. There are free and
commercial ports available for a variety of platforms, including
AmigaOS, DOS, and Atari's TOS.
</para>

<para>
One of the main disadvantages of UUCP networks is that they operate in
batches. Rather than having a permanent connection established between
hosts, it uses temporary connections. A UUCP host machine might dial in to
another UUCP host only once a day, and then only for a short period of time.
While it is connected, it will transfer all of the news, email, and files that
have been queued, and then disconnect. It is this queuing that limits the
sorts of applications that UUCP can be applied to. In the case of email, a
user may prepare an email message and post it. The message will stay queued
on the UUCP host machine until it dials in to another UUCP host to transfer
the message. This is fine for network services such as email, but is no
use at all for services such as <command>rlogin</command>.
</para>

<para>
Despite these limitations, there are still many UUCP networks
operating all over the world, run mainly by hobbyists, which offer
private users network access at reasonable prices. The main reason for
the longtime popularity of UUCP was that it was very cheap compared to
having your computer directly connected to the Internet. To make your
computer a UUCP node, all you needed was a modem, a working UUCP
implementation, and another UUCP node that was willing to feed you
mail and news. Many people were prepared to provide UUCP feeds to
individuals because such connections didn't place much demand on their
existing network.
</para>

<para>
We cover the configuration of UUCP in a chapter of its own later in
the book, but we won't focus on it too heavily, as it's being replaced
rapidly with TCP/IP, now that cheap Internet access has become commonly
available in most parts of the world.
</para>
</sect1>

<sect1><title>Linux Networking</title>

<para>
<indexterm><primary>Linux</primary><secondary>networks</secondary></indexterm> 
<indexterm><primary>networks</primary><secondary>Linux</secondary></indexterm> 
<indexterm><primary>Net-1 network version</primary></indexterm>
<indexterm><primary>Net-2d network version</primary></indexterm>
<indexterm><primary>Net-2Debugged network version</primary></indexterm>
<indexterm><primary>Net-3 network version</primary></indexterm>
<indexterm><primary>Biro, Ross</primary></indexterm>
<indexterm><primary>Cox, Alan</primary></indexterm>
<indexterm><primary>Kempen, Fred van</primary></indexterm>
As it is the result of a concerted effort of programmers around
the world, Linux wouldn't have been possible without the global
network. So it's not surprising that in the early stages of
development, several people started to work on providing it with
network capabilities. A UUCP implementation was running on Linux
almost from the very beginning, and work on TCP/IP-based networking
started around autumn 1992, when Ross Biro and others created what has
now become known as Net-1.
</para>

<para>
After Ross quit active development in May 1993, Fred van Kempen began
to work on a new implementation, rewriting major parts of the
code. This project was known as Net-2. The first public release, Net-2d, was
made in the summer of 1993 (as part of the 0.99.10 kernel), and has
since been maintained and expanded by several people, most 
notably Alan Cox.<footnote id="X-087-2-FNIT04"><para>Alan can be reached at
<systemitem role="emailaddr">alan@lxorguk.ukuu.org.uk</systemitem>
</para></footnote> Alan's original work was known as
Net-2Debugged. After heavy debugging and numerous improvements to the
code, he changed its name to Net-3 after Linux 1.0 was released. The
Net-3 code was further developed for Linux 1.2 and Linux 2.0.  The 2.2
and later kernels use the Net-4 version network support, which remains
the standard official offering today.
</para>

<para>
<indexterm><primary>Net-4 network version</primary></indexterm> The
Net-4 Linux Network code offers a wide variety of device drivers and
advanced features. Standard Net-4 protocols include SLIP and PPP (for
sending network traffic over serial lines), PLIP (for parallel lines),
IPX (for Novell compatible networks, which we'll discuss in <xref
linkend="X-087-2-ipx">), Appletalk (for Apple networks) and AX.25,
NetRom, and Rose (for amateur radio networks). Other standard Net-4
features include IP firewalling, IP accounting (discussed later in
<xref linkend="X-087-2-firewall"> and <xref
linkend="X-087-2-accounting">), and IP Masquerade (discussed later in
<xref linkend="X-087-2-ipmasq">. IP tunnelling in a couple of
different flavors and advanced policy routing are supported. A very
large variety of Ethernet devices is supported, in addition to support
for some FDDI, Token Ring, Frame Relay, and ISDN, and ATM cards.
</para>

<para>
<indexterm><primary>Tridgell, Andrew</primary></indexterm>
Additionally, there are a number of other features that greatly
enhance the flexibility of Linux. These features include an
implementation of the SMB filesystem, which interoperates with
applications like <emphasis>lanmanager</emphasis> and Microsoft
Windows, called Samba, written by Andrew Tridgell, and an
implementation of the Novell NCP (NetWare Core Protocol).<footnote
id="X-087-2-FNIT05"><para> NCP is the protocol on which Novell file
and print services are based.
</para>
</footnote>

</para>

<sect2><title>Different Streaks of Development</title>
<para>
There have been, at various times, varying network development efforts active
for Linux.
</para>

<para>
<indexterm><primary>Net-2e network version</primary></indexterm>
<indexterm><primary>DDI (Device Driver
Interface)</primary></indexterm> <indexterm><primary>Device Driver
Interface (DDI)</primary></indexterm> Fred continued development after
Net-2Debugged was made the official network implementation. This
development led to the Net-2e, which featured a much revised design of
the networking layer. Fred was working toward a standardized Device
Driver Interface (DDI), but the Net-2e work has ended now.
</para>

<para>
<indexterm><primary>Urlichs, Matthias</primary></indexterm> Yet another 
implementation of TCP/IP networking came from Matthias
Urlichs, who wrote an ISDN driver for Linux and FreeBSD. For this
driver, he integrated some of the BSD networking code in the Linux
kernel.  That project, too is no longer being worked on.
</para>

<para>
There has been a lot of rapid change in the Linux kernel networking
implementation, and change is still the watchword as development
continues. Sometimes this means that changes also have to occur in
other software, such as the network configuration tools. While this is
no longer as large a problem as it once was, you may still find that
upgrading your kernel to a later version means that you must upgrade
your network configuration tools, too. Fortunately, with the large
number of Linux distributions available today, this is a quite simple
task.
</para>

<para>
<indexterm><primary>IPv6 (Internet Protocol)</primary></indexterm>
<INDEXTERM><PRIMARY>IP (Internet Protocol)</PRIMARY><SECONDARY>IPv6</SECONDARY></INDEXTERM>
The Net-4 network implementation is now quite mature and is in use at a
very large number of sites around the world. Much work has been done on
improving the performance of the Net-4 implementation, and it now competes
with the best implementations available for the same hardware platforms.
Linux is proliferating in the Internet Service Provider environment, and is
often used to build cheap and reliable World Wide Web servers, mail servers,
and news servers for these sorts of organizations. There is now sufficient
development interest in Linux that it is managing to keep abreast of
networking technology as it changes, and current releases of the Linux kernel
offer the next generation of the IP protocol, IPv6, as a standard offering.
</para>

</sect2>

<sect2><title>Where to Get the Code</title>

<para>
<indexterm><primary>code, obtaining for</primary><secondary>Linux network</secondary></indexterm>
<indexterm><primary>Linux</primary><secondary>networks</secondary><tertiary>obtaining code for</tertiary></indexterm>
<indexterm><primary>FTP (File Transfer Protocol), location of Linux code</primary></indexterm>
<indexterm><primary>Net-3 network version</primary></indexterm>
It seems odd now to remember that in the early days of the Linux
network code development, the standard kernel required a huge patch
kit to add the networking support to it. Today, network development
occurs as part of the mainstream Linux kernel development process. The
latest stable Linux kernels can be found on <emphasis
role=bold>ftp.kernel.org</emphasis> in
<filename>/pub/linux/kernel/v2.x/</filename>, where
<emphasis>x</emphasis> is an even number. The latest experimental Linux
kernels can be found on <emphasis role=bold>ftp.kernel.org</emphasis>
in <filename>/pub/linux/kernel/v2.y/</filename>, where
<emphasis>y</emphasis> is an odd number. There are Linux kernel source
mirrors all over the world. It is now hard to imagine Linux without
standard network support.
</para>

</sect2>

</sect1>

<sect1><title>Maintaining Your System</title>

<para>
<indexterm><primary>maintenance, system</primary></indexterm>
<indexterm><primary>system maintenance</primary></indexterm>
Throughout this book, we will mainly deal with installation and
configuration issues. Administration is, however, much more than
that&mdash;after setting up a service, you have to keep it running, too.
For most services, only a little attendance will be necessary, while some,
like mail and news, require that you perform routine tasks to keep your system
up to date. We will discuss these tasks in later chapters.
</para>

<para>
<indexterm><primary>cron</primary></indexterm>
<INDEXTERM><PRIMARY>errors, checking for</PRIMARY></INDEXTERM>
The absolute minimum in maintenance is to check system and per-application
log files regularly for error conditions and unusual events. Often, you
will want to do this by writing a couple of administrative shell scripts
and periodically running them from <command>cron</command>. The source
distributions of some major applications, like <command>inn</command> or
C News, contain such scripts. You only have to tailor them to suit your
needs and preferences.
</para>

<para>
The output from any of your <command>cron</command> jobs should be mailed to an
administrative account. By default, many applications will send error
reports, usage statistics, or log file summaries to the
<systemitem role="userid">root</systemitem> account. This makes sense only
if you log in as <systemitem role="userid">root</systemitem> frequently; a much
better idea is to forward <systemitem role="userid">root</systemitem>'s mail to
your personal account by setting up a mail alias as described in
<xref linkend="X-087-2-exim"> or <xref linkend="X-087-2-sendmail">.
</para>

<para>
However carefully you have configured your site, Murphy's law guarantees
that some problem <emphasis>will</emphasis> surface eventually. Therefore,
maintaining a system also means being available for complaints. Usually,
people expect that the system administrator can at least be reached via email
as <systemitem role="emailaddr">root</systemitem>, but there are also other
addresses that are commonly used to reach the person responsible for a
specific aspect of maintenence. For instance, complaints about a
malfunctioning mail configuration will usually be addressed to
<systemitem role="emailaddr">postmaster</systemitem>, and problems with the
news system may be reported to
<systemitem role="emailaddr">newsmaster</systemitem> or
<systemitem role="emailaddr">usenet</systemitem>. Mail to
<systemitem role="emailaddr">hostmaster</systemitem> should be redirected to
the person in charge of the host's basic network services, and the DNS name
service if you run a name server.
</para>

<sect2 id="X-087-2-intro.security"><title>System Security</title>

<para>
<indexterm><primary>system security</primary></indexterm>
<indexterm><primary>security</primary><secondary>system</secondary></indexterm>
Another very important aspect of system administration in a network
environment is protecting your system and users from intruders.
Carelessly managed systems offer malicious people many targets. Attacks
range from password guessing to Ethernet snooping, and the damage caused
may range from faked mail messages to data loss or violation of your
users' privacy. We will mention some particular problems when discussing
the context in which they may occur and some common defenses against them.
</para>

<para>
This section will discuss a few examples and basic techniques for
dealing with system security.  Of course, the topics covered cannot
treat all security issues you may be faced with in detail; they merely
serve to illustrate the problems that may arise.  Therefore, reading a
good book on security is an absolute must, especially in a networked
system.
</para>

<para>
System security starts with good system administration. This includes
checking the ownership and permissions of all vital files and
directories and monitoring use of privileged accounts. The COPS
program, for instance, will check your file system and common
configuration files for unusual permissions or other anomalies. It is
also wise to use a password suite that enforces certain rules on the
users' passwords that make them hard to guess. The shadow password
suite, for instance, requires a password to have at least five letters
and to contain both upper- and lowercase numbers, as well as
non-alphabetic characters.
</para>

<para>
<indexterm><primary>services</primary><secondary>restricting access
to</secondary></indexterm> <indexterm><primary>TFTP (Trivial File
Transfer Protocol)</primary></indexterm> When making a service
accessible to the network, make sure to give it &ldquo;least
privilege&rdquo;; don't permit it to do things that aren't required
for it to work as designed. For example, you should make programs
setuid to <systemitem role="userid">root</systemitem> or some other
privileged account only when necessary. Also, if you want to use a
service for only a very limited application, don't hesitate to
configure it as restrictively as your special application allows. For
instance, if you want to allow diskless hosts to boot from your
machine, you must provide <emphasis>Trivial File Transfer
Protocol</emphasis>&thinsp; (TFTP) so that they can download basic
configuration files from the <filename>/boot</filename>
directory. However, when used unrestrictively, TFTP allows users
anywhere in the world to download any world-readable file from your
system. If this is not what you want, restrict TFTP service to the
<filename>/boot</filename> directory.<footnote
id="X-087-2-FNIT06"><para> We will come back to this topic in <xref
linkend="X-087-2-appl">.
</para>
</footnote>

</para>

<para>
<indexterm><primary>access</primary><secondary>restricting</secondary></indexterm>
You might also want to restrict certain services to users from certain
hosts, say from your local network.  In <xref linkend="X-087-2-appl">,
we introduce <command>tcpd</command>, which does this for a variety of
network applications. More sophisticated methods of restricting access
to particular hosts or services will be explored later in <xref
linkend="X-087-2-firewall">.
</para>

<para>
Another important point is to avoid &ldquo;dangerous&rdquo;
software. Of course, any software you use can be dangerous because
software may have bugs that clever people might exploit to gain access
to your system. Things like this happen, and there's no complete
protection against it. This problem affects free software and
commercial products alike.<footnote id="X-087-2-FNIT07"><para> There
have been commercial Unix systems (that you have to pay lots of money
for) that came with a setuid-<systemitem
role="userid">root</systemitem> shell script, which allowed users to
gain <systemitem role="userid">root</systemitem> privilege using a
simple standard trick.
</para>
</footnote> However, programs that require special privilege are inherently
more dangerous than others, because any loophole can have drastic
consequences.<footnote id="X-087-2-FNIT08"><para>
In 1988, the RTM worm brought much of the Internet to a grinding halt, partly
by exploiting a gaping hole in some programs including the
<command>sendmail</command> program. This hole has long since been fixed.
</para>
</footnote>
If you install a setuid program for network purposes, be doubly
careful to check the documentation so that you don't create a security
breach by accident.
</para>

<para>
<INDEXTERM><PRIMARY>ssh tools</PRIMARY></INDEXTERM>
<INDEXTERM><PRIMARY>authentication</PRIMARY><SECONDARY>issues</SECONDARY></INDEXTERM>
Another source of concern should be programs that enable login or
command execution with limited authentication. The
<command>rlogin</command>, <command>rsh</command>, and
<command>rexec</command> commands are all very useful, but offer very
limited authentication of the calling party.  Authentication is based
on trust of the calling host name obtained from a name server (we'll
talk about these later), which can be faked. Today it should be
standard practice to disable the <command>r</command> commands
completely and replace them with the <command>ssh</command> suite of
tools. The <command>ssh</command> tools use a much more reliable
authentication method and provide other services, such as encryption
and compression, as well. 
</para>

<para>
<indexterm><primary>tripwire command</primary></indexterm>
You can never rule out the possibility that your precautions might
fail, regardless of how careful you have been. You should therefore
make sure you detect intruders early. Checking the system log files is
a good starting point, but the intruder is probably clever enough to
anticipate this action and will delete any obvious traces he or she
left. However, there are tools like <command>tripwire</command>,
written by Gene Kim and Gene Spafford, that allow you to check vital
system files to see if their contents or permissions have been
changed. <command>tripwire</command> computes various strong
checksums over these files and stores them in a database. During
subsequent runs, the checksums are recomputed and compared to the
stored ones to detect any modifications.

<indexterm class="endofrange" startref="chit.netwks.intro"> 
</para>

</sect2>
</sect1>
</chapter>

