Here we see the structure of the IP header values.

We can see

• the version of IP, which is almost always the value 4,

• the Internet Header Length value,

• the DiffServ Code Point value (Differentiated Services Code point)

• the Explicit Congestion Notification fields.

Among these first four fields, the one you'll probably be using the most to troubleshoot is the DSCP, or DiffServ, field.

This is where markings for packet priority are made.

DSCP takes 6 bits of the IP Priority remaining 2 bits are used for the ECN

• Total Length is another important header value. This shows you how much data is encapsulated in this packet, including the header itself. This value is useful when we're troubleshooting issues with MTU on the network, which can affect us when a packet is too large to be transmitted across a network segment.

After this, we have

• the ID number of the packet. This number is either randomized, or it will increment sequentially. The point of this header value is to be able to uniquely identify a specific packet from a station. This helps when tracking down whether a packet is duplicated or not, and it can help the fingerprint application traffic behind load balancers.

Next,

• the Flags field, and this is used to indicate if fragmentation is allowed or not for this packet. Now, some applications may mark a packet so that it won't be broken up by the network under any circumstances. This could cause an issue if the packet has to traverse a network connection with a lower MTU than the packet size.

• Fragment offset

• Time to Live field. With just a glance, we can determine how many routers or layer 3 switches a packet has hopped through on its way to its destination.

• The Protocol field tells us which protocol is coming up next in the data payload. This is where we can look to see if the ICMP, UDP, TCP, or some other header is next to be dissected. Wireshark uses this field to know which protocol dissector to bring up next

• Header Checksum

IP Fragmentation

some notes

Sometimes, IP will build a packet that's larger than the network can handle. Remember that at first the client has no idea what the lowest MTU is along the network path. The MTU that it has on its local interface might be higher than that. So, for example, imagine that this packet needs to travel across a link that has an MTU of 1400. Perhaps this is to preserve space for other header values, such as a VPN encapsulation. When the 1500‑byte packet arrives at the first router, as long as the packet is not marked with the do not fragment flag in the IP header, the router will be able to break the packet into two separate packets and send them along their way. These packets are called fragments. Each fragment will have IP header values with information on how to reassemble the data once it reaches its destination. In the IP header, as shown here in Wireshark, the Flags field is what controls the fragmentation process. Sometimes we're working with encrypted applications or other services that do not want data to be manipulated or intercepted. For this reason, it's not uncommon to see the Don't fragment bit set in the Flags field. If this bit is set and the Total Length is 1500, it's possible that we could see some ICMP messages from routers indicating that they need to break up the packet, but they can't do so due to this flag.

IP Fragment Ex

Two important field to look

• More Fragments

• Fragment Offset

If More Fragments is set and Fragment offset is 0 then this is the First fragmented packet of the large size packet. 

If More Fragments is not set and Fragment Offset has some value then that is the last fragemented packet of the large size packet.

The Fragment offset value tells from which byte of the Big packet it carries. (Multiply the offset value with 8 to get the bytes value)

Now, this is just a two‑packet trace file, simple, and it was taken by sending a ping that was too large. So I went ahead and used the length switch to send a packet that was larger than 1500. Now, in this case, the sending interface is what fragmented the packet as it left the interface. However, this function would work exactly the same if this was a router that actually did the fragmentation. So let's examine. So if we come up here to our first packet, we can see that Wireshark is telling us that this is a fragmented IP protocol. So I can come down to my IP header values, and I see I have no real DiffServ field. The total length of this packet, including the IP header, is 1500, and I come down here to Flags.

Now, in this case, I can see that I have More fragments is Set. That means that this packet, although it's 1500, is a fragment of a larger packet, and there are more fragments to follow. Down here I can see Fragment offset: 0. That means that this is the first fragment in the chain.

So we start our data at 0. That's how we start counting. Okay, so let's take a look at the second packet. This is where I can see that this is a smaller one. Here in my Total Length, I can see that this is 148 bytes, and if I come down to the Flags field, I can see that More fragments is Not set. That means that this is the final fragment. So we just have two fragments here that make up a larger packet. Down here, I can see the Fragment offset is 185. And you might be thinking 185? What does that have to do with 1500 up above? How do I reconcile those two values? Well, if you take the number of 185 and you multiply it by 8, you'll find that that is 1480. So what this is saying is offset the data, plug this data, cut and paste it at 1480, which is exactly past where the first one ends. Remember, 1480 also includes a 20‑byte IP header. So as soon as we take away that 20 bytes, the actual encompassed payload is 1480. So this second packet, the second fragment starts at 1480 into the data stream. That's where we can reassemble those fragments, and we can pass them up the receiving IP stack. So remember, along the way, this fragmentation may happen, but it'll only happen as long as we don't have the do not fragment bit set.

If this bit is set, then the routers cannot break up these packets, and it will return an ICMP do not fragment bit is set, but we need to fragment.

IP TTL

The Time to Live field and IP is not a function of time, but rather it's a value that's progressively decremented as the packet traverses routers and layer 3 switches. As that packet travels through a network, each router will decrement this value by one. If this value ever goes down to 0 or expires, the router will drop the packet and reply with an ICMP message indicating that the time to live was exceeded.

In the opposite direction of communication, a station will use its own starting full count TTL value when it transmits a packet. The same process will happen in the opposite direction. This way we can have an educated guess as far as how many routers a packet has traveled through. These days, the TTL value usually starts as one of these three numbers: 255, 128, or 64.

If we see a packet that has a TTL of 253 then, we can determine that the TTL likely started at 255 and has been routed twice. Remember, the TTL field is useful to determine how many router hops away a station is. This is one reason why the TTL value is shown when we ping something. It gives us a good estimate of how many routers the packet has traveled through on the return path.

TTL value can start with