7
NETWORK LAYER PROTOCOLS

Whether you’re troubleshooting latency issues, identifying malfunctioning applications, or zeroing in on security threats in order to spot abnormal traffic, you must first understand normal traffic. In the next couple of chapters, you’ll learn how normal network traffic works at the packet level as we journey from the bottom of the OSI model all the way to the top. Each protocol section has at least one associated capture file, which you can download and work with directly.

In this chapter, we’ll specifically focus on the network layer protocols that are the workhorses of network communication: ARP, IPv4, IPv6, ICMP, and ICMPv6.

The next three chapters on network protocols are arguably the most important chapters in this book. Skipping this discussion would be like making Thanksgiving dinner without preheating the oven. Even if you already have a good grasp of how each protocol functions, give these chapters at least a quick read in order to review the packet structure of each.

Address Resolution Protocol (ARP)

Both logical and physical addresses are used for communication on a network. Logical addresses allow for communication among multiple networks and indirectly connected devices. Physical addresses facilitate communication on a single network segment for devices that are directly connected to each other with a switch. In most cases, these two types of addressing must work together in order for communication to occur.

Consider a scenario in which you wish to communicate with a device on your network. This device may be a server of some sort or just another workstation you need to share files with. The application you are using to initiate the communication is already aware of the remote host’s IP address (via DNS, covered in Chapter 9), meaning the system should have all it needs to build the layer 3 through 7 information of the packet it wants to transmit. The only piece of information it needs at this point is the layer 2 data link information containing the MAC address of the target host.

MAC addresses are needed because a switch that interconnects devices on a network uses a Content Addressable Memory (CAM) table, which lists the MAC addresses of all devices plugged into each of its ports. When the switch receives traffic destined for a particular MAC address, it uses this table to know which port to send the traffic through. If the destination MAC address is unknown, the transmitting device will first check for the address in its cache; if the address isn’t there, then it must be resolved through additional communication on the network.

The resolution process that TCP/IP networking (with IPv4) uses to resolve an IP address to a MAC address is called the Address Resolution Protocol (ARP), which is defined in RFC 826. The ARP resolution process uses only two packets: an ARP request and an ARP response (see Figure 7-1).

The transmitting computer sends out an ARP request that basically says, “Howdy, everybody. My IP address is 192.168.0.101, and my MAC address is f2:f2:f2:f2:f2:f2. I need to send something to whoever has the IP address 192.168.0.1, but I don’t know the hardware address. Will whoever has this IP address please respond with your MAC address?”

This packet is broadcast to every device on the network segment. Any device that doesn’t have this IP address simply discards the packet. The device that does have the address sends an ARP reply with an answer such as “Hey, transmitting device, I’m the one you’re looking for with the IP address 192.168.0.1. My MAC address is 02:f2:02:f2:02:f2.”

Once this resolution process is completed, the transmitting device updates its cache with the MAC-to-IP address association of the receiving device and can begin sending data.

Figure 7-1: The ARP resolution process

Seeing this process in action will help you understand how it works. But before we look at some examples, let’s examine the ARP packet header.

ARP Packet Structure

As shown in Figure 7-2, the ARP header includes the following fields:

Hardware Type   The layer 2 type used—in most cases, this is Ethernet (type 1)

Protocol Type   The higher-layer protocol for which the ARP request is being used

Hardware Address Length   The length (in octets/bytes) of the hardware address in use (6 for Ethernet)

Protocol Address Length   The length (in octets/bytes) of the logical address of the specified protocol type

Operation   The function of the ARP packet: either 1 for a request or 2 for a reply

Figure 7-2: The ARP packet structure

Sender Hardware Address   The hardware address of the sender

Sender Protocol Address   The sender’s upper-layer protocol address

Target Hardware Address   The intended receiver’s hardware address (all zeroes in ARP requests)

Target Protocol Address   The intended receiver’s upper-layer protocol address

Now open the file arp_resolution.pcapng to see this resolution process in action. We’ll focus on each packet individually as we walk through this process.

Packet 1: ARP Request

The first packet is the ARP request, as shown in Figure 7-3. We can confirm that this packet is a true broadcast packet by examining the Ethernet header in Wireshark’s Packet Details pane. The packet’s destination address is ff:ff:ff:ff:ff:ff ➊. This is the Ethernet broadcast address, and anything sent to it will be broadcast to all devices on the current network segment. The source address of this packet in the Ethernet header is listed as our MAC address ➋.

Given this structure, we can discern that this is indeed an ARP request on an Ethernet network using IPv4. The sender’s IP address (192.168.0.114) and MAC address (00:16:ce:6e:8b:24) are listed ➌, as is the IP address of the target (192.168.0.1) ➎. The MAC address of the target—the information we are trying to get—is unknown, so the target MAC is listed as 00:00:00:00:00:00 ➍.

Figure 7-3: An ARP request packet

Packet 2: ARP Response

In the response to the initial request (see Figure 7-4), the Ethernet header now has a destination address of the source MAC address from the first packet. The ARP header looks similar to that of the ARP request, with a few changes:

•     The packet’s operation code (opcode) is now 0x0002 ➊, indicating a reply rather than a request.

•     The addressing information is reversed—the sender MAC address and IP address are now the target MAC address and IP address ➌.

•     Most important, all the information is present, meaning we now have the MAC address (00:13:46:0b:22:ba) ➋ of our host at 192.168.0.1.

Figure 7-4: An ARP reply packet

Gratuitous ARP

Where I come from, when something is done “gratuitously,” the word usually carries a negative connotation. A gratuitous ARP, however, is a good thing.

In many cases, a device’s IP address can change. When this happens, the IP-to-MAC address mappings that hosts on the network have in their caches will be invalid. To prevent this from causing communication errors, a gratuitous ARP packet is transmitted on the network to force any device that receives it to update its cache with the new IP-to-MAC address mapping (see Figure 7-5).

Figure 7-5: The gratuitous ARP process

A few different scenarios can spawn a gratuitous ARP packet. One of the most common is the changing of an IP address. Open the capture file arp_gratuitous.pcapng, and you’ll see this in action. This file contains only a single packet (see Figure 7-6) because that’s all that’s involved in gratuitous ARP.

Figure 7-6: A gratuitous ARP packet

Examining the Ethernet header, you can see that this packet is sent as a broadcast so that all hosts on the network receive it ➊. The ARP header looks like an ARP request, except that the sender IP address ➋ and the target IP address ➌ are the same. When received by other hosts on the network, this packet will cause them to update their ARP tables with the new IP-to-MAC address association. Because this ARP packet is unsolicited but results in a client updating its ARP cache, the packet is considered gratuitous.

You’ll notice gratuitous ARP packets in a few situations. As mentioned, changing a device’s IP address will generate a gratuitous packet. Also, some operating systems will perform a gratuitous ARP on startup. Additionally, some systems use gratuitous ARP packets to support load balancing.

Internet Protocol (IP)

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 used in internetwork communication. A few protocols can do this, but the most common is the Internet Protocol (IP), which currently has two versions in use—IP version 4 and IP version 6. We’ll start by examining IP version 4 (IPv4), which is defined in RFC 791.

Internet Protocol Version 4 (IPv4)

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, 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.

IPv4 Addresses

IPv4 addresses are 32-bit assigned numbers used to uniquely identify devices connected to a network. It’s 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 dotted-quad (or dotted-decimal) 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 7-7). For example, consider the IP address 11000000 10101000 00000000 00000001. This value is obviously a bit much to remember or notate. Fortunately, using dotted-quad notation, we can represent it as 192.168.0.1.

Figure 7-7: Dotted-quad IPv4 address notation

An IP address consists of two parts: a network portion and a host portion. The network portion identifies the LAN the device is connected to, and the host portion identifies the device itself on that network. The determination of which part of the IP address belongs to the network or host portion is not always the same. This information is communicated by another set of addressing information called the network mask (netmask) or sometimes referred to as a subnet mask.

The netmask identifies which part of the IP address belongs to the network portion and which part belongs to the host portion. The netmask number is also 32 bits long, and every bit that is set to a 1 identifies the part of the IP address that is reserved for the network portion. The remaining bits are set to 0 to identify the host portion.

For example, consider the IP address 10.10.1.22, represented in binary as 00001010 00001010 00000001 00010110. 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 (10.10 or 00001010 00001010) is reserved for the network portion, and the last half of the IP address (.1.22 or 00000001 00010110) identifies the individual host on this network, as shown in Figure 7-8.

Figure 7-8: The netmask determines the allocation of the bits in an IP address.

As indicated in Figure 7-8, 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. 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.

IPv4 Packet Structure

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’ll find in a packet. The IP header is quite complex compared to the ARP packet we just examined; it includes a lot of extra functionality that helps IP do its job.

As shown in Figure 7-9, the IPv4 header has the following fields:

Version   The version of IP being used (this will always be 4 for IPv4). Header Length The length of the IP header.

Type of Service   A precedence flag and type of service flag, which are used 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 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 or seconds through routers.

Protocol   Identifies the transport layer header that encapsulates the IPv4 header.

Header Checksum   An error-detection mechanism used to verify that 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 7-9: The IPv4 packet structure

Time to Live

The Time to Live (TTL) value defines a period of time that can elapse or a maximum number of routers a packet can traverse before the packet is discarded for IPv4. 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 zero, and if the final destination of the packet is not on that network, the packet will be discarded (see Figure 7-10).

Figure 7-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’s being forwarded around a network in a never-ending loop.

An infinite loop can cause all sorts of issues, but it typically results in the crash of a program or an entire operating system. 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 denial of service condition occurred. To prevent this, TTL was created.

Let’s look at an example of this in Wireshark. The file ip_ttl_source.pcapng contains two ICMP packets. ICMP (discussed later in this chapter) uses IP to deliver packets, as we can see by expanding the IP header section in the Packet Details pane (see Figure 7-11).

Figure 7-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.pcapng. 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 7-12).

You should immediately notice that the TTL value is 127 ➊, 1 less than the original TTL of 128. Without even knowing the architecture of the network, we can conclude that one router separates these devices and thus the passage through that router reduced the TTL value by 1.

Figure 7-12: The IP header shows us that the TTL has been decremented by 1.

IP Fragmentation

Packet fragmentation is a feature of IP that permits reliable delivery of data across varying 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 this layer 2 protocol. In most cases, the layer 2 data link protocol in use is Ethernet. Ethernet has a default MTU of 1,500, 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).

When a device prepares to transmit an IP packet, it determines whether it must fragment the packet 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.pcapng was taken from a computer with the address 10.10.0.3, transmitting a ping request to a device with the 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 7-13).

Figure 7-13: More fragments and Fragment offset values can indicate a fragmented packet.

You can see that this packet is part of a fragment based on the More fragments and Fragment offset fields. Packets that are fragments will either have a positive Fragment offset value or 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 that this packet is the first in a series of fragments.

The IP header of the second packet (see Figure 7-14) also has the More fragments flag set ➊, but in this case, the Fragment offset value is 1480 ➋. This is indicative of the 1,500-byte MTU, minus 20 bytes for the IP header.

The third packet (see Figure 7-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 7-14: The Fragment offset value increases based on the size of the packets.

Figure 7-15: More fragments is not set, indicating that this fragment is the last.

While it isn’t as common to see fragmented packets on a network as it used to be, understanding why packets are fragmented is useful so that when you do encounter them, you can diagnose issues or spot missing fragments.

Internet Protocol Version 6 (IPv6)

When the IPv4 specification was written, nobody had any idea that we would eventually have the number of internet-connected devices that exist today. The maximum IPv4 addressable space was limited to just south of 4.3 billion addresses. The actual amount of addressable space shrinks even further when you subtract ranges reserved for special uses such as testing, broadcast traffic, and RFC1918 internal addresses. While several efforts were made to delay the exhaustion of IPv4 addresses, ultimately the only way to address this limitation was to develop a new version of the IP specification.

Thus, the IPv6 specification was created, with its first version released in 1998 as RFC 2460. This version provided several performance enhancements, including a much larger address space. In this section, we’ll look at the IPv6 packet structure and discuss how IPv6 communications differ from those of its predecessor.

IPv6 Addresses

IPv4 addresses were limited to 32 bits, a length that provided an addressable space measured in the billions. IPv6 addresses are 128 bit, providing an addressable space measured in undecillions (a trillion trillion trillion). That’s quite an upgrade!

Since IPv6 addresses are 128 bits, they are unwieldy to manage in binary form. Most of the time, an IPv6 address is written in eight groups of 2 bytes in hexadecimal notation, with each group separated by a colon. For example, a very simple IPv6 address looks like this:

1111:aaaa:2222:bbbb:3333:cccc:4444:dddd

Your first thought is probably the same one many have who are used to remembering IPv4 addresses: IPv6 addresses are virtually impossible to memorize. That is an unfortunate trade-off for a much larger address space.

One feature of IPv6 address notation that will help in some cases is that some groups of zeroes can be collapsed. For example, consider the following IPv6 address:

1111:0000:2222:0000:3333:4444:5555:6666

You can collapse the grouping containing the zeroes completely so it isn’t visible, like this:

1111::2222:0000:3333:4444:5555:6666

However, you can only collapse a single group of zeroes, so the following address would be invalid:

1111::2222::3333:4444:5555:6666

Another consideration is that leading zeroes can be dropped from IPv6 addresses. Consider this example in which there are zeroes in front of the fourth, fifth, and six groups:

1111:0000:2222:0333:0044:0005:ffff:ffff

You could represent the address more efficiently like this:

1111::2222:333:44:5:ffff:ffff

This isn’t quite as easy to use as an IPv4 address, but it’s a lot easier to deal with than the longer notation.

An IPv6 address has a network portion and a host portion, often called a network prefix and interface identifier, respectively. The distribution of these fields varies depending on the classification of the IPv6 communication. IPv6 traffic is broken down into three classifications: unicast, multicast, or anycast. In most cases, you’ll probably be working with link-local unicast traffic, which is communication from one device to another inside a network. The format of a link-local unicast IPv6 address is shown in Figure 7-16.

Figure 7-16: The parts of an IPv6 link-local unicast address

Link-local addresses are used when communication is intended for another device within the same network. A link-local address can be identified by having its most significant 10 bits set to 1111111010 and the next 54 bits set to all zeroes. Thus, you can spot a link-local address when the first half is fe80:0000:0000:0000.

The second half of a link-local IPv6 address is the interface ID portion, which uniquely identifies a network interface on an endpoint host. On Ethernet networks, this can be based on the MAC address of the interface. However, a MAC address is only 48 bits. To fill up the entire 64-bit space, the MAC address is cut in half, and the value 0xfffe is added between each half as padding to create a unique identifier. Lastly, the seventh bit of the first byte is inverted. That’s a bit complex, but consider the interface ID in Figure 7-17. The original MAC address for the device represented by this ID was 78:31:c1:cb:b2:56. The bytes 0xfffe were added in the middle, and flipping the seventh bit of the first byte changed the 8 to an a.

Figure 7-17: The interface ID utilizes an interface MAC address and padding.

IPv6 addresses can be represented with CIDR notation just like IPv4 addresses. In this example, 64 bits of addressable space are represented with a link-local address:

fe80:0000:0000:0000:/64

The composition of an IPv6 address changes when it is used with global unicast traffic that is routed over the public internet (see Figure 7-18). When used in this manner, a global unicast is identified by having its first 3 bits set to 001, followed by a 45-bit global routing prefix. The global routing prefix, which is assigned to organizations by the Internet Assigned Numbers Authority (IANA), is used to uniquely identify an organization’s IP space. The next 16 bits are the subnet ID, which can be used for hierarchical addressing, similar to the netmask portion of an IPv4 address. The final 64 bits are used for the interface ID, just as with link-local unicast addresses. The routing prefix and subnet ID can vary in size.

Figure 7-18: The parts of an IPv6 global unicast address

IPv6 provides a lot more efficiency than IPv4 in terms of routing packets to their destination and making effective use of address space. This efficiency is due to the larger range of addresses available and the use of link-local and global addressing along with unique host identifiers.

IPv6 Packet Structure

The structure of the IPv6 header has grown to support more features, but it was also designed to be easier to parse. Instead of being variable in size with a header length field that needs to be checked to parse the header, headers are now a fixed 40 bytes. Additional options are provided via extension headers. The benefit is that most routers only need to process the 40-byte header to forward the packet along.

As shown in Figure 7-19, the IPv6 header has the following fields:

Version   The version of IP being used (this is always 6 for IPv6).

Traffic Class   Used to prioritize certain classes of traffic.

Figure 7-19: The IPv6 packet structure

Flow Label   Used by a source to label a set of packets belonging to the same flow. This field is typically used for quality of service (QoS) management and to ensure packets that are part of the same flow take the same path.

Payload Length   The length of the data payload following the IPv6 header.

Next Header   Identifies the layer 4 header that encapsulates the IPv6 header. This field replaces the Protocol field in IPv4.

Hop Limit   Defines the lifetime of the packet, measured in hops through routers. This field replaces the TTL field in IPv4.

Source IP Address   The IP address of the host that sent the packet.

Destination IP Address   The IP address of the packet’s destination.

Let’s compare an IPv4 and an IPv6 packet to examine a few of the differences by looking at http_ip4and6.pcapng. In this capture, a web server was configured to listen for both IPv4 and IPv6 connections on the same physical host. A single client configured with both IPv4 and IPv6 addresses browsed to a server using each of its addresses independently and downloaded the index.php page using HTTP via the curl application (Figure 7-20).

Upon opening the capture, you should readily see which packets belong to which conversation based on the addresses in the Source and Destination columns in the Packet List area. Packets 1 through 10 represent the IPv4 stream (stream 0), and packets 11 through 20 represent the IPv6 stream (stream 1). You can filter for each of these streams from the Conversations window or by entering tcp.stream == 0 or tcp.stream == 1 in the filter bar.

Figure 7-20: Connections between the same physical hosts using different IP versions

We’ll cover HTTP, the protocol responsible for serving web pages on the internet, in depth in Chapter 8. In this example, just note that the business of serving web pages remains consistent regardless of which lower-layer network protocol is used. The same can be said of TCP, which also operates in a consistent manner. This is a prime example of encapsulation in action. Although IPv4 and IPv6 function differently, the protocols functioning at different layers are unaffected.

Figure 7-21 provides a side-by-side comparison of two packets with the same function—packets 1 and 11. Both packets are TCP SYN packets designed to initiate a connection from the client to the server. The Ethernet and TCP sections of these packets are nearly identical. However, the IP sections are completely different.

•     The source and destination address formats are different ➏➓.

•     The IPv4 packet is 74 bytes with a 60-byte total length ➊, which includes both the IPv4 header and payload and a 14-byte Ethernet header. The IPv6 packet is 96 bytes with a 40-byte IPv6 payload ➐ and a separate 40-byte IPv6 header along with the 14-byte Ethernet header. The IPv6 header is 40 bytes, double the IPv4 header’s 20 bytes, to accommodate the larger address size.

•     IPv4 identifies the protocol with the Protocol field ➍, whereas IPv6 identifies it with the Next header field (which can also be used to specify extension headers) ➑.

•     IPv4 has a TTL field ➌, whereas IPv6 accomplishes the same functionality using the Hop limit field ➒.

•     IPv4 includes a header checksum value ➎, while IPv6 does not.

•     The IPv4 packet is not fragmented, but it still includes values for those options ➋. The IPv6 header doesn’t contain this information because, if fragmentation were required, it would be implemented in an extension header.

Figure 7-21: A side-by-side comparison of IPv4 (top) and IPv6 (bottom) packets performing the same function

Performing side-by-side comparisons of IPv4 and IPv6 traffic is a great way to fully appreciate the difference between how the two protocols operate.

Neighbor Solicitation and ARP

When we discussed the different classifications of traffic earlier, I listed uni-cast, multicast, and anycast but did not list broadcast traffic. IPv6 doesn’t support broadcast traffic because broadcast is viewed as an inefficient mechanism for transmission. Because there is no broadcast, ARP can’t be used for hosts to find each other on a network. So, how do IPv6 devices find each other?

The answer lies with a new feature called neighbor solicitation, a function of Neighbor Discovery Protocol (NDP), which utilizes ICMPv6 (discussed in the last section of this chapter) to do its legwork. To accomplish this task, ICMPv6 uses multicast, a type of communication in which only hosts that subscribe to a data stream will receive and process it. Multicast traffic can be identified quickly because it has its own reserved IP space (ff00::/8).

Although the address resolution process relies on a different protocol, it still uses a very simple request/response workflow. For example, let’s consider a scenario in which a host with the IPv6 address 2001:db8:1:2::1003 wants to communicate with another host identified by the address 2001:db8:1:2::1000. Just as with IPv4, the source device must be able to determine the link-layer (MAC) address of the host it wants to communicate with, since this is intra-network communication. This process is described in Figure 7-22.

Figure 7-22: The neighbor solicitation process for address resolution

In this process, the host 2001:db8:1:2::1003 sends a Neighbor Solicitation (ICMPv6 type 135) packet to every device on the network via multicast, asking, “What is the MAC address for the device whose IP address is 2001:db8:1:2::1000? My MAC address is 00:0C:29:2f:80:31.”

The device assigned that IPv6 address will receive this multicast transmission and respond to the originating host with a Neighbor Advertisement (ICMPv6 type 136) packet. This packet says, “Hi, my network address is 2001:db8:1:2::1000 and my MAC address is 00:0c:29:1f:a7:55.” Once this message is received, communication can begin.

You can see this process in action in the capture file icmpv6_neighbor _solicitation.pcapng. This capture embodies the example we’ve just discussed in which 2001:db8:1:2::1003 wants to communicate with 2001:db8:1:2::1000. Look at the first packet and expand the ICMPv6 portion in the Packet Details window (Figure 7-23) to see that the packet is ICMP type 135 ➋ and was sent from 2001:db8:1:2::1003 to the multicast address ff02::1:ff00:1000 ➊. The source host provided the target IPv6 address it wanted to communicate with ➌, along with its own layer 2 MAC address ➍.

Figure 7-23: A neighbor solicitation packet

The response to the solicitation is found in the second packet in the capture file. Expanding the ICMPv6 portion of the Packet Details window (Figure 7-24) reveals this packet is ICMP type 136 ➋, was sent from 2001:db8:1:2::1000 back to 2001:db8:1:2::1003 ➊, and contains the MAC address 00:0c:29:1f:a7:55 associated with 2001:db8:1:2::1000 ➌.

Figure 7-24: A neighbor advertisement packet

Upon completion of this process, 2001:db8:1:2::1003 and 2001:db8:1:2::1000 begin communicating normally with ICMPv6 echo request and reply packets, indicating the neighbor solicitation process and link-layer address resolution was successful.

IPv6 Fragmentation

Fragmentation support was built into the IPv4 header because it ensured packets could traverse all sorts of networks at a time when network MTUs varied wildly. In IPv6, fragmentation is used less, so the options supporting it are not included in the IPv6 header. A device transmitting IPv6 packets is expected to perform a process called MTU discovery to determine the maximum size of packets it can send before actually sending them. In the event that a router receives a packet that is too large for the MTU on the network it is forwarding to, it will drop the packet and return an ICMPv6 Packet Too Big (type 2) message to the originating host. Upon receipt, the originating host will attempt to resend the packet with a smaller MTU, if such action is supported by the upper-layer protocol. This process will repeat until a small enough MTU is reached or until the payload can be fragmented no more (Figure 7-25). A router will never be responsible for fragmenting packets on its own; the source device is responsible for determining an appropriate MTU for the transmission path and fragmenting appropriately.

Figure 7-25: IPv6 MTU path discovery

If the upper-layer protocol being used in conjunction with IPv6 can’t limit the size of the packet payload, then fragmentation must still be used. A fragmentation extension header can be added to the IPv6 packet to support this scenario. You will find a sample capture showing IPv6 fragmentation in the file named ipv6_fragments.pcapng.

Because the receiving device has a smaller MTU than the sending device, there are two fragmented packets to represent each ICMPv6 echo request and reply in the capture file. The fragmentation header from the first packet is shown in Figure 7-26.

Figure 7-26: An IPv6 fragment header extension

The 8-byte extension header contains all the same fragmentation properties that are found in an IPv4 packet, such as a Fragment offset ➋, More Fragments flag ➌, and Identification field ➍. Instead of being present in every packet, it is only added to the end of packets requiring fragmentation. This more efficient process still allows the receiving system to reassemble the fragments appropriately. Additionally, if this extension header is present, the Next header field will point to the extension header rather than the encapsulating protocol ➊.

IPv6 Transitional Protocols

IPv6 addresses a very real problem, but its adoption has been slow because of the effort required to transition network infrastructure to it. To ease this transition, several protocols allow IPv6 communication to be tunneled across networks that support only IPv4 communication. In this respect, tunneling means that IPv6 communication is encapsulated inside of IPv4 communications just as other protocols may be encapsulated. Encapsulation is usually done in one of three ways:

Router to Router   Uses a tunnel to encapsulate IPv6 traffic from the transmitting and receiving hosts on their networks over an IPv4 network. This method allows entire networks to communicate in IPv6 over intermediary IPv4 links.

Host to Router   Uses encapsulation at the router level to transmit traffic from an IPv6 host over an IPv4 network. This method allows an individual host to communicate in IPv6 to an IPv6 network when the host resides on an IPv4-only network.

Host to Host   Uses a tunnel between two endpoints to encapsulate IPv6 traffic between IPv4- or IPv6-capable hosts. This method allows IPv6 endpoints to communicate directly across an IPv4 network.

While this book won’t cover transitional protocols in depth, it’s helpful to be aware of their existence in case you ever need to investigate them while performing analysis at the packet level. The following are a few common protocols:

6to4   Also known as IPv6 over IPv4, this transitional protocol allows IPv6 packets to be transmitted across an IPv4 network. This protocol supports relays and routers to provide router-to-router, host-to-router, and host-to-host IPv6 communication.

Teredo   This protocol, used for IPv6 unicast communications over an IPv4 network using NAT (network address translation), works by sending IPv6 packets over IPv4 encapsulated in the UDP transport protocol.

ISATAP   This intrasite protocol allows communication between IPv4-and IPv6-only devices within a network in a host-to-host manner.

Internet Control Message Protocol (ICMP)

Internet Control Message Protocol (ICMP) is the utility protocol of TCP/IP, responsible for providing information regarding the availability of devices, services, or routes on a TCP/IP network. Most network-troubleshooting techniques and tools center around common ICMP message types. ICMP is defined in RFC 792.

ICMP Packet Structure

ICMP is part of IP, and it relies on IP to transmit its messages. ICMP contains a relatively small header that changes depending on its purpose. As shown in Figure 7-27, the ICMP header contains the following fields:

Type   The type or classification of the ICMP message, based on the RFC specification

Code   The subclassification of the ICMP message, based on the RFC specification

Checksum   Used to ensure that the contents of the ICMP header and data are intact upon arrival

Variable   A portion that varies depending on the Type and Code fields

Figure 7-27: The ICMP header

ICMP Types and Messages

As noted, the structure of an ICMP packet depends on its purpose, as defined by the values in the Type and Code fields.

You might consider the ICMP Type field the packet’s classification and the Code field its subclass. For example, a Type field value of 3 indicates “destination unreachable.” While this information alone might not be enough to troubleshoot a problem, if that packet were also to specify a Code field value of 3, indicating “port unreachable,” you could conclude that there is an issue with the port with which you are attempting to communicate.

Echo Requests and Responses

ICMP’s biggest claim to fame is the ping utility. Ping is used to test for connectivity to a device. While ping itself isn’t a part of the ICMP spec, it utilizes ICMP to achieve its core functionality.

To use ping, enter ping ipaddress at the command prompt, replacing ipaddress with the actual IP address of a device on your network. If the target device is turned on, your computer has a communication route to it, and there is no firewall blocking that communication, you should see replies to your ping command.

The example in Figure 7-28 shows four successful replies that display their size; round trip time (or RTT), which is the time it takes for the packet to arrive and a response to be received; and TTL used. The Windows utility also provides a summary detailing how many packets were sent, received, and lost. If communication fails, you should see a message telling you why.

Figure 7-28: The ping command being used to test connectivity

Basically, the ping command sends one packet at a time to a device and listens for a reply to determine whether there is connectivity to that device, as shown in Figure 7-29.

Figure 7-29: The ping command involves only two steps.

The ping utility in action is a great example of simple ICMP communication. The packets in the file icmp_echo.pcapng demonstrate what happens when you run ping.

The first packet (see Figure 7-30) shows that host 192.168.100.138 is sending a packet to 192.168.100.1 ➊. When you expand the ICMP portion of this packet, you can determine the ICMP packet type by looking at the Type and Code fields. In this case, the packet is type 8 ➋ and the code is 0 ➌, indicating an echo request. (Wireshark should tell you what the displayed type/code actually is.) This echo (ping) request is the first half of the equation. It is a simple ICMP packet, sent using IP, that contains a small amount of data. Along with the type and code designations and the checksum, we also have a sequence number that is used to pair requests with replies, and there is a random text string in the variable portion of the ICMP packet.

Figure 7-30: An ICMP echo request packet

The second packet in this sequence is the reply to our request (see Figure 7-31). The ICMP portion of the packet is type 0 ➊ and code 0 ➋, indicating that this is an echo reply. Because the sequence number and identifier in the second packet match those of the first ➌, we know that this echo reply matches the echo request in the previous packet. Wireshark displays the values of these fields in big-endian (BE) and little-endian (LE) format. In other words, it represents the data in a different order based on how a particular endpoint might process the data. This reply packet also contains the same 32-byte string of data that was transmitted with the initial request ➍. Once this second packet has been received by 192.168.100.138, ping will report success.

Figure 7-31: An ICMP echo reply packet

Note that you can use variations of the ping command to increase the size of the data padding in echo requests, which forces packets to be fragmented for various types of network troubleshooting. This may be necessary when you’re troubleshooting networks that require a smaller fragment size.

traceroute

The traceroute utility is used to identify the path from one device to another. On a simple network, a path may go through only a single router or no router at all. On a complex network, however, a packet may need to go through dozens of routers to reach its final destination. Thus, it is crucial to be able to trace the exact path a packet takes from one destination to another in order to troubleshoot communication.

By using ICMP (with a little help from IP), traceroute can map the path packets take. For example, the first packet in the file icmp_traceroute.pcapng is pretty similar to the echo request we looked at in the previous section (see Figure 7-32).

In this capture, the packets were generated by running the command tracert 4.2.2.1. To use traceroute on Windows, enter tracert ipaddress at the command prompt, replacing ipaddress with the actual IP address of a device whose path you want to discover. To use traceroute on Linux or Mac, use the command traceroute ipaddress.

Figure 7-32: An ICMP echo request packet with a TTL value of 1

At first glance, this packet appears to be a simple echo request ➌ from 192.168.100.138 to 4.2.2.1 ➊, and everything in the ICMP portion of the packet is identical to the formatting of an echo request packet. However, when you expand the IP header of this packet, you’ll notice something odd: the packet’s TTL value is set to 1 ➋, meaning that the packet will be dropped at the first router that it hits. Because the destination 4.2.2.1 address is an internet address, we know that there must be at least one router between our source and destination devices, so there is no way this packet will reach its destination. That’s good for us, because traceroute relies on the fact that this packet will make it to only the first router it traverses.

The second packet is, as expected, a reply from the first router we reached along the path to our destination (see Figure 7-33). This packet reached this device at 192.168.100.1, its TTL was decremented to 0, and the packet could not be transmitted further, so the router replied with an ICMP response. This packet is type 11 ➊ and code 0 ➋, data that tells us that the destination was unreachable because the packet’s TTL was exceeded during transit.

This ICMP packet is sometimes called a double-headed packet, because the tail end of its ICMP portion contains a copy of the IP header ➌ and ICMP data ➍ that were sent in the original echo request. This information can prove very useful for troubleshooting.

Figure 7-33: An ICMP response from the first router along the path

This process of sending packets with a TTL value of 1 occurs two more times before we get to packet 7. Here, you see the same thing you saw in the first packet, except that this time, the TTL value in the IP header is set to 2, which ensures the packet will make it to the second hop router before it is dropped. As expected, we receive a reply from the next hop router, 12.180.241.1, with the same ICMP destination unreachable and TTL exceeded messages.

This process continues, with the TTL value increasing by 1, until the destination 4.2.2.1 is reached. Right before that happens, however, you’ll see in Figure 7-34 that the request on line 8 timed out. How can a request along the path time out and the process still complete successfully? Typically, this happens when a router is configured to not respond to ICMP requests. The router still receives the request and passes the data forward to the next router, which is why we’re able to see the next hop on line 9 in Figure 7-34. It just didn’t generate the ICMP time to live exceeded packet as the other hops did. With no response, tracert assumes the request has timed out and moves on to the next one.

To sum up, this traceroute process has communicated with each router along the path, building a map of the route to the destination. An example map is shown in Figure 7-34.

Figure 7-34: A sample output from the traceroute utility

ICMP Version 6 (ICMPv6)

The updated version of IP relies heavily on ICMP for functions such as neighbor solicitation and path discovery, as demonstrated in earlier examples. ICMPv6 was established with RFC 4443 to support the feature set needed for IPv6, along with additional enhancements. We don’t cover ICMPv6 separately in this book because it uses the same packet structure as do ICMP packets.

ICMPv6 packets are generally classified as either error messages or informational messages. You can find a full list of the available types and codes from IANA here: http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml.

This chapter has introduced you to a few of the most important protocols you will examine during the process of packet analysis. ARP, IP, and ICMP are at the foundation of all network communications, and they are critical to just about every daily task you will perform. In Chapter 8, we will look at common transport layer protocols, TCP and UDP.