<?xml version="1.0" encoding="UTF-8"?>
<sect1 id="Overview">

<title>Overview</title>

<para>
As with the rest of the Linux operating system and its numerous components
development of networking stack within Linux has been both a slow and
complex journey that has resembled that journey that has been faced by
people in the development of networking stacks of other operating systems
such as Microsoft Windows and Free BSD.
</para>

<para>
As has been stated in the Linux Networking HOWTO 
(http://tldp.org/HOWTO/NET3-4-HOWTO.html)
the actual implementation of the TCP/IP protocol stack was done
basically from scratch due to concerns with regards to copyright issues
as well as the possibilty that developers would be able to come up
with a protocol stack that was superior to existing protocol stacks.
</para>

<para>
Ross Biro originally implemented the first ethernet driver for the
WD-8003 network interface card which led to an increase in pressure
among the open source community for the development of more complete 
networking support. However, due to increased personal commitments he
was unable to continue to do so and soon after left this project
having formed a crucial base for the development of better networking
support under Linux.
</para>

<para>
<screen>
Orest Zborowski <email>obz@Kodak.com</email> produced the original BSD socket
programming interface for the Linux kernel. This was a big step
forward as it allowed many of the existing network applications to be
ported to linux without serious modification.
</screen>
</para>	

<para>
Soon after Laurence Culhane developed the first Linux drivers
to support the SLIP protocol which meant that an increasing
number of people were able to access the Internet from Linux.
It also led to a greater number of people who understood the
implications of what full networking support meant for Linux
which meant there was an increasing community of people who
went on to experiment with this software and further develop it.
</para>

<para>
Eventually Fred van Kempen took over the task of leading the
development of networking support under Linux. The primary
difference between himself and his former predecessors was that he
was far more ambitious in his desire to expand the Linux networking
code. He laid the plans for the development of a dynamic device
interface, Amateur Radio AX.25 protocol support and a more abstract
and modular networking implementation. Obviously, like his predecessor
there was increasing pressure on him to deliver a product that was
both reliable and satisfied the requirements of most users.
</para>

<para>
This issue was resolved by Alan Cox who eventually debugged the code
so that it was reliable enough to use in the general community.
He also became the new leader of the Linux networking effort.
</para>

<para>
Donald Becker then went on to make a name for himself through
his implementation of a huge range of ethernet drivers.
</para>	

<para>
Alan continued to develop the networking code and through the aid of
other people added support for a multitude of other protocols such
as AX.25, IPX, PPP (Michael Callahan and Al Longyear), and AX.25/NetRom/Rose
protcol set (Jonathan Naylor).
</para>	

<para>
While the current state of Linux networking is extremely stable (and
in some cases surpasses the capabilities and performance of commercial
implementations of Linux), there still seems to be significant issues with
regards to driver development. This is most especially the case with regards
to wireless driver development where while most internal cards are supported
there a small minority where support is non-existant and companies seem
to be unwilling to disclose enough information regarding the card to develop
something that is workeable.
</para>	

<para>
<screen>
Linux Networking HOWTO, http://tldp.org/HOWTO/NET3-4-HOWTO.html
</screen>
</para>

----------

<para>

<![CDATA[
  5.1.4.  IP Addresses, an Explanation.

  Internet Protocol Addresses are composed of four bytes. The convention
  is to write addresses in what is called `dotted decimal notation'. In
  this form each byte is converted to a decimal number (0-255) dropping
  any leading zero's unless the number is zero and written with each
  byte separated by a `.' character. By convention each interface of a
  host or router has an IP address. It is legal for the same IP address
  to be used on each interface of a single machine in some circumstances
  but usually each interface will have its own address.

  Internet Protocol Networks are contiguous sequences of IP addresses.
  All addresses within a network have a number of digits within the
  address in common. The portion of the address that is common amongst
  all addresses within the network is called the `network portion' of
  the address. The remaining digits are called the `host portion'. The
  number of bits that are shared by all addresses within a network is
  called the netmask and it is role of the netmask to determine which
  addresses belong to the network it is applied to and which don't. For
  example, consider the following:



               -----------------  ---------------
               Host Address       192.168.110.23
               Network Mask       255.255.255.0
               Network Portion    192.168.110.
               Host portion                  .23
               -----------------  ---------------
               Network Address    192.168.110.0
               Broadcast Address  192.168.110.255
               -----------------  ---------------



  Any address that is 'bitwise anded' with its netmask will reveal the
  address of the network it belongs to. The network address is therefore
  always the lowest numbered address within the range of addresses on
  the network and always has the host portion of the address coded all
  zeroes.

  The broadcast address is a special address that every host on the
  network listens to in addition to its own unique address. This address
  is the one that datagrams are sent to if every host on the network is
  meant to receive it. Certain types of data like routing information
  and warning messages are transmitted to the broadcast address so that
  every host on the network can receive it simultaneously. There are two
  commonly used standards for what the broadcast address should be. The
  most widely accepted one is to use the highest possible address on the
  network as the broadcast address.  In the example above this would be
  192.168.110.255. For some reason other sites have adopted the
  convention of using the network address as the broadcast address. In
  practice it doesn't matter very much which you use but you must make
  sure that every host on the network is configured with the same
  broadcast address.

  For administrative reasons some time early in the development of the
  IP protocol some arbitrary groups of addresses were formed into
  networks and these networks were grouped into what are called classes.
  These classes provide a number of standard size networks that could be
  allocated. The ranges allocated are:



          ----------------------------------------------------------
          | Network | Netmask       | Network Addresses            |
          | Class   |               |                              |
          ----------------------------------------------------------
          |    A    | 255.0.0.0     | 0.0.0.0    - 127.255.255.255 |
          |    B    | 255.255.0.0   | 128.0.0.0  - 191.255.255.255 |
          |    C    | 255.255.255.0 | 192.0.0.0  - 223.255.255.255 |
          |Multicast| 240.0.0.0     | 224.0.0.0  - 239.255.255.255 |
          ----------------------------------------------------------



  What addresses you should use depends on exactly what it is that you
  are doing. You may have to use a combination of the following
  activities to get all the addresses you need:



     Installing a linux machine on an existing IP network
        If you wish to install a linux machine onto an existing IP
        network then you should contact whoever administers the network
        and ask them for the following information:


     ·  Host IP Address

     ·  IP network address

     ·  IP broadcast address

     ·  IP netmask

     ·  Router address

     ·  Domain Name Server Address


        You should then configure your linux network device with those
        details.  You can not make them up and expect your configuration
        to work.


     Building a brand new network that will never connect to the
        Internet" If you are building a private network and you never
        intend that network to be connected to the Internet then you can
        choose whatever addresses you like.  However, for safety and
        consistency reasons there have been some IP network addresses
        that have been reserved specifically for this purpose. These are
        specified in RFC1597 and are as follows:



             -----------------------------------------------------------
             |         RESERVED PRIVATE NETWORK ALLOCATIONS            |
             -----------------------------------------------------------
             | Network | Netmask       | Network Addresses             |
             | Class   |               |                               |
             -----------------------------------------------------------
             |    A    | 255.0.0.0     | 10.0.0.0    - 10.255.255.255  |
             |    B    | 255.255.0.0   | 172.16.0.0  - 172.31.255.255  |
             |    C    | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
             -----------------------------------------------------------



     You should first decide how large you want your network to be and
     then choose as many of the addresses as you require.


  5.2.  Where should I put the configuration commands ?

  There are a few different approaches to Linux system boot procedures.
  After the kernel boots, it always executes a program called `init'.
  The init program then reads its configuration file called /etc/inittab
  and commences the boot process. There are a few different flavours of
  init around, although everyone is now converging to the System V
  (Five) flavor, developed by Miguel van Smoorenburg.

  Despite the fact that the init program is always the same, the setup
  of system boot is organized in a different way by each distribution.

  Usually the /etc/inittab file contains an entry looking something
  like:



               si::sysinit:/etc/init.d/boot



  This line specifies the name of the shell script file that actually
  manages the boot sequence. This file is somewhat equivalent to the
  AUTOEXEC.BAT file in MS-DOS.

  There are usually other scripts that are called by the boot script and
  often the network is configured within one of many of these.

  The following table may be used as a guide for your system:



       ---------------------------------------------------------------------------
       Distrib. | Interface Config/Routing          | Server Initialization
       ---------------------------------------------------------------------------
       Debian   | /etc/init.d/network               | /etc/rc2.d/*
       ---------------------------------------------------------------------------
       Slackware| /etc/rc.d/rc.inet1                | /etc/rc.d/rc.inet2
       ---------------------------------------------------------------------------
       RedHat   | /etc/rc.d/init.d/network          | /etc/rc.d/rc3.d/*
       ---------------------------------------------------------------------------



  Note that Debian and Red Hat use a whole directory to host scripts
  that fire up system services (and usually information does not lie
  within these files, for example Red Hat systems store all of system
  configuration in files under /etc/sysconfig, whence it is retrieved by
  boot scripts). If you want to grasp the details of the boot process,
  my suggestion is to check /etc/inittab and the documentation that
  accompanies init. Linux Journal is also going to publish an article
  about system initialization, and this document will point to it as
  soon as it is available on the web.

  Most modern distributions include a program that will allow you to
  configure many of the common sorts of network interfaces. If you have
  one of these then you should see if it will do what you want before
  attempting a manual configuration.



               -----------------------------------------
               Distrib   | Network configuration program
               -----------------------------------------
               RedHat    | /usr/bin/netcfg
               Slackware | /sbin/netconfig
               -----------------------------------------



  5.3.  Creating your network interfaces.

  In many Unix operating systems the network devices have appearances in
  the /dev directory. This is not so in Linux. In Linux the network
  devices are created dynamically in software and do not require device
  files to be present.

  In the majority of cases the network device is automatically created
  by the device driver while it is initializing and has located your
  hardware. For example, the ethernet device driver creates eth[0..n]
  interfaces sequentially as it locates your ethernet hardware. The
  first ethernet card found becomes eth0, the second eth1 etc.

  In some cases though, notably slip and ppp, the network devices are
  created through the action of some user program. The same sequential
  device numbering applies, but the devices are not created
  automatically at boot time. The reason for this is that unlike
  ethernet devices, the number of active slip or ppp devices may vary
  during the uptime of the machine. These cases will be covered in more
  detail in later sections.

  5.4.  Configuring a network interface.

  When you have all of the programs you need and your address and
  network information you can configure your network interfaces. When we
  talk about configuring a network interface we are talking about the
  process of assigning appropriate addresses to a network device and to
  setting appropriate values for other configurable parameters of a
  network device. The program most commonly used to do this is the
  ifconfig (interface configure) command.

  Typically you would use a command similar to the following:

          root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up

  In this case I'm configuring an ethernet interface `eth0' with the IP
  address `192.168.0.1' and a network mask of `255.255.255.0'.  The `up'
  that trails the command tells the interface that it should become
  active, but can usually be omitted, as it is the default. To shutdown
  an interface, you can just call ``ifconfig eth0 down''.

  The kernel assumes certain defaults when configuring interfaces. For
  example, you may specify the network address and broadcast address for
  an interface, but if you don't, as in my example above, then the
  kernel will make reasonable guesses as to what they should be based on
  the netmask you supply and if you don't supply a netmask then on the
  network class of the IP address configured.  In my example the kernel
  would assume that it is a class-C network being configured on the
  interface and configure a network address of `192.168.0.0' and a
  broadcast address of `192.168.0.255' for the interface.

  There are many other options to the ifconfig command. The most
  important of these are:

     up this option activates an interface (and is the default).

     down
        this option deactivates an interface.

     [-]arp
        this option enables or disables use of the address resolution
        protocol on this interface

     [-]allmulti
        this option enables or disables the reception of all hardware
        multicast packets. Hardware multicast enables groups of hosts to
        receive packets addressed to special destinations. This may be
        of importance if you are using applications like desktop
        videoconferencing but is normally not used.

     mtu N
        this parameter allows you to set the MTU of this device.

     netmask <addr>
        this parameter allows you to set the network mask of the network
        this device belongs to.

     irq <addr>
        this parameter only works on certain types of hardware and
        allows you to set the IRQ of the hardware of this device.

     [-]broadcast [addr]
        this parameter allows you to enable and set the accepting of
        datagrams destined to the broadcast address, or to disable
        reception of these datagrams.

     [-]pointopoint [addr]
        this parameter allows you to set the address of the machine at
        the remote end of a point to point link such as for slip or ppp.

     hw <type> <addr>
        this parameter allows you to set the hardware address of certain
        types of network devices. This is not often useful for ethernet,
        but is useful for other network types such as AX.25.


  You may use the ifconfig command on any network interface. Some user
  programs such as pppd and dip automatically configure the network
  devices as they create them, so manual use of ifconfig is unnecessary.

  5.5.  Configuring your Name Resolver.

  The `Name Resolver' is a part of the linux standard library. Its prime
  function is to provide a service to convert human-friendly hostnames
  like `ftp.funet.fi' into machine friendly IP addresses such as
  128.214.248.6.

  5.5.1.  What's in a name ?

  You will probably be familiar with the appearance of Internet host
  names, but may not understand how they are constructed, or
  deconstructed. Internet domain names are hierarchical in nature, that
  is, they have a tree-like structure. A `domain' is a family, or group
  of names. A `domain' may be broken down into `subdomain'. A `toplevel
  domain' is a domain that is not a subdomain. The Top Level Domains are
  specified in RFC-920. Some examples of the most common top level
  domains are:


     COM
        Commercial Organizations

     EDU
        Educational Organizations

     GOV
        Government Organizations

     MIL
        Military Organizations

     ORG
        Other organizations

     NET
        Internet-Related Organizations

     Country Designator
        these are two letters codes that represent a particular country.


  For historical reasons most domains belonging to one of the non-
  country based top level domains were used by organizations within the
  United States, although the United States also has its own country
  code `.us'. This is not true any more for .com and .org domains, which
  are commonly used by non-us companies.

  Each of these top level domains has subdomains. The top level domains
  based on country name are often next broken down into subdomains based
  on the com, edu, gov, mil and org domains. So for example you end up
  with: com.au and gov.au for commercial and government organizations in
  Australia; note that this is not a general rule, as actual policies
  depend on the naming authority for each domain.

  The next level of division usually represents the name of the
  organization.  Further subdomains vary in nature, often the next level
  of subdomain is based on the departmental structure of the
  organization but it may be based on any criterion considered
  reasonable and meaningful by the network administrators for the
  organization.

  The very left-most portion of the name is always the unique name
  assigned to the host machine and is called the `hostname', the portion
  of the name to the right of the hostname is called the `domainname'
  and the complete name is called the `Fully Qualified Domain Name'.

  To use Terry's host as an example, the fully qualified domain name is
  `perf.no.itg.telstra.com.au'. This means that the host name is `perf'
  and the domain name is `no.itg.telstra.com.au'. The domain name is
  based on a top level domain based on his country, Australia and as his
  email address belongs to a commercial organization, `.com' is there as
  the next level domain. The name of the company is (was) `telstra' and
  their internal naming structure is based on organizational structure,
  in this case the machine belongs to the Information Technology Group,
  Network Operations section.

  Usually, the names are fairly shorter; for example, my ISP is called
  ``systemy.it'' and my non-profit organization is called ``linux.it'',
  without any com and org subdomain, so that my own host is just called
  ``morgana.systemy.it'' and rubini@linux.it is a valid email address.
  Note that the owner of a domain has the rights to register hostnames
  as well as subdomains; for example, the LUG I belong to uses the
  domain pluto.linux.it, because the owners of linux.it agreed to open a
  subdomain for the LUG.

  5.5.2.  What information you will need.

  You will need to know what domain your hosts name will belong to. The
  name resolver software provides this name translation service by
  making requests to a `Domain Name Server', so you will need to know
  the IP address of a local nameserver that you can use.

  There are three files you need to edit, I'll cover each of these in
  turn.

  5.5.3.  /etc/resolv.conf

  The /etc/resolv.conf is the main configuration file for the name
  resolver code. Its format is quite simple. It is a text file with one
  keyword per line. There are three keywords typically used, they are:


     domain
        this keyword specifies the local domain name.

     search
        this keyword specifies a list of alternate domain names to
        search for a hostname

     nameserver
        this keyword, which may be used many times, specifies an IP
        address of a domain name server to query when resolving names


  An example /etc/resolv.conf might look something like:



               domain maths.wu.edu.au
               search maths.wu.edu.au wu.edu.au
               nameserver 192.168.10.1
               nameserver 192.168.12.1



  This example specifies that the default domain name to append to
  unqualified names (ie hostnames supplied without a domain) is
  maths.wu.edu.au and that if the host is not found in that domain to
  also try the wu.edu.au domain directly. Two nameservers entry are
  supplied, each of which may be called upon by the name resolver code
  to resolve the name.

  5.5.4.  /etc/host.conf

  The /etc/host.conf file is where you configure some items that govern
  the behaviour of the name resolver code. The format of this file is
  described in detail in the `resolv+' man page. In nearly all
  circumstances the following example will work for you:



               order hosts,bind
               multi on



  This configuration tells the name resolver to check the /etc/hosts
  file before attempting to query a nameserver and to return all valid
  addresses for a host found in the /etc/hosts file instead of just the
  first.

  5.5.5.  /etc/hosts

  The /etc/hosts file is where you put the name and IP address of local
  hosts. If you place a host in this file then you do not need to query
  the domain name server to get its IP Address. The disadvantage of
  doing this is that you must keep this file up to date yourself if the
  IP address for that host changes. In a well managed system the only
  hostnames that usually appear in this file are an entry for the
  loopback interface and the local hosts name.



               # /etc/hosts
               127.0.0.1      localhost loopback
               192.168.0.1    this.host.name



  You may specify more than one host name per line as demonstrated by
  the first entry, which is a standard entry for the loopback interface.

  5.5.6.  Running a name server

  If you want to run a local nameserver, you can do it easily. Please
  refer to the DNS-HOWTO and to any documents included in your version
  of BIND (Berkeley Internet Name Domain).

  5.6.  Configuring your loopback interface.

  The `loopback' interface is a special type of interface that allows
  you to make connections to yourself. There are various reasons why you
  might want to do this, for example, you may wish to test some network
  software without interfering with anybody else on your network. By
  convention the IP address `127.0.0.1' has been assigned specifically
  for loopback. So no matter what machine you go to, if you open a
  telnet connection to 127.0.0.1 you will always reach the local host.

  Configuring the loopback interface is simple and you should ensure you
  do (but note that this task is usually performed by the standard
  initialization scripts).



               root# ifconfig lo 127.0.0.1
               root# route add -host 127.0.0.1 lo



  We'll talk more about the route command in the next section.

  5.7.  Routing.

  Routing is a big topic. It is easily possible to write large volumes
  of text about it. Most of you will have fairly simple routing
  requirements, some of you will not. I will cover some basic
  fundamentals of routing only.  If you are interested in more detailed
  information then I suggest you refer to the references provided at the
  start of the document.

  Let's start with a definition. What is IP routing ? Here is one that
  I'm using:


       IP Routing is the process by which a host with multiple net­
       work connections decides where to deliver IP datagrams it
       has received.



  It might be useful to illustrate this with an example. Imagine a
  typical office router, it might have a PPP link off the Internet, a
  number of ethernet segments feeding the workstations and another PPP
  link off to another office. When the router receives a datagram on any
  of its network connections, routing is the mechanism that it uses to
  determine which interface it should send the datagram to next. Simple
  hosts also need to route, all Internet hosts have two network devices,
  one is the loopback interface described above and the other is the one
  it uses to talk to the rest of the network, perhaps an ethernet,
  perhaps a PPP or SLIP serial interface.

  Ok, so how does routing work ? Each host keeps a special list of
  routing rules, called a routing table. This table contains rows which
  typically contain at least three fields, the first is a destination
  address, the second is the name of the interface to which the datagram
  is to be routed and the third is optionally the IP address of another
  machine which will carry the datagram on its next step through the
  network. In linux you can see this table by using the following
  command:



               user% cat /proc/net/route



  or by using either of the following commands:



               user% /sbin/route -n
               user% netstat -r



  The routing process is fairly simple: an incoming datagram is
  received, the destination address (who it is for) is examined and
  compared with each entry in the table. The entry that best matches
  that address is selected and the datagram is forwarded to the
  specified interface. If the gateway field is filled then the datagram
  is forwarded to that host via the specified interface, otherwise the
  destination address is assumed to be on the network supported by the
  interface.

  To manipulate this table a special command is used. This command takes
  command line arguments and converts them into kernel system calls that
  request the kernel to add, delete or modify entries in the routing
  table.  The command is called `route'.

  A simple example. Imagine you have an ethernet network. You've been
  told it is a class-C network with an address of 192.168.1.0. You've
  been supplied with an IP address of 192.168.1.10 for your use and have
  been told that 192.168.1.1 is a router connected to the Internet.

  The first step is to configure the interface as described earlier. You
  would use a command like:



               root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up



  You now need to add an entry into the routing table to tell the kernel
  that datagrams for all hosts with addresses that match 192.168.1.*
  should be sent to the ethernet device. You would use a command similar
  to:



               root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0



  Note the use of the `-net' argument to tell the route program that
  this entry is a network route. Your other choice here is a `-host'
  route which is a route that is specific to one IP address.

  This route will enable you to establish IP connections with all of the
  hosts on your ethernet segment. But what about all of the IP hosts
  that aren't on your ethernet segment ?


  It would be a very difficult job to have to add routes to every
  possible destination network, so there is a special trick that is used
  to simplify this task. The trick is called the `default' route. The
  default route matches every possible destination, but poorly, so that
  if any other entry exists that matches the required address it will be
  used instead of the default route. The idea of the default route is
  simply to enable you to say "and everything else should go here". In
  the example I've contrived you would use an entry like:



               root# route add default gw 192.168.1.1 eth0



  The `gw' argument tells the route command that the next argument is
  the IP address, or name, of a gateway or router machine which all
  datagrams matching this entry should be directed to for further
  routing.

  So, your complete configuration would look like:



               root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
               root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
               root# route add default gw 192.168.1.1 eth0



  If you take a close look at your network `rc' files you will find that
  at least one of them looks very similar to this. This is a very common
  configuration.

  Let's now look at a slightly more complicated routing configuration.
  Let's imagine we are configuring the router we looked at earlier, the
  one supporting the PPP link to the Internet and the lan segments
  feeding the workstations in the office. Lets imagine the router has
  three ethernet segments and one PPP link. Our routing configuration
  would look something like:



               root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
               root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
               root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
               root# route add default ppp0



  Each of the workstations would use the simpler form presented above,
  only the router needs to specify each of the network routes separately
  because for the workstations the default route mechanism will capture
  all of them letting the router worry about splitting them up
  appropriately. You may be wondering why the default route presented
  doesn't specify a `gw'.  The reason for this is simple, serial link
  protocols such as PPP and slip only ever have two hosts on their
  network, one at each end. To specify the host at the other end of the
  link as the gateway is pointless and redundant as there is no other
  choice, so you do not need to specify a gateway for these types of
  network connections. Other network types such as ethernet, arcnet or
  token ring do require the gateway to be specified as these networks
  support large numbers of hosts on them.

  5.7.1.  So what does the routed  program do ?

  The routing configuration described above is best suited to simple
  network arrangements where there are only ever single possible paths
  to destinations.  When you have a more complex network arrangement
  things get a little more complicated. Fortunately for most of you this
  won't be an issue.

  The big problem with `manual routing' or `static routing' as
  described, is that if a machine or link fails in your network then the
  only way you can direct your datagrams another way, if another way
  exists, is by manually intervening and executing the appropriate
  commands. Naturally this is clumsy, slow, impractical and hazard
  prone. Various techniques have been developed to automatically adjust
  routing tables in the event of network failures where there are
  alternate routes, all of these techniques are loosely grouped by the
  term `dynamic routing protocols'.

  You may have heard of some of the more common dynamic routing
  protocols. The most common are probably RIP (Routing Information
  Protocol) and OSPF (Open Shortest Path First Protocol). The Routing
  Information Protocol is very common on small networks such as small-
  medium sized corporate networks or building networks. OSPF is more
  modern and more capable at handling large network configurations and
  better suited to environments where there is a large number of
  possible paths through the network. Common implementations of these
  protocols are: `routed' - RIP and `gated' - RIP, OSPF and others.  The
  `routed' program is normally supplied with your Linux distribution or
  is included in the `NetKit' package detailed above.

  An example of where and how you might use a dynamic routing protocol
  might look something like the following:



      192.168.1.0 /                         192.168.2.0 /
         255.255.255.0                         255.255.255.0
       -                                     -
       |                                     |
       |   /-----\                 /-----\   |
       |   |     |ppp0   //    ppp0|     |   |
  eth0 |---|  A  |------//---------|  B  |---| eth0
       |   |     |     //          |     |   |
       |   \-----/                 \-----/   |
       |      \ ppp1             ppp1 /      |
       -       \                     /       -
                \                   /
                 \                 /
                  \               /
                   \             /
                    \           /
                     \         /
                      \       /
                       \     /
                    ppp0\   /ppp1
                       /-----\
                       |     |
                       |  C  |
                       |     |
                       \-----/
                          |eth0
                          |
                     |---------|
                     192.168.3.0 /
                        255.255.255.0



  We have three routers A, B and C. Each supports one ethernet segment
  with a Class C IP network (netmask 255.255.255.0). Each router also
  has a PPP link to each of the other routers. The network forms a
  triangle.

  It should be clear that the routing table at router A could look like:



               root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
               root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
               root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1



  This would work just fine until the link between router A and B should
  fail.  If that link failed then with the routing entry shown above
  hosts on the ethernet segment of A could not reach hosts on the
  ethernet segment on B because their datagram would be directed to
  router A's ppp0 link which is broken. They could still continue to
  talk to hosts on the ethernet segment of C and hosts on the C's
  ethernet segment could still talk to hosts on B's ethernet segment
  because the link between B and C is still intact.

  But wait, if A can talk to C and C can still talk to B, why shouldn't
  A route its datagrams for B via C and let C send them to B ? This is
  exactly the sort of problem that dynamic routing protocols like RIP
  were designed to solve. If each of the routers A, B and C were running
  a routing daemon then their routing tables would be automatically
  adjusted to reflect the new state of the network should any one of the
  links in the network fail.  To configure such a network is simple, at
  each router you need only do two things. In this case for Router A:

               root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
               root# /usr/sbin/routed

  The `routed' routing daemon automatically finds all active network
  ports when it starts and sends and listens for messages on each of the
  network devices to allow it to determine and update the routing table
  on the host.

  This has been a very brief explanation of dynamic routing and where
  you would use it. If you want more information then you should refer
  to the suggested references listed at the top of the document.

  The important points relating to dynamic routing are:


  1. You only need to run a dynamic routing protocol daemon when your
     Linux machine has the possibility of selecting multiple possible
     routes to a destination.  An example of this would be if you plan
     to use IP Masquerading.


  2. The dynamic routing daemon will automatically modify your routing
     table to adjust to changes in your network.

  3. RIP is suited to small to medium sized networks.


  5.8.  Configuring your network servers and services.

  Network servers and services are those programs that allow a remote
  user to make user of your Linux machine. Server programs listen on
  network ports.  Network ports are a means of addressing a particular
  service on any particular host and are how a server knows the
  difference between an incoming telnet connection and an incoming ftp
  connection. The remote user establishes a network connection to your
  machine and the server program, the network daemon program, listening
  on that port accepts the connection and executes. There are two ways
  that network daemons may operate. Both are commonly employed in
  practice. The two ways are:



     standalone
        the network daemon program listens on the designated network
        port and when an incoming connection is made it manages the
        network connection itself to provide the service.


     slave to the inetd server
        the inetd server is a special network daemon program that
        specializes in managing incoming network connections. It has a
        configuration file which tells it what program needs to be run
        when an incoming connection is received. Any service port may be
        configured for either of the tcp or udp protcols. The ports are
        described in another file that we will talk about soon.


  There are two important files that we need to configure. They are the
  /etc/services file which assigns names to port numbers and the
  /etc/inetd.conf file which is the configuration file for the inetd
  network daemon.

  5.8.1.  /etc/services

  The /etc/services file is a simple database that associates a human
  friendly name to a machine friendly service port. Its format is quite
  simple. The file is a text file with each line representing and entry
  in the database. Each entry is comprised of three fields separated by
  any number of whitespace (tab or space) characters. The fields are:


    name      port/protocol        aliases     # comment



     name
        a single word name that represents the service being described.


     port/protocol
        this field is split into two subfields.



     port
        a number that specifies the port number the named service will
        be available on. Most of the common services have assigned
        service numbers. These are described in RFC-1340.


     protocol
        this subfield may be set to either tcp or udp.

        It is important to note that an entry of 18/tcp is very
        different from an entry of 18/udp and that there is no technical
        reason why the same service needs to exist on both. Normally
        common sense prevails and it is only if a particular service is
        available via both tcp and udp that you will see an entry for
        both.


     aliases
        other names that may be used to refer to this service entry.


  Any text appearing in a line after a `#' character is ignored and
  treated as a comment.

  5.8.1.1.  An example /etc/services  file.

  All modern linux distributions provide a good /etc/services file.
  Just in case you happen to be building a machine from the ground up,
  here is a copy of the /etc/services file supplied with an old Debian
  distribution:


  # /etc/services:
  # $Id$
  #
  # Network services, Internet style
  #
  # Note that it is presently the policy of IANA to assign a single well-known
  # port number for both TCP and UDP; hence, most entries here have two entries
  # even if the protocol doesn't support UDP operations.
  # Updated from RFC 1340, ``Assigned Numbers'' (July 1992).  Not all ports
  # are included, only the more common ones.

  tcpmux          1/tcp                           # TCP port service multiplexer
  echo            7/tcp
  echo            7/udp
  discard         9/tcp           sink null
  discard         9/udp           sink null
  systat          11/tcp          users
  daytime         13/tcp
  daytime         13/udp
  netstat         15/tcp
  qotd            17/tcp          quote
  msp             18/tcp                          # message send protocol
  msp             18/udp                          # message send protocol
  chargen         19/tcp          ttytst source
  chargen         19/udp          ttytst source
  ftp-data        20/tcp
  ftp             21/tcp
  ssh             22/tcp                          # SSH Remote Login Protocol
  ssh             22/udp                          # SSH Remote Login Protocol
  telnet          23/tcp
  # 24 - private
  smtp            25/tcp          mail
  # 26 - unassigned
  time            37/tcp          timserver
  time            37/udp          timserver
  rlp             39/udp          resource        # resource location
  nameserver      42/tcp          name            # IEN 116
  whois           43/tcp          nicname
  re-mail-ck      50/tcp                          # Remote Mail Checking Protocol
  re-mail-ck      50/udp                          # Remote Mail Checking Protocol
  domain          53/tcp          nameserver      # name-domain server
  domain          53/udp          nameserver
  mtp             57/tcp                          # deprecated
  bootps          67/tcp                          # BOOTP server
  bootps          67/udp
  bootpc          68/tcp                          # BOOTP client
  bootpc          68/udp
  tftp            69/udp
  gopher          70/tcp                          # Internet Gopher
  gopher          70/udp
  rje             77/tcp          netrjs
  finger          79/tcp
  www             80/tcp          http            # WorldWideWeb HTTP
  www             80/udp                          # HyperText Transfer Protocol
  link            87/tcp          ttylink
  kerberos        88/tcp          kerberos5 krb5  # Kerberos v5
  kerberos        88/udp          kerberos5 krb5  # Kerberos v5
  supdup          95/tcp
  # 100 - reserved
  hostnames       101/tcp         hostname        # usually from sri-nic
  iso-tsap        102/tcp         tsap            # part of ISODE.
  csnet-ns        105/tcp         cso-ns          # also used by CSO name server
  csnet-ns        105/udp         cso-ns
  rtelnet         107/tcp                         # Remote Telnet
  rtelnet         107/udp
  pop-2           109/tcp         postoffice      # POP version 2
  pop-2           109/udp
  pop-3           110/tcp                         # POP version 3
  pop-3           110/udp
  sunrpc          111/tcp         portmapper      # RPC 4.0 portmapper TCP
  sunrpc          111/udp         portmapper      # RPC 4.0 portmapper UDP
  auth            113/tcp         authentication tap ident
  sftp            115/tcp
  uucp-path       117/tcp
  nntp            119/tcp         readnews untp   # USENET News Transfer Protocol
  ntp             123/tcp
  ntp             123/udp                         # Network Time Protocol
  netbios-ns      137/tcp                         # NETBIOS Name Service
  netbios-ns      137/udp
  netbios-dgm     138/tcp                         # NETBIOS Datagram Service
  netbios-dgm     138/udp
  netbios-ssn     139/tcp                         # NETBIOS session service
  netbios-ssn     139/udp
  imap2           143/tcp                         # Interim Mail Access Proto v2
  imap2           143/udp
  snmp            161/udp                         # Simple Net Mgmt Proto
  snmp-trap       162/udp         snmptrap        # Traps for SNMP
  cmip-man        163/tcp                         # ISO mgmt over IP (CMOT)
  cmip-man        163/udp
  cmip-agent      164/tcp
  cmip-agent      164/udp
  xdmcp           177/tcp                         # X Display Mgr. Control Proto
  xdmcp           177/udp
  nextstep        178/tcp         NeXTStep NextStep       # NeXTStep window
  nextstep        178/udp         NeXTStep NextStep       # server
  bgp             179/tcp                         # Border Gateway Proto.
  bgp             179/udp
  prospero        191/tcp                         # Cliff Neuman's Prospero
  prospero        191/udp
  irc             194/tcp                         # Internet Relay Chat
  irc             194/udp
  smux            199/tcp                         # SNMP Unix Multiplexer
  smux            199/udp
  at-rtmp         201/tcp                         # AppleTalk routing
  at-rtmp         201/udp
  at-nbp          202/tcp                         # AppleTalk name binding
  at-nbp          202/udp
  at-echo         204/tcp                         # AppleTalk echo
  at-echo         204/udp
  at-zis          206/tcp                         # AppleTalk zone information
  at-zis          206/udp
  z3950           210/tcp         wais            # NISO Z39.50 database
  z3950           210/udp         wais
  ipx             213/tcp                         # IPX
  ipx             213/udp
  imap3           220/tcp                         # Interactive Mail Access
  imap3           220/udp                         # Protocol v3
  ulistserv       372/tcp                         # UNIX Listserv
  ulistserv       372/udp
  #
  # UNIX specific services
  #
  exec            512/tcp
  biff            512/udp         comsat
  login           513/tcp
  who             513/udp         whod
  shell           514/tcp         cmd             # no passwords used
  syslog          514/udp
  printer         515/tcp         spooler         # line printer spooler
  talk            517/udp
  ntalk           518/udp
  route           520/udp         router routed   # RIP
  timed           525/udp         timeserver
  tempo           526/tcp         newdate
  courier         530/tcp         rpc
  conference      531/tcp         chat
  netnews         532/tcp         readnews
  netwall         533/udp                         # -for emergency broadcasts
  uucp            540/tcp         uucpd           # uucp daemon
  remotefs        556/tcp         rfs_server rfs  # Brunhoff remote filesystem
  klogin          543/tcp                         # Kerberized `rlogin' (v5)
  kshell          544/tcp         krcmd           # Kerberized `rsh' (v5)
  kerberos-adm    749/tcp                         # Kerberos `kadmin' (v5)
  #
  webster         765/tcp                         # Network dictionary
  webster         765/udp
  #
  # From ``Assigned Numbers'':
  #
  #> The Registered Ports are not controlled by the IANA and on most systems
  #> can be used by ordinary user processes or programs executed by ordinary
  #> users.
  #
  #> Ports are used in the TCP [45,106] to name the ends of logical
  #> connections which carry long term conversations.  For the purpose of
  #> providing services to unknown callers, a service contact port is
  #> defined.  This list specifies the port used by the server process as its
  #> contact port.  While the IANA can not control uses of these ports it
  #> does register or list uses of these ports as a convenience to the
  #> community.
  #
  ingreslock      1524/tcp
  ingreslock      1524/udp
  prospero-np     1525/tcp                # Prospero non-privileged
  prospero-np     1525/udp
  rfe             5002/tcp                # Radio Free Ethernet
  rfe             5002/udp                # Actually uses UDP only
  bbs             7000/tcp                # BBS service
  #
  #
  # Kerberos (Project Athena/MIT) services
  # Note that these are for Kerberos v4 and are unofficial.  Sites running
  # v4 should uncomment these and comment out the v5 entries above.
  #
  kerberos4       750/udp         kdc     # Kerberos (server) udp
  kerberos4       750/tcp         kdc     # Kerberos (server) tcp
  kerberos_master 751/udp                 # Kerberos authentication
  kerberos_master 751/tcp                 # Kerberos authentication
  passwd_server   752/udp                 # Kerberos passwd server
  krb_prop        754/tcp                 # Kerberos slave propagation
  krbupdate       760/tcp         kreg    # Kerberos registration
  kpasswd         761/tcp         kpwd    # Kerberos "passwd"
  kpop            1109/tcp                # Pop with Kerberos
  knetd           2053/tcp                # Kerberos de-multiplexor
  zephyr-srv      2102/udp                # Zephyr server
  zephyr-clt      2103/udp                # Zephyr serv-hm connection
  zephyr-hm       2104/udp                # Zephyr hostmanager
  eklogin         2105/tcp                # Kerberos encrypted rlogin
  #
  # Unofficial but necessary (for NetBSD) services
  #
  supfilesrv      871/tcp                 # SUP server
  supfiledbg      1127/tcp                # SUP debugging
  #
  # Datagram Delivery Protocol services
  #
  rtmp            1/ddp                   # Routing Table Maintenance Protocol
  nbp             2/ddp                   # Name Binding Protocol
  echo            4/ddp                   # AppleTalk Echo Protocol
  zip             6/ddp                   # Zone Information Protocol
  #
  # Debian GNU/Linux services
  rmtcfg          1236/tcp                # Gracilis Packeten remote config server
  xtel            1313/tcp                # french minitel
  cfinger         2003/tcp                # GNU Finger
  postgres        4321/tcp                # POSTGRES
  mandelspawn     9359/udp        mandelbrot      # network mandelbrot

  # Local services



  In the real world, the actual file is always growing as new services
  are being created. If you fear your own copy is incomplete, I'd
  suggest to copy a new /etc/services from a recent distribution.

  5.8.2.  /etc/inetd.conf

  The /etc/inetd.conf file is the configuration file for the inetd
  server daemon. Its function is to tell inetd what to do when it
  receives a connection request for a particular service. For each
  service that you wish to accept connections for you must tell inetd
  what network server daemon to run and how to run it.

  Its format is also fairly simple. It is a text file with each line
  describing a service that you wish to provide. Any text in a line
  following a `#' is ignored and considered a comment. Each line
  contains seven fields separated by any number of whitespace (tab or
  space) characters. The general format is as follows:



         service  socket_type  proto  flags  user  server_path  server_args



     service
        is the service relevant to this configuration as taken from the
        /etc/services file.


     socket_type
        this field describes the type of socket that this entry will
        consider relevant, allowable values are: stream, dgram, raw,
        rdm, or seqpacket. This is a little technical in nature, but as
        a rule of thumb nearly all tcp based services use stream and
        nearly all udp based services use dgram. It is only very special
        types of server daemons that would use any of the other values.


     proto
        the protocol to considered valid for this entry. This should
        match the appropriate entry in the /etc/services file and will
        typically be either tcp or udp. Sun RPC (Remote Procedure Call)
        based servers will use rpc/tcp or rpc/udp.


     flags
        there are really only two possible settings for this field.
        This field setting tells inetd whether the network server
        program frees the socket after it has been started and therefore
        whether inetd can start another one on the next connection
        request, or whether inetd should wait and assume that any server
        daemon already running will handle the new connection request.
        Again this is a little tricky to work out, but as a rule of
        thumb all tcp servers should have this entry set to nowait and
        most udp servers should have this entry set to wait. Be warned
        there are some notable exceptions to this, so let the example
        guide you if you are not sure.


     user
        this field describes which user account from /etc/passwd will be
        set as the owner of the network daemon when it is started. This
        is often useful if you want to safeguard against security risks.
        You can set the user of an entry to the nobody user so that if
        the network server security is breached the possible damage is
        minimized.  Typically this field is set to root though, because
        many servers require root privileges in order to function
        correctly.


     server_path
        this field is pathname to the actual server program to execute
        for this entry.


     server_args
        this field comprises the rest of the line and is optional. This
        field is where you place any command line arguments that you
        wish to pass to the server daemon program when it is launched.


  5.8.2.1.  An example /etc/inetd.conf

  As for the /etc/services file all modern distributions will include a
  good /etc/inetd.conf file for you to work with. Here, for completeness
  is the /etc/inetd.conf file from the Debian distribution.



  # /etc/inetd.conf:  see inetd(8) for further informations.
  #
  # Internet server configuration database
  #
  #
  # Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
  #
  # <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
  #
  # Internal services
  #
  #echo           stream  tcp     nowait  root    internal
  #echo           dgram   udp     wait    root    internal
  discard         stream  tcp     nowait  root    internal
  discard         dgram   udp     wait    root    internal
  daytime         stream  tcp     nowait  root    internal
  daytime         dgram   udp     wait    root    internal
  #chargen        stream  tcp     nowait  root    internal
  #chargen        dgram   udp     wait    root    internal
  time            stream  tcp     nowait  root    internal
  time            dgram   udp     wait    root    internal
  #
  # These are standard services.
  #
  telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.telnetd
  ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.ftpd
  #fsp    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.fspd
  #
  # Shell, login, exec and talk are BSD protocols.
  #
  shell   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd
  login   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind
  #exec   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rexecd
  talk    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.talkd
  ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.ntalkd
  #
  # Mail, news and uucp services.
  #
  smtp    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.smtpd
  #nntp   stream  tcp     nowait  news    /usr/sbin/tcpd  /usr/sbin/in.nntpd
  #uucp   stream  tcp     nowait  uucp    /usr/sbin/tcpd  /usr/lib/uucp/uucico
  #comsat dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.comsat
  #
  # Pop et al
  #
  #pop-2  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop2d
  #pop-3  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop3d
  #
  # `cfinger' is for the GNU finger server available for Debian.  (NOTE: The
  # current implementation of the `finger' daemon allows it to be run as `root'.)
  #
  #cfinger stream tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.cfingerd
  #finger stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.fingerd
  #netstat        stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/netstat
  #systat stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/ps -auwwx
  #
  # Tftp service is provided primarily for booting.  Most sites
  # run this only on machines acting as "boot servers."
  #
  #tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd
  #tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd /boot
  #bootps dgram   udp     wait    root    /usr/sbin/bootpd        bootpd -i -t 120
  #
  # Kerberos authenticated services (these probably need to be corrected)
  #
  #klogin         stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k
  #eklogin        stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k -x
  #kshell         stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd -k
  #
  # Services run ONLY on the Kerberos server (these probably need to be corrected)
  #
  #krbupdate      stream tcp      nowait  root    /usr/sbin/tcpd  /usr/sbin/registerd
  #kpasswd        stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/kpasswdd
  #
  # RPC based services
  #
  #mountd/1       dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.mountd
  #rstatd/1-3     dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rstatd
  #rusersd/2-3    dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rusersd
  #walld/1        dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rwalld
  #
  # End of inetd.conf.
  ident           stream  tcp     nowait  nobody  /usr/sbin/identd        identd -i



  5.9.  Other miscellaneous network related configuration files.

  There are a number of miscellaneous files relating to network
  configuration under linux that you might be interested in. You may
  never have to modify these files, but it is worth describing them so
  you know what they contain and what they are for.

  5.9.1.  /etc/protocols

  The /etc/protocols file is a database that maps protocol id numbers
  against protocol names. This is used by programmers to allow them to
  specify protocols by name in their programs and also by some programs
  such as tcpdump to allow them to display names instead of numbers in
  their output. The general syntax of the file is:

         protocolname  number  aliases

  The /etc/protocols file supplied with the Debian distribution is as
  follows:

  # /etc/protocols:
  # $Id$
  #
  # Internet (IP) protocols
  #
  #       from: @(#)protocols     5.1 (Berkeley) 4/17/89
  #
  # Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).

  ip      0       IP              # internet protocol, pseudo protocol number
  icmp    1       ICMP            # internet control message protocol
  igmp    2       IGMP            # Internet Group Management
  ggp     3       GGP             # gateway-gateway protocol
  ipencap 4       IP-ENCAP        # IP encapsulated in IP (officially ``IP'')
  st      5       ST              # ST datagram mode
  tcp     6       TCP             # transmission control protocol
  egp     8       EGP             # exterior gateway protocol
  pup     12      PUP             # PARC universal packet protocol
  udp     17      UDP             # user datagram protocol
  hmp     20      HMP             # host monitoring protocol
  xns-idp 22      XNS-IDP         # Xerox NS IDP
  rdp     27      RDP             # "reliable datagram" protocol
  iso-tp4 29      ISO-TP4         # ISO Transport Protocol class 4
  xtp     36      XTP             # Xpress Tranfer Protocol
  ddp     37      DDP             # Datagram Delivery Protocol
  idpr-cmtp       39      IDPR-CMTP       # IDPR Control Message Transport
  rspf    73      RSPF            # Radio Shortest Path First.
  vmtp    81      VMTP            # Versatile Message Transport
  ospf    89      OSPFIGP         # Open Shortest Path First IGP
  ipip    94      IPIP            # Yet Another IP encapsulation
  encap   98      ENCAP           # Yet Another IP encapsulation

  5.9.2.  /etc/networks

  The /etc/networks file has a similar function to that of the
  /etc/hosts file. It provides a simple database of network names
  against network addresses. Its format differs in that there may be
  only two fields per line and that the fields are coded as:

         networkname networkaddress

  An example might look like:

               loopnet    127.0.0.0
               localnet   192.168.0.0
               amprnet    44.0.0.0

  When you use commands like the route command, if a destination is a
  network and that network has an entry in the /etc/networks file then
  the route command will display that network name instead of its
  address.

  5.10.  Network Security and access control.

  Let me start this section by warning you that securing your machine
  and network against malicious attack is a complex art. I do not
  consider myself an expert in this field at all and while the following
  mechanisms I describe will help, if you are serious about security
  then I recommend you do some research of your own into the subject.
  There are many good references on the Internet relating to the
  subject, including the Security-HOWTO

  An important rule of thumb is: `Don't run servers you don't intend to
  use'.  Many distributions come configured with all sorts of services
  configured and automatically started. To ensure even a minimum level
  of safety you should go through your /etc/inetd.conf file and comment
  out (place a `#' at the start of the line) any entries for services
  you don't intend to use.  Good candidates are services such as: shell,
  login, exec, uucp, ftp and informational services such as finger,
  netstat and systat.

  There are all sorts of security and access control mechanisms, I'll
  describe the most elementary of them.

  5.10.1.  /etc/ftpusers

  The /etc/ftpusers file is a simple mechanism that allows you to deny
  certain users from logging into your machine via ftp. The
  /etc/ftpusers file is read by the ftp daemon program (ftpd) when an
  incoming ftp connection is received. The file is a simple list of
  those users who are disallowed from logging in. It might looks
  something like:

               # /etc/ftpusers - users not allowed to login via ftp
               root
               uucp
               bin
               mail

  5.10.2.  /etc/securetty

  The /etc/securetty file allows you to specify which tty devices root
  is allowed to login on. The /etc/securetty file is read by the login
  program (usually /bin/login). Its format is a list of the tty devices
  names allowed, on all others root login is disallowed:

               # /etc/securetty - tty's on which root is allowed to login
               tty1
               tty2
               tty3
               tty4

  5.10.3.  The tcpd  hosts access control mechanism.

  The tcpd program you will have seen listed in the same /etc/inetd.conf
  provides logging and access control mechanisms to services it is
  configured to protect.

  When it is invoked by the inetd program it reads two files containing
  access rules and either allows or denies access to the server it is
  protecting accordingly.

  It will search the rules files until the first match is found. If no
  match is found then it assumes that access should be allowed to
  anyone. The files it searches in sequence are: /etc/hosts.allow,
  /etc/hosts.deny.  I'll describe each of these in turn. For a complete
  description of this facility you should refer to the appropriate man
  pages (hosts_access(5) is a good starting point).

  5.10.3.1.  /etc/hosts.allow

  The /etc/hosts.allow file is a configuration file of the
  /usr/sbin/tcpd program. The hosts.allow file contains rules describing
  which hosts are allowed access to a service on your machine.

  The file format is quite simple:



               # /etc/hosts.allow
               #
               # <service list>: <host list> [: command]



     service list
        is a comma delimited list of server names that this rule applies
        to.  Example server names are: ftpd, telnetd and fingerd.


     host list
        is a comma delimited list of host names. You may also use IP
        addresses here. You may additionally specify hostnames or
        addresses using wildcard characters to match groups of hosts.
        Examples include: gw.vk2ktj.ampr.org to match a specific host,
        .uts.edu.au to match any hostname ending in that string, 44. to
        match any IP address commencing with those digits.  There are
        some special tokens to simplify configuration, some of these
        are: ALL matches every host, LOCAL matches any host whose name
        does not contain a `.' ie is in the same domain as your machine
        and PARANOID matches any host whose name does not match its
        address (name spoofing). There is one last token that is also
        useful. The EXCEPT token allows you to provide a list with
        exceptions. This will be covered in an example later.


     command
        is an optional parameter. This parameter is the full pathname of
        a command that would be executed everytime this rule is matched.
        It could for example run a command that would attempt to
        identify who is logged onto the connecting host, or to generate
        a mail message or some other warning to a system administrator
        that someone is attempting to connect. There are a number of
        expansions that may be included, some common examples are: %h
        expands to the name of the connecting host or address if it
        doesn't have a name, %d the daemon name being called.


  An example:



         # /etc/hosts.allow
         #
         # Allow mail to anyone
         in.smtpd: ALL
         # All telnet and ftp to only hosts within my domain and my host at home.
         telnetd, ftpd: LOCAL, myhost.athome.org.au
         # Allow finger to anyone but keep a record of who they are.
         fingerd: ALL: (finger @%h | mail -s "finger from %h" root)



  5.10.3.2.  /etc/hosts.deny

  The /etc/hosts.deny file is a configuration file of the /usr/sbin/tcpd
  program. The hosts.deny file contains rules describing which hosts are
  disallowed access to a service on your machine.

  A simple sample would look something like this:



         # /etc/hosts.deny
         #
         # Disallow all hosts with suspect hostnames
         ALL: PARANOID
         #
         # Disallow all hosts.
         ALL: ALL



  The PARANOID entry is really redundant because the other entry traps
  everything in any case. Either of these entry would make a reasonable
  default depending on your particular requirement.

  Having an ALL: ALL default in the /etc/hosts.deny and then
  specifically enabling on those services and hosts that you want in the
  /etc/hosts.allow file is the safest configuration.

  5.10.4.  /etc/hosts.equiv

  The hosts.equiv file is used to grant certain hosts and users access
  rights to accounts on your machine without having to supply a
  password. This is useful in a secure environment where you control all
  machines, but is a security hazard otherwise. Your machine is only as
  secure as the least secure of the trusted hosts. To maximize security,
  don't use this mechanism and encourage your users not to use the
  .rhosts file as well.



  5.10.5.  Configure your ftp  daemon properly.

  Many sites will be interested in running an anonymous ftp server to
  allow other people to upload and download files without requiring a
  specific userid. If you decide to offer this facility make sure you
  configure the ftp daemon properly for anonymous access. Most man pages
  for ftpd(8) describe in some length how to go about this. You should
  always ensure that you follow these instructions. An important tip is
  to not use a copy of your /etc/passwd file in the anonymous account
  /etc directory, make sure you strip out all account details except
  those that you must have, otherwise you will be vulnerable to brute
  force password cracking techniques.

  5.10.6.  Network Firewalling.

  Not allowing datagrams to even reach your machine or servers is an
  excellent means of security. This is covered in depth in the Firewall-
  HOWTO, and (more concisely) in a later section of this document.

  5.10.7.  Other suggestions.

  Here are some other, potentially religious suggestions for you to
  consider.



     sendmail
        despite its popularity the sendmail daemon appears with
        frightening regularity on security warning announcements. Its up
        to you, but I choose not to run it.


     NFS and other Sun RPC services
        be wary of these. There are all sorts of possible exploits for
        these services. It is difficult finding an option to services
        like NFS, but if you configure them, make sure you are careful
        with who you allow mount rights to.


  6.  IP- and Ethernet-Related Information

  This section covers information specific to Ethernet and IP. These
  subsections have been grouped together because I think they are the
  most interesting ones in the formerly-called ``Technology Specific''
  Section. Anyone with a LAN should be able to benefit from these
  goodies.

  6.1.  Ethernet

  Ethernet device names are `eth0', `eth1', `eth2' etc. The first card
  detected by the kernel is assigned `eth0' and the rest are assigned
  sequentially in the order they are detected.

  By default, the Linux kernel only probes for one Ethernet device, you
  need to pass command line arguments to the kernel in order to force
  detection of furter boards.

  To learn how to make your ethernet card(s) working under Linux you
  should refer to the Ethernet-HOWTO.

  Once you have your kernel properly built to support your ethernet card
  then configuration of the card is easy.

  Typically you would use something like (which most distributions
  already do for you, if you configured them to support your ethernet):

               root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
               root# route add -net 192.168.0.0 netmask 255.255.255.0 eth0

  Most of the ethernet drivers were developed by Donald Becker,
  becker@CESDIS.gsfc.nasa.gov.

  6.8.  IPIP Encapsulation

  Why would you want to encapsulate IP datagrams within IP datagrams? It
  must seem an odd thing to do if you've never seen an application of it
  before.  Ok, here are a couple of common places where it is used:
  Mobile-IP and IP-Multicast. What is perhaps the most widely spread use
  of it though is also the least well known, Amateur Radio.

  Kernel Compile Options:

               Networking options  --->
                   [*] TCP/IP networking
                   [*] IP: forwarding/gatewaying
                   ....
                   <*> IP: tunneling

  IP tunnel devices are called `tunl0', `tunl1' etc.

  "But why ?". Ok, ok. Conventional IP routing rules mandate that an IP
  network comprises a network address and a network mask. This produces
  a series of contiguous addresses that may all be routed via a single
  routing entry.  This is very convenient, but it means that you may
  only use any particular IP address while you are connected to the
  particular piece of network to which it belongs. In most instances
  this is ok, but if you are a mobile netizen then you may not be able
  to stay connected to the one place all the time. IP/IP encapsulation
  (IP tunneling) allows you to overcome this restriction by allowing
  datagrams destined for your IP address to be wrapped up and redirected
  to another IP address. If you know that you're going to be operating
  from some other IP network for some time you can set up a machine on
  your home network to accept datagrams to your IP address and redirect
  them to the address that you will actually be using temporarily.

  6.8.1.  A tunneled network configuration.

        192.168.1/24                          192.168.2/24

            -                                     -
            |      ppp0 =            ppp0 =       |
            |  aaa.bbb.ccc.ddd  fff.ggg.hhh.iii   |
            |                                     |
            |   /-----\                 /-----\   |
            |   |     |       //        |     |   |
            |---|  A  |------//---------|  B  |---|
            |   |     |     //          |     |   |
            |   \-----/                 \-----/   |
            |                                     |
            -                                     -

  The diagram illustrates another possible reason to use IPIP encapsula­
  tion, virtual private networking. This example presupposes that you
  have two machines each with a simple dial up internet connection. Each
  host is allocated just a single IP address. Behind each of these
  machines are some private local area networks configured with reserved
  IP network addresses. Suppose that you want to allow any host on net­
  work A to connect to any host on network B, just as if they were prop­
  erly connected to the Internet with a network route. IPIP encapsula­
  tion will allow you to do this. Note, encapsulation does not solve the
  problem of how you get the hosts on networks A and B to talk to any
  other on the Internet, you still need tricks like IP Masquerade for
  that.  Encapsulation is normally performed by machine functioning as
  routers.

  Linux router `A' would be configured with a script like the following:

          #!/bin/sh
          PATH=/sbin:/usr/sbin
          mask=255.255.255.0
          remotegw=fff.ggg.hhh.iii
          #
          # Ethernet configuration
          ifconfig eth0 192.168.1.1 netmask $mask up
          route add -net 192.168.1.0 netmask $mask eth0
          #
          # ppp0 configuration (start ppp link, set default route)
          pppd
          route add default ppp0
          #
          # Tunnel device configuration
          ifconfig tunl0 192.168.1.1 up
          route add -net 192.168.2.0 netmask $mask gw $remotegw tunl0

  Linux router `B' would be configured with a similar script:

               #!/bin/sh
               PATH=/sbin:/usr/sbin
               mask=255.255.255.0
               remotegw=aaa.bbb.ccc.ddd
               #
               # Ethernet configuration
               ifconfig eth0 192.168.2.1 netmask $mask up
               route add -net 192.168.2.0 netmask $mask eth0
               #
               # ppp0 configuration (start ppp link, set default route)
               pppd
               route add default ppp0
               #
               # Tunnel device configuration
               ifconfig tunl0 192.168.2.1 up
               route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0

  The command:

               route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0

  reads: `Send any datagrams destined for 192.168.1.0/24 inside an IPIP
  encap datagram with a destination address of aaa.bbb.ccc.ddd'.

  Note that the configurations are reciprocated at either end. The
  tunnel device uses the `gw' in the route as the destination of the IP
  datagram in which it will place the datagram it has received to route.
  That machine must know how to decapsulate IPIP datagrams, that is, it
  must also be configured with a tunnel device.

  6.8.2.  A tunneled host configuration.

  It doesn't have to be a whole network you route. You could for example
  route just a single IP address. In that instance you might configure
  the tunl device on the `remote' machine with its home IP address and
  at the A end just use a host route (and Proxy Arp) rather than a
  network route via the tunnel device. Let's redraw and modify our
  configuration appropriately. Now we have just host `B' which to want
  to act and behave as if it is both fully connected to the Internet and
  also part of the remote network supported by host `A':

        192.168.1/24

            -
            |      ppp0 =                ppp0 =
            |  aaa.bbb.ccc.ddd      fff.ggg.hhh.iii
            |
            |   /-----\                 /-----\
            |   |     |       //        |     |
            |---|  A  |------//---------|  B  |
            |   |     |     //          |     |
            |   \-----/                 \-----/
            |                      also: 192.168.1.12
            -

  Linux router `A' would be configured with:

               #!/bin/sh
               PATH=/sbin:/usr/sbin
               mask=255.255.255.0
               remotegw=fff.ggg.hhh.iii
               #
               # Ethernet configuration
               ifconfig eth0 192.168.1.1 netmask $mask up
               route add -net 192.168.1.0 netmask $mask eth0
               #
               # ppp0 configuration (start ppp link, set default route)
               pppd
               route add default ppp0
               #
               # Tunnel device configuration
               ifconfig tunl0 192.168.1.1 up
               route add -host 192.168.1.12 gw $remotegw tunl0
               #
               # Proxy ARP for the remote host
               arp -s 192.168.1.12 xx:xx:xx:xx:xx:xx pub

  Linux host `B' would be configured with:

          #!/bin/sh
          PATH=/sbin:/usr/sbin
          mask=255.255.255.0
          remotegw=aaa.bbb.ccc.ddd
          #
          # ppp0 configuration (start ppp link, set default route)
          pppd
          route add default ppp0
          #
          # Tunnel device configuration
          ifconfig tunl0 192.168.1.12 up
          route add -net 192.168.1.0 netmask $mask gw $remotegwtunl0

  This sort of configuration is more typical of a Mobile-IP application.
  Where a single host wants to roam around the Internet and maintain a
  single usable IP address the whole time. You should refer to the
  Mobile-IP section for more information on how that is handled in
  practice.

  6.9.  IP Masquerade

  Many people have a simple dialup account to connect to the Internet.
  Nearly everybody using this sort of configuration is allocated a
  single IP address by the Internet Service Provider. This is normally
  enough to allow only one host full access to the network. IP
  Masquerade is a clever trick that enables you to have many machines
  make use of that one IP address, by causing the other hosts to look
  like, hence the term masquerade, the machine supporting the dialup
  connection. There is a small caveat and that is that the masquerade
  function nearly always works only in one direction, that is the
  masqueraded hosts can make calls out, but they cannot accept or
  receive network connections from remote hosts. This means that some
  network services do not work such as talk and others such as ftp must
  be configured to operate in passive (PASV) mode to operate.
  Fortunately the most common network services such as telnet, World
  Wide Web and irc do work just fine.

  Kernel Compile Options:


               Code maturity level options  --->
                   [*] Prompt for development and/or incomplete code/drivers
               Networking options  --->
                   [*] Network firewalls
                   ....
                   [*] TCP/IP networking
                   [*] IP: forwarding/gatewaying
                   ....
                   [*] IP: masquerading (EXPERIMENTAL)



  Normally you have your linux machine supporting a slip or PPP dialup
  line just as it would if it were a standalone machine. Additionally it
  would have another network device configured, perhaps an ethernet,
  configured with one of the reserved network addresses. The hosts to be
  masqueraded would be on this second network. Each of these hosts would
  have the IP address of the ethernet port of the linux machine set as
  their default gateway or router.

  A typical configuration might look something like this:

       -                                   -
        \                                  | 192.168.1.0
         \                                 |   /255.255.255.0
          \                 ---------      |
           |                | Linux | .1.1 |
       NET =================| masq  |------|
           |    PPP/slip    | router|      |  --------
          /                 ---------      |--| host |
         /                                 |  |      |
        /                                  |  --------
       -                                   -

  Masquerading with IPFWADM

  The most relevant commands for this configuration are:

               # Network route for ethernet
               route add -net 192.168.1.0 netmask 255.255.255.0 eth0
               #
               # Default route to the rest of the internet.
               route add default ppp0
               #
               # Cause all hosts on the 192.168.1/24 network to be masqueraded.
               ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0

  Masquerading with IPCHAINS

  This is similar to using IPFWADM but the command structure has
  changed:

               # Network route for ethernet
               route add -net 192.168.1.0 netmask 255.255.255.0 eth0
               #
               # Default route to the rest of the internet.
               route add default ppp0
               #
               # Cause all hosts on the 192.168.1/24 network to be masqueraded.
               ipchains -A forward -s 192.168.1.0/24 -j MASQ

  You can get more information on the Linux IP Masquerade feature from
  the IP Masquerade Resource Page. Also, a very detailed document about
  masquesrading is the ``IP-Masquerade mini-HOWTO'' (which also intructs
  to configure other OS's to run with a Linux masquerade server).

  6.10.  IP Transparent Proxy

  IP transparent proxy is a feature that enables you to redirect servers
  or services destined for another machine to those services on this
  machine.  Typically this would be useful where you have a linux
  machine as a router and also provides a proxy server. You would
  redirect all connections destined for that service remotely to the
  local proxy server.

  Kernel Compile Options:


               Code maturity level options  --->
                       [*] Prompt for development and/or incomplete code/drivers
               Networking options  --->
                       [*] Network firewalls
                       ....
                       [*] TCP/IP networking
                       ....
                       [*] IP: firewalling
                       ....
                       [*] IP: transparent proxy support (EXPERIMENTAL)

  Configuration of the transparent proxy feature is performed using the
  ipfwadm command

  An example that might be useful is as follows:

               root# ipfwadm -I -a accept -D 0/0 telnet -r 2323

  This example will cause any connection attempts to port telnet (23) on
  any host to be redirected to port 2323 on this host. If you run a
  service on that port, you could forward telnet connections, log them
  or do whatever fits your need.

  A more interesting example is redirecting all http traffic through a
  local cache. However, the protocol used by proxy servers is different
  from native http: where a client connects to www.server.com:80 and
  asks for /path/page, when it connects to the local cache it contacts
  proxy.local.domain:8080 and asks for www.server.com/path/page.

  To filter an http request through the local proxy, you need to adapt
  the protocol by inserting a small server, called transproxy (you can
  find it on the world wide web). You can choose to run transproxy on
  port 8081, and issue this command:

               root# ipfwadm -I -a accept -D 0/0 80 -r 8081

  The transproxy program, then, will receive all connections meant to
  reach external servers and will pass them to the local proxy after
  fixing protocol differences.

  6.11.  IPv6

  Just when you thought you were beginning to understand IP networking
  the rules get changed! IPv6 is the shorthand notation for version 6 of
  the Internet Protocol. IPv6 was developed primarily to overcome the
  concerns in the Internet community that there would soon be a shortage
  of IP addresses to allocate. IPv6 addresses are 16 bytes long (128
  bits). IPv6 incorporates a number of other changes, mostly
  simplifications, that will make IPv6 networks more managable than IPv4
  networks.

  Linux already has a working, but not complete, IPv6 implementation in
  the 2.2.* series kernels.

  If you wish to experiment with this next generation Internet
  technology, or have a requirement for it, then you should read the
  IPv6-FAQ which is available from www.terra.net.

  6.12.  Mobile IP

  The term "IP mobility" describes the ability of a host that is able to
  move its network connection from one point on the Internet to another
  without changing its IP address or losing connectivity. Usually when
  an IP host changes its point of connectivity it must also change its
  IP address.  IP Mobility overcomes this problem by allocating a fixed
  IP address to the mobile host and using IP encapsulation (tunneling)
  with automatic routing to ensure that datagrams destined for it are
  routed to the actual IP address it is currently using.

  A project is underway to provide a complete set of IP mobility tools
  for Linux.  The Status of the project and tools may be obtained from
  the: Linux Mobile IP Home Page.

  6.13.  Multicast

  IP Multicast allows an arbitrary number of IP hosts on disparate IP
  networks to have IP datagrams simultaneously routed to them. This
  mechanism is exploited to provide Internet wide "broadcast" material
  such as audio and video transmissions and other novel applications.

  Kernel Compile Options:

       Networking options  --->
               [*] TCP/IP networking
               ....
               [*] IP: multicasting

  A suite of tools and some minor network configuration is required.
  Please check the Multicast-HOWTO for more information on Multicast
  support in Linux.

  6.14.  NAT - Network Address Translation

  The IP Network Address Translation facility is pretty much the
  standardized big brother of the Linux IP Masquerade facility. It is
  specified in some detail in RFC-1631 at your nearest RFC archive. NAT
  provides features that IP-Masquerade does not that make it eminently
  more suitable for use in corporate firewall router designs and larger
  scale installations.

  An alpha implementation of NAT for Linux 2.0.29 kernel has been
  developed by Michael.Hasenstein, Michael.Hasenstein@informatik.tu-
  chemnitz.de. Michaels documentation and implementation are available
  from:

  Linux IP Network Address Web Page

  Newer Linux 2.2.x kernels also include some NAT functionality in the
  routing algorithm.

  6.15.  Traffic Shaper - Changing allowed bandwidth

  The traffic shaper is a driver that creates new interface devices,
  those devices are traffic-limited in a user-defined way, they rely on
  physical network devices for actual transmission and can be used as
  outgoing routed for network traffic.

  The shaper was introduced in Linux-2.1.15 and was backported to
  Linux-2.0.36 (it appeared in 2.0.36-pre-patch-2 distributed by Alan
  Cox, the author of the shaper device and maintainer of Linux-2.0).

  The traffic shaper can only be compiled as a module and is configured
  by the shapecfg program with commands like the following:

               shapecfg attach shaper0 eth1
               shapecfg speed shaper0 64000

  The shaper device can only control the bandwidth of outgoing traffic,
  as packets are transmitted via the shaper only according to the
  routing tables; therefore, a ``route by source address'' functionality
  could help in limiting the overall bandwidth of specific hosts using a
  Linux router.

  Linux-2.2 already has support for such routing, if you need it for
  Linux-2.0 please check the patch by Mike McLagan, at ftp.invlogic.com.
  Refer to Documentationnetworking/shaper.txt for further information
  about the shaper.

  If you want to try out a (tentative) shaping for incoming packets, try
  out rshaper-1.01 (or newer), from ftp.systemy.it.

  6.16.  Routing in Linux-2.2

  The latest versions of Linux, 2.2 offer a lot of flexibility in
  routing policy. Unfortunately, you have to wait for the next version
  of this howto, or go read the kernel sources.

There are four categories of high level abstract connections:
- point-to-point
- point-to-multipoint
- multipoint-to-point
- multipoint-to-multipoint

In network terminology the word "point" is usually synonymous with "device".

  4.  Networking hardware supported

  Linux supports a great variety of networking hardware, including some
  obsolete equipment.

  Some interesting documents:

  ·  Hardware HOWTO <http://metalab.unc.edu/mdw/HOWTO/Hardware-
     HOWTO.html>

  ·  Ethernet HOWTO <http://metalab.unc.edu/mdw/HOWTO/Ethernet-
     HOWTO.html>

  6.9.  Authentication

  There are also various ways of authenticating users in mixed networks.

  ·  For Linux/Windows NT:http://www.mindware.com.au/ftp/smb-NT-
     verify.1.1.tar.gz

  ·  The PAM (pluggable authentication module) which is a flexible
     method of Unix authentication: PAM library
     <http://www.kernel.org/pub/linux/libs/pam/index.html>.

  ·  Finally, LDAP in Linux
     <http://www.umich.edu/~dirsvcs/ldap/index.html>

  7.  Remote execution of applications

  One of the most amazing features of Unix (yet one of the most unknown
  to new users) is its great support for remote and distributed
  execution of applications.

  7.2.  Remote commands

  In Unix, and in particular in Linux, remote commands exist that allow
  for interaction with other computers from the shell prompt. Examples
  are: rlogin, which allows for login in a remote machine in a similar
  way to telnet, rcp, which allows for the remote transfer of files
  among machines, etc. Finally, the remote shell command rsh allows the
  execution of a command on a remote machine without actually logging
  onto that machine.

  2.2.  What makes Linux different?

  Why work on Linux? Linux is generally cheaper (or at least no more
  expensive) than other operating systems and is frequently less
  problematic than many commercial systems. But what makes Linux
  different is not its price (after all, why would anyone want an OS -
  even a free one - if it is not good enough?) but its outstanding
  capabilities:


  ·  Linux is a true 32-bit multitasking operating system, robust and
     capable enough to be used in organizations ranging from
     universities to large corporations.

  ·  It runs on hardware ranging from low-end 386 boxes to massive
     ultra-parallel machines in research centres.

  ·  Out-of-the-box versions are available for Intel, Sparc, and Alpha
     architectures, and experimental support exists for Power PC and
     embedded systems, among others such as SGI, Ultra Sparc, AP1000+,
     Strong ARM, and MIPS R3000/R4000.

  ·  Finally, when it comes to networking, Linux is choice. Not only
     because networking is tightly integrated with the OS itself and a
     plethora of applications is freely available, but for the
     robustness under heavy loads that can only be achieved after years
     of debugging and testing in an Open Source project.

  5.  File Sharing and Printing

  The primary purpose of many PC based Local Area Networks is to provide
  file and printer sharing services to the users. Linux as a corporate
  file and print server turns out to be a great solution.

  8.  Network Interconnection

  Linux networking is rich in features. A Linux box can be configured so
  it can act as a router, bridge, etc... Some of the available options
  are described below.

Common Network Protocols

As mentioned earlier, network protocols are sets of rules and standards for data commnucations
over networks. A network architecture (such as Ethernet) can support multiple protocols, and even
multiple protocols currently.

Protocols are typically organized into protocol suites, or sets of compatible protocols. These are
also referred to as protocol stacks. A stack includes protocols for several different layers of the
OSI model. Lower-level protocols provide services for use by upper-level protocols. The highest
level protocols communicate directly with applications.

Communications protocols can be divided into two basic types, connection-orientated
and connectionless:

- Connection-orientated protocols

establish a connection, or virtual circuit, before, communicating, and disconnect it when
finished. Connection-orientated protocols generally have a lower speed due to the
bandwidth used for session maintenance.

- Connectionless protocols

do not establish a virtual circuit. Data is sent withoug establishing a connection, and may
be sent at any time. These protocols have low overhead, and are generally used where speed
is a high priority.

Another distinction between protocols is their reliablity. Some protocols send
acknowledgements for each transmitted packet. This makes for a more reliable connection,
but leaves less bandwidth for actual data transmission. These are called reliable protocols.
Protocols without acknowledgements are known as unreliable, although this does not
necessarily mean they are undependable.

Common Network Protocols and Characteristics

Protocol	Overhead	Routable?	Typical Application
TCP/IP	Medium	Yes		Large networks; Internet and UNIX compatibility
NetBEUI	Low		No		Small Windows-based networks
IPX/SPX	Medium	Yes		NetWare compatiblity
Appletalk	Medium	Yes		Apple Macintosh compatiblity
DLC		Medium	No		IBM mainframe compatiblity; some network printers

Common WAN Architectures

- Circuit Switching

Circuit switching is a connection-orientated method of communication. A circuit is dedicated to the connection,
and a connection must be specifically established when needed and disconnected when not needed.

- Message Switching

Message switching is a connectionless method of communication. Individual message units are sent across the network
with routing information without establishing a dedicated nework.

- Packet Switching

Packet switching is a more efficient connectionless communication method. Packets (smaller than message units)
are sent individually and can follow different routes to their destination. Some packet switching systems use
virtual circuits for a logical connection, but don't use a dedicated physical connection.

Switched networks are generally less expensive and allow networking with multiple locations; non-switched
lnks are usually dedicated between two locations and provide more consistent available bandwidth.

WAN connections typically require different (and more expensive) hardware than LAN connections. Typical
WAN equipment includes specialized types of routers, CSU/DSUs (Channel Service Unit/Digital Service Unit),
and multiplexers, which combine multiple signals (such as voice and data) for tranmissions on a single WAN
connection. A number of WAN technologies and public networks are available. FDDI, explained earlier in this
chapter, can also be used for wide-are networks. The common WAN technologies are described in detail in
the sections below.

  3.5.  WAN Networking: X.25, Frame-relay, etc...

  Several third parties provide T-1, T-3, X.25 and Frame Relay products
  for Linux. Generally special hardware is required for these types of
  connections. Vendors that provide the hardware also provide the
  drivers with protocol support.


  ·  WAN resources for Linux:
     http://www.secretagent.com/networking/wan.html
]]>

>Start Binh

Attentuation is a physical phenomenon which causes a signal to gradually lose 
power as it propogates through a medium. This is mainly due to due to two 
factors, signal dispersion and signal absorption. Unfortunately, there is some 
noise which generates a constant noise power, N, and so eventually, as the 
signal travels a long enough distance, the signal poower will decrease to a 
value less than the noise power.

This is similar to the effect observed when you are attempting to communicate 
with another person with your natural voice. As the person moves further away 
the voice is harder to hear as the signal power spreads out and is absorbed 
by obstacles, etc....

Attenuation is generally a factor of distance and frequency.

This is very much in accordance with our current laws of physics.
The intensity if a signal is inversely proportional to the inverse square of the the signal distance. 
You'll often notice that in military applications the usage of broad 
frequency radar for spotting targets over great ranges and then the utilisation 
of higher frequency signals as greater precision positioning is required.

Most transmission medium will have a rating which gives the attenuation as a 
function of frequency and distance, eg. the attenuation per kilometer. Ideally 
the attenuation is zero because this represents no loss in the signal power.

This leads us to the issue of digital transmission versus analogue
transmission. The primary advantage of digital transmission over analogue 
transmission is the reduction in noise. The digital transmission system 
reduces noise over successive transmissions because small variations in 
the signal can be rounded off to the nearest level. Analogue transmission 
systems need to filter out the noise, but the filter itself can sometimes 
be a source of noise and generally, noise can accumulate to an unacceptable 
level in an analogue tranmission system.

Consider two types of repeater to understand of digital transmission. In the 
first instance (analogue) the situation is roughly synonymous with someone 
who doesn't know Korean and who is trying to relay a message from one Korean 
to another. It can be done if the person simply repeats the sounds that are 
heard. In digital tranmission repitition would be more along the lines of 
someone knowing Korean and actually "re-saying" what was heard (perhaps even 
correcting for errors in what was heard).

Systems which transmit ananlogue signals (such as the calssical radio and 
television broadcasting systems) can use one of three well known techniques,
 Amplitude Modulation (AM), Frequency Modulation (FM), and Phase Modulation (PM).
AM works by varying the amplitude of a signal to code the bit stream. FM works 
by varying frequency of a signal to code the bit stream. PM works by varying 
the phase of a signal to code the bit stream.

To allow two transmission medium (usually of the same type) to be directly 
connected the concept of a switch was developed. A general switch can be 
built from many basic switches and is somtimes referred to as a switching 
fabric. A lot of research and development contines in an attempt to build 
better switching fabrics.

A circuit switched network operates at the physical layer to provide a single, 
continuous transmission medium between any two hosts or end devices in the 
network. Circuit switching is perhaps the most straightforward approach to building 
communication network. Computer networks didn't actually evolve using circuit 
switching though circuit switching is being considered for certain computer 
applications such as video and voice. Because circuit switching constucts a 
single long transmission medium with at most analogue repeaters the end devices 
(in this case telephones) are able to modulate the signal on the medium however 
they choose. This is also why two modems can communicate with one another over 
a telephone network.

Multiplexing is used to share a single transmission medium among a number of 
individual transmissions. The demultiplexer just undoes what the multiplexer 
does. Therefore the multiplexer and demultiplexer must directly cooperate. 
Multiplexers and demultiplexers are not so much network devices are not so much 
network devices but functionality that is contained within a network device. 
Switches (in the sense described here) may be similarly categorized in this way.

The transmission medium can be multiplexed in the time domain, called TDM (Time Domain 
Multiplexing), using a simple switch and clocked control. Because of delays incurred 
in the transmission line, the clocks may need to be out of phase with one another. 
See that with the TDM, the shared medium must be able to transmit at a bit rate 
that equals (or is better than) the sum of input bit rates. The swithes must also 
be able to switch fast enough.

The previous example was assuming a synchronous transmission mode. In general, bit 
streams can be divided into DU's called cells. Cells are fixed in length so that the 
receiver knows when one cell finishes and the next cell begins.

Alternatively there is ATM (Asynchronous Transmission Mode, ATM is also the name 
given to a popular network layer device that uses this multiplexing technique.), 
where signals are irregularly multiplexed. How does the receiver know what order 
the signals were multiplexed in?

Additional information is needed in the multiplexed signal. One way is to add a 
header or label to the front of each cell. The header identifies the cell.

Using a header means using additional bits, which becomes overhead. Thus, to reduce 
the overhead the cells should be reasonably larger than the header. Cells for 
modern ATM transmission systems are about 50 butes in size.

Because modulators can transmit signals at different frequency bands, it is possible 
to transmit several signals at one, with each signal transmitted within a different 
frequency band. In this case the different signals have been frequency domain multiplexed.
This is known as FDM, (Frequency Domain Multiplexing).

Similar to FDM, WDM (Wavelength Division Multiplexing) uses each wavelength of light to 
transmit a signal. WDM is for fiber optic systems. The number of wavelengths per 
fiber, currently available, is about 300. Each wavelength can carry about 10Gbps. 
This makes 3Tbps. AT&amp;T predict that up to 1024 wavelengths may be available in the future.

The hub/optical hub is clearly an analogue device - input signals are reflected to all 
outputs. It is also called passive, because it does not introduce any power to the signal 
(otherwise it would be called active). Considering the hub as a device which repeats 
input from an incoming signal on all outputs is quite simplistic however the basic 
function should be understandable. When examining the Data-link layer it will become 
clearer how computers communicate using a hub. For wireless communication, the 
transmission of each device is implicity received by every other device. This is an 
implicit hub.

Wireless communication usually takes place using the IEEE 802.11 standard which specifies 
an unlicensed radio spectrum at 2.4GHz and provides wireless Ethernet access at 11Mbps. 
There is also some spectrum allocated between 5GHz ad 6GHz that provides 54Mbps. 
Sophisticated codes and frequency sharing technology is used to maximise the usage of 
this communication medium. This topic is strictly concerned with Medium Access Control, 
to be discussed later. Wireless also allows point-to-point communication in the sense 
that each point-to-point link or channel is a dedicated frequency range that no other 
pair of devices will use.

Analogue telephone networks use conventional circuit switching networks to 
construct a connection between two telephones. You have seen that a modem 
converts digital signals to analogue to be transmitted over an analogue 
telephone network.

Digital telephone networks use a codec or coder-decoder to convert analogue 
telephone (or modem) signals into digital form! This is so that new digital 
techniques can be used within a conventionally an analogue network, ie. 
transparently to the analogue devices. The codec is used to convert from 
analogue to digital and digital to analogue.

Enough is known now to consider the complexity of a large digital network 
that supporst communication of various kinds. As technologies improve some 
networks become more dominant than others. In todays world we see a 
significant shift towards computer networks, away from conventional 
telecommunication networks.

This doesn't mean the end of telecommunications, but rather a collapse of 
outdated technological layers towards the "core" networks that they connect 
to. It will become more apparent to you as we progres through this subject 
that networks can be built on top of other networks which are themseleves 
built on top of ther networks.

The size and scale of a network can vary substantially from Local Area Networks 
(LANs) which usually connect 10-15 computers in a 
small area (usually a small building) to Metropolitan Area Networks (MANs)
which use long-distance links (such as telephone lines or dedicated media) 
to connect two or more locations within a single city or metropolitan area 
to Wide Area Networks (WANs) which use the same technology as MANs to 
connect computers in distant locations but in different cities 
or even different countries.

There are two basic types of networks: client-server networks, which use 
dedicated servers; and peer-to-peer networks, which (normally) share files 
between workstations. 

Server-based networks (also called client-server networks) use a dedicated 
server machine which provides files and printers to network workstations 
called clients. Client machines are simply used by network users, and usually 
do not share files or printers. The key benefit of the server-client model is 
in centralization. There is only a single point of control for network acccess, 
security, and management. The disadvantages of a server-based network are the 
higher cost of dedicated servers and network operating systems, as well as the 
increased level of administrative effort required.

Conversely, peer-to-peer networks consist solely of workstations called peers. 
Each workstation can be used by a user, and can also make shared files or 
printers available to users at other workstations. The advantages of peer 
networks include their ease of installation and use, their relative 
inexpensiveness in comparison with server-based networks (since a dedicated
server is not required) and the fact that an administrator mightn't be required 
(if users are able to manage resource sharing). The primary disadvantage of 
peer networks is the lack of a central control mechanism. Each user controls 
access to their own workstation's shared files and printers. In a large scale 
network, such a security policy is difficult to manage without 
compromising security. Further, a workstation that is being accessed by peers
can also be slowed down, inconveniencing the user at that workstation. Hence, 
its clear that this system is best suited to smaller networks.

</para>
</sect1>

<sect1 id="Internet">

<title>Internet</title>

<para>
Internet is not described as a network of any single kind. It can be construed 
as a large set of heterogenous networks that support a certain set of protocols 
(TCP/IP) and provide certain common services. A good way to learn about the 
Internet is to use the Internet!
</para>

<para>
Linux is a great platform to act as an Intranet / Internet server. The
term Intranet refers to the application of Internet technologies
inside an organisation mainly for the purpose of distributing and
making available information inside the company. Internet and Intranet
services offered by Linux include mail, news, WWW servers and many
more that will be outlined further on in this document.
</para>

</sect1>
