OREGON INSTITUTE OF TECHNOLOGY

Computer Systems Engineering Technology Department

CST 415 - Computer Networks


Description

In the last project, the Ethernet Frame was parsed, leaving the MAC Client Data alone. In this project, you will move up one layer on the protocol stack and handle the IP packet (layer 3), moving the Ping-Pong protocol you have developed up to layer 4. Upon introducing the IP packet into the program, your system should be to play "ping-pong" with your partners program independent of the MAC layer. The MAC layer handles addresing of individual physical devices. The IP layer will handle logical addressing across physical devices allowing packets to be propigated across physical address end points (e.g. routers, bridges, etc.).

In this project, you will parse the MAC client data when the Ethernet frame has a Length/Type field which identifies the packet as an IP packet. An IP packet has the format of:

    0                   1                   2                   3   
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example Internet Datagram Header


Note that each tick mark represents one bit position.


Version: 4 bits

The Version field indicates the format of the internet header.

IHL: 4 bits

Internet Header Length is the length of the internet header in 32 bit words, and thus points to the beginning of the data. Note that the minimum value for a correct header is 5.

Type of Service: 8 bits

The Type of Service provides an indication of the abstract parameters of the quality of service desired. These parameters are to be used to guide the selection of the actual service parameters
when transmitting a datagram through a particular network. Several networks offer service precedence, which somehow treats high precedence traffic as more important than other traffic (generally by accepting only traffic above a certain precedence at time of high load). The major choice is a three way tradeoff between low-delay, high-reliability, and high-throughput.

Bits 0-2: Precedence.
Bit 3: 0 = Normal Delay, 1 = Low Delay.
Bits 4: 0 = Normal Throughput, 1 = High Throughput.
Bits 5: 0 = Normal Reliability, 1 = High Reliability.
Bit 6-7: Reserved for Future Use.


   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 |     |     |     |     |     |
| PRECEDENCE      | D   | T   | R   | 0   | 0   |
|                 |     |     |     |     |     |
+-----+-----+-----+-----+-----+-----+-----+-----+

Precedence

111 - Network Control
110 - Internetwork Control
101 - CRITIC/ECP
100 - Flash Override
011 - Flash
010 - Immediate
001 - Priority
000 - Routine

The use of the Delay, Throughput, and Reliability indications may increase the cost (in some sense) of the service. In many networks better performance for one of these parameters is coupled with worse performance on another. Except for very unusual cases at most two
of these three indications should be set.

The type of service is used to specify the treatment of the datagram during its transmission through the internet system. Example mappings of the internet type of service to the actual service
provided on networks such as AUTODIN II, ARPANET, SATNET, and PRNET is given in "Service Mappings" [8].

The Network Control precedence designation is intended to be used within a network only. The actual use and control of that designation is up to each network. The Internetwork Control
designation is intended for use by gateway control originators only. If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations.


Total Length: 16 bits

Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. Such long datagrams are impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams.

The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram. The maximal internet header is 60 octets, and a typical internet header is 20 octets, allowing a margin for headers of higher level protocols.

Identification: 16 bits

An identifying value assigned by the sender to aid in assembling the fragments of a datagram.

Flags: 3 bits

Various Control Flags.
 

Bit 0: reserved, must be zero
Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment.
Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.

  0   1   2
+---+---+---+
|   | D | M |
| 0 | F | F |
+---+---+---+

Fragment Offset: 13 bits

This field indicates where in the datagram this fragment belongs.

The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero.

 

Time to Live: 8 bits

This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram must be destroyed. This field is modified in internet header processing. The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime.
 

Protocol: 8 bits

This field indicates the next level protocol used in the data portion of the internet datagram. The values for various protocols are specified in "Assigned Numbers" [9].

 

See the RFC for this information.

 

Look for at least ICMP, TCP, UDP, and your "Ping-Pong" protocol..
 

Header Checksum: 16 bits


A checksum on the header only. Since some header fields change (e.g., time to live), this is recomputed and verified at each point that the internet header is processed.

The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.

Source Address: 32 bits

The source address.

Destination Address: 32 bits

The destination address.

 

Address Interpretation

 

To provide for flexibility in assigning address to networks and allow for the large number of small to intermediate sized networks the interpretation of the address field is coded to specify a small number of networks with a large number of host, a moderate number of networks with a moderate number of hosts, and a large number of networks with a small number of hosts. In addition there is an escape code for extended addressing mode.

Address Formats:
 

High Order Bits                 Format                      Class
---------------     ------------------------------- -----
0                           7 bits of net, 24 bits of host       a
10                        14 bits of net, 16 bits of host      b
110                      21 bits of net, 8 bits of host        c
111                      escape to extended addressing mode
 

A value of zero in the network field means this network. This is only used in certain ICMP messages. The extended addressing mode is undefined. Both of these features are reserved for future use.

The actual values assigned for network addresses is given in "Assigned Numbers" [9].

The local address, assigned by the local network, must allow for a single physical host to act as several distinct internet hosts. That is, there must be a mapping between internet host addresses and network/host interfaces that allows several internet addresses to correspond to one interface. It must also be allowed for a host to have several physical interfaces and to treat the datagrams from several of them as if they were all addressed to a single host.

Address mappings between internet addresses and addresses for ARPANET, SATNET, PRNET, and other networks are described in "Address Mappings" [5].
 

Programming Requirements

Packet Dump:

You must print out the following information as extracted from the incoming packet:

    ETHER:  ----- Ether Header -----
     ETHER:
     ETHER:  Packet size : 210 bytes
     ETHER:  Destination : 08-00-20-01-3d-94   Type: Individual Global
     ETHER:  Source      : 08-00-69-01-5f-0e        Type: Individual Global
     ETHER:  Ethertype   : 0800 (IP) (Note: Here it prints either ARP, IP, or UNKNOWN)
     ETHER:

              IP:   ----- IP Header -----
     IP:
     IP:   Version = 4
     IP:   Header length = 20 bytes
     IP:   Type of service = 0x00
     IP:         xxx. .... = 0 (precedence)
     IP:         ...0 .... = normal delay
     IP:         .... 0... = normal throughput
     IP:         .... .0.. = normal reliability
     IP:   Total length = 64 octets
     IP:   Identification = 25372
     IP:   Flags = 0x4
     IP:         .1.. .... = do not fragment
     IP:         ..0. .... = last fragment
     IP:   Fragment offset = 0 bytes
     IP:   Time to live = 100 seconds/hops
     IP:   Protocol = 6 (TCP)
    IP:   Header checksum = 4b14
     IP:   Source address = 128.128.8.1, lorenzo.cs.purdue.edu
     IP:   Destination address = 7.255.255.11, xinu8.cs.purdue.edu
     IP:   No options
     IP:

0000 08 00 20 01 3d 94 08 00 69 01 5f 0e 08 00 45 00.......% /!@...E.
0010 00 40 63 1c 40 00 64 00 06 05 0a 80 80 08 01 07 .@....d. ........
0020 ff ff 0b 2c 76 5f 00 2c 00 00 54 45 44 35 30 30 ...,v_., ..TED500
0030 30 20 20 20 20 20 20 20 20 7c 38 30 7c 30 30 2d 0....... |80|00-
0040 32 35 2d 32 46 2d 32 31 2d 34 30 2d 31 32 25 00 -2F-21.. -40-12..

After printing out the Ethernet header for the MAC and the IP packet, print out the raw packet as shwon above. The hex dump must contain be formatted as: Byte Count - Hex (16 octets) - ASCII Representation. Print out non-pritable charcters as a ".". Begin the packet dump at the start of the buffer received from the WinPCap library.

IP Level Ping-pong:

As before, you will again play the "ping-pong" game with your lab partner and their program; however, in this case, the payload will be in the next protocol layer above the IP packet (layer 4). Your program will dump the information of all packets received, but it will only handle the IP packets that are IP addressed to your machine. To do this, you must now know the MAC and IP addresses of your machine.

Project Requirements Summary:

  1. Acquire the packet buffer and parse and label:
    1. Layer 2 (Ethernet) - Done in the previous lab.
    2. Layer 3 (IP)
      1. Version
      2. IHL
      3. Type of Service
      4. Total Length
      5. Identification
      6. Flags
      7. Fragment Offset
      8. Time to Live
      9. Protocol
      10. Header Checksum
      11. Source Address
      12. Destination Addres
      13. - No Options
  2. Hex Dump Packet as shown above.
  3. If the packet protocol is a Layer 4 Ping-Pong as defined by you and your partner, process the ping-pong packet.
    1. Build the required IP header filling in all fields appropriately for sending back to your partner.
    2. Create the appropriate header checksum as required by the IP standard.