IPv4 Packet Header


(Ajay R) #21

Thanks Andrew , Now its clear…


(Networklessons Admin) split this topic #22

19 posts were merged into an existing topic: IPv4 Packet Header


(Mohammad Hasanuz Zaman) #23

Hlw Rene,

Thanks a lot, you are amazing :slight_smile:
It is very basic question still curious to understand with your plain examaple .
I want to know about the TCP Checksum/UDP Checksum/ IP Header Checksum and Ethernet FCS .
1.TCP Checksum= It will ensure TCP Header and Data is ok or not ??
2.UDP Checksum= It will ensure UDP Header and Data is ok or not ??
3.IP Header Checksum= It only ensure the IP Header is ok or not ?? It will not ensure upper layer TCP Segment or UDP Datagram is ok or not ??
4. Ethernet FCS= It will ensure all is ok or not ? Here “all” means Ethernet Header + IP Header+TCP/UDP Header + Data. Also why we dont see the FCS field when capture.

Appreciate your plain example as always .Many Thanks

br//
zaman


(Lazaros Agapides) #24

Hello Mohammad

I will attempt to answer your question below:

Yes, youa re correct. It is however considered a relatively weak error detection method by modern standards, but is sufficient in combination with additional error checking functionalities both below and above the transport layer.

You are also correct concerning the checksum of the UDP checksum. The only difference is that in IPv4 this field is optional for UDP while in IPv6 it is mandatory. It functions in exactly the same way as the TCP checksum.

Correct. It only checks the integrity of the IP header and not the payload. It plays no role in ensuring upper layer segments or datagrams.

The Ethernet frame FCS will ensure the integrity of the whole frame including header and payload. It doesn’t check the individual headers of each of the upper layers because it doesn’t discern them as such, but it just sees them all together as the payload.

As for the FCS on Wireshark, Ethernet NIC cards often filter the preamble and the FCS so they don’t pass on that information to Wireshark. Some interfaces may have the capability of being configured to send this info, however, in most cases you won’t see it.

I hope this has been helpful!

Laz


(Mohammad Hasanuz Zaman) #25

Many Thanks Laz, I have another question regarding .why checksum has added at each layer. If Ethernet Checksum OK then we can say everything is OK , right ? Because it indicate all header and payload .so why header and payload will be check at each layer.Pls help me to understand it .Appreciate your reply as always.Thanks


(Lazaros Agapides) #26

Hello again Mohammad.

When any communication is initiated from source to destination, the contents of some network layers change for every hop and some do not change. So, you need some sort of integrity check at different layers to account for that. Let’s look at the following example:

Your PC with IP address 10.10.10.10 is sending an email to the email server with an IP address of 10.10.20.20. The encapsulation takes place like this:

Layer 4 TCP checksum checks the header and payload
Layer 3 IP header checksum checks only the IP header integrity
Layer 2 Ethernet FCS checks header and payload
Layer 1 Placed on the medium

Now because the destination is in another subnet, the PDU must be sent to the default gateway. The default gateway does some decapsulation as well:

Decapsulation:
Layer 2 Check Ethernet FCS and if approved, decapsulate further
Layer 3 Check IP header checksum and if approved, check destination IP addresses and determine routing

The PDU must now be reencapsulated
Layer 2 Create a new Ethernet Header with new Source and Destination MAC addresses and a new FCS
Layer 1 Place on the medium

Now the PDU has reached the subnet in which the email server is, so when it reaches the destination, decapsulation takes place again:

Layer 2 Check Ethernet FCS and if approved, decapsulate further
Layer 3 Check IP header checksum, and if approved, check IP destination address and confirm packet is for me
Layer 4 Check TCP checksum and confirm integrity of segment
Further decapsulate to the application layer.

So you should see from the above that the layer 2 FCS is necessary for EVERY hop that takes place, and it is actually recalculated every time!! The Layer 3 IP header checksum is checked every hop to confirm that the header is correct so that the destination IP address can be read and routing is determined. The Layer 4 TCP checksum is only checked at the destination to make sure the payload has no errors.

So once again, layer 2 changes every hop, layer 3 does not change but must be checked for correct routing, and layer 4 is checked only at the destination. So that’s why we need different integrity checks for different layers of the OSI.

I hope this has been helpful!

Laz


(Mohammad Hasanuz Zaman) #27

Hi Laz/Rene,

Thanks for your valuable reply.:+1:
One more question , If FCS ok then we can say everything (Ethernet Header + IP Header+TCP/UDP Header + Data ) is ok, right ?? or Is there any possibility that FCS approved/ok but IP Header Checksum or TCP/UDP checksum not ok ??? . If so then I think Different layer Checksum is mandatory otherwise not Mandatory. Just imagine , only FCS exist on ethernet and no other checksum(IP/TCP/UDP Checksum) on upper layer then what will happend on Intermediate device , They will face any issue ?? lets give an example source host(A) sending data with his computed TCP checksum, IP checksum and CRC value, consider there is problem in physical medium so there is chance to corrupt . now receiving device either transit router or final destination host unwarp / looking the Layer 2 information and compute CRC algorithm for validate to payload since my data is corrupted its dropped it there itself so no need to go to next level.

if there is any flip in TCP layer - > L2 CRC can able to identify while computing in L2 level , so why need each layer Checksum ??
Again,
like if there is any flip in IP layer - > CRC can able to identify while computing in Layer 2 level , so why need each layer checksum whereas L2 CRC can identify everything. I really appreciate your more clarification again.Thanks

br//zaman


(jonrandall) #28

Hi @Zaman.rubd

If FCS ok then we can say everything (Ethernet Header + IP Header+TCP/UDP Header + Data ) is ok, right ?? or Is there any possibility that FCS approved/ok but IP Header Checksum or TCP/UDP checksum not ok ?

The answer is Yes and also No.

The FCS is based on a hashing function so there is an extremely small possibility that the Ethernet FCS could be correct but the payload has been corrupted. However the probability of this is so small that we can safely ignore it.

In most cases a damaged frame would be damaged during transmission or in transit. Since a very high percentage of interfaces and links currently use Ethernet, the Ethernet FCS is an efficient way to detect corruption.

However, Ethernet is not used on every link and on every interface. At some point the TCP segment or IP packet may be passed over a different (non-Ethernet) L2 link so we must have a method to check integrity in those situations also.

Best regards,
Jon


(Mohammad Hasanuz Zaman) #29

Hi Jon/Laz,

Many Thanks. Could you please make me clear on some issue …

  1. Since Datalink layer has Many Encapsulation except Ethernet like HDLC,PPP,Frame Relay. So what is the role/Job of HDLC/PPP header FCS ?? It will check Integrity like ETHERNET FCS do ??

  2. Suppose A packet travelling from Source To Destination with diffrent L2 link(Ethernet, Serial Link) on different segment so what problem will raise ??

Appreciate your quick response here .Thanks

br//zaman


(Lazaros Agapides) #30

Hello Mohammad

Concerning your first question, the FCS for all layer two protocols plays the same role whether Ethernet, PPP or HDLC. It checks for integrity of the frame.

Concerning your second question, a packet that travels over multiple L2 protocols does not present any problems. This is because the FCS that is created for each hop of the trip is created and stripped off during that hop.

For example, a frame leaves a PC and hits a router’s interface. As it is being encapsulated at the PC’s NIC, an FCS is created and added at the end. When the router receives it, the Ethernet header is removed and the FCS is checked. If it passes, then the packet is prepared for routing.

Let’s say the second hop of the trip is over a serial link using HDLC. The packet is RE-ENCAPSULATED with a NEW HDLC header and a NEW FCS. This new frame is placed on the serial link. When it is received by the router on the other end of the HDLC link, the HDLC header is stripped and the FCS is checked. If it passes, the packet is then prepared for further routing.

So you see that the FCS at layer two has only local significance. That is, it is only used for the specific hop. Once the hop is over, the FCS is discarded and is not used again. A new FCS is created for the next hop of the journey.

I hope this has been helpful!

Laz


(Mohammad Hasanuz Zaman) #31

Hi Rene,
**I want to know from you** regarding my first question “Why each layer Checksum is essential whereas Ethernet FCS ensuring Header & Payload ok or not” . I am facing some confusion on it . My understanding is …

  1. No need IP Header Checksum and TCP/UDP Checksum since Ethernet FCS ensuring the Header and payload is ok or not .
  2. I think IP Header Checksum and TCP/UDP Checksum has used for further layer checking .There is LOGICAL issue behind this .
  3. The only reason could be “Layer 4 and Layer 3 don’t trust lower layer”

**Suppose Only Ethernet FCS exist on header and there is no checksum on L3 and L4 header. So what will happen . It will raise any issue ??**

Correct me in your clear text if i an wrong . Need your assistant badly .Thx

br//zaman


(jonrandall) #32

Hi @Zaman.rubd,

It’s great to see you wanting to get so deep in the understanding here. I think it’s important to consider two points:

First we must accept, checksums exists at multiple layers. They exist by design and normally we should not be concerned about them; we simply let them do their job :slight_smile:

Secondly, let’s imagine a hypothetical scenario where we send an IP packet from one city to another using an IP satellite link and only Ethernet FCS is used; no other FCS is allowed.

  1. We place the packet on our local Ethernet LAN and create an Ethernet FCS.
  2. When the IP packet arrives at the satellite terminal (e.g. VSAT), the Ethernet is removed and the Ethernet FCS is lost.
  3. The packet is now sent on the satellite link and becomes corrupted. There is no Ethernet FCS on this link so this corruption can not be detected.
  4. When the packet arrives at the destination it is then placed onto the Ethernet LAN and a new Ethernet FCS is created.
  5. The packet is received by another host who believes the Ethernet FCS is correct but does not understand why the data appears to be corrupted.

Of course this hypothetical situation produces an unacceptable outcome so it makes life much simpler if each OSI layer manages its own FCS. In this way we are sure that there is always at least one FCS. If there is more than one, we have duplication but we can consider it acceptable.

In summary, we are making a trade-off : simplicity + reliability vs. efficiency

I hope this helps. Kind regards,
Jon


(Praveen R) #33

Hi Rene,

Can you please explain the Time to Live, exactly how it works in real time.

Thanks,
Praveen.


(Lazaros Agapides) #34

Hello Praveen

The TTL field in the IP header is a field that contains a value that is decremented every time a packet is relayed by a router. For example, imagine a network with three routers:

PC1—R1—R2—R3—PC2

PC1 sends a packet to PC2. The packet has an initial TTL value of 64 (this is the default value in most cases, although this can be changed). When the packet reaches

* R1, it will be routed, and the TTL will be decremented, so TTL =63
* at R2, the packet will be routed and TTL will now be TTL= 62
* at R3 the packet will be routed and the TTL will now be TTL = 61

The purpose of this is to prevent incorrectly routed IP packets from remaining in a network forever. If there is a routing loop, packets will be routed continuously between routers until TTL equals 0. When a router receives an IP packet with TTL = 1, it will decrement the vlaue to 0 and discard the packet.

I hope this has been helpful!

Laz


(Praveen R) #35

Thanks alot Lazaros, Now i understood clearly.


(ganesh s) #36

Hi Rene,

Can you explain me the below mentioned topics in IPv4 header in detailed.I am having lot of confusing between bit and bytes in this ipv4 header topic and how they are calculated

Header Length

Total Length

Identification

IP Flags

Fragment Offset


(Rene Molenaar) #37

Hi Ganesh,

The header length can be a bit confusing. It specified the length of the IP header but we only have 4 bits. With 4 bits, you can create values between 0 and 15, that’s it.

How it works is that each bit represents a 32-bit increment. An IP header has a minimum length, which is 20 bytes.

1 byte = 8 bits so:

20 bytes = 160 bits

160 bits / 32-bit increments = 5

So by setting the header length to 5, we know that the length of the IP header is 20 bytes.

The total length and Identification are simple, these are both 16 bits so we can store values from 0 - 65535 here.

Let me explain the total length, identification, ip flags, and fragment offset with an example.

Let’s say this is our original IP packet:

Sequence Identifier Total Length Don’t Fragment More Fragments Fragment Offset
0 321 5140 0 0 0

This packet is 5140 bytes but that includes a 20 byte IP header. The data portion is 5120 bytes. This packet gets fragmented. Here are our fragments:

Sequence Identifier Total Length Don’t Fragment More Fragments Fragment Offset
0-0 321 1500 0 1 0
0-1 321 1500 0 1 185
0-2 321 1500 0 1 370
0-3 321 700 0 0 555

How did we come up with these values?

The identifier remains the same in all fragments. The first three fragments have the “more fragments” switch enabled.

* The first fragment is 1500 bytes but that includes 20 bytes for the IP header so the “data portion” is 1480 bytes.
* The second fragment is also 1500 bytes and the offset is 185:

  • 185 x 8 = 1480
  • This means the data portion of this fragment starts 1480 bytes into the original IP packet.
    * The third fragment is also 1500 bytes and the offset is 370:
  • 370 x 8 = 2960
  • This means the data portion of this fragment starts 2960 bytes into the original IP packet.
    * The fourth (last) fragments is 700 bytes and the offset is 555:
  • 555 x 8 = 4440
  • This means the data portion of this fragment starts 4440 bytes into the original IP packet.

Once we receive the last fragment, we can tell what the size of the original IP packet is. The offset is 555 which means we start 4440 bytes into the original IP packet.

Now take the data bytes from the last fragment: 700 bytes - 20 bytes for the IP header = 680 bytes.

4440 + 680 = 5120 bytes. That’s the length of the data portion of the original IP packet.

I hope this helps!

Rene


(ganesh s) #38

Thanks Rene for your reply.Please dont mistake me as i asking some of basic questions

I can understand the length of the IP header is 4 bits.but I am having a lot of confusion between bits and bytes calculation.

1bit==can be either 0 (or) 1

if its 4 bits then it should either 0101 if i convert that number from binary to decimal i get 5.

I am not sure whether my understanding is correct or not.please guide me Rene

IP header:

Here as you said 4bits and with that you can create value between 0 and 15. I want to know how these value are determined?

You say each bit represent a 32 bit increment

Total Length:

total length are 16 bits so we can store values from 0 - 65535 here.I want to know how these value are determined?

Fragment offset:

How fragment offset value 185,370,555 was determined?


(Rene Molenaar) #39

Hello Ganesh,

1 byte is 8 bits.

With 4 bytes, we have the following possible options:

* 0000 = 0
* 0001 = 1
* 0010 = 2
* 0011 = 3
* 0100 = 4
* 0101 = 5
* 0110 = 6
* 0111 = 7
* 1000 = 8
* 1001 = 9
* 1010 = 10
* 1011 = 11
* 1100 = 12
* 1101 = 13
* 1110 = 14
* 1111 = 15

From 0 to 15, that’s 16 different values. Keep in mind we count from 0…not from 1.

For whatever reason, they decided to only use 4 bits for the header length so if you want to fit a value like “160” in those 4 bits, it’s impossible. That’s why they use a “multiplier” of 32.

So if you have a header that is 20 bytes, you first calculate it to bits: 20 * 8 = 160 bits.

Then you divide 160 / 32 (the multiplier) and you have a value of 5. We set the value of 5 in those 4 bits and that’s it.

With 16 bits, you have 65536 different values…starting at 0, ending with 65535. Because we have enough bits, you don’t need to use a multiplier here. You can just set the value you want and that’s it.

Fragmentation is done on an 8-byte boundary so what we do, is we take the “data portion” of the packet and divide it by 8. For the first fragment, that is:

1480 / 8 = 185

Does this help?

Rene


(Muhammad Rasoul A) #40

Continuing the discussion from [IPv4 Packet
As it is my first post i would like to thanks networklessons.com team, and i have a question regarding what is the difference between Ipv4 packet header, header length (as you mentioned the maximum number we can get is 60 bytes so where does the total length come from), total length, and i am totally confused what is IP flags (what do DF and MF mean), Fragment Offset and IP options.