TCP/IP Link Layer

In the TCP/IP Introduction we discussed the software components that comprise each layer. We mentioned three components of TCP/IP that were part of the link layer, these were:

We have a problem, TCP/IP uses a 32 bit Internet address to identify where packets should go, however ethernet uses a 48bit ethernet address to identify stations. We need some mechanism for converting between internet and ethernet addresses, this is handled by the arp protocol.

The Addrerss Resolution Protocol(ARP)

The ARP protocol is defined in RFC 826 , by David Plummer.

The arp protocol operates at the link layer, it receives a destination IP address and sends out a broadcast request for all machines to see. The request asks the question, If you are IP address N, please respond with your ethernet address . Each host on the network monitors the network for these requests, when itŐs address is requested it sends a arp reply. The arp reply specifies the 48 bit ethernet address to use for that IP address.

Since it is very likely you will send another packet to this IP address after this packet is sent, the arp module caches replies, generally for 20 minutes. Any subsequent request for that IP address will be resolved through the cache instead of requiring an arp broadcast. The arp cache can be manipulated by the super-user through the command arp. This command allows you to view the arp cache entries as well as set or remove entries.

Let us look at what happens when you issue the command telnet gmuvax.gmu.edu

  1. The telnet program issues the system call gethostbyname to request the ip address of host gmuvax.gmu.edu. The system then uses the Domain Naming Service to resolve the address, from the perspective of the telnet command it receives back an IP address for that host.
  2. The application makes a request to the TCP layer to open a connection to that host.
  3. TCP generates a request to the network layer to route the packet to the IP address for routing.
  4. The IP layer calls the kernel to send the packet, the kernel will check the arp cache for that IP address, if it is not present it will issue an arp request.
  5. The kernel then waits for an arp reply.
  6. When the arp reply is received the kernel adds the values to the arp cache and submits the request.

The arp protocol opens up a minor security hole. This is because there is no way for the host issueing the arp request to know if the arp reply it receives is in fact legitimate. It would not be difficult for a host to masquerade as another host. However, the host masquerading as another host must exist on the same network the actual host we want resides on, due to this it isnŐt that hard to usually track down the culprit. Some sites worried about this will pre-load the arp cache with the ethernet addresses of all known hosts on their network. That way it is impossible for another host to masquerade via an arp reply.

The Reverse Address Resolution Protocol (RARP).

The RARP protocol is defined by RFC 903.

The Reverse Address Resolution Protocol (RARP) was developed with diskless workstations and X-terminals in mind. By definition, these systems don't have permanent disk storage, how then do they find out what their IP address should be. The RARP protocol was developed to answer the problem:

Given an ethernet address what is the IP address assigned.

To use the RARP protocol a machine(s) must be designated as Rarp servers. These rarp servers have a file named /etc/ethers containing the ethernet to IP translation. When a diskless system boots it sends out a broadcast RARP request. The server then examines the request and determines if that host is one it is serving, if so it sends back a rarp reply containing the IP address. The host booting then uses that address to continue booting.

The rarp protocol has some problems, one is that while it sounds simple it is not easy to have a kernel level process (rarp deamon) reading an /etc/ethers file to look up addresses. Also, it is normally desirable to have multiple rarp servers supporting diskless clients. However, now when a rarp request is made you may have multiple rarp replies coming back. The rarp protocol relies on a broadcast packet. This means that the rarp server must be on the same network as client. Finally, when booting a diskless workstation the task of getting the IP address is just one of the many tasks you want to accomplish. Thus a client must support other protocols such as tftp if it is to boot using the rarp protocol. To address many of these poblems a new protocol, named Bootp was developed, which we will mention later.

Configuring the interface

Under Unix, we use the command ifconfig to configure a network interface. Here is the ifconfig man page from the SGI system.

The ifconfig command is usually run at start up. On BSD systems it will usually be in the rc.local file. Under SV5 systems it is executed under a shell script in /etc/init.d/network, this script is linked to /etc/rc.2.d/S30network and /etc/rc0.d/K40network. In addition, a file exists in the directory /etc/config named ifconfig-1.options. This file usually contains one line which supplies the neccesary options needed by the ifconfig command. Remember from our earlier discussion on startup and shutdown that SV5 based systems use the concept that all startup scripts reside in the /etc/init.d directory with links to the appropriate rc directory.For more infomation, please review the section on Multi-user operation.

The options needed by the ifconfig command are:

The interface device to be configured.
For this you have to consult your hardware manual. On dec systems the ethernet device is named ln0, under SunOS the device is le0, on SGI's it is ec0.
The name or IP address for this interface.
Each interface used on your network must have a seperate IP address and must have a seperate name. If you use a hostname, then the hostname must exist in the file /etc/hosts and must have the IP address associated with that name.
The netmask to use.
This requires some explanation. When designing networks we generally build a network of networks. When we discussed designing a network we mentioned that some devices such as routers and bridges take a signal and regenerate the signal onto a new network, thereby allowing us to extend a network beyond the limits imposed by the standard on a single network.

It turns out that routers or occasionally hosts acting as gateways play a special part in this design. Routers and gateways understand different protocols, such as IP, and can look at the IP portion of a packet and from the destination address determine the route it should take next. Remember earlier we discussed that an IP address is a 32 bit value, usually divided up as four octets. IP uses a concept called subnets to determine individual networks. Each seperate network is a seperate subnet, the router needs to look at IP addresses and determine if they belong to that network or not. This is down by using a subnet mask.

The subnet mask is a 32 bit value that is logically anded with the IP address to see if the destination is on the same network as the router or gateway. For a class B address a normal subnet mask value would be 255.255.255.0 or sometimes displayed with the hexadecimal address of 0xffffff00. Those values produce the equivalent mask, one with the first 24 bits set to 1 and then the remaining bits are 0.

Lets use an example to demonstrate how this works.

Sunspots has an IP address of 130.85.105.3 and a subnet mask of 255.255.255.0. The router interface supporting that building has an IP address of 130.85.105.1 and a subnet mask of 255.255.255.0. When the router interface sees a packet with sunspots destination address it performs the logical and comparison on both it's own IP address and subnet mask as well as the destination addresses IP address. It then compares the two resulting values, if they are equal the router knows the packet is on the same network and does not need to be forwarded.

        Routers address                      Sunspots address
         130.085.105.1                          130.085.105.3
Anded    255.255.255.0                          255.255.255.0

result   130.085.105.0                          130.085.105.0
Suppose we want to connect from sunspots to umbc8, which has ip address of 130.85.60.8. 
        Routers address                        UMBC8  address
         130.085.105.1                          130.085.060.8
Anded    255.255.255.0                          255.255.255.0

result   130.085.105.0                           130.085.060.0
The results are not equal and the router must consult it's routing table to forward the packet on to the next destination.

By convention subnet masks are usually setup on byte boundaries. This is not required. Internet numbers are assigned by a central agency named the InterNIC. A site may request a class A, B, or C. Class A networks are reserved for very large organizations such as all education institutions. Class B is reserved for moderate sized institutions. These addresses are of the form N.N.0.0, (e.g. 130.85 which is umbc's Class B address). Class C networks are smaller networks of the form N.N.N.0. As you can see, each network will support a differnent number of nodes. For this class we will examine class B networks and subnet masks. Since all addresses at UMBC start with 130.85, we need only have the remaining 16 bits of the IP address to play with. How we subdivide the remaining bits is up to us. The default is usually 8 bits reserved for host-id's and 8 bits for subnets. This would allow us to have up to 254 subnets with each subnet having up to 254 hosts. We may decide that it would be more beneficial to allow more subnets on campus and reserve 10 bits for a subnet mask and 6 bits for host-id's. If so we would set our subnet mask to be 0cffffffc0.

Setting the Broadcast Address to use for the Host.

The Broadcast Address is the address to use for reaching all other addresses on your network. By default any address sent with the host-id field set to all 1's is interpreted as a broadcast address. In a standard class B network, the broadcast address will end with last octet being 255. For example, on our IFSM network, sunspots should have a broadcast address of the subnet IP address followed by 255, or 130.85.105.255. The broadcast address to use is dependent on the subnet mask to use.

Configuring the Interface

With that information you can configure your interface. For example, on a dec host with IP address 130.85.1.4 and host name umbc4.umbc.edu we have the following line in our rc.local file.

/etc/ifconfig ln0 `/bin/hostname` broadcast 130.85.1.255 netmask 255.255.255.0

On the SGI system we would create a file named /etc/config/ifconfig-1.options with the line

netmask 255.255.255.0 broadcast 130.85.6.255

Monitoring the network interface

Unix provides the command netstat to monitor the network interface, the man page is here.

The netstat command has a large number of options and can generate many different types of reports. We will discuss some of the more basic reports available. netstat -i 

umbc7> netstat -i
Name Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
et0  1500  130.85.6    umbc7           26767516     0 17547218     1 576401
ipg0 4352  130.85.3    f-umbc7         14723129     6  8186354     0     0
lo0  8304  loopback    localhost        6282789     0  6282789     0     0
The netstat command above gives us an overview of each configured device, the subnet it resides on, the address, and then infomation on input and output packets processed.

netstat -r 

umbc7> netstat -r
Routing tables
Destination      Gateway            Flags    MTU    RTT RTTvar    Use Interface
localhost        localhost          UH         0      0      0 3402617  lo0
umbc7            localhost          UH         0  0.438  0.375 2870261  lo0
134.192          ecs-gw             UG         0      0      0   5849  et0
default          ecs-gw             UG         0      0      0 1387806  et0
198.202.1        ecs-gw             UG         0      0      0      0  et0
130.85.1         ecs-gw             UG         0  0.438  0.383 2666423  et0
198.202.2        ecs-gw             UG         0      0      0      0  et0
129.2            ecs-gw             UG         0  0.438  0.375  43588  et0
130.85.2         ecs-gw             UG         0  0.438   0.42 3344015  et0
198.202.3        ecs-gw             UG         0      0      0      0  et0
130.85.3         f-umbc7            U          0  0.469  0.438 7808605  ipg0
198.202.4        ecs-gw             UG         0      0      0      0  et0
198.202.5        ecs-gw             UG         0      0      0      0  et0
198.51.197       ecs-gw             UG         0      0      0      0  et0
130.85.5         ecs-gw             UG         0      0      0      0  et0
198.202.6        ecs-gw             UG         0      0      0      0  et0
The "-r" option displays the routing table. With the flags you should have "U" for up. The "G" flag implies a route to the default gateway. The RTT columns refer to Round Trip Time.

netstat -s -p udp 

umbc7> netstat -s -p udb
udp:
        14287305 total datagrams received
        0 wth incomplete header
        0 with bad data length field
        2 with bad checksum
        176542 datagrams dropped due to no socket
        4039 broadcast/multicast datagrams dropped due to no socket
        0 datagrams dropped due to full socket buffers
        14106722 datagrams delivered
        14181450 datagrams output
The "-s" option provides statistics, the "-p" option specifies the protocol to return statistics for. If no protocol is specified then all will be returned.

netstat -C [interval] Provides a real time display of all of the above statistics. This can be useful when monitoring the network. Due to the difficulty of displaying real-time statistics none our shown. Optionally, and interval may be specified that causes the output to be updated every interval. The default is every second.