IP Fragmentation Q&A

#How does a router know whether it has to fragment a packet or not?

IP Fragmentation

An IP packet that is larger than the Maximum Transmission Unit (MTU) of an interface, is too large for transmission over that interface. The packet must either be fragmented, or discarded (and an ICMP error message returned to the sender). In either case, the original data will be fragmented into smaller packets (less than the smallest MTU) in order to allow it to be received by the final destination system.

There are two approaches to doing this fragmentation:

IP Router Segmentation:performing the fragmentation in the routers

IP Path MTU Discovery:forcing the sender to perform the fragmentation

IP Fragmentation processing at a Router

The simplest approach from the end-system point of view is not to worry about the MTU size. In this simple approach, the sender simply has to ensure that each packet is less than the MTU of the link on which it is sent. (The router always knows this from the link interface configuration information).

Large IP packets that exceed the MTU of the link between R1 and R2 are fragmented by R1 in to two or more IP packets each smaller than the MTU size.

The network layer then has to arrange to cut packets up into smaller fragments whenever a router encounters a link with an MTU smaller than the received IP packet size. All the fragments of an IP packet carry the same ID in the IP packet header (allowing the final receiver to reassemble the fragmented parts into the original PDU). This is called "IP fragmentation" or "IP segmentation". The problem is, this offloads a lot of work on to routers, and in the worst case, can also result in packets being segmented by several IP routers one after another, resulting in very peculiar fragmentation.

Fragmentation Method

To fragment/segment a long internet packet, a router (R1 in the figure below) creates a new IP packet and copies the contents of the IP header fields from the long packet into the new IP header. The data of the long packet is then divided into two portions on a 8 byte (64 bit) boundary, so that the first packet is less than the MTU of the out-going interface. The more-fragments flag (MF) in the first packet is set to one (to indicate that more fragments of this packet follow). The More Flag may already be set in this packet if it has already been fragmented by another system. This packet is forwarded.

The second created new packet is then processed. The packet header field is identical to that of the original packet (including the same value of the packet ID, the total length field, the more-fragments flag (MF) and the fragment offset field in the original packet). The packet header field is updated with a new offset field, by adding the number of payload bytes sent in the first fragment. If this new packet is larger than the allowed link MTU, the packet is again fragmented.

IP Router Fragmentation

Any packet that has a more fragments (MF) flag set, must have an integral multiple of 8 bytes. (The final fragment, which does not have this flag set, may have an arbitrary number of bytes).

IP Router fragmentation is not recommended in the modern Internet, and this feature was not carried-forward when the next generation Internet Protocol (IPv6) was specified.

IP Fragmentation processing at a Sender

Path MTU Discovery allows a sender to fragment/segment a long internet packet, rather than relying on routers to perform IP-level fragmentation. This is more efficient and more scalable. It is therefore the recommended method in the current Internet. This is also the only method supported in IPv6.

IP Reassembly processing at the Receiving End System

IP fragmentation and reassembly employs updating and using the values in the second 32 bits of the IPv4 packet header. An end system that accepts an IP packet (with a destination IP address that matches its own IP source address) will also reassemble any fragmented IP packets before these are passed to the next higher protocol layer.

The system stores all received fragments (i.e., IP packets with a more-fragments flag (MF) set to one, or where the fragment offset is non-zero), in one of a number of buffers (memory space). Packets with the same 16-bit Identification value are stored in the same buffer, at the offset specified by the fragment offset field specified in the packet header.

Packets which are incomplete remain stored in the buffer until either all fragments are received, OR a timer expires, indicating that the receiver does not expect to receive any more fragments. Completed packets are forwarded to the next higher protocol layer.

#What are the issues with IP fragmentation?

There are several issues that make IP fragmentation undesirable. There is a small increase in CPU and memory overhead to fragment an IP datagram. This holds true for the sender as well as for a router in the path between a sender and a receiver. Creating fragments simply involves creating fragment headers and copying the original datagram into the fragments. This can be done fairly efficiently because all the information needed to create the fragments is immediately available.

Fragmentation causes more overhead for the receiver when reassembling the fragments because the receiver must allocate memory for the arriving fragments and coalesce them back into one datagram after all of the fragments are received. Reassembly on a host is not considered a problem because the host has the time and memory resources to devote to this task.

But, reassembly is very inefficient on a router whose primary job is to forward packets as quickly as possible. A router is not designed to hold on to packets for any length of time. Also a router doing reassembly chooses the largest buffer available (18K) with which to work because it has no way of knowing the size of the original IP packet until the last fragment is received.

Another fragmentation issue involves handling dropped fragments. If one fragment of an IP datagram is dropped, then the entire original IP datagram must be resent, and it will also be fragmented. You see an example of this with Network File System (NFS). NFS, by default, has a read and write block size of 8192, so a NFS IP/UDP datagram will be approximately 8500 bytes (including NFS, UDP, and IP headers).

 A sending station connected to an Ethernet (MTU 1500) will have to fragment the 8500 byte datagram into six pieces; five 1500 byte fragments and one 1100 byte fragment. If any of the six fragments is dropped because of a congested link, the complete original datagram will have to be retransmitted, which means that six more fragments will have to be created. If this link drops one in six packets, then the odds are low that any NFS data can be transferred over this link, since at least one IP fragment would be dropped from each NFS 8500 byte original IP datagram.

Firewalls that filter or manipulate packets based on Layer 4 (L4) through Layer 7 (L7) information in the packet may have trouble processing IP fragments correctly. If the IP fragments are out of order, a firewall may block the non-initial fragments because they do not carry the information that would match the packet filter. This would mean that the original IP datagram could not be reassembled by the receiving host. If the firewall is configured to allow non-initial fragments with insufficient information to properly match the filter, then a non-initial fragment attack through the firewall could occur. Also, some network devices (such as Content Switch Engines) direct packets based on L4 through L7 information, and if a packet spans multiple fragments, then the device may have trouble enforcing its policies.

#What is meant by IP fragmentation?

The breaking up of a single IP datagram into two or more IP datagrams of smaller size is called IP fragmentation.

#Why is an IP datagram fragmented?

Every transmission medium has a limit on the maximum size of a frame (MTU) it can transmit. As IP datagrams are encapsulated in frames, the size of IP datagram is also restricted. If the size of An IP datagram is greater than this limit, then it must be fragmented.

#Which RFCs discuss IP fragmentation?

RFC 791 & RFC 815 discusses about IP datagrams, fragmentation and reassembly.

#Is it possible to select an IP datagram size to always avoid fragmentation?

It is not possible to select a particular IP datagram size to always avoid fragmentation, as the MTU for different transmission It is possible, though, for a given path to choose a size that will not lead to fragmentation. This is called Path MTU Discovery and is discussed in the RFC 1191. The TCP transport protocol tries to avoid fragmentation using the Maximum Segment Size (MSS) option.

#Where an IP datagram may get fragmented?

An IP datagram may get fragmented either at the sending host or at one of the intermediate routers.

#Where are the IP datagram fragments reassembled?

The IP fragments are reassembled only at the destination host.

#How to prevent an IP datagram from being fragmented?

A IP datagram can be prevented from fragmentation, by setting the "don't fragment" flag in the IP header.

#What happens when a datagram must be fragmented to traverse a network, but the "don't fragment" flag in the datagram is set?

The datagram whose "don't fragment" flag is set is discarded, if it must be fragmented to traverse a network. Also, a ICMP error message is sent back to the sender of the datagram.

#Will all the fragments of a datagram reach the destination using the same path?

The different fragments of the same IP datagram can travel in either in the same path or in different paths to the destination.

#Will all the fragments of a datagram arrive at the destination system in the correct order?

The different fragments of a single IP datagram can arrive in any order to the destination system.

#What happens to the original IP datagram when one or more fragments are lost?

When one or more fragments of an IP datagram are lost, then the entire IP datagram is discarded after a timeout period.

#What is the minimum size of an IP fragment?

The minimum size of an IP fragment is the minimum size of an IP header plus eight data bytes. Most firewall-type devices will drop an initial IP fragment (offset 0) that does not contain enough data to hold the transport headers. In other words, the IP fragment normally need 20 octets of data in addition to the IP header in order to get through a firewall if offset is 0.

#What are the limitations on the size of a fragment?

The size of an IP datagram fragment is limited by

The amount of remaining data in the original IP datagram

The MTU of the network and

Must be a multiple of 8, except for the final fragment.

#How is an IP datagram fragment differentiated from a non-fragmented IP datagram?

A complete IP datagram is differentiated from an IP fragment using the offset field and the "more fragments" flags. For a non-fragmented IP datagram, the fragment offset will be zero and the "more fragments" flag will be set to zero.

#How are the fragments of a single IP datagram identified?

The "identification" field in the IP header is used to identify the fragments of a single IP datagram. The value of this field is set by the originating system. It is unique for that source-destination pair and protocol for the duration in which the datagram will be active.

#How is the last fragment of an IP datagram identified?

The last fragment of an IP datagram is identified using the "more fragments" flag. The "more fragment" flag is set to zero for the last fragment.

#How is the length of a complete IP datagram calculated from the received IP fragments?

Using the fragment offset field and the length of the last fragment, the length of a complete IP datagram is calculated.

#How is an IP datagram fragmented?

In the following example, an IP datagram is fragmented into two. This same algorithm can be used to fragment the datagram into 'n' fragments.

The IP layer creates two new IP datagrams, whose length satisfies the requirements of the network in which the original datagram is going to be sent.

The IP header from the original IP datagram is copied to the two new datagrams.

The data in the original IP datagram is divided into two on an 8 byte boundary. The number of 8 byte blocks in the first portion is called Number of Fragment Blocks (NFB).

The first portion of the data is placed in the first new IP datagram.

The length field in the first new IP datagram is set to the length of the first datagram.

The fragment offset field in the first IP datagram is set to the value of that field in the original datagram.

The "more fragments" field in the first IP datagram is set to one.

The second portion of the data is placed in the second new IP datagram.

The length field in the second new IP datagram is set to the length of the second datagram.

The "more fragments" field in the second IP datagram is set to the same value as the original IP datagram.

The fragment offset field in the second IP datagram is set to the value of that field in the original datagram plus NFB.

#How a destination system reassembles the fragments of an IP datagram?

When a host receives an IP fragment, it stores the fragment in a reassembly buffer based on its fragment offset field.

Once all the fragments of the original IP datagram are received, the datagram is processed.

Upon receiving the first fragment, a reassembly timer is started.

If the reassembly timer expires before all the fragments are received, the datagram is discarded.

#What fields are changed in an IP header due to fragmentation?

The following IP header fields are changed due to IP fragmentation:

Total Length

Header Length

More Fragments Flag

Fragment Offset

Header Checksum

Options

#What happens to the IP options field when an IP datagram is fragmented?

Depending on the option, either it is copied to all the fragments or to only the first fragment.

#Which IP options are copied to all the fragments of an IP datagram?

If the most significant bit in the option type is set (i.e. value one), then that option is copied to all the fragments. If it is not set (i.e. value zero), it is copied only to the first fragment.

IP Header Interview Questions and Answers:

#Which is the importance of identification field in the IP packet?
This is used to identify each fragmented packet so that destination device can rearrange the whole communication in order.

#Which device can reassemble the packet?
This is done only by the ultimate destination of the IP message.

#What is IP datagram?
IP datagram can be used to describe a portion of IP data. Each IP datagram has set of fields arranged in order. IP datagram has following fields Version, Header length, Type of service, Total length, checksum, flag, protocol, Time to live, Identification, Source IP Address and Destination Ip Address, Padding, Options and Payload.

#What is MTU (Maximum Transmission Unit)?
The maximum transmission unit (MTU) of an interface tells Cisco IOS the largest IP packet that can be forwarded out on that interface.

#What is Fragmentation?
Fragmentation is a process of breaking the IP packets into smaller pieces (fragments). Fragmentation is required when the datagram is larger than the MTU. Each fragment than becomes a datagram in itself and transmitted independently from source. These datagrams are reassembled by the destination.

#How the packet is reassembled?
1.When a host receives an IP fragment, it stores this fragment in a reassembly buffer based on its fragment offset field.
2.Once all the fragments of the original IP datagram are received, the datagram is processed.
3.On receiving the first fragment, a reassembly timer is started.
4.If this reassembly timer expires before all the fragments are received than datagram is discarded.

#What is the importance of DF, MF flag?
Don’t fragment bit
If DF bit is set, fragmentation is not allowed.
when a router needs to forward a packet larger than the outgoing interface’s MTU, the router either fragments the packet or discards it. If the IP header’s Do Not Fragment (DF) bit is set, means fragmentation is not allowed and the router discards the packet. If the DF bit is not set, means Fragmentation is allowed and the router can perform Layer 3 fragmentation on the packet.

More fragments bit
If MF Bit is set to 1 means more fragments are coming. If it is set to 0 means This is the Last Fragment.
All fragments that belong to an IP datagram will have more fragments bit set except for the final fragment. The final fragment does not have the more fragment bit set indicating that this is the last fragment. This is how the End hosts comes to know that it has collected all the fragments of the IP datagram.

#What is the purpose of fragment offset?
It is used to define the Size of each Fragmented Packet.

#What is the importance of TTL value?
It defines how long a packet can travel in the network. It is the number of hops that the IP datagram will go through before being discarded. At every hop TTL value is decremented by 1. When this field becomes zero, the data gram is discarded. This behavior helps prevent routing loops. The typical value for a TTL field is 32 or 64.

#What does the protocol field determines in the IP packet?
The Protocol field is an 8-bit field that identifies the next level protocol. It Indicates to which upper-layer protocol this datagram should be delivered.
Example - TCP, UDP.

SOME NOTES:
---------------------
Tcp header is much larger than UDP header hence we use UDP over TCP . It reduces the overhead.
Seq no= no assigned to the 1st byte of data in the message.
Ack no= next seq no or byte of data that rx expect to receive.
Offset = specifies the size of the Tcp header in 32 bit word and indicates where data actually begins.
Reserved field is set to 0 and can be used for further purpose.
Window : this sets the size of the rx window apart from seq no. This comes under flow control.
Padding is used to confirm that TCp header end with 32 bits .
Option is used for synchronization purpose. 

To know the size of the data we should know the size of the header length in Ip header
Minimum size of ip header is 20 bytes and maximum is 60bytes 
4 bits is used for ip header length.
So if header bits are 0101 means 5 *4 = 20 bytes 
So always bits value is multiplied with 4 and header length is calculated .
Lets we have HL = 5base16 =5 *4 = 20bytes
TL =0028base16=40bytes ie 40-20 = 20 bytes is a data 
TL=HL + data 
So tL can be 20 bytes to 65,335bytes 

How Checksum is calculated ?
HL fileds in source side are are segmented/divided into 16 nbits. Initially Checksum is set to 0. All these n sets of 16 bits are added up together .say total bits value is Nbits .Do 1’s Complement of this. Say we get Ncbits .Update checksum with this value .send this value to destination.
Now we do same process in destination . but here we will add all 16 bits value with checksum value received from sender . Do 1’s complement of it and result should be zero. Otherwise data is corrupted.

In case of proc in tcl if we use return command it will return all the variables if return command is not mentioned it will return the last command.

Three way hand shake any host can initiate the connection
Client -------------------------server
Seq x ----------------------- received seq x
Seq y <------------ Ack x+1
Ack y+1 --------received Ack y+1 
Routing Loop Avoidance Techniques
Split Horizon: Updates received in an interface can’t be sent out the same interface.
Split Horizon with Poison Reverse: Updates sent back with infinite metric (hop count 16) for every update received in an interface
Count to Infinity: To avoid continuous looping of a (bad) routing update. RIP sets the count to infinity with a hop count of 16.
Triggered Updates: supported with RIP version 2. Also known as the flash updates. If a metric is changed it is immediately advertised to neighbors without waiting for the regular scheduled update timer.