The primary purpose of protocols at layer 3 of the OSI model is to allow for communication between networks. As you just saw, MAC addresses are used for communication on a single network at layer 2. In much the same fashion, layer 3 is responsible for addresses for internetwork communication. A few protocols can do this, but the most common is the Internet Protocol (IP). Here, we’ll examine IP version 4 (IPv4), which is defined in RFC 791.
In order to understand the functionality of IPv4, you need to know how traffic flows between networks. IPv4 is the workhorse of the communication process and is ultimately responsible for carrying data between devices, regardless of where the communication endpoints are located.
A simple network in which all devices are connected via hubs or switches is called a local area network (LAN). When you want to connect two LANs together, you can do so with a router. Complex networks can consist of thousands of LANs connected through thousands of routers worldwide. The Internet itself is a collection of millions of LANs and routers.
IP Addresses
IP addresses are 32-bit addresses used to uniquely identify devices connected to a network. It is a bit much to expect someone to remember a sequence of ones and zeros that is 32 characters long, so IP addresses are written in dottedquad notation.
In dotted-quad notation, each of the four sets of ones and zeros that make up an IP address is converted to base 10 and represented as a number between 0 and 255 in the format A.B.C.D (see Figure 6-7). For example, consider the IP address 11000000 10101000 00000000 00000001. This value is obviously a bit much to remember or notate. Fortunately, using dottedquad notation, we can represent it as 192.168.0.1.
IP addresses are divided into four distinct parts for a reason. An IP address consists of two parts: a network address and a host address. The network address identifies the LAN the device is connected to, and the host address identifies the device itself on that network. The determination of which part of the IP address belongs to the network or host address is not always the same. This is actually determined by another set of addressing information called the network mask (netmask), sometimes also referred to as a subnet mask.
Figure 6-7: Dotted-quad IPv4 address notation
The netmask identifies which portion of the IP address belongs to the network address and which part belongs to the host address. The netmask number is also 32 bits long, and every bit that is set to a 1 identifies the portion of the IP address that is reserved for the network address. The remaining bits set to 0 identify the host address.
For example, consider the IP address 10.10.1.22, represented in binary as 00001010 00001010 00000001 00010110. In order to determine the allocation of each section of the IP address, we can apply our netmask. In this case, our netmask is 11111111 11111111 00000000 00000000. This means that the first half of the IP address is reserved for the network address (10.10 or 00001010 00001010) and the last half of the IP address identifies the individual host on this network (.1.22 or 00000001 00010110), as shown in Figure 6-8.
Figure 6-8: The netmask determines the allocation of the bits in an IP address.
Netmasks can also be written in dotted-quad notation. For example, the netmask 11111111 11111111 00000000 00000000 is written as 255.255.0.0.
IP addresses and netmasks are commonly written in Classless Inter-Domain Routing (CIDR) notation for shorthand. In this form, an IP address is written in full, followed by a forward slash (/) and the number of bits that represent the network portion of the IP address. For example, an IP address of 10.10.1.22 and a netmask of 255.255.0.0 would be written in CIDR notation as 10.10.1.22/16.
The IPv4 Header
The source and destination IP addresses are the crucial components of the IPv4 packet header, but that’s not all of the IP information you will find within a packet. The IP header is actually quite complex compared with the ARP packet we just examined. It includes a lot of extra functionality that helps IP do its job.
As shown in Figure 6-9, the IPv4 header has the following fields:
Version The version of IP being used
Header Length The length of the IP header
Type of Service A precedence flag and type of service flag, which areused by routers to prioritize traffic
Total Length The length of the IP header and the data included in the packet
Identification A unique identification number used to identify a packet or sequence of fragmented packets
Flags Used to identify whether or not a packet is part of a sequence of fragmented packets
Fragment Offset If a packet is a fragment, the value of this field is used to reassemble the packets in the correct order.
Time to Live Defines the lifetime of the packet, measured in hops/seconds through routers
Protocol Used to identify the type of packet coming next in the sequence of packets
Header Checksum An error-detection mechanism used to verify the contents of the IP header are not damaged or corrupted
Source IP Address The IP address of the host that sent the packet
Destination IP Address The IP address of the packet’s destination
Options Reserved for additional IP options. It includes options for source routing and timestamps.
Data The actual data being transmitted with IP
Figure 6-9: The IPv4 packet structure
Time to Live
The Time to Live (TTL) value defines a period of time that can be elapsed or a maximum number of routers a packet can traverse before the packet is discarded. A TTL is defined when a packet is created, and generally is decremented by 1 every time the packet is forwarded by a router. For example, if a packet has a TTL of 2, the first router it reaches will decrement the TTL to 1 and forward it to the second router. This router will then decrement the TTL to 0, and if the final destination of the packet is not on that network, the packet will be discarded (see Figure 6-10). Since the TTL value is
technically time-based, a very busy router could decrement the TTL value by more than 1, but generally, it’s safe to assume that one routing device will decrement a TTL by only 1 most of the time.
Figure 6-10: The TTL of a packet decreases every time it traverses a router.
Why is the TTL value important? Typically, we are concerned about the lifetime of a packet only in terms of the time that it takes to travel from its source to its destination. However, consider a packet that must travel to a host across the Internet while traversing dozens of routers. At some point in that packet’s path, it could encounter a misconfigured router and lose the path to its final destination. In such a case, the router could do a number of things, one of which could result in the packet being forwarded around a network in a never-ending loop.
If you have any programming background at all, you know that a loop that never ends can cause all sorts of issues, typically resulting in a program or an entire operating system crashing. Theoretically, the same thing could occur with packets on a network. The packets would keep looping between routers. As the number of looping packets increased, the available bandwidth on the network would deplete until a DoS condition occurred. To prevent this potential problem, the TTL field of the IP header was created.
Let’s look at an example of this in Unicorn. The file ip_ttl_source.pcap contains two ICMP packets. ICMP (discussed later in this chapter) utilizes IP to deliver packets, as we can see by expanding the IP header section in the Packet Details pane (see Figure 6-11).
Figure 6-11: The IP header of the source packet
You can see that the version of IP being used is version 4 , the IP header length is 20 bytes , the total length of the header and payload is 60 bytes , and the value of the TTL field is 128 .
The primary purpose of an ICMP ping is to test communication between devices. Data is sent from one host to another as a request, and the receiving host should send that data back as a reply. In this file, we have one device with the address of 10.10.0.3 sending an ICMP request to a device with the address 192.168.0.128 . This initial capture file was created at the source host, 10.10.0.3.
Now open the file ip_ttl_dest.pcap. In this file, the data was captured at the destination host, 192.168.0.128. Expand the IP header of the first packet in this capture to examine its TTL value (see Figure 6-12).
Figure 6-12: The IP header tells us that the TTL has been lowered by 1.
You should immediately notice that the TTL value is 127 , one less than the original TTL of 128. Without even knowing the architecture of the network, we can conclude that these two devices are separated by one router and that the passage through that router reduced the TTL value by one.
IP Fragmentation
Packet fragmentation is a feature of IP that permits reliable delivery of data acrossvarying types of networks by splitting a data stream into smaller fragments.
The fragmentation of a packet is based on the maximum transmission unit (MTU) size of the layer 2 data link protocol in use and the configuration of the devices using these layer 2 protocols. In most cases, the layer 2 data link protocol in use is Ethernet. Ethernet has a default MTU of 1500, which means that the maximum packet size that can be transmitted over an Ethernet network is 1,500 bytes (not including the 14-byte Ethernet header itself).
TIPS: Although there are standard MTU settings, the MTU of a device can be reconfigured manually in most cases. An MTU setting is assigned on a per-interface basis and can be modified on Windows and Linux systems, as well as on the interfaces of managed routers.
When a device prepares to transmit an IP packet, it determines whether it must fragment the packets by comparing the packet’s data size to the MTU of the network interface from which the packet will be transmitted. If the data size is greater than the MTU, the packet will be fragmented. Fragmenting a packet involves the following steps:
1. The device splits the data into the number of packets required for successful data transmission.
2. The Total Length field of each IP header is set to the segment size of each fragment.
3. The More Fragments flag is set to 1 on all packets in the data stream, except for the last one.
4. The Fragment Offset field is set in the IP header of the fragments.
5. The packets are transmitted.
The file ip_frag_source.pcap was taken from a computer with the address 10.10.0.3, transmitting a ping request to a device with address 192.168.0.128. Notice that the Info column of the Packet List pane lists two fragmented IP packets, followed by the ICMP (ping) request.
Begin by examining the IP header of packet 1 (see Figure 6-13).
You can see that this packet is part of a fragment based on the More Fragments and Fragment Offset fields. Packets that are fragments either will have a positive Fragment Offset value or will have the More Fragments flag set. In the first packet, the More Fragments flag is set , indicating that the receiving device should expect to receive another packet in this sequence. The Fragment Offset is set to 0 , indicating this packet is the first in a series of fragments.
Figure 6-13: More fragments and fragment offset values can indicate a fragmented packet.
The third packet (see Figure 6-15) does not have the More Fragments flag set , which marks it as the last fragment in the data stream, and the Fragment Offset is set to 2960 , the result of 1480 + (1500 – 20). These fragments can all be identified as part of the same series of data because they have the same values in the Identification field of the IP header.
Figure 6-15: More Fragments is not set, indicating the last fragment.