Fragmentation in IPv4 and IPv6

 General Routing & Switching, IPv6  Add comments
Oct 272012
 

Fragmentation occurs if an IP device wants to send a packet on a link and the maximum transmission unit of the link is lower than the packet size. If do not fragment bit is set in the IP header, the packet will get dropped other vise FRAGMENTED! If any of the fragments gets lost in transit, the receiver has to request for the whole packet again.

Let’s have a look at how a packet is fragmented. There are a couple of control fields in the IP header to accomplish fragmentation. The Flags will indicate if there are more fragments following or if this is the last fragment. The Fragment Offset indicates the position of the fragment in the original datagram. The Identification field is responsible to uniquely identify each fragments of the original datagram.

Let’s work though the scenario where H1 sends an ICMP request to H2. The payload size of the packet is 1600 bytes. All links other than the segment between R2 and R3 support the default IP MTU of 1500 bytes.

Internet Protocol Version 4, Src: 10.0.10.10 (10.0.10.10), Dst: 20.0.20.10 (20.0.20.10)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 1500
    Identification: 0x02ef (751)
    Flags: 0x01 (More Fragments)
    Fragment offset: 0
    Time to live: 128
    Protocol: ICMP (1)
    Header checksum: 0xd61e [correct]
    Source: 10.0.10.10 (10.0.10.10)
    Destination: 20.0.20.10 (20.0.20.10)
    Data (1480 bytes)

In the first packet we see that the Fragment offset is 0 which means this packet contains the beginning of data. The Identification 751 will be the same for all fragments. The Flag is set to 01, which means more fragments will follow.

Internet Protocol Version 4, Src: 10.0.10.10 (10.0.10.10), Dst: 20.0.20.10 (20.0.20.10)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 140
    Identification: 0x02ef (751)
    Flags: 0x00
    Fragment offset: 1480
    Time to live: 128
    Protocol: ICMP (1)
    Header checksum: 0xfab5 [correct]
    Source: 10.0.10.10 (10.0.10.10)
    Destination: 20.0.20.10 (20.0.20.10)
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0xf6f6 [correct]
    Identifier (BE): 512 (0x0200)
    Identifier (LE): 2 (0x0002)
    Sequence number (BE): 61442 (0xf002)
    Sequence number (LE): 752 (0x02f0)
    Data (1592 bytes)

In the second packet we see that the Fragment offset is 1480 and the flags 00 indicate that this is the final fragment. We can also see that 1592 bytes are the ICMP payload, which should be echoed back by H2.

Internet Protocol Version 4, Src: 20.0.20.10 (20.0.20.10), Dst: 10.0.10.10 (10.0.10.10)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 996
    Identification: 0x023d (573)
    Flags: 0x01 (More Fragments)
    Fragment offset: 0
    Time to live: 124
    Protocol: ICMP (1)
    Header checksum: 0xdcc8 [correct]
    Source: 20.0.20.10 (20.0.20.10)
    Destination: 10.0.10.10 (10.0.10.10)
Data (976 bytes)
 
Internet Protocol Version 4, Src: 20.0.20.10 (20.0.20.10), Dst: 10.0.10.10 (10.0.10.10)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 524
    Identification: 0x023d (573)
    Flags: 0x01 (More Fragments)
    Fragment offset: 976
    Time to live: 124
    Protocol: ICMP (1)
    Header checksum: 0xde26 [correct]
    Source: 20.0.20.10 (20.0.20.10)
    Destination: 10.0.10.10 (10.0.10.10)
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0
    Checksum: 0xfef6 [correct]
    Identifier (BE): 512 (0x0200)
    Identifier (LE): 2 (0x0002)
    Sequence number (BE): 61442 (0xf002)
    Sequence number (LE): 752 (0x02f0)
    Data (1592 bytes)

Now H2 must reply with 1600 bytes of IP payload. It will fragment it into two fragments. One fragment with 1500 bytes with has actual payload of 1480 bytes. The second fragment with 140 bytes which has actual payload of 120 bytes.

But as the fragmented packet with the size of 1500 reaches R3, it will fragment it further down in 2 fragments. One fragment will have 996 bytes with 976 byes of actual payload. The other fragment will be 524 bytes which has actual payload of 504 bytes. We can also see that the total ICMP data is 1592 which was originally echoed in from H1.

Internet Protocol Version 4, Src: 20.0.20.10 (20.0.20.10), Dst: 10.0.10.10 (10.0.10.10)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 140
    Identification: 0x023d (573)
    Flags: 0x00
    Fragment offset: 1480
    Time to live: 124
    Protocol: ICMP (1)
    Header checksum: 0xff67 [correct]
    Source: 20.0.20.10 (20.0.20.10)
    Destination: 10.0.10.10 (10.0.10.10)
Data (120 bytes)

This is the second fragment which was originally produced by H2.    

In IPv6 only the sender is allowed to fragment a packet. Thus the fragmentation control fields in the IPv4 header like fragment offset, fragment flags, packet ID are removed from the IPv6 header. These are now in the extension header. 

Internet Protocol Version 6, Src: 2001:12::2 , Dst: 2001:10::10
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 1240
    Next header: ICMPv6 (0x3a)
    Hop limit: 63
    Source: 2001:12::2 (2001:12::2)
    Destination: 2001:10::10 (2001:10::10)
Internet Control Message Protocol v6
    Type: Packet Too Big (2)
    Code: 0
    Checksum: 0xa39b [correct]
    MTU: 1280
    Internet Protocol Version 6, Src: 2001:10::10 , Dst: 2001:20::10
        0110 .... = Version: 6
        .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
        .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
        Payload length: 1456
        Next header: IPv6 fragment (0x2c)
        Hop limit: 127
        Source: 2001:10::10 (2001:10::10)
        Destination: 2001:20::10 (2001:20::10)
        Fragmentation Header
            Next header: ICMPv6 (0x3a)
            0000 0000 0000 0... = Offset: 0 (0x0000)
            .... .... .... ...1 = More Fragment: Yes
            Identification: 0x00000028
    Data (1184 bytes)

When H1 sends a packet which is larger than the MTU of the path, it will receive a packet too big ICMP message from R2 with the supported MTU size. Thus H1 will only send packet with maximum size of 1280 to H2.

Internet Protocol Version 6, Src: 2001:10::10 , Dst: 2001:20::10
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 1240
    Next header: IPv6 fragment (0x2c)
    Hop limit: 128
    Source: 2001:10::10 (2001:10::10)
    Destination: 2001:20::10 (2001:20::10)
    Fragmentation Header
        Next header: ICMPv6 (0x3a)
        0000 0000 0000 0... = Offset: 0 (0x0000)
        .... .... .... ...1 = More Fragment: Yes
        Identification: 0x0000002c
Data (1232 bytes)
 
 
Internet Protocol Version 6, Src: 2001:10::10 , Dst: 2001:20::10
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 384
    Next header: IPv6 fragment (0x2c)
    Hop limit: 128
    Source: 2001:10::10 (2001:10::10)
    Destination: 2001:20::10 (2001:20::10)
    Fragmentation Header
        Next header: ICMPv6 (0x3a)
        0000 0100 1101 0... = Offset: 154 (0x009a)
        .... .... .... ...0 = More Fragment: No
        Identification: 0x0000002c
Internet Control Message Protocol v6
    Type: Echo (ping) request (128)
    Code: 0
    Checksum: 0x83df [correct]
    Identifier: 0x0001
    Sequence: 155
    Data (1600 bytes)

The first packet has an offset of 0, the second fragmented packet has an offset size of 154. This means the second fragment fits at 154 * 8 = 1232 bytes after the first fragment. The size of the second fragment is 384 bytes which includes the fragment header and the ICMP header which is 8 bytes each.

Internet Protocol Version 6, Src: 2001:20::10 , Dst: 2001:10::10
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 1240
    Next header: IPv6 fragment (0x2c)
    Hop limit: 60
    Source: 2001:20::10 (2001:20::10)
    Destination: 2001:10::10 (2001:10::10)
    Fragmentation Header
        Next header: ICMPv6 (0x3a)
        0000 0000 0000 0... = Offset: 0 (0x0000)
        .... .... .... ...1 = More Fragment: Yes
        Identification: 0x0000001a
    Data (1232 bytes)
 
   
Internet Protocol Version 6, Src: 2001:20::10 , Dst: 2001:10::10
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 384
    Next header: IPv6 fragment (0x2c)
    Hop limit: 60
    Source: 2001:20::10 (2001:20::10)
    Destination: 2001:10::10 (2001:10::10)
    Fragmentation Header
        Next header: ICMPv6 (0x3a)
        0000 0100 1101 0... = Offset: 154 (0x009a)
        .... .... .... ...0 = More Fragment: No
        Identification: 0x0000001a
Internet Control Message Protocol v6
    Type: Echo (ping) reply (129)
    Code: 0
    Checksum: 0x82df [correct]
    Identifier: 0x0001
    Sequence: 155
    Data (1600 bytes)

   As routers do not do any fragmentation, the overall process is simpler than in IPv4. If R2 did not sent any ICMP packet too big messages, then H1 will not be able to reach H2.