IPv4 Packet Header

Why is there a Protocol field in the IP header? Why does Layer 3 need to know about what Layer 4 protocol is being used?

Hello Jashan

It does seem strange that the IP header should include information about what is contained in its payload. It seems to go against the “separation of roles” that the OSI model advocates. However, it is important for a host that receives an IP packet to know how to interpret the payload as the process of decapsulation takes place. This is necessary because on the wire, the data is nothing but a string of 1’s and 0’s. The receiving endpoint must have a way of interpreting what the next bits of the payload refer to.

Similarly, the Ethertype field in the Ethernet frame header is used to indicate the protocol carried in its payload for the same purpose.

I hope this has been helpful!


Good time,
I didn’t understand the the Header Length -field of IPV4 pakcet header, that how those bits like, 20 bytes, 15 bit and 60 bytes been calculated.
I thank you and appreciate in advance from your help in this regard.


Ajmal" Ahmadi

New member from Afghanistan

Hello Ajmal

The Header Length field is a field of 4 bits that tells us how big the IPv4 header is. The length is indicated in the number of 32 bit pieces. In order to get the header length in bytes, the value in this field must be multiplied by 4. In order to get the header length in bits, we must multiply by 32. So…

  • For a value of 5, the header length is 5 * 4 = 20 bytes or 5 * 32 = 160 bits
  • For a value of 6, the header length is 6 * 4 = 24 bytes or 6 * 32 = 192 bits
  • For a value of 7, the header length is 7 * 4 = 28 bytes or 7 * 32 = 224 bits
  • For a value of 10, the header length is 10 * 4 = 40 bytes or 10 * 32 = 360 bits

The minimum size of an IPv4 header is 20, so the header length field will have a minimum value of 5, or 0101 in binary.

I hope this has been helpful!


Hello lagapides,
It’s about header length. The IHL field has only 4 bits so it can hold only 15 numbers as maximum value. I don’t understand where does the 32 bit increment come from? And why can’t we use 1,2,4 as minimum value for multiplying with 32 bits?

Hello Rajaram

The header length field is used to measure the size of the header of the IP packet. But it doesn’t measure it in bits, but in 32-bit blocks. Take a look at the following diagram of an IPv4 header:

Each row of this depiction represents 32 bits of information. Now if we assume that the specific IP packet doesn’t have any IP option information, then the value found within the header length field should be 0101 which is 5 in decimal. This is because the header length is 5 blocks of 32-bits, and you can see these are labeled to the right of the diagram above. Note that all five 32 bit blocks contain header fields that are absolutely necessary, so you will never have a header size less than 5 blocks in size so you will never have a header length field with a value smaller than 5.

Now if the IP option field is not empty, then the header length will increase. But remember, the IP option section only increases by increments of 32 bits. You will never have an IP Option section with a size of say 67 or 84 bits. It will always be 32, 64, 96, 128 and so on. This way, the header length field always measures the number of blocks in the header.

I hope this has been helpful!



Thank you, it is clear now.

1 Like

in IP header length we have 4 bit or 5 bit ??.

if i am not wrong,

After fragmentation of an IP packet . The identifier field value remain same for all fragmented packet .and the fragment off set value changes for each fragmented packet …is not it ??

Hello Narad

The header length field of the IPv4 packet is always 4 bits. That means it can have a value between 0 and 15. But remember, it signifies the number of 32-bit blocks that the header contains. When there are no options fields, the actual lowest value that you can have for this field is 5 in decimal or 0101 in binary. This is because that’s the smallest IPv4 header you can have.

The Identification field is used to aid in the reassembly of fragmented IP packets. But it’s not quite as simple as that. This value must be the same for:

  • a given source address
  • a given destination address
  • a given protocol
  • for the duration of the maximum datagram lifetime (MDL) which is typically 120 seconds

The fragments of any fragmented IP packet will have the same source and destination addresses, and of course the same protocol, and must also all be sent within the limit of the MDL. If those criteria are matched, then the ID will indeed be the same for all fragments of the IP packet. What changes is the offset value.

More information bout this can be found at the following links:

I hope this has been helpful!


It says that TTL value will be decremented by one when every time it passes a L3 node and this is the loop prevention mechanism traditionally in IP header. My questions below,

  1. By default when an IP packet is originated, its TTL is 64 or 255 etc depending on the OS. This means that a packet must travel 64 nodes before its dropped? Is that efficient in internet?
  2. All routing protocols like BGP, OSPF etc have its own loop prevention mechanism, theoretically they sounds much scalable method than TTL . So my assumption is that, TTL in ip header will never be used because routing protocol will take care of loop prevention even before 64hops.
  3. Static route may need to use this TTL for loop prevention. Is there other case scenarios where TTL is in use that you can think of?

Hello Don

The TTL is used as a last resort to ensure that IP packets do not continuously roam the network forever if there is some misconfiguration or network fault. Since it is a last resort, it is rare that it is ever needed to get rid of such packets. In most cases, packets will either reach their destination, will be dropped due to lack of a route, or be dropped due to other loop prevention mechanisms such as those of routing protocols as you mentioned in your post.

The reason the default TTL is set so high is that, first, it is generally accepted that you should be able to reach any destination on the Internet within 30 hops under normal circumstances. But you may have situations when there is a routing problem on the internet that may cause this number to increase. So setting this value to 64 or even 255 ensures that you’re not prematurely dropping packets that would have eventually reached their destination, albeit after an unusually high number of hops. Any packets that do exceed 64 hops are likely not going to reach their destinations, so they are dropped outright.

So it is not considered inefficient, because only a very small number of packets actually get dropped due to TTL reaching zero. Secondly, your assumption that TTL will never be used is almost right in the sense that it is rarely used, because of all the other prevention mechanisms in place.

TTL is definitely needed if you have only static routing in your network, because there are no other mechanisms to prevent loops. So if you create a routing loop with your static routes, then only the TTL will be able to get rid of eternally routed packets.

TTL is extensively used in various other mechanisms including the following:

I hope this has been helpful!


Thanks Lazaros… This was helpful

1 Like

i didn’t understand this .The minimum length of an IP header is 20 bytes so with 32 bit increments, you would see value of 5 here. The maximum value we can create with 4 bits is 15 so with 32 bit increments

o with 32 bit increments, you would see **value of 5 here 32 bits = 4 bytes i dont understand this ? why its 5 ?

Hello Abdul

The Header Length is a “4 bit field that tells us the length of the IP header in 32 bit increments”.

To understand this statement more clearly, let’s use 4-byte increments which is the same as 32-bit increments since 4 bytes = 32 bits.

  • A value of 1 in the Header Length gives us a length of 4 bytes
  • A value of 2 in the Header Length gives us a length of 8 bytes
  • A value of 3 in the Header Length gives us a length of 12 bytes
  • A value of 4 in the Header Length gives us a length of 16 bytes
  • A value of 5 in the Header Length gives us a length of 20 bytes

Because the length of the IP header cannot be smaller than 20 bytes, the smallest value of the Header Length is 5. It can be larger of course, like so:

  • A value of 6 in the Header Length gives us a length of 24 bytes
  • A value of 7 in the Header Length gives us a length of 28 bytes
  • A value of 8 in the Header Length gives us a length of 32 bytes
  • A value of 14 in the Header Length gives us a length of 56 bytes
  • A value of 15 in the Header Length gives us a length of 60 bytes

So essentially, to get the header length in bytes, we multiply the value of the Header Length by 4.

Does that make sense?

I hope this has been helpful!



The source and destination IP address in the header are /32, even if the packet was created on a pc which has an IP with a /24 mask ?

Hello Ahmedlmad

Yes, that is correct. The IP header contains no information about subnet masks. That information is found only as a network parameter configured on the network interface of each device. The subnet mask is used by host devices and routing devices to determine which networks particular IP addresses (such as those configured on the interfaces and those encountered in the headers of IP packets) belong to.

The subnet mask configured on a router’s interfaces allows a router to determine the networks (IP address ranges) that its interfaces are connected to. Using that information, it can correctly build the routing table with its directly connected networks.

Similarly, a host uses its subnet mask to determine if the destination address in the IP header of a packet it is about to send is in its own subnet or in a different subnet. In the former case it sends it directly to the destination host, and in the latter case it will direct the packet to the default gateway.

Subnet information therefore is unnecessary in the header of the IP packet.

I hope this has been helpful!


1 Like

DSCP setting in the IP headers, I did some tests and they do seem to cross the internet. I have heard sometimes they get changed and not carried over the internet. Any way to tell a carrier to preserve them? private circuits (not internet) ?

Hello Rod

There are a couple of things to keep in mind when examining how DSCP values are modified over the Internet. First of all, if we’re talking about any kind of private circuit, VPN, MPLS, MetroEthernet, or others, where our internal traffic is tunneled in some way over another technology, then the DSCP values of those packets are not modified. These are not considered packets that are on the Internet at large but are sent via these technologies between remote sites, as if those remote sites were on the same corporate LAN. Such packets are not directly routed by any router on the Internet, but are tunneled and remain unchanged.

Now when we’re not using such technologies, and you send data out of your ISP’s connection to the Internet, the DSCP values will typically be reset by the first router that is encountered. You mention that:

In order to ensure that this is indeed the case, you would have to take a packet capture at that particular router. By examining packets that have arrived on your network, you still cannot be sure of what happened while that packet was traversing the Internet unless you take a packet capture at one or more of the routers on the Internet itself. For example, you might examine a packet that has just arrived on your network. That packet has passed through the edge router of your network, which may change the DSCP values as the packet enters the corporate network.

So it is not as clear-cut and certain as to what happens while a packet traverses the internet. However, your question got me thinking, and I did some more research. I found the following research paper on the subject which has some interesting results.
It states that within the Internet core, they found that the majority of packets (over 70%) had their DSCP values carried transparently, meaning they remained unchanged. The percentage changes somewhat when we take the network edge into account, which is where the local ISPs operate, which tend to modify them more often, depending upon the type of network (mobile or fixed) and the location in the world (Americas, Europe, Asia etc…).

I hope this has been helpful!


Hello Rene,

As i learned UDP or TCP protocol carried in TRANSPORT layer of OSI Model. But as i see in the captured packet, IP address and Protocol types carried in Network layer. only Port numbers shown in Transport layer. So i am confused further exams how to answer this type of questions. IS UDP, TCP layer 3 or 4?


Hello Munkhorgil

Yes, you are correct, TCP and UDP are protocols that operate in the Transport layer of the OSI model. Now what you saw in the Network layer of the Wireshark capture is the following:

In the header of the IPv4 packet, you will find the “Protocol” field. This field contains information about the Transport layer protocol that this particular IPv4 packet is carrying as its payload. This is just information

Don’t confuse the simple mention of the protocol in the IP header with the actual operation of the TCP or UDP protocols. TCP and UDP are Transport layer protocols because they operate on that layer.

I hope this has been helpful!