Chapter 5. Network Protocols

Effective packet analysis requires familiarity with the primary protocols in use in modern networks. In this chapter, we will review the most common protocols in their respective layers:

• Network layer protocols
• Transport layer protocols
• Application layer protocols

We'll cover the significant purpose and relevant fields to support network connectivity and/or application functionality in each protocol, as well a sampling of Wireshark capture and display filters for each protocol.

The OSI and DARPA reference models

We reviewed the purpose of the OSI and DARPA reference models in Chapter 2, Networking for Packet Analysts. The visual depiction of their layers is repeated in the following diagram as a reference and summary of some of the primary protocols and where they fit into their respective layers:

Network layer protocols

Network layer protocols, also known as Internet layer protocols in the DARPA reference model, provide basic network connectivity and internetwork communications services. In this layer, you will predominantly find the IP protocol being used to get packets transported across the network, along with ARP, IGMP, and ICMP.

We covered the IP and ARP protocol packet header structures and fields in Chapter 2, Networking for Packet Analysts, so this information won't be repeated. However, basic Wireshark capture and display filters are provided here and also for the remaining protocols in the following sections:

Wireshark IPv4 filters

Capture filter(s): ip

Display filter(s): ip ip.addr==192.168.1.1 ip.src== ip.dst== ip.id > 2000

Wireshark ARP filters

Capture filter(s): arp

Display filter(s): arp arp.opcode==1 arp.src.hw_mac==00:1c:25:99:db:85

Internet Group Management Protocol

The Internet Group Management Protocol (IGMP) is used by hosts to notify adjacent routers of established multicast (one-to-any) group memberships. In other words, IGMP enables a computer that provides content (video feeds), for example, to provide such content to a distributed group of users using one set of the multicast address ranges (in the 224.0.0.0 to 239.255.255.255 class D multicast range). This multicast capability depends on routers that are capable and configured to support this service; clients must join the multicast group. When a host wants to start a multicast, it sends an IGMP Membership Report message to the 224.0.0.2 (all multicast routers) address that specifies the multicast IP address for this particular group. Clients who wish to join or leave this group (so they can receive the multicast content) send an IGMP join or leave message to the router. The following table shows the various ranges for addresses:

Starting address range	Ending address range	Description
224.0.0.0	224.0.0.255	These are reserved for special well-known multicast addresses
224.0.1.0	238.255.255.255	These are globally-scoped (Internet-wide) multicast addresses
239.0.0.0	239.255.255.255	These are locally-scoped and administered multicast addresses

The following screenshot shows the significant fields in the IGMP protocol header:

The preceding significant fields in the IGMP protocol header include:

• Type: This is a type of IGMP message. Type 22 is IGMPv3 Membership Report.
• Record Type: There are different types of Group Records. The value of Record Type 3 is Change To Include Mode, which indicates that content from the source device is to be forwarded to the in-group hosts by the multicast router.
• Multicast Address: This is the multicast IP address for a specific group.

You should also note the following interesting fields in the previous protocol layers:

• The Ethernet frame destination MAC address is one of a range of multicast MAC addresses (01:00:5e:00:00:00 – 01:00:5e:7f:ff:ff)
• The Protocol field in the IP header specifies IGMP 2
• The IP layer destination IP Address is 224.0.0.22, which is a reserved IGMPv3 multicast IP address

The IGMP protocol has multiple versions and is rather complex. Refer to the protocol references provided at the beginning of this chapter for more information.

Wireshark IGMP filters

Capture filter(s): igmp

Display filter(s): igmp igmp.type==0x22 igmp.record_type==4 igmp.maddr==244.0.1.60

Internet Control Message Protocol

The Internet Control Message Protocol (ICMP) is used by network devices such as routers to send error messages indicating that a requested service is not available, or a host or network router could not be reached. ICMP is a control protocol. This means that although it is transported as IP datagrams, it does not carry the application data—instead, it carries the information about the status of the network itself.

ICMP pings

One of the most well-known uses of ICMP is to ping, wherein a device sends an ICMP echo request (Type 8, Code 0) packet to a distant host (via that host's IP address), which will (if the ICMP service isn't disabled or blocked by an intermediate firewall) respond with an ICMP echo reply (Type 0, Code 0) packet. Pings are used to determine whether the target host is available and can be reached over the network. By measuring the time that expires between ping requests and replies, we know the round trip time (RTT) delay time over the network path.

ICMP traceroutes

A variation of ping functionality is used to perform a traceroute (also known as traceroute), which is a list of the IP addresses of the router interfaces that packets traverse to get from a sending device to a target host or device. The traceroutes are used to determine or confirm the network path taken from a sending device to a target host or device.

A traceroute is accomplished by sending the ICMP echo request packets to a distant host just as in a normal ping, but with modifications to the Time-to-Live (TTL) field in the IP header of each packet. The traceroute function takes advantage of the fact that each router in a network path decrements the TTL value in a packet by 1, so as the packet traverses, the routers in a path and the TTL value will decrease accordingly along the way. If a router receives a packet with a TTL value of 1, it will send an ICMP TTL exceeded in transit (Type 11, Code 0) error message back to the sender (along with a copy of the request packet it received) and otherwise discard (not forward) the packet.

The traceroute works by sequentially setting the TTL in multiple ICMP request packets to 1, then to 2, then 3, and so on, which results in each router in the network path sending TTL exceeded error messages back to the sender. Since these returned messages are sent by the in-path router using the IP address of the interface where the ICMP packet was received, the traceroute utility can build and display a progressive list of router interface IP addresses in the path and the RTT delay to each router.

ICMP control message types

A sampling of the most commonly seen types of ICMP control messages, including their type and code (subtype) numbers, are provided in the following table:

Type	Code	Description
0	0	This indicates echo reply (ping)
3	0	This indicates destination network unreachable
3	1	This indicates destination host unreachable
3	4	This indicates fragmentation required and do not fragment bit set
3	6	This indicates destination network unknown
3	7	This indicates destination host unknown
5	0	This indicates redirect datagram for the network
5	1	This indicates redirect datagram for the host
8	0	This indicates echo request (ping)
11	0	This indicates TTL expired in transit (seen in traceroutes)

The Wireshark packet details fields for the ICMP packet illustrated in the following screenshot depict a Time-to-live exceeded message as seen in a typical traceroute capture:

The following points are significant to analyze this packet:

• The source IP address seen in the IPv4 header summary is 10.192.128.1, which is the IP address of the router interface sending the ICMP message to the originator, 192.168.1.115
• The ICMP packet is Type 11, Code 0 (TTL exceeded in transit)

The second set of IPv4 and ICMP headers that follow the first IPv4 and ICMP headers are copies of the original packet transmitted by the sender. This copy is returned to allow determination of the packet that caused the ICMP message. The significant points in the packet details of this ICMP message copy include:

• The target destination IP address, where the echo request packet was intended to be sent (and would have been if the TTL value hadn't been altered) is 205.251.242.51.
• The TTL value was 1 when this packet reached the 10.192.128.1 router interface. This packet cannot be forwarded, resulting in the TTL exceeded message being sent back to the sender.
• The original ICMP packet was a Type 8, Code 0 echo request message.
• The Header Data section of the ICMP packet for the echo requests and replies will include a 16-bit identifier and 16-bit sequence number, which are used to match echo replies to their requests.

ICMP redirects

Another common use of ICMP is to redirect a client to use a different default gateway (router) to reach a host or network than the gateway it originally tried to use. In the ICMP Redirect packet depicted in the following screenshot, a number of packet fields should be noted:

• The source IP address of the ICMP redirect packet is 192.168.1.1, which was the client's default gateway; this is the router sending the redirect packet back to the client
• The ICMP Type is 5 (Redirect) and Code is 1 (Redirect for host)
• The gateway IP address that the router 192.168.1.1 is telling the client to use to reach the desired target host is 192.168.1.2
• The IP address of the target host was 10.1.1.125

The following screenshot shows the ICMP Redirect packets:

Wireshark ICMP filters

Capture filters(s): icmp

Display filter(s): icmp icmp.type==8 || icmp.type==0 (pings) icmp.type==5

&& icmp.code==1 (host redirects)

Internet Protocol Version 6

The Internet Protocol Version 6 (IPv6) is the latest version of Internet protocol, and although it is in its earliest stages of adoption, it is intended to eventually replace IPv4—mostly to alleviate the shortage of IP addresses that can be assigned to network devices. IPv4, with its 32-bit address space, provides approximately 4.3 billion addresses, nearly all of which have been assigned to companies and private interests worldwide.

IPv6 utilizes a 128-bit address space, which allows 2¹²⁸ or approximately 3.4 x 10³⁸ addresses; that number is 340,282,366,920,463,463,374,607,431,768,211,456 unique addresses.

IPv6 addressing

The 128 bits of an IPv6 address are represented in eight groups of 16 bits each, written as four hexadecimal digits separated by colons (:). An example of an IPv6 address is 2001:0db8:0000:0000:0000:ff00:0042:8329.

For convenience, an IPv6 address may be abbreviated to shorter notations by application of the following rules, wherever possible:

• One or more leading zeroes from any groups of hexadecimal digits are removed; this is usually done to either all or none of the leading zeroes. For example, the hexadecimal group 0042 can be converted to just 42.
• Consecutive sections of zeroes are replaced with a double colon (::). The double colon may only be used once in an address, as multiple use would render the address indeterminate. A double colon must not be used to denote a single section of omitted zeroes.

An example of applying these rules to IPv6 addresses is as follows:

• Initial address: 2001:0db8:0000:0000:0000:ff00:0042:8329
• After removing all leading zeroes: 2001:db8:0:0:0:ff00:42:8329
• After omitting consecutive sections of zeroes: 2001:db8::ff00:42:8329

The 128 bits of an IPv6 address are logically divided into a network prefix and a host identifier. The Class Inter-Domain Routing (CIDR) notation is used to represent IPv6 network prefixes, for example, 2001:DB8:0:CD30::/64 represents network 2001:DB8:0000:CD30::.

IPv6 address types

There are three basic types of IPv6 addresses:

• Unicast: These packets from one-to-one device use a single interface address. Unicast addresses can be of one of the following three types:
  • Global Unicast: This is routable to and over the Internet. Global Unicast addresses generally start with 2xxx (such as 2000::/3).
  • Link-local: This is automatically assigned to an interface and used on the local network link; this is not routable to the Internet, much like a MAC address. Link-local Unicast addresses start with FE80 (FE80::/10). They are automatically assigned to an interface when it is initialized using an algorithm that uses a rearranged version of the NIC's 48-bit MAC address in the IPv6 address and are used to communicate on the local link. These addresses are not routable. IPv6 uses link-local addresses for neighbor discovery functions.
  • Unique local: This is not routable to the Internet, but it is routable within an enterprise (similar to IPv4 private addresses). Unique local Unicast addresses start with FC00 (FC00::/7). This block of addresses is reserved for use in private IPv6 networks.
• Multicast: These are packets from one-to-many devices. Multicast addresses start with FFxx. An example of a multicast address is FF01:0:0:0:0:0:0:101, which can be shortened to FF01::101. There is no broadcast address in IPv6; multicasts are used as a replacement. Some well-known multicast addresses are shown in the following table:

  Address	Description	Scope
  ff01:0:0:0:0:0:0:1	All nodes address	Interface-local (spans only a single interface on a node useful only for loopback transmission of multicast packets)
  ff02:0:0:0:0:0:0:1	All nodes address	Link-local (all nodes on the local network segment)
  ff01:0:0:0:0:0:0:2	All routers address	Interface-local
  ff02:0:0:0:0:0:0:2	All routers address	Link-local
  ff05:0:0:0:0:0:0:2	All routers address	Site-local (spans a single site)
  ff02:0:0:0:0:0:1:2	DHCPv6 servers/agents	Link-local
  ff05:0:0:0:0:0:1:3	DHCPv6 servers/agents	Site-local

• Anycast: These packets are from one to the nearest of a group of interfaces. There is no special addresses scheme for Anycast addresses; they are similar to Unicast addresses. An Anycast address is created automatically when a Unicast address is assigned to more than one interface. Anycast addresses can be used to set up a group of devices so that any one of the group devices can respond to a request sent to a single IPv6 address.

Further discussion of IPv6 addressing would cover quite a number of additional features, which are beyond the scope of this book. The reader is encouraged to research IPv6 addressing further online and/or by reading Request For Comments (RFC) 4291 (IP Version 6 Addressing Architecture).

IPv6 header fields

An example of an IPv6 protocol header is illustrated in the following screenshot:

The IPv6 header fields are similar to many IPv4 headers and the fields include:

• Version: This is the IP version number, 6 for IPv6.
• Traffic class: This is similar to the IPv4 DiffServ field; it is used to identify different classes or priorities of IPv6 packets.
• Flow label: These are used to identify sequences of packets that are labeled as a set. An IPv6 flow is defined by the 20-bit Flow Label field and the source and destination IPv6 address fields.
• Payload length: This is the length of the IPv6 payload, not including any packet padding.
• Next header: This field indicates what's coming next in the packet. This is equivalent to the IPv4 Protocol field. In the preceding example, the next layer is a normal TCP (6) header.
• Hop limit: This field is roughly equivalent to the Time To Live field in IPv4; it is decremented by one by each device that forwards the IPv6 packet. When the value reaches one, the packet cannot be forwarded.
• Source and Destination addresses: These are the 128-bit IPv6 source and destination addresses.

IPv6 supports extension headers that provide additional information fields and that also extend the length of the IPv6 header. There is specific Next Header code that indicates the presence of this added functionality.

IPv6 transition methods

As part of the transition to IPv6, the current TCP/IP devices support dual stacks (IPv4 and IPv6 simultaneously) and the ability to encapsulate and tunnel IPv6 packets inside IPv4 packets so that they can be routed by IPv4 networks. The three of the most popular encapsulation methods are:

• 6to4 tunneling: In this tunneling method, an IPv6 header follows an IPv4 header; the Protocol field of the IPv4 header will contain 41 (IPv6), and the source IPv6 address in the IPv6 header will start with 2002.
• Teredo: In this tunneling method, an IPv6 header is encapsulated inside a UDP packet. This method was developed to accommodate NAT devices that do not handle protocol 41. Teredo tunneling can be identified in the UDP packet header by a destination port of 3544.
• ISATAP: This tunneling method uses a locally assigned IPv4 address to create a 64-bit interface identifier. For example, in ISATAP, the IPv4 address 24.6.173.220 becomes ::0:5EFE:1806:addc. ISATAP encapsulates IPv6 headers within IPv4 as in 6to4 tunneling.

Wireshark IPv6 filters

Capture filter(s): ip6 host fe80::1 ip proto 41 (capture IPv6-over-IPv4 tunneled traffic)

Display filter(s): ipv6 ipv6.addr == fe80::f61f:c2ff:fe58:7dcb ipv6.addr == ff02::1

Internet Control Message Protocol Version 6

Internet Control Message Protocol Version 6 (ICMPv6) is an integral part of IPv6, and the base protocol must be fully implemented by every IPv6 node. ICMPv6 provides services for an IPv6 environment that are provided by other distinct protocols in an IPv4 environment, such as Neighbor Solicitation to replace ARP.

The following table contains some of the common ICMPv6 packet types:

ICMPv6 packet type	ICMPv6 type	Purpose
Echo request	128	Ping request
Echo response	129	Ping response
Multicast listener query	130	Sent by multicast router to poll a network segment for group members
Multicast listener report	131	Sent by a host when it joins a multicast group, or in response to a multicast listener query sent by a router
Multicast listener done	132	Sent by a host when it leaves a multicast group and might be the last member of that group on the network segment
Router solicitation	133	Discover the local router(s)
Router advertisement	134	Respond to Router Solicitation messages, as well as sending this packet after initialization and periodically afterwards
Neighbor solicitation	135	Used first for Duplicate Address Detection (using a source address of ::) and then to obtain the MAC address of the local router; this function replaces ARP
Neighbor advertisement	136	Response to Neighbor Solicitation messages
Redirect message	137	Redirect a device to the proper router to send packets to a specific network or host

An example of a Neighbor Solicitation ICMPv6 packet is shown in the following screenshot:

The significant fields in this packet include:

• Next Header: This field contains 58, which indicates that the next protocol header is to be ICMPv6.
• IPv6 Source Address: The presence of an unspecified address (::) indicates this is a Duplicate Address Detection packet.
• IPv6 Destination Address: This is basically a multicast address.
• ICMPv6 Type: This is a Neighbor Solicitation message using Type 135.
• ICMPv6 Code: This is the subtype for Neighbor Solicitation messages; this will be 0.
• ICMPv6 Target Address: This is the address the host wants to use. If another node on the network is already using this address, they will respond accordingly.

Multicast Listener Discovery

Multicast Listener Discovery (MLD) is another component of the IPv6 suite used by IPv6 routers to discover multicast listeners on a directly attached link. MLD is part of the ICMPv6 protocol and it replaces IGMP on IPv4 networks.

Wireshark ICMPv6 filters

Capture filter(s): icmp6

Display filter(s): icmpv6 icmpv6.type==1135 && icmpv6.code==0 (Neighbor Solicitation)

Transport layer protocols

The transport layer protocols include TCP and UDP used to transport application protocols.

User Datagram Protocol

The User Datagram Protocol (UDP) is considered an unreliable transport. In this, there's no guarantee of packet delivery or ordering, but it has a lower overhead and is used by time-sensitive applications such as voice and video traffic.

The following screenshot shows the fields contained in an UDP header:

The UDP header is only 8-bytes long, consisting of:

• Source and Destination port number: This is 2 bytes each.
• Length: This is the length of the UDP header plus the payload. This is a 2-byte field.
• Checksum: This is a 2-byte field used to check for errors in the UDP header and data. If no checksum was generated by the transmitter, this will be all zeroes.

Wireshark UDP filters

Capture filter(s): udp udp port 2222

Display filter(s): udp udp.srcport == 161 (SNMP response) udp.length > 256

Transmission Control Protocol

The Transmission Control Protocol (TCP) provides a reliable delivery of data by detecting lost, duplicated, or out-of-order packets, requesting retransmission of lost data, or rearranging packets in the right order before delivering them to the application. TCP can also accept a large chunk of data from an application and handle getting the data transported to the other end reliably using multiple packets and reassembling them at the other end.

The following screenshot highlights the significant fields of a basic TCP header:

The TCP header contents and length can vary depending on options that may be in use, but in its simplest implementation it consists of:

• Source port and Destination port: These are well-known and registered ports are used (on servers) to access standard application services such as HTTP, FTP, SMTP, databases, and so on. Port numbers assigned to client/user sessions are usually in a higher number range and assigned sequentially.
• Sequence number: This is a number that represents the first octet in any given segment. Sequence numbers are initialized at the beginning of new sessions as a random number, and then incremented as data bytes are sent.
• Acknowledgment number: When the ACK flag bit is set, this field contains the next sequence number expected from the sender, which in turn acknowledges receipt of all the bytes received up to that point.

  Note

  The use of sequence and acknowledgment numbers is how TCP ensures reliable delivery of data by tracking the number and order of received bytes.

  Sequence and acknowledgment numbers are large and difficult for humans to follow. Wireshark can convert and display these as relative values that start with 0 at the beginning of a session to make it easier to inspect them and relate the values to the number of bytes transmitted and received.

• Flags: These bits are used to control connection setups, terminations, and flow control mechanisms.
• Window size: This field indicates the current size of the buffer on this host used to store received data until it can be handed off to the receiving application. This information enables the sending host to adjust data flow rates in case of network or host congestion.

TCP flags

The following table lists the flags that are most commonly used in a TCP header:

Flag field name	Description
URG (urgent)	This indicates the Urgent Pointer field (after the TCP header checksum) that should be examined. This flag is normally 0; the Urgent Pointer field is only examined if this bit is set.
ACK (acknowledgment)	This is the acknowledgment packet.
PSH (push)	This indicates whether the sending node's TCP stack should bypass any buffering and pass the data directly to the network and on to the receiving application.
RST (reset)	This is used to close the connection explicitly.
SYN (synchronize)	This is used to synchronize sequence numbers and used in a three-way TCP session initiation handshake process.
FIN (finish)	This is used when the transaction is finished. This does not mean that the connection is to be closed explicitly, but is commonly seen at the end of sessions.

TCP options

The TCP also supports a number of additional options, several of which are in common use in modern networks that you should be aware of. The snippet of a TCP header illustrated in the following screenshot depicts several of the most popular options:

The TCP options highlighted in the preceding screenshot include:

• Maximum Segment Size: This option allows you to specify of the number of bytes that can follow the TCP header. This option exists to allow adjustment to accommodate VLAN tagging or Multiprotocol Label Switching (MPLS).
• Window Scale: This option overcomes the inability of the Window Size field in a standard TCP header to specify a window size greater than 65,535 bytes. Window scaling allows you to specify a factor to multiply the advertised window size to achieve a larger window size. Both sides of a session must be able to support this option for it to apply; this is determined during the session setup.
• TCP SACK Permitted Option: This option indicates that this node supports selective acknowledgments, which allows a node to acknowledge ongoing and incoming data packets while still asking for a specific missing packet. The recovery process only requires retransmission of the missing packet(s), instead of the missing packet and all the packets that followed. Both sides of a session must be able to support this option for it to apply, as determined during session setup.

Wireshark TCP filters

Capture filter(s): tcp tcp port 80

Display filter(s): tcp tcp.port == 80 tcp.dstport == 8080 tcp.stream == 2

User Datagram Protocol

The User Datagram Protocol (UDP) is considered an unreliable transport. In this, there's no guarantee of packet delivery or ordering, but it has a lower overhead and is used by time-sensitive applications such as voice and video traffic.

The following screenshot shows the fields contained in an UDP header:

The UDP header is only 8-bytes long, consisting of:

• Source and Destination port number: This is 2 bytes each.
• Length: This is the length of the UDP header plus the payload. This is a 2-byte field.
• Checksum: This is a 2-byte field used to check for errors in the UDP header and data. If no checksum was generated by the transmitter, this will be all zeroes.

Wireshark UDP filters

Capture filter(s): udp udp port 2222

Display filter(s): udp udp.srcport == 161 (SNMP response) udp.length > 256

Transmission Control Protocol

The Transmission Control Protocol (TCP) provides a reliable delivery of data by detecting lost, duplicated, or out-of-order packets, requesting retransmission of lost data, or rearranging packets in the right order before delivering them to the application. TCP can also accept a large chunk of data from an application and handle getting the data transported to the other end reliably using multiple packets and reassembling them at the other end.

The following screenshot highlights the significant fields of a basic TCP header:

The TCP header contents and length can vary depending on options that may be in use, but in its simplest implementation it consists of:

• Source port and Destination port: These are well-known and registered ports are used (on servers) to access standard application services such as HTTP, FTP, SMTP, databases, and so on. Port numbers assigned to client/user sessions are usually in a higher number range and assigned sequentially.
• Sequence number: This is a number that represents the first octet in any given segment. Sequence numbers are initialized at the beginning of new sessions as a random number, and then incremented as data bytes are sent.
• Acknowledgment number: When the ACK flag bit is set, this field contains the next sequence number expected from the sender, which in turn acknowledges receipt of all the bytes received up to that point.

  Note

  The use of sequence and acknowledgment numbers is how TCP ensures reliable delivery of data by tracking the number and order of received bytes.

  Sequence and acknowledgment numbers are large and difficult for humans to follow. Wireshark can convert and display these as relative values that start with 0 at the beginning of a session to make it easier to inspect them and relate the values to the number of bytes transmitted and received.

• Flags: These bits are used to control connection setups, terminations, and flow control mechanisms.
• Window size: This field indicates the current size of the buffer on this host used to store received data until it can be handed off to the receiving application. This information enables the sending host to adjust data flow rates in case of network or host congestion.

TCP flags

The following table lists the flags that are most commonly used in a TCP header:

Flag field name	Description
URG (urgent)	This indicates the Urgent Pointer field (after the TCP header checksum) that should be examined. This flag is normally 0; the Urgent Pointer field is only examined if this bit is set.
ACK (acknowledgment)	This is the acknowledgment packet.
PSH (push)	This indicates whether the sending node's TCP stack should bypass any buffering and pass the data directly to the network and on to the receiving application.
RST (reset)	This is used to close the connection explicitly.
SYN (synchronize)	This is used to synchronize sequence numbers and used in a three-way TCP session initiation handshake process.
FIN (finish)	This is used when the transaction is finished. This does not mean that the connection is to be closed explicitly, but is commonly seen at the end of sessions.

TCP options

The TCP also supports a number of additional options, several of which are in common use in modern networks that you should be aware of. The snippet of a TCP header illustrated in the following screenshot depicts several of the most popular options:

The TCP options highlighted in the preceding screenshot include:

• Maximum Segment Size: This option allows you to specify of the number of bytes that can follow the TCP header. This option exists to allow adjustment to accommodate VLAN tagging or Multiprotocol Label Switching (MPLS).
• Window Scale: This option overcomes the inability of the Window Size field in a standard TCP header to specify a window size greater than 65,535 bytes. Window scaling allows you to specify a factor to multiply the advertised window size to achieve a larger window size. Both sides of a session must be able to support this option for it to apply; this is determined during the session setup.
• TCP SACK Permitted Option: This option indicates that this node supports selective acknowledgments, which allows a node to acknowledge ongoing and incoming data packets while still asking for a specific missing packet. The recovery process only requires retransmission of the missing packet(s), instead of the missing packet and all the packets that followed. Both sides of a session must be able to support this option for it to apply, as determined during session setup.

Wireshark TCP filters

Capture filter(s): tcp tcp port 80

Display filter(s): tcp tcp.port == 80 tcp.dstport == 8080 tcp.stream == 2

Wireshark UDP filters

Capture filter(s): udp udp port 2222

Display filter(s): udp udp.srcport == 161 (SNMP response) udp.length > 256

Transmission Control Protocol

The Transmission Control Protocol (TCP) provides a reliable delivery of data by detecting lost, duplicated, or out-of-order packets, requesting retransmission of lost data, or rearranging packets in the right order before delivering them to the application. TCP can also accept a large chunk of data from an application and handle getting the data transported to the other end reliably using multiple packets and reassembling them at the other end.

The following screenshot highlights the significant fields of a basic TCP header:

The TCP header contents and length can vary depending on options that may be in use, but in its simplest implementation it consists of:

• Source port and Destination port: These are well-known and registered ports are used (on servers) to access standard application services such as HTTP, FTP, SMTP, databases, and so on. Port numbers assigned to client/user sessions are usually in a higher number range and assigned sequentially.
• Sequence number: This is a number that represents the first octet in any given segment. Sequence numbers are initialized at the beginning of new sessions as a random number, and then incremented as data bytes are sent.
• Acknowledgment number: When the ACK flag bit is set, this field contains the next sequence number expected from the sender, which in turn acknowledges receipt of all the bytes received up to that point.

  Note

  The use of sequence and acknowledgment numbers is how TCP ensures reliable delivery of data by tracking the number and order of received bytes.

  Sequence and acknowledgment numbers are large and difficult for humans to follow. Wireshark can convert and display these as relative values that start with 0 at the beginning of a session to make it easier to inspect them and relate the values to the number of bytes transmitted and received.

• Flags: These bits are used to control connection setups, terminations, and flow control mechanisms.
• Window size: This field indicates the current size of the buffer on this host used to store received data until it can be handed off to the receiving application. This information enables the sending host to adjust data flow rates in case of network or host congestion.

TCP flags

The following table lists the flags that are most commonly used in a TCP header:

Flag field name	Description
URG (urgent)	This indicates the Urgent Pointer field (after the TCP header checksum) that should be examined. This flag is normally 0; the Urgent Pointer field is only examined if this bit is set.
ACK (acknowledgment)	This is the acknowledgment packet.
PSH (push)	This indicates whether the sending node's TCP stack should bypass any buffering and pass the data directly to the network and on to the receiving application.
RST (reset)	This is used to close the connection explicitly.
SYN (synchronize)	This is used to synchronize sequence numbers and used in a three-way TCP session initiation handshake process.
FIN (finish)	This is used when the transaction is finished. This does not mean that the connection is to be closed explicitly, but is commonly seen at the end of sessions.

TCP options

The TCP also supports a number of additional options, several of which are in common use in modern networks that you should be aware of. The snippet of a TCP header illustrated in the following screenshot depicts several of the most popular options:

The TCP options highlighted in the preceding screenshot include:

• Maximum Segment Size: This option allows you to specify of the number of bytes that can follow the TCP header. This option exists to allow adjustment to accommodate VLAN tagging or Multiprotocol Label Switching (MPLS).
• Window Scale: This option overcomes the inability of the Window Size field in a standard TCP header to specify a window size greater than 65,535 bytes. Window scaling allows you to specify a factor to multiply the advertised window size to achieve a larger window size. Both sides of a session must be able to support this option for it to apply; this is determined during the session setup.
• TCP SACK Permitted Option: This option indicates that this node supports selective acknowledgments, which allows a node to acknowledge ongoing and incoming data packets while still asking for a specific missing packet. The recovery process only requires retransmission of the missing packet(s), instead of the missing packet and all the packets that followed. Both sides of a session must be able to support this option for it to apply, as determined during session setup.

Wireshark TCP filters

Capture filter(s): tcp tcp port 80

Display filter(s): tcp tcp.port == 80 tcp.dstport == 8080 tcp.stream == 2

Transmission Control Protocol

The Transmission Control Protocol (TCP) provides a reliable delivery of data by detecting lost, duplicated, or out-of-order packets, requesting retransmission of lost data, or rearranging packets in the right order before delivering them to the application. TCP can also accept a large chunk of data from an application and handle getting the data transported to the other end reliably using multiple packets and reassembling them at the other end.

The following screenshot highlights the significant fields of a basic TCP header:

The TCP header contents and length can vary depending on options that may be in use, but in its simplest implementation it consists of:

• Source port and Destination port: These are well-known and registered ports are used (on servers) to access standard application services such as HTTP, FTP, SMTP, databases, and so on. Port numbers assigned to client/user sessions are usually in a higher number range and assigned sequentially.
• Sequence number: This is a number that represents the first octet in any given segment. Sequence numbers are initialized at the beginning of new sessions as a random number, and then incremented as data bytes are sent.
• Acknowledgment number: When the ACK flag bit is set, this field contains the next sequence number expected from the sender, which in turn acknowledges receipt of all the bytes received up to that point.

  Note

  The use of sequence and acknowledgment numbers is how TCP ensures reliable delivery of data by tracking the number and order of received bytes.

  Sequence and acknowledgment numbers are large and difficult for humans to follow. Wireshark can convert and display these as relative values that start with 0 at the beginning of a session to make it easier to inspect them and relate the values to the number of bytes transmitted and received.

• Flags: These bits are used to control connection setups, terminations, and flow control mechanisms.
• Window size: This field indicates the current size of the buffer on this host used to store received data until it can be handed off to the receiving application. This information enables the sending host to adjust data flow rates in case of network or host congestion.

TCP flags

The following table lists the flags that are most commonly used in a TCP header:

Flag field name	Description
URG (urgent)	This indicates the Urgent Pointer field (after the TCP header checksum) that should be examined. This flag is normally 0; the Urgent Pointer field is only examined if this bit is set.
ACK (acknowledgment)	This is the acknowledgment packet.
PSH (push)	This indicates whether the sending node's TCP stack should bypass any buffering and pass the data directly to the network and on to the receiving application.
RST (reset)	This is used to close the connection explicitly.
SYN (synchronize)	This is used to synchronize sequence numbers and used in a three-way TCP session initiation handshake process.
FIN (finish)	This is used when the transaction is finished. This does not mean that the connection is to be closed explicitly, but is commonly seen at the end of sessions.

TCP options

The TCP also supports a number of additional options, several of which are in common use in modern networks that you should be aware of. The snippet of a TCP header illustrated in the following screenshot depicts several of the most popular options:

The TCP options highlighted in the preceding screenshot include:

• Maximum Segment Size: This option allows you to specify of the number of bytes that can follow the TCP header. This option exists to allow adjustment to accommodate VLAN tagging or Multiprotocol Label Switching (MPLS).
• Window Scale: This option overcomes the inability of the Window Size field in a standard TCP header to specify a window size greater than 65,535 bytes. Window scaling allows you to specify a factor to multiply the advertised window size to achieve a larger window size. Both sides of a session must be able to support this option for it to apply; this is determined during the session setup.
• TCP SACK Permitted Option: This option indicates that this node supports selective acknowledgments, which allows a node to acknowledge ongoing and incoming data packets while still asking for a specific missing packet. The recovery process only requires retransmission of the missing packet(s), instead of the missing packet and all the packets that followed. Both sides of a session must be able to support this option for it to apply, as determined during session setup.

Wireshark TCP filters

Capture filter(s): tcp tcp port 80

Display filter(s): tcp tcp.port == 80 tcp.dstport == 8080 tcp.stream == 2

TCP flags

The following table lists the flags that are most commonly used in a TCP header:

Flag field name	Description
URG (urgent)	This indicates the Urgent Pointer field (after the TCP header checksum) that should be examined. This flag is normally 0; the Urgent Pointer field is only examined if this bit is set.
ACK (acknowledgment)	This is the acknowledgment packet.
PSH (push)	This indicates whether the sending node's TCP stack should bypass any buffering and pass the data directly to the network and on to the receiving application.
RST (reset)	This is used to close the connection explicitly.
SYN (synchronize)	This is used to synchronize sequence numbers and used in a three-way TCP session initiation handshake process.
FIN (finish)	This is used when the transaction is finished. This does not mean that the connection is to be closed explicitly, but is commonly seen at the end of sessions.

TCP options

The TCP also supports a number of additional options, several of which are in common use in modern networks that you should be aware of. The snippet of a TCP header illustrated in the following screenshot depicts several of the most popular options:

The TCP options highlighted in the preceding screenshot include:

• Maximum Segment Size: This option allows you to specify of the number of bytes that can follow the TCP header. This option exists to allow adjustment to accommodate VLAN tagging or Multiprotocol Label Switching (MPLS).
• Window Scale: This option overcomes the inability of the Window Size field in a standard TCP header to specify a window size greater than 65,535 bytes. Window scaling allows you to specify a factor to multiply the advertised window size to achieve a larger window size. Both sides of a session must be able to support this option for it to apply; this is determined during the session setup.
• TCP SACK Permitted Option: This option indicates that this node supports selective acknowledgments, which allows a node to acknowledge ongoing and incoming data packets while still asking for a specific missing packet. The recovery process only requires retransmission of the missing packet(s), instead of the missing packet and all the packets that followed. Both sides of a session must be able to support this option for it to apply, as determined during session setup.

Wireshark TCP filters

Capture filter(s): tcp tcp port 80

Display filter(s): tcp tcp.port == 80 tcp.dstport == 8080 tcp.stream == 2

TCP options

The TCP also supports a number of additional options, several of which are in common use in modern networks that you should be aware of. The snippet of a TCP header illustrated in the following screenshot depicts several of the most popular options:

The TCP options highlighted in the preceding screenshot include:

• Maximum Segment Size: This option allows you to specify of the number of bytes that can follow the TCP header. This option exists to allow adjustment to accommodate VLAN tagging or Multiprotocol Label Switching (MPLS).
• Window Scale: This option overcomes the inability of the Window Size field in a standard TCP header to specify a window size greater than 65,535 bytes. Window scaling allows you to specify a factor to multiply the advertised window size to achieve a larger window size. Both sides of a session must be able to support this option for it to apply; this is determined during the session setup.
• TCP SACK Permitted Option: This option indicates that this node supports selective acknowledgments, which allows a node to acknowledge ongoing and incoming data packets while still asking for a specific missing packet. The recovery process only requires retransmission of the missing packet(s), instead of the missing packet and all the packets that followed. Both sides of a session must be able to support this option for it to apply, as determined during session setup.

Wireshark TCP filters

Capture filter(s): tcp tcp port 80

Display filter(s): tcp tcp.port == 80 tcp.dstport == 8080 tcp.stream == 2

Wireshark TCP filters

Capture filter(s): tcp tcp port 80

Display filter(s): tcp tcp.port == 80 tcp.dstport == 8080 tcp.stream == 2

Application layer protocols

The most common application layer protocols include DHCP used to obtain client IP addresses and configuration information, DNS for hostname resolution, HTTP, SMB, POP/SMTP, and FTP for the most common network services and SIP, RTP, and RTCP for VoIP and video conferencing.

Extensive coverage of all the upper layer protocols is beyond the scope of this book. A brief overview of DHCP and DNS will be provided, as these protocols universally support network operations and HTTP as an example of one of the most common application layer protocols. The reader is encouraged to research any or all of these protocols further depending on their scope of interest and need to meet the analysis tasks being addressed.

Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol (DHCP) allows a client to lease an IP address from a pool managed by a DHCP server. The client can receive other configuration options such as the default gateway, subnet mask, and one or more DNS server addresses as well. DHCP is derived from an older BOOTP protocol; Wireshark uses bootp in display filter syntax. DHCP works by the client sending a broadcast packet using UDP source port 67 to UDP destination port 68. A DHCP server will respond to the requestor's IP address and using UDP source port 68 to UDP destination port 67.

DHCP servers don't necessarily have to reside on the same local network segment as clients. A relay agent such as a router can forward DHCP requests and respond to/from a different network where a DHCP server resides.

Wireshark DHCP filters

Capture filter(s): port 67 (DHCP is between ports 67 and 68; filtering on port 67 is sufficient to get both sides of the conversations)

Display filter(s): bootp bootp.option.value == 0 (DHCP Discover message)

Dynamic Host Configuration Protocol Version 6

Dynamic Host Configuration Protocol Version 6 (DHCPv6) is the IPv6 version of DHCP. Since IPv6 doesn't use broadcasts, DHCPv6 clients use the multicast address for All_DHCP_Relay_Agents_and_Servers (ff02::1:2) to locate DHCPv6 servers or relay agents.

Wireshark DHCPv6 filters

Capture filter(s): port 546 (DHCPv6 is between ports 546 and 547; either will work)

Display filter(s): dhcpv6 dhcpv6.msgtype == 1(DHCPv6 Solicit message)

Domain Name Service

Domain Name Service (DNS) is used to convert host names, such as www.wireshark.org to IP addresses. DNS can also be used to identify the hostname associated with an IP address (an inverse or pointer (PTR) query) and several other network information services. This is a good protocol to become familiar with as it is used extensively to locate nodes both within an enterprise and on the Internet using hostnames.

Wireshark DNS filters

Capture filter(s): port 53

Display filter(s): dns dns.flags.response == 0(DNS query) dns.flags.response == 1(DNS response) dns.flags.rcode != 0(DNS response contains an error)

Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is the application protocol used when someone browses (unsecured) websites on the Internet, along with the secure version (HTTPS). HTTP/1.1 is the current version—although HTTP/2.0 is starting to appear in some environments. Be aware that some network devices such as proxy servers and gateways may not support HTTP/2.0 yet.

An example of a HTTP packet delivering a GET request to a web server is depicted in the following screenshot:

The most common features and fields of the HTTP protocol include HTTP Methods, Host, and Request Modifiers.

In the preceding screenshot, the HTTP header includes:

• Request Method: GET
• Request URI: /Orion (a home page on the web server)
• Request Version: HTTP/1.1

HTTP Methods

Some of the more common HTTP Methods are listed and described in the following table:

Method	Description
GET	This retrieves information defined by the Uniform Resource Identifier (URI) field
HEAD	This retrieves meta data related to the desired URI
POST	This sends data to the HTTP server/application
OPTIONS	This determines the options associated with a resource
PUT	This sends data to the HTTP server/application
DELETE	This deletes the resource defined by the URI
CONNECT	This is used to connect to a proxy device

Host

The Host field identifies the target host and port number of the resource being requested. In the preceding screenshot, Host is pktiqsvr1 on port 8080.

Request Modifiers

HTTP requests and responses use Request Modifiers to provide details for the request. In the preceding screenshot, Request Modifiers includes:

• Connection: This indicates the preference for a persistent connection (keep-alive).
• Accept: This is a list of data formats (text/html and application/xhtml plus xml) accepted.
• User-agent: This is a list of browser and operating system parameters (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit) for the requesting device.
• Accept-encoding: This is a list of the acceptable HTTP compression schemes (gzip, deflate, and sdch).
• Accept-language: The acceptable languages (en-US and en; q=0.8) where q=0.8 is a relative quality factor that specifies the language the user would prefer on a scale of 0 to 1.
• Cookie: This is a session ID cookie (ASP.NET_SessionId=sidsruxjbm4eaed4d3dgg4zd) that was previously stored on the user's browser in a cookie and is being provided to the website.

The following table lists some of the more commonly used modifiers:

Request Modifier	Description
Accept	Acceptable content types
Accept-charset	Acceptable character sets
Accept-encoding	Acceptable encodings
Accept-language	Acceptable languages
Accept-ranges	Server can accept range requests
Authorization	Authentication credentials for HTTP authentication
Cache-control	Caching directives
Connection	Type of connection preferred by the user agent
Cookie	HTTP cookie (a small piece of data sent from the website and stored in a user's browser, and/or sent back to the website the next time the user visits containing session information)
Content-length	Length of the request body in bytes
Content-type	Mime type of the body (used with POST and PUT requests)
Date	Date and time the message was sent
Expect	Defines server behavior expected by the client
If-match	Perform action if client-provided information matches
If-modified-since	Provide date/time of cached data; return 304 Not Modified if the cached data is still current
If-range	Request for range of missing information
IF-unmodified-since	Only send if unmodified since the provided date/time
Max-forwards	Limit the number of forwards through proxies or gateways
Proxy-authorization	Authorization credential for a proxy connection
Range	Request only part of an entity
TE	Transfer encodings accepted
User-agent	A string containing browser and operating system information
Via	The proxies traversed

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol (DHCP) allows a client to lease an IP address from a pool managed by a DHCP server. The client can receive other configuration options such as the default gateway, subnet mask, and one or more DNS server addresses as well. DHCP is derived from an older BOOTP protocol; Wireshark uses bootp in display filter syntax. DHCP works by the client sending a broadcast packet using UDP source port 67 to UDP destination port 68. A DHCP server will respond to the requestor's IP address and using UDP source port 68 to UDP destination port 67.

DHCP servers don't necessarily have to reside on the same local network segment as clients. A relay agent such as a router can forward DHCP requests and respond to/from a different network where a DHCP server resides.

Wireshark DHCP filters

Capture filter(s): port 67 (DHCP is between ports 67 and 68; filtering on port 67 is sufficient to get both sides of the conversations)

Display filter(s): bootp bootp.option.value == 0 (DHCP Discover message)

Dynamic Host Configuration Protocol Version 6

Dynamic Host Configuration Protocol Version 6 (DHCPv6) is the IPv6 version of DHCP. Since IPv6 doesn't use broadcasts, DHCPv6 clients use the multicast address for All_DHCP_Relay_Agents_and_Servers (ff02::1:2) to locate DHCPv6 servers or relay agents.

Wireshark DHCPv6 filters

Capture filter(s): port 546 (DHCPv6 is between ports 546 and 547; either will work)

Display filter(s): dhcpv6 dhcpv6.msgtype == 1(DHCPv6 Solicit message)

Domain Name Service

Domain Name Service (DNS) is used to convert host names, such as www.wireshark.org to IP addresses. DNS can also be used to identify the hostname associated with an IP address (an inverse or pointer (PTR) query) and several other network information services. This is a good protocol to become familiar with as it is used extensively to locate nodes both within an enterprise and on the Internet using hostnames.

Wireshark DNS filters

Capture filter(s): port 53

Display filter(s): dns dns.flags.response == 0(DNS query) dns.flags.response == 1(DNS response) dns.flags.rcode != 0(DNS response contains an error)

Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is the application protocol used when someone browses (unsecured) websites on the Internet, along with the secure version (HTTPS). HTTP/1.1 is the current version—although HTTP/2.0 is starting to appear in some environments. Be aware that some network devices such as proxy servers and gateways may not support HTTP/2.0 yet.

An example of a HTTP packet delivering a GET request to a web server is depicted in the following screenshot:

The most common features and fields of the HTTP protocol include HTTP Methods, Host, and Request Modifiers.

In the preceding screenshot, the HTTP header includes:

• Request Method: GET
• Request URI: /Orion (a home page on the web server)
• Request Version: HTTP/1.1

HTTP Methods

Some of the more common HTTP Methods are listed and described in the following table:

Method	Description
GET	This retrieves information defined by the Uniform Resource Identifier (URI) field
HEAD	This retrieves meta data related to the desired URI
POST	This sends data to the HTTP server/application
OPTIONS	This determines the options associated with a resource
PUT	This sends data to the HTTP server/application
DELETE	This deletes the resource defined by the URI
CONNECT	This is used to connect to a proxy device

Host

The Host field identifies the target host and port number of the resource being requested. In the preceding screenshot, Host is pktiqsvr1 on port 8080.

Request Modifiers

HTTP requests and responses use Request Modifiers to provide details for the request. In the preceding screenshot, Request Modifiers includes:

• Connection: This indicates the preference for a persistent connection (keep-alive).
• Accept: This is a list of data formats (text/html and application/xhtml plus xml) accepted.
• User-agent: This is a list of browser and operating system parameters (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit) for the requesting device.
• Accept-encoding: This is a list of the acceptable HTTP compression schemes (gzip, deflate, and sdch).
• Accept-language: The acceptable languages (en-US and en; q=0.8) where q=0.8 is a relative quality factor that specifies the language the user would prefer on a scale of 0 to 1.
• Cookie: This is a session ID cookie (ASP.NET_SessionId=sidsruxjbm4eaed4d3dgg4zd) that was previously stored on the user's browser in a cookie and is being provided to the website.

The following table lists some of the more commonly used modifiers:

Request Modifier	Description
Accept	Acceptable content types
Accept-charset	Acceptable character sets
Accept-encoding	Acceptable encodings
Accept-language	Acceptable languages
Accept-ranges	Server can accept range requests
Authorization	Authentication credentials for HTTP authentication
Cache-control	Caching directives
Connection	Type of connection preferred by the user agent
Cookie	HTTP cookie (a small piece of data sent from the website and stored in a user's browser, and/or sent back to the website the next time the user visits containing session information)
Content-length	Length of the request body in bytes
Content-type	Mime type of the body (used with POST and PUT requests)
Date	Date and time the message was sent
Expect	Defines server behavior expected by the client
If-match	Perform action if client-provided information matches
If-modified-since	Provide date/time of cached data; return 304 Not Modified if the cached data is still current
If-range	Request for range of missing information
IF-unmodified-since	Only send if unmodified since the provided date/time
Max-forwards	Limit the number of forwards through proxies or gateways
Proxy-authorization	Authorization credential for a proxy connection
Range	Request only part of an entity
TE	Transfer encodings accepted
User-agent	A string containing browser and operating system information
Via	The proxies traversed

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Wireshark DHCP filters

Capture filter(s): port 67 (DHCP is between ports 67 and 68; filtering on port 67 is sufficient to get both sides of the conversations)

Display filter(s): bootp bootp.option.value == 0 (DHCP Discover message)

Dynamic Host Configuration Protocol Version 6

Dynamic Host Configuration Protocol Version 6 (DHCPv6) is the IPv6 version of DHCP. Since IPv6 doesn't use broadcasts, DHCPv6 clients use the multicast address for All_DHCP_Relay_Agents_and_Servers (ff02::1:2) to locate DHCPv6 servers or relay agents.

Wireshark DHCPv6 filters

Capture filter(s): port 546 (DHCPv6 is between ports 546 and 547; either will work)

Display filter(s): dhcpv6 dhcpv6.msgtype == 1(DHCPv6 Solicit message)

Domain Name Service

Domain Name Service (DNS) is used to convert host names, such as www.wireshark.org to IP addresses. DNS can also be used to identify the hostname associated with an IP address (an inverse or pointer (PTR) query) and several other network information services. This is a good protocol to become familiar with as it is used extensively to locate nodes both within an enterprise and on the Internet using hostnames.

Wireshark DNS filters

Capture filter(s): port 53

Display filter(s): dns dns.flags.response == 0(DNS query) dns.flags.response == 1(DNS response) dns.flags.rcode != 0(DNS response contains an error)

Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is the application protocol used when someone browses (unsecured) websites on the Internet, along with the secure version (HTTPS). HTTP/1.1 is the current version—although HTTP/2.0 is starting to appear in some environments. Be aware that some network devices such as proxy servers and gateways may not support HTTP/2.0 yet.

An example of a HTTP packet delivering a GET request to a web server is depicted in the following screenshot:

The most common features and fields of the HTTP protocol include HTTP Methods, Host, and Request Modifiers.

In the preceding screenshot, the HTTP header includes:

• Request Method: GET
• Request URI: /Orion (a home page on the web server)
• Request Version: HTTP/1.1

HTTP Methods

Some of the more common HTTP Methods are listed and described in the following table:

Method	Description
GET	This retrieves information defined by the Uniform Resource Identifier (URI) field
HEAD	This retrieves meta data related to the desired URI
POST	This sends data to the HTTP server/application
OPTIONS	This determines the options associated with a resource
PUT	This sends data to the HTTP server/application
DELETE	This deletes the resource defined by the URI
CONNECT	This is used to connect to a proxy device

Host

The Host field identifies the target host and port number of the resource being requested. In the preceding screenshot, Host is pktiqsvr1 on port 8080.

Request Modifiers

HTTP requests and responses use Request Modifiers to provide details for the request. In the preceding screenshot, Request Modifiers includes:

• Connection: This indicates the preference for a persistent connection (keep-alive).
• Accept: This is a list of data formats (text/html and application/xhtml plus xml) accepted.
• User-agent: This is a list of browser and operating system parameters (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit) for the requesting device.
• Accept-encoding: This is a list of the acceptable HTTP compression schemes (gzip, deflate, and sdch).
• Accept-language: The acceptable languages (en-US and en; q=0.8) where q=0.8 is a relative quality factor that specifies the language the user would prefer on a scale of 0 to 1.
• Cookie: This is a session ID cookie (ASP.NET_SessionId=sidsruxjbm4eaed4d3dgg4zd) that was previously stored on the user's browser in a cookie and is being provided to the website.

The following table lists some of the more commonly used modifiers:

Request Modifier	Description
Accept	Acceptable content types
Accept-charset	Acceptable character sets
Accept-encoding	Acceptable encodings
Accept-language	Acceptable languages
Accept-ranges	Server can accept range requests
Authorization	Authentication credentials for HTTP authentication
Cache-control	Caching directives
Connection	Type of connection preferred by the user agent
Cookie	HTTP cookie (a small piece of data sent from the website and stored in a user's browser, and/or sent back to the website the next time the user visits containing session information)
Content-length	Length of the request body in bytes
Content-type	Mime type of the body (used with POST and PUT requests)
Date	Date and time the message was sent
Expect	Defines server behavior expected by the client
If-match	Perform action if client-provided information matches
If-modified-since	Provide date/time of cached data; return 304 Not Modified if the cached data is still current
If-range	Request for range of missing information
IF-unmodified-since	Only send if unmodified since the provided date/time
Max-forwards	Limit the number of forwards through proxies or gateways
Proxy-authorization	Authorization credential for a proxy connection
Range	Request only part of an entity
TE	Transfer encodings accepted
User-agent	A string containing browser and operating system information
Via	The proxies traversed

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Dynamic Host Configuration Protocol Version 6

Dynamic Host Configuration Protocol Version 6 (DHCPv6) is the IPv6 version of DHCP. Since IPv6 doesn't use broadcasts, DHCPv6 clients use the multicast address for All_DHCP_Relay_Agents_and_Servers (ff02::1:2) to locate DHCPv6 servers or relay agents.

Wireshark DHCPv6 filters

Capture filter(s): port 546 (DHCPv6 is between ports 546 and 547; either will work)

Display filter(s): dhcpv6 dhcpv6.msgtype == 1(DHCPv6 Solicit message)

Domain Name Service

Domain Name Service (DNS) is used to convert host names, such as www.wireshark.org to IP addresses. DNS can also be used to identify the hostname associated with an IP address (an inverse or pointer (PTR) query) and several other network information services. This is a good protocol to become familiar with as it is used extensively to locate nodes both within an enterprise and on the Internet using hostnames.

Wireshark DNS filters

Capture filter(s): port 53

Display filter(s): dns dns.flags.response == 0(DNS query) dns.flags.response == 1(DNS response) dns.flags.rcode != 0(DNS response contains an error)

Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is the application protocol used when someone browses (unsecured) websites on the Internet, along with the secure version (HTTPS). HTTP/1.1 is the current version—although HTTP/2.0 is starting to appear in some environments. Be aware that some network devices such as proxy servers and gateways may not support HTTP/2.0 yet.

An example of a HTTP packet delivering a GET request to a web server is depicted in the following screenshot:

The most common features and fields of the HTTP protocol include HTTP Methods, Host, and Request Modifiers.

In the preceding screenshot, the HTTP header includes:

• Request Method: GET
• Request URI: /Orion (a home page on the web server)
• Request Version: HTTP/1.1

HTTP Methods

Some of the more common HTTP Methods are listed and described in the following table:

Method	Description
GET	This retrieves information defined by the Uniform Resource Identifier (URI) field
HEAD	This retrieves meta data related to the desired URI
POST	This sends data to the HTTP server/application
OPTIONS	This determines the options associated with a resource
PUT	This sends data to the HTTP server/application
DELETE	This deletes the resource defined by the URI
CONNECT	This is used to connect to a proxy device

Host

The Host field identifies the target host and port number of the resource being requested. In the preceding screenshot, Host is pktiqsvr1 on port 8080.

Request Modifiers

HTTP requests and responses use Request Modifiers to provide details for the request. In the preceding screenshot, Request Modifiers includes:

• Connection: This indicates the preference for a persistent connection (keep-alive).
• Accept: This is a list of data formats (text/html and application/xhtml plus xml) accepted.
• User-agent: This is a list of browser and operating system parameters (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit) for the requesting device.
• Accept-encoding: This is a list of the acceptable HTTP compression schemes (gzip, deflate, and sdch).
• Accept-language: The acceptable languages (en-US and en; q=0.8) where q=0.8 is a relative quality factor that specifies the language the user would prefer on a scale of 0 to 1.
• Cookie: This is a session ID cookie (ASP.NET_SessionId=sidsruxjbm4eaed4d3dgg4zd) that was previously stored on the user's browser in a cookie and is being provided to the website.

The following table lists some of the more commonly used modifiers:

Request Modifier	Description
Accept	Acceptable content types
Accept-charset	Acceptable character sets
Accept-encoding	Acceptable encodings
Accept-language	Acceptable languages
Accept-ranges	Server can accept range requests
Authorization	Authentication credentials for HTTP authentication
Cache-control	Caching directives
Connection	Type of connection preferred by the user agent
Cookie	HTTP cookie (a small piece of data sent from the website and stored in a user's browser, and/or sent back to the website the next time the user visits containing session information)
Content-length	Length of the request body in bytes
Content-type	Mime type of the body (used with POST and PUT requests)
Date	Date and time the message was sent
Expect	Defines server behavior expected by the client
If-match	Perform action if client-provided information matches
If-modified-since	Provide date/time of cached data; return 304 Not Modified if the cached data is still current
If-range	Request for range of missing information
IF-unmodified-since	Only send if unmodified since the provided date/time
Max-forwards	Limit the number of forwards through proxies or gateways
Proxy-authorization	Authorization credential for a proxy connection
Range	Request only part of an entity
TE	Transfer encodings accepted
User-agent	A string containing browser and operating system information
Via	The proxies traversed

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Wireshark DHCPv6 filters

Capture filter(s): port 546 (DHCPv6 is between ports 546 and 547; either will work)

Display filter(s): dhcpv6 dhcpv6.msgtype == 1(DHCPv6 Solicit message)

Domain Name Service

Domain Name Service (DNS) is used to convert host names, such as www.wireshark.org to IP addresses. DNS can also be used to identify the hostname associated with an IP address (an inverse or pointer (PTR) query) and several other network information services. This is a good protocol to become familiar with as it is used extensively to locate nodes both within an enterprise and on the Internet using hostnames.

Wireshark DNS filters

Capture filter(s): port 53

Display filter(s): dns dns.flags.response == 0(DNS query) dns.flags.response == 1(DNS response) dns.flags.rcode != 0(DNS response contains an error)

Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is the application protocol used when someone browses (unsecured) websites on the Internet, along with the secure version (HTTPS). HTTP/1.1 is the current version—although HTTP/2.0 is starting to appear in some environments. Be aware that some network devices such as proxy servers and gateways may not support HTTP/2.0 yet.

An example of a HTTP packet delivering a GET request to a web server is depicted in the following screenshot:

The most common features and fields of the HTTP protocol include HTTP Methods, Host, and Request Modifiers.

In the preceding screenshot, the HTTP header includes:

• Request Method: GET
• Request URI: /Orion (a home page on the web server)
• Request Version: HTTP/1.1

HTTP Methods

Some of the more common HTTP Methods are listed and described in the following table:

Method	Description
GET	This retrieves information defined by the Uniform Resource Identifier (URI) field
HEAD	This retrieves meta data related to the desired URI
POST	This sends data to the HTTP server/application
OPTIONS	This determines the options associated with a resource
PUT	This sends data to the HTTP server/application
DELETE	This deletes the resource defined by the URI
CONNECT	This is used to connect to a proxy device

Host

The Host field identifies the target host and port number of the resource being requested. In the preceding screenshot, Host is pktiqsvr1 on port 8080.

Request Modifiers

HTTP requests and responses use Request Modifiers to provide details for the request. In the preceding screenshot, Request Modifiers includes:

• Connection: This indicates the preference for a persistent connection (keep-alive).
• Accept: This is a list of data formats (text/html and application/xhtml plus xml) accepted.
• User-agent: This is a list of browser and operating system parameters (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit) for the requesting device.
• Accept-encoding: This is a list of the acceptable HTTP compression schemes (gzip, deflate, and sdch).
• Accept-language: The acceptable languages (en-US and en; q=0.8) where q=0.8 is a relative quality factor that specifies the language the user would prefer on a scale of 0 to 1.
• Cookie: This is a session ID cookie (ASP.NET_SessionId=sidsruxjbm4eaed4d3dgg4zd) that was previously stored on the user's browser in a cookie and is being provided to the website.

The following table lists some of the more commonly used modifiers:

Request Modifier	Description
Accept	Acceptable content types
Accept-charset	Acceptable character sets
Accept-encoding	Acceptable encodings
Accept-language	Acceptable languages
Accept-ranges	Server can accept range requests
Authorization	Authentication credentials for HTTP authentication
Cache-control	Caching directives
Connection	Type of connection preferred by the user agent
Cookie	HTTP cookie (a small piece of data sent from the website and stored in a user's browser, and/or sent back to the website the next time the user visits containing session information)
Content-length	Length of the request body in bytes
Content-type	Mime type of the body (used with POST and PUT requests)
Date	Date and time the message was sent
Expect	Defines server behavior expected by the client
If-match	Perform action if client-provided information matches
If-modified-since	Provide date/time of cached data; return 304 Not Modified if the cached data is still current
If-range	Request for range of missing information
IF-unmodified-since	Only send if unmodified since the provided date/time
Max-forwards	Limit the number of forwards through proxies or gateways
Proxy-authorization	Authorization credential for a proxy connection
Range	Request only part of an entity
TE	Transfer encodings accepted
User-agent	A string containing browser and operating system information
Via	The proxies traversed

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Domain Name Service

Domain Name Service (DNS) is used to convert host names, such as www.wireshark.org to IP addresses. DNS can also be used to identify the hostname associated with an IP address (an inverse or pointer (PTR) query) and several other network information services. This is a good protocol to become familiar with as it is used extensively to locate nodes both within an enterprise and on the Internet using hostnames.

Wireshark DNS filters

Capture filter(s): port 53

Display filter(s): dns dns.flags.response == 0(DNS query) dns.flags.response == 1(DNS response) dns.flags.rcode != 0(DNS response contains an error)

Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is the application protocol used when someone browses (unsecured) websites on the Internet, along with the secure version (HTTPS). HTTP/1.1 is the current version—although HTTP/2.0 is starting to appear in some environments. Be aware that some network devices such as proxy servers and gateways may not support HTTP/2.0 yet.

An example of a HTTP packet delivering a GET request to a web server is depicted in the following screenshot:

The most common features and fields of the HTTP protocol include HTTP Methods, Host, and Request Modifiers.

In the preceding screenshot, the HTTP header includes:

• Request Method: GET
• Request URI: /Orion (a home page on the web server)
• Request Version: HTTP/1.1

HTTP Methods

Some of the more common HTTP Methods are listed and described in the following table:

Method	Description
GET	This retrieves information defined by the Uniform Resource Identifier (URI) field
HEAD	This retrieves meta data related to the desired URI
POST	This sends data to the HTTP server/application
OPTIONS	This determines the options associated with a resource
PUT	This sends data to the HTTP server/application
DELETE	This deletes the resource defined by the URI
CONNECT	This is used to connect to a proxy device

Host

The Host field identifies the target host and port number of the resource being requested. In the preceding screenshot, Host is pktiqsvr1 on port 8080.

Request Modifiers

HTTP requests and responses use Request Modifiers to provide details for the request. In the preceding screenshot, Request Modifiers includes:

• Connection: This indicates the preference for a persistent connection (keep-alive).
• Accept: This is a list of data formats (text/html and application/xhtml plus xml) accepted.
• User-agent: This is a list of browser and operating system parameters (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit) for the requesting device.
• Accept-encoding: This is a list of the acceptable HTTP compression schemes (gzip, deflate, and sdch).
• Accept-language: The acceptable languages (en-US and en; q=0.8) where q=0.8 is a relative quality factor that specifies the language the user would prefer on a scale of 0 to 1.
• Cookie: This is a session ID cookie (ASP.NET_SessionId=sidsruxjbm4eaed4d3dgg4zd) that was previously stored on the user's browser in a cookie and is being provided to the website.

The following table lists some of the more commonly used modifiers:

Request Modifier	Description
Accept	Acceptable content types
Accept-charset	Acceptable character sets
Accept-encoding	Acceptable encodings
Accept-language	Acceptable languages
Accept-ranges	Server can accept range requests
Authorization	Authentication credentials for HTTP authentication
Cache-control	Caching directives
Connection	Type of connection preferred by the user agent
Cookie	HTTP cookie (a small piece of data sent from the website and stored in a user's browser, and/or sent back to the website the next time the user visits containing session information)
Content-length	Length of the request body in bytes
Content-type	Mime type of the body (used with POST and PUT requests)
Date	Date and time the message was sent
Expect	Defines server behavior expected by the client
If-match	Perform action if client-provided information matches
If-modified-since	Provide date/time of cached data; return 304 Not Modified if the cached data is still current
If-range	Request for range of missing information
IF-unmodified-since	Only send if unmodified since the provided date/time
Max-forwards	Limit the number of forwards through proxies or gateways
Proxy-authorization	Authorization credential for a proxy connection
Range	Request only part of an entity
TE	Transfer encodings accepted
User-agent	A string containing browser and operating system information
Via	The proxies traversed

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Wireshark DNS filters

Capture filter(s): port 53

Display filter(s): dns dns.flags.response == 0(DNS query) dns.flags.response == 1(DNS response) dns.flags.rcode != 0(DNS response contains an error)

Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is the application protocol used when someone browses (unsecured) websites on the Internet, along with the secure version (HTTPS). HTTP/1.1 is the current version—although HTTP/2.0 is starting to appear in some environments. Be aware that some network devices such as proxy servers and gateways may not support HTTP/2.0 yet.

An example of a HTTP packet delivering a GET request to a web server is depicted in the following screenshot:

The most common features and fields of the HTTP protocol include HTTP Methods, Host, and Request Modifiers.

In the preceding screenshot, the HTTP header includes:

• Request Method: GET
• Request URI: /Orion (a home page on the web server)
• Request Version: HTTP/1.1

HTTP Methods

Some of the more common HTTP Methods are listed and described in the following table:

Method	Description
GET	This retrieves information defined by the Uniform Resource Identifier (URI) field
HEAD	This retrieves meta data related to the desired URI
POST	This sends data to the HTTP server/application
OPTIONS	This determines the options associated with a resource
PUT	This sends data to the HTTP server/application
DELETE	This deletes the resource defined by the URI
CONNECT	This is used to connect to a proxy device

Host

The Host field identifies the target host and port number of the resource being requested. In the preceding screenshot, Host is pktiqsvr1 on port 8080.

Request Modifiers

HTTP requests and responses use Request Modifiers to provide details for the request. In the preceding screenshot, Request Modifiers includes:

• Connection: This indicates the preference for a persistent connection (keep-alive).
• Accept: This is a list of data formats (text/html and application/xhtml plus xml) accepted.
• User-agent: This is a list of browser and operating system parameters (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit) for the requesting device.
• Accept-encoding: This is a list of the acceptable HTTP compression schemes (gzip, deflate, and sdch).
• Accept-language: The acceptable languages (en-US and en; q=0.8) where q=0.8 is a relative quality factor that specifies the language the user would prefer on a scale of 0 to 1.
• Cookie: This is a session ID cookie (ASP.NET_SessionId=sidsruxjbm4eaed4d3dgg4zd) that was previously stored on the user's browser in a cookie and is being provided to the website.

The following table lists some of the more commonly used modifiers:

Request Modifier	Description
Accept	Acceptable content types
Accept-charset	Acceptable character sets
Accept-encoding	Acceptable encodings
Accept-language	Acceptable languages
Accept-ranges	Server can accept range requests
Authorization	Authentication credentials for HTTP authentication
Cache-control	Caching directives
Connection	Type of connection preferred by the user agent
Cookie	HTTP cookie (a small piece of data sent from the website and stored in a user's browser, and/or sent back to the website the next time the user visits containing session information)
Content-length	Length of the request body in bytes
Content-type	Mime type of the body (used with POST and PUT requests)
Date	Date and time the message was sent
Expect	Defines server behavior expected by the client
If-match	Perform action if client-provided information matches
If-modified-since	Provide date/time of cached data; return 304 Not Modified if the cached data is still current
If-range	Request for range of missing information
IF-unmodified-since	Only send if unmodified since the provided date/time
Max-forwards	Limit the number of forwards through proxies or gateways
Proxy-authorization	Authorization credential for a proxy connection
Range	Request only part of an entity
TE	Transfer encodings accepted
User-agent	A string containing browser and operating system information
Via	The proxies traversed

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is the application protocol used when someone browses (unsecured) websites on the Internet, along with the secure version (HTTPS). HTTP/1.1 is the current version—although HTTP/2.0 is starting to appear in some environments. Be aware that some network devices such as proxy servers and gateways may not support HTTP/2.0 yet.

An example of a HTTP packet delivering a GET request to a web server is depicted in the following screenshot:

The most common features and fields of the HTTP protocol include HTTP Methods, Host, and Request Modifiers.

In the preceding screenshot, the HTTP header includes:

• Request Method: GET
• Request URI: /Orion (a home page on the web server)
• Request Version: HTTP/1.1

HTTP Methods

Some of the more common HTTP Methods are listed and described in the following table:

Method	Description
GET	This retrieves information defined by the Uniform Resource Identifier (URI) field
HEAD	This retrieves meta data related to the desired URI
POST	This sends data to the HTTP server/application
OPTIONS	This determines the options associated with a resource
PUT	This sends data to the HTTP server/application
DELETE	This deletes the resource defined by the URI
CONNECT	This is used to connect to a proxy device

Host

The Host field identifies the target host and port number of the resource being requested. In the preceding screenshot, Host is pktiqsvr1 on port 8080.

Request Modifiers

HTTP requests and responses use Request Modifiers to provide details for the request. In the preceding screenshot, Request Modifiers includes:

• Connection: This indicates the preference for a persistent connection (keep-alive).
• Accept: This is a list of data formats (text/html and application/xhtml plus xml) accepted.
• User-agent: This is a list of browser and operating system parameters (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit) for the requesting device.
• Accept-encoding: This is a list of the acceptable HTTP compression schemes (gzip, deflate, and sdch).
• Accept-language: The acceptable languages (en-US and en; q=0.8) where q=0.8 is a relative quality factor that specifies the language the user would prefer on a scale of 0 to 1.
• Cookie: This is a session ID cookie (ASP.NET_SessionId=sidsruxjbm4eaed4d3dgg4zd) that was previously stored on the user's browser in a cookie and is being provided to the website.

The following table lists some of the more commonly used modifiers:

Request Modifier	Description
Accept	Acceptable content types
Accept-charset	Acceptable character sets
Accept-encoding	Acceptable encodings
Accept-language	Acceptable languages
Accept-ranges	Server can accept range requests
Authorization	Authentication credentials for HTTP authentication
Cache-control	Caching directives
Connection	Type of connection preferred by the user agent
Cookie	HTTP cookie (a small piece of data sent from the website and stored in a user's browser, and/or sent back to the website the next time the user visits containing session information)
Content-length	Length of the request body in bytes
Content-type	Mime type of the body (used with POST and PUT requests)
Date	Date and time the message was sent
Expect	Defines server behavior expected by the client
If-match	Perform action if client-provided information matches
If-modified-since	Provide date/time of cached data; return 304 Not Modified if the cached data is still current
If-range	Request for range of missing information
IF-unmodified-since	Only send if unmodified since the provided date/time
Max-forwards	Limit the number of forwards through proxies or gateways
Proxy-authorization	Authorization credential for a proxy connection
Range	Request only part of an entity
TE	Transfer encodings accepted
User-agent	A string containing browser and operating system information
Via	The proxies traversed

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

HTTP Methods

Some of the more common HTTP Methods are listed and described in the following table:

Method	Description
GET	This retrieves information defined by the Uniform Resource Identifier (URI) field
HEAD	This retrieves meta data related to the desired URI
POST	This sends data to the HTTP server/application
OPTIONS	This determines the options associated with a resource
PUT	This sends data to the HTTP server/application
DELETE	This deletes the resource defined by the URI
CONNECT	This is used to connect to a proxy device

Host

The Host field identifies the target host and port number of the resource being requested. In the preceding screenshot, Host is pktiqsvr1 on port 8080.

Request Modifiers

HTTP requests and responses use Request Modifiers to provide details for the request. In the preceding screenshot, Request Modifiers includes:

• Connection: This indicates the preference for a persistent connection (keep-alive).
• Accept: This is a list of data formats (text/html and application/xhtml plus xml) accepted.
• User-agent: This is a list of browser and operating system parameters (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit) for the requesting device.
• Accept-encoding: This is a list of the acceptable HTTP compression schemes (gzip, deflate, and sdch).
• Accept-language: The acceptable languages (en-US and en; q=0.8) where q=0.8 is a relative quality factor that specifies the language the user would prefer on a scale of 0 to 1.
• Cookie: This is a session ID cookie (ASP.NET_SessionId=sidsruxjbm4eaed4d3dgg4zd) that was previously stored on the user's browser in a cookie and is being provided to the website.

The following table lists some of the more commonly used modifiers:

Request Modifier	Description
Accept	Acceptable content types
Accept-charset	Acceptable character sets
Accept-encoding	Acceptable encodings
Accept-language	Acceptable languages
Accept-ranges	Server can accept range requests
Authorization	Authentication credentials for HTTP authentication
Cache-control	Caching directives
Connection	Type of connection preferred by the user agent
Cookie	HTTP cookie (a small piece of data sent from the website and stored in a user's browser, and/or sent back to the website the next time the user visits containing session information)
Content-length	Length of the request body in bytes
Content-type	Mime type of the body (used with POST and PUT requests)
Date	Date and time the message was sent
Expect	Defines server behavior expected by the client
If-match	Perform action if client-provided information matches
If-modified-since	Provide date/time of cached data; return 304 Not Modified if the cached data is still current
If-range	Request for range of missing information
IF-unmodified-since	Only send if unmodified since the provided date/time
Max-forwards	Limit the number of forwards through proxies or gateways
Proxy-authorization	Authorization credential for a proxy connection
Range	Request only part of an entity
TE	Transfer encodings accepted
User-agent	A string containing browser and operating system information
Via	The proxies traversed

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Host

The Host field identifies the target host and port number of the resource being requested. In the preceding screenshot, Host is pktiqsvr1 on port 8080.

Request Modifiers

HTTP requests and responses use Request Modifiers to provide details for the request. In the preceding screenshot, Request Modifiers includes:

• Connection: This indicates the preference for a persistent connection (keep-alive).
• Accept: This is a list of data formats (text/html and application/xhtml plus xml) accepted.
• User-agent: This is a list of browser and operating system parameters (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit) for the requesting device.
• Accept-encoding: This is a list of the acceptable HTTP compression schemes (gzip, deflate, and sdch).
• Accept-language: The acceptable languages (en-US and en; q=0.8) where q=0.8 is a relative quality factor that specifies the language the user would prefer on a scale of 0 to 1.
• Cookie: This is a session ID cookie (ASP.NET_SessionId=sidsruxjbm4eaed4d3dgg4zd) that was previously stored on the user's browser in a cookie and is being provided to the website.

The following table lists some of the more commonly used modifiers:

Request Modifier	Description
Accept	Acceptable content types
Accept-charset	Acceptable character sets
Accept-encoding	Acceptable encodings
Accept-language	Acceptable languages
Accept-ranges	Server can accept range requests
Authorization	Authentication credentials for HTTP authentication
Cache-control	Caching directives
Connection	Type of connection preferred by the user agent
Cookie	HTTP cookie (a small piece of data sent from the website and stored in a user's browser, and/or sent back to the website the next time the user visits containing session information)
Content-length	Length of the request body in bytes
Content-type	Mime type of the body (used with POST and PUT requests)
Date	Date and time the message was sent
Expect	Defines server behavior expected by the client
If-match	Perform action if client-provided information matches
If-modified-since	Provide date/time of cached data; return 304 Not Modified if the cached data is still current
If-range	Request for range of missing information
IF-unmodified-since	Only send if unmodified since the provided date/time
Max-forwards	Limit the number of forwards through proxies or gateways
Proxy-authorization	Authorization credential for a proxy connection
Range	Request only part of an entity
TE	Transfer encodings accepted
User-agent	A string containing browser and operating system information
Via	The proxies traversed

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Request Modifiers

HTTP requests and responses use Request Modifiers to provide details for the request. In the preceding screenshot, Request Modifiers includes:

• Connection: This indicates the preference for a persistent connection (keep-alive).
• Accept: This is a list of data formats (text/html and application/xhtml plus xml) accepted.
• User-agent: This is a list of browser and operating system parameters (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit) for the requesting device.
• Accept-encoding: This is a list of the acceptable HTTP compression schemes (gzip, deflate, and sdch).
• Accept-language: The acceptable languages (en-US and en; q=0.8) where q=0.8 is a relative quality factor that specifies the language the user would prefer on a scale of 0 to 1.
• Cookie: This is a session ID cookie (ASP.NET_SessionId=sidsruxjbm4eaed4d3dgg4zd) that was previously stored on the user's browser in a cookie and is being provided to the website.

The following table lists some of the more commonly used modifiers:

Request Modifier	Description
Accept	Acceptable content types
Accept-charset	Acceptable character sets
Accept-encoding	Acceptable encodings
Accept-language	Acceptable languages
Accept-ranges	Server can accept range requests
Authorization	Authentication credentials for HTTP authentication
Cache-control	Caching directives
Connection	Type of connection preferred by the user agent
Cookie	HTTP cookie (a small piece of data sent from the website and stored in a user's browser, and/or sent back to the website the next time the user visits containing session information)
Content-length	Length of the request body in bytes
Content-type	Mime type of the body (used with POST and PUT requests)
Date	Date and time the message was sent
Expect	Defines server behavior expected by the client
If-match	Perform action if client-provided information matches
If-modified-since	Provide date/time of cached data; return 304 Not Modified if the cached data is still current
If-range	Request for range of missing information
IF-unmodified-since	Only send if unmodified since the provided date/time
Max-forwards	Limit the number of forwards through proxies or gateways
Proxy-authorization	Authorization credential for a proxy connection
Range	Request only part of an entity
TE	Transfer encodings accepted
User-agent	A string containing browser and operating system information
Via	The proxies traversed

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Wireshark HTTP filters

Capture filter(s): tcp port http tcp port https

Display filter(s): http http.request.method == "GET" or http.request.method == "POST" http.response.code > 399 (identifies client or server error packets)

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Additional information

Covering all the most common upper layer protocols or covering them to any great depth is obviously more than what can be included in a book of this size. I encourage you to spend some time studying those protocols that are of interest to you for personal or job-related reasons. The return on your investment in time will be well worth the effort.

Additional information for any of the protocols discussed in this chapter as well as all those not covered can be found online.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Wireshark wiki

If you are inspecting a protocol within the Wireshark's Packet Details pane, you can right-click on a protocol header or field within a header and select the Wiki Protocol Page from the menu to go to the specific page on the Wireshark wiki that contains information on that protocol. More information can be found at http://wiki.wireshark.org/ProtocolReference.

You can also get a complete list of Wireshark display filters on specific protocols by selecting a protocol header or a field within a header, right-clicking, and selecting Filter Field Reference.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Protocols on Wikipedia

You can find general information on various protocols on Wikipedia. Start with the Internet protocol. Additional links to the entire Internet protocol suite are also provided at http://en.wikipedia.org/wiki/Internet_Protocol.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Requests for Comments

The Requests for Comment (RFC) documents contain detailed information for all the Internet protocols. These documents are maintained by the Internet Engineering Task Force (IETF) and are the final word on how the protocols should be implemented and function (http://www.ietf.org/rfc.html). If you want to search for a specific RFC by title or keyword, use the link http://www.rfc-editor.org/search/rfc_search.php.

Summary

The topics covered in this chapter included protocol and field coverage of the network layer protocols IPv4, ARP, IGMP, ICMP, IPv6, and ICMPv6; the transport layer protocols UDP and TCP; an overview of the application layer protocols DHCP, DHCPv6, and DNS; and a more in-depth look at HTTP.

In the next chapter, we'll put all the topics covered so far to good use by using Wireshark to troubleshoot the functionality and performance issues.