Assignment 6: Internetworking and TCP/IP Due the week of Apr. 9, 2001

This week, we will do a case study of what is arguably the most important set of network protocols currently in use -- TCP/IP (more correctly know as the Internet Protocol Suite).

The main reading for this topic will be from Tanenbaum. First, Tanenbaum discusses internetworking and IP in chapter 5. In particular, you should read §5.4 and §5.5. In some sense, we are skipping ahead by dicussing both TCP and IP this week. TCP is a transport layer protocol and we haven't actually discussed the transport layer. To make this feasible, you should first get a bit of general background on the transport layer by reading the beginning of chapter 6 up to but not including §6.2.4. Then, you can skip ahead to §6.4 and read up to but not including §6.4.6.

The second required reading is a paper by David Clark entitled "The Design Philosophy of the DARPA Internet Protocols". It does a nice job of discussing some of the design choices that led to the final TCP/IP standards.

For those who want more, I'll make a few optional readings available. The first is a pair of sections on the Internet protocols taken from a network text by Halsall. I'll warn you that when you get to §9.7 on page 467 of the copy I made you should skip immediately to the next page. That page ends with the start of a section on the ISO internet protocols which I didn't want you to read about. The next page of the handout is from a different chapter of Halsall's book.

I will also placed a binder full of RFC's on reserve (An RFC is basically an Internet technical report.). Included in the binder are the official definitions for IP, UDP and TCP and a tutorial on the whole collection. Some of these are a bit long (I think the TCP RFC is about 100 pages).

Exercises

1. Suppose, you spent some time eavesdropping on the packets flowing across some ethernet attached to the internet. Each IP packet on the network contains both an ethernet destination address and an IP destination address. After a while, you notice that in most packets the IP destination address and the ethernet destination address refer to the same host. For one host, however, you see a significant number of packets containing the host's ethernet address as their ethernet destinations but containing IP destination addresses that don't match the hosts IP address. Is something wrong? (Hint: This problem (in a different disguise) is also part of the CS 105 assignment for the week. )
2. Play-by-Play - One of the simplest services implemented on the Internet is the "finger" system. I'm assuming that you are all familiar with the "finger command". If not, log onto one of our Unix machines and type

   finger murtagh@williams.edu

   and see what happens.

   Finger is implemented using TCP. When you type a command like the one shown above, the "finger" program establishes a TCP connection to the finger server port on the machine you specified (williams.edu) and sends the name specified ("murtagh") through the TCP connection to the remote host. It then reads whatever text the remote hosts sends back through the TCP connection and displays it in your terminal window as the output of the command.

   I would like you to figure out exactly what frames go zipping across the ethernet when you execute such a command.

   Assuming no packets are damaged in transit or discarded, determine exactly what sequence of frames would flow across the ethernet during the execution of your finger command for this simple example (in the worse case). Be precise. Include everything (ARP, connection establishment, ...). Indicate the settings of the important fields of each frame. You don't have to specify exactly what data comes back from the finger server, however, and you can assume that the amount of data included in this response is small enough (let's say its 200 bytes) to fit in a single TCP packet.

   Your answer should at least include such points of trivia as:

   • The total number of frames that travel over the ethernet.
   • The total number of bytes (pardon me, octets) sent over the ethernet (don't forget any headers or trailers).
   • The ratio of actual data transmitted to the answer to part (b).
3. Unscrambling the Alphabet Soup The Internet protocol suite contains many members including ARP, RARP, IP, UDP, TCP, ICMP, EGP and several IGP's. Draw a diagram showing how these protocols depend on one another by drawing an arc from one protocol to another if the first depends in some way on the other.

   If you do this correctly, you should end up with some cycles in your diagrams. That is, there are examples of protocols A and B such that A depends on B in some way but B also depends on A. Be prepared to discuss how the Internet can get away with such cycles.

4. Picking on Tanenbaum Tanenbaum's text provides a good description of TCP/IP. If it was perfect, however, I would not have felt it was necessary to provide you with additional, optional readings. With this in mind, I'd like you to consider two particular items in Tanenbaum's description of TCP/IP that are, at best, misleading.
   1. In discussing the elimination of the checksum from the IPv6 header, Tanenbaum comments that "the fact that the data link layer and transport layers normally have their own checksum" made "the value of yet another checksum not worth the performance price it extracted."

      At this point, the only transport layer protocol that uses a checksum with which you are familier is TCP. So, I'd like you to discuss the degree to which the IPv4 checksum is "yet another checksum not worth the performance price" when used in conjuction with TCP.

      Are the TCP and IP checksums redundant? If not, in what cases might one detect an error that the other would ignore?

   2. On page 525, Tanenbaum states that "Since segments can be fragmented, it is possible that part of a transmitted segment is acknowledged by the receiving TCP entity, but the rest is lost." This is not true. Explain why?